f



python-dev Summary for 2005-09-01 to 2005-09-15

[Note: yes, this is *September*!  All my (Tony's) bad, Steve has been =20=

chugging away at the summaries like he should have.  Extra apologies =20
for this one - it was approved by python-dev a while back, and I =20
didn't realise that I hadn't done the python-list post.]

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

... contents::

[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2005-09-01_2005-09-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: Quotes of the Fortnight
-----------------------------

In the thread on the print statement, Charles Cazabon provided some =20
nice imagery for Guido's Python 3.0 strategy.  Our first QOTF is his =20
comment about the print statement:

     It's an anomaly.  It stands out in the language as a sore thumb =20
waiting for Guido's hammer.

We also learned something important about the evolution of Python =20
thanks to Paul Moore.  In the thread on the Python 3.0 executable =20
name, Greg Ewing worried that if the Python 3.0 executable is named =20
"py":

     Python 4.0 is going to just be called "p", and by the time we =20
get to Python 5.0, the name will have vanished altogether!

Fortunately, as Paul Moore explains in our second QOTF, these naming =20
conventions are exactly as we should expect them:

     That's OK, by the time Python 5.0 comes out, it will have taken =20
over the world and be the default language for everything. So =20
omitting the name is exactly right :-)

[SJB]

Contributing threads:

- `Replacement for print in Python 3.0 <http://mail.python.org/=20
pipermail/python-dev/2005-September/055995.html>`__
- `Python 3 executable name <http://mail.python.org/pipermail/python-=20
dev/2005-September/056377.html>`__

--------------------------------------------------
The "Swiss Army Knife (...Not)" API design pattern
--------------------------------------------------

This fortnight saw a number of different discussions on what Guido's =20
guiding principles are in making design decisions about Python. Guido =20=

introduced the "Swiss Army Knife (...Not)" API design pattern, which =20
has been lauded by some as `the long-lost 20th principle from the Zen =20=

of Python`_. A direct quote from Guido:

     [I]nstead of a single "swiss-army-knife" function with various =20
options that choose different behavior variants, it's better to have =20
different dedicated functions for each of the major functionality types.

This principle is the basis for pairs like str.split() and str.rsplit=20
() or str.find() and str.rfind().  The goal is to keep cognitive =20
overhead down by associating with each use case a single function =20
with a minimal number of parameters.

[SJB]

... _the long-lost 20th principle from the Zen of Python: http://=20
mail.python.org/pipermail/python-dev/2005-September/056228.html

Contributing threads:

- `Replacement for print in Python 3.0 <http://mail.python.org/=20
pipermail/python-dev/2005-September/056202.html>`__
- `Replacement for print in Python 3.0 <http://mail.python.org/=20
pipermail/python-dev/2005-September/056228.html>`__

------------------------
A Python-to-C++ compiler
------------------------

Mark Dufour announced `Shed Skin`_, an experimental Python-to-C++ =20
compiler, which can convert many Python programs into optimized C++ =20
code, using static type inference techniques.  It works best for =20
Python programs written in a relatively static C++-style; much work =20
remains to be done, and Mark would like anyone interested in getting =20
involved to contact him.  Shed Skin was one of the recent `Google`_ =20
`Summer of Code`_ projects.
... _Shed Skin: http://shedskin.sourceforge.net
... _Google: http://www.google.com
... _Summer of Code: http://code.google.com/summerofcode.html

[TAM]

Contributing thread:

- `First release of Shed Skin, a Python-to-C++ compiler. <http://=20
mail.python.org/pipermail/python-dev/2005-September/056356.html>`__

--------------------------------------------------------------
python-checkins followups now stay on the python-checkins list
--------------------------------------------------------------

In a follow-up to a `thread in early July`_, the python-checkins =20
mailing list Reply-To header munging has been turned off.  =20
Previously, follow-ups to python-checkins would be addressed to =20
python-dev; now, follow-ups will stay on the python-checkins list by =20
default.

... _thread in early July: http://www.python.org/dev/summary/=20
2005-07-01_2005-07-15.html#behavior-of-sourceforge-when-replying-to-=20
python-checkins

[TAM]

Contributing thread:

- `python-checkins reply-to <http://mail.python.org/pipermail/python-=20
dev/2005-September/056428.html>`__


=3D=3D=3D=3D=3D=3D=3D=3D=3D
Summaries
=3D=3D=3D=3D=3D=3D=3D=3D=3D

--------------------------------------------
Converting print to a function in Python 3.0
--------------------------------------------

In Python 3.0, Guido wants to change print from a statement to a =20
function.  Some of his motivation for this change:

* Converting code that uses the print statement to instead use the =20
logging package, a UI package, etc. is complicated because of the =20
syntax.  Parentheses, commas and >>s all behave differently in the =20
print statement than they would in a function call.
* Having print as a statement makes the language harder to evolve.  =20
For example, if it's determined that Python should gain printf =20
behavior of some sort, adding this is harder -- as a statement, it =20
would require the introduction of new syntax, as a function, it would =20=

feel like a second-class citizen compared to print.
* Since the print statement always inserts spaces, code that doesn't =20
want these spaces will often have to use a completely different style =20=

of formatting (e.g. using sys.stdout.write and/or string formatting)
* Changing the behavior of statements is hard, while builtin =20
functions can simply be replaced by setting an attribute of __builtin__.

Guido's initial proposal suggested three methods to be adopted by all =20=

stream (file-like) objects::

     stream.write(a1, a2, ...) equivalent to:
         map(stream.write, map(str, [a1, a2, ...]))
     stream.writeln(a1, a2, ...) equivalent to:
         stream.write(a1, a2, ..., "\n")
     stream.writef(fmt, a1, a2, ...) equivalent to:
         stream.write(fmt % (a1, a2, ...))

Additionally, three new builtins would appear, write(), writeln() and =20=

writef() which called the corresponding methods on sys.stdout.

People had a number of problems with this initial proposal:

* People make heavy use of the space-insertion behavior of the =20
current print statement. With Guido's initial proposal, inserting =20
spaces would require manually adding space characters, e.g. ``write=20
(foo, " ", bar, " ", baz)``.
* People want to keep the stream API simple.  With Guido's initial =20
proposal, all file-like objects would probably need to support these =20
three new methods.  (But see also `Deriving file-like object methods =20
from read() and write()`_.)
* People primarily (about 85% of the time) use the print statement to =20=

print complete lines.  With Guido's initial proposal, the function to =20=

do this, writeln(), has the longer name than the less-frequently =20
needed write().

There were a variety of proposals following Guido's that attempted to =20=

address the issues above, most of which were posted to the wiki_.  =20
They generally all proposed a function something like::

     def print(*args):
         sys.stdout.write(' '.join(str(arg) for arg in args))
         sys.stdout.write('\n')

with support for a file=3D keyword parameter to specify a stream other =20=

than sys.stdout, and a sep=3D keyword parameter to specify a separator =20=

other than ' '.  There was some discussion about how the final =20
newline could be suppressed, including a nl=3D keyword parameter and =20
the usage of the Ellipsis object (e.g. so that ``print(foo, bar, ...)=20
`` would not print the final newline).  There was also substantial =20
support for a formatting variant like::

     def printf(fmt, *args):
         print(fmt % args)

In the end, Guido seemed to be leaning towards supporting three =20
printing variants::

* print(...) would be much like the proposals above, calling str() on =20=

each argument and then printing them with spaces in between and a =20
following newline
* printraw(...) or printbare(...) would also call str() on each =20
argument and print them, but with no intervening spaces and no final =20
newline
(c) printf(fmt, ...) would string-substitute the arguments into the =20
format string and then write the format string

Each of these functions would also accept a keyword parameter for =20
specifying a stream other than sys.stdout.  Because ``print`` is a =20
keyword, ``from __future__ import printing`` would be required to use =20=

the new print() function.

At this point, the thread trailed off, and no final decisions were made.

[SJB]

... _wiki: http://wiki.python.org/moin/PrintAsFunction

Contributing threads:

- `Python 3 design principles <http://mail.python.org/pipermail/=20
python-dev/2005-September/055944.html>`__
- `Replacement for print in Python 3.0 <http://mail.python.org/=20
pipermail/python-dev/2005-September/055968.html>`__
- `New Wiki page - PrintAsFunction <http://mail.python.org/pipermail/=20
python-dev/2005-September/056081.html>`__
- `Hacking print (was: Replacement for print in Python 3.0) <http://=20
mail.python.org/pipermail/python-dev/2005-September/056125.html>`__
- `Pascaloid print substitute (Replacement for print in Python 3.0) =20
<http://mail.python.org/pipermail/python-dev/2005-September/=20
056171.html>`__

----------------------------------
Making C code easier in Python 3.0
----------------------------------

Nick Jacobson asked whether reference counting would be replaced in =20
Python 3.0.  Guido pointed out that the (CPython) implementation =20
would have to be completely changed, and that isn't planned; many =20
people also pointed out that reference counting is an implementation =20
detail, not part of the language specification, and that there are =20
other options that can be explored (e.g. `PyPy`_, `Jython`_, =20
`IronPython`_).

Arising from this question was a suggestion from Greg Ewing to build =20
something akin to `Pyrex`_ (which takes care of reference count/=20
garbage collection issues automatically) into the standard Python =20
distribution.  This suggestion was met with general enthusiasm; some =20
general discussion about which cases were most appropriate for Pyrex =20
use (e.g. extension modules, wrapping C libraries, modules =20
implemented in C for performance reasons) also followed.

... _PyPy: http://codespeak.net/pypy/
... _Jython: http://www.jython.org/
... _IronPython: http://www.ironpython.com/
... _Pyrex: http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/

[TAM]

Contributing thread:

- `reference counting in Py3K <http://mail.python.org/pipermail/=20
python-dev/2005-September/056215.html>`__

--------------------------
Multiple views of a string
--------------------------

Tim Delaney suggested that str.partition could return 'views' of a =20
string, rather than new string objects, as the substrings, to avoid =20
the time needed to create strings that are potentially unused.  =20
Raymond Hettinger pointed out that the practical cost is unlikely to =20
be significant, as the strings are likely to be empty, small, or =20
used, and that all the pre-Python 2.5 methods would still be =20
available for those times when they would be more appropriate.

However, using string 'views' (objects that reference the 'parent' =20
string, rather than copying the data) caught the imagination of =20
several Python-dev'ers.  Discussion ensued about how this object =20
could work (Skip Montanaro threw together a sample implementation); =20
towards the end it was pointed out that buffer() objects, with some =20
additional string methods, could provide this slice-like instance =20
with low memory requirements.  Guido also mentioned `NSString`_, the =20
NextStep string type used by `ObjC`_, which is fairly similar.

... _ObjC: http://en.wikipedia.org/wiki/Objc
... _NSString: http://developer.apple.com/documentation/Cocoa/=20
Reference/Foundation/ObjC_classic/Classes/NSString.html

[TAM]

Contributing threads:

- `Proof of the pudding: str.partition() <http://mail.python.org/=20
pipermail/python-dev/2005-September/055924.html>`__
- `String views (was: Re: Proof of the pudding: str.partition()) =20
<http://mail.python.org/pipermail/python-dev/2005-September/=20
055933.html>`__
- `String views <http://mail.python.org/pipermail/python-dev/2005-=20
September/055947.html>`__

-------------------------------
String-formatting in Python 3.0
-------------------------------

Currently, using ``%`` for string formatting has a number of =20
inconvenient consequences:

* precedence issues: ``"a%sa" % "b"*4`` produces ``'abaabaabaaba'``, =20
not ``'abbbba'``
* special-cased tuples: ``"%s" % x`` produces a string representation =20=

of x *unless* x is a tuple (in which case it unpacks it, raising a =20
TypeError if ``len(x) !=3D 1``).
* keyword formatting issues: a number of people have complained that =20
``%(myvar)s`` is much more complicated than it needs to be (hence =20
string.Template's ``$myvar``).

To address the first two issues, Raymond Hettinger proposed that =20
string formatting become a builtin function, and others proposed that =20=

formatting become a method of str/unicode objects.  Guido definitely =20
agreed with the move from ``%`` to a callable, but it was unclear as =20
to his preference for function or method.

Nick Coghlan tried to address the ``%(myvar)s`` issue by exploring a =20
few extensions to string.Template formatting.  He produced a format() =20=

function where arguments could be specified either by position (e.g. =20
$1, $2, etc.) or with keywords (e.g. $item, $quantity), and where the =20=

usual C-style format specifiers were still supported::

     format("$item: $[0.2f]quantity", quantity=3D0.5, item=3D'Bees')
     format("$1: $[0.2f]2", 'Bees', 0.5)

Nick also briefly explored format specifiers for expanding iterables, =20=

but Guido disliked the idea, explaining that adding or removing a =20
print from a program should not drastically change the program's =20
behavior (as it might if a print accidentally consumed an iterable =20
that you weren't done with).

There was also some high-level discussion about internationalization =20
concerns, where format strings need to be easy for translators to =20
read and reorganize.  Since word orders may change, having either =20
keyword parameters or positional parameters (as in Nick's scheme) is =20
crucial.

Unfortunately, this discussion seemed to get lost in the massive =20
`Converting print to a function in Python 3.0`_ discussion, and no =20
decisions were made about either a formatting function or Nick's =20
format specifier extensions.

[SJB]

Contributing threads:

- `Replacement for print in Python 3.0 <http://mail.python.org/=20
pipermail/python-dev/2005-September/055979.html>`__
- `string formatting options and removing basestring.__mod__ (WAS: =20
Replacement for print in Python 3.0) <http://mail.python.org/=20
pipermail/python-dev/2005-September/056163.html>`__
- `string formatting and i18n <http://mail.python.org/pipermail/=20
python-dev/2005-September/056191.html>`__
- `string.Template format enhancements (Re: Replacement for print in =20
Python 3.0) <http://mail.python.org/pipermail/python-dev/2005-=20
September/056231.html>`__


---------------------------------------------------------
Deriving file-like object methods from read() and write()
---------------------------------------------------------

A variety of methods on the file object, including  __iter__(), next=20
(), readline(), readlines() and writelines(), are all derivable from =20
the read() and write() methods. At least twice this fortnight, the =20
issue was raised about making it easier for file-like objects to add =20
the derivable methods if they've defined read() and write().

One suggestion was to provide a FileMixin class (like the DictMixin =20
of UserDict) that other types could inherit from. This has the =20
problem that the creator of the file-like object must determine at =20
the time that the class is defined that it should support the =20
additional methods. It is also more difficult to use mixin classes in =20=

C code (because multiple inheritance requires dealing with the type's =20=

metaclass).

Fredrik Lundh suggested that something along the lines of `PEP =20
246`_'s object adaptation might be appropriate, but there was still =20
some disagreement on the issue.

[SJB]

... _PEP 246: http://www.python.org/peps/pep-0246.html

Contributing threads:

- `Mixin classes in the standard library <http://mail.python.org/=20
pipermail/python-dev/2005-September/056135.html>`__
- `Simplify the file-like-object interface (Replacement for print in =20
Python 3.0) <http://mail.python.org/pipermail/python-dev/2005-=20
September/056218.html>`__
- `Simplify the file-like-object interface <http://mail.python.org/=20
pipermail/python-dev/2005-September/056229.html>`__

------------------------------------
Making new-style classes the default
------------------------------------

Lisandro Dalcin proposed that something like::

     from __future__ import new_style_classes

be introduced to have newly defined classes implicitly derive from =20
object. It was pointed out that this functionality is already =20
available through the module-level statement::

     __metaclass__ =3D type

The argument was made that the __future__ version would be easier for =20=

non-experts to understand and to Google for, but Guido declared that =20
the current syntax is fine -- there are much more important issues to =20=

be dealt with right now.

[SJB]

Contributing thread:

- `PEP 3000 and new style classes <http://mail.python.org/pipermail/=20
python-dev/2005-September/056305.html>`__

--------------------------------------------------
Using __future__ to have builtins return iterators
--------------------------------------------------

Lisandro Dalcin requested a __future__ import of some sort that would

* make range() and zip() return iterators
* remove xrange()
* make the dict.keys(), dict.values(), dict.items() etc. methods =20
return iterators

Guido indicated that an alternate builtins module could be provided =20
so that the first point could be covered with something like::

     from future_builtins import zip, range

However, there wasn't really a good way to change the dict methods.  =20
Simply importing a new dict object from "future_builtins" wouldn't =20
solve the problem because using anyone's module that used the old =20
dict object would mean a mix of the two types in your module.  And =20
since __future__ imports are intended to affect only the module which =20=

includes them, changing the builtin dict object globally would be =20
inappropriate (as it would let an import in one module break code in =20
another).

[SJB]

Contributing thread:

- `PEP 3000 and iterators <http://mail.python.org/pipermail/python-=20
dev/2005-September/056340.html>`__

-------------------------------------------------------------
Using compiled re methods vs. using module-level re functions
-------------------------------------------------------------

After Michael Chermside commented that users should be encouraged to =20
use the methods on compiled re objects instead of the re functions =20
available at the module level (and after Stephen J. Turnbull promised =20=

to look into supplying such a documentation patch), there was a brief =20=

discussion about how much of a difference using the compiled re =20
objects really makes. As it turns out, in the CPython implementation, =20=

the module-level functions cache the first 100 patterns, so in many =20
cases, the only additional cost of using the module-level functions =20
is a dictionary lookup.

[SJB]

Contributing thread:

- `Revising RE docs <http://mail.python.org/pipermail/python-dev/2005-=20=

September/055938.html>`__

--------------------------------------
urlparse and urls with too many '../'s
--------------------------------------

Fabien Schwob pointed out that urlparse.join() doesn't strip out any =20
extraneous '..' directories (e.g. http://example.com/../index.html).  =20=

While Guido indicated that he found the current behaviour acceptable, =20=

Jeff Epler pointed out that `RFC 2396`_ states that invalid URIs like =20=

this may be handled by removing the ".." segments from the resolved =20
path (although this is an implementation detail).  Armin Rigo =20
indicated that, even if this is theoretically not a bug, a proposed =20
patch with this motiviation would be welcome.

... _RFC 2396: http://www.faqs.org/rfcs/rfc2396.html

[TAM]

Contributing thread:

- `bug in urlparse <http://mail.python.org/pipermail/python-dev/2005-=20
September/056144.html>`__

-----------------------------------------------
Using an iterator instead of a tuple for \*args
-----------------------------------------------

Nick Coghlan suggested that in Python 3.0, the \*args extended =20
function call syntax should produce an iterator instead of a tuple as =20=

it currently does.  That would mean that code like::

     output(*some_long_iterator)

would not load the entire iterator into a memory before processing =20
it.  I pointed him to a previous discussion Raymond Hettinger and I =20
had about the subject that indicated that for \*args, sequences were =20
preferable to iterators in a number of situations.  Guido agreed, =20
indicating that \*args will continue to be sequences in Python 3.0.

[SJB]

Contributing thread:

- `iterators and extended function call syntax (WAS: Replacement for =20
print in Python 3.0) <http://mail.python.org/pipermail/python-dev/=20
2005-September/056109.html>`__

----------------------------------------
Constructing traceback objects in Python
----------------------------------------

Contributing thread:

- `Asynchronous use of Traceback objects <http://mail.python.org/=20
pipermail/python-dev/2005-September/056091.html>`__

-------------------------------
No dedent() methods for strings
-------------------------------

Contributing thread:

- `str.dedent <http://mail.python.org/pipermail/python-dev/2005-=20
September/056412.html>`__

------------------------
Arguments vs. parameters
------------------------

- `Term unification <http://mail.python.org/pipermail/python-dev/2005-=20=

September/056409.html>`__

-----------------------------------------------------------------------
Removing sequence support from the return value of stat() in Python 3.0
-----------------------------------------------------------------------

Terry J. Reedy proposed that, in Python 3.0, instead of os.stat() =20
returning a sequence (where the order of the items is only of =20
historical significance), a proper stat object be returned.  This was =20=

met with general support, and so seems likely to occur.  Skip =20
Montanaro also proposed that the st_ prefixes in the attribute names =20
be removed, since there are no namespace issues to be concerned with, =20=

which met with some approval, but concern from Guido that the forms =20
with the prefixes would be more familiar to users, and make Googling =20
or grepping simpler.

[TAM]

Contributing thread:

- `stat() return value (was: Re: Proof of the pudding: str.partition=20
()) <http://mail.python.org/pipermail/python-dev/2005-September/=20
055931.html>`__

--------------------------------------------------
Making code in the Tools directory more accessible
--------------------------------------------------

Installation of Python typically doesn't include the Tools directory; =20=

combined with the lack of mention of these scripts in the =20
documentation, this means that knowledge of these generally useful =20
scripts is fairly limited.  Tim Peters noted that historically a =20
Tools directory was only added to the Windows installer if it was =20
specifically requested; as such, the audiopy, bgen, compiler, faqwiz, =20=

framer, modulator, msi, unicode, and world Tools directories are not =20
currently included in the Windows installer.  Nick Coghlan added that =20=

Tools/README.txt isn't included in the Windows installer, so Windows =20
users don't get a synopsis of the tools that are included; he also =20
suggested that adding this readme to the "undocumented modules" =20
section of the standard library would be a simple improvement.  Non-=20
windows users typically don't get the Tools directory at all with an =20
install.

Remaining questions included how the directory should be documented =20
(e.g. man pages for the scripts, a documentation page for them), =20
where to install them on non-Windows installations (e.g. /usr/share/=20
python, /usr/lib/pythonX.Y/Tools), and whether the Windows installer =20
should include all of the directories.

[TAM]

Contributing thread:

- `Tools directory (Was RE: Replacement for print in Python 3.0) =20
<http://mail.python.org/pipermail/python-dev/2005-September/=20
056318.html>`__

----------------------------------
Responsiveness of IDLE development
----------------------------------

Noam Raphael posted a request for help getting a large patch to IDLE =20
committed to CVS.  He was concerned that there hasn't been any IDLE =20
development recently, and that patches are not being considered.  He =20
indicated that his group was considering offering a fork of IDLE with =20=

the improvements, but that they would much prefer integrating the =20
improvements into the core distribution.

It was pointed out that a fork might be the best solution, for =20
various reasons (e.g. the improvements may not be of general =20
interest, the release time would be much quicker), and that this was =20
how the current version of IDLE was developed.  However, later on it =20
turned out that Kurt Kaiser had missed the python-dev message, and =20
when it was brought to his attention he moved the discussion to idle-=20
dev, and it seems that everything will end happily and fork-less.

[TAM]

Contributing thread:

- `IDLE development <http://mail.python.org/pipermail/python-dev/2005-=20=

September/056357.html>`__

-----------------------------
Speeding up list append calls
-----------------------------

A `comp.lang.python message from Tim Peters`_ prompted Neal Norwitz =20
to investigate how the code that Tim posted could be sped up.  He =20
hacked the code to replace var.append() with the LIST_APPEND opcode, =20
and achieved a roughly 200% speed increase.  Although this doesn't =20
work in general, Neal wondered if it could be used as a peephole =20
optimization when a variable is known to be a list.  Martin v. L=88wis =20=

suggested that the code could simply check whether it was a list; =20
Phillip J. Eby and Fredrik Lundh pointed out that this is similar to =20
what various math operators do (e.g. speeding up int + int calls).

... _comp.lang.python message from Tim Peters: http://=20
groups.google.com/group/comp.lang.python/msg/9075a3bc59c334c9

[TAM]

Contributing thread:

- `speeding up list append calls <http://mail.python.org/pipermail/=20
python-dev/2005-September/056396.html>`__

------------------------------------
Allowing str.strip to remove "words"
------------------------------------

Jonny Reichwald proposed an enhancement to str.strip().  In addition =20
to its current form, where it takes a string of characters to strip, =20
to take any iterable containing either character lists or string =20
lists, so that is is possible to remove entire words from the =20
stripped string.  For example::

    #A char list gives the same result as the standard strip
    >>> my_strip("abcdeed", "de")
    'abc'

    #A list of strings instead
    >>> my_strip("abcdeed", ("ed",))
    'abcde'

    #The char order in the strings to be stripped are of importance
    >>> my_strip("abcdeed", ("ad", "eb"))
    'abcdeed'

Raymond Hettinger queried whether there was actual demand for such a =20
change, and whether such demand was sufficient to justify the added =20
complexity; Josiah Carlson also pointed out that implementing this =20
only requires a four-line function.  Judging from the lack of =20
responses, it seems likely that there isn't enough demand.

Contributing thread:

- `str.strip() enhancement <http://mail.python.org/pipermail/python-=20
dev/2005-September/056119.html>`__

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Deferred Threads
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

- `C coding experiment <http://mail.python.org/pipermail/python-dev/=20
2005-September/055965.html>`__
- `os.path.diff(path1, path2) <http://mail.python.org/pipermail/=20
python-dev/2005-September/056391.html>`__


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Skipped Threads
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

- `import exceptions <http://mail.python.org/pipermail/python-dev/=20
2005-September/055926.html>`__
- `[Python-checkins] python/dist/src/Lib/test test_re.py, 1.45.6.3, =20
1.45.6.4 <http://mail.python.org/pipermail/python-dev/2005-September/=20
055927.html>`__
- `setdefault's second argument <http://mail.python.org/pipermail/=20
python-dev/2005-September/055929.html>`__
- `Alternative imports (Re: Python 3 design principles) <http://=20
mail.python.org/pipermail/python-dev/2005-September/055945.html>`__
- `python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4 <http://=20
mail.python.org/pipermail/python-dev/2005-September/055963.html>`__
- `Status of PEP 328 <http://mail.python.org/pipermail/python-dev/=20
2005-September/055969.html>`__
- `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/=20
python-dev/2005-September/055978.html>`__
- `itertools.chain should take an iterable ? <http://mail.python.org/=20
pipermail/python-dev/2005-September/055981.html>`__
- `partition() (was: Remove str.find in 3.0?) <http://mail.python.org/=20=

pipermail/python-dev/2005-September/055983.html>`__
- `gdbinit problem <http://mail.python.org/pipermail/python-dev/2005-=20
September/056178.html>`__
- `Exception Reorg PEP checked in <http://mail.python.org/pipermail/=20
python-dev/2005-September/056296.html>`__
- `international python <http://mail.python.org/pipermail/python-dev/=20
2005-September/056326.html>`__
- `SIGPIPE =3D&gt; SIG_IGN? <http://mail.python.org/pipermail/python-=20
dev/2005-September/056341.html>`__
- `[draft] python-dev Summary for 2005-08-16 through 2005-08-31 =20
<http://mail.python.org/pipermail/python-dev/2005-September/=20
056348.html>`__
- `[Python-checkins] python/dist/src/Lib urllib.py, 1.169, 1.170 =20
<http://mail.python.org/pipermail/python-dev/2005-September/=20
056349.html>`__
- `Wanting to learn <http://mail.python.org/pipermail/python-dev/2005-=20=

September/056350.html>`__
- `Python code.interact() and UTF-8 locale <http://mail.python.org/=20
pipermail/python-dev/2005-September/056361.html>`__
- `pygettext() without newlines (Was: Re: Replacement for print in =20
Python 3.0) <http://mail.python.org/pipermail/python-dev/2005-=20
September/056368.html>`__
- `Python 3 executable name (was: Re: PEP 3000 and iterators) <http://=20=

mail.python.org/pipermail/python-dev/2005-September/056369.html>`__
- `Python 3 executable name <http://mail.python.org/pipermail/python-=20
dev/2005-September/056371.html>`__
- `Skiping searching throw dictionaries of mro() members. <http://=20
mail.python.org/pipermail/python-dev/2005-September/056403.html>`__
- `Fwd: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.94, =20
1.1193.2.95 <http://mail.python.org/pipermail/python-dev/2005-=20
September/056405.html>`__
- `[Python-checkins] python/dist/src/Lib/test regrtest.py, 1.171, =20
1.172 test_ioctl.py, 1.2, 1.3 <http://mail.python.org/pipermail/=20
python-dev/2005-September/056406.html>`__
- `python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2 <http://=20
mail.python.org/pipermail/python-dev/2005-September/056419.html>`__
- `Variant of removing GIL. <http://mail.python.org/pipermail/python-=20
dev/2005-September/056423.html>`__
- `Compatibility between Python 2.3.x and Python 2.4.x <http://=20
mail.python.org/pipermail/python-dev/2005-September/056431.html>`__
- `Example for "property" violates "Python is not a one pass =20
compiler" <http://mail.python.org/pipermail/python-dev/2005-September/=20=

056190.html>`__
- `python optimization <http://mail.python.org/pipermail/python-dev/=20
2005-September/056425.html>`__




=3D=3D=3D=3D=3D=3D=3D=3D
Epilogue
=3D=3D=3D=3D=3D=3D=3D=3D

This is a summary of traffic on the `python-dev mailing list`_ from
September 01, 2005 through September 15, 2005.
It is intended to inform the wider Python community of on-going
developments on the list on a semi-monthly basis.  An archive_ of
previous summaries is available online.

An `RSS feed`_ of the titles of the summaries is available.
You can also watch comp.lang.python or comp.lang.python.announce for
new summaries (or through their email gateways of python-list or
python-announce, respectively, as found at http://mail.python.org).

This is the 3rd summary written by the python-dev summary pairing of
Steve Bethard and Tony Meyer (Tempus Fugit!).

To contact us, please send email:

- Steve Bethard (steven.bethard at gmail.com)
- Tony Meyer (tony.meyer at gmail.com)

Do *not* post to comp.lang.python if you wish to reach us.

The `Python Software Foundation`_ is the non-profit organization that
holds the intellectual property for Python.  It also tries to advance
the development and use of Python.  If you find the python-dev Summary
helpful please consider making a donation.  You can make a donation at
http://python.org/psf/donations.html .  Every penny helps so even a
small donation with a credit card, check, or by PayPal helps.


--------------------
Commenting on Topics
--------------------

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`_!


-------------------------
How to Read the Summaries
-------------------------

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 for 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.

Please note that this summary is written using reStructuredText_.
Any unfamiliar punctuation is probably markup for reST_ (otherwise it
is probably regular expression syntax or a typo =3D); you can safely
ignore it.  We do suggest learning reST, though; it's simple and is
accepted for `PEP markup`_ and can be turned into many different
formats like HTML and LaTeX.  Unfortunately, even though reST is
standardized, the wonders of programs that like to reformat text do
not allow us to 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`_.

... _python-dev: http://www.python.org/dev/
... _SourceForge: http://sourceforge.net/tracker/?group_id=3D5470
... _python-dev mailing list: http://mail.python.org/mailman/listinfo/=20
python-dev
... _c.l.py:
... _comp.lang.python: http://groups.google.com/groups?q=3Dcomp.lang.python=

... _PEP Markup: http://www.python.org/peps/pep-0012.html

... _Docutils: http://docutils.sf.net/
... _reST:
... _reStructuredText: http://docutils.sf.net/rst.html
... _PSF:
... _Python Software Foundation: http://python.org/psf/

... _last summary: http://www.python.org/dev/summary/=20
2005-07-16_2005-07-31.html
... _original text file: http://www.python.org/dev/summary/=20
2005-09-01_2005-09-15.ht
... _archive: http://www.python.org/dev/summary/
... _RSS feed: http://www.python.org/dev/summary/channews.rdf


0
Tony
11/17/2005 12:05:12 AM
comp.lang.python.announce 7374 articles. 0 followers. Post Follow

0 Replies
396 Views

Similar Articles

[PageSpeed] 39

Reply:

Similar Artilces:

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 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 ...

python-dev Summary for 2005-06-01 through 2005-06-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-06-01_2005-06-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 --------------------------------- Bug Day: Saturday, June 25th 2005 --------------------------------- AMK organized another `Python Bug Day`_ on Saturday, June 25th. Hope you got a chance to help out! ... _Python Bug Day: http://wiki.python.org/moin/PythonBugDay Contributing Threads: - `Bug day on the 25th? <http://mail.python.org/pipermail/python-dev/2005-June/054126.html>`__ [SJB] ---------------------- FishEye for Python CVS ---------------------- Peter Moore has kindly set up `Fish Eye for the Python CVS repository`_. FishEye is a repository browsing, searching, analysis and monitoring tool, with great features like RSS feeds, Synthetic changesets, Pretty ediffs and SQL like searches. Check it out! ... _Fish Eye for the Python CVS repository: http://fisheye.cenqua.com/viewrep/python/ Contributing Threads: - `FishEye on Python CVS Repository <http://mail.python.org/pipermail/python-dev/2005-June/054127.html>`__ [SJB] -------------------------------- PyPy Sprint: July 1st - 7th 2005 -------------------------------- The next `PyPy`_ sprint is scheduled right after EuroPython 2005 in Gothenborg, Sweden. It will focus mainly on translating P...

python-dev Summary for 2005-12-01 through 2005-12-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-12-01_2005-12-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 ----------------------------------------------------- Reminder: plain text documentation fixes are accepted ----------------------------------------------------- Want to help out with the Python documentation? Don't know LaTeX? No problem! Plain text or ReST fixes are also welcome. You won't be able to produce a diff file like with a normal patch, but comments that explain how to fix the docs are just as good. A form like "in section XXX right before the paragraph starting with YYY, the documentation should say ZZZ" will make it easy for the doc maintainers to apply your fix. Contributing thread: - `c.l.p post on docs <http://mail.python.org/pipermail/python-dev/2005-December/058479.html>`__ [SJB] -------------------------------------------- New-style exceptions patch requesting review -------------------------------------------- With `PEP 352`_ ready_ for Guido's pronouncement, Michael Hudson has asked for a few more developers to review his patch_ to make all exceptions new-style. It should be basically ready, but it would be nice to have a few eyes for sanity checks, documentation, and compilations on the various platforms. ... _PEP 352: http://www.python.org/peps/pep-0352.html ... _ready: htt...

python-dev summary for 2005-07-01 to 2005-07-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-07-01_2005-07-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 (Quotes of the Fortnight) ------------------------------ Marc-Andre Lemburg provides perhaps the best summary to date of `how strings and Unicode should be used`_ in Python: To untie this Gordian Knot, we should use strings and Unicode like they are supposed to be used (in the context of text data): * strings are fine for text data that is encoded using the default encod= ing * Unicode should be used for all text data that is not or cannot be encoded in the default encoding Later on in Py3k, all text data should be stored in Unicode and all binary data in some new binary type. On a more entertaining note, Anthony Baxter describes the general outlook outlook on handling `threads vs signals`_: threads vs signals is a platform-dependant trail of misery, despair, horror and madness ... _how strings and Unicode should be used: http://mail.python.org/pipermail/python-dev/2005-July/054854.html ... _threads vs signals: http://mail.python.org/pipermail/python-dev/2005-July/054832.html =3D=3D=3D=3D=3D=3D=3D=3D=3D Summaries =3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------------------------- PEP 343 Documentation: Context Managers --------------------------------------- Raymo...

python-dev summary for 2005-07-01 to 2005-07-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-07-01_2005-07-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 (Quotes of the Fortnight) ------------------------------ Marc-Andre Lemburg provides perhaps the best summary to date of `how strings and Unicode should be used`_ in Python: To untie this Gordian Knot, we should use strings and Unicode like they are supposed to be used (in the context of text data): * strings are fine for text data that is encod...

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

python-dev Summary for 2005-04-01 through 2005-04-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-04-01_2005-04-15.html] =3D=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=3D --------------------------- New python-dev summary team --------------------------- This summary marks the first by the team of Steve Bethard, Tim Lesher, and Tony Meyer. We're trying a collaborative approach to the summaries: each fortnight, we'll be getting together in a virtual smoke-filled back room to divide up ...

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 2005-06-01 through 2005-06-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-06-01_2005-06-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 --------------------------------- Bug Day: Saturday, June 25th 2005 --------------------------------- AMK organized another `Python Bug Day`_ on Saturday, June 25th. Hope you got a chance to help out! ... _Python Bug Day: http://wiki.python.org/moin/PythonBugDay Contributing Threads: - `Bug day on the 25th? <http://mail.python....

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`_...

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 don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the twenty-fifth summary written by Brett Cannon (with school looming on the horizon). All summaries are archived at 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...

python-dev Summary for 2004-09-01 through 2004-09-15
python-dev Summary for 2004-09-01 through 2004-09-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from September 01, 2004 through September 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-eighth summary written by Brett Cannon (hopefully school won't drown my this quarter). 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 HT...

python-dev Summary for 2006-09-01 through 2006-09-15
python-dev Summary for 2006-09-01 through 2006-09-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ ... contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-09-01_2006-09-15] ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Through a cross-posting slip-up, Jean-Paul Calderone managed to provide us with some inspiring thoughts on mailing-list archives: One could just as easily ask why no one bothers to read mailing list archives to see if their question has been answered before. No one will ever know, it is just one of the mysteries of the universe. Contributing thread: - `[Twisted-Python] Newbie question <http://mail.python.org/pipermail/python-dev/2006-September/068682.html>`__ ------------------------- Monthly Arlington sprints ------------------------- Jeffrey Elkner has arranged for monthly Arlington Python sprints. See the `Arlington sprint wiki`_ for more details. ... _Arlington sprint wiki: http://wiki.python.org/moin/ArlingtonSprint Contributing thread: - `Arlington sprints to occur monthly <http://mail.python.org/pipermail/python-dev/2006-September/068688.html>`__ ========= Summaries ========= ----------------------------------------- Signals, threads and blocking C functions ----------------------------------------- Gustavo Carneiro explained a ...

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...

python-dev Summary for 2006-09-01 through 2006-09-15
python-dev Summary for 2006-09-01 through 2006-09-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ ... contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-09-01_2006-09-15] ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Through a cross-posting slip-up, Jean-Paul Calderone managed to provide us with some inspiring thoughts on mailing-list archives: One could just as easily ask why no one bothers to read mailing list archives to see if their que...

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 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.p...

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 int...

python-dev Summary for 2005-12-01 through 2005-12-15
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-12-01_2005-12-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 ----------------------------------------------------- Reminder: plain text documentation fixes are accepted ----------------------------------------------------- Want to help out with the Python documentation? Don't know LaTeX? No problem! Plain text or ReST fixes are also welcome. You won't be able to produce a diff file like with a normal patch, but comments that explain how t...

python-dev Summary for 2005-01-16 through 2005-01-31
===================== Summary Announcements ===================== ----------------------------------------- School sure likes to destroy my free time ----------------------------------------- A month late, that much closer to having this hectic quarter being over. Sorry for being so delinquent with this summary but school has kept me busy and obviously the Real World has to take precedence over volunteer work. Now if I could only get paid for doing this... =) And if you hate the summaries being late, you could do it yourself. This is not meant to be a flippant comment! I am always willing to hand over development of the summaries to anyone who is willing to do a comparable job. If you are interested feel free to email me. I have now made this a permanent offer in the header in case someone comes along later and decides they want to do this. ---------------------- RSS feed now available ---------------------- Thanks entirely to one of my predecessors, A.M. Kuchling, the python-dev Summaries are available as an `RSS feed`_. The feed contains the titles of every summary and so will be updated with the newest summaries as soon as they are posted online. A full text feed will eventually be available. ---------- New format ---------- I have done a thorough restructuring of the boilerplate and the Summary Announcements section for the Summaries. The purpose of this is to make finding information in the boilerplate mu...

python-dev Summary for 2005-01-16 through 2005-01-31
===================== Summary Announcements ===================== ----------------------------------------- School sure likes to destroy my free time ----------------------------------------- A month late, that much closer to having this hectic quarter being over. Sorry for being so delinquent with this summary but school has kept me busy and obviously the Real World has to take precedence over volunteer work. Now if I could only get paid for doing this... =) And if you hate the summaries being late, you could do it yourself. This is not meant to be a flippant comment! I am always w...

Web resources about - python-dev Summary for 2005-09-01 to 2005-09-15 - comp.lang.python.announce

Resources last updated: 3/3/2016 9:07:18 PM