python-dev Summary for 2003-07-01 through 2003-07-31

Discussion in 'Python' started by Brett C., Aug 10, 2003.

  1. Brett C.

    Brett C. Guest

    python-dev Summary for 2003-07-01 through 2003-07-31
    This is a summary of traffic on the `python-dev mailing list`_ from July
    1, 2003 through July 31, 2003. It is intended to inform the wider
    Python community of on-going developments on the list. To comment on
    anything mentioned here, just post to or
    `comp.lang.python`_ with a subject line mentioning what you are
    discussing. All python-dev members are interested in seeing ideas
    discussed by the community, so don't hesitate to take a stance on
    something. And if all of this really interests you then get involved
    and join `python-dev`_!

    This is the twenty-first/twenty-second summary written by Brett Cannon
    (who is still learning how to count; gave the wrong summary count last

    All summaries are archived at .

    Please note that this summary is written using reStructuredText_ which
    can be found at . Any unfamiliar
    punctuation is probably markup for reST_ (otherwise it is probably
    regular expression syntax or a typo =); you can safely ignore it,
    although I suggest learning reST; its simple and is accepted for `PEP
    markup`_ and gives some perks for the HTML output. Also, because of the
    wonders of programs that like to reformat text, I cannot guarantee you
    will be able to run the text version of this summary through Docutils_
    as-is unless it is from the original text file.

    ... _PEP Markup:

    The in-development version of the documentation for Python can be found
    at and should be used when looking
    up any documentation on something mentioned here. Python PEPs (Python
    Enhancement Proposals) are located at . To
    view files in the Python CVS online, go to .

    ... _python-dev:
    ... _python-dev mailing list:
    ... _comp.lang.python:
    ... _Docutils:
    ... _reST:
    ... _reStructuredText:

    ... contents::

    ... _last summary:

    Summary Announcements
    It's experimentation time again! In preparation for having to cut down
    on the breadth of the summary thanks to my return to school I am
    starting this summary off as the inaugural release of the new format.
    Pretty much everything is going to change somewhat.

    First, though, I think I should explain my new viewpoint towards the
    summaries that I am taking. In order to continue to provide a certain
    level of quality and coverage while retaining my personal sanity and to
    not feel like the Summaries are a job instead of something I do for fun
    and to help others, I am going to start viewing the Summaries more from
    a journalistic perspective than a historical one. Before I felt more
    like a historian that was summarizing *everything* that happened on
    python-dev. Now, though, I am be more like a journalist, covering only
    the pertinent ideas. This also allows me to inject more of my
    personality into my writing.

    But what ramifications does this new perspective cause? Well, it will
    dictate what I do and do not summarize. I plan on several types of
    discussions to be covered in the Summaries. One is new features of the
    language. This is so people can know about them ASAP and thus comment
    on them. Since practically any feature mentioned here is experimental
    there is a chance to remove it if a community movement mounts. I will
    also cover any major thinking on the future of Python. I have always
    wished there was an easy way to see what pie-in-the-sky ideas python-dev
    was thinking of in the back of our collective mind; the summaries might
    as well fill this desire. And of course any random discussion that is
    large, important, and/or complex will continue to be covered.

    In terms of formatting and layout, that will also change along with the
    new viewpoint. I am planning to follow something more along the lines
    of the Perl's `This Week...
    <>`__; yes, I am taking a cue
    from Perl but AM Kuchling and Michael Hudson originally used this format
    as well. This means titles of summary sections will more reflect the
    topic being summarized rather than the specific thread(s). I will
    continue to list all of the threads that contributed to the summary,
    though, for reference purposes. I feel this will be beneficial since I
    know I have personally looked back into the Summary archives and had a
    hard time finding something specific since the subject of a thread does
    not always match the topic of discussion; if I can't find something and
    I know about what month it happened I can only imagine what everyone
    else has had to go through to find something!

    I am removing the Quickies section from the Summaries. This section was
    nice to have, but it just ate away at my time. This also goes along
    with the new viewpoint.

    I am sure not everyone will be happy with this change, that's fine. But
    if someone out there *truly* hates the direction I am going then they
    can step forward and take the reigns from me. But as I have stated
    before, the fine print on me giving up this post is that the person who
    takes over must be as thorough as I *used* to be; I can do the summaries
    in a half-assed fashion as well as anyone else.

    Enough of that topic. One thing I would like to mention is that the
    `Python Software Foundation`_ can now accept donations through PayPal.
    Specifics can be found at . It
    would be great if people could donate since the PSF is more than just a
    non-profit to hold the Python intellectual property. One of the goals
    of the group is to get enough money to do something like the Perl
    Foundation does and sponsor someone to hack on Python for a living for a
    set amount of time. Right now we are a ways off from having that kind
    of revenue, but there is no reason why we can't. Heck, if we can just
    get enough to sponsor one person to do full-time Python hacking for a
    week it would be beneficial. Or better yet, the PSF could sponsor one
    of their own members to write a summary of the python-dev mailing list
    for the betterment of the community. =)

    ... _PSF:
    ... _Python Software Foundation:
    ... _PayPal:

    Python 2.3 final released!
    In case for some odd reason you didn't know, Python 2.3 final has gone
    out the door. The team managed to meet the goal of getting it out by
    the end of the month so that Apple_ can use a final release instead of a
    release candidate in OS X 10.3 (a.k.a. Panther).

    The goal of this release was to continue to improve Python without
    adding any new keywords. This was met while speeding things up, fixing
    bugs, adding to the standard library, and adding some new built-ins. To
    find out what is new or has changed look at the changelog at or `What's New in Python 2.3`_.

    As with all software, there are bound to be bugs. What bugs that are
    known are listed at . If you find
    bugs not listed there, please report them on the SourceForge bug tracker
    at . Running
    the regression test suite (details on how to do this is covered in the
    documentation for the 'test' package as found at is always

    Contributing threads:
    - `Problem with 2.3b2 tarfile?`__
    - `MacPython 2.3b2 binary installer for MacOSX`__
    - `Running tests on freebsd5`__
    - `Python 2.3 release schedule update`__
    - `Vacation and possibly a new bug`__
    - `Doc/ tree closes at noon, US/Eastern`__
    - `I've tagged the tree`__
    - `cygwin errors`__
    - `test_strptime; test_logging; test_time failure`__
    - `2.3rc1 delayed`__
    - `Python 2.3 release candidate 1`__
    - `post-release festivities`__
    - `New branch for r23c2 work`__
    - `Serious CallTip Bug in IDLE`__
    - `MacPython-OS9 test failures`__
    - `Doc/ tree on trunk closed`__
    - `Cutting the 2.3c2 tonight 8pm EDT`__
    - `Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827`__
    - `RELEASED Python 2.3c2`__
    - `2.3rc2 IDLE problems on a Win2000sp3 box`__
    - `Draft: 2.3 download page`__
    - `Last priority >= 7 bug for Python 2.3`__
    - `CVS Freeze`__
    - `RELEASED Python 2.3 (final)`__


    ... _Apple:
    ... _What's New in Python 2.3:

    String Exceptions Going Extinct, Eventually
    It has been brought up several times before, but things are now moving
    along to eventually deprecate string exceptions (e.g., ``raise "this
    string exception"``). they have now been removed from the tutorial to
    prevent people new to the language from picking up habits that will
    eventually be impossible to perform.

    As for when the impending deprecation will occur only Guido knows. The
    chances of it coming before Python 3, though, is most likely small.

    Contributing threads:
    - `String exceptions in the Tutorial`__


    Someday, My CVS updates Will Succeed on the First Try...
    We all know that SourceForge_ does not have the snappiest or most
    reliable CVS_ servers in the world; Python 2.3 final's release was
    targeted a few days earlier than needed for Apple_ in case SF's CVS went
    down. Solutions to how to deal with this problem have come up.

    One specific problem that people are trying to solve is the poor
    anonymous pserver access. SF has their CVS servers set up so that
    authorized CVS commands take priority over anonymous ones and thus when
    there is heavy traffic anonymous CVS basically shuts down. Martin v.
    Löwis put up a link to a nightly tarball at of the CVS
    HEAD. has provided a nightly tarball as well at for quite some time now. The
    suggestion of having a read-only version of the CVS tree on
    was came up, but how to properly do it and who would set it up was not

    And of course there is always the option of moving CVS off of SF
    entirely. There is one offer on the table with the caveat that we need
    to know what kind of bandwidth demands we would have. Another offer
    sprung up this month from Michal Wallace to host our CVS at with the hitch that it requires an external
    Python script for secure connections (as specified at ).

    Contributing threads:
    - `alternate pserver access for python CVS?`__
    - `[fwd] SourceForge status`__
    - `Volunteering to help with pserver cvs on`__


    ... _SourceForge:
    ... _CVS:

    Which License to Use?
    Domenico Andreoli wanted to donate `python-crack`_ to the PSF_ and
    wondered what steps would be necessary to do so. He was first told that
    the module would not be included in Python since it is too specific.
    Secondly, it was suggested he not choose the PSF license. Instead, he
    was told that he should use the BSD or MIT license (both of which can be
    found at; clean, simple
    licenses that are not viral like the GPL but are GPL-compatible. This
    is so that it can be included in any software that uses Python.

    Contributing threads:
    - `donating python-crack module`__


    ... _python-crack:

    Not Quite ANSI C
    Every so often someone runs Python against a C code checker and notices
    failures that get reported to us. Often, though, we have to tell the
    person that we already know of the failures and that there is nothing to
    worry about. This time it was failures under Purify. We have also
    received reports of failures under Valgrind_ which are spurious. The
    language isn't even fully ANSI C compliant, but as Tim Peters said,
    "it's not possible to write a useful and portable memory allocator in
    100% standard ANSI C" among other reasons why strict ANSI C conformity
    is broken. The only major violations in the code are casting a pointer
    to a unsigned integer type and assuming "that whatever memory protection
    gimmicks an OS implements are at page granularity" which is a minor sin
    at best. There is also some cases of accessing memory without proper

    Contributing threads:
    - `Invalid memory read in PyObject_Free`__
    - `strict aliasing and Python`__


    ... _Valgrind:

    Shadowing Built-ins is Becoming a No-No
    Before the code was removed, Python 2.3 raised a DeprectionWarning when
    you overshadowed a built-in in a module from outside the module's actual
    code. What this means is that doing something like::

    import mod
    mod.reload = 42

    would raise the warning. Now doing ``reload = 42`` in the module itself
    would still be allowed. The idea was (and still is) that the compiler
    can know when a built-in is shadowed in a module when it compiles the
    module's code. But allowing someone to overwrite a built-in externally
    means that the compiler cannot make any assumptions that built-ins will
    forever reference the actual built-in code. This is unfortunate since
    if shadowing externally was made illegal the compiler can reference the
    built-in code directly and skip some steps for a nice speed-up.

    This is why there was code to warn against this initially. But it
    didn't work well enough to be left in Python 2.3 so it has been removed.
    But this restriction will most likely be enforced at some point so it
    is something to keep in mind.

    Contributing threads:
    - `Deprecation warning 'assignment shadows builtin'`__...
    - `DeprecationWarning: assignment shadows builtin`__


    While Python 2.3 sees up to a 30% speed increase over 2.2, it still
    starts up slower. Originally it was believed that it was because of the
    importation of the re module. Marc-André Lemburg applied a patch that
    tried to minimize its possible importation at startup but it was still slow.

    Jeremy Hylton pointed out that 2.2.3 imported re so that probably was
    not the problem. One thing that is different, though, is the automatic
    inclusion of warnings, codecs, and the ability to do zip imports. These
    three things pull more modules and all of this leads to a longer startup
    time. There is also the importation of distutils thanks to the
    module, but that only occurs if you execute in a build directory.

    Including zip imports also got attacked for the number of failed checks
    for files it can incur. But it is believed this is not as bad as all of
    the extra imports being done now and Just van Rossum said he would try
    to cut down the unneeded checks in the future.

    Contributing threads:
    - `2.3 startup speed?`__


    The World and Numbers
    People might not be aware of it, but locale.setlocale never changes the
    LC_NUMERIC locale value. This is so that 'str' and 'float' can return
    and receive numbers in a consistent way in source code. This causes a
    problem, though, for people in locales that do not use a period for a
    decimal point. If you had your locale set to Brazilian and tried to
    pass the string "3,14" to 'float' it would fail even though that is a
    legitimate number representation for your locale.

    The suggestion became to have a locale-agnostic version of 'str' and
    'float' in the locale module for people to use when they needed such
    functionality. It has now reached the stage of a rough draft PEP as
    found at .

    Contributing threads:
    - `LC_NUMERIC and C libraries`__
    - `Be Honest about LC_NUMERIC`__
    - `RE: [Spambayes] Question (or possibly a bug report)`__


    Zippin' Nothin'
    The built-in 'zip' function in Python 2.3 raises TypeError when given no
    arguments. This causes problem when you do ``zip(*args)`` and args is
    empty. So for Python 2.4 'zip' with no arguments will return an empty list.

    Contributing threads:
    - `zip() in Py2.4`__


    A Syntax For Function Attributes
    An old debate (or at least old in terms of it having popped up multiple
    times during the tenure of your author) has been ways of enhancing
    function definitions. Previously it has been over ways to make defining
    classmethod and its ilk in a cleaner fashion along with properties (past
    summaries on this can be found at

    What made the discussion slightly different this time, though, was the
    focus was on function attributes specifically. One idea was to tweak
    Michael Hudson's bracket syntax for method annnotations to allow for
    function attributes; ``def foo() [bar=42]: pass``. Another suggestion
    was to take the dictionary-like connection even farther; ``def foo()
    {bar=42}: pass``. There was no clear winner in either case partially
    because this discussion flared up towards the end of the month.

    It was also pointed out that using Michael Hudson's method descriptors
    you could come up with a wrapping function that handled the situation::

    def attrs(**kw):
    def _(func):
    for k in kw:
    setattr(func, k, kw[k])
    return func
    return _

    def foo() [attrs(bar=42)]: pass

    Perk of this is it does not lead to any special syntax just for function
    attributes. One drawback, though, as pointed out by Paul Moore is that
    this makes the method annotation idea a little to liberal and open to
    hackish solutions like this that will lead to abuse. This was not a
    huge worry, though, since almost anything can be abused and this is all
    already doable now, just without a nice, clean syntax.

    Contributing threads:
    - `A syntax for function attributes?`__

    Brett C., Aug 10, 2003
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brett C.
    Brett C.
    Jul 9, 2003
  2. Brett C.
    Ronald Oussoren
    Aug 20, 2003
  3. Brett C.
    Brett C.
    Sep 13, 2003
  4. Brett C.
    Brett C.
    Sep 22, 2003
  5. Brett C.
    Brett C.
    Oct 13, 2003
  6. Brett C.
    Brett C.
    Oct 24, 2003
  7. Brett C.
    Brett C.
    Dec 4, 2003
  8. Brett C.
    Christos TZOTZIOY Georgiou
    Dec 12, 2003