Re: Tuple parameter unpacking in 3.x

[Brett C.]

On Oct 5, 9:13 am, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Martin Geisler wrote:
> > Steven D'Aprano <[EMAIL PROTECTED]> writes:
> >>> From reading the PEP-3113 I got the impression that the author
> >>> thought that this feature was unused and didn't matter.
>
> And that there were good alternatives, and that there were technical
> reasons why maintaining the feature in the face of other arguments
> options would be a nuisance.
>

As the author of PEP 3113, I should probably say something (kudos to
Python-URL bringing this thread to my attention).

There are two things to realize about the tuple unpacking that acted
as motivation. One is supporting them in the compiler is a pain.
Granted that is a weak argument that only the core developers like
myself care about.

Second, tuple unpacking in parameters breaks introspection horribly.
All one has to do is look at the hoops 'inspect' has to jump through
in order to figure out what the heck is going on to see how messy this
is. And I realize some people will say, "but if 'inspect' can handle
it, then who cares about the complexity", but that doesn't work if
'inspect' is viewed purely as a simple wrapper so you don't have to
remember some attribute names and not having to actually perform some
major hoops. I personally prefer being able to introspect from the
interpreter prompt without having to reverse-engineer how the heck
code objects deal with tuple unpacking.

>  >>> With this I wish to say that it matters to me.
>

Well, every feature matters to someone. Question is whether it matters
to enough people to warrant having a feature. I brought this up at
PyCon 2006 through a partially botched lightning talk and on python-
dev through the PEP, so this was not some snap decision on my part
that I rammed through python-dev; there was some arguing for keeping
it from some python-dev members, but Guido agreed with me in the end.

If you still hate me you can find me at PyCon 2009 and tar & feather
me *after* my talk. =)

> >> Alas, I think it's too late. I feel your pain.
>
> > Thanks! And I know it's too late, I should have found out about this
> > earlier :-(
>
> For future reference, the time to have said something would have been
> during the 3 month alpha phase, which is for testing feature and api
> changes.  I suspect, from reading the pydev discussion, that the answer
> still would have been to either use a def statement and add the unpack
> line or to subscript the tuple arg to stick with lambda expressions.
> But who knows?

I have not read this whole thread thoroughly, but it sounds like using
iterator unpacking at the call site (e.g., ``fxn(*args)`` when calling
your lambda) is out of the question because it is from a callback?

As Terry said, the alpha is one way you can give feedback if you don't
want to follow python-dev or python-3000 but still have your opinion
be heard. The other way is to subscribe to the PEP news feed (found
off of http://www.python.org/dev/peps/) to keep on top of PEPs as
practically all language changes have to result in a PEP at some
point.  And of course the last option is to follow python-dev. =)

-Brett
--
http://mail.python.org/mailman/listinfo/python-list

Secured CPython interpreter in embedded situations

[Brett C.]

I have been working on making Python a secure interpreter to run when
embedded in terms of resources with an object representation (e.g.,
files but not memory or CPU).  To save myself from repeating myself
and missing some details of exactly what I have done I am going to
point to a post to my Python blog (and I have replied to people in the
comments so if you have a question it may have been answered there):
http://sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html
.

With no one having told me they have found a hole in the design I am
ready to make a wider announcement here.  If you have a use for a
secured CPython interpreter then please have a look (although the work
generalizes to the language, I implemented it in CPython since that is
what I know best).  This work is not about replacing rexec, though!
It secures the entire interpreter and is not about running some Python
code at a higher privilege level than some other code.

If you manage to check out the code and get it run, let me know (I
have one report of someone getting it to compile but erroring out
immediately but I can't reproduce it as it still works for me after a
``make distclean``).  And if you do manage to break the security model
(manage to open a file, import a module that is not whitelisted,
etc.), then PLEASE let me know!  If the work holds up I will make an
announcement in c.l.py.a and then start the process to get my changes
into the trunk so that you don't need to use a branch.

Thanks in advance to anyone who gives the code a whirl.

-Brett

-- 
http://mail.python.org/mailman/listinfo/python-list

Localized Type Inference of Atomic Types in Python

[Brett C.]

My thesis, "Localized Type Inference of Atomic Types in Python", was
successfully defended today for my MS in Computer Science at the California
Polytechnic State University, San Luis Obispo.  With that stamp of approval I
am releasing it to the world.  You can grab a copy at
http://www.drifty.org/thesis.pdf .

For those of you who attended my talk at PyCon 2005 this is the thesis that
stemmed from the presented data.

As of this exact moment I am not planning to release the source code mainly
because it's a mess, I am not in the mood to pull the patches together, and the
last thing I want happening is people finding mistakes in the code.  =)  But if
enough people request the source I will take the time to generate a tar.bz2
file of patches against the 2.3.4 source release and put them up somewhere.

Below is the abstract culled directly from the thesis itself.

-Brett C.

-
ABSTRACT

Types serve multiple purposes in programming.  One such purpose is in providing
information to allow for improved performance.  Unfortunately, specifying the
types of all variables in a program does not always fit within the design of a
programming language.

Python is a language where specifying types does not fit within the language
design.  An open source, dynamic programming language, Python does not support
type specifications of variables.  This limits the opportunities in Python for
performance optimizations based on type information  compared to languages that
do allow or require the specification of types.

Type inference is a way to derive the needed type information for optimizations
based on types without requiring type specifications in the source code of a
program.  By inferring the types of variables based on flow control and other
hints in a program, the type information can be derived and used in a
constructive manner.

This thesis is an exploration of implementing a type inference algorithm for
Python without changing the semantics of the language.  It also explores the
benefit of adding type annotations to method calls in order to garner more type
information.
-- 
http://mail.python.org/mailman/listinfo/python-list

python-dev Summary for 2005-03-16 through 2005-03-31 (my last)

[Brett C.]

[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2005-03-16_2005-03-31.html]



=
Summary Announcements
=

---
My last summary
---
So, after nearly 2.5 years, this is my final python-dev Summary.  Steve
Bethard, Tim Lesher, and Tony Meyer will be taking over for me starting with
the April 1 - April 15 summary (and no, this is not an elaborate April Fool's).
 I have learned a ton during my time doing the Summaries and I appreciate
python-dev allowing me to do them all this time.  Hopefully I will be able to
contribute more now in a programming capacity thanks to having more free time.


PyCon was fantastic!

For those of you who missed PyCon, you missed a great one!  It is actually my
favorite PyCon to date.  Already looking forward to next year.


Python fireside chat

Scott David Daniels requested a short little blurb from me expounding on my
thoughts on Python.  Not one to pass on an opportunity to just open myself and
possibly shoot myself in the foot, I figured I would take up the idea.  So here
we go...

First, I suspect Python 3000 stuff will start to make its way into Python.
Stuff that doesn't break backwards compatibility will most likely start to be
implemented as we head toward the Python 2.9 barrier (Guido has stated several
times that there will never be a Python 2.10).  Things that are not
backwards-compatible will most likely end up being hashed out in various PEPs.
 All of this will allow the features in Python 3000 to be worked in over time
so there is not a huge culture shock.

As for things behind the scenes, work on the back-end will move forward.  Guido
himself has suggested that JIT work should be looked into (according to an
interview at http://www.devsource.com/article2/0,1759,1778272,00.asp).  I know
I plan to fiddle with the back-end to see if the compiler can be made to do
more work.

Otherwise I expect changes to be made, flame wars to come and go, and for
someone else to write the python-dev Summaries.  =)


=
Summaries
=


Python 2.4.1 out

Anthony Baxter, on behalf of python-dev, has released `Python 2.4.1`_.

.. _Python 2.4.1: http://www.python.org/2.4.1/

Contributing threads:
  - `RELEASED Python 2.4.1, release candidate 1
`__
  - `RELEASED Python 2.4.1, release candidate 2
`__
  - `BRANCH FREEZE for 2.4.1 final, 2005-03-30 00:00 UTC
`__
  - `RELEASED Python 2.4.1 (final)
`__


-
AST branch update
-
I, along with some other people, sprinted on the `AST branch`_ at PyCon.  This
led to a much more fleshed out design document (found in Python/`compile.txt`_
in the AST branch), the ability to build on Windows, and applying Nick
Coghlan's fix for hex numbers.

Nick also did some more patch work and asked how AST work should be tagged.
There is now an AST category on SourceForge that people should use to flag
things as for the AST.  They should also, by default, assign such items to me
("bcannon" on SF).  We have also taken to flagging threads on the AST with
"[AST]" as the first item in the subject line.

There was also a slight discussion/clarification on the functions named
marshal_write_*() that output a byte format for the AST that is supposed to be
agnostic of implementation.  This will most likely end up being used as the way
to pass AST objects back and forth between C and Python code.  But with the
name collision of the word "marshal" with the actual 'marshal' module, it needs
to be changed.  I have suggested

- byte_encode
- linear_form
- zephyr_encoding
- flat_form
- flat_prefix
- prefix_form

while Nick Coghlan suggsted

- linear_ast
- bytestream_ast

Obviously I prefer "form" and Nick prefers "ast".  With Nick's reply being
independent of mine it will most likely have "linear" or "byte" in the name.

With the patches for descriptors and generator expressions sitting on SF,
syntactic support for all of Python 2.4 should get applied shortly.  After that
it will come down to bug hunting and such.  There is a todo list in the design
doc for those interested in helping out.

.. _AST branch:
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/?only_with_tag=ast-branch
.. _compile.txt:
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/Attic/compile.txt?rev=1.1.2.10&only_with_tag=ast-branch&view=markup

Contributing threads:
  - `Procedure for AST Branch patches
`__
  - `[AST] A somewhat less trivial patch than the last one. . .

python-dev Summary for 2005-03-01 through 2005-03-15

[Brett C.]

[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2005-03-01_2005-03-15.html]

=
Summary Announcements
=
-
Second to last summary for me
-
Just a reminder, after this Summary there is only one more left for me to 
write.  After that Tim Lesher, Tony Meyer, and Steven Bethard will be taking over.

-
See you at PyCon!
-
PyCon_ is practically upon us!  If you are going to be there, great!  Please 
feel free to say hello if you run into me (will be at the sprints and the 
conference Wednesday and Thursday; skipping Friday to see a friend).  Always 
happy to stop-and-chat.

.. _PyCon: http://www.pycon.org/

2.4.1 should be out soon

Python 2.4c2 has now been released.  Assuming no major issues come up, 2.4 
final will be out March 29; day after PyCon.

But in order to make sure no issues come up, we need the code to be tested! 
Please get the code and run the regression tests.  If you are on a UNIX system 
it is as easy as running ``make test`` (``make testall`` is even better).  The 
tests can also be run on non-UNIX systems; see 
http://docs.python.org/lib/regrtest.html on how.

=
Summaries
=
--
2.4 should be out soon
--
Python 2.4.1c1 was releaseed, but enough bugs were found and subsequently fixed 
that c2 release will occur before 2.4 final comes out.

Contributing threads:
  - `2.4.1c1 March 10th, 2.4.1 March 17th 
`__
  - `BRANCH FREEZE for 2.4.1rc1,  UTC, 2005-03-10 
`__
  - `branch release24-maint is unfrozen, 2.4.1rc2? 
`__
  - `os.access and Unicode 
`__
  - `RELEASED Python 2.4.1, release candidate 1 
`__
  - `distutils fix for building Zope against Python 2.4.1c1 
`__
  - `Python2.4.1c1 and win32com 
`__
  - `Open issues for 2.4.1 
`__

---
Getting state of all threads in interpreter
---
Florent Guillaume wrote some code for Zope that returned the current state of 
all threads in the interpreter, regardless of whether they were hung or not. 
Tim Peters suggested someone write up some code so that this could be made 
available in Python itself.

Fazal Majid has volunteered to implement this.
Contributing threads:
  - `Useful thread project for 2.5? 
`__

-
No new features in micro releases
-
A bug in os.access() not allowing Unicode strings triggered the discussion of 
whether it was a bugfix to repair the issue or a new feature.  In the end it 
was decided it was a bugfix.  But the point was specified that micro releases 
should never have any new feature, no matter how small.

Contributing threads:
  - `[Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36 
`__
  - `No new features 
`__
  - `os.access and Unicode 
`__
  - `rationale for the no-new-features approach 
`__

-
Python wins Jolt "Productivity Award"
-
Python was runner-up in the `15th annual Jolt Awards`_ in the category of 
"Languages and Development Environments", being given the "Productivity Award". 
 Python is now award-winning.  =)

.. _15th annual Jolt Awards: 
http://www.sdmagazine.com/jolts/15th_jolt_finalists.html

Contributing threads:
  - `FWD: SD MAgazine.com - Jolt Awards Winners 
`__
  - `Python 2.4 won the "Jolt productivity award" last night 
`__

--
New built-ins: any() and all()
--
Python 2.5 gains two new built-ins: any(), which returns True if the iterable 
passed to it contains any true items, and all(), which returns True if all the 
items in the iterable passed to it are true.

Contributing threads:
  - `Adding any() and all() 

python-dev Summary for 2005-02-15 through 2005-02-28

[Brett C.]

[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2005-02-15_2005-02-28.html]

=
Summary Announcements
=

Status of the candidates

It looks like all three candidates for taking over the Summaries (Tony Meyer, 
Steven Bethard, and Tim Lesher) have agreed to actually do the Summaries 
together.  SO no break in the Summaries and I don't have to agonize over 
choosing a successor.

---
PyCon Looms
---
PyCon_ is coming soon!
.. _PyCon: http://www.pycon.org/
=
Summaries
=
-
PEP movements
-
`PEP 309`_ is now final since the 'functional' module has now been checked into 
Python.

.. _PEP 309: http://www.python.org/peps/pep-0309.html
Contributing threads:
  - `PEP 309 enhancements 
`__
  - `PEP 309 
`__

--
Indices for slices other objects with __int__ not okay
--
Travis Oliphant asked if it would be possible to patch slicing so that any 
object that defines __int__ could be used.

Guido didn't like this idea, though.  Float, for instance, has __int__ defined. 
 Guido admitted he "unfortunately copied a design mistake from C here".  He 
said he might add a __trunc__ magic method in Python 3000 for objects that 
really can't be viewed as an int but are willing to have data loss to give one.

Contributing threads:
  - `Fixing _PyEval_SliceIndex so that integer-like objects can be used 
`__
  - `Fix _PyEval_SliceIndex (Take two) 
`__


Why can't ``class C(): pass`` be acceptable?

No reason.  =)  So as of Python 2.5 it is acceptable to have empty parentheses 
for class definitions.  It does create a classic class and not a new-style one.

Contributing threads:
  - `Requesting that a class be a new-style class 
`__

--
What basestring is truly meant for
--
What is basestring for?  According to Guido it is purely for unicode and str to 
inherit from to help with checks in code where either type is acceptable.  It 
is *not* meant to be used as a base class for any other classes.

Contributing threads:
  - `UserString 
`__

--
Quickly opening an SF bug/patch in Firefox/Thunderbird
--
Martin v. LÃwis posted a way to use the DictionarySearch_ plug-in for Mozilla 
to launch a browser with the highlighted patch/bug #.  See the email for the 
thread on how to get it to work.

.. _DictionarySearch: 
http://dictionarysearch.mozdev.org/download.php/http://downloads.mozdev.org/dictionarysearch/dictionarysearch_0.8.xpi

Contributing threads:
  - `Quick access to Python bug reports in Thunderbird 
`__


Optimizing ``x in [1, 2, 3]``

Raymond Hettinger has been trying to teach the peepholer some new tricks to 
optimize ``x in [1, 2, 3]`` and the like into a faster operation.  Initially he 
got it to change the list to a tuple.  He then tried turning the list into a 
frozenset, but that had the unforeseen issue of breaking semantics since it 
then required the object being checked for to be hashable.

So Raymond suggested introducing a SearchSet that tried the comparison as a 
frozenset first, and upon failure of hashing, to old way of just looking at 
each item in the list.

But this seemed like overkill since most lists would be small; probably usually 
under 4 items.  But Fredrik Lundh suggested expanding it to ``x == 1 or x == 2 
or x == 3``.  This seemed like a performance boost when the items of the list 
were lists since the COMPARE_OP opcode special-cases comparing ints.  But for 
other instances it probably isn't worth it unless more special-casing is done 
in the opcodes.

Contributing threads:
  - `Prospective Peephole Transformation 
`__

--
A DupStore opcode?
--
Raymond Hettinger suggested a new opcode called DupStore that would replace 
load;store opcode pairs.  Guido questioned if this was leading down a road of 
adding too much extra code for little benefit.

Off this a discussion about speeding up frame allocation, an area viewed as 
need

python-dev Summary for 2005-02-01 through 2005-02-14

[Brett C.]

[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2005-02-01_2005-02-14.html]

=
Summary Announcements
=
--
Giving myself a gold watch
--
As some of you may have already heard or read, I am retiring from writing the 
python-dev Summaries after sending out the March 16 - 31 summary.  It has been 
a long time coming and it required a kick in the ass (graciously supplied by 
Steve Holden) to finally make me let go of doing this and let someone else take 
over.

The joy of the Summaries has dwindled over the 2.5 years I have been doing 
this.  I was only doing them to be helpful.  But now I would rather put my time 
and effort I have for Python into coding work rather than the Summaries.  I 
would like to think I can be more productive and helpful as a programmer than a 
writer.  And so there will only be three more regular Summaries after this 
written by yours truly.

But do not worry about the Summaries dying!  When I announced this (see 
http://mail.python.org/pipermail/python-dev/2005-March/051823.html for the 
thread that led to this), three individuals stepped forward to pick up the work 
once I step down.  Steven Bethard, Tony Meyer, and Tim Lesher are being 
considered for picking up where I left off.  There is the possibility that they 
will actually write the Summaries together as a team.

As for my last Summary, expect a more expository one with my random thoughts on 
PyCon, Python, and anything else that comes to mind that I feel like using this 
space to abuse.  You have Scott David Daniels to thank for that format idea for 
my final hurrah.


Go to PyCon!

I just booked my hotel room for PyCon_.  You going to be there so I can shake 
your hand, thanking you for supporting Python?

.. _PyCon: http://www.pycon.org/
=
Summaries
=
-
Python Security Response Team founded
-
For those of you who don't know, a security hole was found in XML-RPC servers 
in the stdlib that use register_instance; details at 
http://www.python.org/security/PSF-2005-001/ .

In response to this, Guido has now formed the 'Python Security Response Team`_. 
 This group's job is to respond to any and all security issues that come up as 
quickly as possible and to issue a patch in a timely fashion.

.. _Python Security Response Team: http://www.python.org/security/
Contributing threads:
  - `Wanted: members for Python Security Response Team 
`__

--
Licensing issues in the stdlib
--
It was reported to python-dev that 'profiler' and 'md5 do not conform to the 
Debian Free Software Guidelines.  The specific issue was derived works using 
Python.  This is obviously not a good thing.

Things are in the works, though.  The hope is to get the copyrights signed over 
and all of this cleared up.  At worst the modules will be replaced with code 
licensed to the Python Software Foundation.  If you care to accelerate this by 
writing replacements please do so.

Contributing threads:
  - `license issues with profiler.py and md5.h/md5c.c 
`__

---
Replacing list of constants with tuple of constants
---
note: written by Tim Lesher
Skip Montanaro noticed that Raymond Hettinger had made a number of
library checkins replacing lists with tuples in constructs like ``for
a in [1, 2, 3]:`` and ``if a in [1, 2, 3]:``.  He agreed with the
motivation (the peephole optimizer can convert a tuple of constants
into a single constant, eliminating construction time), but questioned
hardcoding the optimization.  Instead, he suggested teaching the
optimizer about "throwaway" lists in ``for`` and ``if`` statements.
Guido agreed with the sentiment.  Raymond accepted the suggestion, and
checked in code to implement it.  There were some issues, though, but those 
will be covered in the next Summary.

Contributing threads:
  - `list of constants -> tuple of constants 
`__

---
Complex I/O problem
---
note: written by Tim Lesher
Neal Becker asked why the result of printing a complex number is not an
acceptable input to constructing a complex.  For example, ``print
complex(2,2)`` yields ``'(2+2j)'``; but ``complex('(2+2j)')`` throws a
ValueError.
A. M. Kuchling responded that many types, including 'str' and
'file' share this behavior, and that in any event, parsing string
representations is a job more suited to 'eval' than to classes
themselves.
Guido `reiterated the rules`_ for str() (used by 'print') and
repr(). Since both complex.__str__ and comp

Re: [Python-Dev] Re: OK, time to retire

[Brett C.]

[taking python-dev off of the Cc: list]
Scott David Daniels wrote:
Brett C. wrote:
I have decided that I am going to stop doing the python-dev Summaries
 > after PyCon; the Summary covering the last half of March 2005 will be
 > it for me.
I (as well as most, I'd guess) have enjoyed your voice in the summaries.
Thanks for a great series of summaries.  Perhaps your final summary
could be a personal view of PyCon for those of us unable to get there.
If people want that, sure, be happy to cover PyCon.  Anybody else like that 
idea?  Or do the various bloggers who attend do a good enough job of coverage?

If you make no more contribution to Python than you have so far, you
will have done us a great service.
=)  Thanks.  Glad I have been able to help.
-Brett
--
http://mail.python.org/mailman/listinfo/python-list

OK, time to retire (was: Re: python-dev Summary for 2005-01-16 through 2005-01-31)

[Brett C.]

Steve Holden wrote:
Michele Simionato wrote [on c.l.py]:
Brett Cannon:
[... python-dev summary ... boilerplate change ...]
+1 for this idea. The summary looks much better now :)
Keep the good work going,
Sorry, but i have to disagree. I hope you won't take this reply 
personally, Michele, since it's directed to all c.l.py readers, as well 
as (particularly) at Python users who [unlike you] are mostly take and 
rather less give. Although this is inherently the nature of open source, 
in certain cases this can be taken too far.

[SNIP]
Now, the reason for this specific rant is this: I can tell a cry for 
help when I see one. Brett has done a magnificent job of providing 
python-dev summaries since Andrew decided he'd had enough, and he is to 
be congratulated for it. I managed to offload another bunch of work on 
him (moderation of various troublesome PyCon mailing lists), but at 
least I was able to recompense him by letting him into PyCon for nothing.

[SNIP]
But frankly, I think it's time someone else stood up and said "Brett, 
you've done a magnificent job. Hesitant though I am about replacing you, 
I would like to volunteer for the task, because only when you are free 
from the burden of writing the python-dev summaries will we see what 
else you are capable of". Since I am at best an intermittent reader of 
python-dev I can say this without fear of having to stand up myself.

[SNIP]
[I am going to use this to reply to both Steve and Martin]
As Steve mentioned above, he can spot a cry for help when he sees one.  I think 
the problem is that I am a total sucker when it comes to the Python community 
and python-dev.

Anyone who has been on the python-dev list for as long as I have been a 
participant has most likely seen my almost yearly "thank you" emails I send the 
list (which there will probably be another one of once I choose where I am 
going to pursue my doctorate; I have acceptances but I am still waiting to here 
back from 9 more schools).  Usually it is just me gushing to python-dev, 
thanking the list for how Python has gotten me where I am today.  And that 
statement is completely sincere; python-dev has sculpted me into the programmer 
that I am (does this mean I can blame python-dev for my own buggy code?  =). 
And for that I will be eternally grateful to all of the wonderful people I have 
gotten to work with and know on this list.

It has also made me want to help people to get involved on python-dev in hopes 
others would benefit from python-dev the same way I have.  Granted, python-dev 
tends not to attract people like I was when I started getting involved (a 
philosophy degree and 4 CS courses does not equal a good programmer by default 
 =), but I have always hoped that through my efforts some other people could 
come to enjoy hacking on Python, learn some things, and advance the language.

But I think the big problem is that the Summaries have become a "gift" in the 
truest sense of the word.  I lost all personal benefit from the Summaries over 
a year ago.  Initially I learned a ton from all of the reading I was doing and 
the research required to understand what the heck people were talking about. 
But I have graduated from "The School of Hard Knocks".  At this point I do the 
Summaries entirely altruistically, giving back what I can to the community in a 
way that I know benefits many people which happens to have zero benefit to me now.

The Summaries consume what little free time I do have for Python which is 
unfortunate.  I have always hoped I would get to the point in my programming 
abilities that I would be a larger asset to python-dev as a programmer than as 
a writer.  I would like to think I have reached that point finally after my 
over two and a half years on the list (I can't believe I first posted to the 
list on June 17, 2002!).

So, to make sure I don't squander what time I do have for Python waiting for a 
possible replacement that might never come, I have decided that I am going to 
stop doing the python-dev Summaries after PyCon; the Summary covering the last 
half of March 2005 will be it for me.  Hopefully I will be more valuable as an 
active participant on python-dev again instead of as a passive listener who 
just happens to chime in on occasion and squash a simple bug when I am 
procrastinating from doing my homework.

This has been a long time coming and I needed a swift kick in the ass to 
finally get me to stop.  I thank you, Steve, for giving me that kick like the 
English gentleman you are.  =)

-Brett
--
http://mail.python.org/mailman/listinfo/python-list

python-dev Summary for 2005-01-16 through 2005-01-31

[Brett C]

=
Summary Announcements
=
-
School sure likes to destroy my free time
-
A month late, that much closer to having this hectic quarter being over.  Sorry 
for being so delinquent with this summary but school has kept me busy and 
obviously the Real World has to take precedence over volunteer work.  Now if I 
could only get paid for doing this... =)

And if you hate the summaries being late, you could do it yourself.  This is 
not meant to be a flippant comment!  I am always willing to hand over 
development of the summaries to anyone who is willing to do a comparable job. 
If you are interested feel free to email me.  I have now made this a permanent 
offer in the header in case someone comes along later and decides they want to 
do this.

--
RSS feed now available
--
Thanks entirely to one of my predecessors, A.M. Kuchling, the python-dev 
Summaries are available as an `RSS feed`_.  The feed contains the titles of 
every summary and so will be updated with the newest summaries as soon as they 
are posted online.  A full text feed will eventually be available.

--
New format
--
I have done a thorough restructuring of the boilerplate and the Summary 
Announcements section for the Summaries.  The purpose of this is to make 
finding information in the boilerplate much easier.  It also keeps consistency 
by sectioning off everything as in the Summary section.

The other reason is for the ``contents`` directive in reST_.  This will provide 
a more thorough table of contents for the web version of the summary at the 
very top of the summaries.  This will allow people to jump directly to the 
section of the Summary they care about the most.  Obviously this perk only 
exists in the HTML version.

Lastly, the typical boilerplate for each Summary has now been moved to the 
bottom.  This was at the request of a regular reader who I would like to keep 
happy.  =)  It also seems reasonable since once you have read through it once 
chances are you are not going to read it again so might as well move it out of 
the way.

Then again I could be totally wrong about all of this and manage to alienate 
every person who reads the summaries regularly.  =)


===
Summary
===
-
Python 2.3.5 released
-
Consider how late this summary is I bet you already knew Python 2.3.5 was 
already out the door.  =)

With Python 2.4 out in the world this means there is a very high probability 
2.3.6 will never exist and this marks the end of the 2.3 branch.

Contributing threads:
  - `2.3.5 delayed til next week 
`__
  - `2.3 BRANCH FREEZE imminent! 
`__
  - `RELEASED Python 2.3.5, release candidate 1 
`__

--
Making magic type conversion methods act like __str__
--
Walter DÃrwald discovered that when you subclass 'unicode' and call unicode() 
on an instance of the subclass it will not call the implementation of 
__unicode__ of the subclass but instead will call unicode.__unicode__ .  When 
in the same scenario with strings, though, str() calls the subclass' __str__ 
method.  Turns out 'int' and 'float' act like 'unicode' while 'complex' acts 
like 'str'.

So who is right?  Docs say 'str' is wrong, but this is mainly an artifact of 
pre-2.2 inability to subclass types.  Turns out 'str' is acting properly. 
`Patch #1109424`_ implements the proper semantics and will eventually go in for 
2.5 (won't touch 2.4 since it is a semantic change).

.. _Patch #1109424: http://www.python.org/sf/1109424
Contributing threads:
  - `__str__ vs. __unicode__ 
`__

-
Speeding up function calls to C API functions
-
Neal Norwitz posted the patch found at http://www.python.org/sf/1107887 to help 
with function calls to C code.  The idea is to expand the family of values used 
in PyMethodDef.ml_flags for argument types to include specifying the number of 
minimum and maximum number of arguments.  This can provide a speedup by 
allowing the eval loop to unpack everything in the C stack and skip packing 
arguments in a tuple.

But not everyone was sure it was worth the extra need to specify all of this 
for functions.  Regardless of that and any other objections this would be more 
of a Python 3000 thing.

Which also led to a quick shift in topic to how Python 3.0 will be developed. 
Guido said it would be piece-meal.  Read 
http://joelonsoftware.com/articles/fog69.html for why.

Co

python-dev Summary for 2005-01-01 through 2005-01-15

[Brett C]

This is a summary of traffic on the `python-dev mailing list`_ from January 01, 
2005 through January 15, 2005.  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 
python-list@python.org 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 fifty-sixth summary written by Brett Cannon (I don't want to do my
homework).
To contact me, please send email to brett at python.org ; 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 http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText_ which can be 
found at http://docutils.sf.net/rst.html .  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: http://www.python.org/peps/pep-0012.html
The in-development version of the documentation for Python can be found at
http://www.python.org/dev/doc/devel/ and should be used when looking up any
documentation on new code; otherwise use the current documentation as found at
http://docs.python.org/ .  PEPs (Python Enhancement Proposals) are located at 
http://www.python.org/peps/ .  To view files in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  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 http://python.org/psf/donations.html .  Every penny helps so even a 
small donation (you can donate through PayPal or by check) helps.

.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. contents::
.. _last summary: http://www.python.org/dev/summary/2004-12-16_2004-12-31.html
.. _original text file: 
http://www.python.org/dev/summary/2005-01-01_2005-01-15.ht

=
Summary Announcements
=
PyCon_ will be upon us come late March!  Still time to plan to go.
A warning on the thoroughness off this summary is in order.  While trying to 
delete a single thread of email I managed to accidentally delete my entire 
python-dev mailbox.  I did the best I could to retrieve the emails but it's 
possible I didn't resuscitate all of my emails, so I may have overlooked something.

.. _PyCon: http://www.pycon.org/
===
Summary
===
-
PEP movements
-
tip:: PEP updates by email are available as a topic from the `Python-checkins`_ 
mailing list.

`PEP 246`_ was a major topic of discussion during the time period covered by 
this summary.  This all stemmed from `Guido's blog`_ entries on optional type 
checking. This led to a huge discussion on many aspects of protocols, 
interfaces, and adaptation and the broadening of this author's vocabulary to 
include "Liskov violation".

"Monkey typing" also became a new term to know thanks to Phillip J. Eby's 
proto-PEP on the topic (found at 
http://peak.telecommunity.com/DevCenter/MonkeyTyping).  Stemming from the 
phrase "monkey see, monkey do", it's Phillip version of taking PEP 246 
logically farther (I think; the whole thing is more than my currently 
burned-out-on-school brain can handle right now).

.. _Python-checkins: http://mail.python.org/mailman/listinfo/python-checkins
.. _PEP 246: http://www.python.org/peps/pep-0246.html
.. _Guido's blog: http://www.artima.com/weblogs/index.jsp?blogger=guido
Contributing threads:
  - `getattr and __mro__ 
`__
  - `Son of PEP 246, redux 
`__
  - `PEP 246: lossless and stateless 

python-dev Summary for 2004-12-16 through 2004-12-31

[Brett C.]

This is a summary of traffic on the `python-dev mailing list`_ from December 
16, 2004 through December 31, 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 
python-list@python.org 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 fifty-fifth summary written by Brett Cannon (I have been doing this
for too long...).
To contact me, please send email to brett at python.org ; 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 http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText_ which can be 
found at http://docutils.sf.net/rst.html .  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: http://www.python.org/peps/pep-0012.html
The in-development version of the documentation for Python can be found at
http://www.python.org/dev/doc/devel/ and should be used when looking up any
documentation on new code; otherwise use the current documentation as found at
http://docs.python.org/ .  PEPs (Python Enhancement Proposals) are located at 
http://www.python.org/peps/ .  To view files in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  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 http://python.org/psf/donations.html .  Every penny helps so even a 
small donation (you can donate through PayPal or by check) helps.

.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. contents::
.. _last summary: http://www.python.org/dev/summary/2004-12-01_2004-12-15.html
.. _original text file: 
http://www.python.org/dev/summary/2004-12-16_2004-12-31.ht

=
Summary Announcements
=
You can still `register `__ for 
`PyCon`_.  The `schedule of talks`_ is now online.  Jim Hugunin is lined up to 
be the keynote speaker on the first day with Guido being the keynote on 
Thursday.  Once again PyCon looks like it is going to be great.

On a different note, as I am sure you are all aware I am still about a month 
behind in summaries.  School this quarter for me has just turned out hectic.  I 
think it is lack of motivation thanks to having finished my 14 doctoral 
applications just a little over a week ago (and no, that number is not a typo). 
 I am going to for the first time in my life come up with a very regimented 
study schedule that will hopefully allow me to fit in weekly Python time so as 
to allow me to catch up on summaries.

And this summary is not short because I wanted to finish it.  2.4 was released 
just before the time this summary covers so most stuff was on bug fixes 
discovered after the release.

.. _PyCon: http://www.pycon.org/
.. _schedule of talks: http://www.python.org/pycon/2005/schedule.html
===
Summary
===
-
PEP movements
-
I introduced a `proto-PEP 
`__ to 
the list on how one can go about changing CPython's bytecode.  It will need 
rewriting once the AST branch is merged into HEAD on CVS.  Plus I need to get a 
PEP number assigned to me.  =)

Contributing threads:
  - `proto-pep: How to change Python's bytecode 
`__


Handling versioning within a package

The suggestion of extending import syntax to support explicit ve

python-dev Summary for 2004-12-01 through 2004-12-15

[Brett C.]

This is a summary of traffic on the `python-dev mailing list`_ from December 
01, 2004 through December 15, 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 
python-list@python.org 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 fifty-fourth summary written by Brett Cannon (amazed no one has
complained about the lateness of these summaries!).
To contact me, please send email to brett at python.org ; 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 http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText_ which can be 
found at http://docutils.sf.net/rst.html .  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: http://www.python.org/peps/pep-0012.html
The in-development version of the documentation for Python can be found at
http://www.python.org/dev/doc/devel/ and should be used when looking up any
documentation on new code; otherwise use the current documentation as found at
http://docs.python.org/ .  PEPs (Python Enhancement Proposals) are located at 
http://www.python.org/peps/ .  To view files in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  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 http://python.org/psf/donations.html .  Every penny helps so even a 
small donation (you can donate through PayPal or by check) helps.

.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. contents::
.. _last summary: http://www.python.org/dev/summary/2004-11-16_2004-11-30.html
.. _original text file: 
http://www.python.org/dev/summary/2004-12-01_2004-12-15.ht

=
Summary Announcements
=
PyCon_ 2005 planning is well underway.  The schedule has been posted at 
http://www.python.org/pycon/2005/schedule.html and looks great with a quite the 
varied topics.  And there is still time for the early-bird registration price 
of $175 ($125 students) before it expires on January 28th.

Some day I will be all caught up with the Summaries...
.. _PyCon: http://www.pycon.org
=
Summaries
=
--
PEPS: those existing and gestating
--
[for emails on PEP updates, subscribe to python-checkins_ and choose the 'PEP' 
topic]

A proto-PEP covering the __source__ proposal from the `last summary`_ has been 
posted to python-dev.

`PEP 338`_ proposes how to modify the '-m' modifier so as to be able to execute 
modules contained within packages.

.. _python-checkins: http://mail.python.org/mailman/listinfo/python-checkins
.. _PEP 338: http://www.python.org/peps/pep-0338.html
Contributing threads:
  - `PEP: __source__ proposal 
`__
  - `PEP 338: Executing modules inside packages with '-m' 
`__

---
Deprecating modules
---
The xmllib module was deprecated but not listed in `PEP 4`_.  What does one do? 
 Well, this led to a long discussion on how to handle module deprecation.

With the 'warning' module now in existence, PEP 4 seemed to be less important. 
 It was generally agreed that listing modules in PEP 4 was no longer needed. 
It was also agreed that deleting deprecated modules was not needed; it breaks 
code and disk space is cheap.

It seems that no longer listing documentation a

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

[Brett C]

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 
python-list@python.org 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 fifty-third summary written by Brett Cannon (Another quarter 
begins).
To contact me, please send email to brett at python.org ; 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 http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText_ which can be 
found at http://docutils.sf.net/rst.html .  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: http://www.python.org/peps/pep-0012.html
The in-development version of the documentation for Python can be found at
http://www.python.org/dev/doc/devel/ and should be used when looking up any
documentation on new code; otherwise use the current documentation as found at
http://docs.python.org/ .  PEPs (Python Enhancement Proposals) are located at 
http://www.python.org/peps/ .  To view files in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  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 http://python.org/psf/donations.html .  Every penny helps so even a 
small donation (you can donate through PayPal or by check) helps.

.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. contents::
.. _last summary: http://www.python.org/dev/summary/2004-11-01_2004-11-15.html
.. _original text file: 
http://www.python.org/dev/summary/2004-11-16_2004-11-30.ht

=
Summary Announcements
=
PyCon_ is coming up!  Being held March 23-25 in Washington, DC, registration is 
now open at http://www.python.org/pycon/2005/register.html for credit card 
users (you can pay by check as well; see the general info page for the conference).

.. _PyCon: http://www.python.org/pycon/2005/
=
Summaries
=
-
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 

python-dev Summary for 2004-10-16 through 2004-10-31

[Brett C.]

This is a summary of traffic on the `python-dev mailing list`_ from October 16, 
2004 through October 31, 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 
python-list@python.org 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 fifty-first summary written by Brett Cannon (I *will* be caught up 
on summaries soon).

To contact me, please send email to brett at python.org ; 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 http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText_ which can be 
found at http://docutils.sf.net/rst.html .  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: http://www.python.org/peps/pep-0012.html
The in-development version of the documentation for Python can be found at
http://www.python.org/dev/doc/devel/ and should be used when looking up any
documentation on new code; otherwise use the current documentation as found at
http://docs.python.org/ .  PEPs (Python Enhancement Proposals) are located at 
http://www.python.org/peps/ .  To view files in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  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 http://python.org/psf/donations.html .  Every penny helps so even a 
small donation (you can donate through PayPal or by check) helps.

.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. contents::
.. _last summary: http://www.python.org/dev/summary/2004-10-01_2004-10-15.html
.. _original text file: 
http://www.python.org/dev/summary/2004-10-16_2004-10-31.ht

=
Summary Announcements
=
`Python 2.4`_ final is now out!
As I mentioned in the last summary my school schedule this past quarter has 
been insane.  But now I am on Winter Break and will hopefully be able to catch 
up on my Summary backlog.

.. _Python 2.4: http://www.python.org/2.4/
=
Summaries
=

Specifying main functions and calling packages with '-m'

In my opinion, the new '-m' command line option in Python 2.4 is really handy. 
 But wouldn't it be even handier if you could execute modules in a package? 
That exact question came up.  The reason this kind of thing didn't just go 
directly into 2.4 was that the semantics are not as obvious nor is it as 
simple.  `PEP 338`_ goes over all of this and also points to a recipe that 
implements it all now.

This also brought up the discussion of being able to specify a 'main' function 
to take the place of the good old ``if __name__ == "__main__"`` idiom.  Some 
liked the idea of allowing one to define a function named 'main', others 
'__main__'.  `PEP 299`_ discusses all of this.

.. _PEP 299: http://www.python.org/peps/pep-0299.html
.. _PEP 338: http://www.python.org/peps/pep-0338.html
Contributing threads:
  - `python-dev Summary for 2004-09-16 through 2004-09-30 [draft] 
`__
  - `Magic main functions 
`__
  - `Supporting packages on the command line 
`__


ConfigParser shootout begins

As mentioned in the `last summary`_, a desire for 

python-dev Summary for 2004-11-01 through 2004-11-15

[Brett C.]

python-dev Summary for 2004-11-01 through 2004-11-15

This is a summary of traffic on the `python-dev mailing list`_ from November 
01, 2004 through November 15, 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 
python-list@python.org 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 fifty-second summary written by Brett Cannon (Happy Holidays).
To contact me, please send email to brett at python.org ; 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 http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText_ which can be 
found at http://docutils.sf.net/rst.html .  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: http://www.python.org/peps/pep-0012.html
The in-development version of the documentation for Python can be found at
http://www.python.org/dev/doc/devel/ and should be used when looking up any
documentation on new code; otherwise use the current documentation as found at
http://docs.python.org/ .  PEPs (Python Enhancement Proposals) are located at 
http://www.python.org/peps/ .  To view files in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  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 http://python.org/psf/donations.html .  Every penny helps so even a 
small donation (you can donate through PayPal or by check) helps.

.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. contents::
.. _last summary: http://www.python.org/dev/summary/2004-10-16_2004-10-31.html
.. _original text file: 
http://www.python.org/dev/summary/2004-11-01_2004-11-15.ht

=
Summary Announcements
=
I am hoping to be caught up with my summary backlog by the end of the month. 
Here is to hoping.

=
Summaries
=

2.4 released

`Python 2.4`_ has been released!  Read the `What's New`_ for 2.4 to see what 
the major changes are since 2.3 .

.. _Python 2.4: http://www.python.org/2.4/
.. _What's New: http://www.python.org/doc/2.4/whatsnew/whatsnew24.html
Contributed threads:
  - `TRUNK FROZEN for 2.4b2 release from UTC 3rd November (tomorrrow) 
`__
  - `RELEASED Python 2.4, beta 2 
`__
  - `TRUNK UNFROZEN 
`__

-
Code coverage of the regression tests
-
Walter DÃrwald has a code coverage tool that runs once a month on Python's 
regression test at http://coverage.livinglogic.de/ .  There was some issue with 
the 'trace' module having partially broken in 2.4 .  The coverage was then run 
using ``Lib/test/regrtest.py -T`` to get more accurate numbers.

Contributing threads:
  - `Code coverage tool updated 
`__


Garbage collecting weakref callbacks

Tim Peters discovered that in 2.4 if a weakref's callback is still reachable 
but the referent and weakref itself are unreachable (Tim's example had an 
instance that contained a weakref to itself) that the callback is not called 
during garbage collection.  This se

Ptyon 2.3.5 probably coming in January; get your bugs/patches reported!

[Brett C.]

Anthony Baxter, our ever-diligent release manager, mentioned this past week 
that Python 2.3.5 will most likely come to fruition some time in January (this 
is not guaranteed date).  This means that in order to have enough time to 
proper evaluate new patches and bugs they must be reported **now**!  A one 
month lead time is necessary to properly look at, test, and commit patches, let 
alone coming up with solutions to any reported bugs.

Please realize, though, that reporting a bug or submitting a patch now does not 
guarantee that it will committed in time!  The free time of the development 
team is limited.  If you want to help a bug or patch along to make it easier to 
be evaluated and thus raise its chances of being dealt with please see the 
"Helping Out" section of the 'Intro to Development' essay at 
http://www.python.org/dev/dev_intro.html .

As always, both bugs and patches should be reported to Python's SourceForge 
tracker at http://sourceforge.net/bugs/?group_id=5470 and 
http://sourceforge.net/patch/?group_id=5470, respectively.

-Brett Cannon
--
http://mail.python.org/mailman/listinfo/python-list