[Python-3000] Did I miss anything?

Guido van Rossum guido at python.org
Tue Apr 11 20:29:37 CEST 2006


On 4/10/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 4/10/06, Guido van Rossum <guido at python.org> wrote:
> > Are there other proto-PEPs being worked on? I would appreciate if the
> > authors would send me a note (or reply here) with the URL and the
> > status.
>
> This is the Backwards Incompatibility PEP discussed earlier.  I've
> submitted it for a PEP number, but haven't heard back yet:
>
> http://ucsu.colorado.edu/~bethard/py/pep_backwards_incompatible.txt
> http://ucsu.colorado.edu/~bethard/py/pep_backwards_incompatible.html

I like this! I hope it can be checked in soon.

> This is potentially a Python 2.6 PEP, but it has some optional
> extensions for Python 3000 and may be relevant to the
> adaptation/overloading/interfaces discussion.  It proposes a make
> statement such that:
>     make <callable> <name> <tuple>:
>         <block>
> would be translated into the assignment:
>     <name> = <callable>("<name>", <tuple>, <namespace>)
> much in the same way that the class statement works.  I've posted it
> to comp.lang.python and had generally positive feedback.  I've
> submitted it for a PEP number, but I haven't heard back yet:
>
> http://ucsu.colorado.edu/~bethard/py/pep_make_statement.txt
> http://ucsu.colorado.edu/~bethard/py/pep_make_statement.html

I don't like this. It's been proposed many times before and it always
ends up being stretched until it breaks. Also, I don't like the
property declaration use case; IMO defining explicit access method and
explicitly defining a property makes more sense. In particular it bugs
me that the proposed syntax indents the access methods and places them
in their own scope, while in fact they become (unnamed) methods. Also,
I expect that the requirement that the accessor methods have fixed
names will make debugging harder, since now the function name in the
traceback doesn't tell you which property was being accessed.

I expect that the PEP will go forward despite my passive aggressive
negativism; there are possible rebuttals for all of my objections. But
I don't have to like it.

I wish the community efforts for Python 3000 were focused more on
practical things like the effects of making all strings unicode,
designing a bytes datatype, a new I/O stack, and the view objects to
be returned by keys() etc. These things need thorough design as well
as serious prototyping efforts in the next half year.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list