B
Brett C
python-dev Summary for 2004-08-16 through 2004-08-31
++++++++++++++++++++++++++++++++++++++++++++++++++++
This is a summary of traffic on the `python-dev mailing list`_ from August 16,
2004 through August 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
(e-mail address removed) 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 forty-seventh summary written by Brett Cannon (new type of
coverage, same kind of sarcasm).
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-08-16_2004-08-31.html
... _original text file: http://www.python.org/dev/summary/2004-08-16_2004-08-31.ht
=====================
Summary Announcements
=====================
After asking people last week about how they wanted me to change the python-dev
Summary as as to allow me to retain my free time, all respondents unanimously
went with the option of letting me choose what I wanted to cover. That made me
happy for a couple of reasons. One is that it makes the summaries more
enjoyable for me since I mostly cover stuff I like and thus should be less
bored at points while writing. It also flattering in a way that people trusted
what I would cover enough to not want to suggest what I should cover. It also
allows me to spend more time on python-dev participating than sitting on the
sidelines dreading have to summarize some 100 email thread on whether we should
move over to VC 7 or something (can you tell I was bored out of my skull by
that thread?).
So this summary starts the new coverage style. As you can see it is much
shorter than normal since I didn't try to be as thorough (7 pages compared to
the usual 10-20). But I think this style allows what I do summarize to have
more details than it would normally have; quality over quantity. I have
reintroduced the "Skipped Threads" section of the Summaries so people can see
what I skipped in case there is something they might want to read that I just
didn't care about. In places where I remember something partially relevant I
added a sentence on it so it isn't just a list of subject lines.
Enjoy.
=========
Summaries
=========
-------------
PEP movements
-------------
`PEP 3000`_ (Python 3.0 Plans) came into creation. This text's point of
existence is to list changes known to be planned for Python 3.0 and not
hypothetical (Guido suggested all hypothetical talk call the version Python
3000, partially for marketing purposes). Plus I am a co-author and it finally
completes my time in the `School of Hard Knocks`_. =)
`PEP 333`_ (Python Web Server Gateway Interface v1.0) proposes a "standard
interface between web servers and Python web applications or frameworks, to
promote web application portability across a variety of web servers".
`PEP 309`_ (Partial Function Application) was updated with some details.
`PEP 334`_ (Simple Coroutines via SuspendIteration) came into existence to
suggest coming up with some form of lightweight coroutines.
... _School of Hard Knocks:
http://mail.python.org/pipermail/python-dev/2002-September/028725.html
... _PEP 3000: http://www.python.org/peps/pep-3000.html
... _PEP 333: http://www.python.org/peps/pep-0333.html
... _PEP 309: http://www.python.org/peps/pep-0309.html
... _PEP 334: http://www.python.org/peps/pep-0334.html
Contributing threads:
- `Minimal 'stackless' PEP using generators?
<http://mail.python.org/pipermail/python-dev/2004-August/048239.html>`__
--------------------------------
Decorators "issue" mostly solved
--------------------------------
While the hubbub over using a character for decorators was brewing, people
began suggesting reserving a character that would never be used in Python for
anything. The thought was that people who wanted to use a character to
represent application-specific information could use the reserved symbol and
not have to worry about clashing with possible future features like Leo and
IPython are with the use of '@'. But no reservation of a character occurred.
Towards the end of the month, to meet the a3 deadline, a unified proposal from
the community came forward led by Robert Brewer and Michael Sparks. They
pushed the J2 proposal::
using:
somedecorator
staticmethod
def func():
pass
Guido contemplated the proposal, saying "it got pretty darn close" to being
accepted, but in the end decided not to. For Guido's full reasoning see
http://mail.python.org/pipermail/python-dev/2004-September/048518.html . But
he said he had two key issues. One was the indentation "suggests that its
contents should be a sequence of statement, but in fact it is not". Issue two
was that using a keyword to start a line was a real attention grabber and that
"using" did not deserve this.
The topic of how the whole decorators situation was handled was touched upon.
He realized that "dramatic changes must be discussed with the community at
large". He was also impressed by how the community pulled together to propose
an alternative as it did and hopes to see more proposals of the same quality in
the future.
So now what? Guido said that he would be willing to change the character used
for decorators for 2.4b1 . That means if '@' drives you nuts but something
else like '!' works for you then speak up and try to get the community to rally
behind it.
Contributing threads:
- `Decorator order implemented backwards?
<http://mail.python.org/pipermail/python-dev/2004-August/047512.html>`__
- `Considering decorator syntax on an individual feature
<http://mail.python.org/pipermail/python-dev/2004-August/048081.html>`__
- `PEP 318: Suggest we drop it
<http://mail.python.org/pipermail/python-dev/2004-August/048025.html>`__
- `__metaclass__ and __author__ are already decorators
<http://mail.python.org/pipermail/python-dev/2004-August/048176.html>`__
- `Reserved Characters
<http://mail.python.org/pipermail/python-dev/2004-August/048166.html>`__
- `PEP 318: Can't we all just get along?
<http://mail.python.org/pipermail/python-dev/2004-August/048213.html>`__
- `Multiple decorators per line
<http://mail.python.org/pipermail/python-dev/2004-August/048227.html>`__
- `Important decorator proposal on c.l.p.
<http://mail.python.org/pipermail/python-dev/2004-August/048332.html>`__
- `Re: [Python-checkins] python/nondist/peps pep-0318.txt...
<http://mail.python.org/pipermail/python-dev/2004-August/048323.html>`__
- `CO_FUTURE_DECORATORS
<http://mail.python.org/pipermail/python-dev/2004-August/048354.html>`__
- `decorators: If you go for it, go all the way!!!
<http://mail.python.org/pipermail/python-dev/2004-August/048378.html>`__
- `Re: Re: def fn (args) [dec,dec]:
<http://mail.python.org/pipermail/python-dev/2004-August/048432.html>`__
- `J2 proposal final
<http://mail.python.org/pipermail/python-dev/2004-August/048428.html>`__
- `(my) revisions to PEP318 finally done.
<http://mail.python.org/pipermail/python-dev/2004-August/048471.html>`__
- `Rejecting the J2 decorators proposal
<http://mail.python.org/pipermail/python-dev/2004-September/048518.html>`__
-----------------------------------------------------------
When should something be put under the great powers of -O ?
-----------------------------------------------------------
Python has had a simple peephole optimizer in the compiler since 2.3 that
optimized imported bytecode. Raymond Hettinger moved it up, though, so that
the optimization would be saved to .pyc files and thus remove the need to
repeat the process every time.
Guido questioned this move. He thought that since it was an optimization it
should fall under the -O command-line option.
But then people came forward to suggest that Raymond's move was good, saying
that the cost of the optimization was non-existent and thus should be used. I
brought up the point that a definition of what should be considered an
optimization; anything that changes the initial opcode, or something that takes
extra time/memory or changes semantics? Tim Peters stepped forward and said
that since the optimizations were so simple that he thought they should be
kept. David Abrahams also came forward and said they should be kept to get
more testing on them since they were not complex and thus did not influence
debugging of code.
In the end Raymond's change was kept in place.
Contributing threads:
- `Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320
<http://mail.python.org/pipermail/python-dev/2004-August/048032.html>`__
----------------------------------------
2.4a3 out the doors so kick those tires!
----------------------------------------
`Python 2.4a3`_ has been released. As usual, please download it, run the
regression tests, and report any errors you get. Since this will be the last
alpha this is your last chance to get new features in before b1 comes out.
The use of priorities on the SourceForge tracker has also been clarified.
Anything set to 9 **must** be dealt with before the next release. Priority 8
is to be dealt with before b1; it changes functionality so if it isn't in by b1
it won't be in until the next version. Priority 7 is for something that should
get in before the final release. Anthony Baxter also gained sole control of
setting the priority so as to keep the settings consistent.
... _Python 2.4a3: http://www.python.org/2.4/
Contributing threads:
- `2.4a3 release is September 2, SF tracker keywords
<http://mail.python.org/pipermail/python-dev/2004-August/048078.html>`__
-------------------
Talking about bytes
-------------------
Stemming from a conversation about moving Python over to Unicode only for
string representation for 3.0, the discussion of a bytes type came up. People
were saying they used str to store binary data and that if str went away or no
longer represented straight binary data (since Unicode has different encodings
the values can change while meaning the same thing in terms of characters) they
would need a way to deal with this.
The idea that the array module solved this was basically dismissed since it
seemed more built-in support was needed for convenience. It also meant more
flexibility in terms of what interfaces were implemented. There was also some
issues with getting array to work the exact way people wanted it to.
The next question was whether literal support was needed. Would you really
need to write something like ``b"\x66\x6f\x6f"`` instead of ``bytes([0x66,
0x6f, 0x6f])``?
How all of this would play with Unicode ended up being discussed. In the end
it seemed that one could encode and decode back and forth but that all work
with character should be in Unicode and only decoded into bytes on the I/O
barrier (writing to disk or the network, for instance) to minimize any possible
encoding errors and to make usage easier.
Mutability came up. Being mutable would be handy, but it killed its usage as a
dictionary key. It was suggested that bytes hash to a tuple of integers
representing the bytes, but nothing more was said. But in general almost
everyone agreed that having the bytes type be mutable was best.
`PEP 332`_ was sketched out during the early part of this discussion, but has
not been updated since it died down.
... _PEP 332: http://www.python.org/peps/pep-0332.html
Contributing threads:
- `adding a bytes sequence type to Python
<http://mail.python.org/pipermail/python-dev/2004-August/047722.html>`__
- `Byte string class hierarchy
<http://mail.python.org/pipermail/python-dev/2004-August/048027.html>`__
--------------------------------------------
String substitution sure is a touchy subject
--------------------------------------------
PEP 292`_ (Simpler String Substitutions) got a huge amount of discussion this
past two weeks. Ignoring the syntax discussions (that was decided long ago
before the PEP was accepted and had consensus and thus was a moot point) and
the discussion of whether a trailing ``$`` at the end of the substitution
pattern should be considered an error or not (it is), a couple of topics were
discussed.
To make this summary easier to follow, realize that the class that implements
PEP 292 is named "Template" and thus I will just refer to the implementation by
that name.
The first topic was over whether Template should return Unicode objects. The
side supporting it pointed out that Python 3.0 was going to be using Unicode
for strings exclusively so it would be good to start using them now. It also
went with the initial design of PEP 292 which was to help with i18n where
Unicode is constantly used.
People against, though, didn't want to suddenly be given a Unicode object when
a string was used for template string passed in. That would be too surprising
and lead to inconsistent usage thanks to sudden mixing of strings and Unicode
objects in code. This issue was resolved by no longer subclassing unicode but
making it easy to subclass Template so as to add direct Unicode support with ease.
The second issue was other the design of the API. Originally Template was a
class that overrode __mod__ to make it work like string interpolation works now
for str and unicode. But then some people felt a class was too heavy-handed if
there was no way to change the way Template worked through a subclass. This
obviously led to a desire for functions to do the work for both Template and
SafeTemplate (similar class to Template that left in substitution points if
they didn't match any values in the dict passed in).
In the end the class design was kept thanks to Tim Peters and metaclasses. Tim
came up with a neat way to have the regex be generated at class creation time
through a metaclass and thus allow subclasses to change how Template matched
substitution points and such, all without a performance hit at instance
creation time. Use of __mod__ and the SafeTemplate class were removed and
Template grew substitute and safe_substitute methods. Practically everyone at
this point seems happy with the design so it has been implemented and checked in.
... _PEP 292: http://www.python.org/peps/pep-0292.html
Contributing threads:
- `Update PEP 292
<http://mail.python.org/pipermail/python-dev/2004-August/048160.html>`__
- `PEP 292 - Simpler String Substitutions
<http://mail.python.org/pipermail/python-dev/2004-August/048236.html>`__
- `Alternative Implementation for PEP 292: Simple String Substitutions
<http://mail.python.org/pipermail/python-dev/2004-August/048406.html>`__
- `Alternative placeholder delimiters for PEP 292
<http://mail.python.org/pipermail/python-dev/2004-August/048469.html>`__
-------------------------------------------
Private names considered rude in the stdlib
-------------------------------------------
Anthony Baxter suggested banning use of mangled private names (names starting
with ``__``) in the stdlib. His argument was that they are a hack and the
stdlib is supposed to act as a good example and that name mangling was not good.
Guido essentially agreed with the caveat that some uses of private names is
justified such as if a private name is storing the equivalent of a 'friend'
function from C++.
Contributing threads:
- `__mangled in stdlib considered poor form
<http://mail.python.org/pipermail/python-dev/2004-August/048444.html>`__
===============
Skipped Threads
===============
Warnocked (i.e., emails that get essentially no response) emails very
insignificant threads are not listed
- Find out whether PyEval_InitThreads has been called?
- Unifying Long Integers and Integers: baseint
- test_tempfile failure on Mac OSX
- Deprecate sys.exitfunc?
- multiple instances of python on XP
- Adding 'lexists()' to os.path
- #ifdeffery
- Weekly Python Bug/Patch Summary
- problem with pymalloc on the BeOS port.
- Proposed change to logging
- sre.py backward compatibility and PEP 291
- Dealing with test__locale failure on OS X before a3
- os.urandom API
- Decoding incomplete unicode
Basically culminated into new stateful UTF-8 and UTF-16 decoders but
that's all I know =)
- Decimal module portability to 2.3?
Decimal is compatible with 2.3 at least until 2.5
- Python icons
If you think you can come up with a good icon for the Windows installer
please let c.l.py know and it might get used
- [Python-checkins] python/dist/src/Lib/test test_string.py, 1.25, 1.26
- list += string??
++++++++++++++++++++++++++++++++++++++++++++++++++++
This is a summary of traffic on the `python-dev mailing list`_ from August 16,
2004 through August 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
(e-mail address removed) 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 forty-seventh summary written by Brett Cannon (new type of
coverage, same kind of sarcasm).
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-08-16_2004-08-31.html
... _original text file: http://www.python.org/dev/summary/2004-08-16_2004-08-31.ht
=====================
Summary Announcements
=====================
After asking people last week about how they wanted me to change the python-dev
Summary as as to allow me to retain my free time, all respondents unanimously
went with the option of letting me choose what I wanted to cover. That made me
happy for a couple of reasons. One is that it makes the summaries more
enjoyable for me since I mostly cover stuff I like and thus should be less
bored at points while writing. It also flattering in a way that people trusted
what I would cover enough to not want to suggest what I should cover. It also
allows me to spend more time on python-dev participating than sitting on the
sidelines dreading have to summarize some 100 email thread on whether we should
move over to VC 7 or something (can you tell I was bored out of my skull by
that thread?).
So this summary starts the new coverage style. As you can see it is much
shorter than normal since I didn't try to be as thorough (7 pages compared to
the usual 10-20). But I think this style allows what I do summarize to have
more details than it would normally have; quality over quantity. I have
reintroduced the "Skipped Threads" section of the Summaries so people can see
what I skipped in case there is something they might want to read that I just
didn't care about. In places where I remember something partially relevant I
added a sentence on it so it isn't just a list of subject lines.
Enjoy.
=========
Summaries
=========
-------------
PEP movements
-------------
`PEP 3000`_ (Python 3.0 Plans) came into creation. This text's point of
existence is to list changes known to be planned for Python 3.0 and not
hypothetical (Guido suggested all hypothetical talk call the version Python
3000, partially for marketing purposes). Plus I am a co-author and it finally
completes my time in the `School of Hard Knocks`_. =)
`PEP 333`_ (Python Web Server Gateway Interface v1.0) proposes a "standard
interface between web servers and Python web applications or frameworks, to
promote web application portability across a variety of web servers".
`PEP 309`_ (Partial Function Application) was updated with some details.
`PEP 334`_ (Simple Coroutines via SuspendIteration) came into existence to
suggest coming up with some form of lightweight coroutines.
... _School of Hard Knocks:
http://mail.python.org/pipermail/python-dev/2002-September/028725.html
... _PEP 3000: http://www.python.org/peps/pep-3000.html
... _PEP 333: http://www.python.org/peps/pep-0333.html
... _PEP 309: http://www.python.org/peps/pep-0309.html
... _PEP 334: http://www.python.org/peps/pep-0334.html
Contributing threads:
- `Minimal 'stackless' PEP using generators?
<http://mail.python.org/pipermail/python-dev/2004-August/048239.html>`__
--------------------------------
Decorators "issue" mostly solved
--------------------------------
While the hubbub over using a character for decorators was brewing, people
began suggesting reserving a character that would never be used in Python for
anything. The thought was that people who wanted to use a character to
represent application-specific information could use the reserved symbol and
not have to worry about clashing with possible future features like Leo and
IPython are with the use of '@'. But no reservation of a character occurred.
Towards the end of the month, to meet the a3 deadline, a unified proposal from
the community came forward led by Robert Brewer and Michael Sparks. They
pushed the J2 proposal::
using:
somedecorator
staticmethod
def func():
pass
Guido contemplated the proposal, saying "it got pretty darn close" to being
accepted, but in the end decided not to. For Guido's full reasoning see
http://mail.python.org/pipermail/python-dev/2004-September/048518.html . But
he said he had two key issues. One was the indentation "suggests that its
contents should be a sequence of statement, but in fact it is not". Issue two
was that using a keyword to start a line was a real attention grabber and that
"using" did not deserve this.
The topic of how the whole decorators situation was handled was touched upon.
He realized that "dramatic changes must be discussed with the community at
large". He was also impressed by how the community pulled together to propose
an alternative as it did and hopes to see more proposals of the same quality in
the future.
So now what? Guido said that he would be willing to change the character used
for decorators for 2.4b1 . That means if '@' drives you nuts but something
else like '!' works for you then speak up and try to get the community to rally
behind it.
Contributing threads:
- `Decorator order implemented backwards?
<http://mail.python.org/pipermail/python-dev/2004-August/047512.html>`__
- `Considering decorator syntax on an individual feature
<http://mail.python.org/pipermail/python-dev/2004-August/048081.html>`__
- `PEP 318: Suggest we drop it
<http://mail.python.org/pipermail/python-dev/2004-August/048025.html>`__
- `__metaclass__ and __author__ are already decorators
<http://mail.python.org/pipermail/python-dev/2004-August/048176.html>`__
- `Reserved Characters
<http://mail.python.org/pipermail/python-dev/2004-August/048166.html>`__
- `PEP 318: Can't we all just get along?
<http://mail.python.org/pipermail/python-dev/2004-August/048213.html>`__
- `Multiple decorators per line
<http://mail.python.org/pipermail/python-dev/2004-August/048227.html>`__
- `Important decorator proposal on c.l.p.
<http://mail.python.org/pipermail/python-dev/2004-August/048332.html>`__
- `Re: [Python-checkins] python/nondist/peps pep-0318.txt...
<http://mail.python.org/pipermail/python-dev/2004-August/048323.html>`__
- `CO_FUTURE_DECORATORS
<http://mail.python.org/pipermail/python-dev/2004-August/048354.html>`__
- `decorators: If you go for it, go all the way!!!
<http://mail.python.org/pipermail/python-dev/2004-August/048378.html>`__
- `Re: Re: def fn (args) [dec,dec]:
<http://mail.python.org/pipermail/python-dev/2004-August/048432.html>`__
- `J2 proposal final
<http://mail.python.org/pipermail/python-dev/2004-August/048428.html>`__
- `(my) revisions to PEP318 finally done.
<http://mail.python.org/pipermail/python-dev/2004-August/048471.html>`__
- `Rejecting the J2 decorators proposal
<http://mail.python.org/pipermail/python-dev/2004-September/048518.html>`__
-----------------------------------------------------------
When should something be put under the great powers of -O ?
-----------------------------------------------------------
Python has had a simple peephole optimizer in the compiler since 2.3 that
optimized imported bytecode. Raymond Hettinger moved it up, though, so that
the optimization would be saved to .pyc files and thus remove the need to
repeat the process every time.
Guido questioned this move. He thought that since it was an optimization it
should fall under the -O command-line option.
But then people came forward to suggest that Raymond's move was good, saying
that the cost of the optimization was non-existent and thus should be used. I
brought up the point that a definition of what should be considered an
optimization; anything that changes the initial opcode, or something that takes
extra time/memory or changes semantics? Tim Peters stepped forward and said
that since the optimizations were so simple that he thought they should be
kept. David Abrahams also came forward and said they should be kept to get
more testing on them since they were not complex and thus did not influence
debugging of code.
In the end Raymond's change was kept in place.
Contributing threads:
- `Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320
<http://mail.python.org/pipermail/python-dev/2004-August/048032.html>`__
----------------------------------------
2.4a3 out the doors so kick those tires!
----------------------------------------
`Python 2.4a3`_ has been released. As usual, please download it, run the
regression tests, and report any errors you get. Since this will be the last
alpha this is your last chance to get new features in before b1 comes out.
The use of priorities on the SourceForge tracker has also been clarified.
Anything set to 9 **must** be dealt with before the next release. Priority 8
is to be dealt with before b1; it changes functionality so if it isn't in by b1
it won't be in until the next version. Priority 7 is for something that should
get in before the final release. Anthony Baxter also gained sole control of
setting the priority so as to keep the settings consistent.
... _Python 2.4a3: http://www.python.org/2.4/
Contributing threads:
- `2.4a3 release is September 2, SF tracker keywords
<http://mail.python.org/pipermail/python-dev/2004-August/048078.html>`__
-------------------
Talking about bytes
-------------------
Stemming from a conversation about moving Python over to Unicode only for
string representation for 3.0, the discussion of a bytes type came up. People
were saying they used str to store binary data and that if str went away or no
longer represented straight binary data (since Unicode has different encodings
the values can change while meaning the same thing in terms of characters) they
would need a way to deal with this.
The idea that the array module solved this was basically dismissed since it
seemed more built-in support was needed for convenience. It also meant more
flexibility in terms of what interfaces were implemented. There was also some
issues with getting array to work the exact way people wanted it to.
The next question was whether literal support was needed. Would you really
need to write something like ``b"\x66\x6f\x6f"`` instead of ``bytes([0x66,
0x6f, 0x6f])``?
How all of this would play with Unicode ended up being discussed. In the end
it seemed that one could encode and decode back and forth but that all work
with character should be in Unicode and only decoded into bytes on the I/O
barrier (writing to disk or the network, for instance) to minimize any possible
encoding errors and to make usage easier.
Mutability came up. Being mutable would be handy, but it killed its usage as a
dictionary key. It was suggested that bytes hash to a tuple of integers
representing the bytes, but nothing more was said. But in general almost
everyone agreed that having the bytes type be mutable was best.
`PEP 332`_ was sketched out during the early part of this discussion, but has
not been updated since it died down.
... _PEP 332: http://www.python.org/peps/pep-0332.html
Contributing threads:
- `adding a bytes sequence type to Python
<http://mail.python.org/pipermail/python-dev/2004-August/047722.html>`__
- `Byte string class hierarchy
<http://mail.python.org/pipermail/python-dev/2004-August/048027.html>`__
--------------------------------------------
String substitution sure is a touchy subject
--------------------------------------------
PEP 292`_ (Simpler String Substitutions) got a huge amount of discussion this
past two weeks. Ignoring the syntax discussions (that was decided long ago
before the PEP was accepted and had consensus and thus was a moot point) and
the discussion of whether a trailing ``$`` at the end of the substitution
pattern should be considered an error or not (it is), a couple of topics were
discussed.
To make this summary easier to follow, realize that the class that implements
PEP 292 is named "Template" and thus I will just refer to the implementation by
that name.
The first topic was over whether Template should return Unicode objects. The
side supporting it pointed out that Python 3.0 was going to be using Unicode
for strings exclusively so it would be good to start using them now. It also
went with the initial design of PEP 292 which was to help with i18n where
Unicode is constantly used.
People against, though, didn't want to suddenly be given a Unicode object when
a string was used for template string passed in. That would be too surprising
and lead to inconsistent usage thanks to sudden mixing of strings and Unicode
objects in code. This issue was resolved by no longer subclassing unicode but
making it easy to subclass Template so as to add direct Unicode support with ease.
The second issue was other the design of the API. Originally Template was a
class that overrode __mod__ to make it work like string interpolation works now
for str and unicode. But then some people felt a class was too heavy-handed if
there was no way to change the way Template worked through a subclass. This
obviously led to a desire for functions to do the work for both Template and
SafeTemplate (similar class to Template that left in substitution points if
they didn't match any values in the dict passed in).
In the end the class design was kept thanks to Tim Peters and metaclasses. Tim
came up with a neat way to have the regex be generated at class creation time
through a metaclass and thus allow subclasses to change how Template matched
substitution points and such, all without a performance hit at instance
creation time. Use of __mod__ and the SafeTemplate class were removed and
Template grew substitute and safe_substitute methods. Practically everyone at
this point seems happy with the design so it has been implemented and checked in.
... _PEP 292: http://www.python.org/peps/pep-0292.html
Contributing threads:
- `Update PEP 292
<http://mail.python.org/pipermail/python-dev/2004-August/048160.html>`__
- `PEP 292 - Simpler String Substitutions
<http://mail.python.org/pipermail/python-dev/2004-August/048236.html>`__
- `Alternative Implementation for PEP 292: Simple String Substitutions
<http://mail.python.org/pipermail/python-dev/2004-August/048406.html>`__
- `Alternative placeholder delimiters for PEP 292
<http://mail.python.org/pipermail/python-dev/2004-August/048469.html>`__
-------------------------------------------
Private names considered rude in the stdlib
-------------------------------------------
Anthony Baxter suggested banning use of mangled private names (names starting
with ``__``) in the stdlib. His argument was that they are a hack and the
stdlib is supposed to act as a good example and that name mangling was not good.
Guido essentially agreed with the caveat that some uses of private names is
justified such as if a private name is storing the equivalent of a 'friend'
function from C++.
Contributing threads:
- `__mangled in stdlib considered poor form
<http://mail.python.org/pipermail/python-dev/2004-August/048444.html>`__
===============
Skipped Threads
===============
Warnocked (i.e., emails that get essentially no response) emails very
insignificant threads are not listed
- Find out whether PyEval_InitThreads has been called?
- Unifying Long Integers and Integers: baseint
- test_tempfile failure on Mac OSX
- Deprecate sys.exitfunc?
- multiple instances of python on XP
- Adding 'lexists()' to os.path
- #ifdeffery
- Weekly Python Bug/Patch Summary
- problem with pymalloc on the BeOS port.
- Proposed change to logging
- sre.py backward compatibility and PEP 291
- Dealing with test__locale failure on OS X before a3
- os.urandom API
- Decoding incomplete unicode
Basically culminated into new stateful UTF-8 and UTF-16 decoders but
that's all I know =)
- Decimal module portability to 2.3?
Decimal is compatible with 2.3 at least until 2.5
- Python icons
If you think you can come up with a good icon for the Windows installer
please let c.l.py know and it might get used
- [Python-checkins] python/dist/src/Lib/test test_string.py, 1.25, 1.26
- list += string??