f



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

python-dev Summary for 2004-08-01 through 2004-08-15
++++++++++++++++++++++++++++++++++++++++++++++++++++
This is a summary of traffic on the `python-dev mailing list`_ from 
August 01, 2004 through August 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 forty-sixth summary written by Brett Cannon (two freakin' years
doing this; I *am* nuts).

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-01_2004-08-15.html
... _original text file: 
http://www.python.org/dev/summary/2004-08-01_2004-08-15.ht



=====================
Summary Announcements
=====================
Well, I have now been doing the summaries for two years.  As has become 
a yearly tradition, I am offering to pass on the writing of the 
summaries to someone else.  My only requirement is you do a comparable 
job.  You do learn *tons* about Python's internals when you have to 
research a topic to be able to summarize it.

With that said, it is also time for stats on the list to scare away 
anyone considering taking over this job  =) .  According to my probably 
buggy script that I wrote last year, I have read 10,190 emails (this 
month has already been the busiest month and it is only half over; could 
set the record for busiest month ever).
The people with over 300 emails posted over the year are:

9. Michael Hudson (303)
8. Martin v. Lowis (307)
7. Barry Warsaw (341)
6. Phillip J. Eby (341) # not a typo; same number as Barry
5. Greg Ewing (354)
4. Raymond Hettinger (372)
3. Skip Montanaro (399)
2. Tim Peters (629)
1. Guido van Rossum (1031)

These 9 people make up over 40% of all the emails from the past year.

Longest threads were:

1. decorate-sort-undecorate (694 emails)
2. Call for defense of @decorators (195 emails)
3. PEP 318: Decorators last before colon (181 emails)
4. redefining is (162 emails)
5. Christmas Wishlist (162 emails)

These stats along with the insane amount of email has showed me 
something; the Summaries have detracted from my participation on 
python-dev this past year.  I have a bigger mouth and more opinions than 
the number of emails I sent to the list show.  This means something has 
to change, and it isn't going to be my mouth.  The Summaries need to 
change in one of two ways.

Option one is that I focus in on certain areas of interest and skip 
other ones.  I have labeled all of the summaries below with what their 
type is right under the titles.  Please email me your top ares of 
interest.  I realize that this month may not be typical but pretty much 
all areas are covered at least once so at least there is a good taste 
for the different areas.  So, choose from:

1. improvement stuff
       Pretty much anything that is not a major change to the 
language/stdlib.  Usually something you find out from the Misc/NEWS or 
the "What's New" doc.
2. how python-dev works
       Stuff like how python-dev handles things such as the PEP process, 
coding style, etc.
3. nuggets of info
       Cool tricks and ideas that come up on the list that the greater 
world probably does not know.
4. minor language change
       Stuff that deals with the language changing, but is not 
significant; such as discussions of existing PEPs.

Language evolution stuff (such as decorators) will always be covered so 
you don't need to vote on that.  If people like this first option then I 
will make sure I cover the area with most votes and everything else is 
just considered icing.

Option two out of all of this is people just say, "summarize what you 
want, Brett."  Then I just cover what I find interesting and just don't 
worry about covering a specific area.  I obviously prefer this option 
but if people really care about a specific area I want to make sure to 
cover it.  What will most likely happen is I will still cover almost 
everything but the thoroughness will be lower.  I will go more off of 
memory for example.

But something will change.  Being on the sidelines for the decorators 
discussion because I dreaded having to start reading all of those emails 
in terms of summarizing is not acceptable (and no, I can't just ignore 
some of them since that is just not how I work).  Having to read 1,289 
emails for just the first two weeks of this month finally caused me to 
lose my sanity.

Another question becomes whether people miss the "Skipped Threads" 
feature of the Summaries.  If you do let me know and I can go back to 
doing that by just listing the threads that I don't cover (but with no 
one-liners probably, but it is possible, or linking to the archives; you 
would just get the subject line in a long list of threads I didn't 
bother covering).  If that would be *really* helpful then let me know 
about that as well.

========
Summary
========
--------------------------------------------------------------------------------
Multiple interpreters at a time in a C program kind of broken
--------------------------------------------------------------------------------
3. nuggets of info

Philip Eby thought he might have a fix for a known limitation of running 
multiple interpeters at once (using PyInterpreter_New() ) and having 
imports not being clearly separated between interpreters.  But Martin v. 
Löwis popped Philip's bubble somewhat by saying that he and some other 
people viewed multiple interpreter support as inherently broken.

Contributing threads:
   - `Safe to change a thread's interpreter? 
<http://mail.python.org/pipermail/python-dev/2004-August/046593.html>`__


--------------------------------------------
Another sucker becomes an official developer
--------------------------------------------
2. how python-dev works

Sean Reifschneider took the bait to become another one of Guido's minions.

Sean has been maintaining the RPM spec files for quite a while.

Contributing threads:
   - `New developer 
<http://mail.python.org/pipermail/python-dev/2004-August/046595.html>`__


----------------------------------------
Discovering leaks with a regrtest wrench
----------------------------------------
1. minor language change

Michael Hudson, who found and fixed a bunch of refcount leaks shortly 
after 2.3 was released, used his magical regrtest patch (which has 
subsequently been checked in) to hunt down leaks for 2.4 .  A bunch of 
tests were cleaned up to make them not raise false-positives along with 
fixing some true leaks.

Contributing threads:
   - `refleak hunting season 
<http://mail.python.org/pipermail/python-dev/2004-August/046611.html>`__


---------------------------------
Another Bug Day has come and gone
---------------------------------
2. how python-dev works

The Bug Day held on August 7 led to 19 bugs and 12 patches being closed. 
  You can see the results at 
http://www.python.org/cgi-bin/moinmoin/PythonBugDayStatus .

Feel guilty for not being able to make it?  Still want to help?  Go to 
that page to see bugs that could use some squashing that shouldn't be 
too difficult to deal with.

Contributing threads:
   - `Bug day coming up this Saturday 
<http://mail.python.org/pipermail/python-dev/2004-August/046645.html>`__


--------------------------------------------------
How to shut a compiler up about an unused variable
--------------------------------------------------
3. nuggets of info

Tim Peters had come up with some optimizations for list.pop() that 
avoided unneeded test+branches.  The problem is that it led to a 
variable possibly being unused.  C compilers tend to complain about that 
and so an initial solution was used.  Unfortunately gcc complained about 
it, and so yours truly came up with one.  But that solution was labeled 
as "perverse" (and it was; total hack solution), so another solution was 
found thanks to Sjoerd Mullender by just taking the variable and casting 
it to void.

Contributing threads:
   - `RE: [Python-checkins] python/dist/src/Objects listobject.c, ... 
<http://mail.python.org/pipermail/python-dev/2004-August/046678.html>`__


------------------------------------------------------
Variable sequence unpacking assignment shot down again
------------------------------------------------------
language evolution

David Cole suggested adding the ability to have sequence unpacking 
assignment
just like \*args for parameters; ``a, b, *c = (0, 1, 2, 3, 4, 5)  # a == 
0, b == 2, c == (3, 4, 5)``.  This idea got a -1 from Guido as not 
really needed.  That reaction makes Guido consistent; the idea was 
originally shot down back in Nov. 2002; 
http://www.python.org/dev/summary/2002-11-16_2002-11-30.html#half-baked-proposal-and-in-assignments 
..  If you really like that idea the previous summary contains a function 
that helps you do this in a way.

Contributing threads:
   - `Tuple/list assignment question 
<http://mail.python.org/pipermail/python-dev/2004-August/046684.html>`__


-------------------------------------------------------------------------------------
Changing the Big-O complexity for something in the language is now a 
language feature
-------------------------------------------------------------------------------------
language evolution

Armin Rigo came up with a way to have string concatenation in a loop 
(think ``for thing in iter_of_strings: concat_str += thing``) not be a 
quadratic algorithm thanks to some trickery for ``a = a + b`` and ``a += 
b`` conditions for strings.  The hope was to remove the (commonly 
considered) wart of having ``"".join(iter_of_strings)`` be the suggested 
way to concatenate a bunch of strings.

But Guido didn't like the patch.  His reasoning was that changing 
something that led to a change in the Big-O complexity of certain 
algorithms would inherently hurt other implementations of Python when 
people would start to code specifically for that performance gain.  For 
instance, having Jython be able to pull this trick off is, I believe, 
near impossible.  So, in order to make sure changes like this are 
considered before applying them, Guido instated a new rule that 
"implementation features that affect not just the running speed but the 
O() rate for certain algorithms should be considered language features, 
because any implementation will be required to implement them in order 
to ensure code portability" between implementations of Python.

In the end, though, this went in with a warning that the speed 
performance is not portable.  It is not to be used in the stdlib ever.

Contributing threads:
   - `Optimized string concatenation 
<http://mail.python.org/pipermail/python-dev/2004-August/046686.html>`__
   - `PEP 0008 confusion - here it is, but don't use it? 
<http://mail.python.org/pipermail/python-dev/2004-August/047194.html>`__


-------------------------------------------------------------------------------
Bet you didn't think about string interning and how that affects .pyc, 
did you?
-------------------------------------------------------------------------------
1. minor language change

Luckily Martin v. Löwis did.  A patch was originally applied to not 
intern strings representing filenames.  Problem is that every code 
object stores that string, so it increases .pyc files since it has to 
store multiple copies of that string instead of just one.

Contributing threads:
   - `Re: [Python-checkins] python/dist/src/Python compile.c ... 
<http://mail.python.org/pipermail/python-dev/2004-August/046703.html>`__


------------------------------------------------------------------------------
`PEP 324`_ (process - New POSIX process module) != process.py from 
ActiveState
------------------------------------------------------------------------------
1. minor language change

Guido asked if the APIs between the module proposed in `PEP 324`_ and 
the process.py module by Trent Mick of ActiveState were compatible. 
Turns out they are not.  Then the discussion went into select(), broken 
pipes, and other stuff not relevant to the OP.  =)

... _PEP 324: http://www.python.org/peps/pep-0324.html

Contributing threads:
   - `PEP 324 (process module) 
<http://mail.python.org/pipermail/python-dev/2004-August/046707.html>`__


--------------------------------------------------------------------------------------------------------------------------------------------------
Getting it so string literals accept those nutty non-ASCII characters 
more easily (and getting files to be more upfront about their Unicode-ness)
--------------------------------------------------------------------------------------------------------------------------------------------------
language evolution

François Pinard asked what people thought about two things related to 
Unicode.  First, he thought having a __coding__ attribute for files that 
contained the encoding of the text would be nice.  Martin v. Löwis said 
it would be possible.  MA Lemburg added his vote of support.  It has not 
been implemented to my knowledge yet, though.

The second idea was to have a directive of some sort on a per-module 
basis so that all string literals could be considered in something other 
than ASCII.  Once again Martin said it was doable with MA saying he 
liked the idea.  But it was pointed out that you might as well just use 
the 'u' in front of strings now.

This led to a slight discussion on good i18n practices.  Both Martin and 
MA seemed to suggest that if you are going to be doing most of your work 
in a single encoding then just use that and declare everything Unicode. 
  ANd if you are going to support a lot of different languages, use 
gettext and such.  Martin also stated it is best to get text into 
Unicode ASAP and then only convert to the final encoding at the last moment.

Contributing threads:
   - `Python in Unicode context 
<http://mail.python.org/pipermail/python-dev/2004-August/046727.html>`__


----------------------------------------------------------------------
An exception is an exception, unless it doesn't inherit from Exception
----------------------------------------------------------------------
language evolution

Coming up in a discussion on Unicode of all things, a discussion on 
moving exceptions over to new-style classes came up.  Guido pointed out 
that moving over to new-style classes would seem to suddenly require 
that anything passed to 'raise' be a new-style class and that goes 
against the current acceptance.

But in comes Paul Prescod with his argument that exceptions are 
inherently organized based on inheritance and thus requiring things 
being passed to 'raise' subclass Exception somewhere is not that big of 
a thing.  Guido really liked that point.  So if it goes this way and you 
don't like it blame Paul (who is a nice guy, so go easy on him  =).

And then along come Holger Krekel bringing up the point that using 
exceptions to do non-standard flow control is handy.  But the question 
was asked as to why he couldn't still just subclass Exception?  Was it 
that big of a deal?  He admitted it wasn't and said when the name 
Raisable was suggested that would make it easier.

Michael Hudson then came in and wrote up a hacked-up patch to turn 
exceptions into new-style classes.  Most stuff seemed to still work.

Python 3 was already going to switch to new-style classes for exceptions 
and string exceptions have already been deprecated.  Now add to the mix 
the possible requirement that anything passed to 'raise' require a 
common base class.

Contributing threads (note that the thread starts part way in a thread 
on Unicode and end before the end of the full thread):
   - `Python in Unicode context 
<http://mail.python.org/pipermail/python-dev/2004-August/046757.html>`__


-------------------------
Python 2.4a2 out the door
-------------------------
language evolution

Python 2.4a2 has been released.  As usual, please download it and test 
it with your code along with the regression test suite.

Contributing threads:
   - `trunk frozen for 2.4a2 
<http://mail.python.org/pipermail/python-dev/2004-August/046822.html>`__
   - `RELEASED Python 2.4, alpha 2 
<http://mail.python.org/pipermail/python-dev/2004-August/046864.html>`__


-------------------------------------------------------
Amendment to how to compile with the free .NET compiler
-------------------------------------------------------
3. nuggets of info

Nick Coghlan expanded upon my summary on how to compile with the free 
..NET compiler under Windows at 
http://www.python.org/dev/summary/2004-07-16_2004-07-31.html#how-to-get-python-to-compile-with-microsoft-s-free-compiler-that-should-just-come-with-the-os-standard 
..  See his email at 
http://mail.python.org/pipermail/python-dev/2004-August/047215.html on 
the extra steps.

Or just move to another OS.

Contributing threads:
   - `python-dev Summary for 2004-07-16 through 2004-07-31 [draft] 
<http://mail.python.org/pipermail/python-dev/2004-August/047215.html>`__


--------------------------------------
Darned Solaris, g++, and _XOPEN_SOURCE
--------------------------------------
1. improvement stuff

Skip Montanaro discovered that building under Solaris with g++ raised a 
warning about redefining _XOPEN_SOURCE.  pyconfig.h defines it, but 
apparently so does g++ in order for Solaris' toolchain to expose some 
code that is only available if it is defined.  Martin v. Löwis came up 
with a couple of suggestions on how to handle this.  Skip ended up going 
with the idea of setting _XOPEN_SOURCE to the same value as it is 
defined by g++.

Contributing threads:
   - `use of #pragma GCC system_header to suppress _XOPEN_SOURCE 
warnings 
<http://mail.python.org/pipermail/python-dev/2004-August/046955.html>`__


-------------------------------------------------------------------------------------
pre-PEP on a function for re that "captures matches for groups that 
match repeatedly"
-------------------------------------------------------------------------------------
1. minor language change

Mike Coleman presented a pre-PEP (newest version at 
http://mail.python.org/pipermail/python-dev/2004-August/047238.html ) on 
adding a function to re that would create a tree (in the form of a list) 
containing all group matches in a string.  It got a little support, but 
the discussion quickly moved over to dreamings of a full-on scanner or 
parser package for the stdlib.

But if the idea of the PEP works for you then speak up on c.l.py .

Contributing threads:
   - `pre-PEP: Complete, Structured Regular Expression Group Matching 
<http://mail.python.org/pipermail/python-dev/2004-August/047042.html>`__


---------------------------------------
Making ourselves follow the PEP process
---------------------------------------
2. how python-dev works

It was noticed early on that the PEP process had broken down for `PEP 
318`_ (decorators).  What should happen is a PEP gets written (and the 
author becomes its champion), there is a public discussion, the PEP is 
updated, that's repeated until it is deemed done, gets get BDFL 
pronouncement, if Guido okays it the code goes in.  Unfortunately the 
part about  updating the PEP didn't really happen.

This led to two major things being stated and generally agreed upon. 
One is that PEPs should not be checked in if the PEP has not been 
updated.  While a minor nit is not a reason to hold back code, not 
updating after a major public debate is not acceptable.

This directly segued into the other point of a PEP needs to have a 
champion, period.  Since the developers on python-dev do not have the 
time to keep PEPs updated it is up to the PEP champion to make sure it 
is kept current.  If it isn't it is take to mean the champion no longer 
cares, which means python-dev no longer cares, which means the PEP gets 
rejected outright.  This will also make sure that there is a focus to 
the design of what the PEP wants and does not lead to a 
design-by-committee problem.

... _PEP 318: http://www.python.org/peps/pep-0318.html

Contributing threads:
   - `PEP 318, and the PEP process 
<http://mail.python.org/pipermail/python-dev/2004-August/047020.html>`__


----------------------------------------------------------------
How to tell Windows from Linux without lifting up anyone's skirt
----------------------------------------------------------------
3. nuggets of info

The question came up on what the best way was to tell what platform you 
are running on.  The answer came down to why you were cared.  If it was 
whether or not you had a specific functionality (or lack thereof), then 
just test for the functionality.  If you had other needs, though, using 
sys.platform seemed to be the most reliable way (at least for Windows 
since all of them use 'win32').

Contributing threads:
   - `Asyncore .set_reuse_addr() on Windows 
<http://mail.python.org/pipermail/python-dev/2004-August/047269.html>`__


-----------------------------------------
func_name can now have an identity crisis
-----------------------------------------
1. improvement stuff

Thanks to the rampant decorator discussion, Skip Montanaro came up with 
the idea of wanting func_name to be writable.  This would allow 
decorators to wrap a function with another function and yet reset 
func_name to its original value, thus not having the wrapper function 
become the prevailing name.

Guido liked and Michael Hudson subsequently wrote up `patch #1004703`_.

... _patch #1004703: http://www.python.org/sf/1004703

Contributing threads:
   - `PEP 318 - writing to func_name attribute 
<http://mail.python.org/pipermail/python-dev/2004-August/047097.html>`__


-----------------------------------------
statistics.py ain't goin' into the stdlib
-----------------------------------------
1. improvement stuff

Raymond Hettinger (at the last Python Bug Day) made the statement that 
he didn't think 'statistic's should be taken out of the sandbox in CVS 
and put into the stdlib.  He felt that most of the important algorithms 
were available elsewhere (such as nsmallest and nlargest in the heapq 
module) and the remaining functions that were not found anywhere were 
not that critical.

He did say, though, he would like to do a calculator module where those 
remaining functions could go.

Contributing threads:
   - `status of statistics.py? 
<http://mail.python.org/pipermail/python-dev/2004-August/047129.html>`__


------------------------------------
Making re.split care about emptiness
------------------------------------
1. improvement stuff

Mike Coleman wrote up a patch for re.split() that AM Kuchling presented 
to the list.  It adds an argument to the function to allow an empty 
string to be put into the resulting list when a match occurs, even if 
the match consumes no characters.  This allows delimiters used in the 
regex to still appear in the groups.

No decision on the exact semantics of the function, how to handle 
turning on the new functionality (some say an extra argument, some say 
adding another bit flag like traditional re arguments), or even if it 
will be accepted.

Contributing threads:
   - `re.split on empty patterns 
<http://mail.python.org/pipermail/python-dev/2004-August/047272.html>`__


----------------------------------------
Pickler's 'bin' argument on its last leg
----------------------------------------
1. improvement stuff

As per `PEP 307`_ (Extensions to the pickle protocol), the 'bin' 
argument is being upgraded from PendingDeprecationWarning to 
DeprecationWarning; so it's gone plaid and the only way to stop it is 
with some emergency change.

... _PEP 307: http://www.python.org./peps/pep-0307.html

Contributing threads:
   - `Pickler()'s bin argument 
<http://mail.python.org/pipermail/python-dev/2004-August/047274.html>`__


---------------------------------
Some modules are getting the boot
---------------------------------
1. improvement stuff

TERMIOS, mpz, statcache, xreadlines and rotor are all being removed. 
mimify, MimeWriter, and whrandom will raise a DeprecationWarning. 
rfc822 and mimetools will not be raising DeprecationWarning as specified 
by `PEP 4`_ since some code in the stdlib still uses it.

... _PEP 4: http://www.python.org/peps/pep-0004.html

Contributing threads:
   - `Removing stuff from 2.4 
<http://mail.python.org/pipermail/python-dev/2004-August/047308.html>`__


-------------------------------------------------
Should decimal.Context.copy() be deep or shallow?
-------------------------------------------------
1. improvement stuff

Raymond Hettinger brought up the question of whether 
decimal.Context.copy() should be a deep or shallow copy.  While 
tradition dictates it be shallow based on name, it seems like the 
functionality should be deep.  No one wants context to be shared between 
number naturally since numbers tend to be viewed as unique things.

Staring in 2.4a3 it will be deep unless people come up with reasons to 
switch it to shallow.

Contributing threads:
   - `decimal.Context.copy() shallow or deep? 
<http://mail.python.org/pipermail/python-dev/2004-August/047416.html>`__


----------------------------------------------------------
The dark corners of Python allow you to skip return values
----------------------------------------------------------
3. nuggets of info

Christian Tismer discovered that you can actually stop a return 
statement from returning if you encase it in a 'finally' block and tweak 
it slightly (see the OP to get what I mean by this).  Turns out this is 
a reliable feature of Python if you really want to use it.

Contributing threads:
   - `capturing RETURN_VALUE 
<http://mail.python.org/pipermail/python-dev/2004-August/047360.html>`__


--------------------------------------
Is an int/long combined type worth it?
--------------------------------------
language evolution

Dmitry Vasiliev pointed out that `PEP 237`_ (Unifying Long Integers and 
Integers) mentioned that a a new type named 'integer' might be 
introduced that subclassed both int and long.  The discussion waivered 
between whether it was at all needed, and if it was if it should be a 
true type or just a tuple containing both types for use with isinstance() .

No conclusion was reached in the end.

... _PEP 237: http://www.python.org/peps/pep-0237.html

Contributing threads:
   - `Unifying Long Integers and Integers: baseint 
<http://mail.python.org/pipermail/python-dev/2004-August/047404.html>`__


--------------------------------------
Should byte arrays be a built-in type?
--------------------------------------
language evolution

Through the discussion bout having a common type combining int and long 
a discussion on whether a byte array type should be introduced.  The 
initial suggestion was for it to be practically synonymous with str 
since str itself stores everything as an array of 8-bit values.  The use 
cases would be for streams and such that just want a stream of bytes 
with no care for any encoding.

Syntactically, having a 'b' and 'B' cookie before literals was 
suggested.  The issue with this, though, is that byte arrays should be 
mutable, which would make literals that can be mutated, and that is 
frowned upon by Guido.

Semantically, aliasing bytes to the str type was suggested.  That was 
not loved since that could create confusion.  Returning an object from 
'array' was suggested and seemed okay.

In general it seemed this could be useful and could go in 2.5, but 
nothing for 2.4 .

Contributing threads:
   - `Unifying Long Integers and Integers: baseint 
<http://mail.python.org/pipermail/python-dev/2004-August/047665.html>`__


-----------------------------
Thar the Windows stack blows!
-----------------------------
1. minor language change

Running the new test_compiler test (if you run it with ``-uall`` for 
regrtest it will recompile the entire stdlib) was leading to an odd 
failure: the "process on Windows "just vanishes" without a trace, and 
without an error message of any kind, but with an exit code of 128". 
After a lot of work put in by a bunch of people (led by Tim Peters) the 
problem was tracked down to a blown C stack.

Turned out that the stack-checking code was not being called frequently 
enough to pick up the error.  The problem with this was that it was 
leading to odd errors that should have been MemoryError but were 
manifesting themselves as KeyError.  This was because PyDict_GetItem() 
was failing and return NULL which is the same as signaling the key 
doesn't exist in the dict.

Trick was trying to come up with a good way to deal with this.  Adding 
more calls would be very expensive (reliable way of catching it was 
sticking a check in pymalloc code) and so that was ruled out. 
PyDict_GetItem() couldn't change its return value since that would break 
more code than could be imagined.  So, in the end, the stack was 
increased to 2 MB on Windows.

Contributing threads:
   - `Another test_compiler mystery 
<http://mail.python.org/pipermail/python-dev/2004-August/047468.html>`__


------------------------------------------
Someone else falls for the dangling carrot
------------------------------------------
2. how python-dev works

Johannes Gijsbers now has checkin rights.  May he close many bugs.

Contributing threads:
   - `New Developer 
<http://mail.python.org/pipermail/python-dev/2004-August/047815.html>`__


----------------------------------------------------------
Lying about being in __builtin__ is not always a bad thing
----------------------------------------------------------
1. improvement stuff

James Knight noticed that some objects (mostly C types such as iterators 
for the built-in types and such) claim in their __module__ attribute 
that they come from __builtin__ which is not technically correct since 
you can't access them from there.  The desire to fix this came from 
allowing for proper introspection.  The leading idea is to put these 
types in __builtin__ properly so that they are no longer lying about 
where they come from.

Contributing threads:
   - `Classes that claim to be defined in __builtin__ but aren't 
<http://mail.python.org/pipermail/python-dev/2004-August/047477.html>`__


---------------------------------------------------------
Bringing order to the order of application for decorators
---------------------------------------------------------
1. minor language change

Turns out that the order of application for decorators was implemented 
in the reverse order of what it was supposed to be in 2.4a2 .  Luckily 
James Knight spotted this and let the list know.  It has been fixed, 
though, in CVS and now follows `PEP 318`_ to apply in bottom-up order::

   @first
   @second
   def blah(): pass

is equivalent to::

   blah = first(second(blah))

The arguments for this ordering beyond it just making more sense to 
Guido and others is that people will typically put decorators such as 
staticmethod and classmethod first.  Going with the original order would 
have led to errors in most situations if people were not expecting to be 
receiving a class or static method to be passed to the other decorators.

There was a short discussion on the order of instantiation for the 
decorators, but in the end the order chosen was the order listed; first 
would be first() instantiated followed by second().

Contributing threads:
   - `Decorator order implemented backwards? 
<http://mail.python.org/pipermail/python-dev/2004-August/047512.html>`__


-----------------------------------------------------------------------------------
PEP 292 (Simpler String Substitutions) getting gussied up for the Python 
2.4a3 ball
-----------------------------------------------------------------------------------
1. minor language change

`PEP 292`_'s implementation got fixed up.  The names of the class names 
were changed to Template and SafeTemplate, the whole process was made 
lazy, and just cleaned up in general (solution is small, simple, and 
rather cool; all subclassable and works with Unicode to boot).

But then questions over the merits of $-based string interpolation 
popped up.  People wondered if going from ``%(blah)s`` to ``${blah}`` 
was worth it.  The answer is "yes".  And that is just worst case; when 
you just want ``$blah`` you get an even bigger win.

The other question was over whether the string module should become a 
package.  The original idea was to stick the original string module in 
as a submodule of the package and the Template code in another module. 
This would allow easy removal of the 'string' module code that has been 
deprecated for eons.  Barry Warsaw (author of the PEP) asked Guido to 
make the call on this, but he hasn't had the time yet to get to this.

... _PEP 292: http://www.python.org./peps/pep-0292.html

Contributing threads:
   - `PEP 292 
<http://mail.python.org/pipermail/python-dev/2004-August/047580.html>`__


--------------------------------
Multi-line imports get clarified
--------------------------------
1. minor language change

Multi-line imports will only accept parentheses around what is being 
explicitly imported and only if there is more than one item being 
imported.  Trailing commas are also to be accepted.

Contributing threads:
   - `Multi-line import implementation (first part) 
<http://mail.python.org/pipermail/python-dev/2004-August/047393.html>`__
   - `Multi-line import implementation (second part) 
<http://mail.python.org/pipermail/python-dev/2004-August/047614.html>`__
   - `Naming nit 
<http://mail.python.org/pipermail/python-dev/2004-August/047641.html>`__


------------------------------------------------
For those of you who need Python to run on Win64
------------------------------------------------
3. nuggets of info

Nick Bastin asked if anyone has gotten Python 2.3 to work under Win64. 
Martin v. Löwis said "yes" for Python 2.4, but not for 2.3 .  He 
suggested to Nick that he run vsextcomp_ to generate the targets on the 
2.4 VC 7 build files and then move that over to 2.3 .

... _vsextcomp: http://www.sf.net/projects/vsextcomp

Contributing threads:
   - `2.3.4 on Win64? 
<http://mail.python.org/pipermail/python-dev/2004-August/047631.html>`__


----------------------------------------------
Sometimes concealing the truth is a good thing
----------------------------------------------
1. improvement stuff

Nick Coghlan discovered that some of the function in the 'commands' 
module did actually work under Windows and he wanted to make sure it was 
okay to fix another module to work under Windows and to document the 
fact.  But the whole idea was shot down by both Tim Peters and Guido in 
order to keep the module simple.  Keeping the whole thing UNIX-only is 
much easier than having an API that is only partly compatible with 
Windows (and with only certain versions of Windows at that).  Guido also 
said that the module would not even be accepted today since it doesn't 
add enough functionality.

Contributing threads:
   - `'commands' module on Win32 
<http://mail.python.org/pipermail/python-dev/2004-August/047774.html>`__


----------------------------------------------
atexit module, good; sys.exitfunc, not so good
----------------------------------------------
1. improvement stuff

Raymond Hettinger pointed out that the docs for the atexit module state 
that sys.exitfunc was to be deprecated.  Well, atexit has been in the 
stdlib since 2.0 so the deprecation is long overdue.  Looks like it will 
get its deprecation finally.

Contributing threads:
   - `Deprecate sys.exitfunc? 
<http://mail.python.org/pipermail/python-dev/2004-August/047842.html>`__


----------------------------------------------------------------------------------------------
My Personal Hell: decorators and the people who suggest new syntax for 
them...  next, on Oprah
----------------------------------------------------------------------------------------------
language evolution

What led to a record-setting flurry of emails to python-dev was set up 
when Guido gave the green light to checking in code to implement 
decorators using the '@' syntax (now known at the pie syntax thanks to 
its checkin coming very shortly after the OSCON Pie-thon competition and 
'@' sort of looking like a pie).  People didn't like it.  People were 
screaming that there had to be a better syntax than just settling for 
the least offensive one.  Others started to question whether decorators 
were really needed.  Others wanted to extend them even more and what 
their role truly was.  Either way this was all coming a little late.

But then Guido decided to make my life difficult by saying that if the 
community could come up with an agreed-upon alternative syntax to 
propose to him he would consider ripping out the '@' syntax; decorators 
have always been experimental and '@' was checked in so people had 
*something* to play with.  This meant everyone and their mother started 
to propose both new and old syntaxes for decorators.  This led to a 
record amount of email on python-dev (at least compared to what we have 
archives for; back to April 1999).

In order of my own personal sanity I am not going to cover any specific 
syntax.  There are just too many and I actually like the '@' syntax 
(just *try* using it; it grows on you quickly).  Instead this summary 
will cover any important design considerations for decorators (it should 
all be in the PEP but so much happened there is no way it all got in 
there) along with any other important considerations about them.  I will 
discuss anything specific to the '@' syntax since it is the currently 
winning syntax.

With that said, `PEP 318`_ and the PythonDecorators_ wiki page are the 
de-facto place for info on this whole situation.  I am probably going to 
be more biased than normal in this summary just out of time restraints 
to get this done by not over-analyzing people's suggestions and just 
assuming what I summarize here is not covered elsewhere; checking if it 
is would take too long.

First off, going with a syntax just so you could add backward-compatible 
support was not considered worth it.  It's a new feature so there is no 
need to hobble it at the get-go just so people who don't want to upgrade 
can still use it.  Plus the implementations to make this even possible 
were playing some tricks with the interpreter and not considered a good 
thing.  Besides you can, always will be able to, still use the way to do 
it in 2.2 and beyond.

Another design point that needed to be taken into consideration was 
ambiguity.  There could not be a question about what is a decorator and 
what isn't (list-before-def is an example of a syntax that can be 
ambiguous).

Syntactic support that allowed for possible future compiler 
optimizations was also considered important.  The on-going hope is to 
eventually get a JIT compiler for Python and if the decorators are not 
placed before the def somehow you make it much harder to optimize since 
you learn about the decorators after the fact of the function starting 
to be defined.

An argument against '@' was that people thought it got rather unwieldy 
quickly (and I am sure the new decision that each decorator must be on 
its own line is not making these objectors happy).  But one thing that 
must be remembered is that chances are most functions will not need more 
than one decorator if the even need one.  Looking through the stdlib 
sans the test suite you will notice there are not a lot of uses for any 
of the built-in decorators.  Yes, usage will probably grow with 
syntactic support for decorators, but not exponentially in terms of 
applying multiple decorators to a single function.

Allowing decorators to take arguments is a requirement.  Not being able 
to pass arguments to a decorator at instantiation time would severely 
cripple their usefulness.

Being prefix instead of postfix was considered important.  Knowing about 
what is coming up was something Guido thought is better than finding out 
about some special tweak to the use of a function based on a decorator 
listed after the definition line.  And in the method body had been 
completely ruled out.

In terms of implementation details, decorators can only be functions 
directly (and not lambda).  This means no ``@a or b`` tricks and such. 
It also means ``@foo().bar()`` is not allowed.  This is all gut feeling 
from Guido for why the restriction should be there.  It could change in 
the future since it is easier to loosen restrictions that make something 
more strict.

A problem with '@' in terms of portability is that Leo_ and IPython_ 
both use '@' for special syntax.  The authors of both tools seem willing 
to change their tools (not necessarily overly joyous, though  =) .

Guido wanted a syntax "that ... [is] easy to remember once explained". 
It did not need to be miraculously obvious what it did just by looking 
at the first time.

Some people didn't like '@' because they keep wanting to say "at" when 
they saw it.  To that, I give you Tim Peters' fix for this: "Pick the 
keyword you'd like.  Then whenever you see "@", pronounce
that word instead <wink>".

A single decorator that applied to multiple code blocks is completely 
out.  Guido gave a couple of reasons why, but one that he had mentioned 
multiple times is indenting the code block again just for the decorator 
is out.

Some people suggested that things be kept simple by just throwing out 
the entire idea of syntactic support.  Could happen if everyone agreed 
to that, but I wouldn't count on it.

A supposed knock against '@' was that it wasn't Pythonic.  Well, it is 
Pythonic if Guido says it is so not really a valid argument.


OK, tirade time.  If you don't want to listen to me get up on my 
soapbox, then just skip the rest of this...

"In the old days, Guido would Pronounce, and we'd all bite our tongues 
(although not necessarily each his own).  The less time Guido can make 
for Python, the more important becomes graceful capitulation."  Tim said 
this and it makes me wish for the old days.  People had *months* to 
comment on decorators and no one spoke up until something went into the 
language.  Procrastination is not a virtue when it comes to major 
language evolution discussions.  What was worse was when the emails 
started repeating themselves (which was pretty much from the get-go when 
this exploded).  Seemed like people decided to start talking without 
doing some research.  Granted the PEP was outdated and the wiki page was 
not up yet, but this stuff was covered in the Summaries before and you 
could have just Googled for the previous threads.

Personally, if I was Guido, I would have said that the community had 
their chance to speak up and they just didn't take it.  But Guido is a 
nicer guy than that so people are getting a second chance with this. 
Personally this came off a great case of the tyranny of the majority in 
my eyes.  There is a reason why Python is a dictatorship.

At this point people should be hashing out which syntax alternative they 
want to present to Guido on comp.lang.python_.  No more talking on 
python-dev, no more syntax proposals.  The community should set a goal 
date (Sept. 1 seems good) and just choose a bloody alternative.  Then 
when Guido makes his choice people accept it or just go to another 
language.  No one had better voice their disappoint once Guido chooses 
his syntax or I will personally come beat you over with a stick for 
being a whiner.

OK, that's out of my system.  I feel better now.

... _PythonDecorators: 
http://www.python.org/cgi-bin/moinmoin/PythonDecorators
... _Leo: http://leo.sourceforge.net/
... _IPython: http://ipython.scipy.org/

Contributing threads (sans emails that were warnocked):
   - `2.4a2, and @decorators 
<http://mail.python.org/pipermail/python-dev/2004-August/046599.html>`__
   - `Plea for simpler decorator syntax,	in addition to pie-shaped 
syntax 
<http://mail.python.org/pipermail/python-dev/2004-August/046798.html>`__
   - `Call for defense of @decorators 
<http://mail.python.org/pipermail/python-dev/2004-August/046878.html>`__
   - `@decorators, the PEP and the "options" out there? 
<http://mail.python.org/pipermail/python-dev/2004-August/046905.html>`__
   - `About pep 318--Intro 
<http://mail.python.org/pipermail/python-dev/2004-August/046918.html>`__
   - `Questions about '@' in pep 318 
<http://mail.python.org/pipermail/python-dev/2004-August/046934.html>`__
   - `A usability argument for list-after-def 
<http://mail.python.org/pipermail/python-dev/2004-August/046935.html>`__
   - `The impact of '@' on Leo 
<http://mail.python.org/pipermail/python-dev/2004-August/046937.html>`__
   - `Similar syntax 
<http://mail.python.org/pipermail/python-dev/2004-August/046969.html>`__
   - `def fn (args) [dec,dec]: 
<http://mail.python.org/pipermail/python-dev/2004-August/047112.html>`__
   - `pep 318, Decorators for Functions, Methods and Classes 
<http://mail.python.org/pipermail/python-dev/2004-August/047132.html>`__
   - `Density of pie-decorator syntax 
<http://mail.python.org/pipermail/python-dev/2004-August/047154.html>`__
   - `elements of decorator syntax suggestions 
<http://mail.python.org/pipermail/python-dev/2004-August/047185.html>`__
   - `318: Annotation background 
<http://mail.python.org/pipermail/python-dev/2004-August/047218.html>`__
   - `IPython, @, and option E from the wiki 
<http://mail.python.org/pipermail/python-dev/2004-August/047223.html>`__
   - `Decorators: vertical bar syntax 
<http://mail.python.org/pipermail/python-dev/2004-August/047231.html>`__
   - `Suggesting '.' decorators (PEP318) 
<http://mail.python.org/pipermail/python-dev/2004-August/047234.html>`__
   - `Attribute strings? 
<http://mail.python.org/pipermail/python-dev/2004-August/047362.html>`__
   - `request: add keywords for static and class methods only 
<http://mail.python.org/pipermail/python-dev/2004-August/047498.html>`__
   - `@decorator syntax is sugar, but for what exactly? 
<http://mail.python.org/pipermail/python-dev/2004-August/047500.html>`__
   - `Semantics of decorators? 
<http://mail.python.org/pipermail/python-dev/2004-August/047623.html>`__
   - `A decorator syntax not yet mentioned (I think!) 
<http://mail.python.org/pipermail/python-dev/2004-August/047625.html>`__
   - `Another approach to decorators. 
<http://mail.python.org/pipermail/python-dev/2004-August/047647.html>`__
   - `Decorators after 'def' should be reconsidered 
<http://mail.python.org/pipermail/python-dev/2004-August/047637.html>`__
   - `def ... decorate 
<http://mail.python.org/pipermail/python-dev/2004-August/047781.html>`__
   - `Decorator syntax J2 (decorate..def) 
<http://mail.python.org/pipermail/python-dev/2004-August/047807.html>`__
   - `Decorators and docstrings 
<http://mail.python.org/pipermail/python-dev/2004-August/047827.html>`__
   - `block-based decorators and other block issues 
<http://mail.python.org/pipermail/python-dev/2004-August/047839.html>`__
   - `More concerns about decorators 
<http://mail.python.org/pipermail/python-dev/2004-August/047863.html>`__

0
bac1 (39)
8/24/2004 4:50:48 AM
comp.lang.python 77058 articles. 6 followers. Post Follow

17 Replies
685 Views

Similar Articles

[PageSpeed] 24

Brett Cannon wrote:


> Armin Rigo came up with a way to have string concatenation in a loop 
> (think ``for thing in iter_of_strings: concat_str += thing``) not be a 
> quadratic algorithm 

> But Guido didn't like the patch.  

Sometimes I just don't get it.

Here is a patch that removes one of the warts of python, does not introduce
any new behavior, makes python behave as it should have had in the first place,
yet it gets shot down on the grounds that it is 'too much of an improvement'
and that other python implementations might not be able to keep up
with it...

Istvan.


0
ialbert (222)
8/24/2004 1:59:20 PM
On Tue, 24 Aug 2004 09:59:20 -0400, Istvan Albert
<ialbert@mailblocks.com> wrote:
> Brett Cannon wrote:
> 
> > Armin Rigo came up with a way to have string concatenation in a loop
> > (think ``for thing in iter_of_strings: concat_str += thing``) not be a
> > quadratic algorithm
> 
> > But Guido didn't like the patch.
> 
> Sometimes I just don't get it.
> 
> Here is a patch that removes one of the warts of python, does not introduce
> any new behavior, makes python behave as it should have had in the first place,
> yet it gets shot down on the grounds that it is 'too much of an improvement'
> and that other python implementations might not be able to keep up
> with it...

Er. Did you _read_ the rest of the section you quoted?

"""In the end, though, this went in with a warning that the speed
performance is not portable.  It is not to be used in the stdlib ever.""""
0
8/24/2004 2:06:41 PM
Anthony Baxter wrote:


> Er. Did you _read_ the rest of the section you quoted?
> 
> """In the end, though, this went in with a warning that the speed
> performance is not portable.  It is not to be used in the stdlib ever.""""

I read the whole thread. It is very clear from it that
the only reason this feature made it in (in whatever form)
is that it has already been committed without Guido's
permission and removing it would have been
quite a bit insulting. If it was up to Guido would
not have made it.

On my part calling it 'an idea that was shot down'
is an exaggeration, but then what does:

 > It is not to be used in the stdlib ever.

mean in this context?

Istvan.

0
ialbert (222)
8/24/2004 2:51:00 PM
[Istvan]
> what does:
> 
>  > It is not to be used in the stdlib ever.
> 
> mean in this context?

As I understand it, it means that no standard library code should take
advantage of the fact that repeated s1 += s2 operations are fast in CPython
2.4.  Instead, it should use the ''.join() idiom.

This seems reasonable - the standard library should work equally well across
all implementations of Python, and should serve as best-practice
documentation for writing "good" Python code.  My definition of "good" in
this context would include "works across all Python implementations without
unnecessary surprises".

-- 
Richie Hindle
richie@entrian.com

0
richie8547 (271)
8/24/2004 3:18:36 PM
Istvan Albert <ialbert@mailblocks.com> wrote in message news:<t6GdnTYtX4VOyLbcRVn-vA@giganews.com>...
>  > It is not to be used in the stdlib ever.
> 
> mean in this context?

IMHO, it means that Python code that is, or might be, checked into the
standard library (i.e. shipped with Python) must never assume that this
optimization is implemented.  Presumably this is because other Python 
implementations reuse code from the standard library and they may not
have implemented the optimization.
0
dlp (17)
8/24/2004 6:11:40 PM
"Brett Cannon" <bac@OCF.Berkeley.EDU> schreef in bericht
news:mailman.2274.1093330945.5135.python-list@python.org...
<...snip...>
> These stats along with the insane amount of email has showed me
> something; the Summaries have detracted from my participation on
> python-dev this past year.  I have a bigger mouth and more opinions than
> the number of emails I sent to the list show.  This means something has
> to change, and it isn't going to be my mouth.  The Summaries need to
> change in one of two ways.
<...snip...>
> Option two out of all of this is people just say, "summarize what you
> want, Brett."  Then I just cover what I find interesting and just don't
> worry about covering a specific area.  I obviously prefer this option
> but if people really care about a specific area I want to make sure to
> cover it.  What will most likely happen is I will still cover almost
> everything but the thoroughness will be lower.  I will go more off of
> memory for example.

Yes, please cover what you find interesting!
I prefer to read something with a personal taste in it.
Please don't be replaced by a thorough bot that does a mechanistic
summarizing job.
I always like your summaries.
>
<...snip...>

kind regards, Gerrit


0
gmuller (21)
8/24/2004 8:13:48 PM
"Brett Cannon" <bac@OCF.Berkeley.EDU> wrote in message
news:mailman.2274.1093330945.5135.python-list@python.org...
> python-dev Summary for 2004-08-01 through 2004-08-15
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> This is a summary of traffic on the `python-dev mailing list`_ from
> August 01, 2004 through August 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.

< my emphasis>

> All python-dev members
> are interested in seeing ideas discussed by the community, so don't
> hesitate to take a stance on something.

<snip>

> OK, tirade time.  If you don't want to listen to me get up on my
> soapbox, then just skip the rest of this...
>
> "In the old days, Guido would Pronounce, and we'd all bite our tongues
> (although not necessarily each his own).  The less time Guido can make
> for Python, the more important becomes graceful capitulation."  Tim said
> this and it makes me wish for the old days.  People had *months* to
> comment on decorators and no one spoke up until something went into the
> language.  Procrastination is not a virtue when it comes to major
> language evolution discussions.  What was worse was when the emails
> started repeating themselves (which was pretty much from the get-go when
> this exploded).  Seemed like people decided to start talking without
> doing some research.  Granted the PEP was outdated and the wiki page was
> not up yet, but this stuff was covered in the Summaries before and you
> could have just Googled for the previous threads.
>
> Personally, if I was Guido, I would have said that the community had
> their chance to speak up and they just didn't take it.  But Guido is a
> nicer guy than that so people are getting a second chance with this.
> Personally this came off a great case of the tyranny of the majority in
> my eyes.  There is a reason why Python is a dictatorship.
>

"Well, then allow me to retort."

Up until PyCon in June, Guido was publicly leaning toward a C1-flavor of
decorator syntax.  Apparently, there was sufficient furor by some audience
members (not to quibble whether or not this group was in fact representative
of all Python users) that Guido dropped back from it.  Sometime in June,
@decorator seemed to drop from the sky - it was not even one of the top 2
that GvR had in his keynote presentation - and by late July, it was suddenly
to be found in the newly released 2.4a2.

I guess my sin of omission was in not following python-dev directly, but
instead relying on the natural checks and balances that have produced the
beautiful Python language thus far.  Despite the periodic reporting of
python-dev summaries (thank you! BTW), and the April and June summaries of
the decorator status, *not one* of these summaries announced the selection
of "@decorator" before it was checked in and released - making it a seeming
fait accompli.  Contrast with the announcement of 'Generator expressions are
in!' in your May summary, well in advance of the 2.4a release.

> At this point people should be hashing out which syntax alternative they
> want to present to Guido on comp.lang.python_.  No more talking on
> python-dev, no more syntax proposals.  The community should set a goal
> date (Sept. 1 seems good) and just choose a bloody alternative.  Then
> when Guido makes his choice people accept it or just go to another
> language.  No one had better voice their disappoint once Guido chooses
> his syntax or I will personally come beat you over with a stick for
> being a whiner.
>

Um, where have you been?  It seemed to me that, instead of continued
wallowing in a chaos of syntax discussions, that we collectively *were*
working on "just choosing a bloody alternative."  I guess we've not been
wholly successful, as there are still *two* popular contenders, but one is
leading the other by more than 2-to-1, and a consensus measure shows an even
greater level of, if not acceptance, at least tolerance.  c.l.py is a tough
herd of cats!  Michael Sparks and Robert Brewer have voted in a measure
beyond simply posting Usenet votes, and have completed the steps for one of
the contenders to be considered by Guido.  The absence of champions for the
other option may end up making the decision by default - too bad, actually.

> OK, that's out of my system.  I feel better now.
>

Well, good for you.  I also subscribe to a "no whining" philosophy, but I
don't think it is unexpected nor unreasonable that the rapid selection,
implementation, and release of "@decorator" took many by (unpleasant)
surprise.  And am I the only one who has trouble reconciling your tirade
with your encouragement to "take a stance" (in the emphasized section at
top)?

We can agree to disagree - I'll plead guilty to being a miserable lurker who
up until recently was happy to rely on the wisdom of strangers - but allow
me to take at least a little umbrage at your tirade.

-- Paul


0
ptmcg2 (617)
8/24/2004 10:32:10 PM
[SNIP - me going on about how I had wished Guido just pronounced on
decorators and moved on]
> "Well, then allow me to retort."
> 
> Up until PyCon in June, Guido was publicly leaning toward a C1-flavor of
> decorator syntax.  Apparently, there was sufficient furor by some audience
> members (not to quibble whether or not this group was in fact representative
> of all Python users) that Guido dropped back from it.  Sometime in June,
> @decorator seemed to drop from the sky - it was not even one of the top 2
> that GvR had in his keynote presentation - and by late July, it was suddenly
> to be found in the newly released 2.4a2.
> 

The '@' syntax had pretty much been discussed the whole time.  At the
end of PyCON Guido had a chance to talk to some other developers
toward the end of the conference that started to change his opinion. 
After the conference he stated that he was starting to strongly
consider the '@' syntax, and this was all public.

He then went to EuroPython.  Audience was much more perceptive to '@'
than other syntaxes.  Some more contemplation on Guido's part, and
that led to the '@' syntax.

But even had there not been any public discussion on Guido's part, I
still think it is fine that Guido didn't have a huge discussion before
making his final decision.  This is Guido's language and we all just
happen to love it.


> I guess my sin of omission was in not following python-dev directly, but
> instead relying on the natural checks and balances that have produced the
> beautiful Python language thus far.

And the final check is Guido.  =)

>  Despite the periodic reporting of
> python-dev summaries (thank you! BTW),

Welcome.

> and the April and June summaries of
> the decorator status, *not one* of these summaries announced the selection
> of "@decorator" before it was checked in and released - making it a seeming
> fait accompli.

No report because I didn't officially know until people started to
scream about it (I check my python-dev mail before python-checkins so
I didn't even see the checkin before the flood of mail started).

>  Contrast with the announcement of 'Generator expressions are
> in!' in your May summary, well in advance of the 2.4a release.
> 

That's just because it was all resolved way back when.  Had decorators
been resolved earlier it also would have gotten mentioned earlier.

People need to realize this is all alpha software, not beta. 
Everything can change and python-dev reserves the right to tweak stuff
up to b1.

> > At this point people should be hashing out which syntax alternative they
> > want to present to Guido on comp.lang.python_.  No more talking on
> > python-dev, no more syntax proposals.  The community should set a goal
> > date (Sept. 1 seems good) and just choose a bloody alternative.  Then
> > when Guido makes his choice people accept it or just go to another
> > language.  No one had better voice their disappoint once Guido chooses
> > his syntax or I will personally come beat you over with a stick for
> > being a whiner.
> >
> 
> Um, where have you been?

Sitting in my chair reading a lot of email.

>  It seemed to me that, instead of continued
> wallowing in a chaos of syntax discussions, that we collectively *were*
> working on "just choosing a bloody alternative."

Not how it looked on python-dev.  Story may have been that on c.l.py,
but on my side it was a ton of back and forth and people proposing
random syntaxes whenever an idea popped in their head.

>  I guess we've not been
> wholly successful, as there are still *two* popular contenders, but one is
> leading the other by more than 2-to-1, and a consensus measure shows an even
> greater level of, if not acceptance, at least tolerance.  c.l.py is a tough
> herd of cats!  Michael Sparks and Robert Brewer have voted in a measure
> beyond simply posting Usenet votes, and have completed the steps for one of
> the contenders to be considered by Guido.  The absence of champions for the
> other option may end up making the decision by default - too bad, actually.
> 

And that's great.  As I said, this was not reflected on python-dev *at
all*.  Robert sent an email today stating that he had a whole paper on
the syntax he was supporting.  He seems to be going about it the right
way and honestly I hope his wins just for the fact that he has put the
effort in.


> > OK, that's out of my system.  I feel better now.
> >
> 
> Well, good for you.  I also subscribe to a "no whining" philosophy, but I
> don't think it is unexpected nor unreasonable that the rapid selection,
> implementation, and release of "@decorator" took many by (unpleasant)
> surprise.
>  And am I the only one who has trouble reconciling your tirade
> with your encouragement to "take a stance" (in the emphasized section at
> top)?
> 

Maybe.  =)

The tirade was not on taking a stand.  It was at everybody fighting
this out on python-dev even after Guido told people to go off and
agree on a single syntax.  python-dev is not the place to have the
whole community duke it out over an alternative syntax.  *That* was
what the tirade was about.

> We can agree to disagree - I'll plead guilty to being a miserable lurker who
> up until recently was happy to rely on the wisdom of strangers - but allow
> me to take at least a little umbrage at your tirade.
> 

Sure, but I think you mistook me.  But even if you didn't, no problem.

-Brett
0
brett3729 (21)
8/25/2004 2:51:43 AM
Paul McGuire wrote:
> "Brett Cannon" <bac@OCF.Berkeley.EDU> wrote in message
> news:mailman.2274.1093330945.5135.python-list@python.org...
> 
[snip]
> "Well, then allow me to retort."
> 
> Up until PyCon in June, Guido was publicly leaning toward a C1-flavor of
> decorator syntax.  Apparently, there was sufficient furor by some audience
> members (not to quibble whether or not this group was in fact representative
> of all Python users) that Guido dropped back from it.  Sometime in June,
> @decorator seemed to drop from the sky - it was not even one of the top 2
> that GvR had in his keynote presentation - and by late July, it was suddenly
> to be found in the newly released 2.4a2.
> 
My feeling is that Guido was right the first time.  One of C1 or C2 is 
the better way to go.

Why? There is a natural hierarchy.  We do not define methods before the 
class signature is given. A subclass is defined after the class. A break 
is specified within the flow control being broken. We don't refer to a 
function until after is is declared.

In the case of a 'decorator', it is better to identify the thing being 
modified, annotated or whatever before specifying the modification, 
annotation etc.  The exception to this would arise if the 'decoration' 
were to apply to a group of functions or methods, but this is not being 
proposed.

Brett Cameron and Anthony Baxter have pointed out that PEP 318 has been 
on the table for a while.  That's true, perhaps I didn't read it 
carefully enough, but my initial impression was that the PEP was 
concerned with tarting up a function.

It wasn't until I saw Dan Bishop's memoize that I realized the full 
import.  I tried it with his Fibonacci example and found that it offered 
a significant speed improvement over both recursion and the iterative 
solution.

Like many others, I fund the intrusion of a Perlish symbol into Python 
to be surprising.

Thus, to sum up, Guido was right, C1 or C2 would be better than what has 
been implemented in either the current alpha version or Robert Brewer's 
proposal.

Colin W.

0
cjw6656 (317)
8/25/2004 12:11:21 PM
On Mon, 23 Aug 2004 21:50:48 -0700, Brett Cannon
<bac@OCF.Berkeley.EDU> wrote:
>
>But then Guido decided to make my life difficult by saying that if the 
>community could come up with an agreed-upon alternative syntax to 
>propose to him he would consider ripping out the '@' syntax; decorators 
>have always been experimental and '@' was checked in so people had 
>*something* to play with.  This meant everyone and their mother started 
>to propose both new and old syntaxes for decorators.  This led to a 
>record amount of email on python-dev (at least compared to what we have 
>archives for; back to April 1999).

<SNIP>

>"In the old days, Guido would Pronounce, and we'd all bite our tongues 
>(although not necessarily each his own).  The less time Guido can make 
>for Python, the more important becomes graceful capitulation."  Tim said 
>this and it makes me wish for the old days.  People had *months* to 
>comment on decorators and no one spoke up until something went into the 
>language.  Procrastination is not a virtue when it comes to major 
>language evolution discussions.  What was worse was when the emails 
>started repeating themselves (which was pretty much from the get-go when 
>this exploded).  Seemed like people decided to start talking without 
>doing some research.  Granted the PEP was outdated and the wiki page was 
>not up yet, but this stuff was covered in the Summaries before and you 
>could have just Googled for the previous threads.

Perhaps you could clarify your position a bit.  I think the
"community" understands some fundamental difference between posting to
python-dev and to python-list.  If not Aahz is normally there to
remind them.

Guido's "genius" extends to marketing, IMO.

Having some sense of participation in the fate of Python, even if bit
hullicinatory, is fundamental to the development of its following.  A
clasic form of guerilla marketing.  Considering that the Python
markteing budget in $ is 0, I think it would be a mistake to have the
community believe that their only role is to read the release notes.

>
>Personally, if I was Guido, I would have said that the community had 
>their chance to speak up and they just didn't take it. 

I think you are inadvertently going somewhere dangerous here.  A
significant part of the community finds that their first appropriate
opportunity to comment to be after some initial decision at python-dev
- the Senate.  It then goes to the People. We the rowdy poeple then do
our rowdy thing.

You see the point...

I don't think you want to say to the People, either to crash the
Senate floor, or hold their peace,

Art

0
ajsiegel (191)
8/25/2004 1:22:33 PM
On Wed, 25 Aug 2004 13:22:33 GMT, Arthur <ajsiegel@optonline.com> wrote:
> Perhaps you could clarify your position a bit.  I think the
> "community" understands some fundamental difference between posting to
> python-dev and to python-list.  If not Aahz is normally there to
> remind them.
> 
> Guido's "genius" extends to marketing, IMO.
> 
> Having some sense of participation in the fate of Python, even if bit
> hullicinatory, is fundamental to the development of its following.  A
> clasic form of guerilla marketing.  Considering that the Python
> markteing budget in $ is 0, I think it would be a mistake to have the
> community believe that their only role is to read the release notes.

I think Brett might have overstated his case a little - I can
understand his frustration, though. The _overwhelming_ number of posts
on the subject of decorators have evidently not bothered to make the
slightest effort to read the past postings on the subject. Yes, part
of this is that the PEP wasn't up to date before a2. But I see many of
the same points being raised, again and again, without the poster
having bothered to read the previous posts and the replies to them,
often _in_ _the_ _same_ _thread_. Instead, there was a mass pile-on of
folks jumping up and down and screaming[1]

[1] I'm obviously not including everyone here. There's also been a
large number of insightful and carefully thought out posts.

_No-one_ is saying "we don't need to include the community". FFS, I'd
point to the something around 120 posts I've made to
c.l.py/python-list since a2 came out.

However (and this is what I think Brett was trying to get at) at a
certain point in any syntax discussion, it comes down to aesthetics,
and a judgement call. And the person who _I_ trust to make the best
judgement call on the subject of Python's aesthetics is Guido. He's
got an exceptionally good track record here. (I discount print >>,
which I still regard as horrible).

Go back and read some of the earlier posts after a2 came out. In many,
many cases they were full-on rants and raves, "how could Guido do
this?" and the like. I'm _quite_ confident that in many/most cases,
the people doing the ranting and raving had *not* bothered to download
the alpha and actually *try* *the* *syntax* *out*. Instead, we got
"ew! the @ symbol! That's perl!" or "decorators are stupid! No-one
needs them!"

Certainly, part of the reason many of my responses were strongly
worded in the days after the a2 release was that it was obvious the
posters were posting their immediate thoughts, as I said, without
bothering to stop and try the syntax out, or think about the issues a
little.

I'm all for community involvement. I recognise that we could have done
better in the days around the second alpha, and I've been trying
*damn* hard to make that better. But I don't see much point getting
community feedback if the feedback is unthinking abuse and uninformed
ranting. It's a two way street.
0
8/25/2004 5:54:53 PM
Richie Hindle <richie@entrian.com> writes:

> [Istvan]
> > what does:
> > 
> >  > It is not to be used in the stdlib ever.
> > 
> > mean in this context?
> 
> As I understand it, it means that no standard library code should take
> advantage of the fact that repeated s1 += s2 operations are fast in CPython
> 2.4.  Instead, it should use the ''.join() idiom.
[...]

The stdlib already *does* take advantage of the patch.

It began taking advantage of it the instant the code was committed,
because, for example, httplib.HTTPResponse_read_chunked() uses string
concatenation.

believe-it-or-not-ly y'rs,


John
0
jjl (1300)
8/25/2004 6:38:33 PM
Arthur <ajsiegel@optonline.com> wrote in message news:<3l3pi0pgmgu0uir1ucnj0rlfo355c6i5cp@4ax.com>...
> On Mon, 23 Aug 2004 21:50:48 -0700, Brett Cannon
> <bac@OCF.Berkeley.EDU> wrote:
> >
> >But then Guido decided to make my life difficult by saying that if the 
> >community could come up with an agreed-upon alternative syntax to 
> >propose to him he would consider ripping out the '@' syntax; decorators 
> >have always been experimental and '@' was checked in so people had 
> >*something* to play with.  This meant everyone and their mother started 
> >to propose both new and old syntaxes for decorators.  This led to a 
> >record amount of email on python-dev (at least compared to what we have 
> >archives for; back to April 1999).
> 
> <SNIP>
> 
> >"In the old days, Guido would Pronounce, and we'd all bite our tongues 
> >(although not necessarily each his own).  The less time Guido can make 
> >for Python, the more important becomes graceful capitulation."  Tim said 
> >this and it makes me wish for the old days.  People had *months* to 
> >comment on decorators and no one spoke up until something went into the 
> >language.  Procrastination is not a virtue when it comes to major 
> >language evolution discussions.  What was worse was when the emails 
> >started repeating themselves (which was pretty much from the get-go when 
> >this exploded).  Seemed like people decided to start talking without 
> >doing some research.  Granted the PEP was outdated and the wiki page was 
> >not up yet, but this stuff was covered in the Summaries before and you 
> >could have just Googled for the previous threads.
> 
> Perhaps you could clarify your position a bit.  I think the
> "community" understands some fundamental difference between posting to
> python-dev and to python-list.

python-dev is meant for discussing details about  Python's evolution. 
The idea is that pie-in-the-sky ideas get hashed out in the community
(which c.l.py is the gateway), once it gets clarified and has
community support it moves over to python-dev, it gets discussed
there, and either gets accepted, canned, or revised and sent back out
to the community for more refinement.

Obviously this is not hard and fast, but in general that is how it is
supposed to work.

>  If not Aahz is normally there to
> remind them.
> 

=)

> Guido's "genius" extends to marketing, IMO.
> 
> Having some sense of participation in the fate of Python, even if bit
> hullicinatory, is fundamental to the development of its following.  A
> clasic form of guerilla marketing.  Considering that the Python
> markteing budget in $ is 0, I think it would be a mistake to have the
> community believe that their only role is to read the release notes.
> 

But the community shouldn't think that.  Just read the developer intro
(http://www.python.org/dev/dev_intro.html) and you  can see how many
mentions there are of the community in it.  Participation is
practically required for a PEP to even be considered  being looked at,
for instance.

> >
> >Personally, if I was Guido, I would have said that the community had 
> >their chance to speak up and they just didn't take it. 
> 
> I think you are inadvertently going somewhere dangerous here.  A
> significant part of the community finds that their first appropriate
> opportunity to comment to be after some initial decision at python-dev
> - the Senate.  It then goes to the People. We the rowdy poeple then do
> our rowdy thing.
> 
> You see the point...
> 
> I don't think you want to say to the People, either to crash the
> Senate floor, or hold their peace,
> 

Just to start off, I hope everyone realizes this is my opinion and in
no way do I represent python-dev in any official way.  Even with the
Summaries I just happen to be dumb enough to do them so they just let
me play in my little corner while I write up the history book.  =)

OK, with that disclaimer out of the way...

That is the reverse order of things are supposed to be.  It should go:
the idea being put before the people, they let their collective voice
be known, and then the Senate takes a look and has a vote.  We try to
use the community as a basic filter for feature ideas, python-dev
hashes out  the details.  Trust me, you don't want python-dev
involvement unless you want really nitty-gritty arguments over things
as small as function names and stdlib coding style.  It is not a party
with Barry getting plastered on beer, Tim with a lady on each arm, and
me getting stoned in a corner with the crack that Barry gave me
earlier while Raymond is tweaking out on Speed

I am sure people are going to be sick of my political system
analogies, but my bachelors is in philosophy so it's how I think.  =) 
Think of c.l.py as the general public.  Its role is to come up with
ideas and to voice its opinion on those ideas.  python-dev is the
advising committee to the BDFL.  Its role is to take ideas from the
community and to generate its own in terms of running PythonLand in
terms of day-to-day details; it's Guido's cabinet.  Guido, the
dictator, holds absolute power and makes final decisions on things
that the cabinet brings in front of him.  It actually mirrors the US
government fairly well sans the ability to overturn the dictator  =) .

Although it is in no way a direct, or even indirect democracy (then
again it  could be argued neither is  the US with the amount of
political passivity in the country).  People live in PythonLand if
they are happy but really have no direct vote unless the dictator
gives it to them on some specific issue.  And if people really don't
like that they are free to leave although no one wants that to happen.
 Yes, we try to listen to what people want, but in the end we all rely
on Guido's gut to lead us.

And that is the order that things are supposed to flow.  Public voices
opinion on idea, cabinet fiddles, dictator decides.  Usually it goes
that way unless someone from the public skips dealing with the public
forum and goes straight to the cabinet.  If it is a small, simple idea
that is fine, but if the idea has any form of complexity the person
gets kicked out and told to talk to his fellow man first to see if
they like the idea.

And this is essentially how it went when decorators were first brought
up.  But then the public decided to throw a little mutiny over the
dictator's decision.  It's the first time I know of where the
community came back to really snap at Guido for his decision (all
other times has been people whining but eventually people said, "I
wish you had not done that, but  I will just deal with it and trust
you").  I think everyone (community, python-dev, maybe even Guido) has
learned some lessons from this whole experience.

I just don't want people to suddenly get the impression that they can
always just throw a little mutiny every time Guido makes a decision. 
Do that and he will just ignore what people want period and never even
give people a chance to propose an alternative once it reaches
python-dev.

And I want people to realize my tirade was just that, a personal
tirade.  It was out of frustration and thus should be taken with a
grain of salt.

And that frustration came from the feeling that the Python community,
which I love, seemed to suddenly form a mob, grab pitchforks and
torches, and started screaming.  And then they seemed to hold a public
meeting with *everyone* proposing their idea and not completely
listening to initial decisions.

I truly hope that next time Guido makes a decision that people as a
whole disagree with everyone involved can get together and discuss it
calmly without flooding my inbox.  =)

-Brett
0
brett3729 (21)
8/25/2004 7:03:49 PM
On Thu, 26 Aug 2004 03:54:53 +1000, Anthony Baxter
<anthonybaxter@gmail.com> wrote:
>got an exceptionally good track record here. (I discount print >>,
>which I still regard as horrible).

Not only am I OK with print >> and use print >>, I am clueless in
trying to identify the nerve it touches in those who view it with
horror.

Which gives you a clue - 

 as to with whom you have been wasting your time. 

;)

Art

0
ajsiegel (191)
8/26/2004 12:40:24 AM
On 25 Aug 2004 12:03:49 -0700, brett@python.org (Brett C.) wrote:

>Arthur <ajsiegel@optonline.com> wrote in message news:<3l3pi0pgmgu0uir1ucnj0rlfo355c6i5cp@4ax.com>...
>
>python-dev is meant for discussing details about  Python's evolution. 
>The idea is that pie-in-the-sky ideas get hashed out in the community
>(which c.l.py is the gateway), once it gets clarified and has
>community support it moves over to python-dev, it gets discussed
>there, and either gets accepted, canned, or revised and sent back out
>to the community for more refinement.

Huh?

I don't agree that it is supposed to work in any particular way.  It
works the way it works. 

There *is* a BDFL,  

Which is fine with me, but inconsistent with a defined structure of
the kind you are trying to describe, or any other kind for that
matter.

>> You see the point...
>> 
>> I don't think you want to say to the People, either to crash the
>> Senate floor, or hold their peace,
>> 
>
>Just to start off, I hope everyone realizes this is my opinion and in
>no way do I represent python-dev in any official way.  Even with the
>Summaries I just happen to be dumb enough to do them so they just let
>me play in my little corner while I write up the history book.  =)
>
>OK, with that disclaimer out of the way...
>
>That is the reverse order of things are supposed to be. 

Huh?

I don't agree that it is supposed to work in any particular way.  It
works the way it works. 

There *is* a BDFL,  

Which is fine with me, but inconsistent with a defined structure of
the kind you are trying to describe, or any other kind for that
matter.


Art
0
ajsiegel (191)
8/26/2004 2:01:21 AM
jjl@pobox.com (John J. Lee) wrote in message news:<87y8k35ahi.fsf@pobox.com>...
> Richie Hindle <richie@entrian.com> writes:
> 
> > [Istvan]
> > > what does:
> > > 
> > >  > It is not to be used in the stdlib ever.
> > > 
> > > mean in this context?
> > 
> > As I understand it, it means that no standard library code should take
> > advantage of the fact that repeated s1 += s2 operations are fast in CPython
> > 2.4.  Instead, it should use the ''.join() idiom.
> [...]
> 
> The stdlib already *does* take advantage of the patch.
> 
> It began taking advantage of it the instant the code was committed,
> because, for example, httplib.HTTPResponse_read_chunked() uses string
> concatenation.

Yes, the standard library does benefit.  The += style is occasionally
used either out of necessity or for simplicity in some places.  For
the most part, whereever it really matters, ''.join() was always used.
 There are some places like the sre modules where the cost of building
up small lists and joining them does not pay for itself.  Also, I
believe (but haven't checked recently) that some SAX code also uses +=
because the consecutive additions take place across calls and the
string is expected to be available after each.  In some places, there
are just a small constant number of string adds that don't warrant
using less straight-forward coding for speed.

If you see a time critical section of library code that can profitably
be converted to ''.join(), then please submit a patch.  If it is not
time sensitive, resist the temptation to optimize it.

That guidance can also apply to non-library code.  The purpose of the
+= optimization was to make it less disasterous when someone forgets
to use ''.join().  Ideally, the experts will leaving their coding
styles unchanged.


Raymond
0
python (586)
8/26/2004 5:51:46 AM
Brett C. <brett@python.org> wrote:

> Obviously this is not hard and fast

It _IS_ quite hard, but _definitely_ not fast...;-)


Alex
0
aleaxit (1612)
8/26/2004 1:30:38 PM
Reply:

Similar Artilces:

RE: python-dev Summary for 2004-08-01 through 2004-08-15 #2
Brett C. wrote: > I just don't want people to suddenly get the impression that they can > always just throw a little mutiny every time Guido makes a decision.=20 > Do that and he will just ignore what people want period and never even > give people a chance to propose an alternative once it reaches > python-dev. Well said. > And I want people to realize my tirade was just that, a personal > tirade. It was out of frustration and thus should be taken with a > grain of salt. But that frustration is grounded in reality. > And that frustration came from the feeli...

python-dev Summary for 2004-01-01 through 2004-01-31
python-dev Summary for 2004-01-01 through 2004-01-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from=20 January 1, 2004 through January 31, 2004. It is intended to inform the=20 wider Python community of on-going developments on the list. To comment=20 on anything mentioned here, just post to `comp.lang.python`_ (or email=20 python-list@python.org which is a gateway to the newsgroup) with a=20 subject line mentioning what you are discussing. All python-dev members=20 are interested in seeing ideas discussed by the commu...

python-dev Summary for 2003-08-01 through 2003-08-15
python-dev Summary for 2003-08-01 through 2003-08-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from=20 August 1, 2003 through August 15, 2003. It is intended to inform the=20 wider Python community of on-going developments on the list. To comment=20 on anything mentioned here, just post to python-list@python.org or=20 `comp.lang.python`_ with a subject line mentioning what you are=20 discussing. All python-dev members are interested in seeing ideas=20 discussed by the community, so don't hesitate to take a stance o...

python-dev Summary for 2004-07-01 through 2004-07-15
python-dev Summary for 2004-07-01 through 2004-07-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from July 01, 2004 through July 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'...

python-dev Summary for 2005-08-01 through 2005-08-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-08-01_2005-08-15.html] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Announcements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Some wise words from Donovan Baarda in the PEP 347 discussions: It is true that some well designed/developed software becomes = reliable very quickly. However, it still takes heavy use over time to prove that. Contributing thread: - `PEP: Migrating the Python CVS to Subversion <http://mail.python.org/pipermail/python-dev/2005-August/055105.html>`__ [SJB] ------------ Process PEPs ------------ The PEP editors have introduced a new PEP category: "Process", for PEPs = that don't fit into the "Standards Track" and "Informational" categories. = More detail can be found in `PEP 1`_, which is itself a Process PEP. ... _PEP 1: http://www.python.org/peps/pep-0001.html Contributing thread: - `new PEP type: Process <http://mail.python.org/pipermail/python-dev/2005-August/055361.html>`__ [TAM] ----------------------------------------------- Tentative Schedule for 2.4.2 and 2.5a1 Releases ----------------------------------------------- Python 2.4.2 is tentatively scheduled for a mid-to-late September = release and a first alpha of Python 2.5 for March 2006 (with a final release = aro...

python-dev Summary for 2004-06-01 through 2004-06-15
python-dev Summary for 2004-06-01 through 2004-06-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from June 01, 2004 through June 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 forty-third summary written by Brett Cannon (wonder if that summary count is correct?). 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...

python-dev Summary for 2006-08-01 through 2006-08-15
python-dev Summary for 2006-08-01 through 2006-08-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ ... contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-08-01_2006-08-15] ========= Summaries ========= -------------------------------- Mixing str and unicode dict keys -------------------------------- Ralf Schmitt noted that in Python head, inserting str and unicode keys to the same dictionary would sometimes raise UnicodeDecodeErrors:: >>> d = {} >>> d[u'm\xe1s'] = 1 >>> d['m\xe1s'] = 1 Traceback (most recent call last): ... UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 1: ordinal not in range(128) This error showed up as a result of Armin Rigo's `patch to stop dict lookup from hiding exceptions`_, which meant that the UnicodeDecodeError raised when a str object is compared to a non-ASCII unicode object was no longer silenced. In the end, people agreed that UnicodeDecodeError should not be raised for equality comparisons, and in general, ``__eq__()`` methods should not raise exceptions. But comparing str and unicode objects is often a programming error, so in addition to just returning False, equality comparisons on str and non-ASCII unicode now issues a warning with the UnicodeDecodeError message. ... _patch to stop dict lookup from hiding exceptions: http://bugs.python.org/1...

python-dev Summary for 2006-08-01 through 2006-08-15 #2
python-dev Summary for 2006-08-01 through 2006-08-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-08-01_2006-08-15] ========= Summaries ========= -------------------------------- Mixing str and unicode dict keys -------------------------------- Ralf Schmitt noted that in Python head, inserting str and unicode keys to the same dictionary would sometimes raise UnicodeDecodeErrors:: >>> d = {} >>> d[u'm\xe1s'] = 1 >>> d['m\xe1s&#...

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

python-dev Summary for 2004-03-16 through 2004-03-31
python-dev Summary for 2004-03-16 through 2004-03-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from March 16, 2004 through March 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 thirty-eighth summary written by Brett Cannon (who managed to actually convince someone to employ him for the summer). 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 p...

python-dev Summary for 2006-08-16 through 2006-08-31
python-dev Summary for 2006-08-16 through 2006-08-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ ... contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-08-16_2006-08-31] ============= Announcements ============= --------------------------- Python communnity buildbots --------------------------- Want to make sure your package works with the latest and greatest development and release versions of Python? Thanks to Grig Gheorghiu, you can add your test suite to the `Python community buildbots`_ and the results of these tests will show up on the `Python buildbot results page`_. ... _Python community buildbots: http://www.pybots.org/ ... _Python buildbot results page: http://www.python.org/dev/buildbot/ Contributing thread: - `link to community buildbot? <http://mail.python.org/pipermail/python-dev/2006-August/068552.html>`__ ========= Summaries ========= --------------------- Fast subclass testing --------------------- Neal Norwitz was playing around with a patch that would make subclass testing for certain builtin types faster by stealing some bits from tp_flags. Georg Brandl thought this could be useful for exception handling in Python 3000 when all exceptions must be subclasses of BaseException. Guido also liked the patch and suggested it be checked into the `Python 3000 branch`_. ... _Python 3000 branch: http://svn.python.org/view/python/branches/p3yk/ Contr...

python-dev Summary for 2004-07-16 through 2004-07-31
python-dev Summary for 2004-07-16 through 2004-07-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from July 16, 2004 through July 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'...

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

python-dev Summary for 2006-01-01 through 2006-01-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-01-01_2006-01-15.html] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Announcements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Guido, on the crashability of Python: I'm not saying it's uncrashable. I'm saying that if you crash it, it's a bug unless proven harebrained. Contributing thread: - `Include ctypes into core Python? <http://mail.python.org/pipermail/python-dev/2006-January/059621.html>`_ [SJB] ------------------------------------ Brett Cannon looking for Ph.D. ideas ------------------------------------ Brett Cannon is looking for Python-related ideas to form the subject of his PhD dissertation, under Eric Wohlstadter at the University of British Columbia. He has three areas in which he has possible funding (XML integration, game scripting support, and AOP); he is open to grants from anyone else interested in particular Python development.=20 If anyone has suggestions for topics, Brett is listening! So far: * Phillip J. Eby mentioned that he has been doing some research on implementing a non-traditional form of AOP in Python. * Bill Janssen suggested a system to compile Python to AJAX. * Steve Holden suggested a Python learning system. * Ian Bicking suggested Boxer_ implemented for Python. * Armin Rigo suggested PyPy related w...

python-dev Summary for 2005-01-01 through 2005-01-15
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 ...

python-dev Summary for 2006-01-01 through 2006-01-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-01-01_2006-01-15.html] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Announcements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Guido, on the crashability of Python: I'm not saying it's uncrashable. I'm saying that if you crash it, it's a bug unless proven harebrained. Contributing thread: - `Include ctypes into core Python? <http://mail.python.org/pipermail/python-dev/2006-January/059621.html>`_ [SJB] ------------------------------------ Brett Cannon looking for Ph.D. ideas ------------------------------------ Brett Cannon is looking for Python-related ideas to form the subject of his PhD dissertation, under Eric Wohlstadter at the University of British Columbia. He has three areas in which he has possible funding (XML integration, game scripting support, and AOP); he is open to grants from anyone else interested in particular Python development.=20 If anyone has suggestions for topics, Brett is listening! So far: * Phillip J. Eby mentioned that he has been doing some research on implementing a non-traditional form of AOP in Python. * Bill Janssen suggested a system to compile Python to AJAX. * Steve Holden suggested a Python learning system. * Ian Bicking suggested Boxer_ implemented for Python. * Armin Rigo suggested PyPy related work. * Jason Orendorff suggested collectin...

08-08-08
Tomorrow is, but I haven't seen the usual comment on such dates. Perhaps I should look in the Atmarian calendar? Tracy Johnson Measurement Specialties Inc. BT NNNN=20 * To join/leave the list, search archives, change list settings, * * etc., please visit http://raven.utc.edu/archives/hp3000-l.html * Chinese olympic games do begin at 08:08 08-08-08 because it is a genera= l belief in China that number 8 brings luck. BRGds, Andres Ogayar I.T. ELCAN Optical Technologies Raytheon Microelectronics Espa=F1a, S.A. T: +34.95.224.92.27 M...

python-dev Summary for 2005-03-01 through 2005-03-15
[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 bug...

python-dev Summary for 2006-07-01 through 2006-07-15
python-dev Summary for 2006-07-01 through 2006-07-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ ... contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-07-01_2006-07-15] ============= Announcements ============= ------------------- Python 2.5 schedule ------------------- Python continues to make progress towards Python 2.5 final. See `PEP 356`_ for more details and the full schedule. ... _PEP 356: http://www.python.org/dev/peps/pep-0356/ Contributing threads: - `TRUNK FREEZE for 2.5b2, tomorrow Tuesday 11th, 00:00 UTC <http://mail.python.org/pipermail/python-dev/2006-July/067189.html>`__ - `Subject: RELEASED Python 2.5 (beta 2) <http://mail.python.org/pipermail/python-dev/2006-July/067255.html>`__ - `TRUNK is UNFROZEN. <http://mail.python.org/pipermail/python-dev/2006-July/067259.html>`__ -------------------------- ctypes in the Python trunk -------------------------- Martin v. Lowis successfully imported the ctypes history into the Python trunk, so ctypes now shares its repository with the rest of Python. Thanks everyone for your hard work! Contributing threads: - `Moving the ctypes repository to python.org <http://mail.python.org/pipermail/python-dev/2006-July/066962.html>`__ - `Subversion outage Friday 15:00 GMT <http://mail.python.org/pipermail/python-dev/2006-July/067101.html>`__ - `SVN write access is back <http://mail.python.org/pipermail/python-dev/2006-July/067125...

python-dev Summary for 2003-10-01 through 2003-10-15
python-dev Summary for 2003-10-01 through 2003-10-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from=20 October 1, 2003 through October 15, 2003. It is intended to inform the=20 wider Python community of on-going developments on the list. To comment=20 on anything mentioned here, just post to `comp.lang.python`_ (or email=20 python-list@python.org which is a gateway to the newsgroup) with a=20 subject line mentioning what you are discussing. All python-dev members=20 are interested in seeing ideas discussed by the commu...

python-dev Summary for 2003-09-01 through 2003-09-15
python-dev Summary for 2003-09-01 through 2003-09-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from September 1, 2003 through September 15, 2003. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email 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...

python-dev Summary for 2006-10-01 through 2006-10-15
python-dev Summary for 2006-10-01 through 2006-10-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ ... contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-10-01_2006-10-15] ============= Announcements ============= ----------------------------- QOTF: Quotes of the Fortnight ----------------------------- Martin v. Lowis on a small change to Python that wouldn't affect many applications: I'm pretty sure someone will notice, though; someone always notices. Contributing thread: - `Caching float(0.0) <http://mail.python.org/pipermail/python-dev/2006-October/069175.html>`__ Steve Holden reminds us that patch submissions are dramatically preferred to verbose thread discussions: This thread has disappeared down a rat-hole, never to re-emerge with anything of significant benefit to users. C'mon, guys, implement a patch or leave it alone :-) Contributing thread: - `Caching float(0.0) <http://mail.python.org/pipermail/python-dev/2006-October/069190.html>`__ ========= Summaries ========= -------------- Caching floats -------------- Nick Craig-Wood discovered that he could save 7MB in his application by adding the following simple code:: if age == 0.0: age = 0.0 A large number of his calculations were producing the value 0.0, which meant that many copies of 0.0 were being stored. Since all 0.0 literals refer to the same object, the code above was removing all the duplicat...

python-dev Summary for 2005-05-01 through 2005-05-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-05-01_2005-05-15.html] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Summary Announcements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------- PEP 340 Episode 2: Revenge of the With (Block) ---------------------------------------------- This fornight's Python-Dev was dominated again by another nearly 400 messages on the topic of anonymous block statements. The discussion was a little more focused than the last thanks mainly to Guido's introduction of `PEP 340`_. Discussion of this PEP resulted in a series of other PEPs, including * `PEP 342`_: Enhanced Iterators, which broke out into a separate PEP the parts of `PEP 340`_ that allowed code to pass values into iterators using ``continue EXPR`` and yield-expressions. * `PEP 343`_: Anonymous Block Redux, a dramatically simplified version of `PEP 340`_, which removed the looping nature of the anonymous blocks and the injection-of-exceptions semantics for generators. * `PEP 3XX`_: User Defined ("with") Statements, which proposed non-looping anonymous blocks accompanied by finalization semantics for iterators and generators in for loops. Various details of each of these proposals are discussed below in the sections: 1. `Enhanced Iterators`_ 2. `Separate APIs for Iterators and Anonymous Blocks`_...

Web resources about - python-dev Summary for 2004-08-01 through 2004-08-15 - comp.lang.python

Resources last updated: 3/26/2016 11:23:39 PM