python-dev Summary for 2003-09-01 through 2003-09-15

Discussion in 'Python' started by Brett C., Sep 22, 2003.

  1. Brett C.

    Brett C. Guest

    python-dev Summary for 2003-09-01 through 2003-09-15
    This is a summary of traffic on the `python-dev mailing list`_ from
    September 1, 2003 through September 15, 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 `comp.lang.python`_ (or
    email which is a gateway to the newsgroup) 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-fifth summary written by Brett Cannon (with school
    looming on the horizon).

    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; it's 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. PEPs (Python
    Enhancement Proposals) are located at . To
    view files in the Python CVS online, go to . Reported bugs
    and suggested patches can be found at the SourceForge_ project page.

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

    ... contents::

    ... _last summary:

    Summary Announcements
    Summary is nice and short this time. More people went on vacation
    (although Martin came back and so that helped to pick up the traffic a
    little). I skipped covering some threads that are due for PEPs since
    those will be more in-depth then anything I write.

    I should give fair warning that starting on the 22nd of September I will
    begin school. I am hoping that it will not be difficult and I will have
    a carefree time in school. But if my workload becomes a burden the
    Summaries might suffer. I hope they don't, though, and I am going to do
    my best to make sure that doesn't happen.

    If It Isn't Documented, Is It a Secret?
    Some undocumented methods in readline were discovered by Philip Eby. He
    asked if this was on purpose and whether he should submit a bug report
    on the lack of documentation. Guido told him to go ahead and submit the
    bug report.

    If you ever find something undocumented in the Python source code and
    there is nothing suggesting the code is meant to be hidden from the user
    (it's for internal use, a comment says it is experimental, etc.), then
    please file a bug report!

    Contributing threads:
    - `Undocumented functions in 'readline' module

    "You are more trouble than you are worth!", screamed the micro release
    to the new feature
    The topic of what should be backported for micro releases (with Python
    2.3.1 looming on the horizon) came up. Originally minor improvements
    were allowed in if they didn't break backwards compatibility. And of
    course bugfixes have been as well as long as they didn't break code that
    came to depend on the buggy behavior (really depends on how long the
    bugginess has been there and how well-known it is).

    But then the point of OS X 10.3 possibly becoming the largest install
    base of Python of any version (it will be 2.3) came up. With rough
    estimates being thrown around of 5 million installs in about a year's
    time, the point that making it difficult to run Python 2.3.x code on
    that size of an install base would be bad. For instance, if some small
    new feature was added to 2.3.1 then any code using that feature would
    not be able to run on a virgin install of OS X 10.3 (and considering
    that this is Mac it should not be expected that most users will want to,
    let alone know how, to add a secondary install of Python since the
    original is used by the OS and thus should not be overwritten). It
    looks like a more conservative patching scheme will be taken with micro

    Bytecode will also continue to work between releases. Guido has always
    unofficially held that position but now it has been vocalized.

    Contributing threads:
    - `Documenting branch policy

    PyPy "Berlin" sprint (29th Sep - 4th Oct 2003)
    Just what the title says: there is going to be a sprint_ for PyPy_ in
    Berlin from September 29 to October 4. Read the email for more specific
    details on goals and such.

    ... _sprint:
    ... _PyPy:

    Contributing threads:
    - `PyPy "Berlin" sprint (29th Sep - 4th Oct 2003)

    Away with you ambiguous imports!
    A discussion on how to create a hierarchy of loggers in the standard
    library led to the idea of having a way to cause an import to come
    directly from the standard library and thus remove any ambiguity from a
    relative import grabbing a similarly named module from the local package.

    Barry Warsaw said he was thinking of writing a PEP on this idea.

    Contributing threads:
    - `Consistent logging in the standard library

    Quick: want to give a Python talk at Linuxworld NY?
    If you are interested in what the title asks, then read the email for
    some details.

    Contributing threads:
    - `Quick: want to give a Python talk at Linuxworld NY?

    Be careful about saying something is "easy"
    A word of advice about saying something is "easy" on python-dev: if you
    say that you should make sure you can back up that claim because
    otherwise you will be told to write the "easy" patch and that will be
    the end of the discussion.

    Contributing threads:
    - `Making python C-API thread safe (try 2)

    Parsing dates for datetime
    There was some talk about coming up with some code to parse dates for
    the datetime module. It was kind of hand-wavy since there are multiples
    chunks of code that can do that in the standard library.

    If you have an opinion on this (or anything for that matter), make sure
    to make a post to `comp.lang.python`_ about it.

    Contributing threads:
    - `datetime issues
    Brett C., Sep 22, 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.
    Brett C.
    Aug 10, 2003
  3. Brett C.
    Ronald Oussoren
    Aug 20, 2003
  4. Brett C.
    Brett C.
    Sep 13, 2003
  5. Brett C.
    Brett C.
    Oct 13, 2003