RetroSearch Browse

Thu Jan 1 12:27:16 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-January/041564.html

At 08:25 01.01.2004 -0800, Guido van Rossum wrote:
> > I still think that depending on <...> reprs should be non-portable
> > and discouraged, also CPython is already rather whimsical in its own
> > evolution (Python 2.3):
> >
> >  >>> class X: pass
> > ...
> >  >>> X
> > <class __main__.X at 0x007E2C30>
> >  >>> class X(object): pass
> > ...
> >  >>> X
> > <class '__main__.X'>
> >  >>>
> >
> > I may change my opinion if someone writes a (unit) test pinning down what
> > is exactly meant by that somewhat.
>
>That's a good point.  I'll add a SF entry to request these unit tests.
>
>What you see as whimsical was actually done for compatibility reasons;
>the new-style classes look more like built-in classes, whose repr is
><type 'int'> or perhaps <type 'module.C'>.  (It says 'type' if it's
>pure C, 'class' if it was created by a Python class statement.)

yes, but from the point of view of a classic -> new-style migration is not 
really compatible.

<class __main__.X>
<class __main__.X at ...>
<class '__main__.X' at ...>
<type '__main__.X' at ...>

seem also reasonable variations for a new-style X. I understand that the 
first output is from class_repr while the second is from the evolution of 
type_repr. The problem is that what was expected (as compatible) isn't defined.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-January/041564.html below:

[Python-Dev] Pie-thon benchmark code ready