Re: [Python-Dev] python sendmsg()/recvmsg() implementation
Done, it's at: http://bugs.python.org/issue6560 Kalman Gergely Aahz wrote: On Thu, Jul 23, 2009, K?lm?n Gergely wrote: This is the rewritten-from-scratch implementation of the sendmsg()/recvmsg() methods. Any comments / suggestions / flames are very welcome. Currently it supports what I need and I'm only releasing it, because I don't have much time to develop it further in the forseeable future (1-2 months). It is rewritten from scratch, using the python c-api documents. I've tried my best, but I wouldn't bet that it works as it's supposed to. I'd be glad if someone could give me a review on what I've done wrong. Please post this to bugs.python.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Christian Tismer wrote:
Hi all,
I was hacking to get mingw32 builds of psyco to work
and found a pretty weird thing:
I used mingw32 (stable distro) to build the psyco extension
on top of standard python2.6, built with Visual Studio,
and got weird crashes.
The reason is in objimpl.h:
typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy; /* force worst-case alignment */
} PyGC_Head;
[SNIP]
Did the crash disappear is you add "__attribute__((aligned(8)))" after
variable dummy ?
Regards,
Roumen
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Antoine Pitrou wrote: Christian Tismer stackless.com> writes: Well, I doubt that a 12 byte long double causes any other alignment but 4. In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). And alignment is ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Roumen Petrov roumenpetrov.info> writes: > > Antoine Pitrou wrote: > > > > In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). > > And alignment is ? 16 bytes as well. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Antoine Pitrou pitrou.net> writes: > > Roumen Petrov roumenpetrov.info> writes: > > > > Antoine Pitrou wrote: > > > > > > In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes > > > (!!). > > > > And alignment is ? > > 16 bytes as well. This is probably why, by the way, a PyGC_Head takes only 12 bytes in 32-bit mode, but 32 bytes in 64-bit mode. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Antoine Pitrou wrote: Antoine Pitrou pitrou.net> writes: Roumen Petrov roumenpetrov.info> writes: Antoine Pitrou wrote: In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). And alignment is ? 16 bytes as well. This is probably why, by the way, a PyGC_Head takes only 12 bytes in 32-bit mode, but 32 bytes in 64-bit mode. yes, 10x Roumen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] REVIEW: PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail string.
On Thu, Jul 23, 2009, Sean Reifschneider wrote: > > Thoughts? Please file a report at bugs.python.org to make sure it doesn't get lost. -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "At Resolver we've found it useful to short-circuit any doubt and just refer to comments in code as 'lies'. :-)" --Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] command line attachable debugger
On Jul 24, 2009, at 1:31 AM, Edward Peschko wrote: all, I'I was wondering if there was a command line python debugger that was able to attach to an existing process. I'd very much like to be able to debug over a ssh session using screen. Ed (ps - and yes, I know about winpdb, etc... that is not exactly what I'm looking for..) Winpdb is *exactly* what you asked for, so if it's not what you're looking for you'll need to be more specific about what you want that it doesn't do... James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] command line attachable debugger
On Thu, Jul 23, 2009, Edward Peschko wrote: > > I'I was wondering if there was a command line python debugger that was > able to attach to an existing process. I'd very much like to be able > to debug over a ssh session using screen. python-dev is not the correct place to ask about this, please use comp.lang.python (python-dev is for questions about fixing bugs and adding features). -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "At Resolver we've found it useful to short-circuit any doubt and just refer to comments in code as 'lies'. :-)" --Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
David Lyon schrieb: > On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes > wrote: >> I'm sorry to inform you that a wxWindows based solution has zero change >> to get into the Python standard library ever. We are not going to add >> another GUI toolkit to the core distribution. > > In executable form, the Package Manager does not require wxWidgets > to be installed. > > There is no dependency for this to be installed. What does "in exectuable form" mean? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (07/17/09 - 07/24/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2278 open (+41) / 16106 closed (+16) / 18384 total (+57) Open issues with patches: 897 Average duration of open issues: 661 days. Median duration of open issues: 413 days. Open Issues Breakdown open 2245 (+41) pending33 ( +0) Issues Created Or Reopened (58) ___ warnings.warn segfaults on bad formatted string 07/18/09 CLOSED http://bugs.python.org/issue6415reopened r.david.murray patch lib2to3 fails to convert 'thread' when not followed by a period 07/17/09 CLOSED http://bugs.python.org/issue6506created ericp Enhance dis.dis to autocompile codestrings 07/17/09 http://bugs.python.org/issue6507created tjreedy expose setresuid 07/17/09 http://bugs.python.org/issue6508created solinym re.py - encounter unexpected 07/18/09 http://bugs.python.org/issue6509created kaizhu zipfile: OSError File exists 07/18/09 CLOSED http://bugs.python.org/issue6510created srid zipfile: Invalid argument when opening zero-sized files 07/18/09 http://bugs.python.org/issue6511created srid UnicodeDecodeError: 'utf8' codec can't decode bytes in position 07/18/09 CLOSED http://bugs.python.org/issue6512created wplappert Standard Library, Warnings, 28.5.4, example fails07/18/09 CLOSED http://bugs.python.org/issue6513created jasontiller "python -m unittest " does not run any tests 07/18/09 CLOSED http://bugs.python.org/issue6514created exarkun http://docs.python.org/dev/library/unittest.html#load-tests-prot 07/18/09 http://bugs.python.org/issue6515created exarkun reset owner/group to root for distutils tarballs 07/18/09 http://bugs.python.org/issue6516created till configparser: add possibility to escape formatstrings07/18/09 http://bugs.python.org/issue6517created till patch Enable 'with' statement in ossaudiodev module07/19/09 http://bugs.python.org/issue6518created jjalocha Reorder 'with' statement for files in Python Tutorial07/19/09 http://bugs.python.org/issue6519created jjalocha urllib.urlopen does not have timeout parameter where as urllib2. 07/19/09 http://bugs.python.org/issue6520created orsenthil easy Contradictory documentation for email.mime.text.MIMEText 07/19/09 http://bugs.python.org/issue6521created pitrou docs for unittest.expectedFailure do not syntactically show it's 07/20/09 http://bugs.python.org/issue6522created brett.cannon smtplib exception smtp.connect TypeError encode_plain07/20/09 http://bugs.python.org/issue6523created kmcguire
Re: [Python-Dev] Update to Python Documentation Website Request
2009/7/24 Georg Brandl : > David Lyon schrieb: >> On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes >> wrote: >>> I'm sorry to inform you that a wxWindows based solution has zero change >>> to get into the Python standard library ever. We are not going to add >>> another GUI toolkit to the core distribution. >> >> In executable form, the Package Manager does not require wxWidgets >> to be installed. >> >> There is no dependency for this to be installed. > > What does "in exectuable form" mean? I read this as meaning that David was proposing to ship a built application (on Windows, bundled up with something like py2exe, I guess) and any supporting DLLs such as the wxWindows ones would be bundled in, but the wxPython package would *not* be shipped as part of the standard library. If my assumption is right, that makes the package manager inappropriate for shipping with Python, whether or not there are other issues. In my view, for an "application" to be shipped with Python, whether it be Idle, or a package manager, or pydoc, or whatever, it must: - be written as a Python script - depend only on packages shipped with the standard library That is before any considerations of the value of the application itself. Given that David's package manager uses setuptools to do the installs (and now it appears it uses wxPython for its GUI) that immediately disqualifies it for inclusion in my view - regardless of its value as a package. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Document None values in sys.modules?
Still works, at least in some old 3.1 I had lying around: $ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.modules['string'] = None >>> import string Traceback (most recent call last): File "", line 1, in ImportError: No module named string >>> $ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> $ The experiment should be easily repeatable. :-) --Guido On Thu, Jul 23, 2009 at 8:35 PM, Brett Cannon wrote: > > > On Thu, Jul 23, 2009 at 20:18, Guido van Rossum wrote: >> >> So, I guess, we'll live with it for a while longer. Given that it >> managed to evade our attention for so long, I think that's fine. > > Can someone double-check me that the semantics can even be triggered in 3.1? > I just tried and couldn't come up with anything. Heck, I quick search for a > Py_None comparison in 3.1's import.c turned up nothing useful (other than > mark_miss() is the function used to set None in sys.modules). We might have > actually already removed it or made it so that the semantics can't be > triggered. > >> >> I agree that there's no reason for a None result from loaders to be >> interpreted the same way, assuming that's not how it works ATM. >> >> And we can live with import and importlib differing on this in 3.1 >> (though you could call it a bug in importlib and fix it for 3.1.1 -- >> not sure if you were planning on that). > > I can if people can trigger the semantics somehow so I have a test to go by. > -Brett > >> >> --Guido >> >> On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon wrote: >> > >> > >> > On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson >> > wrote: >> >> >> >> 2009/7/23 Brett Cannon : >> >> > >> >> > >> >> > On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson >> >> > >> >> > wrote: >> >> >> >> >> >> 2009/7/23 Brett Cannon : >> >> >> > None in Python 3.1 is really useless in terms of its semantics in >> >> >> > relative >> >> >> > imports; importlib doesn't support it and still passes as >> >> >> > __import__ >> >> >> > (at >> >> >> > least last time I ran the test suite that way). I thought we had >> >> >> > agreed >> >> >> > a >> >> >> > while back that supporting None was not warranted in Python 3.0? >> >> >> > Otherwise I >> >> >> > will do whatever work is necessary for this to happen. >> >> >> >> >> >> I think it's still nice for the rare cases where you need to trick a >> >> >> module into thinking another one doesn't exist. >> >> > >> >> > But None does not strictly mean "I don't exist". None is supposed to >> >> > trigger >> >> > an another import attempt for the module with a top-level name. It's >> >> > that >> >> > extra import trigger that has no real use in 3.0 and just complicates >> >> > import >> >> > semantics (IMO) needlessly. If you want a module to not exist then >> >> > you >> >> > either stick something else in (e.g. '42') or we remove the special >> >> > semantics for None (which I thought we had). >> >> >> >> >> >> I didn't realize None had other semantics attached to it. (Imagine >> >> that dealing with import!) +1 for making it simply indicate an >> >> ImportError. >> > >> > I'm +0 with having import raise ImportError if None is set in >> > sys.modules as >> > long as we don't suddenly expect loaders to trigger the same thing if >> > they >> > return None (actually, as of right now what loaders return count for >> > nothing, but just want to be clear). >> > -Brett >> >> >> >> -- >> --Guido van Rossum (home page: http://www.python.org/~guido/) > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Document None values in sys.modules?
On Fri, Jul 24, 2009 at 10:39, Guido van Rossum wrote: > Still works, at least in some old 3.1 I had lying around: > > $ python3.1 > Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) > [GCC 4.0.1 (Apple Inc. build 5465)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> sys.modules['string'] = None > >>> import string > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named string > >>> > $ python3.1 > Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) > [GCC 4.0.1 (Apple Inc. build 5465)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import string > >>> > $ > > The experiment should be easily repeatable. :-) > =) Yes, the None raising ImportError semantics can be added easily and codified as official import semantics in 3.1. I was talking about the "None triggers another import as with relative imports" semantics and if there was some rather convoluted way to trigger that. I am guessing not as that would require a value of -1 for level which is no longer valid. I will fix importlib in both 3.2 and 3.1.1. And speaking of fixing, should I put the failing test in now and decorate it with unittest.expectedFailure until I get around to fixing it? -Brett > > --Guido > > On Thu, Jul 23, 2009 at 8:35 PM, Brett Cannon wrote: > > > > > > On Thu, Jul 23, 2009 at 20:18, Guido van Rossum > wrote: > >> > >> So, I guess, we'll live with it for a while longer. Given that it > >> managed to evade our attention for so long, I think that's fine. > > > > Can someone double-check me that the semantics can even be triggered in > 3.1? > > I just tried and couldn't come up with anything. Heck, I quick search for > a > > Py_None comparison in 3.1's import.c turned up nothing useful (other than > > mark_miss() is the function used to set None in sys.modules). We might > have > > actually already removed it or made it so that the semantics can't be > > triggered. > > > >> > >> I agree that there's no reason for a None result from loaders to be > >> interpreted the same way, assuming that's not how it works ATM. > >> > >> And we can live with import and importlib differing on this in 3.1 > >> (though you could call it a bug in importlib and fix it for 3.1.1 -- > >> not sure if you were planning on that). > > > > I can if people can trigger the semantics somehow so I have a test to go > by. > > -Brett > > > >> > >> --Guido > >> > >> On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon wrote: > >> > > >> > > >> > On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson > > >> > wrote: > >> >> > >> >> 2009/7/23 Brett Cannon : > >> >> > > >> >> > > >> >> > On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> 2009/7/23 Brett Cannon : > >> >> >> > None in Python 3.1 is really useless in terms of its semantics > in > >> >> >> > relative > >> >> >> > imports; importlib doesn't support it and still passes as > >> >> >> > __import__ > >> >> >> > (at > >> >> >> > least last time I ran the test suite that way). I thought we had > >> >> >> > agreed > >> >> >> > a > >> >> >> > while back that supporting None was not warranted in Python 3.0? > >> >> >> > Otherwise I > >> >> >> > will do whatever work is necessary for this to happen. > >> >> >> > >> >> >> I think it's still nice for the rare cases where you need to trick > a > >> >> >> module into thinking another one doesn't exist. > >> >> > > >> >> > But None does not strictly mean "I don't exist". None is supposed > to > >> >> > trigger > >> >> > an another import attempt for the module with a top-level name. > It's > >> >> > that > >> >> > extra import trigger that has no real use in 3.0 and just > complicates > >> >> > import > >> >> > semantics (IMO) needlessly. If you want a module to not exist then > >> >> > you > >> >> > either stick something else in (e.g. '42') or we remove the special > >> >> > semantics for None (which I thought we had). > >> >> > >> >> > >> >> I didn't realize None had other semantics attached to it. (Imagine > >> >> that dealing with import!) +1 for making it simply indicate an > >> >> ImportError. > >> > > >> > I'm +0 with having import raise ImportError if None is set in > >> > sys.modules as > >> > long as we don't suddenly expect loaders to trigger the same thing if > >> > they > >> > return None (actually, as of right now what loaders return count for > >> > nothing, but just want to be clear). > >> > -Brett > >> > >> > >> > >> -- > >> --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Document None values in sys.modules?
On Fri, Jul 24, 2009 at 10:39, Guido van Rossum wrote:
> Still works, at least in some old 3.1 I had lying around:
>
Which reminds me, do we want to change the error message for ImportError in
this case to say something like "import of {0} halted; None found in
sys.modules"? Might be a tough exception to debug if you are not aware that
some library shoved None into sys.modules.
>
> $ python3.1
> Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> sys.modules['string'] = None
> >>> import string
> Traceback (most recent call last):
> File "", line 1, in
> ImportError: No module named string
> >>>
> $ python3.1
> Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import string
> >>>
> $
>
> The experiment should be easily repeatable. :-)
>
> --Guido
>
> On Thu, Jul 23, 2009 at 8:35 PM, Brett Cannon wrote:
> >
> >
> > On Thu, Jul 23, 2009 at 20:18, Guido van Rossum
> wrote:
> >>
> >> So, I guess, we'll live with it for a while longer. Given that it
> >> managed to evade our attention for so long, I think that's fine.
> >
> > Can someone double-check me that the semantics can even be triggered in
> 3.1?
> > I just tried and couldn't come up with anything. Heck, I quick search for
> a
> > Py_None comparison in 3.1's import.c turned up nothing useful (other than
> > mark_miss() is the function used to set None in sys.modules). We might
> have
> > actually already removed it or made it so that the semantics can't be
> > triggered.
> >
> >>
> >> I agree that there's no reason for a None result from loaders to be
> >> interpreted the same way, assuming that's not how it works ATM.
> >>
> >> And we can live with import and importlib differing on this in 3.1
> >> (though you could call it a bug in importlib and fix it for 3.1.1 --
> >> not sure if you were planning on that).
> >
> > I can if people can trigger the semantics somehow so I have a test to go
> by.
> > -Brett
> >
> >>
> >> --Guido
> >>
> >> On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon wrote:
> >> >
> >> >
> >> > On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson >
> >> > wrote:
> >> >>
> >> >> 2009/7/23 Brett Cannon :
> >> >> >
> >> >> >
> >> >> > On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson
> >> >> >
> >> >> > wrote:
> >> >> >>
> >> >> >> 2009/7/23 Brett Cannon :
> >> >> >> > None in Python 3.1 is really useless in terms of its semantics
> in
> >> >> >> > relative
> >> >> >> > imports; importlib doesn't support it and still passes as
> >> >> >> > __import__
> >> >> >> > (at
> >> >> >> > least last time I ran the test suite that way). I thought we had
> >> >> >> > agreed
> >> >> >> > a
> >> >> >> > while back that supporting None was not warranted in Python 3.0?
> >> >> >> > Otherwise I
> >> >> >> > will do whatever work is necessary for this to happen.
> >> >> >>
> >> >> >> I think it's still nice for the rare cases where you need to trick
> a
> >> >> >> module into thinking another one doesn't exist.
> >> >> >
> >> >> > But None does not strictly mean "I don't exist". None is supposed
> to
> >> >> > trigger
> >> >> > an another import attempt for the module with a top-level name.
> It's
> >> >> > that
> >> >> > extra import trigger that has no real use in 3.0 and just
> complicates
> >> >> > import
> >> >> > semantics (IMO) needlessly. If you want a module to not exist then
> >> >> > you
> >> >> > either stick something else in (e.g. '42') or we remove the special
> >> >> > semantics for None (which I thought we had).
> >> >>
> >> >>
> >> >> I didn't realize None had other semantics attached to it. (Imagine
> >> >> that dealing with import!) +1 for making it simply indicate an
> >> >> ImportError.
> >> >
> >> > I'm +0 with having import raise ImportError if None is set in
> >> > sys.modules as
> >> > long as we don't suddenly expect loaders to trigger the same thing if
> >> > they
> >> > return None (actually, as of right now what loaders return count for
> >> > nothing, but just want to be clear).
> >> > -Brett
> >>
> >>
> >>
> >> --
> >> --Guido van Rossum (home page: http://www.python.org/~guido/)
> >
> >
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Document None values in sys.modules?
On Fri, Jul 24, 2009 at 10:50 AM, Brett Cannon wrote: > > > On Fri, Jul 24, 2009 at 10:39, Guido van Rossum wrote: >> >> Still works, at least in some old 3.1 I had lying around: >> >> $ python3.1 >> Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) >> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import sys >> >>> sys.modules['string'] = None >> >>> import string >> Traceback (most recent call last): >> File "", line 1, in >> ImportError: No module named string >> >>> >> $ python3.1 >> Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) >> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import string >> >>> >> $ >> >> The experiment should be easily repeatable. :-) > > =) Yes, the None raising ImportError semantics can be added easily and > codified as official import semantics in 3.1. I thought it was too simple. :-) Maybe I should go back to bed and nurse my cough some more instead of playing hookie from being sick and indulging in email. > I was talking about the "None > triggers another import as with relative imports" semantics and if there was > some rather convoluted way to trigger that. I can't think of one and doubt you will find one -- it was introduced (in the earliest of early package import implementations) to optimize the problem we had with code living inside a package trying to stat() a toplevel module locally each time an import of it was processed (a problem if a package contains lots of modules each of which import os, sys, etc.). Since we no longer to relative import, I don't see how there could be another use -- if it's not there it's not there. > I am guessing not as that would > require a value of -1 for level which is no longer valid. Ah. Sure. > I will fix importlib in both 3.2 and 3.1.1. And speaking of fixing, should I > put the failing test in now and decorate it with unittest.expectedFailure > until I get around to fixing it? Oh, I don't know. All this new-fangled technology... Can't you just leave it in your workspace, unsubmitted, until you get to fixing it? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Document None values in sys.modules?
On Fri, Jul 24, 2009 at 10:58, Guido van Rossum wrote: > On Fri, Jul 24, 2009 at 10:50 AM, Brett Cannon wrote: > > > > > > On Fri, Jul 24, 2009 at 10:39, Guido van Rossum > wrote: > >> > >> Still works, at least in some old 3.1 I had lying around: > >> > >> $ python3.1 > >> Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) > >> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin > >> Type "help", "copyright", "credits" or "license" for more information. > >> >>> import sys > >> >>> sys.modules['string'] = None > >> >>> import string > >> Traceback (most recent call last): > >> File "", line 1, in > >> ImportError: No module named string > >> >>> > >> $ python3.1 > >> Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) > >> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin > >> Type "help", "copyright", "credits" or "license" for more information. > >> >>> import string > >> >>> > >> $ > >> > >> The experiment should be easily repeatable. :-) > > > > =) Yes, the None raising ImportError semantics can be added easily and > > codified as official import semantics in 3.1. > > I thought it was too simple. :-) Maybe I should go back to bed and > nurse my cough some more instead of playing hookie from being sick and > indulging in email. > I'm glad I can help provide a distraction. And I hope you get over whatever you have soon. > > > I was talking about the "None > > triggers another import as with relative imports" semantics and if there > was > > some rather convoluted way to trigger that. > > I can't think of one and doubt you will find one -- it was introduced > (in the earliest of early package import implementations) to optimize > the problem we had with code living inside a package trying to stat() > a toplevel module locally each time an import of it was processed (a > problem if a package contains lots of modules each of which import os, > sys, etc.). Since we no longer to relative import, I don't see how > there could be another use -- if it's not there it's not there. > > > I am guessing not as that would > > require a value of -1 for level which is no longer valid. > > Ah. Sure. > > > I will fix importlib in both 3.2 and 3.1.1. And speaking of fixing, > should I > > put the failing test in now and decorate it with unittest.expectedFailure > > until I get around to fixing it? > > Oh, I don't know. All this new-fangled technology... Can't you just > leave it in your workspace, unsubmitted, until you get to fixing it? > Oh sure, I normally just leave it in my scratch svn checkout until I get around to it. But since we now have the decorator I was wondering if any discussion came up while I was gone of using it within our tests when we happen to get a working (failing) test case before we have a patch to fix it. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Document None values in sys.modules?
Brett Cannon python.org> writes: > > Oh, I don't know. All this new-fangled technology... Can't you just > > leave it in your workspace, unsubmitted, until you get to fixing it? > > Oh sure, I normally just leave it in my scratch svn checkout until I get around to it. What? You're not even using a DVCS? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Thu, 23 Jul 2009 06:11:38 -0700, Jesse Noller wrote: Then why not include pip, easy_install, and this bash script I use to install packages into core? The more the merrier, right? Answer: None of these are standards, and as nick points out, there's issues with sysadmins, security, and other things. Not to mention they're fundamentally not part of the language. At the language summit, this was hashed out quite a bit. I think most everyone agreed that tools like easy_install, pip, virtualenv, zc.buildout, etc simply do not belong in core python. Once PEP 376 is implemented, my suggestion is to at least link to these tools (if not write a paragraph) as way of pointing users to alternative package managers that uses the 'uninstall' API. A mention of PyPI would also be helpful. -srid ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Document None values in sys.modules?
On Fri, Jul 24, 2009 at 11:13, Antoine Pitrou wrote: > Brett Cannon python.org> writes: > > > Oh, I don't know. All this new-fangled technology... Can't you just > > > leave it in your workspace, unsubmitted, until you get to fixing it? > > > > Oh sure, I normally just leave it in my scratch svn checkout until I get > around to it. > > > What? You're not even using a DVCS? Not for Python; waiting for hg switch (all my other code uses hg). Never got a workflow involving both hg and svn up and going (and don't even mention gitsvn). -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, Jul 24, 2009 at 11:47, Sridhar Ratnakumar wrote: > On Thu, 23 Jul 2009 06:11:38 -0700, Jesse Noller > wrote: > > Then why not include pip, easy_install, and this bash script I use to >> install packages into core? The more the merrier, right? >> Answer: None of these are standards, and as nick points out, there's >> issues with sysadmins, security, and other things. Not to mention >> they're fundamentally not part of the language. >> At the language summit, this was hashed out quite a bit. I think most >> everyone agreed that tools like easy_install, pip, virtualenv, >> zc.buildout, etc simply do not belong in core python. >> > > Once PEP 376 is implemented, my suggestion is to at least link to these > tools (if not write a paragraph) as way of pointing users to alternative > package managers that uses the 'uninstall' API. A mention of PyPI would also > be helpful. You can put that in the wiki, but it does not belong in the core documentation (except the PyPI mention as we do control that). That simply becomes a maintenance nightmare for use as we then have to keep up with the releases of external tools that we have no direct connection with. Plus it also give the illusion that Python has blessed these tools when in fact we have not. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, 24 Jul 2009 17:54:09 +0200, Georg Brandl wrote: > David Lyon schrieb: >> In executable form, the Package Manager does not require wxWidgets >> to be installed. >> >> There is no dependency for this to be installed. > > What does "in exectuable form" mean? Compiled with py2exe. An executable ".exe" file is created under windows. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, 24 Jul 2009 17:08:32 +0100, Paul Moore wrote: > I read this as meaning that David was proposing to ship a built > application (on Windows, bundled up with something like py2exe, I > guess) and any supporting DLLs such as the wxWindows ones would be > bundled in, but the wxPython package would *not* be shipped as part of > the standard library. That's correct. > In my view, for an "application" to be shipped with Python, whether it > be Idle, or a package manager, or pydoc, or whatever, it must: > - be written as a Python script > - depend only on packages shipped with the standard library This is true for the Package Manager in executable form. > Given that David's package manager uses setuptools to do the installs > (and now it appears it uses wxPython for its GUI) that immediately > disqualifies it for inclusion in my view - regardless of its value as > a package. Yes, It offers the choice to install via setuptools. As well as PIP. And it will be extended to Enstaller. Presently it used pkg_resources to read the list of packages installed which is part of setuptools. I was told it was the "right" and only way to read a list of packages. If using this package presents a problem, then it can be removed and I will replace the functionality with my own code. If the gui needs to be rewritten in TK this can be accomplished. I'm in no way pushing any GUI toolkit, and this was the one suggested to me by many. Redoing to meet the above criteria is achievable. If there's any other objections, can they be raised now before I start a rewrite? Thank you. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes wrote: > I'm sorry to inform you that a wxWindows based solution has zero change > to get into the Python standard library ever. Is that a personal preference or is there a software engineering reason for this? I wasn't suggesting including it in the standard library as I like others know how troublesome it can be. > We are not going to add > another GUI toolkit to the core distribution. We might even remove TK > from the core and ship it as a separate package like bsddb3. So is this a bias against native window applications? Does the application need to be web based? or console based? or TK based... ? For it to be acceptable.. Thank you David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
[email protected] writes: > Distutils was once seperate and was then included in the standard > python. > > So i guess that I am working with the same goal in mind. I interpret this as expressing your intent to (eventually) have your application included in standard Python. David Lyon writes: > On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes > wrote: > > I'm sorry to inform you that a wxWindows based solution has zero > > change to get into the Python standard library ever. > > I wasn't suggesting including it in the standard library as I like > others know how troublesome it can be. This appears to contradict what you said above. > > We are not going to add another GUI toolkit to the core > > distribution. We might even remove TK from the core and ship it as a > > separate package like bsddb3. > > So is this a bias against native window applications? No, it's a bias against adding things to Python that depend on things not already in Python. Are you, or are you not, intending for your application to be in standard Python? If that is your intent, I think Christian's answer is valid: applications, especially ones that depend on third-party widget libraries, shouldn't get added to Python. If that is not your intent, then your application shouldn't be mentioned in standard Python documentation. -- \“Stop — Drive sideways.” —detour sign, Kyushu, Japan | `\ | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney wrote: [snip] If that is not your intent, then your application shouldn't be mentioned in standard Python documentation. Hm. But docutils isn't part of the standard library, and the documentation refers to it. And the docs link to ActivePython and Enthought's Python distribution. And they link to things like "Collin Winter’s functional module" and Django and PyOpenGL and so forth. I don't think anyone would seriously suggest removing all references to third-party software from the Python documentation. Perhaps the criterion that David is looking to have is explained is that people would probably prefer for his app to get a bit more popular before Python itself starts pointing people in its direction. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney wrote: > I interpret this as expressing your intent to (eventually) have your > application included in standard Python. It's my intention to get a Package Manager included in standard python - yes. >> I wasn't suggesting including it in the standard library as I like >> others know how troublesome it can be. > > This appears to contradict what you said above. Not at all. In source form the pythonpkgmgr requires wx package. In executable form it does not. > No, it's a bias against adding things to Python that depend on things > not already in Python. That implies that nothing new can be added then. > Are you, or are you not, intending for your application to be in > standard Python? > > If that is your intent, I think Christian's answer is valid: > applications, especially ones that depend on third-party widget > libraries, shouldn't get added to Python. > > If that is not your intent, then your application shouldn't be mentioned > in standard Python documentation. The Python Package Manager can be written to work in console mode. It can be redone to work with the TK that already ships. That doesn't present any great problem. If it was the interests of python users that were foremost, being able to install packages in a modern way - Then I think there would be more room to move than this. It's no different than any other windows application that ships with dll files. I fully appreciate that changes could be necessary and I'm prepared to accomodate them. Not much more I can do than that.. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
Jean-Paul Calderone writes: > Hm. But docutils isn't part of the standard library, and the > documentation refers to it. Fair enough, because the documentation is generated using Docutils. > And the docs link to ActivePython and Enthought's Python distribution. I consider those to be exceptions that prove the rule: they are “standard Python” in a different form. > And they link to things like "Collin Winter’s functional module" and > Django and PyOpenGL and so forth. I don't know enough about those to comment. > I don't think anyone would seriously suggest removing all references to > third-party software from the Python documentation. No, and nor did I. I'm suggesting that *adding* such a reference has a high barrier. > Perhaps the criterion that David is looking to have is explained is > that people would probably prefer for his app to get a bit more > popular before Python itself starts pointing people in its direction. Right. The process is usually in the following order: * get the code registered on PyPI * get a community of users and make the code meet their needs well * discuss adding some or all of the code to Python, by (in recent years) raising the topic on ‘python-ideas’ * defend the proposal against all comers to ensure it's actually a good idea * await further instructions -- \ “It seems intuitively obvious to me, which means that it might | `\ be wrong.” —Chris Torek | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
David Lyon writes: > Not at all. In source form the pythonpkgmgr requires wx package. In > executable form it does not. The only way it could be added is in source form; that's essential for free software like Python. So, if it's not suitable for adding to Python in source form, it's not suitable for adding to Python. > > No, it's a bias against adding things to Python that depend on things > > not already in Python. > > That implies that nothing new can be added then. You omit the important part: adding a new thing to Python *so long as it doesn't depend on anything outside Python*. > The Python Package Manager can be written to work in console mode. I think this would be best. The functionality you often discuss around this tool would be best implemented independently of any UI. It would, in fact, be best to work with the team performing ongoing active standardisation of distutils functionality. -- \“Consider the daffodil. And while you're doing that, I'll be | `\ over here, looking through your stuff.” —Jack Handey | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
At 08:09 PM 7/24/2009 -0400, David Lyon wrote: Presently it used pkg_resources to read the list of packages installed which is part of setuptools. I was told it was the "right" and only way to read a list of packages. "Right" is relative, but right now it is certainly the *only* way to read a list of installed packages, that's compatible with both distutils and setuptools-based ways of installing packages (including of course pip, enstaller, and buildout). PEP 376 proposes a stdlib replacement for a portion of this functionality, but the status of whether it's actually going to support anything other than distutils, pip, and setuptools' backward-compatibility mode is apparently still up for grabs. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
Ben Finney writes: > The functionality you often discuss around this tool would be best > implemented independently of any UI. It would, in fact, be best to > work with the team performing ongoing active standardisation of > distutils functionality. Sloppy use of “in fact”. That should be “in my opinion”. -- \“Our wines leave you nothing to hope for.” —restaurant menu, | `\ Switzerland | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] command line attachable debugger
> Winpdb is *exactly* what you asked for, so if it's not what you're looking > for you'll need to be more specific about what you want that it doesn't > do... > > James > Fair enough, I was assuming that winpdb didn't have a command line interface, but I was mistaken (rpdb2). In any case, I would argue that attach functionality is something that should be put into the core, along with pdb, as a standard. What if I want to use pudb? or pydb? or the interface which goes with perl? There should be a standard mechanism for debuggers to talk to a python process; not one-offs for each debugger, probably at the level of the python executable (the same way that gcc lets gdb attach with a pid.. Ed ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 11:25:27 +1000, Ben Finney > You omit the important part: adding a new thing to Python *so long as it > doesn't depend on anything outside Python*. I'm signing out on this silly discussion for now Any python program is dependant on things "outside" python. For example an operating system.. a computer... and a user perhaps for without such it wouldn't be possible to generate the all important 1Di0t errors that we so often have to deal with. >> The Python Package Manager can be written to work in console mode. > > I think this would be best. Haha - I'm glad somebody took this seriously... It was a sort of a joke comment but it's a serious possibility. > The functionality you often discuss around > this tool would be best implemented independently of any UI. It is anyway. That's why doing an entirely different UI isn't any major issue. I have a class and a possible command line interface behind the scenes. > It would, in fact, be best to work with the team performing ongoing > active standardisation of distutils functionality. I am already doing that. But there is a bias against windows development and a bias against native applications. That's fine because I know they are using python on different platforms. I'm working on a proposal to make setup.py object oriented and "modern". http://wiki.python.org/moin/Distutils/Proposals So I'm doing as much as I can - really. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backporting HTTPS via Proxy Support in urllib2
Issue: http://bugs.python.org/issue1424152 mentions about HTTPS Support via proxy in urllib2. This is fixed in the trunk (Revision 72880), but there has been number of valid requests to backport it Python 2.6. While I agree and ready to backport to Python 2.6, I would like to ask here if there are any objections in this front. I am ready with the Python 3.x patch as well (with tests passed and tested under proxy setup). I shall apply that too, which is pending for a while now. :( -- Senthil Wad some power the giftie gie us To see oursels as others see us. -- R. Burns ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
David Lyon writes: > On Fri, 24 Jul 2009 17:08:32 +0100, Paul Moore wrote: > > I read this as meaning that David was proposing to ship a built > > application (on Windows, bundled up with something like py2exe, I > > guess) and any supporting DLLs such as the wxWindows ones would be > > bundled in, but the wxPython package would *not* be shipped as part of > > the standard library. > > That's correct. -1, then. Python is open source. Anything shipped with the standard distribution should be buildable with the Pythonic tools in the standard distribution. Obviously the C compiler and operating system services are non-Pythonic, and the line is pretty fuzzy, but I would not want to extend similar consideration to wxPython. This kind of thing is what ActiveState and the OS distros are for. If you say this is discriminating against Windows, well, it probably is, but it should be addressed with a Windows solution, such as a script to generate MSIs. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] command line attachable debugger
On Fri, Jul 24, 2009 at 9:43 PM, Edward Peschko wrote: > There should be a standard mechanism for debuggers to talk to a python > process; not one-offs for each debugger, probably at the level of the > python executable (the same way that gcc lets gdb attach with a pid.. > Sounds like this is moving into hypothetical territory better-suited to python-ideas. (Although I'm sure that if you wanted to contribute polished, tested code for a standard remote debugger interface, few people would complain.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update to Python Documentation Website Request
David Lyon writes: > On Sat, 25 Jul 2009 11:25:27 +1000, Ben Finney > > You omit the important part: adding a new thing to Python *so long > > as it doesn't depend on anything outside Python*. > > I'm signing out on this silly discussion for now > > Any python program is dependant on things "outside" python. I think you know quite well what “depend on” means in this instance, so this is taking it to silly extremes. -- \ “For your convenience we recommend courteous, efficient | `\self-service.” —supermarket, Hong Kong | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] command line attachable debugger
Glyph Lefkowitz: > Sounds like this is moving into hypothetical territory better-suited to > python-ideas. (Although I'm sure that if you wanted to contribute polished, > tested code for a standard remote debugger interface, few people would > complain.) There is a remote debugger protocol called DBGP for different languages (including Python) and debuggers (such as Komodo) http://xdebug.org/docs-dbgp.php Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
