[Python-Dev] python-dev Summary for 2004-03-16 through 2004-03-31 [rough draft] (original) (raw)

Brett C. bac at OCF.Berkeley.EDU
Sat Apr 10 22:27:36 EDT 2004

Don't plan on sending this summary out for a while since it is so long (over 8 pages if TextEdit is to be believed) and because of the volume of emails I had to go based on memory on some of the summaries and thus may have missed some of the discussions in the large threads.

Anyway, reply with any corrections you have and such.

===================== Summary Announcements

Still looking for a summer job or internship. Please let me know if have one at your company or happen to know of one somewhere. And yes, this message will go away; either I will actually get a summer job or the summer will come around. =)

PyCon happened during the timespan this summary covers. Unlike last year when emails to python-dev actually went down, there was a good amount of traffic at the conference. A good portion of this was due to the sprint on Python's core that took place. A bunch of core developers showed up for the whole weekend and used part of that time to answer emails. Great for python-dev but made my life a little difficult. =) But the sprint overall was a definite gain with various tweaks done, improvements to the profiler, and a bunch of bugs and patches closed (actually had the number of open patches and bugs have a net loss of 7 and 10 from that week, respectively; that has not happened in a while).

The release schedule (and thus what is definitely planned and what can go in if it gets finished in time) was set while at PyCon. Read the summary entitled Python 2.4 release schedule_ below for details and links.

========= Summaries

"I want to be like Raymond!"

So, you want to speed up Python like Raymond Hettinger has? Well, he posted an email listing various optimizations he has on his list to try out. That specific email can be found at http://mail.python.org/pipermail/python-dev/2004-March/043276.html

This also brought back the debate of whether pure Python modules should be recoded in C for performance. See previous threads for a longer discussion on the subject.

Contributing threads:

Decimal update

PEP 327_ was revised to make certain issues more explicit and to discuss possible function naming (summarized below). This lead to a discussion about how to name various things. Although there are historical violations of the coding standard, the names should follow PEP 7_ and PEP 8_.

The testing suite is also finished along with the PEP essentially being finished.

.. _PEP 327: http://www.python.org/peps/pep-0327.html

Contributing threads:

Follow the coding standard, people

Discussing naming conventions came up while discussing PEP 327. The basic conclusion is that older modules don't follow the coding standards laid out in PEP 7_ and PEP 8_, but that does not mean new code should be allowed to break the rules.

.. _PEP 7: http://www.python.org/peps/pep-0007.html .. _PEP 8: http://www.python.org/peps/pep-0008.html

Contributing threads:

"It depends on what the meaning of the word 'is' is"

The idea of redefining how 'is' operates when comparing immutable types came up. It was suggested that when two immutable objects of the same type were being compared that it should be an equivalence test instead of an identity test. For instance::

x = 99 y = 99 x is y

is true while::

x = 100 y = 100 x is y

is false. The point was made, though, that unless you are comparing to None that 'is' should not be used for comparing immutables and instead the equality operator ('==') should be used instead. There is backwards-compatibility issues with changing this.

Guido pronounced that 'is' ain't changing.

Contributing threads:

Getting PyChecker into the stdlib

The idea of adding PyChecker_ to the stdlib came up once again. Support seems to be there but the developers of PyChecker did not speak up. PyChecker 2 is under development and that changes how PyChecker does things significantly (analyzes bytecode directly) which might be why they were mum on the topic.

.. _PyChecker: http://pychecker.sf.net/

Simplifying logging.basicConfig

Simplifying basicConfig in the logging package to making logging to a file simpler was proposed. One person suggested more examples in the documentation ala unittest. Another person disagreed.

No change has been made at this point nor any specific statement as to whether any will be.

Contributing threads:

A new committer amongst us

Phillip J. Eby gained CVS commit privileges to help with development of Distutils. But Phillip has been active on python-dev for a while so I am sure he can be put to work on some other things as well. =)

Contributing threads:

Working on HP-UX

Cameron Laird is still interested in working on the port of Python on HP-UX. If you are interested in helping out please contact him.

Contributing threads:

Binding variables for generator expressions

What would you expect in this situation using generator expressions?::

gen_exps = [] for cnt in range(10): gen_exps.append(x**2 for x in range(cnt))

If you thought that gen_exps would contain 10 generators that each return a list longer than the one previous then you like capture binding for generator expressions (capturing the values of all free variables used in the generator expression at definition time). If you though there would be 10 generators that all had the power of 2 from 0 to 9 then you like late binding (using the value of the free variables in the generator expression at execution time of the generator).

Guido brought this up in his keynote for PyCon_ and said that he preferred late binding (don't remember if he pronounced; I could lie and say I was under the influence of a hang-over from a drunken stupor from the night before but I actually didn't go drinking once this year at PyCon and so my excuse is I just don't plain remember). The reasoning is that there are no surprises in terms of corner cases and having more obvious values for the free variables.

The point about performance of generator expressions was also brought up using the now-standard sum(x**2 for range(1000)) example. Using a list comprehension was actually slightly faster (less than 10%) then the generator expression. This is partially thanks to Raymond's tweaking of list comprehensions by adding the LIST_APPEND opcode. The rest is due to generator expressions creating an actual generator and thus having to create eval frames and playing with them. But it was pointed out that if the number passed into 'range' is raised then generator expressions quickly end up winning because the execution fits in the cache better, especially if xrange is used.

Contributing threads:

More than you ever wanted to know about decorators

Decorators were the topic for the latter half of March. Initially the discussion focused on where to put the list of decorators (if Guido's patch as found at http://www.python.org/sf/926860 is any indication he has a preference with the decorators coming on the line above the function/method definition) should go. With C# having a similar functionality as what is being proposed roughly following C#'s syntax was considered a good thing, albeit tweaked so that the decorator list goes on its own line (reason being the LL(1) parser is too dumb to handle it coming before the 'def' on the same line and it alleviates the issue of having a long decorator list that would a full line anyway.

With the winning syntax, though, there is the issue of preexisting code and the work at interpreter prompt. The former is a problem for code that happens to have a list that is not assigned to anything before a function definition; why anyone would have a list defined that is not assigned is beyond me. As for the latter issue, that is a slight problem. To get around it you can stick the definition in an 'if' statement::

if True: [decorate, this] def marthastewart(): pass

Slight pain, but it has been generally accepted that placing decorators on their own line is just so much easier to deal with aesthetically this minor inconvenience has been viewed as acceptable.

After PyCon Guido talked to some people who suggested having another way of tacking on metadata separate from using descriptors, partially since C#'s version of decorators is mostly for metadata. But tacking on attributes to a function can be done using the proposed decorators by defining some auxiliary function that takes in named arguments that specify the name of the attribute and the value to set it and returns a callable that will take in a function and assign the attributes.

This also brought up the discussion of setting function attributes from within a function since decorators will most likely be used to set metadata. The idea of having attributes set for the function if a name starts with '.' was brought up but Guido said he wanted to save that syntax for within a 'with' block. The other suggestion was to do func.attribute where "func" is the name of the function is being defined, but Guido gave that a -1000 vote so that ain't about to happen.

Contributing threads:

Python 2.4 release schedule

If you read PEP 320_ you will notice an alpha is currently planned in July with a possible release in September if the alphas and betas go well.

To see what is planned for this release read the PEP. Looks like some really cool new additions to Python (under the hood, stdlib, and to syntax) might make this release.

.. _PEP 320: http://python.org/peps/pep-0320.html

Contributing threads:

Cutting down on string creation at startup

Martin v. Loewis discovered that Python in CVS created about 12,000 strings while Python 2.2 created 8,000 strings. Martin subsequently changed 'marshal' so as to share strings that are the same instead of having to constantly create strings, discover they have been interned, and then destroy the second copy.

Contributing threads:

f_tstate gone the way of the dodo

In case you don't catch the meaning of the title, f_tstate has now been removed.

Contributing threads:

Tentative fix for OpenVMS and its dislike of UNIVERSAL_NEWLINES

See http://www.python.org/sf/903339 for the proposed patch.

Contributing threads:

The hell that is floating point representation

The discussion came up over the output of repr(1.1), which is '1.1000000000000001' (although, apparently, a few years back this was not the case). The objection was risen that this can surprise people since repr is what 'marshal' uses for writing .pyc files. But the counter-argument was that this forces people to deal with the issues inherent in binary floating point. Plus it makes the value consistent across platforms if you pass around a .pyc file since the value the programmer used is explicitly stated. The status quo is staying put.

It was also pointed out that decimal floating point has similar issues as binary floating point, but at least you get to specify the accuracy at the cost of speed.

Contributing threads:

Relative imports getting a bunch of dots

For PEP 328_ (which deals with relative imports of modules), Guido pronounced that he prefers the multiple dots to delineate going up a level in the directory hierarchy for handling relative imports.

.. _PEP 328: htttp://www.python.org/peps/pep-0328.html

Contributing threads:

More information about the Python-Dev mailing list