python-dev Summary for 2004-11-16 through 2004-11-30

Discussion in 'Python' started by Brett C, Jan 6, 2005.

  1. Brett C

    Brett C Guest

    python-dev Summary for 2004-11-16 through 2004-11-30
    This is a summary of traffic on the `python-dev mailing list`_ from November
    16, 2004 through November 30, 2004. 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

    This is the fifty-third summary written by Brett Cannon (Another quarter begins).

    To contact me, please send email to brett at ; I do not have the
    time to keep up on comp.lang.python and thus do not always catch follow-ups
    posted there.

    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 new code; otherwise use the current documentation as found at . 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.

    The `Python Software Foundation`_ is the non-profit organization that holds the
    intellectual property for Python. It also tries to forward the development and
    use of Python. But the PSF_ cannot do this without donations. You can make a
    donation at . Every penny helps so even a
    small donation (you can donate through PayPal or by check) helps.

    ... _python-dev:
    ... _SourceForge:
    ... _python-dev mailing list:
    ... _comp.lang.python:
    ... _Docutils:
    ... _reST:
    ... _reStructuredText:
    ... _PSF:
    ... _Python Software Foundation:

    ... contents::

    ... _last summary:
    ... _original text file:

    Summary Announcements
    PyCon_ is coming up! Being held March 23-25 in Washington, DC, registration is
    now open at for credit card
    users (you can pay by check as well; see the general info page for the conference).

    ... _PyCon:

    Would you like the source with your function?
    Would you like all functions and classes to contain a __pycode__ attribute that
    contains a string of the code used to compile that code object? Well, that
    very idea was proposed. You would use a command-line switch to turn on the
    feature in order to remove the memory and any performance overhead for the
    default case of not needing this feature.

    Some might ask why this is needed when inspect.getsource and its ilk exist.
    The perk is that __pycode__ would always exist while inspect.getsource is a
    best attempt but cannot guarantee it will have the source.

    Beyond a suggested name change to __source__, various people have suggested
    very different uses. Some see it as a convenient way to save interpreter work
    easily and thus not lose any nice code snippet developed interactively. Others
    see a more programmatic use (such as AOP "advice" injection). Both are rather
    different and led to the thread ending on the suggestion that a PEP be written
    that specifies what the intended use-case to make sure that need is properly met.

    Contributing threads:
    - `__pycode__ extension

    Skipped Threads
    - PEP 310 Status
    - python 2.3.5 release?
    look for 2.3.5 possibly in January
    - Current CVS, Cygwin and "make test"
    - syntactic shortcut - unpack to variably sizedlist
    mostly discussed `last summary`_
    - Python 2.4, MS .NET 1.1 and distutils
    - Trouble installing 2.4
    - Looking for authoritative documentation on packages, import & ihooks
    no docs exist, but feel free to write some! =)
    - String literal concatenation & docstrings
    literal string concatenation only works if the newline separating the
    strings is not significant to the parser
    - print "%X" % id(object()) not so nice
    does 'id' need to return only a positive? No, but it would be nice.
    - Bug in PyLocale_strcoll
    - Multilib strikes back
    - File encodings
    file.write does not work with Unicode strings; have to decode them to
    ASCII on your own
    Brett C, Jan 6, 2005
    1. Advertisements

  2. Guest

    > Would you like the source with your function?

    Yes, since I asked for this feature something like two years ago ;-)
    Michele Simionato
    , Jan 6, 2005
    1. Advertisements

  3. wrote:
    >>Would you like the source with your function?

    > Yes, since I asked for this feature something like two years ago ;-)

    Well, the main objection seemed to be that we can get the source of a
    function one way or another. For functions with a file (1) with
    "inspect" , for functions defined dynamically with "exec"(2), by
    "knowing what we pass to exec and storing it", and for functions defined
    in the interactive prompt (3), by using a higher level IDE/shell that is
    not the pure raw_input, but does sophisticated analysis of code fed to
    it and which will be responsible for storing functions (!!). Still I
    believe it's the job of the core python parser to get this info and
    attach it to function objects.

    The other problem was whether the source attribute should be saved to
    pyc files (or more generally marhsaled together with the function
    object). Logically it should. OTOH, for the application I had using
    this, I didn't need marshalling source because it stored all the code
    (initial functions + functions defined while the application was
    running) in python source form. So, I think that in practice one will
    use either bytecode or the __source__ feature and not both, but I can't
    prove it. 8)

    There's a PEP and an --ugly- patch for 2.3.4

    +10 ?

    Stelios Xanthakis, Jan 7, 2005
    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.
    Michael Hudson
    Feb 26, 2004
  2. Brett C.
    Brett C.
    Apr 18, 2004
  3. Brett C.
    Andrew Dalke
    May 16, 2004
  4. Brett Cannon
    Brett Cannon
    Jun 20, 2004
  5. Brett Cannon
    Brett Cannon
    Jul 6, 2004

Share This Page