[Python-Dev] python-dev Summary for 2004-08-01 through 2004-08-15
[draft]
Brett C.
bac at OCF.Berkeley.EDU
Thu Aug 19 09:02:07 CEST 2004
Well, after reading 1,289 emails for this summary I finally finished it.
As you will notice in the Summary Announcements I have my yearly stats
on the list since this summary marks the end of year two for me doing
this. As I did last year, the position is available to anyone who wants
it and can do a comparable job.
Also notice that in the Summary Announcements I am asking for people to
vote on one of two ways I am going to cut back on the amount of time the
Summaries take up of my time. If you actually read the summaries then
do let me know since votes from regular python-dev'ers will count for
more than from the general Python community.
I don't plan to send this summary out any sooner than Sunday night so
you have at least until then to send me corrections. I am burned out
enough at the moment that I doubt I will hit that date, though.
Also, I doubt I covered anything new in my decorators summary, but if I
did let me know and I will make sure to plug it into the PEP or wiki if
needed.
---------
=====================
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. I know it greatly
accelerated my understanding of both Python as a language and of its
implementation.
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 over the
past year (this month has already been the busiest month with 1,289
emails 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.
========
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?
<>`__
----------------------------------------
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
< .
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
<>`__
------------------------------------------------------
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
<>`__
- `PEP 0008 confusion - here it is, but don't use it?
<>`__
------------------------------------------------------------------------------
`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)
<>`__
----------------------------------------------------------------------
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
<>`__
- `RELEASED Python 2.4, alpha 2
<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
>`__
--------------------------------------
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
<>`__
---------------------------------------
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
<>`__
-----------------------------------------
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
<>`__
------------------------------------
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.
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
<>`__
---------------------------------
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
<>`__
----------------------------------------------------------
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://www.python.org/peps/pep-0237.html
Contributing threads:
- `Unifying Long Integers and Integers: baseint
<>`__
-----------------------------
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
<>`__
----------------------------------------------------------
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
<>`__
-----------------------------------------------------------------------------------
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
<>`__
- `Multi-line import implementation (second part)
<>`__
------------------------------------------------
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?
<>`__
----------------------------------------------
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://www.python.org./peps/pep-0318.html
.. _PythonDecorators:
http://leo.sourceforge.net/
.. _IPython: http://ipython.scipy.org/
Contributing threads (sans emails that were warnocked):
- `2.4a2, and @decorators
<>`__
- `Call for defense of @decorators
<>`__
- `About pep 318--Intro
<>`__
- `A usability argument for list-after-def
<>`__
- `Similar syntax
<>`__
- `pep 318, Decorators for Functions, Methods and Classes
<>`__
- `elements of decorator syntax suggestions
<>`__
- `IPython, @, and option E from the wiki
<>`__
- `Suggesting '.' decorators (PEP318)
<>`__
- `request: add keywords for static and class methods only
<>`__
- `Semantics of decorators?
<>`__
- `Another approach to decorators.
<>`__
- `def ... decorate
<>`__
- `Decorators and docstrings
<>`__
- `More concerns about decorators
<[Python-Dev] PEP 318: Can't we all just get along?
Next message: [Python-Dev] python-dev Summary for 2004-08-01 through 2004-08-15
[draft]
Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Python-Dev
mailing list