From status at bugs.python.org  Sun Jul  1 02:00:53 2007
From: status at bugs.python.org (Tracker)
Date: Sun,  1 Jul 2007 00:00:53 +0000 (UTC)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20070701000053.48F0B78278@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (06/24/07 - 07/01/07)
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.


 1645 open ( +0) /  8584 closed ( +0) / 10229 total ( +0)

Average duration of open issues: 843 days.
Median duration of open issues: 791 days.

Open Issues Breakdown
   open  1645 ( +0)
pending     0 ( +0)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070701/94ffa127/attachment.html 

From greg at electricrain.com  Wed Jul  4 08:58:44 2007
From: greg at electricrain.com (Gregory P. Smith)
Date: Tue, 3 Jul 2007 23:58:44 -0700
Subject: [Python-Dev] Adding NetworkIOError for bug 1706815
Message-ID: <20070704065843.GG5055@electricrain.com>

In response to bug 1706815 and seeing messy code to catch errors in
network apps I've implemented most of the ideas in the bug and added a
NetworkIOError exception (child of IOError).  With this, socket.error
would now inherit from NetworkIOError instead of being its own thing
(the old one didn't even declare a parent!).

Complete patch attached to the bug.  All unit tests pass.
Documentation updates included.

 http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470

Any thoughts?  I'm happy with it and would like to commit it if folks
agree.


From guido at python.org  Wed Jul  4 11:03:42 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 4 Jul 2007 11:03:42 +0200
Subject: [Python-Dev] Adding NetworkIOError for bug 1706815
In-Reply-To: <20070704065843.GG5055@electricrain.com>
References: <20070704065843.GG5055@electricrain.com>
Message-ID: <ca471dc20707040203k4ef4395aj9ef51fd78aa9eb5c@mail.gmail.com>

Why not simply inherit socket.error from EnvironmentError?

On 7/4/07, Gregory P. Smith <greg at electricrain.com> wrote:
> In response to bug 1706815 and seeing messy code to catch errors in
> network apps I've implemented most of the ideas in the bug and added a
> NetworkIOError exception (child of IOError).  With this, socket.error
> would now inherit from NetworkIOError instead of being its own thing
> (the old one didn't even declare a parent!).
>
> Complete patch attached to the bug.  All unit tests pass.
> Documentation updates included.
>
>  http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470
>
> Any thoughts?  I'm happy with it and would like to commit it if folks
> agree.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From exarkun at divmod.com  Wed Jul  4 14:17:15 2007
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Wed, 4 Jul 2007 08:17:15 -0400
Subject: [Python-Dev] Adding NetworkIOError for bug 1706815
In-Reply-To: <20070704065843.GG5055@electricrain.com>
Message-ID: <20070704121715.4947.423515156.divmod.quotient.6849@ohm>

On Tue, 3 Jul 2007 23:58:44 -0700, "Gregory P. Smith" <greg at electricrain.com> wrote:
>In response to bug 1706815 and seeing messy code to catch errors in
>network apps I've implemented most of the ideas in the bug and added a
>NetworkIOError exception (child of IOError).  With this, socket.error
>would now inherit from NetworkIOError instead of being its own thing
>(the old one didn't even declare a parent!).
>
>Complete patch attached to the bug.  All unit tests pass.
>Documentation updates included.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470
>

FWIW, that page does not seem to be generally accessible.  It's difficult
to know what you're talking about without being able to see it.

    Artifact: Invalid ArtifactID; this Tracker item may have moved to a
    different Tracker since this URL was generated -- [Find the new location
    of this Tracker item]

Following [Find the new location ...]:

    Artifact: This Artifact Has Been Made Private. Only Group Members Can
    View Private ArtifactTypes.

>Any thoughts?  I'm happy with it and would like to commit it if folks
>agree.
>

Jean-Paul

From ncoghlan at gmail.com  Wed Jul  4 14:51:49 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 04 Jul 2007 22:51:49 +1000
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
Message-ID: <468B97E5.7070800@gmail.com>

A c.l.p discussion referenced from Python-URL just brought this topic 
back to my attention, and with the relatively low traffic on the 
development lists in the last few days, it seemed like a good time to 
repost this PEP (it vanished beneath the Unicode identifier discussion 
last time).

Cheers,
Nick.


PEP: 366
Title: Main module explicit relative imports
Version: $Revision: 56172 $
Last-Modified: $Date: 2007-07-04 22:47:13 +1000 (Wed, 04 Jul 2007) $
Author: Nick Coghlan <ncoghlan at gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 2.6
Post-History: 1-May-2007


Abstract
========

This PEP proposes a backwards compatible mechanism that permits
the use of explicit relative imports from executable modules within
packages. Such imports currently fail due to an awkward interaction
between PEP 328 and PEP 338 - this behaviour is the subject of at
least one open SF bug report (#1510172)[1], and has most likely
been a factor in at least a few queries on comp.lang.python (such
as Alan Isaac's question in [2]).

With the proposed mechanism, relative imports will work automatically
if the module is executed using the ``-m`` switch. A small amount of
boilerplate will be needed in the module itself to allow the relative
imports to work when the file is executed by name.


Import Statements and the Main Module
=====================================

(This section is taken from the final revision of PEP 338)

The release of 2.5b1 showed a surprising  (although obvious in
retrospect) interaction between PEP 338 and PEP 328 - explicit
relative imports don't work from a main module. This is due to
the fact that relative imports rely on ``__name__`` to determine
the current module's position in the package hierarchy. In a main
module, the value of ``__name__`` is always ``'__main__'``, so
explicit relative imports will always fail (as they only work for
a module inside a package).

Investigation into why implicit relative imports *appear* to work when
a main module is executed directly but fail when executed using ``-m``
showed that such imports are actually always treated as absolute
imports. Because of the way direct execution works, the package
containing the executed module is added to sys.path, so its sibling
modules are actually imported as top level modules. This can easily
lead to multiple copies of the sibling modules in the application if
implicit relative imports are used in modules that may be directly
executed (e.g. test modules or utility scripts).

For the 2.5 release, the recommendation is to always use absolute
imports in any module that is intended to be used as a main module.
The ``-m`` switch already provides a benefit here, as it inserts the
current directory into ``sys.path``, instead of the directory containing
the main module. This means that it is possible to run a module from
inside a package using ``-m`` so long as the current directory contains
the top level directory for the package. Absolute imports will work
correctly even if the package isn't installed anywhere else on
sys.path. If the module is executed directly and uses absolute imports
to retrieve its sibling modules, then the top level package directory
needs to be installed somewhere on sys.path (since the current directory
won't be added automatically).

Here's an example file layout::

     devel/
         pkg/
             __init__.py
             moduleA.py
             moduleB.py
             test/
                 __init__.py
                 test_A.py
                 test_B.py

So long as the current directory is ``devel``, or ``devel`` is already
on ``sys.path`` and the test modules use absolute imports (such as
``import pkg.moduleA`` to retrieve the module under test, PEP 338
allows the tests to be run as::

     python -m pkg.test.test_A
     python -m pkg.test.test_B

Rationale for Change
====================

In rejecting PEP 3122 (which proposed a higher impact solution to this
problem), Guido has indicated that he still isn't particularly keen on
the idea of executing modules inside packages as scripts [2]. Despite
these misgivings he has previously approved the addition of the ``-m``
switch in Python 2.4, and the ``runpy`` module based enhancements
described in PEP 338 for Python 2.5.

The philosophy that motivated those previous additions (i.e. access to
utility or testing scripts without needing to worry about name clashes in
either the OS executable namespace or the top level Python namespace) is
also the motivation behind fixing what I see as a bug in the current
implementation.

This PEP is intended to provide a solution which permits explicit
relative imports from main modules, without incurring any significant
costs during interpreter startup or normal module import.


Proposed Solution
=================

The heart of the proposed solution is a new module attribute
``__package_name__``. This attribute will be defined only in
the main module (i.e. modules where ``__name__ == "__main__"``).

For a directly executed main module, this attribute will be set
to the empty string. For a module executed using
``runpy.run_module()`` with the ``run_name`` parameter set to
``"__main__"``, the attribute will be set to
``mod_name.rpartition('.')[0]`` (i.e., everything up to
but not including the last period).

In the import machinery there is an error handling path which
deals with the case where an explicit relative reference attempts
to go higher than the top level in the package hierarchy. This
error path would be changed to fall back on the ``__package_name__``
attribute for explicit relative imports when the importing module
is called ``"__main__"``.

With this change, explicit relative imports will work automatically
from a script executed with the ``-m`` switch. To allow direct
execution of the module, the following boilerplate would be needed at
the top of the script::

   if __name__ == "__main__" and not __package_name__:
       __package_name__ = "<expected_pkg_name>"

Note that this boilerplate is sufficient only if the top level package
is already accessible via sys.path. Additional code that manipulates
sys.path would be needed in order for direct execution to work
without the top level package already being on sys.path.

This approach also has the same disadvantage as the use of absolute
imports of sibling modules - if the script is moved to a different
package or subpackage, the boilerplate will need to be updated
manually.

With this feature in place, the test scripts in the package above
would be able to change their import lines to something along the
lines of ``import ..moduleA``. The scripts could then be
executed unmodified even if the name of the package was changed.

(Rev 47142 in SVN implemented an early variant of this proposal
which stored the main module's real module name in the
'__module_name__' attribute. It was reverted due to the fact
that 2.5 was already in beta by that time.)


Alternative Proposals
=====================

PEP 3122 proposed addressing this problem by changing the way
the main module is identified. That's a huge compatibility cost
to incur to fix something that is a pretty minor bug in the overall
scheme of things.

The advantage of the proposal in this PEP is that its only impact on
normal code is the tiny amount of time needed at startup to set the extra
attribute in the main module. The changes to the import machinery are all
in an existing error handling path, so normal imports don't incur any
performance penalty at all.


References
==========

.. [1] Absolute/relative import not working?
    (http://www.python.org/sf/1510172)

.. [2] Guido's rejection of PEP 3122
    (http://mail.python.org/pipermail/python-3000/2007-April/006793.html)

.. [3] c.l.p. question about modules and relative imports
 
(http://groups.google.com/group/comp.lang.python/browse_thread/thread/c44c769a72ca69fa/)

Copyright
=========

This document has been placed in the public domain.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From orsenthil at users.sourceforge.net  Wed Jul  4 21:22:23 2007
From: orsenthil at users.sourceforge.net (O.R.Senthil Kumaran)
Date: Thu, 5 Jul 2007 00:52:23 +0530
Subject: [Python-Dev] Tracker item: 735515 - urllib to cache 301
	redirections?
Message-ID: <20070704192223.GA3393@gmail.com>

Hi,
One of the tracker items: 735515 mentions that urllib should cache 301 and 302
redirections.

urllib / urllib2 should cache the results of 301
(permanent) redirections. This shouldn't break
anything, since it's just an internal optimisation
from one point of view -- but it's also what the
RFC (2616, section 10.3.2, first para) says
SHOULD happen. 

I am trying to understand, what does it mean.
Should the original url be avaiable to the user upon request as urllib
automatically calls the redirect_request and provides the redirected url only?

I am not completely getting what "cache - redirection" implies and what should
be done with the urllib2 module. Any pointers?

Thanks,

-- 
O.R.Senthil Kumaran
http://uthcode.sarovar.org

From greg at electricrain.com  Thu Jul  5 08:48:29 2007
From: greg at electricrain.com (Gregory P. Smith)
Date: Wed, 4 Jul 2007 23:48:29 -0700
Subject: [Python-Dev] Adding NetworkIOError for bug 1706815
In-Reply-To: <ca471dc20707040203k4ef4395aj9ef51fd78aa9eb5c@mail.gmail.com>
References: <20070704065843.GG5055@electricrain.com>
	<ca471dc20707040203k4ef4395aj9ef51fd78aa9eb5c@mail.gmail.com>
Message-ID: <20070705064829.GJ5055@electricrain.com>

On Wed, Jul 04, 2007 at 11:03:42AM +0200, Guido van Rossum wrote:
> Why not simply inherit socket.error from EnvironmentError?

True, that would be simpler; is it enough?  If we avoid adding the new
exception, I really think it should inherit from IOError, not
EnviromnentError because sockets are I/O.  urllib2.URLError was
already a child of IOError; doing the same to to socket.error makes
sense.

The patch makes URLError a child of NetworkIOError instead of IOError.
Does that make sense?  URLs as an abstract concept may or may not
imply network I/O behind the scenes though network i/o is the most
common use.  I could take that argument further and suggest they don't
necessarily even imply actual I/O if you've provided your own protocol
handlers.

The question then becomes if there are any use cases for "except
NetworkIOError:" that code wouldn't want to just use "except IOError:"
for that using "except socket.error:" or "except urllib2.URLError:"
are insufficient for.  My intuition is telling me: probably not.
urllib2 code should catch socket.error everywhere internally and turn
it into a URLError (the code appears to do this in many places though
i haven't audited that it does everywhere).

-greg

PS for the person complaining that the url didn't work.  blame
   sourceforge and go look the bug up by id yourself.  nothing i can
   do about that.

> On 7/4/07, Gregory P. Smith <greg at electricrain.com> wrote:
> >In response to bug 1706815 and seeing messy code to catch errors in
> >network apps I've implemented most of the ideas in the bug and added a
> >NetworkIOError exception (child of IOError).  With this, socket.error
> >would now inherit from NetworkIOError instead of being its own thing
> >(the old one didn't even declare a parent!).
> >
> >Complete patch attached to the bug.  All unit tests pass.
> >Documentation updates included.
> >
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470
> >
> >Any thoughts?  I'm happy with it and would like to commit it if folks
> >agree.

From guido at python.org  Thu Jul  5 11:53:15 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 5 Jul 2007 11:53:15 +0200
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <468B97E5.7070800@gmail.com>
References: <468B97E5.7070800@gmail.com>
Message-ID: <ca471dc20707050253q2bd8ee1bi4a954bb1702c6947@mail.gmail.com>

I see no big problems with this, except I wonder if in the end it
wouldn't be better to *always* define __package_name__ instead of only
when it's in main? And then perhaps rename it to __package__? Done
properly it could always be used for relative imports, rather than
parsing __module__ to find the package. Then you won't even need the
error handler.

FWIW, I find the PEP is rather wordy for such a simple proposal (it
took me more time to find the proposal than to understand it :-).

--Guido

On 7/4/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> A c.l.p discussion referenced from Python-URL just brought this topic
> back to my attention, and with the relatively low traffic on the
> development lists in the last few days, it seemed like a good time to
> repost this PEP (it vanished beneath the Unicode identifier discussion
> last time).
>
> Cheers,
> Nick.
>
>
> PEP: 366
> Title: Main module explicit relative imports
> Version: $Revision: 56172 $
> Last-Modified: $Date: 2007-07-04 22:47:13 +1000 (Wed, 04 Jul 2007) $
> Author: Nick Coghlan <ncoghlan at gmail.com>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 1-May-2007
> Python-Version: 2.6
> Post-History: 1-May-2007
>
>
> Abstract
> ========
>
> This PEP proposes a backwards compatible mechanism that permits
> the use of explicit relative imports from executable modules within
> packages. Such imports currently fail due to an awkward interaction
> between PEP 328 and PEP 338 - this behaviour is the subject of at
> least one open SF bug report (#1510172)[1], and has most likely
> been a factor in at least a few queries on comp.lang.python (such
> as Alan Isaac's question in [2]).
>
> With the proposed mechanism, relative imports will work automatically
> if the module is executed using the ``-m`` switch. A small amount of
> boilerplate will be needed in the module itself to allow the relative
> imports to work when the file is executed by name.
>
>
> Import Statements and the Main Module
> =====================================
>
> (This section is taken from the final revision of PEP 338)
>
> The release of 2.5b1 showed a surprising  (although obvious in
> retrospect) interaction between PEP 338 and PEP 328 - explicit
> relative imports don't work from a main module. This is due to
> the fact that relative imports rely on ``__name__`` to determine
> the current module's position in the package hierarchy. In a main
> module, the value of ``__name__`` is always ``'__main__'``, so
> explicit relative imports will always fail (as they only work for
> a module inside a package).
>
> Investigation into why implicit relative imports *appear* to work when
> a main module is executed directly but fail when executed using ``-m``
> showed that such imports are actually always treated as absolute
> imports. Because of the way direct execution works, the package
> containing the executed module is added to sys.path, so its sibling
> modules are actually imported as top level modules. This can easily
> lead to multiple copies of the sibling modules in the application if
> implicit relative imports are used in modules that may be directly
> executed (e.g. test modules or utility scripts).
>
> For the 2.5 release, the recommendation is to always use absolute
> imports in any module that is intended to be used as a main module.
> The ``-m`` switch already provides a benefit here, as it inserts the
> current directory into ``sys.path``, instead of the directory containing
> the main module. This means that it is possible to run a module from
> inside a package using ``-m`` so long as the current directory contains
> the top level directory for the package. Absolute imports will work
> correctly even if the package isn't installed anywhere else on
> sys.path. If the module is executed directly and uses absolute imports
> to retrieve its sibling modules, then the top level package directory
> needs to be installed somewhere on sys.path (since the current directory
> won't be added automatically).
>
> Here's an example file layout::
>
>      devel/
>          pkg/
>              __init__.py
>              moduleA.py
>              moduleB.py
>              test/
>                  __init__.py
>                  test_A.py
>                  test_B.py
>
> So long as the current directory is ``devel``, or ``devel`` is already
> on ``sys.path`` and the test modules use absolute imports (such as
> ``import pkg.moduleA`` to retrieve the module under test, PEP 338
> allows the tests to be run as::
>
>      python -m pkg.test.test_A
>      python -m pkg.test.test_B
>
> Rationale for Change
> ====================
>
> In rejecting PEP 3122 (which proposed a higher impact solution to this
> problem), Guido has indicated that he still isn't particularly keen on
> the idea of executing modules inside packages as scripts [2]. Despite
> these misgivings he has previously approved the addition of the ``-m``
> switch in Python 2.4, and the ``runpy`` module based enhancements
> described in PEP 338 for Python 2.5.
>
> The philosophy that motivated those previous additions (i.e. access to
> utility or testing scripts without needing to worry about name clashes in
> either the OS executable namespace or the top level Python namespace) is
> also the motivation behind fixing what I see as a bug in the current
> implementation.
>
> This PEP is intended to provide a solution which permits explicit
> relative imports from main modules, without incurring any significant
> costs during interpreter startup or normal module import.
>
>
> Proposed Solution
> =================
>
> The heart of the proposed solution is a new module attribute
> ``__package_name__``. This attribute will be defined only in
> the main module (i.e. modules where ``__name__ == "__main__"``).
>
> For a directly executed main module, this attribute will be set
> to the empty string. For a module executed using
> ``runpy.run_module()`` with the ``run_name`` parameter set to
> ``"__main__"``, the attribute will be set to
> ``mod_name.rpartition('.')[0]`` (i.e., everything up to
> but not including the last period).
>
> In the import machinery there is an error handling path which
> deals with the case where an explicit relative reference attempts
> to go higher than the top level in the package hierarchy. This
> error path would be changed to fall back on the ``__package_name__``
> attribute for explicit relative imports when the importing module
> is called ``"__main__"``.
>
> With this change, explicit relative imports will work automatically
> from a script executed with the ``-m`` switch. To allow direct
> execution of the module, the following boilerplate would be needed at
> the top of the script::
>
>    if __name__ == "__main__" and not __package_name__:
>        __package_name__ = "<expected_pkg_name>"
>
> Note that this boilerplate is sufficient only if the top level package
> is already accessible via sys.path. Additional code that manipulates
> sys.path would be needed in order for direct execution to work
> without the top level package already being on sys.path.
>
> This approach also has the same disadvantage as the use of absolute
> imports of sibling modules - if the script is moved to a different
> package or subpackage, the boilerplate will need to be updated
> manually.
>
> With this feature in place, the test scripts in the package above
> would be able to change their import lines to something along the
> lines of ``import ..moduleA``. The scripts could then be
> executed unmodified even if the name of the package was changed.
>
> (Rev 47142 in SVN implemented an early variant of this proposal
> which stored the main module's real module name in the
> '__module_name__' attribute. It was reverted due to the fact
> that 2.5 was already in beta by that time.)
>
>
> Alternative Proposals
> =====================
>
> PEP 3122 proposed addressing this problem by changing the way
> the main module is identified. That's a huge compatibility cost
> to incur to fix something that is a pretty minor bug in the overall
> scheme of things.
>
> The advantage of the proposal in this PEP is that its only impact on
> normal code is the tiny amount of time needed at startup to set the extra
> attribute in the main module. The changes to the import machinery are all
> in an existing error handling path, so normal imports don't incur any
> performance penalty at all.
>
>
> References
> ==========
>
> .. [1] Absolute/relative import not working?
>     (http://www.python.org/sf/1510172)
>
> .. [2] Guido's rejection of PEP 3122
>     (http://mail.python.org/pipermail/python-3000/2007-April/006793.html)
>
> .. [3] c.l.p. question about modules and relative imports
>
> (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c44c769a72ca69fa/)
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
>              http://www.boredomandlaziness.org
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Thu Jul  5 11:54:06 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 5 Jul 2007 11:54:06 +0200
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <ca471dc20707050253q2bd8ee1bi4a954bb1702c6947@mail.gmail.com>
References: <468B97E5.7070800@gmail.com>
	<ca471dc20707050253q2bd8ee1bi4a954bb1702c6947@mail.gmail.com>
Message-ID: <ca471dc20707050254v90d1eagdc9a171f227e0ad7@mail.gmail.com>

Oh, one more thing. Perhaps we should rename it, like the other PEPs
still active slated for inclusion in Py3k (and backporting to 2.6)?

--Guido

On 7/5/07, Guido van Rossum <guido at python.org> wrote:
> I see no big problems with this, except I wonder if in the end it
> wouldn't be better to *always* define __package_name__ instead of only
> when it's in main? And then perhaps rename it to __package__? Done
> properly it could always be used for relative imports, rather than
> parsing __module__ to find the package. Then you won't even need the
> error handler.
>
> FWIW, I find the PEP is rather wordy for such a simple proposal (it
> took me more time to find the proposal than to understand it :-).
>
> --Guido
>
> On 7/4/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > A c.l.p discussion referenced from Python-URL just brought this topic
> > back to my attention, and with the relatively low traffic on the
> > development lists in the last few days, it seemed like a good time to
> > repost this PEP (it vanished beneath the Unicode identifier discussion
> > last time).
> >
> > Cheers,
> > Nick.
> >
> >
> > PEP: 366
> > Title: Main module explicit relative imports
> > Version: $Revision: 56172 $
> > Last-Modified: $Date: 2007-07-04 22:47:13 +1000 (Wed, 04 Jul 2007) $
> > Author: Nick Coghlan <ncoghlan at gmail.com>
> > Status: Draft
> > Type: Standards Track
> > Content-Type: text/x-rst
> > Created: 1-May-2007
> > Python-Version: 2.6
> > Post-History: 1-May-2007
> >
> >
> > Abstract
> > ========
> >
> > This PEP proposes a backwards compatible mechanism that permits
> > the use of explicit relative imports from executable modules within
> > packages. Such imports currently fail due to an awkward interaction
> > between PEP 328 and PEP 338 - this behaviour is the subject of at
> > least one open SF bug report (#1510172)[1], and has most likely
> > been a factor in at least a few queries on comp.lang.python (such
> > as Alan Isaac's question in [2]).
> >
> > With the proposed mechanism, relative imports will work automatically
> > if the module is executed using the ``-m`` switch. A small amount of
> > boilerplate will be needed in the module itself to allow the relative
> > imports to work when the file is executed by name.
> >
> >
> > Import Statements and the Main Module
> > =====================================
> >
> > (This section is taken from the final revision of PEP 338)
> >
> > The release of 2.5b1 showed a surprising  (although obvious in
> > retrospect) interaction between PEP 338 and PEP 328 - explicit
> > relative imports don't work from a main module. This is due to
> > the fact that relative imports rely on ``__name__`` to determine
> > the current module's position in the package hierarchy. In a main
> > module, the value of ``__name__`` is always ``'__main__'``, so
> > explicit relative imports will always fail (as they only work for
> > a module inside a package).
> >
> > Investigation into why implicit relative imports *appear* to work when
> > a main module is executed directly but fail when executed using ``-m``
> > showed that such imports are actually always treated as absolute
> > imports. Because of the way direct execution works, the package
> > containing the executed module is added to sys.path, so its sibling
> > modules are actually imported as top level modules. This can easily
> > lead to multiple copies of the sibling modules in the application if
> > implicit relative imports are used in modules that may be directly
> > executed (e.g. test modules or utility scripts).
> >
> > For the 2.5 release, the recommendation is to always use absolute
> > imports in any module that is intended to be used as a main module.
> > The ``-m`` switch already provides a benefit here, as it inserts the
> > current directory into ``sys.path``, instead of the directory containing
> > the main module. This means that it is possible to run a module from
> > inside a package using ``-m`` so long as the current directory contains
> > the top level directory for the package. Absolute imports will work
> > correctly even if the package isn't installed anywhere else on
> > sys.path. If the module is executed directly and uses absolute imports
> > to retrieve its sibling modules, then the top level package directory
> > needs to be installed somewhere on sys.path (since the current directory
> > won't be added automatically).
> >
> > Here's an example file layout::
> >
> >      devel/
> >          pkg/
> >              __init__.py
> >              moduleA.py
> >              moduleB.py
> >              test/
> >                  __init__.py
> >                  test_A.py
> >                  test_B.py
> >
> > So long as the current directory is ``devel``, or ``devel`` is already
> > on ``sys.path`` and the test modules use absolute imports (such as
> > ``import pkg.moduleA`` to retrieve the module under test, PEP 338
> > allows the tests to be run as::
> >
> >      python -m pkg.test.test_A
> >      python -m pkg.test.test_B
> >
> > Rationale for Change
> > ====================
> >
> > In rejecting PEP 3122 (which proposed a higher impact solution to this
> > problem), Guido has indicated that he still isn't particularly keen on
> > the idea of executing modules inside packages as scripts [2]. Despite
> > these misgivings he has previously approved the addition of the ``-m``
> > switch in Python 2.4, and the ``runpy`` module based enhancements
> > described in PEP 338 for Python 2.5.
> >
> > The philosophy that motivated those previous additions (i.e. access to
> > utility or testing scripts without needing to worry about name clashes in
> > either the OS executable namespace or the top level Python namespace) is
> > also the motivation behind fixing what I see as a bug in the current
> > implementation.
> >
> > This PEP is intended to provide a solution which permits explicit
> > relative imports from main modules, without incurring any significant
> > costs during interpreter startup or normal module import.
> >
> >
> > Proposed Solution
> > =================
> >
> > The heart of the proposed solution is a new module attribute
> > ``__package_name__``. This attribute will be defined only in
> > the main module (i.e. modules where ``__name__ == "__main__"``).
> >
> > For a directly executed main module, this attribute will be set
> > to the empty string. For a module executed using
> > ``runpy.run_module()`` with the ``run_name`` parameter set to
> > ``"__main__"``, the attribute will be set to
> > ``mod_name.rpartition('.')[0]`` (i.e., everything up to
> > but not including the last period).
> >
> > In the import machinery there is an error handling path which
> > deals with the case where an explicit relative reference attempts
> > to go higher than the top level in the package hierarchy. This
> > error path would be changed to fall back on the ``__package_name__``
> > attribute for explicit relative imports when the importing module
> > is called ``"__main__"``.
> >
> > With this change, explicit relative imports will work automatically
> > from a script executed with the ``-m`` switch. To allow direct
> > execution of the module, the following boilerplate would be needed at
> > the top of the script::
> >
> >    if __name__ == "__main__" and not __package_name__:
> >        __package_name__ = "<expected_pkg_name>"
> >
> > Note that this boilerplate is sufficient only if the top level package
> > is already accessible via sys.path. Additional code that manipulates
> > sys.path would be needed in order for direct execution to work
> > without the top level package already being on sys.path.
> >
> > This approach also has the same disadvantage as the use of absolute
> > imports of sibling modules - if the script is moved to a different
> > package or subpackage, the boilerplate will need to be updated
> > manually.
> >
> > With this feature in place, the test scripts in the package above
> > would be able to change their import lines to something along the
> > lines of ``import ..moduleA``. The scripts could then be
> > executed unmodified even if the name of the package was changed.
> >
> > (Rev 47142 in SVN implemented an early variant of this proposal
> > which stored the main module's real module name in the
> > '__module_name__' attribute. It was reverted due to the fact
> > that 2.5 was already in beta by that time.)
> >
> >
> > Alternative Proposals
> > =====================
> >
> > PEP 3122 proposed addressing this problem by changing the way
> > the main module is identified. That's a huge compatibility cost
> > to incur to fix something that is a pretty minor bug in the overall
> > scheme of things.
> >
> > The advantage of the proposal in this PEP is that its only impact on
> > normal code is the tiny amount of time needed at startup to set the extra
> > attribute in the main module. The changes to the import machinery are all
> > in an existing error handling path, so normal imports don't incur any
> > performance penalty at all.
> >
> >
> > References
> > ==========
> >
> > .. [1] Absolute/relative import not working?
> >     (http://www.python.org/sf/1510172)
> >
> > .. [2] Guido's rejection of PEP 3122
> >     (http://mail.python.org/pipermail/python-3000/2007-April/006793.html)
> >
> > .. [3] c.l.p. question about modules and relative imports
> >
> > (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c44c769a72ca69fa/)
> >
> > Copyright
> > =========
> >
> > This document has been placed in the public domain.
> >
> > --
> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> > ---------------------------------------------------------------
> >              http://www.boredomandlaziness.org
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Thu Jul  5 12:05:01 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 5 Jul 2007 12:05:01 +0200
Subject: [Python-Dev] Adding NetworkIOError for bug 1706815
In-Reply-To: <20070705064829.GJ5055@electricrain.com>
References: <20070704065843.GG5055@electricrain.com>
	<ca471dc20707040203k4ef4395aj9ef51fd78aa9eb5c@mail.gmail.com>
	<20070705064829.GJ5055@electricrain.com>
Message-ID: <ca471dc20707050305t4993e086nd16866458198455@mail.gmail.com>

On 7/5/07, Gregory P. Smith <greg at electricrain.com> wrote:
> On Wed, Jul 04, 2007 at 11:03:42AM +0200, Guido van Rossum wrote:
> > Why not simply inherit socket.error from EnvironmentError?
>
> True, that would be simpler; is it enough?  If we avoid adding the new
> exception, I really think it should inherit from IOError, not
> EnviromnentError because sockets are I/O.  urllib2.URLError was
> already a child of IOError; doing the same to to socket.error makes
> sense.

OTOH, when os.read() returns an error, os.error (OSError) is raised.
Is that not I/O?

IMO this is all hairsplitting, and the exact inheritance hierarchy for
these doesn't matter much -- nobody is going to write a handler that
treats OSError or socket.error different than IOError.

(If you have different call sites that raise different exceptions,
each call site should have a separate try/except rather than a single
try/except with multiple handlers.)

> The patch makes URLError a child of NetworkIOError instead of IOError.
> Does that make sense?  URLs as an abstract concept may or may not
> imply network I/O behind the scenes though network i/o is the most
> common use.  I could take that argument further and suggest they don't
> necessarily even imply actual I/O if you've provided your own protocol
> handlers.

Well, as long as NetworkIOError inherits from IOError, the change is
compatible, but I don't think anyone would care. Making URLError a
child of EnvironmentError or socket.error could be defended too, and I
doubt it makes a difference for any real code. (Anyone with evidence
to the contrary, please speak up now).

> The question then becomes if there are any use cases for "except
> NetworkIOError:" that code wouldn't want to just use "except IOError:"
> for that using "except socket.error:" or "except urllib2.URLError:"
> are insufficient for.  My intuition is telling me: probably not.
> urllib2 code should catch socket.error everywhere internally and turn
> it into a URLError (the code appears to do this in many places though
> i haven't audited that it does everywhere).

Hm. I'm no fan of such renaming of exceptions (even though the
__cause__ mechanism from PEP 3134 (formerly 344) makes it a little
less problematic).

> -greg
>
> PS for the person complaining that the url didn't work.  blame
>    sourceforge and go look the bug up by id yourself.  nothing i can
>    do about that.

Try python.org/sf/1706815

--Guido

> > On 7/4/07, Gregory P. Smith <greg at electricrain.com> wrote:
> > >In response to bug 1706815 and seeing messy code to catch errors in
> > >network apps I've implemented most of the ideas in the bug and added a
> > >NetworkIOError exception (child of IOError).  With this, socket.error
> > >would now inherit from NetworkIOError instead of being its own thing
> > >(the old one didn't even declare a parent!).
> > >
> > >Complete patch attached to the bug.  All unit tests pass.
> > >Documentation updates included.
> > >
> > > http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470
> > >
> > >Any thoughts?  I'm happy with it and would like to commit it if folks
> > >agree.
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From oodi at comcast.net  Wed Jul  4 20:33:42 2007
From: oodi at comcast.net (Oodi Pilzer)
Date: Wed, 4 Jul 2007 14:33:42 -0400
Subject: [Python-Dev] IDLE Functionality
Message-ID: <006d01c7be69$d961b050$ec7d8018@D2BV8W41>

Hi, I am trying to duplicate the indenting functionality of the IDLE into another environment used in an educational setting at MIT.  As Python is open software, I assume I can look at the source code for the IDLE.  If someone could kindly give me a pointer as to where I might find the source code for this functionality, I would very much appreciate it.

Thank you very much,
Beth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070704/9594e6b5/attachment.html 

From ncoghlan at gmail.com  Thu Jul  5 17:38:07 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 06 Jul 2007 01:38:07 +1000
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <ca471dc20707050254v90d1eagdc9a171f227e0ad7@mail.gmail.com>
References: <468B97E5.7070800@gmail.com>	
	<ca471dc20707050253q2bd8ee1bi4a954bb1702c6947@mail.gmail.com>
	<ca471dc20707050254v90d1eagdc9a171f227e0ad7@mail.gmail.com>
Message-ID: <468D105F.4080502@gmail.com>

Guido van Rossum wrote:
> Oh, one more thing. Perhaps we should rename it, like the other PEPs
> still active slated for inclusion in Py3k (and backporting to 2.6)?

Might as well be consistent - I'll take care of that when I update the 
PEP based on your suggestions.

> On 7/5/07, Guido van Rossum <guido at python.org> wrote:
>> I see no big problems with this, except I wonder if in the end it
>> wouldn't be better to *always* define __package_name__ instead of only
>> when it's in main? And then perhaps rename it to __package__? Done
>> properly it could always be used for relative imports, rather than
>> parsing __module__ to find the package. Then you won't even need the
>> error handler.

I'll have a look at what would be involved in always defining 
__package__ and using it for relative imports. I suspect it will be a 
slightly bigger change than the current PEP (i.e. more lines/files 
touched), but not significantly so.

>> FWIW, I find the PEP is rather wordy for such a simple proposal (it
>> took me more time to find the proposal than to understand it :-).

Yeah, I still haven't come up with a particularly concise way of 
explaining why relative imports don't currently work in main modules.

I'll rearrange the PEP to put the proposed fix before the detailed 
explanation of the problem (in fact, given that the latter is mainly of 
historical interest now, I may just include a pointer to the relevant 
section of PEP 338).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From pje at telecommunity.com  Thu Jul  5 18:24:44 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 05 Jul 2007 12:24:44 -0400
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <ca471dc20707050253q2bd8ee1bi4a954bb1702c6947@mail.gmail.co
 m>
References: <468B97E5.7070800@gmail.com>
	<ca471dc20707050253q2bd8ee1bi4a954bb1702c6947@mail.gmail.com>
Message-ID: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>

At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
>I see no big problems with this, except I wonder if in the end it
>wouldn't be better to *always* define __package_name__ instead of only
>when it's in main? And then perhaps rename it to __package__? Done
>properly it could always be used for relative imports, rather than
>parsing __module__ to find the package. Then you won't even need the
>error handler.

+1 for __package__, and putting it everywhere.  Relative import 
should use it first if present, falling back to use of __name__.


From brett at python.org  Thu Jul  5 19:17:51 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 5 Jul 2007 10:17:51 -0700
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>
References: <468B97E5.7070800@gmail.com>
	<ca471dc20707050253q2bd8ee1bi4a954bb1702c6947@mail.gmail.com>
	<20070705162235.5F16A3A405F@sparrow.telecommunity.com>
Message-ID: <bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>

On 7/5/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
> >I see no big problems with this, except I wonder if in the end it
> >wouldn't be better to *always* define __package_name__ instead of only
> >when it's in main? And then perhaps rename it to __package__? Done
> >properly it could always be used for relative imports, rather than
> >parsing __module__ to find the package. Then you won't even need the
> >error handler.
>
> +1 for __package__, and putting it everywhere.  Relative import
> should use it first if present, falling back to use of __name__.

+1 from me as well.

-Brett

From tjreedy at udel.edu  Thu Jul  5 23:00:57 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 5 Jul 2007 17:00:57 -0400
Subject: [Python-Dev] IDLE Functionality
References: <006d01c7be69$d961b050$ec7d8018@D2BV8W41>
Message-ID: <f6jm69$81j$1@sea.gmane.org>


"Oodi Pilzer" <oodi at comcast.net> wrote in message 
news:006d01c7be69$d961b050$ec7d8018 at D2BV8W41...
Hi, I am trying to duplicate the indenting functionality of the IDLE into 
another environment used in an educational setting at MIT.  As Python is 
open software, I assume I can look at the source code for the IDLE.  If 
someone could kindly give me a pointer as to where I might find the source 
code for this functionality, I would very much appreciate it.

--------------------------------------------------------------------------------

After installation, .../Python2.x/Lib/idlelib/*.py are the IDLE source 
files.
For indentation, I would first look in EditorWindow.py.

tjr






From grig.gheorghiu at gmail.com  Fri Jul  6 06:17:38 2007
From: grig.gheorghiu at gmail.com (Grig Gheorghiu)
Date: Thu, 5 Jul 2007 21:17:38 -0700
Subject: [Python-Dev] Error trying to access community buildbot page
Message-ID: <3f09d5a00707052117m40f463a0h43d3a3a39593fcab@mail.gmail.com>

When I go to

http://www.python.org/dev/buildbot/community/all/

I get a 503 error "Service Temporarily Unavailable".

Can anybody shed some light?

Thanks,

Grig

-- 
http://agiletesting.blogspot.com

From martin at v.loewis.de  Fri Jul  6 09:36:00 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 06 Jul 2007 09:36:00 +0200
Subject: [Python-Dev] Error trying to access community buildbot page
In-Reply-To: <3f09d5a00707052117m40f463a0h43d3a3a39593fcab@mail.gmail.com>
References: <3f09d5a00707052117m40f463a0h43d3a3a39593fcab@mail.gmail.com>
Message-ID: <468DF0E0.6010406@v.loewis.de>

Grig Gheorghiu schrieb:
> When I go to
> 
> http://www.python.org/dev/buildbot/community/all/
> 
> I get a 503 error "Service Temporarily Unavailable".
> 
> Can anybody shed some light?

The community buildbot had stopped working since the
last reboot, because the crontab line to restart it
at reboot was incorrect; nobody had noticed so far
(i.e. since June 21).

Regards,
Martin

From loupgaroublond at gmail.com  Fri Jul  6 15:45:55 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 6 Jul 2007 09:45:55 -0400
Subject: [Python-Dev] Fwd: [ python-Patches-1744382 ] Read Write lock
In-Reply-To: <E1I4guK-0003Qv-GU@sc8-sf-web22.sourceforge.net>
References: <E1I4guK-0003Qv-GU@sc8-sf-web22.sourceforge.net>
Message-ID: <7f692fec0707060645s7251b54epfe36c5450e14ac29@mail.gmail.com>

Hi,

I submitted this patch a few days ago, and unfortunately have been
busy to reply, but now it's Friday :).
<snip>

Patches item #1744382, was opened at 2007-06-27 20:08
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744382&group_id=5470

<snip>

The patch is unacceptable in its current form:
- it should be provided as a patch to threading.py, not as a separate
module
- it should have a name that follows "the convention", which seems to be
that
  it should have "reader" and "writer" in its name (or "rw"). See how C#
and
  Java do it (and other libraries you can find that provide such a
mechanism)
- it needs documentation
- it needs tests.

<snip>

I can do the other three parts, but I am wondering, how do I write a
deterministic test unit for my patch?  How is it done with the
threading model in python in general?


Cheers,
Yaakov

From howarth at bromo.msbb.uc.edu  Fri Jul  6 15:39:12 2007
From: howarth at bromo.msbb.uc.edu (Jack Howarth)
Date: Fri, 6 Jul 2007 09:39:12 -0400
Subject: [Python-Dev] 2.5.2 schedule?
Message-ID: <20070706133912.GA10956@bromo.msbb.uc.edu>

   I was wondering if there is a schedule for the
release of a python 2.5.2 update? I don't see anything
like that on the www.python.org web site. Thanks in
advance for any information.
              Jack

From jcarlson at uci.edu  Fri Jul  6 17:10:59 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Fri, 06 Jul 2007 08:10:59 -0700
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>
References: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>
	<bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>
Message-ID: <20070706080601.8C3B.JCARLSON@uci.edu>


"Brett Cannon" <brett at python.org> wrote:
> On 7/5/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
> > >I see no big problems with this, except I wonder if in the end it
> > >wouldn't be better to *always* define __package_name__ instead of only
> > >when it's in main? And then perhaps rename it to __package__? Done
> > >properly it could always be used for relative imports, rather than
> > >parsing __module__ to find the package. Then you won't even need the
> > >error handler.
> >
> > +1 for __package__, and putting it everywhere.  Relative import
> > should use it first if present, falling back to use of __name__.
> 
> +1 from me as well.

This would solve some issues I'm currently having with relative imports. 
+1

 - Josiah


From mike.klaas at gmail.com  Fri Jul  6 19:47:16 2007
From: mike.klaas at gmail.com (Mike Klaas)
Date: Fri, 6 Jul 2007 10:47:16 -0700
Subject: [Python-Dev] Fwd: [ python-Patches-1744382 ] Read Write lock
In-Reply-To: <7f692fec0707060645s7251b54epfe36c5450e14ac29@mail.gmail.com>
References: <E1I4guK-0003Qv-GU@sc8-sf-web22.sourceforge.net>
	<7f692fec0707060645s7251b54epfe36c5450e14ac29@mail.gmail.com>
Message-ID: <8D54C7E8-F525-4707-94F2-92F59F4A2FF5@gmail.com>

On 6-Jul-07, at 6:45 AM, Yaakov Nemoy wrote:

>
> I can do the other three parts, but I am wondering, how do I write a
> deterministic test unit for my patch?  How is it done with the
> threading model in python in general?

I don't know how it is done in general, but for reference, here are  
some of the unittests for my read/write lock class:

     def testReadCount(self):
         wrlock = ReadWriteLock()
         read, write = wrlock.reader, wrlock.writer

         self.assertEqual(wrlock.readerCount, 0)
         read.acquire()
         self.assertEqual(wrlock.readerCount, 1)
         read.acquire()
         self.assertEqual(wrlock.readerCount, 2)
         read.release()
         self.assertEqual(wrlock.readerCount, 1)
         read.release()
         self.assertEqual(wrlock.readerCount, 0)

     def testContention(self):
         wrlock = ReadWriteLock()
         read, write = wrlock.reader, wrlock.writer

         class Writer(Thread):
             gotit = False
             def run(self):
                 write.acquire()
                 self.gotit = True
                 write.release()
         writer = Writer()

         self.assertEqual(wrlock.readerCount, 0)
         read.acquire()
         self.assertEqual(wrlock.readerCount, 1)
         writer.start()
         self.assertFalse(writer.gotit)

         read.acquire()
         self.assertEqual(wrlock.readerCount, 2)
         self.assertFalse(writer.gotit)

         read.release()
         self.assertEqual(wrlock.readerCount, 1)
         self.assertFalse(writer.gotit)

         read.release()
         self.assertEqual(wrlock.readerCount, 0)
         time.sleep(.1)
         self.assertTrue(writer.gotit)

     def testWRAcquire(self):
         wrlock = ReadWriteLock()
         read, write = wrlock.reader, wrlock.writer

         self.assertEqual(wrlock.readerCount, 0)
         write.acquire()
         write.acquire()
         write.release()
         write.release()

         read.acquire()
         self.assertEqual(wrlock.readerCount, 1)
         read.acquire()
         self.assertEqual(wrlock.readerCount, 2)
         read.release()
         self.assertEqual(wrlock.readerCount, 1)
         read.release()
         self.assertEqual(wrlock.readerCount, 0)
         write.acquire()
         write.release()

     def testOwnAcquire(self):
         wrlock = ReadWriteLock()
         read, write = wrlock.reader, wrlock.writer

         class Writer(Thread):
             gotit = False
             def run(self):
                 write.acquire()
                 self.gotit = True
                 write.release()
         writer = Writer()

         self.assertEqual(wrlock.readerCount, 0)
         read.acquire()
         self.assertEqual(wrlock.readerCount, 1)
         writer.start()
         self.assertFalse(writer.gotit)

         # can acquire the write lock if only
         # this thread has the read lock
         write.acquire()
         write.release()

         read.acquire()
         self.assertEqual(wrlock.readerCount, 2)
         self.assertFalse(writer.gotit)

         read.release()
         self.assertEqual(wrlock.readerCount, 1)
         self.assertFalse(writer.gotit)

         read.release()
         self.assertEqual(wrlock.readerCount, 0)
         time.sleep(.1)
         self.assertTrue(writer.gotit)


     def testDeadlock(self):
         wrlock = ReadWriteLock()
         read, write = wrlock.reader, wrlock.writer

         errors = []

         # a situation which can readily deadlock if care isn't taken
         class LockThread(threading.Thread):
             def __init__(self):
                 threading.Thread.__init__(self)
                 self.q = Queue.Queue()
             def run(self):
                 while True:
                     task, lock, delay = self.q.get()
                     if not task:
                         break
                     time.sleep(delay)
                     if task == 'acquire':
                         for delay in waittime(maxTime=5.0):
                             if lock.acquire(False):
                                 break
                             time.sleep(delay)
                         else:
                             errors.append("Couldn't acquire %s" % str 
(lock))
                     else:
                         lock.release()

         thrd = LockThread()
         thrd.start()

         thrd.q.put(('acquire', read, 0))
         time.sleep(.2)
         read.acquire()
         thrd.q.put(('acquire', write, 0))
         thrd.q.put(('release', write, .5))
         thrd.q.put(('release', read, 0))
         write.acquire()
         time.sleep(0.0)
         write.release()
         read.release()

         # end
         thrd.q.put((None, None, None))
         thrd.join()

         self.assertFalse(errors, "Errors: %s" % errors)


From exarkun at divmod.com  Fri Jul  6 20:26:23 2007
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Fri, 6 Jul 2007 14:26:23 -0400
Subject: [Python-Dev] Fwd: [ python-Patches-1744382 ] Read Write lock
In-Reply-To: <8D54C7E8-F525-4707-94F2-92F59F4A2FF5@gmail.com>
Message-ID: <20070706182623.4947.1143473124.divmod.quotient.8001@ohm>

On Fri, 6 Jul 2007 10:47:16 -0700, Mike Klaas <mike.klaas at gmail.com> wrote:
>On 6-Jul-07, at 6:45 AM, Yaakov Nemoy wrote:
>
>>
>> I can do the other three parts, but I am wondering, how do I write a
>> deterministic test unit for my patch?  How is it done with the
>> threading model in python in general?
>
>I don't know how it is done in general, but for reference, here are
>some of the unittests for my read/write lock class:
>
> [snip]
>
>         read.release()
>         self.assertEqual(wrlock.readerCount, 0)
>         time.sleep(.1)
>         self.assertTrue(writer.gotit)

Not exactly deterministic.  Instead of a flag attribute, try using an Event or
a Condition.  Either of these will let you know exactly when the necessary
operation has completed.

Jean-Paul

From brett at python.org  Fri Jul  6 20:53:56 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 6 Jul 2007 11:53:56 -0700
Subject: [Python-Dev] 2.5.2 schedule?
In-Reply-To: <20070706133912.GA10956@bromo.msbb.uc.edu>
References: <20070706133912.GA10956@bromo.msbb.uc.edu>
Message-ID: <bbaeab100707061153r4655b269v27e4acdb8a20ca9b@mail.gmail.com>

On 7/6/07, Jack Howarth <howarth at bromo.msbb.uc.edu> wrote:
>    I was wondering if there is a schedule for the
> release of a python 2.5.2 update? I don't see anything
> like that on the www.python.org web site. Thanks in
> advance for any information.

There is no schedule at the moment, no.  It is up to the release
manager (Anthony Baxter) and python-dev to decide if another release
is necessary soon or not.

Having said that, there will very likely be a 2.5 release shortly
after 2.6 is out the door.

-Brett

From greg at electricrain.com  Sat Jul  7 01:01:10 2007
From: greg at electricrain.com (Gregory P. Smith)
Date: Fri, 6 Jul 2007 16:01:10 -0700
Subject: [Python-Dev] Adding NetworkIOError for bug 1706815
In-Reply-To: <ca471dc20707050305t4993e086nd16866458198455@mail.gmail.com>
References: <20070704065843.GG5055@electricrain.com>
	<ca471dc20707040203k4ef4395aj9ef51fd78aa9eb5c@mail.gmail.com>
	<20070705064829.GJ5055@electricrain.com>
	<ca471dc20707050305t4993e086nd16866458198455@mail.gmail.com>
Message-ID: <20070706230109.GN5055@electricrain.com>

On Thu, Jul 05, 2007 at 12:05:01PM +0200, Guido van Rossum wrote:
> On 7/5/07, Gregory P. Smith <greg at electricrain.com> wrote:
> >On Wed, Jul 04, 2007 at 11:03:42AM +0200, Guido van Rossum wrote:
> >> Why not simply inherit socket.error from EnvironmentError?
> >
> >True, that would be simpler; is it enough?  If we avoid adding the new
> >exception, I really think it should inherit from IOError, not
> >EnviromnentError because sockets are I/O.  urllib2.URLError was
> >already a child of IOError; doing the same to to socket.error makes
> >sense.
> 
> OTOH, when os.read() returns an error, os.error (OSError) is raised.
> Is that not I/O?
> 
> IMO this is all hairsplitting, and the exact inheritance hierarchy for
> these doesn't matter much -- nobody is going to write a handler that
> treats OSError or socket.error different than IOError.

Ah.  Given all that, the point of a NetworkIOError is moot.  I had
assumed read would raise an IOError but hadn't read the code.  Looks
like fileobject.c's file_read() raises IOError as I expected but
posixmodule.c's read() raises OSError (fair enough, its the os module).

Since socket objects are treated like file objects in many cases I
think IOError would be a more appropriate parent than
EnvironmentError.  There was a case at work recently that started me
down the path of looking at this where code caught IOError but not
socket.error.

Any objects to me just having socket.error inherit from IOError?

> >PS for the person complaining that the url didn't work.  blame
> >   sourceforge and go look the bug up by id yourself.  nothing i can
> >   do about that.
> 
> Try python.org/sf/1706815
> 
> --Guido

ooo handy.  thanks.

-Greg


From knut at wikstrom.dk  Sat Jul  7 10:22:03 2007
From: knut at wikstrom.dk (=?ISO-8859-1?Q?=22Knut_A=2E_Wikstr=F6m=22?=)
Date: Sat, 07 Jul 2007 10:22:03 +0200
Subject: [Python-Dev] Python for embedding?
Message-ID: <468F4D2B.8030805@wikstrom.dk>

Python is a great language. We all know. But I have tried implementing 
Python into C/C++ applications, and have a) had a lot of trouble getting 
it running properly and b) it is slow, compared to other languages, like 
LUA.

What is my idea, is to make a Python implementation made to be embedded 
into applications.. It will have these features:
a) Small footprint.
b) Easy-to-use, but still advanced API.
c) Stackless.
d) A smaller standard library.
e) Fast.

The smaller footprint is, so that it will use minimal resources 
possible, leaving more for the underlying application.
The API is the most important thing, really, as this distro will be made 
for embedding. It will not have any compiler features, just an interpreter.
Stackless Python is - as we know - faster than Python. Another good 
reason to use it in embedding.
A lot of the standard library is seldom used; we only need the core 
functions.
Fast, of course! It needs to be the fastest interpreter ever written (at 
least fast).

Hope you have any ideas/comments!
~Knut

From aahz at pythoncraft.com  Sat Jul  7 15:23:16 2007
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 7 Jul 2007 06:23:16 -0700
Subject: [Python-Dev] Python for embedding?
In-Reply-To: <468F4D2B.8030805@wikstrom.dk>
References: <468F4D2B.8030805@wikstrom.dk>
Message-ID: <20070707132316.GA14928@panix.com>

On Sat, Jul 07, 2007, "Knut A. Wikstr?m" wrote:
>
> Python is a great language. We all know. But I have tried implementing 
> Python into C/C++ applications, and have a) had a lot of trouble getting 
> it running properly and b) it is slow, compared to other languages, like 
> LUA.

This thread should go into either comp.lang.python or the python-ideas
mailing list.  python-dev is for discussions about the implementation of
current python.  Thanks.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

I support the RKAB

From barry at python.org  Sat Jul  7 15:38:44 2007
From: barry at python.org (Barry Warsaw)
Date: Sat, 7 Jul 2007 09:38:44 -0400
Subject: [Python-Dev] Python for embedding?
In-Reply-To: <20070707132316.GA14928@panix.com>
References: <468F4D2B.8030805@wikstrom.dk> <20070707132316.GA14928@panix.com>
Message-ID: <1C71A51F-EECA-404A-AFD7-D18E7CF29DA8@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 7, 2007, at 9:23 AM, Aahz wrote:

> On Sat, Jul 07, 2007, "Knut A. Wikstr?m" wrote:
>>
>> Python is a great language. We all know. But I have tried  
>> implementing
>> Python into C/C++ applications, and have a) had a lot of trouble  
>> getting
>> it running properly and b) it is slow, compared to other  
>> languages, like
>> LUA.
>
> This thread should go into either comp.lang.python or the python-ideas
> mailing list.  python-dev is for discussions about the  
> implementation of
> current python.  Thanks.

There is also the new C/API sig:

http://mail.python.org/mailman/listinfo/capi-sig

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRo+XZHEjvBPtnXfVAQLjlwP/bv88BGiPr/A9jxFEHuiscCb1viEelnA9
R6zHiWHt4JkeR65P8Vtc20Ev+rigmqrmSTSn4usgf57pceZsZOMXmuH1aK4Pwd/2
jGRDdsxCK4ePItWHuJHdjO7w7Ddz5jJTTxpNNmtH+lNyqzeQTqxF9otlCX7L5LLJ
jKHRrVk3e2g=
=X+O6
-----END PGP SIGNATURE-----

From gjcarneiro at gmail.com  Sat Jul  7 16:01:33 2007
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Sat, 7 Jul 2007 15:01:33 +0100
Subject: [Python-Dev] Python 2.6 BaseException.message deprecation,
	really needed?
Message-ID: <a467ca4f0707070701va6e5a54i987749f2741a7dec@mail.gmail.com>

In PyGObject we want to use a 'message' attribute in an exception defined by
us.  The name 'message' comes from a C API, therefore we would like to keep
it for easier mapping between C and Python APIs.  Why does Python have to
deprecate this attribute?

.../gobject/option.py:187: DeprecationWarning: BaseException.message has
been deprecated as of Python 2.6
  gerror.message = str(error)

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070707/c94aa2bb/attachment.html 

From status at bugs.python.org  Sun Jul  8 02:00:46 2007
From: status at bugs.python.org (Tracker)
Date: Sun,  8 Jul 2007 00:00:46 +0000 (UTC)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20070708000046.E82AC78176@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (07/01/07 - 07/08/07)
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.


 1645 open ( +0) /  8584 closed ( +0) / 10229 total ( +0)

Average duration of open issues: 850 days.
Median duration of open issues: 798 days.

Open Issues Breakdown
   open  1645 ( +0)
pending     0 ( +0)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070708/eea64e13/attachment.html 

From brett at python.org  Sun Jul  8 02:42:18 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 7 Jul 2007 17:42:18 -0700
Subject: [Python-Dev] Python 2.6 BaseException.message deprecation,
	really needed?
In-Reply-To: <a467ca4f0707070701va6e5a54i987749f2741a7dec@mail.gmail.com>
References: <a467ca4f0707070701va6e5a54i987749f2741a7dec@mail.gmail.com>
Message-ID: <bbaeab100707071742m28facda7kcacbf8a57c4aabc9@mail.gmail.com>

On 7/7/07, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> In PyGObject we want to use a 'message' attribute in an exception defined by
> us.  The name 'message' comes from a C API, therefore we would like to keep
> it for easier mapping between C and Python APIs.  Why does Python have to
> deprecate this attribute?
>

It's going away in Python 3.0.  In retrospect the attribute was a
mistake thanks to its odd semantics to be backwards compatible in a
reasonable way.  Plus its removal from the code base was nasty mostly
thanks to C-based exceptions.

> .../gobject/option.py:187: DeprecationWarning: BaseException.message has
> been deprecated as of Python 2.6
>   gerror.message = str(error)

You can get around this easily enough with a subclass that uses a
property for message::

  class gerror(Exception):
    def _get_message(self, message): return self._message
    def _set_message(self, message): self._message = message
    message = property(_get_message, _set_message)

-Brett

From fdrake at acm.org  Sun Jul  8 02:51:45 2007
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sat, 7 Jul 2007 20:51:45 -0400
Subject: [Python-Dev] Python 2.6 BaseException.message deprecation,
	really needed?
In-Reply-To: <a467ca4f0707070701va6e5a54i987749f2741a7dec@mail.gmail.com>
References: <a467ca4f0707070701va6e5a54i987749f2741a7dec@mail.gmail.com>
Message-ID: <200707072051.45150.fdrake@acm.org>

On Saturday 07 July 2007, Gustavo Carneiro wrote:
 > In PyGObject we want to use a 'message' attribute in an exception defined
 > by us.  The name 'message' comes from a C API, therefore we would like to
 > keep it for easier mapping between C and Python APIs.  Why does Python
 > have to deprecate this attribute?

It can be deprecated for BaseException without it being deprecated for your 
exception.  You'll need to define a property that overrides the property in 
BaseException; something like this in Python (not tested):

  class MyException(Exception):

      _message = None

      @apply
      def message():

          def get(self):
              return self._message

          def set(self, value):
              self._message = value

          return property(get, set)

I think your use case is entirely reasonable, and can be handled readily.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From steve at holdenweb.com  Sun Jul  8 03:32:40 2007
From: steve at holdenweb.com (Steve Holden)
Date: Sat, 07 Jul 2007 21:32:40 -0400
Subject: [Python-Dev] Summary of Tracker Issues
In-Reply-To: <20070708000046.E82AC78176@psf.upfronthosting.co.za>
References: <20070708000046.E82AC78176@psf.upfronthosting.co.za>
Message-ID: <f6peri$opv$2@sea.gmane.org>

Tracker wrote:
> 
>     ACTIVITY SUMMARY (07/01/07 - 07/08/07)
> 
> 
>       Tracker at http://bugs.python.org/
> 
> To view or respond to any of the issues listed below, simply click on 
> the issue ID. Do *not* respond to this message.
> 
> 1645 open ( +0) / 8584 closed ( +0) / 10229 total ( +0)
> 
> Average duration of open issues: 850 days.
> 
> Median duration of open issues: 798 days.
> 
> Open Issues Breakdown STATUS 	Number	Change
> open	1645	+0
> pending	0	+0
> 
This script appears to have been producing exactly the same output since 
June 9. I can't believe it's useful information.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------


From jcarlson at uci.edu  Sun Jul  8 05:48:03 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sat, 07 Jul 2007 20:48:03 -0700
Subject: [Python-Dev] Summary of Tracker Issues
In-Reply-To: <f6peri$opv$2@sea.gmane.org>
References: <20070708000046.E82AC78176@psf.upfronthosting.co.za>
	<f6peri$opv$2@sea.gmane.org>
Message-ID: <20070707204619.8C48.JCARLSON@uci.edu>


Steve Holden <steve at holdenweb.com> wrote:
> Tracker wrote:
> > 
> >     ACTIVITY SUMMARY (07/01/07 - 07/08/07)
> > 
> > 
> >       Tracker at http://bugs.python.org/
> > 
> > To view or respond to any of the issues listed below, simply click on 
> > the issue ID. Do *not* respond to this message.
> > 
> > 1645 open ( +0) / 8584 closed ( +0) / 10229 total ( +0)
> > 
> > Average duration of open issues: 850 days.
> > 
> > Median duration of open issues: 798 days.
> > 
> > Open Issues Breakdown STATUS 	Number	Change
> > open	1645	+0
> > pending	0	+0
> > 
> This script appears to have been producing exactly the same output since 
> June 9. I can't believe it's useful information.

The bugs.python.org tracker is not yet the official tracker for Python
yet (partially due to the sf.net data dump issue).

 - Josiah


From ncoghlan at gmail.com  Sun Jul  8 09:51:16 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 08 Jul 2007 17:51:16 +1000
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <20070706080601.8C3B.JCARLSON@uci.edu>
References: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>	<bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>
	<20070706080601.8C3B.JCARLSON@uci.edu>
Message-ID: <46909774.7030602@gmail.com>

Josiah Carlson wrote:
> "Brett Cannon" <brett at python.org> wrote:
>> On 7/5/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>>> At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
>>>> I see no big problems with this, except I wonder if in the end it
>>>> wouldn't be better to *always* define __package_name__ instead of only
>>>> when it's in main? And then perhaps rename it to __package__? Done
>>>> properly it could always be used for relative imports, rather than
>>>> parsing __module__ to find the package. Then you won't even need the
>>>> error handler.
>>> +1 for __package__, and putting it everywhere.  Relative import
>>> should use it first if present, falling back to use of __name__.
>> +1 from me as well.
> 
> This would solve some issues I'm currently having with relative imports. 
> +1

I've updated the PEP to incorporate the feedback from this thread. The 
new version is below, and should show up on the website shortly.

Cheers,
Nick.

PEP: 366
Title: Main module explicit relative imports
Version: $Revision: 56190 $
Last-Modified: $Date: 2007-07-08 17:45:46 +1000 (Sun, 08 Jul 2007) $
Author: Nick Coghlan <ncoghlan at gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 2.6, 3.0
Post-History: 1-May-2007, 4-Jul-2007, 7-Jul-2007


Abstract
========

This PEP proposes a backwards compatible mechanism that permits
the use of explicit relative imports from executable modules within
packages. Such imports currently fail due to an awkward interaction
between PEP 328 and PEP 338.

By adding a new module level attribute, this PEP allows relative imports
to work automatically if the module is executed using the ``-m``switch.
A small amount of boilerplate in the module itself will allow the relative
imports to work when the file is executed by name.


Proposed Change
===============

The major proposed change is the introduction of a new module level
attribute, ``__package__``. When it is present, relative imports will
be based on this attribute rather than the module ``__name__``
attribute.

As with the current ``__name__`` attribute, setting ``__package__`` will
be the responsibility of the PEP 302 loader used to import a module.
Loaders which use ``imp.new_module()`` to create the module object will
have the new attribute set automatically to
``__name__.rpartition('.')[0]``.

``runpy.run_module`` will also set the new attribute, basing it off the
``mod_name`` argument, rather than the ``run_name`` argument. This will
allow relative imports to work correctly from main modules executed with
the ``-m`` switch.

When the main module is specified by its filename, then the
``__package__`` attribute will be set to the empty string. To allow
relative imports when the module is executed directly, boilerplate
similar to the following would be needed before the first relative
import statement:

   if __name__ == "__main__" and not __package_name__:
       __package_name__ = "<expected_pacakage_name>"

Note that this boilerplate is sufficient only if the top level package
is already accessible via ``sys.path``. Additional code that manipulates
``sys.path`` would be needed in order for direct execution to work
without the top level package already being importable.

This approach also has the same disadvantage as the use of absolute
imports of sibling modules - if the script is moved to a different
package or subpackage, the boilerplate will need to be updated
manually.


Rationale for Change
====================

The current inability to use explicit relative imports from the main
module is the subject of at least one open SF bug report (#1510172)[1],
and has most likely been a factor in at least a few queries on
comp.lang.python (such as Alan Isaac's question in [2]).

This PEP is intended to provide a solution which permits explicit
relative imports from main modules, without incurring any significant
costs during interpreter startup or normal module import.

The section in PEP 338 on relative imports and the main module provides
further details and background on this problem.


Reference Implementation
========================

Rev 47142 in SVN implemented an early variant of this proposal
which stored the main module's real module name in the
'__module_name__' attribute. It was reverted due to the fact
that 2.5 was already in beta by that time.

A new patch will be developed for 2.6, and forward ported to
Py3k via svnmerge.


Alternative Proposals
=====================

PEP 3122 proposed addressing this problem by changing the way
the main module is identified. That's a significant compatibility cost
to incur to fix something that is a pretty minor bug in the overall
scheme of things, and the PEP was rejected [3].

The advantage of the proposal in this PEP is that its only impact on
normal code is the small amount of time needed to set the extra
attribute when importing a module. Relative imports themselves should
be sped up fractionally, as the package name is stored in the module
globals, rather than having to be worked out again for each relative
import.


References
==========

.. [1] Absolute/relative import not working?
    (http://www.python.org/sf/1510172)

.. [2] c.l.p. question about modules and relative imports
 
(http://groups.google.com/group/comp.lang.python/browse_thread/thread/c44c769a72ca69fa/)

.. [3] Guido's rejection of PEP 3122
    (http://mail.python.org/pipermail/python-3000/2007-April/006793.html)


Copyright
=========

This document has been placed in the public domain.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From walter at livinglogic.de  Sun Jul  8 11:38:22 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Sun, 08 Jul 2007 11:38:22 +0200
Subject: [Python-Dev] itertools addition: getitem()
Message-ID: <4690B08E.3010501@livinglogic.de>

I'd like to propose the following addition to itertools: A function 
itertools.getitem() which is basically equivalent to the following 
python code:

_default = object()

def getitem(iterable, index, default=_default):
    try:
       return list(iterable)[index]
    except IndexError:
       if default is _default:
          raise
       return default

but without materializing the complete list. Negative indexes are 
supported too (this requires additional temporary storage for abs(index) 
objects).

The patch is available at http://bugs.python.org/1749857

Servus,
    Walter

From martin at v.loewis.de  Sun Jul  8 12:02:19 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 08 Jul 2007 12:02:19 +0200
Subject: [Python-Dev] Python for embedding?
In-Reply-To: <468F4D2B.8030805@wikstrom.dk>
References: <468F4D2B.8030805@wikstrom.dk>
Message-ID: <4690B62B.9000509@v.loewis.de>

> What is my idea, is to make a Python implementation made to be embedded 
> into applications.. 
> 
> Hope you have any ideas/comments!

My main question: Who will implement that idea? Ideas are cheap;
making them come true is a lot of work.

It seems that you believe the current implementation of Python
is *deliberately* slow, and that a new implementation would
necessarily be faster. Please rest assured that this is not
the case: people have put a considerable amount of work into
making Python as fast as it is today.

Regards,
Martin

From guido at python.org  Sun Jul  8 13:31:07 2007
From: guido at python.org (Guido van Rossum)
Date: Sun, 8 Jul 2007 13:31:07 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <4690B08E.3010501@livinglogic.de>
References: <4690B08E.3010501@livinglogic.de>
Message-ID: <ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>

How important is it to have the default in this API? __getitem__()
doesn't have a default; instead, there's a separate API get() that
provides a default (and I find defaulting to None more manageable than
the "_default = object()" pattern).

--Guido

On 7/8/07, Walter D?rwald <walter at livinglogic.de> wrote:
> I'd like to propose the following addition to itertools: A function
> itertools.getitem() which is basically equivalent to the following
> python code:
>
> _default = object()
>
> def getitem(iterable, index, default=_default):
>     try:
>        return list(iterable)[index]
>     except IndexError:
>        if default is _default:
>           raise
>        return default
>
> but without materializing the complete list. Negative indexes are
> supported too (this requires additional temporary storage for abs(index)
> objects).
>
> The patch is available at http://bugs.python.org/1749857
>
> Servus,
>     Walter
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From g.brandl at gmx.net  Sun Jul  8 13:33:55 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 08 Jul 2007 13:33:55 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>
References: <4690B08E.3010501@livinglogic.de>
	<ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>
Message-ID: <f6qi33$4c0$1@sea.gmane.org>

Guido van Rossum schrieb:
> How important is it to have the default in this API? __getitem__()
> doesn't have a default; instead, there's a separate API get() that
> provides a default (and I find defaulting to None more manageable than
> the "_default = object()" pattern).

getattr() has a default too, while __getattr__ hasn't...

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.


From guido at python.org  Sun Jul  8 13:49:23 2007
From: guido at python.org (Guido van Rossum)
Date: Sun, 8 Jul 2007 13:49:23 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <f6qi33$4c0$1@sea.gmane.org>
References: <4690B08E.3010501@livinglogic.de>
	<ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>
	<f6qi33$4c0$1@sea.gmane.org>
Message-ID: <ca471dc20707080449l4a5b6fbdjff974d512fcae689@mail.gmail.com>

On 7/8/07, Georg Brandl <g.brandl at gmx.net> wrote:
> Guido van Rossum schrieb:
> > How important is it to have the default in this API? __getitem__()
> > doesn't have a default; instead, there's a separate API get() that
> > provides a default (and I find defaulting to None more manageable than
> > the "_default = object()" pattern).
>
> getattr() has a default too, while __getattr__ hasn't...

Fair enough.

But I still want to hear of a practical use case for the default here.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From walter at livinglogic.de  Sun Jul  8 15:30:37 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Sun, 08 Jul 2007 15:30:37 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <ca471dc20707080449l4a5b6fbdjff974d512fcae689@mail.gmail.com>
References: <4690B08E.3010501@livinglogic.de>	<ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>	<f6qi33$4c0$1@sea.gmane.org>
	<ca471dc20707080449l4a5b6fbdjff974d512fcae689@mail.gmail.com>
Message-ID: <4690E6FD.50002@livinglogic.de>

Guido van Rossum wrote:
> On 7/8/07, Georg Brandl <g.brandl at gmx.net> wrote:
>> Guido van Rossum schrieb:
>>> How important is it to have the default in this API? __getitem__()
>>> doesn't have a default; instead, there's a separate API get() that
>>> provides a default (and I find defaulting to None more manageable than
>>> the "_default = object()" pattern).

Of course it isn't implemented this way in the C version.

>> getattr() has a default too, while __getattr__ hasn't...
> 
> Fair enough.
> 
> But I still want to hear of a practical use case for the default here.

In most cases

    foo = getitem(iterable, 0, None)
    if foo is not None:
       ...

is simpler than:

    try:
       foo = getitem(iterable, 0)
    except IndexError:
       pass
    else:
       ...

Here is a use case from one of my "import XML into the database" scripts:

    compid = getitem(root[ns.Company_company_id], 0, None)
    if compid:
       compid = int(compid)

The expression root[ns.company_id] returns an iterator that produces all 
children of the root node that are of the element type company_id. If 
there is a company_id its content will be turned into an int, if not 
None will be used.

Servus,
    Walter


From guido at python.org  Sun Jul  8 16:49:45 2007
From: guido at python.org (Guido van Rossum)
Date: Sun, 8 Jul 2007 16:49:45 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <4690E6FD.50002@livinglogic.de>
References: <4690B08E.3010501@livinglogic.de>
	<ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>
	<f6qi33$4c0$1@sea.gmane.org>
	<ca471dc20707080449l4a5b6fbdjff974d512fcae689@mail.gmail.com>
	<4690E6FD.50002@livinglogic.de>
Message-ID: <ca471dc20707080749q41e0a00eyc3b99629d8801aa0@mail.gmail.com>

On 7/8/07, Walter D?rwald <walter at livinglogic.de> wrote:
[quoting Guido]
> > But I still want to hear of a practical use case for the default here.
>
> In most cases
>
>     foo = getitem(iterable, 0, None)
>     if foo is not None:
>        ...
>
> is simpler than:
>
>     try:
>        foo = getitem(iterable, 0)
>     except IndexError:
>        pass
>     else:
>        ...
>
> Here is a use case from one of my "import XML into the database" scripts:
>
>     compid = getitem(root[ns.Company_company_id], 0, None)
>     if compid:
>        compid = int(compid)
>
> The expression root[ns.company_id] returns an iterator that produces all
> children of the root node that are of the element type company_id. If
> there is a company_id its content will be turned into an int, if not
> None will be used.

Ahem. I hope you have a better use case for getitem() than that
(regardless of the default issue). I find it clearer to write that as

try:
  compid = root[ns.company_id].next()
except StopIteration:
  compid = None
else:
  compid = int(compid)

While this is more lines, it doesn't require one to know about
getitem() on an iterator. This is the same reason why setdefault() was
a mistake -- it's too obscure to invent a compact spelling for it
since the compact spelling has to be learned or looked up.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From bioinformed at gmail.com  Sun Jul  8 17:49:59 2007
From: bioinformed at gmail.com (Kevin Jacobs <jacobs@bioinformed.com>)
Date: Sun, 8 Jul 2007 11:49:59 -0400
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <ca471dc20707080749q41e0a00eyc3b99629d8801aa0@mail.gmail.com>
References: <4690B08E.3010501@livinglogic.de>
	<ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>
	<f6qi33$4c0$1@sea.gmane.org>
	<ca471dc20707080449l4a5b6fbdjff974d512fcae689@mail.gmail.com>
	<4690E6FD.50002@livinglogic.de>
	<ca471dc20707080749q41e0a00eyc3b99629d8801aa0@mail.gmail.com>
Message-ID: <2e1434c10707080849r38a5e295s605df338304fd38e@mail.gmail.com>

On 7/8/07, Guido van Rossum <guido at python.org> wrote:
>
> Ahem. I hope you have a better use case for getitem() than that
> (regardless of the default issue). I find it clearer to write that as
>
> try:
>   compid = root[ns.company_id].next()
> except StopIteration:
>   compid = None
> else:
>   compid = int(compid)
>
> While this is more lines, it doesn't require one to know about
> getitem() on an iterator. This is the same reason why setdefault() was
> a mistake -- it's too obscure to invent a compact spelling for it
> since the compact spelling has to be learned or looked up.
>


Apropos of this discussion, I've occasionally wanted a faster version of the
following:

_nothing=object()

def nth_next(seq,n,default=_nothing):
  '''
  Return the n'th next element for seq, if it exists.

  If default is specified, it is return when the sequence is too short.
  Otherwise StopIteration is raised.
  '''
  try:
    for i in xrange(n-1):
      seq.next()
    return seq.next()
  except StopIteration:
    if default is _nothing:
      raise
    return default

The nice thing about this function is that it solves several problems in
one: extraction of the n'th next element, testing for a minimum sequence
length given a sentinel value, and just skipping n elements.  It also leaves
the sequence in a useful and predictable state, which is not true of the
Python-version getitem code.  While cute, I can't say if it is worthy of
being an itertool function.

Also vaguely apropos:

def ilen(seq):
  'Return the length of the hopefully finite sequence'
  n = 0
  for x in seq:
    n += 1
  return n

Why?  Because I find myself implementing it in virtually every project.
Maybe I'm just an outlier, but many algorithms I implement need to consume
iterators (for side-effects, obviously) and it is sometimes nice to know
exactly how many elements were consumed.

~Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070708/af8ba064/attachment.htm 

From steven.bethard at gmail.com  Sun Jul  8 17:56:04 2007
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sun, 8 Jul 2007 09:56:04 -0600
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <2e1434c10707080849r38a5e295s605df338304fd38e@mail.gmail.com>
References: <4690B08E.3010501@livinglogic.de>
	<ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>
	<f6qi33$4c0$1@sea.gmane.org>
	<ca471dc20707080449l4a5b6fbdjff974d512fcae689@mail.gmail.com>
	<4690E6FD.50002@livinglogic.de>
	<ca471dc20707080749q41e0a00eyc3b99629d8801aa0@mail.gmail.com>
	<2e1434c10707080849r38a5e295s605df338304fd38e@mail.gmail.com>
Message-ID: <d11dcfba0707080856w3b5649bcq2dd8b6b6dec6ac72@mail.gmail.com>

On 7/8/07, Kevin Jacobs <jacobs at bioinformed.com> <bioinformed at gmail.com> wrote:
> Also vaguely apropos:
>
> def ilen(seq):
>   'Return the length of the hopefully finite sequence'
>   n = 0
>   for x in seq:
>      n += 1
>   return n

Also known as::

    sum(1 for _ in iterable)

That's always been simple enough that I didn't feel a need for an
ilen() function.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From pogonyshev at gmx.net  Sun Jul  8 19:23:19 2007
From: pogonyshev at gmx.net (Paul Pogonyshev)
Date: Sun, 8 Jul 2007 20:23:19 +0300
Subject: [Python-Dev] proposed attribute lookup optimization
Message-ID: <200707082023.19837.pogonyshev@gmx.net>

Hi,

I would like to propose an optimization (I think so, anyway) for the
way attributes are looked up.  Currently, it is done like this:

	return value of attribute in instance.__dict__ if present
	for type in instance.__class__.__mro__:
	    return value of attribute in type.__dict__ if present
	raise AttributeError

I propose adding to each type a C-implementation-private dictionary
of attribute-name => type-in-which-defined.  Then, it will not be
necessary to traverse __mro__ on each attribute lookup for names
which are present in this lookup dictionary.

This optimization will not have any effect for attributes defined
on instance.  It will, however, for type attributes, most notably
for methods.  It will most likely cause a slowdown for looking up
attributes that are defined directly on self.__class__, not on any
of its bases.  However, I believe it will be a benefit for all
non-extremely shallow inheritance tree.  Especially if they involve
multiple inheritance.

One open question is what to do in case an attribute on a type is
set or deleted.

Python example:

class Current (type):

    @staticmethod
    def getattribute (self, name):
        dict = object.__getattribute__(self, '__dict__')
        if name in dict:
            return dict[name]

        mro = object.__getattribute__ (self, '__class__').__mro__
        for type in mro:
            dict = type.__dict__
            if name in dict:
                return dict[name]

        raise AttributeError

    def __init__(self, name, bases, dict):
        super (Current, self).__init__(name, bases, dict)
        self.__getattribute__ = Current.getattribute


class Optimized (type):

    @staticmethod
    def getattribute (self, name):
        dict = object.__getattribute__(self, '__dict__')
        if name in dict:
            return dict[name]

        # <possible optimization>
        lookup = object.__getattribute__ (self, '__class__').__lookup_cache__
        if name in lookup:
            return lookup[name].__dict__[name]
        # </possible optimization>

        mro = object.__getattribute__ (self, '__class__').__mro__
        for type in mro:
            dict = object.__getattribute__(type, '__dict__')
            if name in dict:
                return dict[name]

        raise AttributeError

    # <possible optimization>
    def build_lookup_cache (self):
        lookup = {}
        for type in self.__mro__:
            for name in type.__dict__:
                if name not in lookup:
                    lookup[name] = type

        return lookup
    # </possible optimization>

    def __init__(self, name, bases, dict):
        super (Optimized, self).__init__(name, bases, dict)
        # <possible optimization>
        self.__lookup_cache__ = self.build_lookup_cache ()
        # </possible optimization>
        self.__getattribute__ = Optimized.getattribute


class A (object):
    __metaclass__ = Optimized
    x = 1

class B (A):
    pass

class C (B):
    pass

class D (C):
    pass

class E (D):
    pass

t = E ()

for k in xrange (100000):
    t.x

Try swapping metaclass of A from Optimized to Current and measure
execution time.

Paul

From pje at telecommunity.com  Sun Jul  8 19:42:52 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 08 Jul 2007 13:42:52 -0400
Subject: [Python-Dev] proposed attribute lookup optimization
In-Reply-To: <200707082023.19837.pogonyshev@gmx.net>
References: <200707082023.19837.pogonyshev@gmx.net>
Message-ID: <20070708174039.C56113A404D@sparrow.telecommunity.com>

At 08:23 PM 7/8/2007 +0300, Paul Pogonyshev wrote:
>I would like to propose an optimization (I think so, anyway) for the
>way attributes are looked up.  Currently, it is done like this:
>
>         return value of attribute in instance.__dict__ if present
>         for type in instance.__class__.__mro__:
>             return value of attribute in type.__dict__ if present
>         raise AttributeError

Actually, it is only done like that for "classic" classes.  New-style 
classes actually work more like this:

     descriptor = None
     for t in type(ob).__mro__:
         if attribute in t.__dict__:
             descriptor = t.__dict__[attribute]
             if hasattr(descriptor, '__set__'):
                 return descriptor.__get__(ob, type(ob))
             break

     if attribute in ob.__dict__: return ob.__dict__[attribute]
     if descriptor is not None: return descriptor.__get__(ob, type(ob))
     if hasattr(type(ob),'__getattr__'): return ob.__getattr__(attribute)
     raise AttributeError


>I propose adding to each type a C-implementation-private dictionary
>of attribute-name => type-in-which-defined.  Then, it will not be
>necessary to traverse __mro__ on each attribute lookup for names
>which are present in this lookup dictionary.

Sounds good to me...  but it's just as simple to store the 
descriptors directly, rather than the type that defines the 
descriptor.  Might as well cut out the middleman.

I believe that someone proposed this already, with a patch, in fact...


>This optimization will not have any effect for attributes defined
>on instance.

It will for new-style classes, actually -- and a significant one if 
the inheritance  hierarchy is deep and doesn't contain a default 
value for the attribute.


>   It will, however, for type attributes, most notably
>for methods.

Yep.  It'll also speed up access to inherited slots.


>   It will most likely cause a slowdown for looking up
>attributes that are defined directly on self.__class__, not on any
>of its bases.

Not if it's a direct cache of descriptors; in that case it will have 
no effect on lookup time.


>One open question is what to do in case an attribute on a type is
>set or deleted.

New-style classes can handle this easily; they know their subclasses 
and you can't directly write to a new-style class' __dict__.  So when 
you set or delete an attribute on a type, it's possible to walk the 
subclasses and update their caches accordingly.  I believe Python 
already does this so that if you e.g. set 'sometype.__call__ = 
something', then all the subclasses' C-level tp_call slots get 
changed to match.  The same approach could be used for caching on 
new-style classes.

Again, though, this has already been proposed, and I believe there's 
a patch awaiting review for inclusion in 2.6 (and presumably 3.0).


From brett at python.org  Sun Jul  8 20:36:49 2007
From: brett at python.org (Brett Cannon)
Date: Sun, 8 Jul 2007 11:36:49 -0700
Subject: [Python-Dev] Summary of Tracker Issues
In-Reply-To: <20070707204619.8C48.JCARLSON@uci.edu>
References: <20070708000046.E82AC78176@psf.upfronthosting.co.za>
	<f6peri$opv$2@sea.gmane.org> <20070707204619.8C48.JCARLSON@uci.edu>
Message-ID: <bbaeab100707081136g306cd33ci245a7cfa7aa15a81@mail.gmail.com>

On 7/7/07, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> Steve Holden <steve at holdenweb.com> wrote:
> > Tracker wrote:
> > >
> > >     ACTIVITY SUMMARY (07/01/07 - 07/08/07)
> > >
> > >
> > >       Tracker at http://bugs.python.org/
> > >
> > > To view or respond to any of the issues listed below, simply click on
> > > the issue ID. Do *not* respond to this message.
> > >
> > > 1645 open ( +0) / 8584 closed ( +0) / 10229 total ( +0)
> > >
> > > Average duration of open issues: 850 days.
> > >
> > > Median duration of open issues: 798 days.
> > >
> > > Open Issues Breakdown STATUS        Number  Change
> > > open        1645    +0
> > > pending     0       +0
> > >
> > This script appears to have been producing exactly the same output since
> > June 9. I can't believe it's useful information.
>
> The bugs.python.org tracker is not yet the official tracker for Python
> yet (partially due to the sf.net data dump issue).

Yep.  The email is not meant to be useful to python-dev yet.  It's
there as we work out issues and make sure stuff continues to work.

The export issue should hopefully be fixed on Tuesday.  We then need
to change the importer since the DTD changed.  Then we will verify
everything works and do the transition (hopefully soon).

-Brett

From brett at python.org  Sun Jul  8 20:47:34 2007
From: brett at python.org (Brett Cannon)
Date: Sun, 8 Jul 2007 11:47:34 -0700
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <46909774.7030602@gmail.com>
References: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>
	<bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>
	<20070706080601.8C3B.JCARLSON@uci.edu> <46909774.7030602@gmail.com>
Message-ID: <bbaeab100707081147m7d1949e9oa5c450e59a0a9a86@mail.gmail.com>

On 7/8/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Josiah Carlson wrote:
> > "Brett Cannon" <brett at python.org> wrote:
> >> On 7/5/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> >>> At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
> >>>> I see no big problems with this, except I wonder if in the end it
> >>>> wouldn't be better to *always* define __package_name__ instead of only
> >>>> when it's in main? And then perhaps rename it to __package__? Done
> >>>> properly it could always be used for relative imports, rather than
> >>>> parsing __module__ to find the package. Then you won't even need the
> >>>> error handler.
> >>> +1 for __package__, and putting it everywhere.  Relative import
> >>> should use it first if present, falling back to use of __name__.
> >> +1 from me as well.
> >
> > This would solve some issues I'm currently having with relative imports.
> > +1
>
> I've updated the PEP to incorporate the feedback from this thread. The
> new version is below, and should show up on the website shortly.
>
> Cheers,
> Nick.
>
> PEP: 366
> Title: Main module explicit relative imports
> Version: $Revision: 56190 $
> Last-Modified: $Date: 2007-07-08 17:45:46 +1000 (Sun, 08 Jul 2007) $
> Author: Nick Coghlan <ncoghlan at gmail.com>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 1-May-2007
> Python-Version: 2.6, 3.0
> Post-History: 1-May-2007, 4-Jul-2007, 7-Jul-2007
>
>
> Abstract
> ========
>
> This PEP proposes a backwards compatible mechanism that permits
> the use of explicit relative imports from executable modules within
> packages. Such imports currently fail due to an awkward interaction
> between PEP 328 and PEP 338.
>
> By adding a new module level attribute, this PEP allows relative imports
> to work automatically if the module is executed using the ``-m``switch.
> A small amount of boilerplate in the module itself will allow the relative
> imports to work when the file is executed by name.
>
>
> Proposed Change
> ===============
>
> The major proposed change is the introduction of a new module level
> attribute, ``__package__``. When it is present, relative imports will
> be based on this attribute rather than the module ``__name__``
> attribute.
>
> As with the current ``__name__`` attribute, setting ``__package__`` will
> be the responsibility of the PEP 302 loader used to import a module.
> Loaders which use ``imp.new_module()`` to create the module object will
> have the new attribute set automatically to
> ``__name__.rpartition('.')[0]``.

Is this really the best semantics for this?  Let's say I have
A/B/__init__.py and A/B/C.py.  With these semantics I would have A.B
having __package__ be 'A' and A.B.C having 'A.B'.

While I agree that the A.B.C setting is correct, is the A.B value what
is truly desired?  Is an __init__ module really to be considered part
of the above package?  I always viewed the __init__ module as part of
its own package.  Thus I expected A.B to have __package__ set to
'A.B'.

Beyond just what I expected, the reason I bring this up is that if
__package__ had the semantics I am suggesting, it is trivial to
discover what modules are the package __init__ modules (as
``__package__ == __name__``) compared to being a submodule
(``__package__ and __package__ != __name__``).  As of right now you
can only do that if you examine __file__ for __init__.py(c), but that
is highly dependent on how the module was loaded.  It might be nice if
what kind of module (top-level, package, or submodule) something is
based on its metadata.

-Brett

From steve at holdenweb.com  Sun Jul  8 20:49:58 2007
From: steve at holdenweb.com (Steve Holden)
Date: Sun, 08 Jul 2007 14:49:58 -0400
Subject: [Python-Dev] Summary of Tracker Issues
In-Reply-To: <bbaeab100707081136g306cd33ci245a7cfa7aa15a81@mail.gmail.com>
References: <20070708000046.E82AC78176@psf.upfronthosting.co.za>	<f6peri$opv$2@sea.gmane.org>
	<20070707204619.8C48.JCARLSON@uci.edu>
	<bbaeab100707081136g306cd33ci245a7cfa7aa15a81@mail.gmail.com>
Message-ID: <f6rbkg$573$1@sea.gmane.org>

Brett Cannon wrote:
> On 7/7/07, Josiah Carlson <jcarlson at uci.edu> wrote:
>> Steve Holden <steve at holdenweb.com> wrote:
>>> Tracker wrote:
>>>>     ACTIVITY SUMMARY (07/01/07 - 07/08/07)
>>>>
>>>>
>>>>       Tracker at http://bugs.python.org/
>>>>
>>>> To view or respond to any of the issues listed below, simply click on
>>>> the issue ID. Do *not* respond to this message.
>>>>
>>>> 1645 open ( +0) / 8584 closed ( +0) / 10229 total ( +0)
>>>>
>>>> Average duration of open issues: 850 days.
>>>>
>>>> Median duration of open issues: 798 days.
>>>>
>>>> Open Issues Breakdown STATUS        Number  Change
>>>> open        1645    +0
>>>> pending     0       +0
>>>>
>>> This script appears to have been producing exactly the same output since
>>> June 9. I can't believe it's useful information.
>> The bugs.python.org tracker is not yet the official tracker for Python
>> yet (partially due to the sf.net data dump issue).
> 
> Yep.  The email is not meant to be useful to python-dev yet.  It's
> there as we work out issues and make sure stuff continues to work.
> 
> The export issue should hopefully be fixed on Tuesday.  We then need
> to change the importer since the DTD changed.  Then we will verify
> everything works and do the transition (hopefully soon).
> 
Yay! I'm sure the tracker change has taken more effort than most people 
expected, but it should be worth it in the end.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------


From walter at livinglogic.de  Sun Jul  8 22:00:30 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Sun, 08 Jul 2007 22:00:30 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <ca471dc20707080749q41e0a00eyc3b99629d8801aa0@mail.gmail.com>
References: <4690B08E.3010501@livinglogic.de>	
	<ca471dc20707080431j43a8c063v91a079dc86c13205@mail.gmail.com>	
	<f6qi33$4c0$1@sea.gmane.org>	
	<ca471dc20707080449l4a5b6fbdjff974d512fcae689@mail.gmail.com>	
	<4690E6FD.50002@livinglogic.de>
	<ca471dc20707080749q41e0a00eyc3b99629d8801aa0@mail.gmail.com>
Message-ID: <4691425E.1000708@livinglogic.de>

Guido van Rossum wrote:

> On 7/8/07, Walter D?rwald <walter at livinglogic.de> wrote:
> [quoting Guido]
>> > But I still want to hear of a practical use case for the default here.
>>
>> In most cases
>>
>>     foo = getitem(iterable, 0, None)
>>     if foo is not None:
>>        ...
>>
>> is simpler than:
>>
>>     try:
>>        foo = getitem(iterable, 0)
>>     except IndexError:
>>        pass
>>     else:
>>        ...
>>
>> Here is a use case from one of my "import XML into the database" scripts:
>>
>>     compid = getitem(root[ns.Company_company_id], 0, None)
>>     if compid:
>>        compid = int(compid)
>>
>> The expression root[ns.company_id] returns an iterator that produces all
>> children of the root node that are of the element type company_id. If
>> there is a company_id its content will be turned into an int, if not
>> None will be used.
> 
> Ahem. I hope you have a better use case for getitem() than that
> (regardless of the default issue). I find it clearer to write that as
> 
> try:
>  compid = root[ns.company_id].next()
> except StopIteration:
>  compid = None
> else:
>  compid = int(compid)
> 
> While this is more lines, it doesn't require one to know about
> getitem() on an iterator. This is the same reason why setdefault() was
> a mistake -- it's too obscure to invent a compact spelling for it
> since the compact spelling has to be learned or looked up.

Well I have used (a Python version of) this getitem() function to 
implement a library that can match a CSS3 expression against an XML 
tree. For implementing the nth-child(), nth-last-child(), nth-of-type() 
and nth-last-of-type() pseudo classes (see 
http://www.w3.org/TR/css3-selectors/#structural-pseudos) getitem() was 
very useful.

Servus,
    Walter

From python at rcn.com  Mon Jul  9 00:40:17 2007
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 8 Jul 2007 15:40:17 -0700
Subject: [Python-Dev] itertools addition: getitem()
References: <4690B08E.3010501@livinglogic.de>
Message-ID: <000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>

[Walter D?rwald]
> I'd like to propose the following addition to itertools: A function
> itertools.getitem() which is basically equivalent to the following
> python code:
>
> _default = object()
>
> def getitem(iterable, index, default=_default):
>    try:
>       return list(iterable)[index]
>    except IndexError:
>       if default is _default:
>          raise
>       return default
>
> but without materializing the complete list. Negative indexes are
> supported too (this requires additional temporary storage for abs(index)
> objects).

Why not use the existing islice() function?

   x = list(islice(iterable, i, i+1)) or default

Also, as a practical matter, I think it is a bad idea to introduce
__getitem__ style access to itertools because the starting point
moves with each consecutive access:

    # access items 0, 2, 5, 9, 14, 20, ...
    for i in range(10):
        print getitem(iterable, i)

Worse, this behavior changes depending on whether the iterable
is re-iterable (a string would yield consecutive items while a
generator would skip around as shown above).

Besides being a bug factory, I think the getitem proposal would
tend to steer people down the wrong road, away from more
natural solutions to problems involving iterators.  A basic step
in learning the language is to differentiate between sequences
and general iterators -- we should not conflate the two.


Raymond

From walter at livinglogic.de  Mon Jul  9 08:16:35 2007
From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=)
Date: Mon, 09 Jul 2007 08:16:35 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>
References: <4690B08E.3010501@livinglogic.de>
	<000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>
Message-ID: <4691D2C3.5090509@livinglogic.de>

Raymond Hettinger wrote:
> [Walter D?rwald]
>> I'd like to propose the following addition to itertools: A function
>> itertools.getitem() which is basically equivalent to the following
>> python code:
>>
>> _default = object()
>>
>> def getitem(iterable, index, default=_default):
>>    try:
>>       return list(iterable)[index]
>>    except IndexError:
>>       if default is _default:
>>          raise
>>       return default
>>
>> but without materializing the complete list. Negative indexes are
>> supported too (this requires additional temporary storage for abs(index)
>> objects).
> 
> Why not use the existing islice() function?
> 
>   x = list(islice(iterable, i, i+1)) or default

This doesn't work, because it produces a list

>>> list(islice(xrange(10), 2, 3)) or 42
[2]

The following would work:
   x = (list(islice(iterable, i, i+1)) or [default])[0]

However islice() doesn't support negative indexes, getitem() does.

> Also, as a practical matter, I think it is a bad idea to introduce
> __getitem__ style access to itertools because the starting point
> moves with each consecutive access:
> 
>    # access items 0, 2, 5, 9, 14, 20, ...
>    for i in range(10):
>        print getitem(iterable, i)
> 
> Worse, this behavior changes depending on whether the iterable
> is re-iterable (a string would yield consecutive items while a
> generator would skip around as shown above).

islice() has the same "problem":

>>> from itertools import *
>>> iterable = iter(xrange(100))
>>> for i in range(10):
...     print list(islice(iterable, i, i+1))
[0]
[2]
[5]
[9]
[14]
[20]
[27]
[35]
[44]
[54]

>>> iterable = xrange(100)
>>> for i in range(10):
...     print list(islice(iterable, i, i+1))
[0]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]

> Besides being a bug factory, I think the getitem proposal would
> tend to steer people down the wrong road, away from more
> natural solutions to problems involving iterators.

I don't think that
   (list(islice(iterable, i, i+1)) or [default])[0]
is more natural than
   getitem(iterable, i, default)

> A basic step
> in learning the language is to differentiate between sequences
> and general iterators -- we should not conflate the two.

Servus,
   Walter

From guido at python.org  Mon Jul  9 08:33:58 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 9 Jul 2007 09:33:58 +0300
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>
References: <4690B08E.3010501@livinglogic.de>
	<000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>
Message-ID: <ca471dc20707082333w56de18d6k7afa26f0db28616d@mail.gmail.com>

On 7/9/07, Raymond Hettinger <python at rcn.com> wrote:
> Also, as a practical matter, I think it is a bad idea to introduce
> __getitem__ style access to itertools because the starting point
> moves with each consecutive access:
>
>     # access items 0, 2, 5, 9, 14, 20, ...
>     for i in range(10):
>         print getitem(iterable, i)
>
> Worse, this behavior changes depending on whether the iterable
> is re-iterable (a string would yield consecutive items while a
> generator would skip around as shown above).
>
> Besides being a bug factory, I think the getitem proposal would
> tend to steer people down the wrong road, away from more
> natural solutions to problems involving iterators.  A basic step
> in learning the language is to differentiate between sequences
> and general iterators -- we should not conflate the two.

But doesn't the very same argument also apply against islice(), which
you just offered as an alternative?

PS. If Walter is also at EuroPython, maybe you two could discuss this in person?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From walter at livinglogic.de  Mon Jul  9 12:11:39 2007
From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=)
Date: Mon, 09 Jul 2007 12:11:39 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <ca471dc20707082333w56de18d6k7afa26f0db28616d@mail.gmail.com>
References: <4690B08E.3010501@livinglogic.de>	
	<000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>
	<ca471dc20707082333w56de18d6k7afa26f0db28616d@mail.gmail.com>
Message-ID: <469209DB.1090403@livinglogic.de>

Guido van Rossum wrote:
> On 7/9/07, Raymond Hettinger <python at rcn.com> wrote:
>> Also, as a practical matter, I think it is a bad idea to introduce
>> __getitem__ style access to itertools because the starting point
>> moves with each consecutive access:
>>
>>     # access items 0, 2, 5, 9, 14, 20, ...
>>     for i in range(10):
>>         print getitem(iterable, i)
>>
>> Worse, this behavior changes depending on whether the iterable
>> is re-iterable (a string would yield consecutive items while a
>> generator would skip around as shown above).
>>
>> Besides being a bug factory, I think the getitem proposal would
>> tend to steer people down the wrong road, away from more
>> natural solutions to problems involving iterators.  A basic step
>> in learning the language is to differentiate between sequences
>> and general iterators -- we should not conflate the two.
> 
> But doesn't the very same argument also apply against islice(), which
> you just offered as an alternative?

Exactly.

> PS. If Walter is also at EuroPython, maybe you two could discuss this in
> person?

Sorry, I won't be at EuroPython.

Servus,
   Walter

From ncoghlan at gmail.com  Mon Jul  9 12:34:59 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 09 Jul 2007 20:34:59 +1000
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <bbaeab100707081147m7d1949e9oa5c450e59a0a9a86@mail.gmail.com>
References: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>	
	<bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>	
	<20070706080601.8C3B.JCARLSON@uci.edu> <46909774.7030602@gmail.com>
	<bbaeab100707081147m7d1949e9oa5c450e59a0a9a86@mail.gmail.com>
Message-ID: <46920F53.7070904@gmail.com>

Brett Cannon wrote:
> On 7/8/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> As with the current ``__name__`` attribute, setting ``__package__`` will
>> be the responsibility of the PEP 302 loader used to import a module.
>> Loaders which use ``imp.new_module()`` to create the module object will
>> have the new attribute set automatically to
>> ``__name__.rpartition('.')[0]``.
> 
> Is this really the best semantics for this?  Let's say I have
> A/B/__init__.py and A/B/C.py.  With these semantics I would have A.B
> having __package__ be 'A' and A.B.C having 'A.B'.
> 
> While I agree that the A.B.C setting is correct, is the A.B value what
> is truly desired?  Is an __init__ module really to be considered part
> of the above package?  I always viewed the __init__ module as part of
> its own package.  Thus I expected A.B to have __package__ set to
> 'A.B'.

Good point - PEP 328 makes it explicit that __init__.py is treated like 
any other module in the package for purposes of relative imports, so the 
semantics you suggest are the ones required. I hadn't actually thought 
about this case, as it wasn't relevant when the new attribute applied 
only to the main module.

However, those semantics mean that we won't be able to automatically add 
the new attribute inside imp.new_module(), as that function doesn't know 
whether or not the new module is a package.

> Beyond just what I expected, the reason I bring this up is that if
> __package__ had the semantics I am suggesting, it is trivial to
> discover what modules are the package __init__ modules (as
> ``__package__ == __name__``) compared to being a submodule
> (``__package__ and __package__ != __name__``).  As of right now you
> can only do that if you examine __file__ for __init__.py(c), but that
> is highly dependent on how the module was loaded.  It might be nice if
> what kind of module (top-level, package, or submodule) something is
> based on its metadata. 

This part of the argument isn't relevant though, as it's already trivial 
to determine whether or not a module is a package by checking for a 
__path__ attribute. That's what PEP 302 specifies, and it is how the 
relative import machinery currently determines whether to use __name__ 
or __name__.rpartition('.')[0] as the base for relative imports.

Given the above limitations, I propose that we document the new 
attribute as follows:

"If the module global __package__ exists when executing an import 
statement, it is used to determine the base for relative imports, 
instead of the __name__ and __path__ attributes. This attribute may be 
set by the interpreter before a module is executed - whether or not it 
is set automatically in a given module is implementation dependent."

And for the CPython implementation, I propose that we set the new attribute:
   1. When the main module is executed using the -m switch
   2. When a relative import is executed and the attribute is not yet set

This will allow any module which uses relative imports to benefit from 
the micro-optimisation of caching the package name in normal modules 
(regardless of how the module gets loaded), as well as allowing relative 
imports from the main module (which is the main goal of the PEP).

With the way PEP 302 hands off creation of the module and execution of 
its code to the loader objects, I don't see any way to guarantee that 
__package__ will always be set - this seems like a reasonable compromise.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From p.f.moore at gmail.com  Mon Jul  9 15:12:54 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 9 Jul 2007 14:12:54 +0100
Subject: [Python-Dev] Summary of Tracker Issues
In-Reply-To: <f6peri$opv$2@sea.gmane.org>
References: <20070708000046.E82AC78176@psf.upfronthosting.co.za>
	<f6peri$opv$2@sea.gmane.org>
Message-ID: <79990c6b0707090612r6a6af4dpce52e3766a5b6226@mail.gmail.com>

On 08/07/07, Steve Holden <steve at holdenweb.com> wrote:
> This script appears to have been producing exactly the same output since
> June 9. I can't believe it's useful information.

It has one positive aspect for me - it's reassured me that the spate
of spam which hit the new tracker a month or two ago has been
successfully stopped...

Paul.

From python at rcn.com  Mon Jul  9 18:43:50 2007
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 9 Jul 2007 09:43:50 -0700
Subject: [Python-Dev] itertools addition: getitem()
References: <4690B08E.3010501@livinglogic.de>
	<000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>
	<ca471dc20707082333w56de18d6k7afa26f0db28616d@mail.gmail.com>
Message-ID: <00b101c7c248$541f4dc0$2500a8c0@RaymondLaptop1>

From: "Guido van Rossum" <guido at python.org>
> But doesn't the very same argument also apply against islice(), which
> you just offered as an alternative?

Not really.  The use cases for islice() typically do not involve
repeated slices of an iterator unless it is slicing off the front
few elements on each pass.  In contrast, getitem() is all about
grabbing something other than the frontmost element and seems
to be intended for repeated calls on the same iterator.  And its
support for negative indices seems somewhat weird in the
context of general purpose iterators:  getitem(genprimes(), -1).

I'll study Walter's use case but my instincts say that adding
getitem() will do more harm than good.


Raymond

From brett at python.org  Mon Jul  9 21:14:04 2007
From: brett at python.org (Brett Cannon)
Date: Mon, 9 Jul 2007 12:14:04 -0700
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <46920F53.7070904@gmail.com>
References: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>
	<bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>
	<20070706080601.8C3B.JCARLSON@uci.edu> <46909774.7030602@gmail.com>
	<bbaeab100707081147m7d1949e9oa5c450e59a0a9a86@mail.gmail.com>
	<46920F53.7070904@gmail.com>
Message-ID: <bbaeab100707091214u131e5bdcw3056c5af99d85cd2@mail.gmail.com>

On 7/9/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
> > On 7/8/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >> As with the current ``__name__`` attribute, setting ``__package__`` will
> >> be the responsibility of the PEP 302 loader used to import a module.
> >> Loaders which use ``imp.new_module()`` to create the module object will
> >> have the new attribute set automatically to
> >> ``__name__.rpartition('.')[0]``.
> >
> > Is this really the best semantics for this?  Let's say I have
> > A/B/__init__.py and A/B/C.py.  With these semantics I would have A.B
> > having __package__ be 'A' and A.B.C having 'A.B'.
> >
> > While I agree that the A.B.C setting is correct, is the A.B value what
> > is truly desired?  Is an __init__ module really to be considered part
> > of the above package?  I always viewed the __init__ module as part of
> > its own package.  Thus I expected A.B to have __package__ set to
> > 'A.B'.
>
> Good point - PEP 328 makes it explicit that __init__.py is treated like
> any other module in the package for purposes of relative imports, so the
> semantics you suggest are the ones required. I hadn't actually thought
> about this case, as it wasn't relevant when the new attribute applied
> only to the main module.
>
> However, those semantics mean that we won't be able to automatically add
> the new attribute inside imp.new_module(), as that function doesn't know
> whether or not the new module is a package.
>

Good point.

> > Beyond just what I expected, the reason I bring this up is that if
> > __package__ had the semantics I am suggesting, it is trivial to
> > discover what modules are the package __init__ modules (as
> > ``__package__ == __name__``) compared to being a submodule
> > (``__package__ and __package__ != __name__``).  As of right now you
> > can only do that if you examine __file__ for __init__.py(c), but that
> > is highly dependent on how the module was loaded.  It might be nice if
> > what kind of module (top-level, package, or submodule) something is
> > based on its metadata.
>
> This part of the argument isn't relevant though, as it's already trivial
> to determine whether or not a module is a package by checking for a
> __path__ attribute. That's what PEP 302 specifies, and it is how the
> relative import machinery currently determines whether to use __name__
> or __name__.rpartition('.')[0] as the base for relative imports.
>

=)  The lesson here is be careful when emailing on vacation as you
might not think everything through.  =)

> Given the above limitations, I propose that we document the new
> attribute as follows:
>
> "If the module global __package__ exists when executing an import
> statement, it is used to determine the base for relative imports,
> instead of the __name__ and __path__ attributes.

That's fine.  __path__ actually isn't used to resolve relative imports
into absolute ones anyway; it's used only as a substitute to sys.path
when importing within a package.


> This attribute may be
> set by the interpreter before a module is executed - whether or not it
> is set automatically in a given module is implementation dependent."
>
> And for the CPython implementation, I propose that we set the new attribute:
>    1. When the main module is executed using the -m switch
>    2. When a relative import is executed and the attribute is not yet set
>
> This will allow any module which uses relative imports to benefit from
> the micro-optimisation of caching the package name in normal modules
> (regardless of how the module gets loaded), as well as allowing relative
> imports from the main module (which is the main goal of the PEP).
>
> With the way PEP 302 hands off creation of the module and execution of
> its code to the loader objects, I don't see any way to guarantee that
> __package__ will always be set - this seems like a reasonable compromise.

It could be set after the import, but you are right that the loaders
will not necessarily set it before executing code.  You might be able
to use the reload requirement of using an existing dict if the module
is in sys.modules somehow, but that just sounds like asking for
trouble.

-Brett

From walter at livinglogic.de  Mon Jul  9 21:23:40 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Mon, 09 Jul 2007 21:23:40 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <00b101c7c248$541f4dc0$2500a8c0@RaymondLaptop1>
References: <4690B08E.3010501@livinglogic.de>	<000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>	<ca471dc20707082333w56de18d6k7afa26f0db28616d@mail.gmail.com>
	<00b101c7c248$541f4dc0$2500a8c0@RaymondLaptop1>
Message-ID: <46928B3C.2020602@livinglogic.de>

Raymond Hettinger wrote:

> From: "Guido van Rossum" <guido at python.org>
>> But doesn't the very same argument also apply against islice(), which
>> you just offered as an alternative?
> 
> Not really.  The use cases for islice() typically do not involve
> repeated slices of an iterator unless it is slicing off the front
> few elements on each pass.  In contrast, getitem() is all about
> grabbing something other than the frontmost element and seems
> to be intended for repeated calls on the same iterator. 

That wouldn't make sense as getitem() consumes the iterator! ;)

But seriously: perhaps the name getitem() is misleading? What about 
item() or pickitem()?

> And its
> support for negative indices seems somewhat weird in the
> context of general purpose iterators:  getitem(genprimes(), -1).

This does indeed make as much sense as sum(itertools.count()).

> I'll study Walter's use case but my instincts say that adding
> getitem() will do more harm than good.

Here's the function in use (somewhat invisibly, as it's used by the 
walknode() method). This gets the oldest news from Python's homepage:

 >>> from ll.xist import parsers, xfind
 >>> from ll.xist.ns import html
 >>> e = parsers.parseURL("http://www.python.org", tidy=True)
 >>> print e.walknode(html.h2 & xfind.hasclass("news"))[-1]
Google Adds Python Support to Google Calendar Developer's Guide


Get the first comment line from a python file:

 >>> getitem((line for line in open("Lib/codecs.py") if 
line.startswith("#")), 0)
'### Registry and builtin stateless codec functions\n'


Create a new unused identifier:

 >>> def candidates(base):
...     yield base
...     for suffix in count(2):
...         yield "%s%d" % (base, suffix)
...
 >>> usedids = set(("foo", "bar"))
 >>> getitem((i for i in candidates("foo") if i not in usedids), 0)
'foo2'

Servus,
    Walter


From kbk at shore.net  Tue Jul 10 03:33:54 2007
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 9 Jul 2007 21:33:54 -0400 (EDT)
Subject: [Python-Dev] Weekly Python Patch/Bug Summary
Message-ID: <200707100133.l6A1Xsld009031@hampton.thirdcreek.com>

Patch / Bug Summary
___________________

Patches :  392 open ( +7) /  3792 closed ( +2) /  4184 total ( +9)
Bugs    : 1042 open (+13) /  6757 closed (+13) /  7799 total (+26)
RFE     :  263 open ( +1) /   292 closed ( +1) /   555 total ( +2)

New / Reopened Patches
______________________

"%d" format handling for long values  (2007-06-25)
       http://python.org/sf/1742669  opened by  Gabriel Genellina

Read Write lock  (2007-06-27)
       http://python.org/sf/1744382  opened by  Yaakov Nemoy

Improve exception pickling support  (2007-06-27)
       http://python.org/sf/1744398  opened by  Eric Huss

Patch for feat. 713877 Expose callbackAPI in readline module  (2007-06-27)
       http://python.org/sf/1744456  opened by  strank

IPv6 Interface naming/indexing functions  (2007-07-02)
       http://python.org/sf/1746656  opened by  Michael Meier

Limiting data copy in xmlrpclib  (2007-07-04)
       http://python.org/sf/1747670  opened by  Gael Le Mignot

Extra optional argument to os.path.expandvars  (2007-07-06)
       http://python.org/sf/1748960  opened by  Geoffrey Bache

New byte packing format for the struct module  (2007-07-07)
       http://python.org/sf/1749662  opened by  Robert Zeh

itertools.getitem()  (2007-07-08)
       http://python.org/sf/1749857  opened by  Walter D?rwald

Patches Closed
______________

Fix for duplicate "preferences" menu-OS X  (2007-04-03)
       http://python.org/sf/1693258  closed by  ronaldoussoren

Mac OS X: libtool  (2007-03-03)
       http://python.org/sf/1673122  closed by  ronaldoussoren

New / Reopened Bugs
___________________

Incorrect docs for optparse OptionParser add_help_option  (2007-06-23)
       http://python.org/sf/1742164  opened by  Forest Wilkinson

ZipFile.writestr writes incorrect extended local headers  (2007-06-23)
       http://python.org/sf/1742205  opened by  alexis

Documentation for BaseHTTPServer.HTTPServer  (2007-06-25)
       http://python.org/sf/1742837  opened by  Brandon Mintern

Pickling of exceptions broken  (2007-06-25)
       http://python.org/sf/1742889  opened by  Jim Fulton

shlex handles  'None' poorly  (2007-06-25)
CLOSED http://python.org/sf/1742901  opened by  Seth Vidal

can't run single lamba funcs as unittest  (2007-06-25)
       http://python.org/sf/1742940  opened by  timmeh

conditional expressions vs. () and * in call arguments.  (2007-06-26)
CLOSED http://python.org/sf/1743665  opened by  Mike Meyer

Some incorrect national characters (Polish) in unicodedata  (2007-06-26)
CLOSED http://python.org/sf/1743795  opened by  admindomeny

Examples dropped from PDF version of docs  (2007-06-26)
       http://python.org/sf/1743846  opened by  Terry Carroll

cvs.get_dialect() return a class object   (2007-06-28)
       http://python.org/sf/1744580  opened by  Christian Kristukat

Newline skipped in "for line in file"  (2007-06-28)
       http://python.org/sf/1744752  opened by  Rune Devik

DoS smtpd vulnerability  (2007-06-28)
       http://python.org/sf/1745035  opened by  billiejoex

2.5.1 curses panel segfault in new_panel on aix 5.3  (2007-06-29)
       http://python.org/sf/1745108  opened by  Mattias Wadenstein

pdtri gives wrong results  (2007-06-29)
CLOSED http://python.org/sf/1745178  opened by  Nikke Knatterton

Filename providing cross platform capability  (2007-06-29)
CLOSED http://python.org/sf/1745533  reopened by  loewis

Filename providing cross platform capability  (2007-06-29)
CLOSED http://python.org/sf/1745533  opened by  Damian

Bad attributes/data handling in SGMLib  (2007-06-30)
       http://python.org/sf/1745761  opened by  Alvaro Lopez

class mutex doesn't do anything atomically  (2007-07-01)
       http://python.org/sf/1746071  opened by  David Benbennick

long.__str__ is quadratic time  (2007-07-01)
       http://python.org/sf/1746088  opened by  David Benbennick

AMD64 installer does not place python25.dll in system dir  (2007-07-02)
       http://python.org/sf/1746880  opened by  Roger Upole

chown broken on 64bit  (2007-07-04)
       http://python.org/sf/1747858  opened by  Neal D. Becker

Module-level stack scopes have incorrect bindings.  (2007-07-04)
       http://python.org/sf/1748015  opened by  Nefarious CodeMonkey, Jr.

inspect.getargspec fails on built-in or slot wrapper methods  (2007-07-04)
       http://python.org/sf/1748064  opened by  Michael A. Hawker

str.join() intercepts UnicodeDecodeError raised by iterator  (2007-07-05)
CLOSED http://python.org/sf/1748292  opened by  Christoph Zwerschke

imaplib cannot handle mailboxes with ACL: lrs  (2007-07-07)
       http://python.org/sf/1749512  opened by  Florian Friesdorf

PLATFORM macro in PC/pyconfig.h already defined by Apache  (2007-07-07)
       http://python.org/sf/1749567  opened by  Adal Chiriliuc

expanduser("~") on Windows looks for HOME first  (2007-07-07)
       http://python.org/sf/1749583  opened by  Edward Diener

os.getlogin should use the DISPLAY and not the tty  (2007-07-08)
       http://python.org/sf/1750013  opened by  Serge Noiraud

Python 2.5+ skips while statements in debuggers  (2007-07-08)
       http://python.org/sf/1750076  opened by  Chris Lasher

Bugs Closed
___________

Odd UDP problems in socket library  (2007-06-22)
       http://python.org/sf/1741898  deleted by  bluej774

shlex handles  'None' poorly  (2007-06-25)
       http://python.org/sf/1742901  closed by  gbrandl

python: Modules/gcmodule.c:240: update_refs: Assertion `gc->  (2007-06-20)
       http://python.org/sf/1740599  closed by  stuffduff

shutil.move doesn't work when only case changes  (2007-06-16)
       http://python.org/sf/1738441  closed by  ggambett

conditional expressions vs. () and * in call arguments.  (2007-06-26)
       http://python.org/sf/1743665  closed by  gbrandl

Some incorrect national characters (Polish) in unicodedata  (2007-06-26)
       http://python.org/sf/1743795  closed by  loewis

pdtri gives wrong results  (2007-06-29)
       http://python.org/sf/1745178  closed by  gbrandl

Filename providing cross platform capability  (2007-06-29)
       http://python.org/sf/1745533  closed by  loewis

Filename providing cross platform capability  (2007-06-29)
       http://python.org/sf/1745533  closed by  atagar

str.join() intercepts UnicodeDecodeError raised by iterator  (2007-07-05)
       http://python.org/sf/1748292  closed by  lemburg

Tkinter is not working on trunk (2.6)  (2007-06-09)
       http://python.org/sf/1733943  closed by  kbk

logging module formatter problem with %(filename)s  (2006-06-19)
       http://python.org/sf/1508369  closed by  ronaldoussoren

Mac Universal Build of Python confuses distutils  (2006-07-28)
       http://python.org/sf/1530142  closed by  ronaldoussoren

Mac build fails if not building universal due to libtool  (2007-06-12)
       http://python.org/sf/1736103  closed by  jackjansen

Status bar on OSX garbled  (2007-01-04)
       http://python.org/sf/1627543  closed by  ronaldoussoren

New / Reopened RFE
__________________

please add wsgi to SimpleXMLRPCServer  (2007-06-30)
       http://python.org/sf/1745722  opened by  Helmut Grohne

RFE Closed
__________

MacPython ignores user-installed Tcl/Tk  (2006-09-21)
       http://python.org/sf/1563046  closed by  ronaldoussoren


From ncoghlan at gmail.com  Tue Jul 10 11:28:19 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 10 Jul 2007 19:28:19 +1000
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <bbaeab100707091214u131e5bdcw3056c5af99d85cd2@mail.gmail.com>
References: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>	
	<bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>	
	<20070706080601.8C3B.JCARLSON@uci.edu>
	<46909774.7030602@gmail.com>	
	<bbaeab100707081147m7d1949e9oa5c450e59a0a9a86@mail.gmail.com>	
	<46920F53.7070904@gmail.com>
	<bbaeab100707091214u131e5bdcw3056c5af99d85cd2@mail.gmail.com>
Message-ID: <46935133.7000401@gmail.com>

Brett Cannon wrote:
> On 7/9/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Given the above limitations, I propose that we document the new
>> attribute as follows:
>>
>> "If the module global __package__ exists when executing an import
>> statement, it is used to determine the base for relative imports,
>> instead of the __name__ and __path__ attributes.
> 
> That's fine.  __path__ actually isn't used to resolve relative imports
> into absolute ones anyway; it's used only as a substitute to sys.path
> when importing within a package.

I was referring to the fact that if __path__ is present (indicating a 
package), then the relative import is based directly on __name__, 
otherwise it is based on __name__.rpartition('.')[0].

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From bingham at cenix-bioscience.com  Tue Jul 10 11:02:12 2007
From: bingham at cenix-bioscience.com (Aaron Bingham)
Date: Tue, 10 Jul 2007 11:02:12 +0200
Subject: [Python-Dev] Should r53624 be applied to release branches?
Message-ID: <46934B14.7080802@cenix-bioscience.com>

Hello,

We recently had a production failure caused by the issue fixed in r53624 
on the trunk [1].   I see that this patch has also been applied to 
py3k-struni.  Should this patch be merged to the release branches?  In 
the meantime we will have to patch subprocess.py ourselves.

[1] 
http://mail.python.org/pipermail/python-checkins/2007-February/058421.html

Thanks,

-- 
Aaron Bingham
Senior Software Engineer
bingham at cenix-bioscience.com
Tel. +49 (0)351 4173-146
Fax +49 (0)351 4173-109

Cenix BioScience GmbH
Tatzberg 47
01307 Dresden, Germany
www.cenix-bioscience.com

---------------------------------------------------------
Sitz der Gesellschaft (Place of Business): Dresden
Gesch?ftsf?hrer (CEO): Dr. Christophe J. Echeverri
Amtsgericht (Local Court): Dresden, HRB 19964
Ust-ID (VAT-No.): DE205824437
---------------------------------------------------------

WICHTIGE INFORMATION: Diese Email, inklusive der Anh?nge, ist 
ausschlie?lich f?r den Gebrauch durch die hierzu berechtigten 
Empf?nger bestimmt. Sollten Sie nicht der f?r diese Email bestimmte 
Adressat sein, ist Ihnen jede Ver?ffentlichung, Vervielf?ltigung oder 
Weitergabe dieses Dokuments untersagt. Bitte senden Sie eine Email an 
info at cenix-bioscience.com, falls Sie diese Email versehentlich erhalten
haben. Vielen Dank!

IMPORTANT NOTICE:  This message, including any attached documents, is
intended only for the use of the individual or entity to which it is
addressed, and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law.  If the reader of this 
Message is not the intended recipient, or the employee or agent 
responsible for delivering the message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of 
this communication is strictly prohibited. If you have received this 
communication in error, please notify Cenix BioScience immediately by 
email at info at cenix-bioscience.com. Thank you.



From skip at pobox.com  Tue Jul 10 13:57:37 2007
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 10 Jul 2007 06:57:37 -0500
Subject: [Python-Dev] Should r53624 be applied to release branches?
In-Reply-To: <46934B14.7080802@cenix-bioscience.com>
References: <46934B14.7080802@cenix-bioscience.com>
Message-ID: <18067.29745.886704.769693@montanaro.dyndns.org>


    Aaron> We recently had a production failure caused by the issue fixed in
    Aaron> r53624 on the trunk [1].  I see that this patch has also been
    Aaron> applied to py3k-struni.  Should this patch be merged to the
    Aaron> release branches?  In the meantime we will have to patch
    Aaron> subprocess.py ourselves.

In theory, I'm in favor of backporting, but how far back do you need/want to
apply it?  There will clearly be more 2.5 releases.  I don't think any more
2.4 releases are planned.

Skip

From bingham at cenix-bioscience.com  Tue Jul 10 14:55:17 2007
From: bingham at cenix-bioscience.com (Aaron Bingham)
Date: Tue, 10 Jul 2007 14:55:17 +0200
Subject: [Python-Dev] Should r53624 be applied to release branches?
In-Reply-To: <18067.29745.886704.769693@montanaro.dyndns.org>
References: <46934B14.7080802@cenix-bioscience.com>
	<18067.29745.886704.769693@montanaro.dyndns.org>
Message-ID: <469381B5.1080300@cenix-bioscience.com>

skip at pobox.com wrote:
>     Aaron> We recently had a production failure caused by the issue fixed in
>     Aaron> r53624 on the trunk [1].  I see that this patch has also been
>     Aaron> applied to py3k-struni.  Should this patch be merged to the
>     Aaron> release branches?  In the meantime we will have to patch
>     Aaron> subprocess.py ourselves.
>
> In theory, I'm in favor of backporting, but how far back do you need/want to
> apply it?  There will clearly be more 2.5 releases.  I don't think any more
> 2.4 releases are planned.
>   
We will only be supporting 2.4 for a few months more, so as far as we 
are concerned a backport to 2.5 would be sufficient.

Thanks,

-- 
Aaron Bingham
Senior Software Engineer
bingham at cenix-bioscience.com
Tel. +49 (0)351 4173-146
Fax +49 (0)351 4173-109

Cenix BioScience GmbH
Tatzberg 47
01307 Dresden, Germany
www.cenix-bioscience.com

---------------------------------------------------------
Sitz der Gesellschaft (Place of Business): Dresden
Gesch?ftsf?hrer (CEO): Dr. Christophe J. Echeverri
Amtsgericht (Local Court): Dresden, HRB 19964
Ust-ID (VAT-No.): DE205824437
---------------------------------------------------------

WICHTIGE INFORMATION: Diese Email, inklusive der Anh?nge, ist 
ausschlie?lich f?r den Gebrauch durch die hierzu berechtigten 
Empf?nger bestimmt. Sollten Sie nicht der f?r diese Email bestimmte 
Adressat sein, ist Ihnen jede Ver?ffentlichung, Vervielf?ltigung oder 
Weitergabe dieses Dokuments untersagt. Bitte senden Sie eine Email an 
info at cenix-bioscience.com, falls Sie diese Email versehentlich erhalten
haben. Vielen Dank!

IMPORTANT NOTICE:  This message, including any attached documents, is
intended only for the use of the individual or entity to which it is
addressed, and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law.  If the reader of this 
Message is not the intended recipient, or the employee or agent 
responsible for delivering the message to the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of 
this communication is strictly prohibited. If you have received this 
communication in error, please notify Cenix BioScience immediately by 
email at info at cenix-bioscience.com. Thank you.



From guido at python.org  Tue Jul 10 23:14:27 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jul 2007 00:14:27 +0300
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in py3k-struni
Message-ID: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>

One of the most daunting tasks remaining for Python 3.0a1 (to be
released by the end of August) is fixing the remaining failing unit
tests in the py3k-struni branch
(http://svn.python.org/view/python/branches/py3k-struni/).

This is the branch where I have started the work on the
string/unification branch. I want to promote this branch to become the
"main" Py3k branch ASAP (by renaming it to py3k), but I don't want to
do that until all unit tests pass. I've been working diligently on
this task, and I've got it down to about 50 tests that are failing on
at least one of OSX and Ubuntu (the platforms to which I have easy
access). Now I need help.

To facilitate distributing the task of getting the remaining tests to
pass, I've created a wiki page:
http://wiki.python.org/moin/Py3kStrUniTests . Please help! It's easy
to help: (1) check out the py3k-struni branch; (2) build it; (3) pick
a test and figure out why it's failing; (4) produce a fix; (5) submit
the fix to SF (or check it in, if you have submit privileges and are
confident enough).

In order to avoid duplicate work, I've come up with a simple protocol:
you mark a test in the wiki as "MINE" (with your name) when you start
looking at it. You mark it as "FIXED [IN SF]" once you fix it, adding
the patch# if the fix is in SF. If you give up, remove your lock,
adding instead a note with what you've found (even just the names of
the failing subtests is helpful).

Please help!

There are other tasks, see PEP 3100. Mail me if you're interested in
anything specifically. (Please don't ask me "do you think I could do
this" -- you know better than I whether you're capable of coding at a
specific level. If you don't understand the task, you're probably not
qualified.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From lists at cheimes.de  Wed Jul 11 00:30:13 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 11 Jul 2007 00:30:13 +0200
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
Message-ID: <46940875.2000606@cheimes.de>

Guido van Rossum wrote:
> Please help!

I've made a meta patch that makes debugging the bugs a lot easier. It
replaces assert_(foo == bar) and failUnless(foo == bar) with
failUnlessEqual(foo, bar). failUnlessEqual shows the value of foo and
bar when they are not equal.

http://www.python.org/sf/1751515

sed -r "s/self\.assert_\((.*)\ ==/self.failUnlessEqual\(\1,/" -i *.py
sed -r "s/self\.failUnless\((.*)\ ==/self.failUnlessEqual\(\1,/" -i *.py

By the way the ctypes unit tests are causing a segfault on my machine:
test_ctypes
Warning: could not import ctypes.test.test_numbers: unpack requires a
string argument of length 1
Segmentation fault

Ubunutu 7.04 on i386 machine with an Intel P3.

Christian


From steven.bethard at gmail.com  Wed Jul 11 00:38:53 2007
From: steven.bethard at gmail.com (Steven Bethard)
Date: Tue, 10 Jul 2007 16:38:53 -0600
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <46940875.2000606@cheimes.de>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
	<46940875.2000606@cheimes.de>
Message-ID: <d11dcfba0707101538l1d3c3244i788032054da92717@mail.gmail.com>

On 7/10/07, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
> > Please help!
>
> I've made a meta patch that makes debugging the bugs a lot easier. It
> replaces assert_(foo == bar) and failUnless(foo == bar) with
> failUnlessEqual(foo, bar). failUnlessEqual shows the value of foo and
> bar when they are not equal.
>
> http://www.python.org/sf/1751515
>
> sed -r "s/self\.assert_\((.*)\ ==/self.failUnlessEqual\(\1,/" -i *.py
> sed -r "s/self\.failUnless\((.*)\ ==/self.failUnlessEqual\(\1,/" -i *.py

Some of these look questionable, e.g.:

-        self.assert_(d == self.spamle or d == self.spambe)
+        self.failUnlessEqual(d == self.spamle or d, self.spambe)
...
-        self.assert_((a == 42) is False)
+        self.failUnlessEqual((a, 42) is False)

I'd probably go with something a little more restrictive, maybe:

    r'self.assert_\(\S+ == \S+\)'

Something like that ought to have fewer false positives.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From rasky at develer.com  Wed Jul 11 01:01:07 2007
From: rasky at develer.com (Giovanni Bajo)
Date: Wed, 11 Jul 2007 01:01:07 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <46928B3C.2020602@livinglogic.de>
References: <4690B08E.3010501@livinglogic.de>	<000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>	<ca471dc20707082333w56de18d6k7afa26f0db28616d@mail.gmail.com>	<00b101c7c248$541f4dc0$2500a8c0@RaymondLaptop1>
	<46928B3C.2020602@livinglogic.de>
Message-ID: <f7133k$tls$1@sea.gmane.org>

On 09/07/2007 21.23, Walter D?rwald wrote:

>  >>> from ll.xist import parsers, xfind
>  >>> from ll.xist.ns import html
>  >>> e = parsers.parseURL("http://www.python.org", tidy=True)
>  >>> print e.walknode(html.h2 & xfind.hasclass("news"))[-1]
> Google Adds Python Support to Google Calendar Developer's Guide
> 
> 
> Get the first comment line from a python file:
> 
>  >>> getitem((line for line in open("Lib/codecs.py") if 
> line.startswith("#")), 0)
> '### Registry and builtin stateless codec functions\n'
> 
> 
> Create a new unused identifier:
> 
>  >>> def candidates(base):
> ...     yield base
> ...     for suffix in count(2):
> ...         yield "%s%d" % (base, suffix)
> ...
>  >>> usedids = set(("foo", "bar"))
>  >>> getitem((i for i in candidates("foo") if i not in usedids), 0)
> 'foo2'

You keep posting examples where you call your getitem() function with "0" as 
index, or -1.

getitem(it, 0) already exists and it's spelled it.next(). getitem(it, -1) 
might be useful in fact, and it might be spelled last(it) (or it.last()). Then 
one may want to add first() for simmetry, but that's it:

first(i for i in candidates("foo") if i not in usedids)
last(line for line in open("Lib/codecs.py") if line[0] == '#')

Are there real-world use cases for getitem(it, n) with n not in (0, -1)? I 
share Raymond's feelings on this. And by the way, if you wonder, I have these 
exact feelings as well for islice... :)
-- 
Giovanni Bajo



From lists at cheimes.de  Wed Jul 11 01:17:26 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 11 Jul 2007 01:17:26 +0200
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <d11dcfba0707101538l1d3c3244i788032054da92717@mail.gmail.com>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>	<46940875.2000606@cheimes.de>
	<d11dcfba0707101538l1d3c3244i788032054da92717@mail.gmail.com>
Message-ID: <46941386.9080301@cheimes.de>

Steven Bethard wrote:
> I'd probably go with something a little more restrictive, maybe:
> 
>     r'self.assert_\(\S+ == \S+\)'
> 
> Something like that ought to have fewer false positives.

Woops! You are right. Even your pattern has caused some false positives
but I've reread the patch and removed the offending lines. I'm going to
upload another patch as soon as I have verified mine again.

Christian


From guido at python.org  Wed Jul 11 08:48:49 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jul 2007 09:48:49 +0300
Subject: [Python-Dev] [Python-3000] Need help fixing failing Py3k
	Unittests in py3k-struni
In-Reply-To: <46941386.9080301@cheimes.de>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
	<46940875.2000606@cheimes.de>
	<d11dcfba0707101538l1d3c3244i788032054da92717@mail.gmail.com>
	<46941386.9080301@cheimes.de>
Message-ID: <ca471dc20707102348p78041da9hbd4f08b84d4abab1@mail.gmail.com>

Please use self.assertEqual() instead of self.failUnlessEqual() -- the
assertEqual() form is much more common. Otherwise, good idea!

On 7/11/07, Christian Heimes <lists at cheimes.de> wrote:
> Steven Bethard wrote:
> > I'd probably go with something a little more restrictive, maybe:
> >
> >     r'self.assert_\(\S+ == \S+\)'
> >
> > Something like that ought to have fewer false positives.
>
> Woops! You are right. Even your pattern has caused some false positives
> but I've reread the patch and removed the offending lines. I'm going to
> upload another patch as soon as I have verified mine again.
>
> Christian
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From walter at livinglogic.de  Wed Jul 11 10:11:35 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 11 Jul 2007 10:11:35 +0200
Subject: [Python-Dev] itertools addition: getitem()
In-Reply-To: <f7133k$tls$1@sea.gmane.org>
References: <4690B08E.3010501@livinglogic.de>	<000001c7c1b3$c71ecde0$2500a8c0@RaymondLaptop1>	<ca471dc20707082333w56de18d6k7afa26f0db28616d@mail.gmail.com>	<00b101c7c248$541f4dc0$2500a8c0@RaymondLaptop1>	<46928B3C.2020602@livinglogic.de>
	<f7133k$tls$1@sea.gmane.org>
Message-ID: <469490B7.5040107@livinglogic.de>

Giovanni Bajo wrote:

> On 09/07/2007 21.23, Walter D?rwald wrote:
> 
>>  >>> from ll.xist import parsers, xfind
>>  >>> from ll.xist.ns import html
>>  >>> e = parsers.parseURL("http://www.python.org", tidy=True)
>>  >>> print e.walknode(html.h2 & xfind.hasclass("news"))[-1]
>> Google Adds Python Support to Google Calendar Developer's Guide
>>
>>
>> Get the first comment line from a python file:
>>
>>  >>> getitem((line for line in open("Lib/codecs.py") if 
>> line.startswith("#")), 0)
>> '### Registry and builtin stateless codec functions\n'
>>
>>
>> Create a new unused identifier:
>>
>>  >>> def candidates(base):
>> ...     yield base
>> ...     for suffix in count(2):
>> ...         yield "%s%d" % (base, suffix)
>> ...
>>  >>> usedids = set(("foo", "bar"))
>>  >>> getitem((i for i in candidates("foo") if i not in usedids), 0)
>> 'foo2'
> 
> You keep posting examples where you call your getitem() function with "0" as 
> index, or -1.
> 
> getitem(it, 0) already exists and it's spelled it.next(). getitem(it, -1) 
> might be useful in fact, and it might be spelled last(it) (or it.last()). Then 
> one may want to add first() for simmetry, but that's it:
> 
> first(i for i in candidates("foo") if i not in usedids)
> last(line for line in open("Lib/codecs.py") if line[0] == '#')
> 
> Are there real-world use cases for getitem(it, n) with n not in (0, -1)? I 
> share Raymond's feelings on this. And by the way, if you wonder, I have these 
> exact feelings as well for islice... :)

It useful for screen scraping HTML. Suppose you have the following HTML 
table:

<table>
<tr><td>01.01.2007</td><td>12.34</td><td>Foo</td></tr>
<tr><td>13.01.2007</td><td>23.45</td><td>Bar</td></tr>
<tr><td>04.02.2007</td><td>45.56</td><td>Baz</td></tr>
<tr><td>27.02.2007</td><td>56.78</td><td>Spam</td></tr>
<tr><td>17.03.2007</td><td>67.89</td><td>Eggs</td></tr>
<tr><td>          </td><td>164.51</td><td>Total</td></tr>
<tr><td>          </td><td>(incl. VAT)</td><td></td></tr>
</table>

To extract the total sum, you want the second column from the second to 
last row, i.e. something like:
    row = getitem((r for r in table if r.name == "tr"), -2)
    col = getitem((c for c in row if c.name == "td"), 1)

Servus,
    Walter

From theller at ctypes.org  Wed Jul 11 11:39:18 2007
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 11 Jul 2007 11:39:18 +0200
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <46940875.2000606@cheimes.de>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
	<46940875.2000606@cheimes.de>
Message-ID: <f728g6$6gt$1@sea.gmane.org>

Christian Heimes schrieb:
> 
> By the way the ctypes unit tests are causing a segfault on my machine:
> test_ctypes
> Warning: could not import ctypes.test.test_numbers: unpack requires a
> string argument of length 1
> Segmentation fault
> 
> Ubunutu 7.04 on i386 machine with an Intel P3.

I can reproduce this.  ctypes.test.test_numbers is easy to fix, but there
are other severe problems with ctypes.

I would love to look into these, but I prefer debugging on Windows.
However, the windows build does not work because the _fileio builtin
module is missing from config.c.  Again, this is not so easy to fix,
because the ftruncate function does not exist on Windows.

Thomas


From guido at python.org  Wed Jul 11 13:46:12 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 11 Jul 2007 14:46:12 +0300
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <f728g6$6gt$1@sea.gmane.org>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
	<46940875.2000606@cheimes.de> <f728g6$6gt$1@sea.gmane.org>
Message-ID: <ca471dc20707110446je177145x8d0b0cf2ca2f8487@mail.gmail.com>

On 7/11/07, Thomas Heller <theller at ctypes.org> wrote:
> Christian Heimes schrieb:
> >
> > By the way the ctypes unit tests are causing a segfault on my machine:
> > test_ctypes
> > Warning: could not import ctypes.test.test_numbers: unpack requires a
> > string argument of length 1
> > Segmentation fault
> >
> > Ubunutu 7.04 on i386 machine with an Intel P3.
>
> I can reproduce this.  ctypes.test.test_numbers is easy to fix, but there
> are other severe problems with ctypes.
>
> I would love to look into these, but I prefer debugging on Windows.
> However, the windows build does not work because the _fileio builtin
> module is missing from config.c.  Again, this is not so easy to fix,
> because the ftruncate function does not exist on Windows.

I don't have a Windows box; contributions to fix this situation are welcome.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From thomas at python.org  Wed Jul 11 14:03:56 2007
From: thomas at python.org (Thomas Wouters)
Date: Wed, 11 Jul 2007 05:03:56 -0700
Subject: [Python-Dev] SVN precommit hook
Message-ID: <9e804ac0707110503t25aacce8ma2599b6f2e103f5d@mail.gmail.com>

I just got this traceback trying to do a rather large checkin:

Transmitting file data
............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................svn:
Commit failed (details follow):
svn: 'pre-commit' hook failed with error output:
file /python/branches/p3yk-noslice/Lib/test/string_tests.py is not
whitespace-normalized
file /python/branches/p3yk-noslice/Doc/tools/buildindex.py is not
whitespace-normalized
file /python/branches/p3yk-noslice/Lib/test/test_array.py is not
whitespace-normalized
Traceback (most recent call last):
  File "/data/repos/projects/hooks/checkwhitespace.py", line 50, in ?
  File "/var/lib/python-support/python2.4/svn/core.py", line 217, in run_app
  File "/data/repos/projects/hooks/checkwhitespace.py", line 32, in main
  File "/var/lib/python-support/python2.4/libsvn/fs.py", line 381, in
svn_fs_node_prop
libsvn._core.SubversionException: ("Can't open file
'/data/repos/projects/db/transactions/56255-1.txn/props': Too many open
files", 24)

I'm not complaining about the whitespace-normalization issues, but rather
the open files issue ;-P It sounds like a buglet somewhere, although it may
be in libsvn.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070711/3b7e1030/attachment.htm 

From thomas at python.org  Wed Jul 11 14:09:34 2007
From: thomas at python.org (Thomas Wouters)
Date: Wed, 11 Jul 2007 05:09:34 -0700
Subject: [Python-Dev] SVN precommit hook
In-Reply-To: <9e804ac0707110503t25aacce8ma2599b6f2e103f5d@mail.gmail.com>
References: <9e804ac0707110503t25aacce8ma2599b6f2e103f5d@mail.gmail.com>
Message-ID: <9e804ac0707110509y7f94fde8te9beea769fff6909@mail.gmail.com>

On 7/11/07, Thomas Wouters <thomas at python.org> wrote:
>
>
> I just got this traceback trying to do a rather large checkin:
>
> Transmitting file data
> ............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................svn:
> Commit failed (details follow):
> svn: 'pre-commit' hook failed with error output:
> file /python/branches/p3yk-noslice/Lib/test/string_tests.py is not
> whitespace-normalized
> file /python/branches/p3yk-noslice/Doc/tools/buildindex.py is not
> whitespace-normalized
> file /python/branches/p3yk-noslice/Lib/test/test_array.py is not
> whitespace-normalized
> Traceback (most recent call last):
>   File "/data/repos/projects/hooks/checkwhitespace.py", line 50, in ?
>   File "/var/lib/python-support/python2.4/svn/core.py", line 217, in
> run_app
>   File "/data/repos/projects/hooks/checkwhitespace.py", line 32, in main
>   File "/var/lib/python-support/python2.4/libsvn/fs.py", line 381, in
> svn_fs_node_prop
> libsvn._core.SubversionException: ("Can't open file
> '/data/repos/projects/db/transactions/56255- 1.txn/props': Too many open
> files", 24)
>
> I'm not complaining about the whitespace-normalization issues, but rather
> the open files issue ;-P It sounds like a buglet somewhere, although it may
> be in libsvn.


Oh, and for the record, it also fails when there are no whitespace issues to
fix. I can't check in my (admittedly somewhat big) svnmerge now. It touches
about 1130 files.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070711/09fbe7a6/attachment.html 

From thomas at python.org  Wed Jul 11 15:46:18 2007
From: thomas at python.org (Thomas Wouters)
Date: Wed, 11 Jul 2007 06:46:18 -0700
Subject: [Python-Dev] SVN precommit hook
In-Reply-To: <9e804ac0707110503t25aacce8ma2599b6f2e103f5d@mail.gmail.com>
References: <9e804ac0707110503t25aacce8ma2599b6f2e103f5d@mail.gmail.com>
Message-ID: <9e804ac0707110646y1e4f3a8btb49a689cd4d8de88@mail.gmail.com>

On 7/11/07, Thomas Wouters <thomas at python.org> wrote:

> libsvn._core.SubversionException: ("Can't open file
> '/data/repos/projects/db/transactions/56255- 1.txn/props': Too many open
> files", 24)


Fixed. The problem was that checkwhitespace.py wasn't closing the SVN
streams it was reading. Added the 'svn_stream_close' call and my checkin got
through. Should be safe to do massive checkins from now on ;-)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070711/d4f136a8/attachment.html 

From fuzzyman at voidspace.org.uk  Wed Jul 11 17:50:13 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 11 Jul 2007 16:50:13 +0100
Subject: [Python-Dev] Need help fixing failing Py3k Unittests
	in	py3k-struni
In-Reply-To: <ca471dc20707110446je177145x8d0b0cf2ca2f8487@mail.gmail.com>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>	<46940875.2000606@cheimes.de>
	<f728g6$6gt$1@sea.gmane.org>
	<ca471dc20707110446je177145x8d0b0cf2ca2f8487@mail.gmail.com>
Message-ID: <4694FC35.3050205@voidspace.org.uk>

Guido van Rossum wrote:
> On 7/11/07, Thomas Heller <theller at ctypes.org> wrote:
>   
>> Christian Heimes schrieb:
>>     
>>> By the way the ctypes unit tests are causing a segfault on my machine:
>>> test_ctypes
>>> Warning: could not import ctypes.test.test_numbers: unpack requires a
>>> string argument of length 1
>>> Segmentation fault
>>>
>>> Ubunutu 7.04 on i386 machine with an Intel P3.
>>>       
>> I can reproduce this.  ctypes.test.test_numbers is easy to fix, but there
>> are other severe problems with ctypes.
>>
>> I would love to look into these, but I prefer debugging on Windows.
>> However, the windows build does not work because the _fileio builtin
>> module is missing from config.c.  Again, this is not so easy to fix,
>> because the ftruncate function does not exist on Windows.
>>     
>
> I don't have a Windows box; contributions to fix this situation are welcome.
>   

You would accept a donated Windows box ? (1/2 ;-)

Michael Foord

From alex.neundorf at kitware.com  Wed Jul 11 19:12:49 2007
From: alex.neundorf at kitware.com (Alexander Neundorf)
Date: Wed, 11 Jul 2007 13:12:49 -0400
Subject: [Python-Dev] [PATCH] fixing 2.5.1 build with unicode and dynamic
	loading disabled
Message-ID: <200707111312.49908.alex.neundorf@kitware.com>

Hi,

this is my first email to this list, I'm currently porting python to some 
platforms with limited capabilities and so I thought it would be a good idea 
to subscribe here.
While doing the porting, I found two small problems in Python 2.5.1:

If Py_USING_UNICODE is disabled, in Python/ast.c decode_unicode() still calls 
unicode-related functions, which leads to undefined references when linking.

If HAVE_DYNAMIC_LOADING is disabled, in Python/import.c 
_PyImport_DynLoadFiletab is still initialized, which also leads to undefined 
references when linking, since then no source file which defines this 
variable is used.

A patch against 2.5.1 is attached.

Best regards
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-2.5.1.diff
Type: text/x-diff
Size: 1795 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20070711/f1dcb6a7/attachment.bin 

From chrism at plope.com  Wed Jul 11 19:16:01 2007
From: chrism at plope.com (Chris McDonough)
Date: Wed, 11 Jul 2007 13:16:01 -0400
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
Message-ID: <FB45562E-60A9-4369-837B-ECD846981ED1@plope.com>

I have a very remedial question about how to fix test failures due to  
the side effects of string-unicode integration.

The xmlrpc library uses explicit encoding to encode XML tag payloads  
to (almost always) utf8.  Tag literals are not encoded.

What would be the best way to mimic this behavior under the new  
regime?  Just use unicode everywhere and encode the entire XML body  
to utf-8 at the end?  Or deal explicitly in bytes everywhere?  Or..?

Remedially,

- C

On Jul 10, 2007, at 5:14 PM, Guido van Rossum wrote:

> One of the most daunting tasks remaining for Python 3.0a1 (to be
> released by the end of August) is fixing the remaining failing unit
> tests in the py3k-struni branch
> (http://svn.python.org/view/python/branches/py3k-struni/).
>
> This is the branch where I have started the work on the
> string/unification branch. I want to promote this branch to become the
> "main" Py3k branch ASAP (by renaming it to py3k), but I don't want to
> do that until all unit tests pass. I've been working diligently on
> this task, and I've got it down to about 50 tests that are failing on
> at least one of OSX and Ubuntu (the platforms to which I have easy
> access). Now I need help.
>
> To facilitate distributing the task of getting the remaining tests to
> pass, I've created a wiki page:
> http://wiki.python.org/moin/Py3kStrUniTests . Please help! It's easy
> to help: (1) check out the py3k-struni branch; (2) build it; (3) pick
> a test and figure out why it's failing; (4) produce a fix; (5) submit
> the fix to SF (or check it in, if you have submit privileges and are
> confident enough).
>
> In order to avoid duplicate work, I've come up with a simple protocol:
> you mark a test in the wiki as "MINE" (with your name) when you start
> looking at it. You mark it as "FIXED [IN SF]" once you fix it, adding
> the patch# if the fix is in SF. If you give up, remove your lock,
> adding instead a note with what you've found (even just the names of
> the failing subtests is helpful).
>
> Please help!
>
> There are other tasks, see PEP 3100. Mail me if you're interested in
> anything specifically. (Please don't ask me "do you think I could do
> this" -- you know better than I whether you're capable of coding at a
> specific level. If you don't understand the task, you're probably not
> qualified.)
>
> -- 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists 
> %40plope.com
>


From pogonyshev at gmx.net  Wed Jul 11 20:46:33 2007
From: pogonyshev at gmx.net (Paul Pogonyshev)
Date: Wed, 11 Jul 2007 21:46:33 +0300
Subject: [Python-Dev] proposed attribute lookup optimization
Message-ID: <200707112146.33680.pogonyshev@gmx.net>

[I don't know why I didn't receive this mail, presumably spam filter
at gmx.net sucks as always]

Phillip J. Eby wrote:
> At 08:23 PM 7/8/2007 +0300, Paul Pogonyshev wrote:
> >I would like to propose an optimization (I think so, anyway) for the
> >way attributes are looked up.  [...]
> 
> [...]
>
> Again, though, this has already been proposed, and I believe there's 
> a patch awaiting review for inclusion in 2.6 (and presumably 3.0).

OK, good to know.  Of course it is better if done by someone familiar
with Python internals :)  After proposing this I decided it wasn't
worthwile, since it would require cache revalidation after any
assignment to a new class attribute.  But supposedly I just have
incorrect picture of what is often in Python :)

Paul

From aahz at pythoncraft.com  Wed Jul 11 21:01:42 2007
From: aahz at pythoncraft.com (Aahz)
Date: Wed, 11 Jul 2007 12:01:42 -0700
Subject: [Python-Dev] [PATCH] fixing 2.5.1 build with unicode and
	dynamic loading disabled
In-Reply-To: <200707111312.49908.alex.neundorf@kitware.com>
References: <200707111312.49908.alex.neundorf@kitware.com>
Message-ID: <20070711190141.GA2259@panix.com>

On Wed, Jul 11, 2007, Alexander Neundorf wrote:
>
> A patch against 2.5.1 is attached.

Patches to the list tend to get lost.  Please post to SourceForge and
then send the ID to python-dev.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

I support the RKAB

From alex.neundorf at kitware.com  Wed Jul 11 21:40:49 2007
From: alex.neundorf at kitware.com (Alexander Neundorf)
Date: Wed, 11 Jul 2007 15:40:49 -0400
Subject: [Python-Dev] [PATCH] fixing 2.5.1 build with unicode and
	dynamic loading disabled
In-Reply-To: <20070711190141.GA2259@panix.com>
References: <200707111312.49908.alex.neundorf@kitware.com>
	<20070711190141.GA2259@panix.com>
Message-ID: <200707111540.49637.alex.neundorf@kitware.com>

On Wednesday 11 July 2007 15:01, Aahz wrote:
> On Wed, Jul 11, 2007, Alexander Neundorf wrote:
> > A patch against 2.5.1 is attached.
>
> Patches to the list tend to get lost.  Please post to SourceForge and
> then send the ID to python-dev.

Done, it's #1752175

Alex

From martin at v.loewis.de  Wed Jul 11 22:46:47 2007
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 11 Jul 2007 22:46:47 +0200
Subject: [Python-Dev] SVN precommit hook
In-Reply-To: <9e804ac0707110646y1e4f3a8btb49a689cd4d8de88@mail.gmail.com>
References: <9e804ac0707110503t25aacce8ma2599b6f2e103f5d@mail.gmail.com>
	<9e804ac0707110646y1e4f3a8btb49a689cd4d8de88@mail.gmail.com>
Message-ID: <469541B7.8080603@v.loewis.de>

> Fixed. The problem was that checkwhitespace.py wasn't closing the SVN
> streams it was reading. Added the 'svn_stream_close' call and my checkin
> got through. Should be safe to do massive checkins from now on ;-)

Thanks for fixing it. Those of you having access to dinsdale, feel free
to temporarily disable this particular hook in the future if you find it
is in your way; don't forgot to report the problem at least, and try
enabling it after the questionable checkin has completed.

Regards,
Martin

From guido at python.org  Wed Jul 11 23:05:39 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Jul 2007 00:05:39 +0300
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <FB45562E-60A9-4369-837B-ECD846981ED1@plope.com>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>
	<FB45562E-60A9-4369-837B-ECD846981ED1@plope.com>
Message-ID: <ca471dc20707111405q44922c5chaba514e734f86c9@mail.gmail.com>

On 7/11/07, Chris McDonough <chrism at plope.com> wrote:
> I have a very remedial question about how to fix test failures due to
> the side effects of string-unicode integration.
>
> The xmlrpc library uses explicit encoding to encode XML tag payloads
> to (almost always) utf8.  Tag literals are not encoded.
>
> What would be the best way to mimic this behavior under the new
> regime?  Just use unicode everywhere and encode the entire XML body
> to utf-8 at the end?  Or deal explicitly in bytes everywhere?  Or..?

The correct approach would be to use Unicode (i.e., str) everywhere
and encode to UTF-8 at the end. If that's too hard something's wrong
with the philosophy of using Unicode everywhere...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From matthew at woodcraft.me.uk  Thu Jul 12 01:20:18 2007
From: matthew at woodcraft.me.uk (Matthew Woodcraft)
Date: Wed, 11 Jul 2007 23:20:18 +0000 (UTC)
Subject: [Python-Dev] Subprocesses and SIGPIPE
Message-ID: <f73oji$juu$1@sea.gmane.org>

The documentation for the subprocess module says that it can be used as a
replacement for shell pipelines, and gives an example.

On *nix systems, cpython is set to ignore SIGPIPE, and this setting is
inherited by child processes created by the subprocess module. This is nearly
always not what you want when you're constructing a pipeline.

In practice, I think most programs are not particularly designed (or tested)
to run with SIGPIPE ignored, and I've had trouble caused by this a couple of
times now.

If you know about this, it's easy enough to avoid trouble using something like
this as a preexec_fn for subprocess.Popen:

def permit_sigpipe():
    signal.signal(signal.SIGPIPE, signal.SIG_DFL)

My question is: should subprocess.Popen do this by default? In any case, it
would be good to see this issue mentioned near the pipeline example.

-M-



From steve at holdenweb.com  Thu Jul 12 03:06:17 2007
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 11 Jul 2007 21:06:17 -0400
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <4694FC35.3050205@voidspace.org.uk>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>	<46940875.2000606@cheimes.de>	<f728g6$6gt$1@sea.gmane.org>	<ca471dc20707110446je177145x8d0b0cf2ca2f8487@mail.gmail.com>
	<4694FC35.3050205@voidspace.org.uk>
Message-ID: <46957E89.5000302@holdenweb.com>

Michael Foord wrote:
> Guido van Rossum wrote:
>> On 7/11/07, Thomas Heller <theller at ctypes.org> wrote:
>>   
>>> Christian Heimes schrieb:
>>>     
>>>> By the way the ctypes unit tests are causing a segfault on my machine:
>>>> test_ctypes
>>>> Warning: could not import ctypes.test.test_numbers: unpack requires a
>>>> string argument of length 1
>>>> Segmentation fault
>>>>
>>>> Ubunutu 7.04 on i386 machine with an Intel P3.
>>>>       
>>> I can reproduce this.  ctypes.test.test_numbers is easy to fix, but there
>>> are other severe problems with ctypes.
>>>
>>> I would love to look into these, but I prefer debugging on Windows.
>>> However, the windows build does not work because the _fileio builtin
>>> module is missing from config.c.  Again, this is not so easy to fix,
>>> because the ftruncate function does not exist on Windows.
>>>     
>> I don't have a Windows box; contributions to fix this situation are welcome.
>>   
> 
> You would accept a donated Windows box ? (1/2 ;-)
> 
Please don't force Guido to spend valuable development time climbing 
*that* learning curve!

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

From steve at holdenweb.com  Thu Jul 12 03:06:17 2007
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 11 Jul 2007 21:06:17 -0400
Subject: [Python-Dev] Need help fixing failing Py3k Unittests in
	py3k-struni
In-Reply-To: <4694FC35.3050205@voidspace.org.uk>
References: <ca471dc20707101414q77168e32v12b157c2ab756394@mail.gmail.com>	<46940875.2000606@cheimes.de>	<f728g6$6gt$1@sea.gmane.org>	<ca471dc20707110446je177145x8d0b0cf2ca2f8487@mail.gmail.com>
	<4694FC35.3050205@voidspace.org.uk>
Message-ID: <46957E89.5000302@holdenweb.com>

Michael Foord wrote:
> Guido van Rossum wrote:
>> On 7/11/07, Thomas Heller <theller at ctypes.org> wrote:
>>   
>>> Christian Heimes schrieb:
>>>     
>>>> By the way the ctypes unit tests are causing a segfault on my machine:
>>>> test_ctypes
>>>> Warning: could not import ctypes.test.test_numbers: unpack requires a
>>>> string argument of length 1
>>>> Segmentation fault
>>>>
>>>> Ubunutu 7.04 on i386 machine with an Intel P3.
>>>>       
>>> I can reproduce this.  ctypes.test.test_numbers is easy to fix, but there
>>> are other severe problems with ctypes.
>>>
>>> I would love to look into these, but I prefer debugging on Windows.
>>> However, the windows build does not work because the _fileio builtin
>>> module is missing from config.c.  Again, this is not so easy to fix,
>>> because the ftruncate function does not exist on Windows.
>>>     
>> I don't have a Windows box; contributions to fix this situation are welcome.
>>   
> 
> You would accept a donated Windows box ? (1/2 ;-)
> 
Please don't force Guido to spend valuable development time climbing 
*that* learning curve!

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------


From andychup at gmail.com  Thu Jul 12 04:43:45 2007
From: andychup at gmail.com (Andy C)
Date: Wed, 11 Jul 2007 19:43:45 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
Message-ID: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>

(resending this now that I'm subscribed, not sure it made it through
the moderation the first time)

I'd like to request comments on this patch I submitted:

https://sourceforge.net/tracker/index.php?func=detail&aid=1739468&group_id=5470&atid=305470

There are many details given in the comments on that page.

This can be used to deploy Python programs in a very lightweight and
cross-platform way.  You could imagine a cgi script or a light web app
server being deployed like this.  I have personally deployed Python
programs using zip files and this would get rid of the need for
boilerplate needed for each platform.

The good thing about this is that it's extremely simple -- basically
20 lines of C code to add a -z flag that calls a 3-line Python
function in the runpy module.

I don't believe it overlaps with anything that already exists.  py2exe
and py2app are platform specific and bundle the Python interpreter.
This will be a cross platform binary that doesn't bundle the Python
interpreter.  It doesn't require eggs but I think it would work fine
with eggs, and could help fix a little bug as I mentioned on the patch
page.

Nick Coghlan has reviewed the patch and seems to think it's a good
idea.  Thomas Wouters also said he likes it, and I ran it by Guido
earlier and he seemed to think the idea is good, although I don't
think he has seen the implementation.

thanks,
Andy

From martin at v.loewis.de  Thu Jul 12 07:36:38 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 12 Jul 2007 07:36:38 +0200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
Message-ID: <4695BDE6.8030109@v.loewis.de>

> Nick Coghlan has reviewed the patch and seems to think it's a good
> idea.  Thomas Wouters also said he likes it, and I ran it by Guido
> earlier and he seemed to think the idea is good, although I don't
> think he has seen the implementation.

See my comment: I must be missing the point of the patch, since
I can do the same thing (make a single executable zip file on
Linux) through a /bin/sh header just fine.

Regards,
Martin

From andychup at gmail.com  Thu Jul 12 08:46:27 2007
From: andychup at gmail.com (Andy C)
Date: Wed, 11 Jul 2007 23:46:27 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <4695BDE6.8030109@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
Message-ID: <596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>

On 7/11/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Nick Coghlan has reviewed the patch and seems to think it's a good
> > idea.  Thomas Wouters also said he likes it, and I ran it by Guido
> > earlier and he seemed to think the idea is good, although I don't
> > think he has seen the implementation.
>
> See my comment: I must be missing the point of the patch, since
> I can do the same thing (make a single executable zip file on
> Linux) through a /bin/sh header just fine.

Right, but it's supposed to be cross platform, as mentioned in the
patch.  This will work on Windows.  The main problem I see is that a
shell script in front of a zip file seems like a relatively common
idiom that people use and have different variants on, each of which
have their own idiosyncrasies.  So it would nice to consolidate them
and make it standard and robust.

For example, it looks like eggs have an executable format that is
similar to this.  And see the bug I mentioned where those executable
eggs can't be invoked through a symlink (which to me is a relatively
severe problem).  I think this has to do with some introspection on
$0, but you won't run into that with this implementation.

Also, I mentioned the program called autopar we use at Google that
does the same thing, and it also have a significant number of weird
hacks in the shell header.  I think Thomas Wouters has also worked on
another program to make an executable zip file.

Another example is that the behavior of the zip in your example
depends on what else is in the current directory [1], which isn't
desirable.  Nick pointed out this issue and I addressed it in the
patch by removing "" from sys.path, since the -c flag adds that.  If
lots of people reinvent this wheel (and they have), there are going to
be other subtleties like this that will be missed.

The -z flag also eliminates starting an extra process -- you invoke
the Python interpreter directly instead of starting a shell which in
turn invokes the Python interpreter.

As mentioned, it's also a very tiny amount of code, and I don't see
much potential for bad interactions with other things, the way I've
written it.

Andy

1)
andychu test2$ ./foo_exe.zip
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "foo.py", line 16, in ?
    import outside
ImportError: No module named outside

andychu test2$ touch outside.py

andychu test2$ ./foo_exe.zip
main

andychu test2$

From martin at v.loewis.de  Thu Jul 12 10:09:55 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 12 Jul 2007 10:09:55 +0200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
Message-ID: <4695E1D3.8080608@v.loewis.de>

> Right, but it's supposed to be cross platform, as mentioned in the
> patch.  This will work on Windows.

But in the description, you said that you do the same on Windows
by making a file that is both a zip file and a batch file. So my
approach is also cross-platform, no?

How do you get the -z option to work on Windows? What extension
do you use, and how is the zipfile created?

> The main problem I see is that a
> shell script in front of a zip file seems like a relatively common
> idiom that people use and have different variants on, each of which
> have their own idiosyncrasies.  So it would nice to consolidate them
> and make it standard and robust.

Couldn't that also be achieved by documenting best practice in
the documentation? Why is the shell script not robust?

> For example, it looks like eggs have an executable format that is
> similar to this.  And see the bug I mentioned where those executable
> eggs can't be invoked through a symlink (which to me is a relatively
> severe problem).  I think this has to do with some introspection on
> $0, but you won't run into that with this implementation.

Why that? Why do eggs fail to process $0 correctly, whereas the
-z option gets it correct? That just sounds like a bug in eggs
to me, that could be fixed - or, if not, I'd expect that -z
cannot fix it, either.

My understanding of this note is that
pkg_resources uses sys.argv[0] to determine the version number
of the egg; IIUC, -z won't help at all here because sys.argv[0]
will still be the name of the symlink.

> Also, I mentioned the program called autopar we use at Google that
> does the same thing, and it also have a significant number of weird
> hacks in the shell header.  I think Thomas Wouters has also worked on
> another program to make an executable zip file.

What are those weird hacks, why are they necessary, and how does the
-z option overcome the need for these hacks?

That people fail to make it work with /bin/sh doesn't automatically
mean they succeed with -z. Either they are too unexperienced to
make the shell header correct (in which case documenting best
practice would help), or they have deeper problems with that approach,
in which case it isn't at all obvious that the proposed change
improves anything.

> Another example is that the behavior of the zip in your example
> depends on what else is in the current directory [1], which isn't
> desirable.  Nick pointed out this issue and I addressed it in the
> patch by removing "" from sys.path, since the -c flag adds that.

"" should not be removed from sys.path. It is *not* meant to be
the current directory, but the directory where the main script
lives.

> The -z flag also eliminates starting an extra process -- you invoke
> the Python interpreter directly instead of starting a shell which in
> turn invokes the Python interpreter.

See my script. It does not start (fork) another process. Instead,
the existing process gets reused. It execs another program, true.

> As mentioned, it's also a very tiny amount of code, and I don't see
> much potential for bad interactions with other things, the way I've
> written it.

It's baggage that is rarely needed, and the feature can be readily
implemented in a different way for people who need it.

Regards,
Martin


From thomas at python.org  Thu Jul 12 10:37:58 2007
From: thomas at python.org (Thomas Wouters)
Date: Thu, 12 Jul 2007 01:37:58 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <4695E1D3.8080608@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
Message-ID: <9e804ac0707120137h54861df1mc31528efac2e3392@mail.gmail.com>

On 7/12/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> > Right, but it's supposed to be cross platform, as mentioned in the
> > patch.  This will work on Windows.
>
> But in the description, you said that you do the same on Windows
> by making a file that is both a zip file and a batch file. So my
> approach is also cross-platform, no?


The approach is cross-platform, in that you can use the approach on
different platforms. The result of the approach, however, is not
cross-platform. You can't distribute your single zip-as-executable to both
Windows and bourne-shell-using platforms. The -z argument does allow that.

Why is the shell script not robust?


There are a lot of subtleties in figuring out which python to execute,
environment variables that you may or may not want to tweak (admittedly
Google's solution that Andy referenced is more vulnerable to that, but it's
not unique to Google by any means.) If you want any kind of flexibility in
the packaged-up program, you need a bunch of logic in the shell script, and
environment-tricks to pass information to the python process, start the
python process and provide a bunch more logic in Python to boot. For
instance, you need to set PYTHONPATH to include the zipfile before you can
import from it, but you don't want that PYTHONPATH to be passed to
subprocesses by accident.

The -z argument makes it extremely simple: the user decides which python to
run, and the program is run directly just like it would if it was unpacked
and run that way.  It makes it extremely easy to create 'single executables'
out of multiple Python files, in the form that single .py files already are.
It leaves building a more complex system (such as eggs) ontop of it entirely
open. The change is a good thing, IMHO. And I say this not because we use a
similar solution at Google -- we already solved it, and we won't be using
the -z argument anytime soon anyway. I say this because I've had many
requests from non-googlers for something exactly like this :)

"" should not be removed from sys.path. It is *not* meant to be
> the current directory, but the directory where the main script
> lives.


Yes. "" should either be interpreted as the zipfile, or be replaced by the
zipfile. In the case of executing the zipfile, the main script lives *in the
zipfile*.

It's baggage that is rarely needed, and the feature can be readily
> implemented in a different way for people who need it.


I disagree with both statements. The bagage is much less than zipimport
itself, which has proven to be quite useful. Nevertheless, zipimport built
into the interpreter was by no means necessary; current users of it could
have readily implemented it themselves, with no changes to Python. (In fact,
Google's 'autopar' tool does exactly that to support Python 2.2, which lacks
zipimport.) This is a very small, logical and useful extension to zipimport,
and I believe you will find more uses for it than you expect (although I do
believe you yourself don't have a need for it. I just don't think you're a
typical Python programmer in this case :)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070712/c940523e/attachment.html 

From guido at python.org  Thu Jul 12 10:41:08 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Jul 2007 11:41:08 +0300
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <9e804ac0707120137h54861df1mc31528efac2e3392@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<9e804ac0707120137h54861df1mc31528efac2e3392@mail.gmail.com>
Message-ID: <ca471dc20707120141g49ad21cfo4b73cead7836bcd1@mail.gmail.com>

On 7/12/07, Thomas Wouters <thomas at python.org> wrote:
> On 7/12/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > > Right, but it's supposed to be cross platform, as mentioned in the
> > > patch.  This will work on Windows.
> >
> > But in the description, you said that you do the same on Windows
> > by making a file that is both a zip file and a batch file. So my
> > approach is also cross-platform, no?
>
> The approach is cross-platform, in that you can use the approach on
> different platforms. The result of the approach, however, is not
> cross-platform. You can't distribute your single zip-as-executable to both
> Windows and bourne-shell-using platforms. The -z argument does allow that.
>
> > Why is the shell script not robust?
>
> There are a lot of subtleties in figuring out which python to execute,
> environment variables that you may or may not want to tweak (admittedly
> Google's solution that Andy referenced is more vulnerable to that, but it's
> not unique to Google by any means.) If you want any kind of flexibility in
> the packaged-up program, you need a bunch of logic in the shell script, and
> environment-tricks to pass information to the python process, start the
> python process and provide a bunch more logic in Python to boot. For
> instance, you need to set PYTHONPATH to include the zipfile before you can
> import from it, but you don't want that PYTHONPATH to be passed to
> subprocesses by accident.
>
> The -z argument makes it extremely simple: the user decides which python to
> run, and the program is run directly just like it would if it was unpacked
> and run that way.  It makes it extremely easy to create 'single executables'
> out of multiple Python files, in the form that single .py files already are.
> It leaves building a more complex system (such as eggs) ontop of it entirely
> open. The change is a good thing, IMHO. And I say this not because we use a
> similar solution at Google -- we already solved it, and we won't be using
> the -z argument anytime soon anyway. I say this because I've had many
> requests from non-googlers for something exactly like this :)
>
>
> > "" should not be removed from sys.path . It is *not* meant to be
> > the current directory, but the directory where the main script
> > lives.
>
> Yes. "" should either be interpreted as the zipfile, or be replaced by the
> zipfile. In the case of executing the zipfile, the main script lives *in the
> zipfile*.
> > It's baggage that is rarely needed, and the feature can be readily
> > implemented in a different way for people who need it.
>
> I disagree with both statements. The bagage is much less than zipimport
> itself, which has proven to be quite useful. Nevertheless, zipimport built
> into the interpreter was by no means necessary; current users of it could
> have readily implemented it themselves, with no changes to Python. (In fact,
> Google's 'autopar' tool does exactly that to support Python 2.2, which lacks
> zipimport.) This is a very small, logical and useful extension to zipimport,
> and I believe you will find more uses for it than you expect (although I do
> believe you yourself don't have a need for it. I just don't think you're a
> typical Python programmer in this case :)

+1.

(Hi Andy! :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Thu Jul 12 11:27:53 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 12 Jul 2007 12:27:53 +0300
Subject: [Python-Dev] PEP 366 - Relative imports from main modules
In-Reply-To: <46935133.7000401@gmail.com>
References: <20070705162235.5F16A3A405F@sparrow.telecommunity.com>
	<bbaeab100707051017o2f21040ar4a6d2cfd5233cedd@mail.gmail.com>
	<20070706080601.8C3B.JCARLSON@uci.edu> <46909774.7030602@gmail.com>
	<bbaeab100707081147m7d1949e9oa5c450e59a0a9a86@mail.gmail.com>
	<46920F53.7070904@gmail.com>
	<bbaeab100707091214u131e5bdcw3056c5af99d85cd2@mail.gmail.com>
	<46935133.7000401@gmail.com>
Message-ID: <ca471dc20707120227o515c169na8c49e1872bcad08@mail.gmail.com>

I'm in general in favor of this. I will accept it once there is a
working implementation that is satisfactory.

Are we planning on supporting this in 2.6? It might break some 2.5
code that messes with modules and packages?

--Guido

On 7/10/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
> > On 7/9/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >> Given the above limitations, I propose that we document the new
> >> attribute as follows:
> >>
> >> "If the module global __package__ exists when executing an import
> >> statement, it is used to determine the base for relative imports,
> >> instead of the __name__ and __path__ attributes.
> >
> > That's fine.  __path__ actually isn't used to resolve relative imports
> > into absolute ones anyway; it's used only as a substitute to sys.path
> > when importing within a package.
>
> I was referring to the fact that if __path__ is present (indicating a
> package), then the relative import is based directly on __name__,
> otherwise it is based on __name__.rpartition('.')[0].
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
>              http://www.boredomandlaziness.org
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From glyph at divmod.com  Thu Jul 12 11:33:59 2007
From: glyph at divmod.com (glyph at divmod.com)
Date: Thu, 12 Jul 2007 09:33:59 -0000
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <ca471dc20707120141g49ad21cfo4b73cead7836bcd1@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<9e804ac0707120137h54861df1mc31528efac2e3392@mail.gmail.com>
	<ca471dc20707120141g49ad21cfo4b73cead7836bcd1@mail.gmail.com>
Message-ID: <20070712093359.26384.1543070356.divmod.xquotient.718@joule.divmod.com>

On 08:41 am, guido at python.org wrote:
>On 7/12/07, Thomas Wouters <thomas at python.org> wrote:

>>I disagree with both statements. The bagage is much less than 
>>zipimport
>>itself, which has proven to be quite useful. Nevertheless, zipimport 
>>built
>>into the interpreter was by no means necessary; current users of it 
>>could
>>have readily implemented it themselves, with no changes to Python.

I wonder, is it even necessary to say anything, after:
>+1.

?

But, since I so often object to new features, and there is a heavy 
Google bias in the existing survey sample, I would like to say that I 
had a problem several months ago in a _radically_ different environment 
(Twisted running on an embedded system, Zipfile of PYCs used to shave 
off as much disk space and startup time as possible) where having the 
subtleties of a "-z" flag figured out already would have saved me a 
_ton_ of work.  I was already aware of the shell-header trick, but 
discovering all the environment-setup details was tedious and 
distracting enough to make me give up and switch to writing a bunch of 
hard-to-test /bin/sh code.

It wasn't a bad project by any means, and Python worked out even better 
than expected (we weren't even sure if it would be able to load into the 
memory available, but it turns out that being able to do everything in a 
single process helped a lot) but a -z option would have been that much 
more impressive :).

In fact, I distinctly remember thinking "You know, if Python had an 
equivalent to Java's '-jar' option, this would be a whole lot easier."

(Even better, on this _particular_ project, would have been a generic 
"run this thing-which-looks-like-a-sys.path-entry" standard format, 
which could have been switched for different deployments to a directory, 
a zipfile, or the result of freezing.  Perhaps that's starting to get 
too obscure, though.)

From p.f.moore at gmail.com  Thu Jul 12 11:44:09 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 12 Jul 2007 10:44:09 +0100
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <20070712093359.26384.1543070356.divmod.xquotient.718@joule.divmod.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<9e804ac0707120137h54861df1mc31528efac2e3392@mail.gmail.com>
	<ca471dc20707120141g49ad21cfo4b73cead7836bcd1@mail.gmail.com>
	<20070712093359.26384.1543070356.divmod.xquotient.718@joule.divmod.com>
Message-ID: <79990c6b0707120244p1e13c81dgf67a99681d659130@mail.gmail.com>

On 12/07/07, glyph at divmod.com <glyph at divmod.com> wrote:
> I wonder, is it even necessary to say anything, after:
> >+1.
[...]
> In fact, I distinctly remember thinking "You know, if Python had an
> equivalent to Java's '-jar' option, this would be a whole lot easier."

I'm also +1 on this, for exactly the same reason - I've often thought
that an equivalent of -jar would be useful, but whenever I've had a go
at implementing it myself, the fiddly bits needed have meant that it
ended up not being cost effective to bother...

Paul.

From p.f.moore at gmail.com  Thu Jul 12 12:23:12 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 12 Jul 2007 11:23:12 +0100
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <4695E1D3.8080608@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
Message-ID: <79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>

On 12/07/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > Right, but it's supposed to be cross platform, as mentioned in the
> > patch.  This will work on Windows.
>
> But in the description, you said that you do the same on Windows
> by making a file that is both a zip file and a batch file. So my
> approach is also cross-platform, no?

Getting the details of such a batch file header right on Windows is
not easy, not least because there is no "exec" equivalent on Windows.
The following works, but (a) uses 2 processes, and (b) doesn't
preserve the exit code. The first issue is minor, but the second is a
big problem (and one I don't know how to fix).

Also, on Windows, zip-packaged GUI programs could be useful - these
would be executed using "pythonw -z"

> How do you get the -z option to work on Windows? What extension
> do you use, and how is the zipfile created?

The patch suggests using .pyz and adding a default association to the
installer (much like .py and .pyw have). It also offers a script for
building the zipfiles - either as sample code, or to be included with
Python (it's not clear to me).

It's arguable that .pyz files should use pythonw -z, not python -z, as
file extensions are more often useful for clickable programs in the
GUI. You could have two extensions (.pyz and .pzw, maybe) but I'm not
sure it's worth it.

The point here is that the fiddly part (setting sys.path, locating the
main module, etc) is covered by the -z option, deployment
considerations are easier to handle (and hence the exact defaults
supplied are less crucial) once -z is available.

Paul.

From pje at telecommunity.com  Thu Jul 12 16:58:53 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jul 2007 10:58:53 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <4695E1D3.8080608@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
Message-ID: <20070712145643.CE88B3A40A8@sparrow.telecommunity.com>

At 10:09 AM 7/12/2007 +0200, Martin v. L?wis wrote:
>"" should not be removed from sys.path. It is *not* meant to be
>the current directory, but the directory where the main script
>lives.

Right; it should be replaced with the zipfile path instead.

I would personally rather see this option defined as simply placing a 
directory at the front of sys.path, and perhaps defining a default -m 
value of __main__, unless overrridden.  Being able to use the option 
more than once would be nice, too.  On Windows, you can't set an 
environment variable on the same line as a command, so this would 
give you a one-liner way of setting sys.path and running an application.

I do not see a reason to make this option zipfile-specific in any 
way, though; it's just as useful (and sometimes more so) to be able 
to distribute an application as a directory, since that lets you use 
.pyd, .so, .dll etc. without needing the egg cache system for using those.


>Why that? Why do eggs fail to process $0 correctly, whereas the
>-z option gets it correct? That just sounds like a bug in eggs
>to me, that could be fixed - or, if not, I'd expect that -z
>cannot fix it, either.
>
>My understanding of this note is that
>pkg_resources uses sys.argv[0] to determine the version number
>of the egg; IIUC, -z won't help at all here because sys.argv[0]
>will still be the name of the symlink.

That's correct; it will not help.  A change in the zipped .egg format 
is required, but could be done.  If the option is added (again, 
without being zipfile-specific!) then there is a reason for me to 
make the change.


From andychup at gmail.com  Thu Jul 12 17:00:59 2007
From: andychup at gmail.com (Andy C)
Date: Thu, 12 Jul 2007 08:00:59 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <4695E1D3.8080608@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
Message-ID: <596909b30707120800y251f857ela125fee010ac9d8e@mail.gmail.com>

On 7/12/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> But in the description, you said that you do the same on Windows
> by making a file that is both a zip file and a batch file. So my
> approach is also cross-platform, no?
>
> How do you get the -z option to work on Windows? What extension
> do you use, and how is the zipfile created?

Nick suggested using .pyz, and others seem to like that solution
(possibly using pythonw) and that seems logical enough to me.  If it's
agreed that that's the right solution on Windows, I can put in the
work for that.

> Couldn't that also be achieved by documenting best practice in
> the documentation? Why is the shell script not robust?

I think it's pretty clear that it's not robust, and there have been
even more anecdotal examples on this thread.  Everyone does it
slightly differently -- not for any particular reason, but just
because the right thing isn't trivial.

As I pointed out, the example you came up with (which many others
would come up with too) has a fairly serious problem, in that it will
import things from outside the .zip file.  I could build my .zip file
on my system, test it out, and then deploy it to another machine and
it will break.  Ironically, this happened to *me* while developing the
patch!

> Why that? Why do eggs fail to process $0 correctly, whereas the
> -z option gets it correct? That just sounds like a bug in eggs
> to me, that could be fixed - or, if not, I'd expect that -z
> cannot fix it, either.
>
> My understanding of this note is that
> pkg_resources uses sys.argv[0] to determine the version number
> of the egg; IIUC, -z won't help at all here because sys.argv[0]
> will still be the name of the symlink.

OK, I could be mistaken here, I haven't actually repro'd this bug.

> What are those weird hacks, why are they necessary, and how does the
> -z option overcome the need for these hacks?
>
> That people fail to make it work with /bin/sh doesn't automatically
> mean they succeed with -z. Either they are too unexperienced to
> make the shell header correct (in which case documenting best
> practice would help), or they have deeper problems with that approach,
> in which case it isn't at all obvious that the proposed change
> improves anything.

I don't think this is true at all.  I have provided the sample code to
make one of these files, and so you basically have to run a command
line, rather than write a shell header -- and the shell header is
currently not documented anywhere.  As mentioned, this approach also
prevents you from having to start the shell, and makes it more
portable, since people might use #!/bin/myfavoriteshell or use
#!/bin/sh and not realize they are using system-specific features of
the shell.

> > Another example is that the behavior of the zip in your example
> > depends on what else is in the current directory [1], which isn't
> > desirable.  Nick pointed out this issue and I addressed it in the
> > patch by removing "" from sys.path, since the -c flag adds that.
>
> "" should not be removed from sys.path. It is *not* meant to be
> the current directory, but the directory where the main script
> lives.

Regardless of what "" *should* be interpretreted as, the example you
gave has the problem mentioned (with current versions of Python) --
that "" *is* the current directory and thus things get imported
outside of the zip file when they are not found in the zip file.

Right now "" is replaced with the zip file.  If there's a better
implementation I'm willing to change it.

> > As mentioned, it's also a very tiny amount of code, and I don't see
> > much potential for bad interactions with other things, the way I've
> > written it.
>
> It's baggage that is rarely needed, and the feature can be readily
> implemented in a different way for people who need it.

I also disagree with both statements. : )  I think others have said
basically the exact same thing as I am saying: that it is *commonly*
needed, it's not a lot of baggage in Python since it's so little code,
and it's easy to get wrong.

Andy

From andychup at gmail.com  Thu Jul 12 17:11:05 2007
From: andychup at gmail.com (Andy C)
Date: Thu, 12 Jul 2007 08:11:05 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
Message-ID: <596909b30707120811h2c2133b2q2db73d37be6e7600@mail.gmail.com>

On 7/12/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:09 AM 7/12/2007 +0200, Martin v. L?wis wrote:
> >"" should not be removed from sys.path. It is *not* meant to be
> >the current directory, but the directory where the main script
> >lives.
>
> Right; it should be replaced with the zipfile path instead.

That's indeed what the current implementation does, replacing "" with
the zip file.

> I would personally rather see this option defined as simply placing a
> directory at the front of sys.path, and perhaps defining a default -m
> value of __main__, unless overrridden.  Being able to use the option

Actually, that's a good idea, and it does work with my current
implementation [1], although we'd have to change the name __zipmain__.
 Is __main__ a good idea considering that is used for something
similar but implemented completely differently (the module name)?  I
thought about using __main__, but decided on __zipmain__ since seemed
to be more explicit and reduce potential conflicts.

To be clear to other readers, the convention would be that if a
__main__.py file exists at the root of a directory, then the whole
directory is considered an executable python program.

> more than once would be nice, too.  On Windows, you can't set an
> environment variable on the same line as a command, so this would
> give you a one-liner way of setting sys.path and running an application.
>
> I do not see a reason to make this option zipfile-specific in any
> way, though; it's just as useful (and sometimes more so) to be able
> to distribute an application as a directory, since that lets you use
> .pyd, .so, .dll etc. without needing the egg cache system for using those.

Yes, the dynamic library importing is nice.

thanks,
Andy


1)
andychu testprog$ find
.
./__init__.py
./package1
./package1/__init__.py
./package1/foo.py
./package1/lib.py
./__zipmain__.py

andychu testprog$ ../python -z .
lib module here
argv: ['.']
andychu testprog$

From ncoghlan at gmail.com  Thu Jul 12 17:46:13 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 13 Jul 2007 01:46:13 +1000
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>	<4695BDE6.8030109@v.loewis.de>	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>	<4695E1D3.8080608@v.loewis.de>
	<20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
Message-ID: <46964CC5.3080005@gmail.com>

Phillip J. Eby wrote:
> At 10:09 AM 7/12/2007 +0200, Martin v. L?wis wrote:
>> "" should not be removed from sys.path. It is *not* meant to be
>> the current directory, but the directory where the main script
>> lives.
> 
> Right; it should be replaced with the zipfile path instead.
> 
> I would personally rather see this option defined as simply placing a 
> directory at the front of sys.path, and perhaps defining a default -m 
> value of __main__, unless overrridden.  Being able to use the option 
> more than once would be nice, too.  On Windows, you can't set an 
> environment variable on the same line as a command, so this would 
> give you a one-liner way of setting sys.path and running an application.
> 
> I do not see a reason to make this option zipfile-specific in any 
> way, though; it's just as useful (and sometimes more so) to be able 
> to distribute an application as a directory, since that lets you use 
> .pyd, .so, .dll etc. without needing the egg cache system for using those.

I've thought about this a little further since my last comment on SF, 
and I think it may be a better idea to handle this as a runpy module 
parameter rather than as a parameter for the main interpreter.

For those that aren't aware, the two commands:

   python -m <module>
   python -m runpy <module>

actually have the same effect - both run the specified module. The 
second version is just a little indirect, as it first executes the runpy 
module, which then makes its a second call to run_module(). It was done 
this way so that -m style functionality was readily available for Python 
versions prior to 2.4.

The current version of runpy doesn't accept any options, but it would be 
pretty easy to make the following changes:

1. Accept a -p option that prepends path entries. These path entries 
would be combined into a single list from left to right on the command 
line, then the whole list prepended to sys.path. If at least one -p 
option is given, the default '' entry would be removed from sys.path 
(the current directory could be added back in explicitly via -p '.').

2. Attempt to run the module __main__ if no module is otherwise specified

Startup would be fractionally slower than it would be with the C-level 
option, but the code would be much simpler, and the new feature would be 
readily available on any Python implementation which can execute the 
runpy module.

The relevant shebang line to be prepended to a zip file would then look 
something like:

#!/usr/bin/env python -m runpy -p

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From nnorwitz at gmail.com  Thu Jul 12 19:32:30 2007
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 12 Jul 2007 09:32:30 -0800
Subject: [Python-Dev] Python developers at Google (was Re: Add a -z
	interpreter flag to execute a zip file)
Message-ID: <ee2a432c0707121032m69c78be1l74a1eade9a8b24eb@mail.gmail.com>

On 7/12/07, glyph at divmod.com <glyph at divmod.com> wrote:
>
> ... there is a heavy Google bias in the existing survey sample ...

Not just this survey...

There are many python developers at Google and that is not likely to
change anytime soon.  This means that it's even more important to hear
differing points of view.  We need to hear more from people outside of
Google to ensure we are doing the best possible job.  It would also be
great to have more active committers that don't work at Google.

n

From pje at telecommunity.com  Thu Jul 12 19:58:13 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jul 2007 13:58:13 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip   file
In-Reply-To: <46964CC5.3080005@gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
	<46964CC5.3080005@gmail.com>
Message-ID: <20070712175600.8D73E3A40B0@sparrow.telecommunity.com>

At 01:46 AM 7/13/2007 +1000, Nick Coghlan wrote:
>The current version of runpy doesn't accept any options, but it 
>would be pretty easy to make the following changes:
>
>1. Accept a -p option that prepends path entries. These path entries 
>would be combined into a single list from left to right on the 
>command line, then the whole list prepended to sys.path. If at least 
>one -p option is given, the default '' entry would be removed from 
>sys.path (the current directory could be added back in explicitly via -p '.').
>
>2. Attempt to run the module __main__ if no module is otherwise specified
>
>Startup would be fractionally slower than it would be with the 
>C-level option, but the code would be much simpler, and the new 
>feature would be readily available on any Python implementation 
>which can execute the runpy module.
>
>The relevant shebang line to be prepended to a zip file would then 
>look something like:
>
>#!/usr/bin/env python -m runpy -p

I don't have any particular objection to using runpy for this, but I 
believe that this shebang line won't actually work on certain non-BSD 
OSes, such as most Linux versions, which allow you to have at most 
*one* argument to a #! line, and will combine anything after the 
executable portion into a single argument.  This means that the only 
workable form of this line for cross-platform use is:

#!/usr/bin/python2.6 -z

And of course that won't work if Python is somewhere else.  You can't 
both use env to invoke Python, *and* expect arguments to work.  env 
will receive a single argument of "python -m runpy -p", which it will 
then try to invoke.  On Mac OS and various other BSDs, your example 
will work correctly, but it won't work most anywhere else, as few 
OSes actually support passing individual arguments from a #! line.  See:

    http://www.in-ulm.de/~mascheck/various/shebang/



From pje at telecommunity.com  Thu Jul 12 20:01:04 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jul 2007 14:01:04 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <596909b30707120811h2c2133b2q2db73d37be6e7600@mail.gmail.co
 m>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
	<596909b30707120811h2c2133b2q2db73d37be6e7600@mail.gmail.com>
Message-ID: <20070712175851.562DF3A40B0@sparrow.telecommunity.com>

At 08:11 AM 7/12/2007 -0700, Andy C wrote:
>Is __main__ a good idea considering that is used for something
>similar but implemented completely differently (the module name)?

That would be why it *is* a good idea; it's the One Obvious Way To Do It.  :)

Now we just need an option abbreviation that's less obscure than 
'-z', given that this isn't just for zipfiles.  Either that, or we 
can pretend it stands for "zoom in on this path and run its __main__".  ;-)


From matthieu.brucher at gmail.com  Thu Jul 12 22:00:37 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 12 Jul 2007 22:00:37 +0200
Subject: [Python-Dev] Typo in itertools.dropwhile()
Message-ID: <e76aa17f0707121300l39463364n37289201b7092d6c@mail.gmail.com>

Hi,

There seems to be a typo in the doc of itertools.dropwhile() :

Make an iterator that drops elements from the iterable as long as the
predicate is true; afterwards, returns every element. Note, the iterator
does not produce *any* output until the predicate is true, so it may have a
lengthy start-up time.

It says something and then the opposite, so which one is true ?

Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070712/f70b3f95/attachment.htm 

From skip at pobox.com  Thu Jul 12 22:10:42 2007
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 12 Jul 2007 15:10:42 -0500
Subject: [Python-Dev] Python developers at Google (was Re: Add a -z
 interpreter flag to execute a zip file)
In-Reply-To: <ee2a432c0707121032m69c78be1l74a1eade9a8b24eb@mail.gmail.com>
References: <ee2a432c0707121032m69c78be1l74a1eade9a8b24eb@mail.gmail.com>
Message-ID: <18070.35522.317432.537285@montanaro.dyndns.org>


    Neal> We need to hear more from people outside of Google to ensure we
    Neal> are doing the best possible job.  It would also be great to have
    Neal> more active committers that don't work at Google.

Are you worried that Google might get hit by a bus? <wink>

Skip

From martin at v.loewis.de  Thu Jul 12 22:53:43 2007
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 12 Jul 2007 22:53:43 +0200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <9e804ac0707120137h54861df1mc31528efac2e3392@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>	
	<4695BDE6.8030109@v.loewis.de>	
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>	
	<4695E1D3.8080608@v.loewis.de>
	<9e804ac0707120137h54861df1mc31528efac2e3392@mail.gmail.com>
Message-ID: <469694D7.4050308@v.loewis.de>

> The approach is cross-platform, in that you can use the approach on
> different platforms. The result of the approach, however, is not
> cross-platform. You can't distribute your single zip-as-executable to
> both Windows and bourne-shell-using platforms. The -z argument does
> allow that.

I still don't understand how so. How will this work on Windows?

> For instance, you need to set PYTHONPATH to include the
> zipfile before you can import from it, but you don't want that
> PYTHONPATH to be passed to subprocesses by accident.

That's why I say a best-practice solution should be established.
In this case, if the actual main function is invoked through
-c, the -c script could get a sys.path.append statement as
well.

> The -z argument makes it extremely simple: the user decides which python
> to run, and the program is run directly just like it would if it was
> unpacked and run that way.

Really? I think there a still a number of subtleties, like what
sys.argv[0] will be, and how sys.path will look like. It's definitely
*not* the same as if you unzipped it, and ran the unzipped one.

> I disagree with both statements. The bagage is much less than zipimport
> itself, which has proven to be quite useful. Nevertheless, zipimport
> built into the interpreter was by no means necessary; current users of
> it could have readily implemented it themselves, with no changes to
> Python. (In fact, Google's 'autopar' tool does exactly that to support
> Python 2.2, which lacks zipimport.) This is a very small, logical and
> useful extension to zipimport, and I believe you will find more uses for
> it than you expect (although I do believe you yourself don't have a need
> for it. I just don't think you're a typical Python programmer in this
> case :)

Ok. I'll shut up, just hoping that this won't cause too much trouble
in the long run.

Regards,
Martin

From martin at v.loewis.de  Thu Jul 12 22:57:21 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 12 Jul 2007 22:57:21 +0200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>	
	<4695BDE6.8030109@v.loewis.de>	
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>	
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
Message-ID: <469695B1.5050107@v.loewis.de>

> The patch suggests using .pyz and adding a default association to the
> installer (much like .py and .pyw have).

Ok. It would be good if the patch actually added that extension, rather
than merely suggesting that it should be added.

Regards,
Martin

From martin at v.loewis.de  Thu Jul 12 23:30:50 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 12 Jul 2007 23:30:50 +0200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <46964CC5.3080005@gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>	<4695BDE6.8030109@v.loewis.de>	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>	<4695E1D3.8080608@v.loewis.de>
	<20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
	<46964CC5.3080005@gmail.com>
Message-ID: <46969D8A.3040106@v.loewis.de>

> The relevant shebang line to be prepended to a zip file would then look
> something like:
> 
> #!/usr/bin/env python -m runpy -p

I might be confusing things, but I think some systems only allow a
single argument in the shebang line.

Regards,
Martin

From martin at v.loewis.de  Thu Jul 12 23:44:08 2007
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 12 Jul 2007 23:44:08 +0200
Subject: [Python-Dev] Subversion branch merging
Message-ID: <4696A0A8.4090604@v.loewis.de>

I'm tasked with performing a number of merge operations across
various Python branches. Can somebody please share a command
line that I should use to continue with the merge tracking that
has been used? Is that documented somewhere?

Regards,
Martin

From brett at python.org  Thu Jul 12 23:54:27 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 12 Jul 2007 14:54:27 -0700
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <4696A0A8.4090604@v.loewis.de>
References: <4696A0A8.4090604@v.loewis.de>
Message-ID: <bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>

On 7/12/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I'm tasked with performing a number of merge operations across
> various Python branches. Can somebody please share a command
> line that I should use to continue with the merge tracking that
> has been used? Is that documented somewhere?

You mean using svnmerge?  If so, see the dev FAQ:
http://www.python.org/dev/faq/#how-do-i-merge-branches .  If you are
after something else then I don't know.  =)

I do know, though, that Thomas kept talking about moving us over to
Bazaar (or some distributed VCS) and instead of having a ton of svn
branches we have distributed VCS branch for each feature in Py3K.
That way the VCS's strong merge system would work in our favour for
pulling in from the various Py3K branches and for eventual mainline
merging.

-Brett

From andychup at gmail.com  Fri Jul 13 00:52:19 2007
From: andychup at gmail.com (Andy C)
Date: Thu, 12 Jul 2007 15:52:19 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <469695B1.5050107@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
	<469695B1.5050107@v.loewis.de>
Message-ID: <596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>

On 7/12/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > The patch suggests using .pyz and adding a default association to the
> > installer (much like .py and .pyw have).
>
> Ok. It would be good if the patch actually added that extension, rather
> than merely suggesting that it should be added.

So does everyone agree that there should be a new extension called
.pyz?  And that the definition of this is a .zip file with a
__zipmain__.py module at its root?  If so, I can make the change... I
haven't looked around the codebase yet but it sounds easy enough.

This makes it seem like a bigger change than it is, but I think it's
the right thing to do to support Windows properly.

Other points:

* I think it's true that the shebang line should only have one argument.

* Does anyone else want to change the -z flag to make more sense for
directories (and possibly change __zipmain__.py to __main__.py)?  In
thinking about this again, I am not sure I can come up with a real use
case.  I think it's sufficient to treat it as a documented "trick"
that you can substitute a whole directory for a zip file with the -z
flag.  If there is a concrete suggestion, I'd like to discuss it, but
otherwise it seems like we'll get bogged down in expanding use cases.

* Magically looking at the first argument to see if it's a zip file
seems problematic to me.  I'd rather be explicit with the -z flag.
Likewise, I'd rather be explicit and call it __zipmain__ rather than
__main__.

thanks,
Andy

From skip at pobox.com  Fri Jul 13 01:04:29 2007
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 12 Jul 2007 18:04:29 -0500
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <46969D8A.3040106@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
	<46964CC5.3080005@gmail.com> <46969D8A.3040106@v.loewis.de>
Message-ID: <18070.45949.554232.578076@montanaro.dyndns.org>


    >> #!/usr/bin/env python -m runpy -p

    Martin> I might be confusing things, but I think some systems only allow
    Martin> a single argument in the shebang line.

It's always been my impression that all Unix or Linux systems have that
constraint.  I've never heard of that restriction being relaxed.

Skip


From pje at telecommunity.com  Fri Jul 13 01:22:51 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jul 2007 19:22:51 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.co
 m>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
	<469695B1.5050107@v.loewis.de>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
Message-ID: <20070712232039.C78BD3A40A9@sparrow.telecommunity.com>

At 03:52 PM 7/12/2007 -0700, Andy C wrote:
>On 7/12/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > > The patch suggests using .pyz and adding a default association to the
> > > installer (much like .py and .pyw have).
> >
> > Ok. It would be good if the patch actually added that extension, rather
> > than merely suggesting that it should be added.
>
>So does everyone agree that there should be a new extension called
>.pyz?  And that the definition of this is a .zip file with a
>__zipmain__.py module at its root?  If so, I can make the change... I
>haven't looked around the codebase yet but it sounds easy enough.

Let's use __main__, please.  Fewer names to remember, and __main__ is 
supposed to be the __name__ of the main program.  It Just Makes Sense<TM>.


>* Does anyone else want to change the -z flag to make more sense for
>directories (and possibly change __zipmain__.py to __main__.py)?  In
>thinking about this again, I am not sure I can come up with a real use
>case.

Testing your package before you zip it, would be one.  :)  My 
personal main interest was in being able to add an item to sys.path 
without having to set $PYTHONPATH on Windows.  That's why I'd like it 
to be possible to use -z more than once (or whatever the option ends up as).


>   I think it's sufficient to treat it as a documented "trick"
>that you can substitute a whole directory for a zip file with the -z
>flag.  If there is a concrete suggestion, I'd like to discuss it, but
>otherwise it seems like we'll get bogged down in expanding use cases.

Eh? First you say there aren't any use cases, now you say there'll be 
too many?  I'm confused.  The only competing proposal besides what 
I've suggested was the one to add an option to "runpy", and IMO 
that's dead in the water due to shebang argument limits.


>* Magically looking at the first argument to see if it's a zip file
>seems problematic to me.  I'd rather be explicit with the -z flag.
>Likewise, I'd rather be explicit and call it __zipmain__ rather than
>__main__.

I personally don't see any benefit to making up an extra name, when 
we already have one that describes the functionality 
perfectly.  There is absolutely nothing about -z that needs or should 
care about zipfile-ness, so why add an unnecessary limitation while 
creating yet another __special__ name to remember?


From pje at telecommunity.com  Fri Jul 13 01:30:26 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 12 Jul 2007 19:30:26 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <469694D7.4050308@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<9e804ac0707120137h54861df1mc31528efac2e3392@mail.gmail.com>
	<469694D7.4050308@v.loewis.de>
Message-ID: <20070712232811.A94673A40A9@sparrow.telecommunity.com>

At 10:53 PM 7/12/2007 +0200, Martin v. L??wis wrote:
> > The approach is cross-platform, in that you can use the approach on
> > different platforms. The result of the approach, however, is not
> > cross-platform. You can't distribute your single zip-as-executable to
> > both Windows and bourne-shell-using platforms. The -z argument does
> > allow that.
>
>I still don't understand how so. How will this work on Windows?

Via the .pyz extension on Windows, and a shebang header everywhere 
else... although the path and possibly Python version will have to be 
hardcoded in the shebang line.


> > The -z argument makes it extremely simple: the user decides which python
> > to run, and the program is run directly just like it would if it was
> > unpacked and run that way.
>
>Really? I think there a still a number of subtleties, like what
>sys.argv[0] will be, and how sys.path will look like. It's definitely
>*not* the same as if you unzipped it, and ran the unzipped one.

IMO, sys.argv[0] should equal the -z argument, as should the "script 
directory" entry on sys.path.

Actually, the more I think about this, the more I'm leaning towards 
getting rid of the option and just having the startup code check 
whether sys.argv[0] can be mapped to an importer object, and if so, 
importing __main__ from it.  A special "python script file" importer 
type could be implemented for file objects, so that importing 
__main__ from it will execute the contents of the file in a __main__ module.

This approach would provide uniform argv[0] handling (in that "python 
argv[0]" will always rerun the same program) and allow zipfile 
shebangs to use 'env' to invoke Python, since no command-line option 
is then required.

There is one slight complication: the "python script file" importer 
must adjust sys.path[0] to the directory of the script, instead of 
the script itself.


From mhammond at skippinet.com.au  Fri Jul 13 03:03:38 2007
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 13 Jul 2007 11:03:38 +1000
Subject: [Python-Dev] Registry keys written by x64 installer
Message-ID: <06b801c7c4e9$a5c6c600$090a0a0a@enfoldsystems.local>

After installing the x64 version of Python 2.5.1 via the MSI file on
python.org, I noticed most of the registry keys are "missing".  Further
investigation shows they aren't actually missing, but have simply been
"virtualized", so they actually appear under the Wow6432Node key.

This Wow6432Node key is used by 32bit programs running on a 64bit OS.
Ironically, this means that a 32 bit Python can open HKLM\Software\Python -
the OS virtualizes that request to the Wow3264Node tree.  However, a 64 bit
Python (ie, the very Python that was installed by the MSI) fails to open
that key - no vistualization occurs and as the key specified does not exist,
we fail.  For example:

This is the Python 2.5 installed by the MSI installer:

Python 2.5.1 (r251:54863, Apr 18 2007, 09:02:36) [MSC v.1400 64 bit (AMD64)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import _winreg
>>> _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE,
"Software\\Python\\PythonCore")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 2] The system cannot find the file specified
>>>

But if I use a 32bit version of Python:

Python 2.5.1 (release25-maint, Jun  4 2007, 23:00:11) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import _winreg
>>> _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE,
"Software\\Python\\PythonCore")
<PyHKEY at 004790B0 (00000098)>

It works.

I'm afraid my knowledge of MSI is very limited, so I'm not sure where to
start.  One thing I did notice is that msilib\__init__.py has a variable
'Win64' set, hard-coded to 0 - but I've no idea if it is relevant.
Presumably it is relevant to *something*, otherwise it would not have been
created - but its unclear when and how this should be set to 1, and if this
should concern people trying to use bdist_msi to create x64 extension
packages - but for now, let's just stick with the topic at hand - the
registry keys set by the installer.

Any clues?

Thanks,

Mark


From murman at gmail.com  Fri Jul 13 04:34:50 2007
From: murman at gmail.com (Michael Urman)
Date: Thu, 12 Jul 2007 21:34:50 -0500
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <06b801c7c4e9$a5c6c600$090a0a0a@enfoldsystems.local>
References: <06b801c7c4e9$a5c6c600$090a0a0a@enfoldsystems.local>
Message-ID: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>

On 7/12/07, Mark Hammond <mhammond at skippinet.com.au> wrote:
> I'm afraid my knowledge of MSI is very limited, so I'm not sure where to
> start.  One thing I did notice is that msilib\__init__.py has a variable
> 'Win64' set, hard-coded to 0 - but I've no idea if it is relevant.
> Presumably it is relevant to *something*, otherwise it would not have been
> created - but its unclear when and how this should be set to 1, and if this
> should concern people trying to use bdist_msi to create x64 extension
> packages - but for now, let's just stick with the topic at hand - the
> registry keys set by the installer.

Per the requirements documented at
http://msdn2.microsoft.com/En-US/library/aa372396.aspx, the behavior
you describe is expected for a 32-bit installer. (To install files and
registry to 64-bit locations, the Template Summary must include
Intel64 or x64 depending on which architecture, and the component must
be marked as 64-bit).

I'm not familiar with how msilib is invoked to create the MSI files in
question, but it does look like setting Win64 to 1 at an early enough
time would cause an Intel64 installer to be built, along with entirely
64-bit components. This wouldn't work for x64 machines, and all
components being 64-bit may be incorrect: potentially the 64-bit
installer should have some 32-bit components.

-- 
Michael Urman

From fdrake at acm.org  Fri Jul 13 04:55:15 2007
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 12 Jul 2007 22:55:15 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
Message-ID: <200707122255.15928.fdrake@acm.org>

At 03:52 PM 7/12/2007 -0700, Andy C wrote:
 >So does everyone agree that there should be a new extension called
 >.pyz?  And that the definition of this is a .zip file with a
 >__zipmain__.py module at its root?  If so, I can make the change... I
 >haven't looked around the codebase yet but it sounds easy enough.

I'm not a Windows user, so don't have a good feel for the state of the 
extension mess on that platform these days.  PYZ isn't listed on filext.com, 
but I don't know if that means much.

On Thursday 12 July 2007, Phillip J. Eby wrote:
 > Let's use __main__, please.  Fewer names to remember, and __main__ is
 > supposed to be the __name__ of the main program.  It Just Makes Sense<TM>.

Indeed.  Let's not do something so specific it's a pain to use.

Andy C:
 >* Does anyone else want to change the -z flag to make more sense for
 >directories (and possibly change __zipmain__.py to __main__.py)?  In
 >thinking about this again, I am not sure I can come up with a real use
 >case.

Yes.  A use case for using directories, or for *not* supporting them?  These 
cases should be as similar as possible; like Phillip suggested, we should be 
thinking "sys.path entry" rather than "zip file".

Phillip Eby:
 > Testing your package before you zip it, would be one.  :)  My
 > personal main interest was in being able to add an item to sys.path
 > without having to set $PYTHONPATH on Windows.  That's why I'd like it
 > to be possible to use -z more than once (or whatever the option ends up
 > as).

What happens if multiple entries contain __main__.py entries?  I don't like 
this one so much.  I don't know what Java does if you specify -jar more than 
once; that might suggest something.

 > The only competing proposal besides what
 > I've suggested was the one to add an option to "runpy", and IMO
 > that's dead in the water due to shebang argument limits.

Agreed.

Andy:
 >* Magically looking at the first argument to see if it's a zip file
 >seems problematic to me.  I'd rather be explicit with the -z flag.
 >Likewise, I'd rather be explicit and call it __zipmain__ rather than
 >__main__.

Identifying ZIP files is straightforward; there's nothing weird about this 
one.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From nnorwitz at gmail.com  Fri Jul 13 05:31:32 2007
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 12 Jul 2007 20:31:32 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <200707122255.15928.fdrake@acm.org>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<200707122255.15928.fdrake@acm.org>
Message-ID: <ee2a432c0707122031v1c9ffd70md39af4656d5fb4c3@mail.gmail.com>

On 7/12/07, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
>
> Phillip Eby:
>  > Testing your package before you zip it, would be one.  :)  My
>  > personal main interest was in being able to add an item to sys.path
>  > without having to set $PYTHONPATH on Windows.  That's why I'd like it
>  > to be possible to use -z more than once (or whatever the option ends up
>  > as).
>
> What happens if multiple entries contain __main__.py entries?  I don't like
> this one so much.  I don't know what Java does if you specify -jar more than
> once; that might suggest something.

You can't with:
java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode)

-help says:
     or  java [-options] -jar jarfile [args...]
           (to execute a jar file)

args are passed to the jarfile being run.

$ java -jar xalan2.jar -jar xalan2.jar
Invalid option: -jar
Invalid option: xalan2.jar

n

From dave at cryptohorizon.com  Fri Jul 13 05:41:35 2007
From: dave at cryptohorizon.com (Dave Harrison)
Date: Fri, 13 Jul 2007 13:41:35 +1000
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
Message-ID: <4696F46F.8090803@cryptohorizon.com>

Brett Cannon wrote:
> On 7/12/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I'm tasked with performing a number of merge operations across
>> various Python branches. Can somebody please share a command
>> line that I should use to continue with the merge tracking that
>> has been used? Is that documented somewhere?
> 
> You mean using svnmerge?  If so, see the dev FAQ:
> http://www.python.org/dev/faq/#how-do-i-merge-branches .  If you are
> after something else then I don't know.  =)
> 
> I do know, though, that Thomas kept talking about moving us over to
> Bazaar (or some distributed VCS) and instead of having a ton of svn
> branches we have distributed VCS branch for each feature in Py3K.
> That way the VCS's strong merge system would work in our favour for
> pulling in from the various Py3K branches and for eventual mainline
> merging.
> 
> -Brett

Hi all,

While I'm generally just a silent listener to this list, I thought I'd
share my experiences with distributed SCM - primarily because I think
it's a great step in the right direction.

So far I've used DARCS, Hg, and Git.  And at this point Git is far and
away the winner.

While I can't claim to have spent alot of time with DARCS, my
experience was that it took a fair whack of unintuitive pain to work
out how to extract a patch that I could send upstream to be submitted
to a project.  I believe it also has a reputation for being rather
slow.  I've also noticed that repositories sometimes become "broken"
and need to be re-checked out - but that I'm willing to put down to
some other factor I'm not aware of.

With Hg I went in fast and hard, and nearly got burned before I could
bail out in time :-)  It's very friendly to use, but we run a number
of OpenBSD hosts for our core architecture, and it turns out Hg wraps
calls to patch, and parses the text output from the call (assuming the
version of patch is GnuPatch).  The problem here is that under OpenBSD
the output assumptions get violated, as reflected by the failure of
lots of tests - including repository sanity checks.  That meant Hg
just wasn't going to be an option for us.  I also found that having a
new directory tree of files for each branch was rather onerous.

Having bailed on Hg I found git to be fast, cross platform, and
user-friendly (provided you understand the basic concepts of
distributed SCM, and you're using git 1.5+ ;-) ).  It also has some
really cool features like "rebasing" for letting your branch actively
track the trunk from which you branched it.

I can't speak to how easily any of these cross over to the windows
platform, although none of them seem to be overly windows friendly
(YMMV).  But I presume this would be one of the key problems facing a
distributed versioning system by the python community.

Cheers
Dave

From andychup at gmail.com  Fri Jul 13 06:13:55 2007
From: andychup at gmail.com (Andy C)
Date: Thu, 12 Jul 2007 21:13:55 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
	<469695B1.5050107@v.loewis.de>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
Message-ID: <596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.com>

On 7/12/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 03:52 PM 7/12/2007 -0700, Andy C wrote:
> >On 7/12/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > > > The patch suggests using .pyz and adding a default association to the
> > > > installer (much like .py and .pyw have).
> > >
> > > Ok. It would be good if the patch actually added that extension, rather
> > > than merely suggesting that it should be added.
> >
> >So does everyone agree that there should be a new extension called
> >.pyz?  And that the definition of this is a .zip file with a
> >__zipmain__.py module at its root?  If so, I can make the change... I
> >haven't looked around the codebase yet but it sounds easy enough.
>
> Let's use __main__, please.  Fewer names to remember, and __main__ is
> supposed to be the __name__ of the main program.  It Just Makes Sense<TM>.

I can definitely see why it "just makes sense", and my first thought
was indeed to name it __main__.  But then you lose the ability to make
a distinction:  What does "if __name__ == '__main__" mean in
__main__.py?  : )  If someone tries does import __main__ from another
module in the program, won't that result in an infinite loop?

There aren't any restrictions on what can be in __main__ (it's just
another module), and while I think it would be a bad practice to
import __main__, I could see people being tripped up by this in
practice.  People might start storing silly things like the program
version there, for convenience.

At Google some people do "import sitecustomize" and get values that
were computed earlier by the sitecustomize.  I could see the same kind
of thing happen with __main__.py.

> >* Does anyone else want to change the -z flag to make more sense for
> >directories (and possibly change __zipmain__.py to __main__.py)?  In
> >thinking about this again, I am not sure I can come up with a real use
> >case.
>
> Testing your package before you zip it, would be one.  :)  My
> personal main interest was in being able to add an item to sys.path
> without having to set $PYTHONPATH on Windows.  That's why I'd like it
> to be possible to use -z more than once (or whatever the option ends up as).

Where would you do that?  Just typing it literally on the command
line?  Just curious, I have never felt a need to do that.  I use
Python on Windows frequently.

> >   I think it's sufficient to treat it as a documented "trick"
> >that you can substitute a whole directory for a zip file with the -z
> >flag.  If there is a concrete suggestion, I'd like to discuss it, but
> >otherwise it seems like we'll get bogged down in expanding use cases.
>
> Eh? First you say there aren't any use cases, now you say there'll be
> too many?  I'm confused.  The only competing proposal besides what
> I've suggested was the one to add an option to "runpy", and IMO
> that's dead in the water due to shebang argument limits.

As implemented the patch is fairly simple, and shouldn't have any
unintended consequences.  I'm not necessarily opposed to making it
more general and thinking about sys.path vs. a zip file specifically.
But I don't have a clear enough picture from all the comments of what
exactly to implement.

-z is not the same as "prepend an item to sys.path", because we
replace "" with the -z argument.  And we also munge sys.argv[0] (which
is what you said should happen).

So it's not clear to me at all what multiple -z's should do, exactly.
Can you write out the pseudo code?  Or modify my patch.

I think it would be fine to have both a -z and -p flag, if the
functionality is needed.  -z accepts a zip file or a directory and
does the right thing to run it as an executable.  -p could accept
multiple arguments and literally prepends them to sys.path.  These
seem like different things to me.

I'll look at adding the file association for .pyz (is there an expert
on that for questions?), and in that time hopefully the list can
decide on the rest of the issues.  Or we can just make Guido decide,
which is fine by me. : )

Andy

From mhammond at skippinet.com.au  Fri Jul 13 06:16:05 2007
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 13 Jul 2007 14:16:05 +1000
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>
Message-ID: <06cb01c7c504$88b62d10$090a0a0a@enfoldsystems.local>

> Per the requirements documented at
> http://msdn2.microsoft.com/En-US/library/aa372396.aspx, the behavior
> you describe is expected for a 32-bit installer.

Agreed - but unless I'm missing something, this release is not expected to
be a 32bit installer.

> (To install files and
> registry to 64-bit locations, the Template Summary must include
> Intel64 or x64 depending on which architecture, and the component must
> be marked as 64-bit).
>
> I'm not familiar with how msilib is invoked to create the MSI files in
> question, but it does look like setting Win64 to 1 at an early enough
> time would cause an Intel64 installer to be built, along with entirely
> 64-bit components. This wouldn't work for x64 machines,

Why wouldn't it work for x64 machines?  Is it simply because msilib only
handles Intel64 when that flag is set?

> and all
> components being 64-bit may be incorrect: potentially the 64-bit
> installer should have some 32-bit components.

What 32bit components should a 64bit build of Python include?  Perhaps you
mean *could* - but IIUC, there is no intention to release 32bit and 64bit
versions of Python in a single package (and further, IIUC, no intent on
supporting a 32bit and 64bit installation on the same machine, regardless of
packaging)

I'm afraid its not clear to me if you are agreeing with me (ie, that the
registry keys are incorrect), or disagreeing with me (the keys are what you
would expect a correct x64 install to create)?  I think you are agreeing,
but sounding a caution that it might not be trivial to fix, but I would like
to be sure...

Cheers,

Mark


From andychup at gmail.com  Fri Jul 13 06:26:19 2007
From: andychup at gmail.com (Andy C)
Date: Thu, 12 Jul 2007 21:26:19 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
	<469695B1.5050107@v.loewis.de>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.com>
Message-ID: <596909b30707122126r507a502oca85b7a8b7257f2b@mail.gmail.com>

Another issue I see is that -m and -c have command line parsing
semantics, and -z follows those now.

python -z foo.zip -z bar

As implemented, this would pass sys.argv[0:3] == ['foo.zip', '-z', 'bar']

If you allow multiple -z flags to be meaningful, this gets confusing.
The foo.zip program could have a legitimate -z flag.

If you overload -z to mean "prepend things to sys.path", then you
might also want to do python -z /dir1 -z /foo.zip -c 'import foo;
print foo'.  Should this execute dir1/__main__.py, foo.zip/__main__.py
or print foo?

I could be missing what you intend.  But I think the patch as
implemented doesn't have any of these potentially unconsidered cases
and unintended consequences.

Andy

From python at rcn.com  Fri Jul 13 06:50:35 2007
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 12 Jul 2007 21:50:35 -0700
Subject: [Python-Dev] Typo in itertools.dropwhile()
References: <e76aa17f0707121300l39463364n37289201b7092d6c@mail.gmail.com>
Message-ID: <011401c7c509$64363480$7815800a@RaymondLaptop1>


[Matthieu on itertools.dropwhile() docs]
> Make an iterator that drops elements from the iterable as long as the predicate is true; afterwards, returns every element. Note, 
> the iterator does not produce any output until the predicate is true, so it may have a lengthy start-up time.
>
> It says something and then the opposite, so which one is true ?


It is correct as written.  Given a sequence where predicate is true 1000 times and then alternately false and true, it returns the 
part that is alternately false and true.  So, it did DROP (omit, not return, skip-over, etc) the first 1000 true items and it did 
return EVERY element from the first false to the end.  It did not produce any output for the first 1000 inputs so it took a while to 
get to the first output (the first false).  Hope that clears it up for you.


Raymond

From murman at gmail.com  Fri Jul 13 06:58:46 2007
From: murman at gmail.com (Michael Urman)
Date: Thu, 12 Jul 2007 23:58:46 -0500
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <06cb01c7c504$88b62d10$090a0a0a@enfoldsystems.local>
References: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>
	<06cb01c7c504$88b62d10$090a0a0a@enfoldsystems.local>
Message-ID: <dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>

On 7/12/07, Mark Hammond <mhammond at skippinet.com.au> wrote:
> Why wouldn't it work for x64 machines?  Is it simply because msilib only
> handles Intel64 when that flag is set?

Right - it sets the template summary to include Intel64, not x64.
Furthermore only one architecture may be set in the template summary,
so an installer may be only one of i386, x64, and Intel64 (although
the latter are assumed to also be able to run i386 binaries).

> What 32bit components should a 64bit build of Python include?  Perhaps you
> mean *could* - but IIUC, there is no intention to release 32bit and 64bit
> versions of Python in a single package (and further, IIUC, no intent on
> supporting a 32bit and 64bit installation on the same machine, regardless of
> packaging)

Agreed. I was just making clear that I'm not familiar with what the
MSI includes, and whether any of the components in a 64-bit install
should be 32-bit or not. With the msilib code as is, it appears to be
all or nothing, or rely on tweaking a global between calls to
start_component.

> I'm afraid its not clear to me if you are agreeing with me (ie, that the
> registry keys are incorrect), or disagreeing with me (the keys are what you
> would expect a correct x64 install to create)?  I think you are agreeing,
> but sounding a caution that it might not be trivial to fix, but I would like
> to be sure...

The former, with hints of caution: it appears the unused 64-bit code
paths of msilib were created to best serve under incorrect
assumptions. With what the code would create (with or without Win64
set), it will not generate the 64-bit registry keys that the 64-bit
program will access. With Win64 set it will not even install except on
an Itanium system. If you just want to get to the keys it currently
sets, there should be an override parameter that causes the registry
API to read the 32-bit keys even in a 64-bit process, but I'm not
familiar with using _winreg.

If there's interest and I can get pointers to where the MSI files are
built, I can look into patching it. I don't have a convenient 64-bit
Windows machine around to test any changes, though.

-- 
Michael Urman

From matthieu.brucher at gmail.com  Fri Jul 13 07:21:48 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Fri, 13 Jul 2007 07:21:48 +0200
Subject: [Python-Dev] Typo in itertools.dropwhile()
In-Reply-To: <011401c7c509$64363480$7815800a@RaymondLaptop1>
References: <e76aa17f0707121300l39463364n37289201b7092d6c@mail.gmail.com>
	<011401c7c509$64363480$7815800a@RaymondLaptop1>
Message-ID: <e76aa17f0707122221yc2feadcx14a37c4a3b113c75@mail.gmail.com>

2007/7/13, Raymond Hettinger <python at rcn.com>:
>
>
> [Matthieu on itertools.dropwhile() docs]
> > Make an iterator that drops elements from the iterable as long as the
> predicate is true; afterwards, returns every element. Note,
> > the iterator does not produce any output until the predicate is true, so
> it may have a lengthy start-up time.
> >
> > It says something and then the opposite, so which one is true ?
>
> It is correct as written.  Given a sequence where predicate is true 1000
> times and then alternately false and true, it returns the
> part that is alternately false and true.  So, it did DROP (omit, not
> return, skip-over, etc) the first 1000 true items and it did
> return EVERY element from the first false to the end.  It did not produce
> any output for the first 1000 inputs so it took a while to
> get to the first output (the first false).  Hope that clears it up for
> you.


Hi,

Thanks for the answer.
I agree with you, but this explains the first sentence. The second says that
nothing is output until the predicate is true. It should say" while the
predicate is true" or "until the predicate is false". But I could be
misunderstand 'until' as well (English is not my mother tongue, but
still...)


Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070713/910e9379/attachment.htm 

From stephen at xemacs.org  Fri Jul 13 08:01:58 2007
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jul 2007 15:01:58 +0900
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <4696F46F.8090803@cryptohorizon.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<4696F46F.8090803@cryptohorizon.com>
Message-ID: <87ps2wrgdl.fsf@uwakimon.sk.tsukuba.ac.jp>

Dave Harrison writes:

 > While I can't claim to have spent alot of time with DARCS, my
 > experience was that it took a fair whack of unintuitive pain to work
 > out how to extract a patch that I could send upstream to be submitted
 > to a project.

This doesn't seem to be a common issue with Darcs, but obviously your
mileage varies.

 > I believe it also has a reputation for being rather slow.  I've
 > also noticed that repositories sometimes become "broken" and need
 > to be re-checked out - but that I'm willing to put down to some
 > other factor I'm not aware of.

Both of these are acknowledged by the core Darcs developers.  Recently
several users posted their regrets to the Darcs mailing lists, and the
developers only said something like "we're working on it, so please
come back and check."  IMO Darcs is a non-starter for a large project
at this point.

 > It also has some really cool features like "rebasing" for letting
 > your branch actively track the trunk from which you branched it.

Unfortunately, rebasing doesn't seem to be stable yet.  Sometimes it
works for me, sometimes not.  I don't know whether its because I don't
know what I'm doing, bugs in git, or changes in the calling syntax.

(NB, "git rebase" is basically just what the Arch people call "tla
update", and darcs's claim to fame is that you don't need to
distinguish between a rebase and a simple pull, darcs calculates it
for you.)


From stephen at xemacs.org  Fri Jul 13 08:07:12 2007
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jul 2007 15:07:12 +0900
Subject: [Python-Dev] Typo in itertools.dropwhile()
In-Reply-To: <011401c7c509$64363480$7815800a@RaymondLaptop1>
References: <e76aa17f0707121300l39463364n37289201b7092d6c@mail.gmail.com>
	<011401c7c509$64363480$7815800a@RaymondLaptop1>
Message-ID: <87odigrg4v.fsf@uwakimon.sk.tsukuba.ac.jp>

Raymond Hettinger writes:

 > [Matthieu on itertools.dropwhile() docs]

 > > Note, the iterator does not produce any output until the
 > > predicate is true

 > it did return EVERY element from the first false

Shouldn't the "until" in the doc be "while"?  Alternatively, "true"
could be changed to "false".


From tjreedy at udel.edu  Fri Jul 13 08:25:55 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 13 Jul 2007 02:25:55 -0400
Subject: [Python-Dev] Typo in itertools.dropwhile()
References: <e76aa17f0707121300l39463364n37289201b7092d6c@mail.gmail.com><011401c7c509$64363480$7815800a@RaymondLaptop1>
	<87odigrg4v.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <f775tq$uoh$1@sea.gmane.org>


"Stephen J. Turnbull" <stephen at xemacs.org> wrote in message 
news:87odigrg4v.fsf at uwakimon.sk.tsukuba.ac.jp...
| Raymond Hettinger writes:
|
| > [Matthieu on itertools.dropwhile() docs]
|
| > > Note, the iterator does not produce any output until the
| > > predicate is true
|
| > it did return EVERY element from the first false
|
| Shouldn't the "until" in the doc be "while"?  Alternatively, "true"
| could be changed to "false".

As I understand the first sentence, yes. 




From ajm at flonidan.dk  Fri Jul 13 08:40:23 2007
From: ajm at flonidan.dk (Anders J. Munch)
Date: Fri, 13 Jul 2007 08:40:23 +0200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
Message-ID: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>

Andy C wrote:
> So does everyone agree that there should be a new extension called
> .pyz?  

How about .pyzip instead?  To make it more obvious, and not mistakable for .py.z.

- Anders

From dave at cryptohorizon.com  Fri Jul 13 09:01:04 2007
From: dave at cryptohorizon.com (Dave Harrison)
Date: Fri, 13 Jul 2007 17:01:04 +1000
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <87ps2wrgdl.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4696A0A8.4090604@v.loewis.de>	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>	<4696F46F.8090803@cryptohorizon.com>
	<87ps2wrgdl.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <46972330.7080406@cryptohorizon.com>

>> It also has some really cool features like "rebasing" for letting
>> your branch actively track the trunk from which you branched it.
>
> Unfortunately, rebasing doesn't seem to be stable yet.  Sometimes it
> works for me, sometimes not.  I don't know whether its because I
> don't know what I'm doing, bugs in git, or changes in the calling
> syntax.

Not to diverge py-dev too far into the depths of DRCS usage, but are
you doing anything particularly complex ?  While I wouldn't say I do
it regularly, I certainly consider it part and parcel of general git
usage, and I've always found it works well for me.  Rebasing is one of
the features that really convinced me git was a cut above the rest,
obviously along with the ease of merging.

For those that are interested the ultra brief explanation for git
branching is that it stores all your branches in the one directory
structure.  You "git checkout" to switch between branches, which
causes all the managed files in your directory to be changed to
reflect the state branch you are changing to.


From martin at v.loewis.de  Fri Jul 13 09:15:50 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jul 2007 09:15:50 +0200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <ee2a432c0707122031v1c9ffd70md39af4656d5fb4c3@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>	<200707122255.15928.fdrake@acm.org>
	<ee2a432c0707122031v1c9ffd70md39af4656d5fb4c3@mail.gmail.com>
Message-ID: <469726A6.3010809@v.loewis.de>

>> What happens if multiple entries contain __main__.py entries?  I don't like
>> this one so much.  I don't know what Java does if you specify -jar more than
>> once; that might suggest something.
> 
> You can't with:
> java version "1.5.0_11"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode)
> 
> -help says:
>      or  java [-options] -jar jarfile [args...]
>            (to execute a jar file)
> 
> args are passed to the jarfile being run.

Sure. However, you *can* specify multiple jar files on the command
line, in the class path.

java -cp xerces.jar -jar xalan2.jar

This runs xalan2.jar, but adds xerces.jar to the class path. It
has all the advantages of a command line option compared to
setting CLASSPATH: it won't be inherited to subprocesses, and
you can use it on Windows, too, whereas you cannot set environment
variables in the command line on Windows.

So while -z strictly gives the equivalent -jar, it's actually
-cp that is used much more often in Java (I think), and that
doesn't have an equivalent in Python still. My typical usage
of java goes like this

java -cp <endless list of jar files> the.main.class

The equivalent Python line would be

python -p <path> -m main_module

Regards,
Martin

From martin at v.loewis.de  Fri Jul 13 09:19:52 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jul 2007 09:19:52 +0200
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>
References: <06b801c7c4e9$a5c6c600$090a0a0a@enfoldsystems.local>
	<dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>
Message-ID: <46972798.5000909@v.loewis.de>


> I'm not familiar with how msilib is invoked to create the MSI files in
> question, but it does look like setting Win64 to 1 at an early enough
> time would cause an Intel64 installer to be built, along with entirely
> 64-bit components. This wouldn't work for x64 machines, and all
> components being 64-bit may be incorrect: potentially the 64-bit
> installer should have some 32-bit components.

There are several places where "64-bitness" need to be considered:
you need to set the architecture of the entire MSI file, and the
installer sets it to "x64" ("Intel64" means Itanium).

In addition, you can set the Win64 bit on components, and
msilib sets it on all components, AFAIK.

Regards,
Martin


From martin at v.loewis.de  Fri Jul 13 09:22:56 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jul 2007 09:22:56 +0200
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <06b801c7c4e9$a5c6c600$090a0a0a@enfoldsystems.local>
References: <06b801c7c4e9$a5c6c600$090a0a0a@enfoldsystems.local>
Message-ID: <46972850.4060508@v.loewis.de>

> I'm afraid my knowledge of MSI is very limited, so I'm not sure where to
> start.  One thing I did notice is that msilib\__init__.py has a variable
> 'Win64' set, hard-coded to 0 - but I've no idea if it is relevant.
> Presumably it is relevant to *something*, otherwise it would not have been
> created - but its unclear when and how this should be set to 1, and if this
> should concern people trying to use bdist_msi to create x64 extension
> packages - but for now, let's just stick with the topic at hand - the
> registry keys set by the installer.
> 
> Any clues?

Please take a look at msilib.set_arch_from_file. This takes an
executable file, determines the processor architecture, and then
sets both MSI type (the PID_TEMPLATE SummaryInformation field),
and the Win64 variable, which should cause all components to
become Win64 components (i.e. flag 256 being set).

Regards,
Martin

From mhammond at skippinet.com.au  Fri Jul 13 09:23:34 2007
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Fri, 13 Jul 2007 17:23:34 +1000
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>
Message-ID: <06e401c7c51e$b8da8d50$090a0a0a@enfoldsystems.local>

On Friday, 13 July 2007, Michael Urman wrote:

> Furthermore only one architecture may be set in the template summary,
> so an installer may be only one of i386, x64, and Intel64 (although
> the latter are assumed to also be able to run i386 binaries).

I suspect I'm still missing something here.  The title of the page you
referenced before is "Using 64-Bit Windows Installer Packages" - I suspect
that is different than a 32-Bit installer package installing a 64bit
program!

> Agreed. I was just making clear that I'm not familiar with what the
> MSI includes, and whether any of the components in a 64-bit install
> should be 32-bit or not. With the msilib code as is, it appears to be
> all or nothing, or rely on tweaking a global between calls to
> start_component.

Yes - that is a bit of a shame, as having 32bit components would allow more
flexibility (eg, allow a 64bit install of Python to work with an IIS
configured for 32bit extensions), but that's something we can deal with
later if necessary.

> If you just want to get to the keys it currently
> sets, there should be an override parameter that causes the registry
> API to read the 32-bit keys even in a 64-bit process, but I'm not
> familiar with using _winreg.

using _winreg is (almost) like using the API directly.
RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the
real keys - I'm not aware of how 64bit apps would enable that reflection,
but it probably doesn't really matter for our purposes.  In case anyone is
interested, I just made a patch to _winreg.c adding these 2 functions
(http://python.org/sf/1753245) in case anyone would like to review it.

> If there's interest and I can get pointers to where the MSI files are
> built, I can look into patching it. I don't have a convenient 64-bit
> Windows machine around to test any changes, though.

I think Tools\msi is what you are looking for, but hopefully Martin will
chime in.  I'm more than happy to help test.

Cheers,

Mark


From martin at v.loewis.de  Fri Jul 13 09:36:29 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jul 2007 09:36:29 +0200
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>
References: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>	<06cb01c7c504$88b62d10$090a0a0a@enfoldsystems.local>
	<dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>
Message-ID: <46972B7D.9040901@v.loewis.de>

Michael Urman schrieb:
> On 7/12/07, Mark Hammond <mhammond at skippinet.com.au> wrote:
>> Why wouldn't it work for x64 machines?  Is it simply because msilib only
>> handles Intel64 when that flag is set?
> 
> Right - it sets the template summary to include Intel64, not x64.

You might be looking at the wrong version. In Python 2.5, it also
sets it to x64, if the PE machine type is 0x8664.

> Furthermore only one architecture may be set in the template summary,
> so an installer may be only one of i386, x64, and Intel64 (although
> the latter are assumed to also be able to run i386 binaries).

Right. That's why I provide three installers.

> Agreed. I was just making clear that I'm not familiar with what the
> MSI includes, and whether any of the components in a 64-bit install
> should be 32-bit or not. With the msilib code as is, it appears to be
> all or nothing, or rely on tweaking a global between calls to
> start_component.

That's correct. I'm also uncertain what precisely the Win64 flag
on a component means, according to

http://msdn2.microsoft.com/EN-US/library/aa368007.aspx

msidbComponentAttributes64bit means

# Set this bit to mark this as a 64-bit component. This attribute
# facilitates the installation of packages that include both 32-bit and
# 64-bit components. If this bit is not set, the component is registered
# as a 32-bit component.
#
# If this is a 64-bit component replacing a 32-bit component, set this
# bit and assign a new GUID in the ComponentId column.

When I started to work on this, I found that not setting the Win64
bit at all "does not work", although I forgot the details what precisely
failed.

I found some articles in the net that suggest that this flag turns
off redirection, e.g.

http://blogs.msdn.com/heaths/archive/2006/04/14/avoid-overwriting-files-in-administrative-installations.aspx

As we don't want any redirection, setting the flag on all components
should be correct.


> The former, with hints of caution: it appears the unused 64-bit code
> paths of msilib were created to best serve under incorrect
> assumptions. With what the code would create (with or without Win64
> set), it will not generate the 64-bit registry keys that the 64-bit
> program will access. 

Why do you say that? What registry keys do you think it creates,
and what registry keys do you think it should create instead?

There are no "64-bit registry keys" on Windows; Win64 only
has "normal registry keys" and "32-bit (i.e. redirected)
registry keys".

> With Win64 set it will not even install except on
> an Itanium system.

I always test whether the AMD 64 binary installs correctly before
releasing it.

> If you just want to get to the keys it currently
> sets, there should be an override parameter that causes the registry
> API to read the 32-bit keys even in a 64-bit process, but I'm not
> familiar with using _winreg.
> 
> If there's interest and I can get pointers to where the MSI files are
> built, I can look into patching it. I don't have a convenient 64-bit
> Windows machine around to test any changes, though.

You don't need to provide patches - just tell me what's wrong with
the MSI file. I.e. look at it in orca, correct it so that it works
correctly, then report what changes you made.

Regards,
Martin


From martin at v.loewis.de  Fri Jul 13 09:49:12 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jul 2007 09:49:12 +0200
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <06e401c7c51e$b8da8d50$090a0a0a@enfoldsystems.local>
References: <06e401c7c51e$b8da8d50$090a0a0a@enfoldsystems.local>
Message-ID: <46972E78.8080506@v.loewis.de>

> I suspect I'm still missing something here.  The title of the page you
> referenced before is "Using 64-Bit Windows Installer Packages" - I suspect
> that is different than a 32-Bit installer package installing a 64bit
> program!

Right. You cannot easily have a 32-bit installer install 64-bit
programs. That will normally not work, as Windows will silently
redirect all registry keys to the Wow6432Node, so it won't
"see" the registry keys that the Win64 program sees.

The only way to "see" the same keys as a 64-bit process would
do is to specify KEY_WOW64_64KEY when opening the key.

>> Agreed. I was just making clear that I'm not familiar with what the
>> MSI includes, and whether any of the components in a 64-bit install
>> should be 32-bit or not. With the msilib code as is, it appears to be
>> all or nothing, or rely on tweaking a global between calls to
>> start_component.
> 
> Yes - that is a bit of a shame, as having 32bit components would allow more
> flexibility (eg, allow a 64bit install of Python to work with an IIS
> configured for 32bit extensions), but that's something we can deal with
> later if necessary.

Can you elaborate? It's incorrect for a Win64 installer to make the
executable components Win32. A 64 bit pythonxy.dll cannot work in
a 32-bit IIS - it's a different instruction set. That's not something
that you can fix by just installing things differently.

> using _winreg is (almost) like using the API directly.
> RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the
> real keys - I'm not aware of how 64bit apps would enable that reflection,
> but it probably doesn't really matter for our purposes.

They can specify KEY_WOW64_32KEY.

Regards,
Martin

From martin at v.loewis.de  Fri Jul 13 09:50:28 2007
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 13 Jul 2007 09:50:28 +0200
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
Message-ID: <46972EC4.9060904@v.loewis.de>

> You mean using svnmerge?  If so, see the dev FAQ:
> http://www.python.org/dev/faq/#how-do-i-merge-branches .  If you are
> after something else then I don't know.  =)

I think that's what I'm looking for.

Thanks,
Martin

From p.f.moore at gmail.com  Fri Jul 13 10:51:02 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 13 Jul 2007 09:51:02 +0100
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <469726A6.3010809@v.loewis.de>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<200707122255.15928.fdrake@acm.org>
	<ee2a432c0707122031v1c9ffd70md39af4656d5fb4c3@mail.gmail.com>
	<469726A6.3010809@v.loewis.de>
Message-ID: <79990c6b0707130151p19d58c5fpa090cdcff487a6a6@mail.gmail.com>

On 13/07/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> So while -z strictly gives the equivalent -jar, it's actually
> -cp that is used much more often in Java (I think), and that
> doesn't have an equivalent in Python still. My typical usage
> of java goes like this
>
> java -cp <endless list of jar files> the.main.class
>
> The equivalent Python line would be
>
> python -p <path> -m main_module

Fair point. Doesn't it argue that there are valid uses for both -p and
-z (in Python terms)? I'm not expert in Java usage, but on Windows,
.jar files are associated with javaw -jar "%1" %*, which would
reinforce the suggestion that Python have a .pyz extension associated
with pythonw -z "%1" %*. Note the -w (GUI) form of both of these...

Paul.

From stephen at xemacs.org  Fri Jul 13 12:37:54 2007
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Jul 2007 19:37:54 +0900
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <46972330.7080406@cryptohorizon.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<4696F46F.8090803@cryptohorizon.com>
	<87ps2wrgdl.fsf@uwakimon.sk.tsukuba.ac.jp>
	<46972330.7080406@cryptohorizon.com>
Message-ID: <87k5t4r3lp.fsf@uwakimon.sk.tsukuba.ac.jp>

Dave Harrison writes:

 > > Unfortunately, rebasing doesn't seem to be stable yet.
 > 
 > Not to diverge py-dev too far into the depths of DRCS usage, but are
 > you doing anything particularly complex ?

As of git 1.5.0.something, "git rebase --onto NEWBASE UPSTREAM" just
ignored the --onto flag AFAICT.  As I say, I may have been abusing it
to do something inappropriate.  Basically I wanted to take the tip of
BRANCH (which was experimental, but I'd accidentally done a bunch of
generic typo fixing) and graft it onto the mainline.

From fdrake at acm.org  Fri Jul 13 13:16:15 2007
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Jul 2007 07:16:15 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <79990c6b0707130151p19d58c5fpa090cdcff487a6a6@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<469726A6.3010809@v.loewis.de>
	<79990c6b0707130151p19d58c5fpa090cdcff487a6a6@mail.gmail.com>
Message-ID: <200707130716.15444.fdrake@acm.org>

On Friday 13 July 2007, Paul Moore wrote:
 > Fair point. Doesn't it argue that there are valid uses for both -p and
 > -z (in Python terms)? I'm not expert in Java usage, but on Windows,

Indeed it does.  I'd be happy for there to be a -p that allows both Windows 
and Unix users to prepend to sys.path.  It should also be separate from 
the -z (or whatever that gets called).


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From fdrake at acm.org  Fri Jul 13 13:17:18 2007
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 13 Jul 2007 07:17:18 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>
References: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>
Message-ID: <200707130717.18224.fdrake@acm.org>

On Friday 13 July 2007, Anders J. Munch wrote:
 > How about .pyzip instead?  To make it more obvious, and not mistakable for
 > .py.z.

I guess it would be pinheaded to call it .zippy.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From shiblon at gmail.com  Fri Jul 13 13:29:41 2007
From: shiblon at gmail.com (Chris Monson)
Date: Fri, 13 Jul 2007 07:29:41 -0400
Subject: [Python-Dev] Typo in itertools.dropwhile()
In-Reply-To: <011401c7c509$64363480$7815800a@RaymondLaptop1>
References: <e76aa17f0707121300l39463364n37289201b7092d6c@mail.gmail.com>
	<011401c7c509$64363480$7815800a@RaymondLaptop1>
Message-ID: <da3f900e0707130429j191592f2k7327666048cb2e44@mail.gmail.com>

Actually, I think it *is* a typo:  the last part should read that no
output is produced until the predicate becomes *false*.

- C


On 7/13/07, Raymond Hettinger <python at rcn.com> wrote:
>
> [Matthieu on itertools.dropwhile() docs]
> > Make an iterator that drops elements from the iterable as long as the
> predicate is true; afterwards, returns every element. Note,
> > the iterator does not produce any output until the predicate is true, so
> it may have a lengthy start-up time.
> >
> > It says something and then the opposite, so which one is true ?
>
>
> It is correct as written.  Given a sequence where predicate is true 1000
> times and then alternately false and true, it returns the
> part that is alternately false and true.  So, it did DROP (omit, not return,
> skip-over, etc) the first 1000 true items and it did
> return EVERY element from the first false to the end.  It did not produce
> any output for the first 1000 inputs so it took a while to
> get to the first output (the first false).  Hope that clears it up for you.
>
>
> Raymond
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/shiblon%40gmail.com
>

From shiblon at gmail.com  Fri Jul 13 13:40:51 2007
From: shiblon at gmail.com (Chris Monson)
Date: Fri, 13 Jul 2007 07:40:51 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <ee2a432c0707122031v1c9ffd70md39af4656d5fb4c3@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<200707122255.15928.fdrake@acm.org>
	<ee2a432c0707122031v1c9ffd70md39af4656d5fb4c3@mail.gmail.com>
Message-ID: <da3f900e0707130440g53fd3562q25c937e0a3114f79@mail.gmail.com>

(Sorry about top-posting: I'm using my blackberry while waiting for
the bus and my gmail client doesn't do quoting :-( )

Certainly java won't let you specify -jar more than once, because that
would be telling it to *run* two files.  It *will*, however, let you
specify more than one jar in the classpath.  This is done all the
time, making the contents of those jars available for importing.

These aren't typically combined, since the whole point of running a
jar file is to have a single distributed package, but IIRC it is not
prohibited.

- C



On 7/12/07, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On 7/12/07, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> >
> > Phillip Eby:
> >  > Testing your package before you zip it, would be one.  :)  My
> >  > personal main interest was in being able to add an item to sys.path
> >  > without having to set $PYTHONPATH on Windows.  That's why I'd like it
> >  > to be possible to use -z more than once (or whatever the option ends up
> >  > as).
> >
> > What happens if multiple entries contain __main__.py entries?  I don't
> like
> > this one so much.  I don't know what Java does if you specify -jar more
> than
> > once; that might suggest something.
>
> You can't with:
> java version "1.5.0_11"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode)
>
> -help says:
>      or  java [-options] -jar jarfile [args...]
>            (to execute a jar file)
>
> args are passed to the jarfile being run.
>
> $ java -jar xalan2.jar -jar xalan2.jar
> Invalid option: -jar
> Invalid option: xalan2.jar
>
> n
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/shiblon%40gmail.com
>

From python at rcn.com  Fri Jul 13 12:53:02 2007
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 13 Jul 2007 03:53:02 -0700
Subject: [Python-Dev] Typo in itertools.dropwhile()
References: <e76aa17f0707121300l39463364n37289201b7092d6c@mail.gmail.com><011401c7c509$64363480$7815800a@RaymondLaptop1>
	<87odigrg4v.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <000001c7c546$3faec770$2100000a@RaymondLaptop1>

[Stephen J. Turnbull]
> Shouldn't the "until" in the doc be "while"?  Alternatively, "true"
> could be changed to "false".

Yes.  I'll make the change.


Raymond

From steve at holdenweb.com  Fri Jul 13 14:19:54 2007
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 13 Jul 2007 08:19:54 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <200707130717.18224.fdrake@acm.org>
References: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>
	<200707130717.18224.fdrake@acm.org>
Message-ID: <f77ql0$u9l$3@sea.gmane.org>

Fred L. Drake, Jr. wrote:
> On Friday 13 July 2007, Anders J. Munch wrote:
>  > How about .pyzip instead?  To make it more obvious, and not mistakable for
>  > .py.z.
> 
> I guess it would be pinheaded to call it .zippy.  ;-)
> 
I believe .zpy would be most recognizable and lest subject to confusion.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------


From steve at holdenweb.com  Fri Jul 13 14:23:00 2007
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 13 Jul 2007 08:23:00 -0400
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <4696F46F.8090803@cryptohorizon.com>
References: <4696A0A8.4090604@v.loewis.de>	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<4696F46F.8090803@cryptohorizon.com>
Message-ID: <f77qqr$u9l$4@sea.gmane.org>

Dave Harrison wrote:
[...]
> I can't speak to how easily any of these cross over to the windows
> platform, although none of them seem to be overly windows friendly
> (YMMV).  But I presume this would be one of the key problems facing a
> distributed versioning system by the python community.
> 
We can probably assume that none of the Linux kernel team are developing 
on Windows. There is probably s a group with relevant experience 
somewhere. I'd Google for it, but I expect that the results would be 
dominated by British assertions that "you have to be a stupid git to run 
Windows".

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------


From matthieu.brucher at gmail.com  Fri Jul 13 14:37:34 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Fri, 13 Jul 2007 14:37:34 +0200
Subject: [Python-Dev] Typo in itertools.dropwhile()
In-Reply-To: <000001c7c546$3faec770$2100000a@RaymondLaptop1>
References: <e76aa17f0707121300l39463364n37289201b7092d6c@mail.gmail.com>
	<011401c7c509$64363480$7815800a@RaymondLaptop1>
	<87odigrg4v.fsf@uwakimon.sk.tsukuba.ac.jp>
	<000001c7c546$3faec770$2100000a@RaymondLaptop1>
Message-ID: <e76aa17f0707130537v24ff3924t8cc3bcc1a29f3726@mail.gmail.com>

Thank you very much !

Matthieu

2007/7/13, Raymond Hettinger <python at rcn.com>:
>
> [Stephen J. Turnbull]
> > Shouldn't the "until" in the doc be "while"?  Alternatively, "true"
> > could be changed to "false".
>
> Yes.  I'll make the change.
>
>
> Raymond
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070713/a26f21cf/attachment.html 

From murman at gmail.com  Fri Jul 13 15:44:50 2007
From: murman at gmail.com (Michael Urman)
Date: Fri, 13 Jul 2007 08:44:50 -0500
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <06e401c7c51e$b8da8d50$090a0a0a@enfoldsystems.local>
References: <dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>
	<06e401c7c51e$b8da8d50$090a0a0a@enfoldsystems.local>
Message-ID: <dcbbbb410707130644u6281e3bdr2f4dea94a207ede6@mail.gmail.com>

On 7/13/07, Mark Hammond <mhammond at skippinet.com.au> wrote:
> On Friday, 13 July 2007, Michael Urman wrote:
> I suspect I'm still missing something here.  The title of the page you
> referenced before is "Using 64-Bit Windows Installer Packages" - I suspect
> that is different than a 32-Bit installer package installing a 64bit
> program!

I haven't worked with it enough to know all the intracacies, but the
short of what I know is if your template is i386, you can only install
to 32-bit locations. If it is x64 or Intel64, then you can only
install on machines of those architectures, and the 64-bit locations
become available to components marked as 64-bit.

> using _winreg is (almost) like using the API directly.
> RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the
> real keys - I'm not aware of how 64bit apps would enable that reflection,
> but it probably doesn't really matter for our purposes.  In case anyone is
> interested, I just made a patch to _winreg.c adding these 2 functions
> (http://python.org/sf/1753245) in case anyone would like to review it.

http://msdn2.microsoft.com/en-us/library/aa384129.aspx describes the
KEY_WOW64_64KEY and KEY_WOW64_32KEY flags, allowing explicit access to
either set from either type of application.

> I think Tools\msi is what you are looking for, but hopefully Martin will
> chime in.  I'm more than happy to help test.

Thanks, and I see he has, and perhaps I've been looking at an incorrect file...

-- 
Michael Urman

From murman at gmail.com  Fri Jul 13 16:01:33 2007
From: murman at gmail.com (Michael Urman)
Date: Fri, 13 Jul 2007 09:01:33 -0500
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <46972B7D.9040901@v.loewis.de>
References: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>
	<06cb01c7c504$88b62d10$090a0a0a@enfoldsystems.local>
	<dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>
	<46972B7D.9040901@v.loewis.de>
Message-ID: <dcbbbb410707130701j34a15069j81239decbacf87cf@mail.gmail.com>

On 7/13/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Michael Urman schrieb:
> > Right - it sets the template summary to include Intel64, not x64.
>
> You might be looking at the wrong version. In Python 2.5, it also
> sets it to x64, if the PE machine type is 0x8664.

I've looked most closely at
http://svn.python.org/view/python/trunk/Lib/msilib/__init__.py?rev=47280&view=auto,
and from there not even full readings yet, just searching for Win64 to
see what the flag did. No doubt I have missed several intracacies.

> As we don't want any redirection, setting the flag on all components
> should be correct.

It may well be fine for the Python installers. Without the flag,
locations such as the 64-bit folder destinations resolve to the 32-bit
redirected locations, and the registry resolves to the 32-bit
reflected registry. The former isn't particularly helpful in any case
I can think of (as the non 64-bit locations are available anyway), but
the latter could be important if an 64-bit install needs to set 32-bit
registry keys.

> > The former, with hints of caution: it appears the unused 64-bit code
> > paths of msilib were created to best serve under incorrect
> > assumptions. With what the code would create (with or without Win64
> > set), it will not generate the 64-bit registry keys that the 64-bit
> > program will access.
>
> Why do you say that? What registry keys do you think it creates,
> and what registry keys do you think it should create instead?

Perhaps it's my reading the wrong version (the one I linked above
doesn't even have the string x64), or my assumption that msilib would
target a more general use case than pure 64-bit / pure 32-bit
installers. Or I missed the easy way to interleave 64 and 32-bit
components.

> There are no "64-bit registry keys" on Windows; Win64 only
> has "normal registry keys" and "32-bit (i.e. redirected)
> registry keys".

I find that nomenclature distinction to be more confusing than
referring to them "incorrectly" :)

> I always test whether the AMD 64 binary installs correctly before
> releasing it.

And I ran no tests at all, so I defer to you here.

> You don't need to provide patches - just tell me what's wrong with
> the MSI file. I.e. look at it in orca, correct it so that it works
> correctly, then report what changes you made.

That's even easier then, if anything's actually wrong. I'll find some
time this weekend to look at it and report back. Would the one at the
following URL be the correct one to verify?

http://www.python.org/ftp/python/2.5.1/python-2.5.1.amd64.msi
(linked from http://www.python.org/download/)

-- 
Michael Urman

From foom at fuhm.net  Fri Jul 13 16:14:44 2007
From: foom at fuhm.net (James Y Knight)
Date: Fri, 13 Jul 2007 10:14:44 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <20070712175600.8D73E3A40B0@sparrow.telecommunity.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<20070712145643.CE88B3A40A8@sparrow.telecommunity.com>
	<46964CC5.3080005@gmail.com>
	<20070712175600.8D73E3A40B0@sparrow.telecommunity.com>
Message-ID: <399C1A52-0EE9-4B18-8BA5-8F854A195AA8@fuhm.net>

On Jul 12, 2007, at 1:58 PM, Phillip J. Eby wrote:
> I don't have any particular objection to using runpy for this, but I
> believe that this shebang line won't actually work on certain non-BSD
> OSes, such as most Linux versions, which allow you to have at most
> *one* argument to a #! line, and will combine anything after the
> executable portion into a single argument.  This means that the only
> workable form of this line for cross-platform use is:
>
> #!/usr/bin/python2.6 -z
>
> And of course that won't work if Python is somewhere else.  You can't
> both use env to invoke Python, *and* expect arguments to work.  env
> will receive a single argument of "python -m runpy -p", which it will
> then try to invoke.  On Mac OS and various other BSDs, your example
> will work correctly, but it won't work most anywhere else, as few
> OSes actually support passing individual arguments from a #! line.   
> See:
>
>     http://www.in-ulm.de/~mascheck/various/shebang/

Ah, but you *can* use some quite clever quoting to get that effect.  
E.g. this starts up python with /usr/bin/env and a -O argument:

#!/bin/sh
""""exec /usr/bin/env python -O $0 "$@";" """

Credit for this trick originally belong to someone else: I found this  
on some website, but I don't know where anymore.

I'll leave it as a exercise to the reader to figure out how it works. :)

James

From murman at gmail.com  Fri Jul 13 16:18:48 2007
From: murman at gmail.com (Michael Urman)
Date: Fri, 13 Jul 2007 09:18:48 -0500
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <dcbbbb410707130701j34a15069j81239decbacf87cf@mail.gmail.com>
References: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>
	<06cb01c7c504$88b62d10$090a0a0a@enfoldsystems.local>
	<dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>
	<46972B7D.9040901@v.loewis.de>
	<dcbbbb410707130701j34a15069j81239decbacf87cf@mail.gmail.com>
Message-ID: <dcbbbb410707130718n130136e8o36e1b278cdf4adde@mail.gmail.com>

On 7/13/07, Michael Urman <murman at gmail.com> wrote:
> That's even easier then, if anything's actually wrong. I'll find some
> time this weekend to look at it and report back. Would the one at the
> following URL be the correct one to verify?
>
> http://www.python.org/ftp/python/2.5.1/python-2.5.1.amd64.msi
> (linked from http://www.python.org/download/)

Assuming this is the right file, the cause of the behavior Mark
reported is pretty clear. While the template summary is indeed x64,
the attributes on the registry components are all 4 instead of 256 |
4, so they are placed in the 32-bit reflected registry. I don't know
if this is desirable for some other reason.

-- 
Michael Urman

From martin at v.loewis.de  Fri Jul 13 16:51:38 2007
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 13 Jul 2007 16:51:38 +0200
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <dcbbbb410707130701j34a15069j81239decbacf87cf@mail.gmail.com>
References: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>	<06cb01c7c504$88b62d10$090a0a0a@enfoldsystems.local>	<dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>	<46972B7D.9040901@v.loewis.de>
	<dcbbbb410707130701j34a15069j81239decbacf87cf@mail.gmail.com>
Message-ID: <4697917A.1050004@v.loewis.de>

> I've looked most closely at
> http://svn.python.org/view/python/trunk/Lib/msilib/__init__.py?rev=47280&view=auto,
> and from there not even full readings yet, just searching for Win64 to
> see what the flag did. No doubt I have missed several intracacies.

Ah, ok. This should get fixed, but it isn't use to create the installer.
Instead, look at

http://svn.python.org/view/python/trunk/Tools/msi/msilib.py?rev=55245&view=markup

> Perhaps it's my reading the wrong version (the one I linked above
> doesn't even have the string x64), or my assumption that msilib would
> target a more general use case than pure 64-bit / pure 32-bit
> installers. 

Why should it? I have yet to see a use case for that.

> That's even easier then, if anything's actually wrong. I'll find some
> time this weekend to look at it and report back. Would the one at the
> following URL be the correct one to verify?
> 
> http://www.python.org/ftp/python/2.5.1/python-2.5.1.amd64.msi
> (linked from http://www.python.org/download/)

Indeed.

Regards,
Martin


From martin at v.loewis.de  Fri Jul 13 16:52:53 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jul 2007 16:52:53 +0200
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <dcbbbb410707130718n130136e8o36e1b278cdf4adde@mail.gmail.com>
References: <dcbbbb410707121934l7185ba50xb28bcd6e0c42a94@mail.gmail.com>	<06cb01c7c504$88b62d10$090a0a0a@enfoldsystems.local>	<dcbbbb410707122158s5e4d79dch73bfc30da2f3ce53@mail.gmail.com>	<46972B7D.9040901@v.loewis.de>	<dcbbbb410707130701j34a15069j81239decbacf87cf@mail.gmail.com>
	<dcbbbb410707130718n130136e8o36e1b278cdf4adde@mail.gmail.com>
Message-ID: <469791C5.2040705@v.loewis.de>

> Assuming this is the right file, the cause of the behavior Mark
> reported is pretty clear. While the template summary is indeed x64,
> the attributes on the registry components are all 4 instead of 256 |
> 4, so they are placed in the 32-bit reflected registry. I don't know
> if this is desirable for some other reason.

I found the same thing, and put a corrected installer at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi

Mark, can you please report whether that fixes your problem?

Regards,
Martin

From barry at python.org  Fri Jul 13 17:25:22 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Jul 2007 11:25:22 -0400
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
Message-ID: <2AC40587-6297-4082-97BC-915FB9F25470@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 12, 2007, at 5:54 PM, Brett Cannon wrote:

> I do know, though, that Thomas kept talking about moving us over to
> Bazaar (or some distributed VCS) and instead of having a ton of svn
> branches we have distributed VCS branch for each feature in Py3K.
> That way the VCS's strong merge system would work in our favour for
> pulling in from the various Py3K branches and for eventual mainline
> merging.

Mailman switch to Bazaar on June 22. The transition went pretty  
smoothly (the hardest part of the process was shutting off write  
access to Subversion ;).  I know some of us were talking about it at  
Pycon, but I've now been using it for 4 or 5 more months.  It's  
really a top-notch dvcs and I think it would bring a lot of benefit  
to the Python community.

I'll see if I can set up some public bzr mirrors of our svn  
repository for people to try it out.  Or you could just use the bzr- 
svn plugin to get a local repository.

There are lots of key benefits to using a dvcs, but IMO the most  
important is that it helps democratize the development process, and  
makes it much easier for the core to review and accept  
contributions.  diffs are so 20th century. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRpeZYnEjvBPtnXfVAQL0ugQArei77bNsmv1hdrfs6RGinNiBdhNvSet8
vprjc3JgdV0iBltSX2KvHj+xOEd49ImDtKSws1uQNDLzIGMzv65/P03d3udwd2fy
VrzBrO9Nlw+YdWtfJEcwCmRGT7Zj4HNUhYxQUB/V/3dytjLZoCp3m5xYAbfj44be
FThPPbnCeDI=
=CuEJ
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jul 13 17:31:42 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Jul 2007 11:31:42 -0400
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <2AC40587-6297-4082-97BC-915FB9F25470@python.org>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
Message-ID: <412802E2-3CFF-48FB-94A6-4B77E8664222@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 13, 2007, at 11:25 AM, Barry Warsaw wrote:

> I'll see if I can set up some public bzr mirrors of our svn
> repository for people to try it out.  Or you could just use the bzr-
> svn plugin to get a local repository.

Silly me, the trunk is already available:

https://code.launchpad.net/~vcs-imports/python/trunk

I could certainly request that other branches be mirrored if there's  
any interest.  Should the community ever decide to make the switch, I  
believe the entire Subversion history could be imported, though we  
may not care about the majority of existing branches.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRpea3nEjvBPtnXfVAQLZZAP9GeBgNh3t8fr5sA+sDk8gxnzp9ORQEaob
jqB5GfFYtthDPpwWElAYDbnBIO2jBWiidagVu40Rh1eLrIP74x+OFFkVdgK1yGP2
NJ1lJvk0jEMgDleMz2GTtEwULQDvKWM8jtw3qrdhQgIkM5H+DintF4BgkmpbmXKj
ecxLeQcvuR0=
=Z360
-----END PGP SIGNATURE-----

From skip at pobox.com  Fri Jul 13 17:39:04 2007
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 13 Jul 2007 10:39:04 -0500
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <2AC40587-6297-4082-97BC-915FB9F25470@python.org>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
Message-ID: <18071.40088.978318.822066@montanaro.dyndns.org>

    Barry> diffs are so 20th century. :)

How do you compare two versions of something without some sort of diff?

Skip

From aahz at pythoncraft.com  Fri Jul 13 17:46:09 2007
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 13 Jul 2007 08:46:09 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <da3f900e0707130440g53fd3562q25c937e0a3114f79@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<200707122255.15928.fdrake@acm.org>
	<ee2a432c0707122031v1c9ffd70md39af4656d5fb4c3@mail.gmail.com>
	<da3f900e0707130440g53fd3562q25c937e0a3114f79@mail.gmail.com>
Message-ID: <20070713154609.GA16150@panix.com>

On Fri, Jul 13, 2007, Chris Monson wrote:
> 
> Certainly java won't let you specify -jar more than once, because that
> would be telling it to *run* two files.  It *will*, however, let you
> specify more than one jar in the classpath.  This is done all the
> time, making the contents of those jars available for importing.
> 
> These aren't typically combined, since the whole point of running a
> jar file is to have a single distributed package, but IIRC it is not
> prohibited.

Actually, I do regularly use both classpath and -jar with java because
I'm running a .jar file that does not contain "the world".  OTOH, this
is a development environment rather than a production environment, so
theoretically I could just shove everything into the .jar file -- but I
don't because that adds more time to the compile/link/jarjarjar cycle.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

I support the RKAB

From barry at python.org  Fri Jul 13 18:10:55 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Jul 2007 12:10:55 -0400
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <18071.40088.978318.822066@montanaro.dyndns.org>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<18071.40088.978318.822066@montanaro.dyndns.org>
Message-ID: <DC11E09B-450D-4C7E-A449-EC930CAD5718@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 13, 2007, at 11:39 AM, skip at pobox.com wrote:

>     Barry> diffs are so 20th century. :)
>
> How do you compare two versions of something without some sort of  
> diff?

Well okay, you caught me being flippant. :)

Sure, you visually compare with diffs, but you apply those changes  
with merges.  This means the end of posting patches because instead  
what you would do is post the url to a branch that you published some  
place.  It means that branch can be kept up-to-date as its parent  
branch changes, so a new feature candidate need never get stale.  It  
also means your new feature candidate is a first class revision  
control branch, just as usable as the trunk, say.  So it's much more  
powerful than trading patch files around.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRpekD3EjvBPtnXfVAQLBqwP/RbJ3VhArWjijJ99/u3CzAy0xbcvnUIEv
htlZ/2PBXGZ+ZZm0uQiQcnwlczVUVAiyopdPgTAUmerh9aYWZTP8rtC3SIG7gBDz
6QdNYMl2Rvh5AsvLNXo3HzTyVx74cKHEy91csUuoUWomBa1dR9DVRsT+CpbwM4U8
q11cm7kjXa4=
=v4w0
-----END PGP SIGNATURE-----

From facundobatista at gmail.com  Fri Jul 13 18:24:21 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 13 Jul 2007 13:24:21 -0300
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <DC11E09B-450D-4C7E-A449-EC930CAD5718@python.org>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<18071.40088.978318.822066@montanaro.dyndns.org>
	<DC11E09B-450D-4C7E-A449-EC930CAD5718@python.org>
Message-ID: <e04bdf310707130924p21747404md299cfe85e3b6782@mail.gmail.com>

2007/7/13, Barry Warsaw <barry at python.org>:

> with merges.  This means the end of posting patches because instead
> what you would do is post the url to a branch that you published some
> place.  It means that branch can be kept up-to-date as its parent
> branch changes, so a new feature candidate need never get stale.  It
> also means your new feature candidate is a first class revision
> control branch, just as usable as the trunk, say.  So it's much more
> powerful than trading patch files around.

More powerful, maybe, but also more limitating.

Do you still have the "patch" metodologie? How can you provide a patch
if you don't have a place to publish the change?

3rd-world--ly yours,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From martin at v.loewis.de  Fri Jul 13 18:54:41 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jul 2007 18:54:41 +0200
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <DC11E09B-450D-4C7E-A449-EC930CAD5718@python.org>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<18071.40088.978318.822066@montanaro.dyndns.org>
	<DC11E09B-450D-4C7E-A449-EC930CAD5718@python.org>
Message-ID: <4697AE51.50006@v.loewis.de>

> Sure, you visually compare with diffs, but you apply those changes with
> merges.  This means the end of posting patches because instead what you
> would do is post the url to a branch that you published some place.

But how do you publish stuff? Do you need to run your own web server on
your dial-up machine?

I simply cannot imagine that all contributors have access to some
machine that is always online and willing to host bzr patches (which
is necessary IIUC).

Regards,
Martin

From jimjjewett at gmail.com  Fri Jul 13 19:09:01 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 13 Jul 2007 13:09:01 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
Message-ID: <fb6fbf560707131009m1704e299m409922e1f29e98d5@mail.gmail.com>

Andy C wrote:
>... a .zip file with a __zipmain__.py module at its root?

Why not just an __init__.py, which you would normally execute if you
tried to import/run a directory?

> * Magically looking at the first argument to see if it's a zip file
> seems problematic to me.  I'd rather be explicit with the -z flag.
> Likewise, I'd rather be explicit and call it __zipmain__ rather than
> __main__.

Treating zip files (and only zip files) as a special case equivalent
to uncompressed files seems like a wart; I would prefer not to
special-case zips any more than they already are.

If anything, I would like to see the -m option enhanced so that if it
gets a recognized "collection" file type (including a directory or
zip), it does the right thing.  Whether that actually makes sense, or
defeats the purpose of the -m shortcut, I'm not sure.

[on using __main__ instead of __init__ or __zipmain__]

> __main__.py?  : )  If someone tries does import __main__ from another
> module in the program, won't that result in an infinite loop?

It doesn't today; it does use circular imports, which can be a problem.

> while I think it would be a bad practice to
> import __main__,

I have seen it recommended as the right place to store global
(cross-module) settings.

-jJ

From barry at python.org  Fri Jul 13 19:31:13 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Jul 2007 13:31:13 -0400
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <4697AE51.50006@v.loewis.de>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<18071.40088.978318.822066@montanaro.dyndns.org>
	<DC11E09B-450D-4C7E-A449-EC930CAD5718@python.org>
	<4697AE51.50006@v.loewis.de>
Message-ID: <78D66207-7204-4715-803C-4CA45D534F07@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 13, 2007, at 12:54 PM, Martin v. L?wis wrote:

>> Sure, you visually compare with diffs, but you apply those changes  
>> with
>> merges.  This means the end of posting patches because instead  
>> what you
>> would do is post the url to a branch that you published some place.
>
> But how do you publish stuff? Do you need to run your own web  
> server on
> your dial-up machine?

You could, but you certainly don't need to.  For example, Launchpad 
[1] hosts bzr code branches for anyone working on open source  
software.  Sign in (for free of course) and start pushing your own  
branches immediately[2].

However, there's also no reason why other such services couldn't be  
deployed, perhaps even hosted by the PSF, just like we do with  
Subversion.  The difference is that it doesn't matter because unlike  
running multiple Subversion repositories, dvcs's in general are  
designed to be distributed (duh :).

> I simply cannot imagine that all contributors have access to some
> machine that is always online and willing to host bzr patches (which
> is necessary IIUC).

Having access is easy.  Self-publishing might not be something people  
want to do (it's certainly not something I want to do), but that's  
not a requirement.

- -Barry

[1] <http://www.launchpad.net> which is a service provided by  
Canonical.  Full disclosure: I work for them.  But I'm not touting  
that as a company shill; I really do think that bzr and the Launchpad  
code hosting service provide a lot of benefit.  Be your own judge.

[2] E.g. https://code.launchpad.net/~barry/munepy/trunk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRpe24nEjvBPtnXfVAQITRQP/YNKJ8GSU/vvXrAyIi/EHhQhGLyXma1Xg
rSzDWbQV/khXGhnsxOEwdKJUXKHskyGkJFr0x3ClCyiAKyLAgpM/pgbknAfuE5mU
9oAD+K/aGYFem+BxoLfwFeE0eBqDw/NYvnQH3FHSPaEpTJ2eCtu+M6N7AB0MUQQH
9pL7VYT3bEk=
=Hio1
-----END PGP SIGNATURE-----

From barry at python.org  Fri Jul 13 19:33:27 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Jul 2007 13:33:27 -0400
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <e04bdf310707130924p21747404md299cfe85e3b6782@mail.gmail.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<18071.40088.978318.822066@montanaro.dyndns.org>
	<DC11E09B-450D-4C7E-A449-EC930CAD5718@python.org>
	<e04bdf310707130924p21747404md299cfe85e3b6782@mail.gmail.com>
Message-ID: <7CB8DCD6-DD50-43C8-A4E5-5016CD40041A@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 13, 2007, at 12:24 PM, Facundo Batista wrote:

> 2007/7/13, Barry Warsaw <barry at python.org>:
>
>> with merges.  This means the end of posting patches because instead
>> what you would do is post the url to a branch that you published some
>> place.  It means that branch can be kept up-to-date as its parent
>> branch changes, so a new feature candidate need never get stale.  It
>> also means your new feature candidate is a first class revision
>> control branch, just as usable as the trunk, say.  So it's much more
>> powerful than trading patch files around.
>
> More powerful, maybe, but also more limitating.
>
> Do you still have the "patch" metodologie? How can you provide a patch
> if you don't have a place to publish the change?

You can still have a patch methodology if your internet connection  
really sucks.  But if you have good enough access to the current  
Subversion repository, then you probably have good enough access to  
use a free branch hosting service like Launchpad.

- -Barry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRpe3aHEjvBPtnXfVAQL1swQAuXP/QX5c/isttwQ3Et/N7fp6mG9a+sA+
HX7G6rSWxaYGtmYOjXTqjeou/QEoNlEtOqvZQcAJQ4iObMVg0mVIVFxixPln3JPQ
u4XNt37FklJh7q0tbvi6VQeBi82beqWuL6+MTE6dMD1ruRAkJ/zpM9/ruiCBSmSB
XO84dNkv/dY=
=sUf+
-----END PGP SIGNATURE-----

From skip at pobox.com  Fri Jul 13 19:58:24 2007
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 13 Jul 2007 12:58:24 -0500
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <412802E2-3CFF-48FB-94A6-4B77E8664222@python.org>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<412802E2-3CFF-48FB-94A6-4B77E8664222@python.org>
Message-ID: <18071.48448.156970.833314@montanaro.dyndns.org>


    Barry> Silly me, the trunk is already available:

    Barry> https://code.launchpad.net/~vcs-imports/python/trunk

Bazaar keeps this in sync with svn.python.org?

Skip

From alex.neundorf at kitware.com  Fri Jul 13 19:59:16 2007
From: alex.neundorf at kitware.com (Alexander Neundorf)
Date: Fri, 13 Jul 2007 13:59:16 -0400
Subject: [Python-Dev] Building Python with CMake
Message-ID: <200707131359.17030.alex.neundorf@kitware.com>

Hi,

as I wrote in my previous email, I'm currently porting Python to some more 
unusual platforms, namely to a super computer 
(http://www.research.ibm.com/bluegene/) and a tiny embedded operating system 
(http://ecos.sourceware.org), which have more or less surprisingly quite 
similar properties.

To do this, I added CMake files to Python, in order to use CMake to cross 
compile Python to these platforms. CMake (http://www.cmake.org) is a 
buildsystem in scope similar to autotools, but it's just one tool (instead of 
a collection of tools) and it support Windows and the MS compilers as first 
class citizens, i.e. it can not only generate Makefiles, but also project 
files for the various versions of Visual Studio, and also for XCode.

Attached you can find the files I had to add to get this working. With these 
CMake files I was able to build python for eCos, BlueGene, Linux and Windows 
(with Visual Studio 2003, but here I simply reused the existing pyconfig.h, 
because I didn't want to spend to much time with this). 
So for Linux the configure checks should be already quite good and almost 
complete, for eCos and BlueGene they also work (both are UNIX-like), for 
Windows there is probably some tweaking required.

So if anybody is interested in trying to use CMake for Python, you can find 
the files attached. Version 2.4.5 of CMake or newer is required.

I guess I should mention that I'm doing this currently with the released 
Python 2.5.1.

Bye
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Python-2.5.1-cmake.tar.bz2
Type: application/x-tbz
Size: 13850 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20070713/890fcc4a/attachment-0001.bin 

From pje at telecommunity.com  Fri Jul 13 20:10:25 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 13 Jul 2007 14:10:25 -0400
Subject: [Python-Dev] Alternative to -z option
Message-ID: <20070713180813.E80293A40AE@sparrow.telecommunity.com>

After thinking about it some more, I suggest that instead of using a 
special option to execute a zipfile, we simply always get an importer 
for the script filename.  If the importer is imp.NullImporter, then 
we do normal script processing.  Otherwise, we set set sys.path[0] = 
sys.argv[0] = script, and import __main__.

This will support zipfiles and directories, Windows and Unix, even 
using "env" (since no option to the interpreter is required).

Thoughts?


From pje at telecommunity.com  Fri Jul 13 20:16:06 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 13 Jul 2007 14:16:06 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.co
 m>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
	<469695B1.5050107@v.loewis.de>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.com>
Message-ID: <20070713181353.5AF4B3A40AE@sparrow.telecommunity.com>

At 09:13 PM 7/12/2007 -0700, Andy C wrote:
>I can definitely see why it "just makes sense", and my first thought
>was indeed to name it __main__.  But then you lose the ability to make
>a distinction:  What does "if __name__ == '__main__" mean in
>__main__.py?  : )

The same as anywhere else; it'll just always be true.  :)

>  If someone tries does import __main__ from another
>module in the program, won't that result in an infinite loop?

No, for two reasons.  First, importing __main__ always returns 
whatever the start script is using as a __main__ module.  Second, 
even if you're in the middle of __main__ itself, the module is 
already in sys.modules.  So this is a non-issue.


>At Google some people do "import sitecustomize" and get values that
>were computed earlier by the sitecustomize.  I could see the same kind
>of thing happen with __main__.py.

Yes, but it won't work unless the overall program was launched via 
*that particular* __main__.py -- running from the interpreter prompt 
for example, those values won't be there.  So, people will learn 
quickly why that doesn't work.


> > Testing your package before you zip it, would be one.  :)  My
> > personal main interest was in being able to add an item to sys.path
> > without having to set $PYTHONPATH on Windows.  That's why I'd like it
> > to be possible to use -z more than once (or whatever the option 
> ends up as).
>
>Where would you do that?  Just typing it literally on the command
>line?

Yes.


> > >   I think it's sufficient to treat it as a documented "trick"
> > >that you can substitute a whole directory for a zip file with the -z
> > >flag.  If there is a concrete suggestion, I'd like to discuss it, but
> > >otherwise it seems like we'll get bogged down in expanding use cases.
> >
> > Eh? First you say there aren't any use cases, now you say there'll be
> > too many?  I'm confused.  The only competing proposal besides what
> > I've suggested was the one to add an option to "runpy", and IMO
> > that's dead in the water due to shebang argument limits.
>
>As implemented the patch is fairly simple, and shouldn't have any
>unintended consequences.  I'm not necessarily opposed to making it
>more general and thinking about sys.path vs. a zip file specifically.

I think it can be replaced with using standard importer detection of 
sys.argv[0], to decide whether it is an importable location 
(dir/zip), and then importing __main__, with fallback to the old 
script behavior.  This is forward-compatible with other import 
mechanisms, and supports #! lines better for zipfiles, since no -z 
option is needed.


From p.f.moore at gmail.com  Fri Jul 13 20:27:57 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 13 Jul 2007 19:27:57 +0100
Subject: [Python-Dev] Alternative to -z option
In-Reply-To: <20070713180813.E80293A40AE@sparrow.telecommunity.com>
References: <20070713180813.E80293A40AE@sparrow.telecommunity.com>
Message-ID: <79990c6b0707131127g646470aekc55e34cfc8a18d71@mail.gmail.com>

On 13/07/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> After thinking about it some more, I suggest that instead of using a
> special option to execute a zipfile, we simply always get an importer
> for the script filename.  If the importer is imp.NullImporter, then
> we do normal script processing.  Otherwise, we set set sys.path[0] =
> sys.argv[0] = script, and import __main__.
>
> This will support zipfiles and directories, Windows and Unix, even
> using "env" (since no option to the interpreter is required).
>
> Thoughts?

Let me get this right: if I had a one-liner hello.py (containing the
line print "Hello, world") all I'd need to do is

(1) rename hello.py to __main__.py
(2) zip hello.zip __main__.py.

Then,

    python hello.zip

would work exactly as python hello.py did previously?

Sounds plausible. I'm not entirely clear on the details of the code
needed (long day!) - would you be willing to produce a patch? (One
major point in favour of the -z patch is that it exists already!)

Paul.

From martin at v.loewis.de  Fri Jul 13 20:28:39 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Jul 2007 20:28:39 +0200
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <412802E2-3CFF-48FB-94A6-4B77E8664222@python.org>
References: <4696A0A8.4090604@v.loewis.de>	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<412802E2-3CFF-48FB-94A6-4B77E8664222@python.org>
Message-ID: <4697C457.5060308@v.loewis.de>

> Should the community ever decide to make the switch

The last time, I was asked to write a PEP. I would demand the same
thing the next time such a switch is suggested.

I would be -1 on any proposed switch to a system that hasn't made
its 1.0 release yet (myself, I've used subversion since 0.21, and
I certainly don't want to go back to these times).

Regards,
Martin

From Dennis.Benzinger at gmx.net  Fri Jul 13 20:50:57 2007
From: Dennis.Benzinger at gmx.net (Dennis Benzinger)
Date: Fri, 13 Jul 2007 20:50:57 +0200
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <18071.48448.156970.833314@montanaro.dyndns.org>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<412802E2-3CFF-48FB-94A6-4B77E8664222@python.org>
	<18071.48448.156970.833314@montanaro.dyndns.org>
Message-ID: <20070713205057.4c22c8ec@dennis-laptop>

Am Fri, 13 Jul 2007 12:58:24 -0500
schrieb skip at pobox.com:

> 
>     Barry> Silly me, the trunk is already available:
> 
>     Barry> https://code.launchpad.net/~vcs-imports/python/trunk
> 
> Bazaar keeps this in sync with svn.python.org?
> [...]

Yes, the branch is update regularly. I think it's done nightly.
The last checkin is from Georg Brandl for patch #1675424.

Bye,
Dennis Benzinger

From facundobatista at gmail.com  Fri Jul 13 20:53:46 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 13 Jul 2007 15:53:46 -0300
Subject: [Python-Dev] Building Python with CMake
In-Reply-To: <200707131359.17030.alex.neundorf@kitware.com>
References: <200707131359.17030.alex.neundorf@kitware.com>
Message-ID: <e04bdf310707131153x780293b3p9561b8e5d9952069@mail.gmail.com>

2007/7/13, Alexander Neundorf <alex.neundorf at kitware.com>:

> as I wrote in my previous email, I'm currently porting Python to some more
> unusual platforms, namely to a super computer
> (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system
> (http://ecos.sourceware.org), which have more or less surprisingly quite
> similar properties.

Sorry, missed the previous mail. Have two questions for you:

- Why?

- Do you know if there're plans for support this two platforms beyond
this porting?

Thank you!!

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From thomas at python.org  Fri Jul 13 21:44:35 2007
From: thomas at python.org (Thomas Wouters)
Date: Fri, 13 Jul 2007 12:44:35 -0700
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <e04bdf310707130924p21747404md299cfe85e3b6782@mail.gmail.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<2AC40587-6297-4082-97BC-915FB9F25470@python.org>
	<18071.40088.978318.822066@montanaro.dyndns.org>
	<DC11E09B-450D-4C7E-A449-EC930CAD5718@python.org>
	<e04bdf310707130924p21747404md299cfe85e3b6782@mail.gmail.com>
Message-ID: <9e804ac0707131244y119f0c35mfd336befe817c917@mail.gmail.com>

On 7/13/07, Facundo Batista <facundobatista at gmail.com> wrote:
>
> 2007/7/13, Barry Warsaw <barry at python.org>:
>
> > with merges.  This means the end of posting patches because instead
> > what you would do is post the url to a branch that you published some
> > place.  It means that branch can be kept up-to-date as its parent
> > branch changes, so a new feature candidate need never get stale.  It
> > also means your new feature candidate is a first class revision
> > control branch, just as usable as the trunk, say.  So it's much more
> > powerful than trading patch files around.
>
> More powerful, maybe, but also more limitating.
>
> Do you still have the "patch" metodologie? How can you provide a patch
> if you don't have a place to publish the change?


All DCVS's I looked at had a simple file export for 'changes'. It's diff +
metadata, basically, which means it includes renames, directory mutation,
changelogs, change-dependency information (which 'revision' it is based on,
in effect) and whatever else the DCVS needs or wants. You can toss those
around just like you can toss around diffs.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070713/32c78875/attachment.htm 

From alex.neundorf at kitware.com  Fri Jul 13 21:48:33 2007
From: alex.neundorf at kitware.com (Alexander Neundorf)
Date: Fri, 13 Jul 2007 15:48:33 -0400
Subject: [Python-Dev] Building Python with CMake
In-Reply-To: <e04bdf310707131153x780293b3p9561b8e5d9952069@mail.gmail.com>
References: <200707131359.17030.alex.neundorf@kitware.com>
	<e04bdf310707131153x780293b3p9561b8e5d9952069@mail.gmail.com>
Message-ID: <200707131548.33046.alex.neundorf@kitware.com>

On Friday 13 July 2007 14:53, you wrote:
> 2007/7/13, Alexander Neundorf <alex.neundorf at kitware.com>:
> > as I wrote in my previous email, I'm currently porting Python to some
> > more unusual platforms, namely to a super computer
> > (http://www.research.ibm.com/bluegene/) and a tiny embedded operating
> > system (http://ecos.sourceware.org), which have more or less surprisingly
> > quite similar properties.
>
> Sorry, missed the previous mail. Have two questions for you:
>
> - Why?

Why porting or why using cmake ?
Porting because of VTK (http://www.vtk.org), cmake because it has really good 
support for cross compiling (cvs version of cmake). And it has the nice side 
effect that the manually maintained MSVC project files would not be required 
anymore.

> - Do you know if there're plans for support this two platforms beyond
> this porting?

BlueGene is for running VTK on it, and this will be supported for the coming 
years. eCos was for testing the cross compile, since this is easier to work 
with than with BlueGene. I don't know if there will be users for Python on 
eCos, but then again I didn't have to change anything to get it working on 
eCos, the configure checks did it all.

Bye
Alex

From rasky at develer.com  Fri Jul 13 22:04:11 2007
From: rasky at develer.com (Giovanni Bajo)
Date: Fri, 13 Jul 2007 22:04:11 +0200
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <f77qqr$u9l$4@sea.gmane.org>
References: <4696A0A8.4090604@v.loewis.de>	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>	<4696F46F.8090803@cryptohorizon.com>
	<f77qqr$u9l$4@sea.gmane.org>
Message-ID: <f78lrs$5h4$1@sea.gmane.org>

On 13/07/2007 14.23, Steve Holden wrote:

>> I can't speak to how easily any of these cross over to the windows
>> platform, although none of them seem to be overly windows friendly
>> (YMMV).  But I presume this would be one of the key problems facing a
>> distributed versioning system by the python community.
>>
> We can probably assume that none of the Linux kernel team are developing 
> on Windows. There is probably s a group with relevant experience 
> somewhere. I'd Google for it, but I expect that the results would be 
> dominated by British assertions that "you have to be a stupid git to run 
> Windows".

git doesn't support Windows in a way that Windows users would find reasonable. 
In fact, the only ones saying it does already support Windows are non-Windows 
users.

hg has a much more mature Windows support. In fact, I didn't face any major 
problems in using it under Windows (even in the details: eg, it supports 
case-insensitive filesystems).

I can't speak of bzr.
-- 
Giovanni Bajo


From thomas at python.org  Fri Jul 13 22:05:30 2007
From: thomas at python.org (Thomas Wouters)
Date: Fri, 13 Jul 2007 13:05:30 -0700
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
Message-ID: <9e804ac0707131305m7a35cb5fq32bdca0d66b063d1@mail.gmail.com>

On 7/12/07, Brett Cannon <brett at python.org> wrote:

> I do know, though, that Thomas kept talking about moving us over to
> Bazaar (or some distributed VCS) and instead of having a ton of svn
> branches we have distributed VCS branch for each feature in Py3K.
> That way the VCS's strong merge system would work in our favour for
> pulling in from the various Py3K branches and for eventual mainline
> merging.


No. I never talked about moving us over. I do not believe and have never
believed that to be feasible (in the foreseeable future.) It is certainly
possible to host a project of Python's size, depth of history and number of
committers in a DVCS (Monotone is my personal favourite, with Mercurial and
Bazaar a shared second), and certain things would go a _lot_ better with
proper branch tracking and merging, but switching over Python means an
entirely new way of working, educating all the developers and working around
the limitations of the chosen system. (I'm not saying they have more
limitations than Subversion per se, but we are already used to working
around Subversion's limitations.)

What I talked about was converting the monolithic p3yk branch to a
collection of separate feature-branches, which would then be merged together
into "the py3k branch", as well as the trunk (for backported changes.) The
p3yk branch contains many changes that will never be backported, mixed in
with change we want in Python 2.6. We currently do manual merging from the
trunk into p3yk. When we start backporting features, those features in the
trunk will end up conflicting with the p3yk changes. Worse, we will need to
manually track bugfixes to those features in the p3yk branch in order to
apply them to the trunk, and take extra care when merging in bugfixes from
the trunk, too. Because Subversion don't keep track of which chunk was
already merged, you get a lot of spurious conflicts. It gets extremely
tedious to do those merges manually, and the error rate raises
significantly. (I already have an uncomfortable feeling that I missed some
of the merges in the p3yk branch, leaving bugs in p3yk that were fixed in
the trunk. Fortunately, tests catch them fairly quickly -- but we still
don't have 100% test coverage, not even for newly fixed bugs.)

I have been working on converting the p3yk branch into separate Bazaar[*]
branches, by first converting the whole branch (with 'tailor') and then
applying each changeset to an appropriate feature branch, creating them as
needed (using a little script based on tailor, because cherrypicking doesn't
quite do what I want.) The last half year of changes, though, gets so
incredibly intertwined that it's quite hard to pull them apart. Furthermore,
I would still have to merge them back together to create the original py3k
branch, and do merges with the trunk, too.

I've been forced to decide it's not worth it, at this point. If we'd started
with separate feature-branches earlier, it would have been. Now, it's easier
and less error prone to just suck it up and deal with the numerous conflicts
backported features will create. (Since I will be doing much backporting
myself, I'm not just letting someone else deal with the mess :-)

Some-branch-of-me'ly y'rs,

[*] Bazaar was chosen for a number of unimportant reasons that are entirely
moot at this point. It doesn't reflect my personal preference or constitute
any form of official endorsement :-)
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070713/df822a5a/attachment.htm 

From rasky at develer.com  Fri Jul 13 22:11:56 2007
From: rasky at develer.com (Giovanni Bajo)
Date: Fri, 13 Jul 2007 22:11:56 +0200
Subject: [Python-Dev] Building Python with CMake
In-Reply-To: <e04bdf310707131153x780293b3p9561b8e5d9952069@mail.gmail.com>
References: <200707131359.17030.alex.neundorf@kitware.com>
	<e04bdf310707131153x780293b3p9561b8e5d9952069@mail.gmail.com>
Message-ID: <f78mad$876$1@sea.gmane.org>

On 13/07/2007 20.53, Facundo Batista wrote:

>> as I wrote in my previous email, I'm currently porting Python to some more
>> unusual platforms, namely to a super computer
>> (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system
>> (http://ecos.sourceware.org), which have more or less surprisingly quite
>> similar properties.
> 
> Sorry, missed the previous mail. Have two questions for you:
> 
> - Why?

Because it would be a single unified build system instead of having two build 
systems like we have one (UNIX and Windows).

Also, it would be much easier to maintain because Visual Studio projects are 
generated from a simple description, while right now if you want to change 
something you need to go through the hassle of defining it within the Visual 
Studio GUI.

Consider for instance if you want to change the Windows build so that a 
builtin module is compiled as an external .pyd instead. Right now, you need to 
go through the hassle of manually defining a new project, setting all the 
include/libraries dependencies correctly, ecc. ecc. With CMake or a similar 
tool, it would be a matter of a couple of textual line changes.

[ I'll also remember that "ease of maintanance for developers" is the #1 
reason for having a 2.1Mb python25.dll under Windows, which I would really 
love to reduce. ]
-- 
Giovanni Bajo


From barry at python.org  Fri Jul 13 22:12:00 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Jul 2007 16:12:00 -0400
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <f78lrs$5h4$1@sea.gmane.org>
References: <4696A0A8.4090604@v.loewis.de>	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>	<4696F46F.8090803@cryptohorizon.com>
	<f77qqr$u9l$4@sea.gmane.org> <f78lrs$5h4$1@sea.gmane.org>
Message-ID: <23F1C95A-6AF7-43AD-BE84-23EF2F5E1325@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 13, 2007, at 4:04 PM, Giovanni Bajo wrote:

> I can't speak of bzr.

I don't use or even have Windows, but this page says there are native  
Windows binaries available (yes Bazaar is pure Python):

http://bazaar-vcs.org/BzrOnPureWindows

There's also a Tortoise-like extension available:

http://bazaar-vcs.org/TortoiseBzr

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRpfckHEjvBPtnXfVAQKArwP/aS20z5EcNT7GJSMepCORo34tE5SpF1g/
OMvRTervNDuUmjulgAHM9w9Chi3lOibM6eX0nJ8kHHzoaPrFDQkzh1/Gc+OZqfSA
FAgctJtVkT956o+F1+xFe90KqtTtH8gmwHMFMhr/a7BZvV1S1kpCyu8ygI3YEe2u
5JParA9UcO0=
=5HLR
-----END PGP SIGNATURE-----

From thomas at python.org  Fri Jul 13 22:16:28 2007
From: thomas at python.org (Thomas Wouters)
Date: Fri, 13 Jul 2007 13:16:28 -0700
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <4696F46F.8090803@cryptohorizon.com>
References: <4696A0A8.4090604@v.loewis.de>
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>
	<4696F46F.8090803@cryptohorizon.com>
Message-ID: <9e804ac0707131316t5aa5bbd5sc5a72bfac93fcd7b@mail.gmail.com>

On 7/12/07, Dave Harrison <dave at cryptohorizon.com> wrote:

> So far I've used DARCS, Hg, and Git.  And at this point Git is far and
> away the winner.


Let's not start a discussion on which DVCS is better, or I'd burn your ears
off about all the ways each of those (as well as Bazaar, Arch/tla/bzr1, Arx,
CodeVille, SVK, Monotone and BitKeeper) suck, suck badly or are the work of
the devil. The official Python source repository will be Subversion for now
(although it isn't officially my decision :). I encourage anyone to use a
mirror of it in their own favourite VCS, and do their own development in it.
'tailor' is a nice tool if you care about having the full history (as I do)
and you don't happen to hit bugs in it or the VCS. Do realize that the full
history may be a burden, especially in DVCS solutions.

For what it's worth, rumour has it Subversion 1.5 or 2.0 will get actual
branch tracking and full-history merging. If done properly (it's not done
yet, so it's hard to say) it would reduce the advantage of the DVCS
solutions by about half ;-P

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070713/b11b074e/attachment.html 

From mhammond at skippinet.com.au  Sat Jul 14 00:45:16 2007
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 14 Jul 2007 08:45:16 +1000
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <46972E78.8080506@v.loewis.de>
Message-ID: <077501c7c59f$7c14fa50$090a0a0a@enfoldsystems.local>

Martin quoting me:
> > Yes - that is a bit of a shame, as having 32bit components
> > would allow more flexibility (eg, allow a 64bit install of
> > Python to work with an IIS configured for 32bit extensions),
> > but that's something we can deal with later if necessary.
>
> Can you elaborate?

As you mention, 64 and 32bit programs use different instruction sets.
Therefore, trying to use a 64bit install of Python with IIS configured to
work with 32bits is not going to work.  In this case, switching the
configuration of IIS will require the Python user to uninstall the previous
version and install a different version - but some sites may end up in a
dilemma here - they may be *forced* to use IIS in 32bit mode due to no 64bit
port for a tool they need, but simultaneously desire a 64bit build of Python
for other tasks on that same box.

> It's incorrect for a Win64 installer to make the executable components
Win32.

Right - I got the impression from Micheal that it was possible for 32bit
components to be installed in a 64bit install, but I don't profess to know
anything about this.

> A 64 bit pythonxy.dll cannot work in
> a 32-bit IIS - it's a different instruction set. That's not something
> that you can fix by just installing things differently.

Exactly - which is why I'm suggesting that not "allowing" 64bit and 32bit
versions of Python to be installed on the same box will cause inconvenience
for some people.  I agree such people will be in the minority, and their
requirements are not clear, so I'm not pushing for a change of policy here.

> > using _winreg is (almost) like using the API directly.
> > RegDisable[/Enable]ReflectionKey appears to let the 32bit
> > process see the
> > real keys - I'm not aware of how 64bit apps would enable
> > that reflection,
> > but it probably doesn't really matter for our purposes.
>
> They can specify KEY_WOW64_32KEY.

Ah - thanks.

Cheers,

Mark


From mhammond at skippinet.com.au  Sat Jul 14 01:12:14 2007
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sat, 14 Jul 2007 09:12:14 +1000
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <469791C5.2040705@v.loewis.de>
Message-ID: <077a01c7c5a3$40044030$090a0a0a@enfoldsystems.local>

Martin:
> > Assuming this is the right file, the cause of the behavior Mark
> > reported is pretty clear. While the template summary is indeed x64,
> > the attributes on the registry components are all 4 instead of 256 |
> > 4, so they are placed in the 32-bit reflected registry. I don't know
> > if this is desirable for some other reason.
> 
> I found the same thing, and put a corrected installer at
> 
> http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi
> 
> Mark, can you please report whether that fixes your problem?

It does indeed - thank you guys!

Mark


From dave at cryptohorizon.com  Sat Jul 14 03:42:23 2007
From: dave at cryptohorizon.com (Dave Harrison)
Date: Sat, 14 Jul 2007 11:42:23 +1000
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <9e804ac0707131316t5aa5bbd5sc5a72bfac93fcd7b@mail.gmail.com>
References: <4696A0A8.4090604@v.loewis.de>	
	<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>	
	<4696F46F.8090803@cryptohorizon.com>
	<9e804ac0707131316t5aa5bbd5sc5a72bfac93fcd7b@mail.gmail.com>
Message-ID: <469829FF.5090403@cryptohorizon.com>

Thomas Wouters wrote:
> 
> On 7/12/07, *Dave Harrison* <dave at cryptohorizon.com
> <mailto:dave at cryptohorizon.com>> wrote:
> 
>     So far I've used DARCS, Hg, and Git.  And at this point Git is far and
>     away the winner.
> 
> 
> Let's not start a discussion on which DVCS is better, or I'd burn your
> ears off about all the ways each of those (as well as Bazaar,
> Arch/tla/bzr1, Arx, CodeVille, SVK, Monotone and BitKeeper) suck, suck
> badly or are the work of the devil. The official Python source
> repository will be Subversion for now (although it isn't officially my
> decision :). I encourage anyone to use a mirror of it in their own
> favourite VCS, and do their own development in it. 'tailor' is a nice
> tool if you care about having the full history (as I do) and you don't
> happen to hit bugs in it or the VCS. Do realize that the full history
> may be a burden, especially in DVCS solutions.
> 
> For what it's worth, rumour has it Subversion 1.5 or 2.0 will get actual
> branch tracking and full-history merging. If done properly (it's not
> done yet, so it's hard to say) it would reduce the advantage of the DVCS
> solutions by about half ;-P

While I don't necessarily agree (and await for that burning feeling to
start in my ears ;-) ), I think the lack of a decent windows port for
some, and general lack of real maturity in most, are the killer
arguments against DRCS for Python at this point.

My own DRCS of preference (git) has a method for pulling from
subversion anyway, and I can't really claim to even contribute much
directly _to_ Python's core, so I'm wary of claiming to be too
invested in this.  That said, there are always strong arguments in
favour of the distributed model encouraging and fostering community
dev participation - and code always speaks louder than words heh.

Dave

From greg.ewing at canterbury.ac.nz  Sat Jul 14 04:58:33 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 14 Jul 2007 14:58:33 +1200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
	<469695B1.5050107@v.loewis.de>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.com>
Message-ID: <46983BD9.70702@canterbury.ac.nz>

Andy C wrote:
> What does "if __name__ == '__main__" mean in
> __main__.py?  : )  If someone tries does import __main__ from another
> module in the program, won't that result in an infinite loop?

Is there a reason not to use __init__.py for this?

--
Greg

From greg.ewing at canterbury.ac.nz  Sat Jul 14 04:58:40 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 14 Jul 2007 14:58:40 +1200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>
References: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>
Message-ID: <46983BE0.7040300@canterbury.ac.nz>

Anders J. Munch wrote:

> How about .pyzip instead?  To make it more obvious, and not mistakable for .py.z.

Indeed. Is there any need to restrict extensions to
3 characters these days? Last time I experimented
with this on Windows, it seemed to handle longer
extensions okay.

--
Greg

From andychup at gmail.com  Sat Jul 14 06:38:12 2007
From: andychup at gmail.com (Andy C)
Date: Fri, 13 Jul 2007 21:38:12 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <46983BD9.70702@canterbury.ac.nz>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
	<469695B1.5050107@v.loewis.de>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.com>
	<46983BD9.70702@canterbury.ac.nz>
Message-ID: <596909b30707132138i2d803d04t62555362b3a10cd3@mail.gmail.com>

On 7/13/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Andy C wrote:
> > What does "if __name__ == '__main__" mean in
> > __main__.py?  : )  If someone tries does import __main__ from another
> > module in the program, won't that result in an infinite loop?
>
> Is there a reason not to use __init__.py for this?

Well, you might have multiple executable .py files in the same source
tree.  So then you would want to build multiple .pyz files, each of
which has a different __zipmain__.

I think of __zipmain__ as part of the format of the .pyz file, not
part of the source tree.  In particular, it specifies what
module/function to run in the zipped source tree (and I imagine it
will be adapted for other uses).  In this model you're separating your
development tree and the thing you deploy, which is not always the
case in Python.

Andy

From martin at v.loewis.de  Sat Jul 14 08:32:02 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 14 Jul 2007 08:32:02 +0200
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <077501c7c59f$7c14fa50$090a0a0a@enfoldsystems.local>
References: <077501c7c59f$7c14fa50$090a0a0a@enfoldsystems.local>
Message-ID: <46986DE2.8020204@v.loewis.de>

> As you mention, 64 and 32bit programs use different instruction sets.
> Therefore, trying to use a 64bit install of Python with IIS configured to
> work with 32bits is not going to work.  In this case, switching the
> configuration of IIS will require the Python user to uninstall the previous
> version and install a different version - but some sites may end up in a
> dilemma here - they may be *forced* to use IIS in 32bit mode due to no 64bit
> port for a tool they need, but simultaneously desire a 64bit build of Python
> for other tasks on that same box.

IIUC, you want the AMD64 installer also deploy 32-bit pythonxy.dll etc.
That's a challenge, of course: how would you install the 32-bit
extension modules so that they don't interfere with the 64-bit ones?

> Right - I got the impression from Micheal that it was possible for 32bit
> components to be installed in a 64bit install, but I don't profess to know
> anything about this.

That is true. However, there really isn't anything special about a 32bit
component: the only difference is that Installer turns on file and
registry redirection when installing that component.

You are free to put 32-bit executables into 64-bit components just fine.
(A "component" in MSI is a group of files and registry keys that is
installed together).

Regards,
Martin


From pje at telecommunity.com  Sat Jul 14 15:58:56 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 14 Jul 2007 09:58:56 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <46983BD9.70702@canterbury.ac.nz>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<4695BDE6.8030109@v.loewis.de>
	<596909b30707112346p1a8be426x62625cf422341778@mail.gmail.com>
	<4695E1D3.8080608@v.loewis.de>
	<79990c6b0707120323l3bf81db2j3cd568577b6acc24@mail.gmail.com>
	<469695B1.5050107@v.loewis.de>
	<596909b30707121552k6e3b492ew9a7b9a66ebd3d155@mail.gmail.com>
	<20070712232039.C78BD3A40A9@sparrow.telecommunity.com>
	<596909b30707122113p71afd42ay6be7d61f9c2500e8@mail.gmail.com>
	<46983BD9.70702@canterbury.ac.nz>
Message-ID: <20070714135647.4710F3A404D@sparrow.telecommunity.com>

At 02:58 PM 7/14/2007 +1200, Greg Ewing wrote:
>Andy C wrote:
> > What does "if __name__ == '__main__" mean in
> > __main__.py?  : )  If someone tries does import __main__ from another
> > module in the program, won't that result in an infinite loop?
>
>Is there a reason not to use __init__.py for this?

Even some moderately-experienced Python developers confuse the 
concepts of "package" and "directory containing Python code" -- let's 
not make it worse by encouraging the inclusion of an __init__ module 
in the top-level package namespace!


From ncoghlan at gmail.com  Sat Jul 14 19:28:21 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 15 Jul 2007 03:28:21 +1000
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <fb6fbf560707131009m1704e299m409922e1f29e98d5@mail.gmail.com>
References: <fb6fbf560707131009m1704e299m409922e1f29e98d5@mail.gmail.com>
Message-ID: <469907B5.6030903@gmail.com>

Jim Jewett wrote:
> If anything, I would like to see the -m option enhanced so that if it
> gets a recognized "collection" file type (including a directory or
> zip), it does the right thing.  Whether that actually makes sense, or
> defeats the purpose of the -m shortcut, I'm not sure.

-m deals with the package namespace as it already stands - it knows 
nothing whatsoever about the underlying filesystem (and that's 
deliberate - the runpy module relies on PEP 302 to abstract away all 
those details).

On Phillip's idea regarding being able to execute directories and zip 
files, I think the semantics would actually be manageable (as 
directories and zip files can be definitely identified), but I'd be 
concerned as to the startup cost for checking what is being executed.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From andychup at gmail.com  Sat Jul 14 19:39:19 2007
From: andychup at gmail.com (Andy C)
Date: Sat, 14 Jul 2007 10:39:19 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <fb6fbf560707131009m1704e299m409922e1f29e98d5@mail.gmail.com>
References: <fb6fbf560707131009m1704e299m409922e1f29e98d5@mail.gmail.com>
Message-ID: <596909b30707141039n20c9f8n9c3256bca7a7a857@mail.gmail.com>

On 7/13/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> Andy C wrote:
> >... a .zip file with a __zipmain__.py module at its root?
>
> Why not just an __init__.py, which you would normally execute if you
> tried to import/run a directory?
>
> > * Magically looking at the first argument to see if it's a zip file
> > seems problematic to me.  I'd rather be explicit with the -z flag.
> > Likewise, I'd rather be explicit and call it __zipmain__ rather than
> > __main__.
>
> Treating zip files (and only zip files) as a special case equivalent
> to uncompressed files seems like a wart; I would prefer not to
> special-case zips any more than they already are.

Just to clarify, my patch already works with uncompressed directory
trees just fine.  It's just a matter of naming, I suppose.

I don't mind calling it -z and using it for directories.  But mainly
that's because no one has proprosed another name. : )  I think we've
agreed that -p is something totally different.

> > while I think it would be a bad practice to
> > import __main__,
>
> I have seen it recommended as the right place to store global
> (cross-module) settings.

Where?  People use __main__.py now?  That seems bad, because __ names
are reserved, so they should just use main.py, I would think.

Andy

From fdrake at acm.org  Sat Jul 14 19:55:50 2007
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sat, 14 Jul 2007 13:55:50 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707141039n20c9f8n9c3256bca7a7a857@mail.gmail.com>
References: <fb6fbf560707131009m1704e299m409922e1f29e98d5@mail.gmail.com>
	<596909b30707141039n20c9f8n9c3256bca7a7a857@mail.gmail.com>
Message-ID: <200707141355.50452.fdrake@acm.org>

On Saturday 14 July 2007, Andy C wrote:
 > I don't mind calling it -z and using it for directories.  But mainly
 > that's because no one has proprosed another name. : )  I think we've
 > agreed that -p is something totally different.

We could use -r ("run"), or -X ("execute"); not sure those are really right 
either.

 > > > while I think it would be a bad practice to
 > > > import __main__,
 > >
 > > I have seen it recommended as the right place to store global
 > > (cross-module) settings.
 >
 > Where?  People use __main__.py now?  That seems bad, because __ names
 > are reserved, so they should just use main.py, I would think.

I've seen __main__ suggested as a place to store application-specific global 
settings, but not for a long time.  I don't think it was ever mapped directly 
to a file on disk though.

I find the idea really hackish.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From pje at telecommunity.com  Sat Jul 14 20:04:08 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 14 Jul 2007 14:04:08 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <469907B5.6030903@gmail.com>
References: <fb6fbf560707131009m1704e299m409922e1f29e98d5@mail.gmail.com>
	<469907B5.6030903@gmail.com>
Message-ID: <20070714180155.BE9483A404D@sparrow.telecommunity.com>

At 03:28 AM 7/15/2007 +1000, Nick Coghlan wrote:
>Jim Jewett wrote:
> > If anything, I would like to see the -m option enhanced so that if it
> > gets a recognized "collection" file type (including a directory or
> > zip), it does the right thing.  Whether that actually makes sense, or
> > defeats the purpose of the -m shortcut, I'm not sure.
>
>-m deals with the package namespace as it already stands - it knows
>nothing whatsoever about the underlying filesystem (and that's
>deliberate - the runpy module relies on PEP 302 to abstract away all
>those details).
>
>On Phillip's idea regarding being able to execute directories and zip
>files, I think the semantics would actually be manageable (as
>directories and zip files can be definitely identified), but I'd be
>concerned as to the startup cost for checking what is being executed.

Well, the start file is being opened and checked for directory-ness 
already, and it has to be read to be executed.  The extra reading to 
see if it's a zipfile isn't likely to be much additional overhead.

At this point I've got a partial patch.  It figures out when it 
should import __main__, but it's not successful at actually doing 
so.  It seems that simply importing or reloading '__main__' doesn't 
work, because it's considered a built-in module.  Apparently, I'll 
have to explicitly load the module via the found importer.


From martin at v.loewis.de  Sat Jul 14 23:43:38 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 14 Jul 2007 23:43:38 +0200
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <469829FF.5090403@cryptohorizon.com>
References: <4696A0A8.4090604@v.loewis.de>		<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>		<4696F46F.8090803@cryptohorizon.com>	<9e804ac0707131316t5aa5bbd5sc5a72bfac93fcd7b@mail.gmail.com>
	<469829FF.5090403@cryptohorizon.com>
Message-ID: <4699438A.5010102@v.loewis.de>

> That said, there are always strong arguments in
> favour of the distributed model encouraging and fostering community
> dev participation

Just for the record: Python's development model *is* distributed,
and has been for a long time. We don't all work in the same office,
or even in the same time zone. We rarely meet face-to-face (although
the recent hiring wave at Google has changed some of that - but
then, there also was ZC, BeOpen, CNRI before that).

I really don't think that the non-D aspect of the VCS is a burden to
contribution. Many patches are contributed from the released source,
i.e. without bothering to check out anything, or even from the binary
installation, i.e. without bothering to download and build the source.
People who don't use subversion to get themselves the latest sources to
contribute against won't start doing so if some other system was
used (they are less likely to if they have to learn it first).

Instead, requiring contributors to use the Python VCS would place
a burden, as does the requirement that we already have to contribute
diff files, rather than an edited version of the original file. Also,
having to register with the bugtracker is a burden for some
contributors.

Regards,
Martin

From jimjjewett at gmail.com  Sun Jul 15 00:29:18 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Sat, 14 Jul 2007 18:29:18 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707141039n20c9f8n9c3256bca7a7a857@mail.gmail.com>
References: <fb6fbf560707131009m1704e299m409922e1f29e98d5@mail.gmail.com>
	<596909b30707141039n20c9f8n9c3256bca7a7a857@mail.gmail.com>
Message-ID: <fb6fbf560707141529w497f55fat3152ecb253bcffa8@mail.gmail.com>

On 7/14/07, Andy C <andychup at gmail.com> wrote:
> On 7/13/07, Jim Jewett <jimjjewett at gmail.com> wrote:

> > > while I think it would be a bad practice to
> > > import __main__,

> > I have seen it recommended as the right place to store global
> > (cross-module) settings.

> Where?  People use __main__.py now?

No; they don't use a file.  It is treated as a strictly dynamic
scratchpad, and they do things like

    import __main__
    __main__.DEBUGLEVEL=5
    if __main__.myvar: ...

-jJ

From status at bugs.python.org  Sun Jul 15 02:00:47 2007
From: status at bugs.python.org (Tracker)
Date: Sun, 15 Jul 2007 00:00:47 +0000 (UTC)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20070715000047.E9BC078136@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (07/08/07 - 07/15/07)
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.


 1646 open ( +1) /  8584 closed ( +0) / 10230 total ( +1)

Average duration of open issues: 856 days.
Median duration of open issues: 805 days.

Open Issues Breakdown
   open  1646 ( +1)
pending     0 ( +0)

Issues Created Or Reopened (1)
______________________________

Datetime enhancements                                            07/13/07
       http://bugs.python.org/issue1031    created  FredFlinstone     



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070715/8c61f001/attachment.html 

From dave at cryptohorizon.com  Sun Jul 15 10:57:49 2007
From: dave at cryptohorizon.com (Dave Harrison)
Date: Sun, 15 Jul 2007 18:57:49 +1000
Subject: [Python-Dev] Subversion branch merging
In-Reply-To: <4699438A.5010102@v.loewis.de>
References: <4696A0A8.4090604@v.loewis.de>		<bbaeab100707121454n37c9284boc1727970aa71abaf@mail.gmail.com>		<4696F46F.8090803@cryptohorizon.com>	<9e804ac0707131316t5aa5bbd5sc5a72bfac93fcd7b@mail.gmail.com>
	<469829FF.5090403@cryptohorizon.com> <4699438A.5010102@v.loewis.de>
Message-ID: <4699E18D.5030302@cryptohorizon.com>

Martin v. L?wis wrote:
>> That said, there are always strong arguments in
>> favour of the distributed model encouraging and fostering community
>> dev participation
> 
> Just for the record: Python's development model *is* distributed,
> and has been for a long time. We don't all work in the same office,
> or even in the same time zone. We rarely meet face-to-face (although
> the recent hiring wave at Google has changed some of that - but
> then, there also was ZC, BeOpen, CNRI before that).

Without wanting to have a discussion about the semantics of what it is
to be "distributed", what it seems (to me at least) that you're saying
is that the python community itself is distributed.  That's doesn't
mean that your versioning is distributed.  The model you describe is
very much centralised, where many people submit patches to a central
source repository - otherwise SVN would already be a distributed RCS.
 The model you describe isn't quite the distributed method of
operation where you have many repos that can be pulled and merged
together - I won't attempt to rehash Linus' Google Tech Talk,
  See here : http://www.youtube.com/watch?v=4XpnKHJAok8)
of the distributed model he uses, if only because so many python-dev
members work for Google now ;-)

> I really don't think that the non-D aspect of the VCS is a burden to
> contribution. Many patches are contributed from the released source,
> i.e. without bothering to check out anything, or even from the binary
> installation, i.e. without bothering to download and build the source.

No certainly not, I'm not by any means suggesting that the current way
of handling revision control is having a negative impact.  I also
don't intend to evangelize.  But there are arguments to be put that a
DRCS can promote more involvement by allowing people to checkout and
work on their own copy of the tree.  This way they can cut code in a
controlled environment using commits, reverts, version diffs etc
without the necessity of setting up their own svn repo to commit to,
or needing a sandbox in the python repo.

> People who don't use subversion to get themselves the latest sources to
> contribute against won't start doing so if some other system was
> used (they are less likely to if they have to learn it first).

Generally I agree with you, for bugfixing etc it's unlikely that if
they didn't participate before, an RCS change won't suddenly change
their mind.  That said, I think the number of people that know SVN
beyond update and commit are few and far between as well - I'd suggest
the real distinctions between distributed and non-distributed apps at
this level are virtually nil for such simple use cases.

> Instead, requiring contributors to use the Python VCS would place
> a burden, as does the requirement that we already have to contribute
> diff files, rather than an edited version of the original file. Also,
> having to register with the bugtracker is a burden for some
> contributors.

The learning curve is definitely one of the key impediments to any
change to the RCS used.  The last thing you want to do is cause
unreasonable difficulty for the people who are already contributing to
the project; it's not much use to have encouraged 20 new developers
only to lose 20 existing ones.  But it's worth considering the balance
between costs and benefits, for example being able to branch virtually
instantly without modifying the python.org repository is a big win I'd
think.  Being able to more easily modularise the maintenance and
responsibility load for the source tree is another win, especially as
the size of the tree grows and new efforts such as Py3k begin.

With respect to bugtracking, well that's probably a separate issue
really.  However if there's a way to integrate a bugtracker with my
RCS in a way that lets me create and resolve tickets when I'm offline,
someone please tell me :-)

Cheers
Dave


From aahz at pythoncraft.com  Sun Jul 15 14:58:54 2007
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 15 Jul 2007 05:58:54 -0700
Subject: [Python-Dev] Three-char file extensions
In-Reply-To: <46983BE0.7040300@canterbury.ac.nz>
References: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>
	<46983BE0.7040300@canterbury.ac.nz>
Message-ID: <20070715125854.GA3054@panix.com>

On Sat, Jul 14, 2007, Greg Ewing wrote:
> Anders J. Munch wrote:
>> 
>> How about .pyzip instead?  To make it more obvious, and not
>> mistakable for .py.z.
>
> Indeed. Is there any need to restrict extensions to 3 characters these
> days? Last time I experimented with this on Windows, it seemed to
> handle longer extensions okay.

ARAIK, the only disk fromat that really cares about this which may still
be in widespread use is ISO-9660-formatted CDs without Joliet/Rock Ridge
extensions.  Also, it seems that memory sticks and USB thumb drives are
often formatted with FAT because that's the closest we have to a
universal file format.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

I support the RKAB

From p.f.moore at gmail.com  Sun Jul 15 15:31:18 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 15 Jul 2007 14:31:18 +0100
Subject: [Python-Dev] Three-char file extensions
In-Reply-To: <20070715125854.GA3054@panix.com>
References: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>
	<46983BE0.7040300@canterbury.ac.nz> <20070715125854.GA3054@panix.com>
Message-ID: <79990c6b0707150631l1188cf9dlb956eea7707e9a64@mail.gmail.com>

On 15/07/07, Aahz <aahz at pythoncraft.com> wrote:
> Also, it seems that memory sticks and USB thumb drives are
> often formatted with FAT because that's the closest we have to a
> universal file format.

I think they tend to use FAT32 (the ones I've seen do), which does
support long filenames and more than 3 character extensions.

Paul

From skip at pobox.com  Sun Jul 15 16:08:24 2007
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 15 Jul 2007 09:08:24 -0500
Subject: [Python-Dev] Three-char file extensions
In-Reply-To: <79990c6b0707150631l1188cf9dlb956eea7707e9a64@mail.gmail.com>
References: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>
	<46983BE0.7040300@canterbury.ac.nz>
	<20070715125854.GA3054@panix.com>
	<79990c6b0707150631l1188cf9dlb956eea7707e9a64@mail.gmail.com>
Message-ID: <18074.10840.449851.175467@montanaro.dyndns.org>


    >> Also, it seems that memory sticks and USB thumb drives are often
    >> formatted with FAT because that's the closest we have to a universal
    >> file format.

    Paul> I think they tend to use FAT32 (the ones I've seen do), which does
    Paul> support long filenames and more than 3 character extensions.

I'd check with the guys doing the Portable Python and Movable Python stuff
to see if they see >-three-char extensions as a problem.

    http://www.portablepython.com/
    http://www.voidspace.org.uk/python/movpy/

They both seem to be Window-centric so they've pretty much been off my radar
screen.

Skip

From tjreedy at udel.edu  Sun Jul 15 20:39:39 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 15 Jul 2007 14:39:39 -0400
Subject: [Python-Dev] Three-char file extensions
References: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net><46983BE0.7040300@canterbury.ac.nz>
	<20070715125854.GA3054@panix.com>
Message-ID: <f7dplc$he2$1@sea.gmane.org>

For me, .pyz is fine.  Python has more or less a trademark on .pyx 
extensions, and one more fits well.  I think we should stick with them.

Confusion of .pyz with .py.z is not an issue with Windows users, though I 
can understand how it might be for *nix users.  On the other hand, pyzip is 
quite similar (too similar?) to pkzip.

tjr




From scott+python-dev at scottdial.com  Sun Jul 15 20:54:34 2007
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Sun, 15 Jul 2007 14:54:34 -0400
Subject: [Python-Dev] Three-char file extensions
In-Reply-To: <79990c6b0707150631l1188cf9dlb956eea7707e9a64@mail.gmail.com>
References: <9B1795C95533CA46A83BA1EAD4B01030031FA5@flonidanmail.flonidan.net>	<46983BE0.7040300@canterbury.ac.nz>
	<20070715125854.GA3054@panix.com>
	<79990c6b0707150631l1188cf9dlb956eea7707e9a64@mail.gmail.com>
Message-ID: <469A6D6A.1000305@scottdial.com>

Paul Moore wrote:
> On 15/07/07, Aahz <aahz at pythoncraft.com> wrote:
>> Also, it seems that memory sticks and USB thumb drives are
>> often formatted with FAT because that's the closest we have to a
>> universal file format.
> 
> I think they tend to use FAT32 (the ones I've seen do), which does
> support long filenames and more than 3 character extensions.
> 

In general, this is not true. FAT16 can address a 2GB device and I can 
think of at least one embedded system I am working with that does not 
support FAT32. If anything, at least .pyzip reduces to .pyz in 8dot3 
(whereas .py.z reduces to .z *yikes!*). However, I think it is still 
best practice to aim for 8dot3 naming.

-Scott

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From ajm at flonidan.dk  Mon Jul 16 11:19:18 2007
From: ajm at flonidan.dk (Anders J. Munch)
Date: Mon, 16 Jul 2007 11:19:18 +0200
Subject: [Python-Dev] Three-char file extensions
Message-ID: <9B1795C95533CA46A83BA1EAD4B01030031FA6@flonidanmail.flonidan.net>

Scott Dial wrote:
> In general, this is not true. FAT16 can address a 2GB device and I can 
> think of at least one embedded system I am working with that does not 
> support FAT32. If anything, at least .pyzip reduces to .pyz in 8dot3 
> (whereas .py.z reduces to .z *yikes!*). However, I think it is still 
> best practice to aim for 8dot3 naming.

The three-letter extension namespace is very small and heavily
overloaded.  There's no such thing as a previously unused three-letter
extension; it's bound to conflict with something, even if we don't
know what it is.  It's not best practice to restrict yourself to
short, cryptic, ambiguous names unless you have to.

For stuff hardwired into the interpreter, I agree it's safer to stick
with 8+3.  But this is just the default association created by the
installer.  If it's creating problems, you can always rename your
files to .pyz or whatever you like and create an association for that.

I'm a little surprised that people are suffering 8+3 names on their
usb drives in this day and age still.  I suppose if I had to deal with
that, I would just zip/tar up my long-file-named files in an 8+3-named
archive.  And since a .pyz-file is just such an archive, I concede the
point and withdraw my suggestion.

- Anders

From mhammond at skippinet.com.au  Wed Jul 18 08:25:13 2007
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Wed, 18 Jul 2007 16:25:13 +1000
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <469791C5.2040705@v.loewis.de>
Message-ID: <0a4301c7c904$669bb0c0$090a0a0a@enfoldsystems.local>

Hi Martin,

> I found the same thing, and put a corrected installer at
>
> http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi

Is there any intention to update the msi at python.org?  Alternatively, can
I point people at the above file?  I've a .msi created by bdist_msi that
works only with the corrected version and I'm wondering the best way to get
people to test it...

Cheers,

Mark.


From kbk at shore.net  Wed Jul 18 08:30:16 2007
From: kbk at shore.net (Kurt B. Kaiser)
Date: Wed, 18 Jul 2007 02:30:16 -0400 (EDT)
Subject: [Python-Dev] Weekly Python Patch/Bug Summary
Message-ID: <200707180630.l6I6UGld029215@hampton.thirdcreek.com>

Patch / Bug Summary
___________________

Patches :  394 open ( +2) /  3827 closed (+35) /  4221 total (+37)
Bugs    : 1046 open ( +4) /  6773 closed (+16) /  7819 total (+20)
RFE     :  262 open ( -1) /   293 closed ( +1) /   555 total ( +0)

New / Reopened Patches
______________________

make build_opener raise exception when not passed a handler  (2007-07-10)
CLOSED http://python.org/sf/1750931  opened by  Robert Renaud

struni: fix for test_cmd_line  (2007-07-10)
CLOSED http://python.org/sf/1751493  opened by  Christian Heimes

struni: Replace assert_(==) with failUnlessEqual  (2007-07-11)
CLOSED http://python.org/sf/1751515  opened by  Christian Heimes

curses - new window methods: addchstr and addchnstr  (2007-07-11)
       http://python.org/sf/1751519  opened by  Wojciech Mula

Dict comprehensions  (2007-07-11)
CLOSED http://python.org/sf/1751800  opened by  Thomas Wouters

Patch for Windows build  (2007-07-11)
CLOSED http://python.org/sf/1751801  opened by  Thomas Heller

struni: gettext fixes  (2007-07-11)
CLOSED http://python.org/sf/1751958  opened by  Christian Heimes

Typo in Lib/lib-tk/ScrolledText.py  (2007-07-11)
CLOSED http://python.org/sf/1751965  opened by  Ali Gholami Rudi

opcode.h incorrectly describes arg of SETUP_*  (2007-07-11)
CLOSED http://python.org/sf/1752132  opened by  Christopher Tur Lesniewski-Laas

Use the bytes type in asynchat  (2007-07-11)
CLOSED http://python.org/sf/1752173  opened by  Alexandre Vassalotti

fixing 2.5.1 build with unicode and dynamic loading disabled  (2007-07-11)
       http://python.org/sf/1752175  opened by  Alexander Neundorf

PyHeapTypeObject fix  (2007-07-11)
       http://python.org/sf/1752184  opened by  Thomas Heller

struni: for for poll, pep263, bigmem and a bit pickletool   (2007-07-11)
CLOSED http://python.org/sf/1752195  opened by  Christian Heimes

struni: _fileio fixes for Windows  (2007-07-11)
CLOSED http://python.org/sf/1752225  opened by  Amaury Forgeot d'Arc

Use the Unicode API in dlmodule.c  (2007-07-11)
CLOSED http://python.org/sf/1752229  opened by  Alexandre Vassalotti

urllib2 1750931 alternative patch  (2007-07-12)
CLOSED http://python.org/sf/1752270  opened by  John J Lee

reference leak in _PyUnicode_AsDefaultEncodedString  (2007-07-12)
CLOSED http://python.org/sf/1752317  opened by  Amaury Forgeot d'Arc

getaddrinfo no longer used in httplib  (2007-07-12)
       http://python.org/sf/1752332  opened by  John J Lee

fix failing unit tests in mmap in struni branch  (2007-07-12)
CLOSED http://python.org/sf/1752647  opened by  Joe Gregorio

chown() does not handle UID > INT_MAX  (2007-07-12)
       http://python.org/sf/1752703  opened by  Andrew Ferguson

Add RegEnableReflectionKey and RegDisableReflectionKey  (2007-07-13)
       http://python.org/sf/1753245  opened by  Mark Hammond

Lib/regrtest.py -x 'test_xxx' does not work  (2007-07-13)
CLOSED http://python.org/sf/1753310  opened by  Thomas Heller

test_urllib2.test_fie passes  (2007-07-13)
CLOSED http://python.org/sf/1753889  opened by  Hasan Diwan

Tighter co_stacksize computation in stackdepth_walk  (2007-07-14)
       http://python.org/sf/1754094  opened by  Christopher Tur Lesniewski-Laas

Deprecation warning for `backticks`  (2007-07-15)
       http://python.org/sf/1754271  opened by  Tom Lee

Deprecation warning for <> (NOTEQUAL)  (2007-07-15)
       http://python.org/sf/1754273  opened by  Tom Lee

struni: Bytes support for TextIOWrapper.write()   (2007-07-15)
CLOSED http://python.org/sf/1754339  opened by  Christian Heimes

linecache package handling  (2007-07-15)
       http://python.org/sf/1754483  opened by  Kevin Goodsell

struni: Various patches for windows  (2007-07-16)
CLOSED http://python.org/sf/1754484  opened by  Amaury Forgeot d'Arc

Non-portable address length calculation for AF_UNIX sockets  (2007-07-16)
       http://python.org/sf/1754489  opened by  Vlado Handziski

urllib2 tests pass  (2007-07-16)
       http://python.org/sf/1755133  opened by  Hasan Diwan

struni: corrections for test_cProfile  (2007-07-17)
CLOSED http://python.org/sf/1755176  opened by  Amaury Forgeot d'Arc

struni: corrections in ftplib  (2007-07-17)
CLOSED http://python.org/sf/1755206  opened by  Amaury Forgeot d'Arc

struni: correction for sockets on win32  (2007-07-17)
CLOSED http://python.org/sf/1755214  opened by  Amaury Forgeot d'Arc

struni: correction for _winreg module  (2007-07-17)
CLOSED http://python.org/sf/1755229  opened by  Amaury Forgeot d'Arc

Patch for [ 735515 ] urllib2 should cache 301 redir  (2007-07-18)
       http://python.org/sf/1755841  opened by  O.R.Senthil Kumaran

Show Location of Unicode Escape Errors  (2007-07-18)
       http://python.org/sf/1755885  opened by  Kurt B. Kaiser

Patches Closed
______________

make build_opener raise exception when not passed a handler  (2007-07-10)
       http://python.org/sf/1750931  closed by  gbrandl

struni: fix for test_cmd_line  (2007-07-10)
       http://python.org/sf/1751493  closed by  gvanrossum

struni: Replace assert_(==) with failUnlessEqual  (2007-07-10)
       http://python.org/sf/1751515  closed by  gvanrossum

Dict comprehensions  (2007-07-11)
       http://python.org/sf/1751800  closed by  twouters

Patch for Windows build  (2007-07-11)
       http://python.org/sf/1751801  closed by  theller

Patch for PEP 3109  (2007-05-06)
       http://python.org/sf/1713889  closed by  gvanrossum

Implementation of @abstractmethod for PEP 3119  (2007-04-24)
       http://python.org/sf/1706989  closed by  gvanrossum

struni: gettext fixes  (2007-07-11)
       http://python.org/sf/1751958  closed by  gvanrossum

Typo in Lib/lib-tk/ScrolledText.py  (2007-07-11)
       http://python.org/sf/1751965  closed by  gbrandl

opcode.h incorrectly describes arg of SETUP_*  (2007-07-11)
       http://python.org/sf/1752132  closed by  gbrandl

Use the bytes type in asynchat  (2007-07-11)
       http://python.org/sf/1752173  closed by  gvanrossum

struni: for for poll, pep263, bigmem and a bit pickletool   (2007-07-11)
       http://python.org/sf/1752195  closed by  gvanrossum

struni: _fileio fixes for Windows  (2007-07-11)
       http://python.org/sf/1752225  closed by  theller

Use the Unicode API in dlmodule.c  (2007-07-11)
       http://python.org/sf/1752229  closed by  gvanrossum

urllib2 1750931 alternative patch  (2007-07-11)
       http://python.org/sf/1752270  closed by  gbrandl

reference leak in _PyUnicode_AsDefaultEncodedString  (2007-07-11)
       http://python.org/sf/1752317  closed by  gvanrossum

binary and new-style octal literals  (2007-03-14)
       http://python.org/sf/1681002  closed by  twouters

Patch inspect.py for IronPython / Jython Compatibility  (2007-06-19)
       http://python.org/sf/1739696  closed by  gbrandl

Fix selectmodule.c compilation on GNU/Hurd  (2007-06-11)
       http://python.org/sf/1735030  closed by  gbrandl

Patch to vs 2005 build  (2007-05-26)
       http://python.org/sf/1726195  closed by  gbrandl

Datetime enhancements  (2007-02-21)
       http://python.org/sf/1665292  closed by  gbrandl

'%G' string formatting doesn't catch same errors as '%g'  (2007-03-05)
       http://python.org/sf/1673759  closed by  gbrandl

Improve doc for time.strptime  (2007-06-05)
       http://python.org/sf/1731659  closed by  gbrandl

Expect skips by platform  (2007-06-05)
       http://python.org/sf/1731169  closed by  gbrandl

Zipfile tweaks and test coverage improvement  (2007-03-07)
       http://python.org/sf/1675424  closed by  gbrandl

fix failing unit tests in mmap in struni branch  (2007-07-12)
       http://python.org/sf/1752647  closed by  gvanrossum

Lib/regrtest.py -x 'test_xxx' does not work  (2007-07-13)
       http://python.org/sf/1753310  closed by  gbrandl

test_urllib2.test_fie passes  (2007-07-13)
       http://python.org/sf/1753889  closed by  gvanrossum

struni: Bytes support for TextIOWrapper.write()   (2007-07-15)
       http://python.org/sf/1754339  closed by  gvanrossum

struni: Various patches for windows  (2007-07-15)
       http://python.org/sf/1754484  closed by  gvanrossum

struni: corrections for test_cProfile  (2007-07-16)
       http://python.org/sf/1755176  closed by  gvanrossum

struni: corrections in ftplib  (2007-07-16)
       http://python.org/sf/1755206  closed by  gvanrossum

struni: correction for sockets on win32  (2007-07-16)
       http://python.org/sf/1755214  closed by  gvanrossum

struni: correction for _winreg module  (2007-07-16)
       http://python.org/sf/1755229  closed by  gvanrossum

New / Reopened Bugs
___________________

Popen pipe file descriptor leak on OSError in init  (2007-07-10)
       http://python.org/sf/1751245  opened by  Justin Francis

struni: str() doesn't call __str__() of subclasses of str  (2007-07-11)
       http://python.org/sf/1751598  opened by  Christian Heimes

struni: Three ctypes tests are SEGFAULTing  (2007-07-11)
CLOSED http://python.org/sf/1751885  opened by  Christian Heimes

struni: help() is broken  (2007-07-11)
       http://python.org/sf/1751932  opened by  Christian Heimes

tkFileDialog closes Python when used  (2007-07-11)
       http://python.org/sf/1752252  opened by  ferrari24

RotatingFileHandler.doRollover behave wrong vs. log4j's  (2007-07-12)
       http://python.org/sf/1752539  opened by  Jin Qing

email.message_from_string: initial line gets discarded  (2007-07-12)
CLOSED http://python.org/sf/1752723  opened by  David Webster

Exception in HTMLParser for special JavaScript code  (2007-07-12)
       http://python.org/sf/1752919  opened by  Eugine Kosenko

Open always create new tab or new browser  (2007-07-13)
       http://python.org/sf/1753371  opened by  Ilan Peleg

struni: assertion in Windows debug build  (2007-07-13)
       http://python.org/sf/1753395  opened by  Thomas Heller

subprocess.check_call() new in 2.5  (2007-07-13)
CLOSED http://python.org/sf/1753406  opened by  Yitz Gale

base64 "legacy" functions violate RFC 3548  (2007-07-13)
       http://python.org/sf/1753718  opened by  Paul Winkler

xmlrpclib.Binary doesn't say which base64 spec it implements  (2007-07-13)
       http://python.org/sf/1753732  opened by  Paul Winkler

subprocess raising "No Child Process" OSError  (2007-07-13)
       http://python.org/sf/1753891  opened by  slowfood

Docstring for codecs.lookup is incorrect  (2007-07-15)
       http://python.org/sf/1754453  opened by  Omari Norman

"yield" causes strange behaviour  (2007-07-16)
CLOSED http://python.org/sf/1754456  opened by  Miki Tebeka

subprocess.Popen.wait fails sporadically with threads  (2007-07-16)
       http://python.org/sf/1754642  opened by  Geoffrey Bache

document default values for sort parameters  (2007-07-16)
       http://python.org/sf/1755097  opened by  Ilya Sandler

subprocess raising "No Child Process" OSError  (2007-07-16)
CLOSED http://python.org/sf/1755150  opened by  slowfood

Deadlocks with fork() and multithreading  (2007-07-16)
       http://python.org/sf/1755179  opened by  Vanco Buca

Problem with socket.gethostbyaddr() and KeyboardInterrupt  (2007-07-17)
       http://python.org/sf/1755388  opened by  STINNER Victor

Bugs Closed
___________

Bad documentation of SMTPException  (2007-04-05)
       http://python.org/sf/1694950  closed by  quiver

Python-2.5.1.tar.bz2 build failed at Centos-4.5 server  (2007-06-17)
       http://python.org/sf/1738559  closed by  loewis

os.getlogin should use the DISPLAY and not the tty  (2007-07-08)
       http://python.org/sf/1750013  closed by  loewis

struni: Three ctypes tests are SEGFAULTing  (2007-07-11)
       http://python.org/sf/1751885  closed by  tiran

string and unicode formatting are missing a test for "G"  (2007-03-05)
       http://python.org/sf/1673757  closed by  gbrandl

PCbuild8/pcbuild.sln is missing "_socket" sub-project  (2007-04-15)
       http://python.org/sf/1700865  closed by  gbrandl

test_sqlite fails on OSX G5 arch if test_ctypes is run  (2006-10-21)
       http://python.org/sf/1581906  closed by  theller

email.message_from_string: initial line gets discarded  (2007-07-12)
       http://python.org/sf/1752723  closed by  bwarsaw

IDE needs to remember status of interactive window  (2003-06-22)
       http://python.org/sf/758565  closed by  ronaldoussoren

subprocess.check_call() new in 2.5  (2007-07-13)
       http://python.org/sf/1753406  closed by  gbrandl

Segfault in c_char_p of ctypes  (2007-04-16)
       http://python.org/sf/1701409  closed by  theller

non-standard: array[0]  (2007-01-31)
       http://python.org/sf/1649098  closed by  theller

ctypes: problem with large integers  (2007-04-19)
       http://python.org/sf/1703952  closed by  theller

ctypes documenation obscure and incomplete  (2006-05-09)
       http://python.org/sf/1484580  closed by  theller

Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)  (2006-07-26)
       http://python.org/sf/1529269  closed by  theller

"yield" causes strange behaviour  (2007-07-16)
       http://python.org/sf/1754456  closed by  tebeka

subprocess raising "No Child Process" OSError  (2007-07-16)
       http://python.org/sf/1755150  deleted by  slowfood

RFE Closed
__________

if __name__=='__main__' missing in tutorial  (2007-01-17)
       http://python.org/sf/1637365  closed by  gbrandl


From ironfroggy at gmail.com  Wed Jul 18 14:37:13 2007
From: ironfroggy at gmail.com (Calvin Spealman)
Date: Wed, 18 Jul 2007 08:37:13 -0400
Subject: [Python-Dev] Sorry About Summaries
Message-ID: <76fd5acf0707180537t7e49dc28h8706f595ed3a8acf@mail.gmail.com>

I completely intend to finish the backlog of summaries, but I've
reached the point that I know it is futile to continue thinking I'll
be able to fit in the time for the summaries in an on-going and
reliable manner. When I took on the responsibility, it was looking
like time would be fine. Since then, I had to move, my work load has
at least tripled, children prove more time consumer once they learn to
walk, and I'm even having to look at the possibility of expanding
beyond a one-man operation.

When I took the position, I had the time. My situation only lasted
that way for a couple weeks. Every time I think it will change,
something else happens. At this point, I can't keep fooling myself.
But, as I said, I absolutely will be finishing the summaries I have
not done, to make up for my mistakes with this. I haven't even had the
time to read python-dev during all these months, much less write about
them.

Becoming involved with the upcoming Python Magazine is just the
evidence I needed that my life is not as care free as it was when I
thought I could make time for this.

Is anyone interested in taking the (much dwindled) flame from my unable hands?

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/

From brett at python.org  Wed Jul 18 20:57:35 2007
From: brett at python.org (Brett Cannon)
Date: Wed, 18 Jul 2007 11:57:35 -0700
Subject: [Python-Dev] Sorry About Summaries
In-Reply-To: <76fd5acf0707180537t7e49dc28h8706f595ed3a8acf@mail.gmail.com>
References: <76fd5acf0707180537t7e49dc28h8706f595ed3a8acf@mail.gmail.com>
Message-ID: <bbaeab100707181157p2ee070ebt245aa971615e1a0f@mail.gmail.com>

On 7/18/07, Calvin Spealman <ironfroggy at gmail.com> wrote:
> I completely intend to finish the backlog of summaries, but I've
> reached the point that I know it is futile to continue thinking I'll
> be able to fit in the time for the summaries in an on-going and
> reliable manner. When I took on the responsibility, it was looking
> like time would be fine. Since then, I had to move, my work load has
> at least tripled, children prove more time consumer once they learn to
> walk, and I'm even having to look at the possibility of expanding
> beyond a one-man operation.
>
> When I took the position, I had the time. My situation only lasted
> that way for a couple weeks. Every time I think it will change,
> something else happens. At this point, I can't keep fooling myself.
> But, as I said, I absolutely will be finishing the summaries I have
> not done, to make up for my mistakes with this. I haven't even had the
> time to read python-dev during all these months, much less write about
> them.

I wouldn't worry about trying to catch up, Calvin.  I am sure people
are appreciative you just tried to take on the load.

-Brett

From martin at v.loewis.de  Thu Jul 19 00:02:24 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 19 Jul 2007 00:02:24 +0200
Subject: [Python-Dev] Registry keys written by x64 installer
In-Reply-To: <0a4301c7c904$669bb0c0$090a0a0a@enfoldsystems.local>
References: <0a4301c7c904$669bb0c0$090a0a0a@enfoldsystems.local>
Message-ID: <469E8DF0.5000101@v.loewis.de>

> Hi Martin,
> 
>> I found the same thing, and put a corrected installer at
>>
>> http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi
> 
> Is there any intention to update the msi at python.org?

No. I would have to bump the version number for that, which I cannot
do - it will need to wait for 2.5.2.

> Alternatively, can I point people at the above file?

That's certainly fine. I can leave the file in place at least until
2.5.2 is released (although I will eventually remove it, to reduce
confusion).

Regards,
Martin

From nnorwitz at gmail.com  Fri Jul 20 01:52:32 2007
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 19 Jul 2007 16:52:32 -0700
Subject: [Python-Dev] Python sprint at Google
Message-ID: <ee2a432c0707191652n439abedao5641d8d8b6519a45@mail.gmail.com>

It's about that time of year again.  We are starting to organize
Python sprints again this year hosted at Google (ie, there was a 5
minute conversation and a couple of emails).  Nothing has solidified
yet, but here are our ideas:

 * Hosted at Google's headquarters in Mountain View, CA USA
 * From Wed, Aug 22 to Sat Aug 25 (4 days)
 * Cost: free, but need to code for food and internet :-)

How does that work for people?  You can attend for as little or as
much time as you want. I expect most people will focus on py3k--the
core language changes as well as tools to support the transition.

We'd like to start figuring out how many people would be attending.
If you are interested, please mail me privately.  You don't need to
commit to anything.  Just how likely you are to attend.  Could someone
update the wiki we used for last years sprints:
http://wiki.python.org/moin/GoogleSprint

If you would be interested in other locations/dates, let me know.  I
don't know that we can accommodate anything else, but we can try.

Cheers,
n

From 00ai99 at gmail.com  Fri Jul 20 09:11:56 2007
From: 00ai99 at gmail.com (David Gowers)
Date: Fri, 20 Jul 2007 16:41:56 +0930
Subject: [Python-Dev] PyGEGL instant crash (Python regression?)
Message-ID: <23f4e3390707200011q41af8a83sa2675412e030ba84@mail.gmail.com>

Has anyone tried PyGEGL, the Python interface to gegl (www.gegl.org),
with SVN Python?
When I 'import gegl', that causes an immediate crash with the
following backtrace.

----
babl-db.c:100 babl_db_insert()
       Eeeeek
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1210014016 (LWP 30914)]
0xffffe410 in __kernel_vsyscall ()
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e97933 in waitpid () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e413c9 in strtold_l () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7f6e7dd in system () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb6e93df4 in babl_backtrack () at babl-internal.c:68
#5  0xb6e93e15 in babl_die () at babl-internal.c:74
#6  0xb6e8d352 in babl_db_insert (db=0x0, item=0x82bbff8) at babl-db.c:100
#7  0xb6e968be in babl_type_new (first_arg=0xb6ef90d6) at babl-type.c:135
#8  0xb6ef7dea in init () at CIE-Lab.c:427
#9  0xb7b191b3 in babl_extension_init () at babl-extension.c:194
#10 0xb7b16a2f in babl_init () at babl.c:40
#11 0xb7b3630e in gegl_post_parse_hook (context=0x0, group=0x0,
data=0x0, error=0x0)
   at gegl-init.c:199
#12 0xb7b364d5 in gegl_init (argc=0xbffa1038, argv=0xbffa1034) at gegl-init.c:73
#13 0xb7f8494d in pygegl_register_classes (d=0xb7d27714) at gegl.override:139
#14 0xb7f82f21 in initgegl () at geglmodule.c:57
#15 0x080d742f in _PyImport_LoadDynamicModule (name=0xbffa2177 "gegl",
   pathname=0xbffa1103
"/usr/lib/python2.6/site-packages/geglmodule.so", fp=0xfffffe00)
   at ./Python/importdl.c:53
#16 0x080d5327 in load_module (name=0xbffa2177 "gegl", fp=0x0,
   buf=0xbffa1103 "/usr/lib/python2.6/site-packages/geglmodule.so", type=3,
   loader=0xbffa0974) at Python/import.c:1752
#17 0x080d578c in import_submodule (mod=0x81343c0, subname=0xbffa2177 "gegl",
   fullname=0xbffa2177 "gegl") at Python/import.c:2394
#18 0x080d59d1 in load_next (mod=0x81343c0, altmod=0x81343c0,
p_name=<value optimized out>,
   buf=0xbffa2177 "gegl", p_buflen=0xbffa3178) at Python/import.c:2214
#19 0x080d5e0d in import_module_level (name=0x0, globals=0xb7de2acc,
   locals=<value optimized out>, fromlist=0x81343c0, level=-1) at
Python/import.c:1995
#20 0x080d62de in PyImport_ImportModuleLevel (name=0xb7d23374 "gegl",
globals=0xb7de2acc,
   locals=0xb7de2acc, fromlist=0xfffffe00, level=-512) at Python/import.c:2066
#21 0x080b5658 in builtin___import__ (self=0x0, args=0xfffffe00,
kwds=0xfffffe00)c:1995
   at Python/bltinmodule.c:47
#22 0x0805a8ac in PyObject_Call (func=0xbffa0974, arg=0xfffffe00, kw=0xfffffe00)
   at Objects/abstract.c:1860
#23 0x080b9c39 in PyEval_CallObjectWithKeywords (func=0xfffffe00,
arg=0xb7ddecac, kw=0x0)
   at Python/ceval.c:3433
#24 0x080bc631 in PyEval_EvalFrameEx (f=0x81ebf24, throwflag=0) at
Python/ceval.c:2071
#25 0x080c133f in PyEval_EvalCodeEx (co=0xb7d9d968,
globals=0xb7de2acc, locals=0xb7de2acc,
   args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
   at Python/ceval.c:2840
#26 0x080c14c6 in PyEval_EvalCode (co=0xfffffe00, globals=0xfffffe00,
locals=0xfffffe00)
   at Python/ceval.c:493
#27 0x080df9dc in PyRun_InteractiveOneFlags (fp=0xfffffe00,
filename=0x8116d6e "<stdin>",
   flags=0xbffa3688) at Python/pythonrun.c:1293
#28 0x080dfbd0 in PyRun_InteractiveLoopFlags (fp=0xb7f37240,
filename=0x8116d6e "<stdin>",
   flags=0xbffa3688) at Python/pythonrun.c:723
#29 0x080e030b in PyRun_AnyFileExFlags (fp=0xb7f37240,
filename=0x8116d6e "<stdin>",
   closeit=0, flags=0xbffa3688) at Python/pythonrun.c:692
#30 0x08056dad in Py_Main (argc=0, argv=0xbffa3724) at Modules/main.c:527
#31 0xb7e20ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#32 0x08056251 in _start () at ../sysdeps/i386/elf/start.S:119
----

I'm pretty sure that the bug lies in either Python or the pygegl module, as I've
ran the babl and gegl tests successfully (and the gegl editor
works okay too)

(btw, this is with both SVN python and SVN gegl -- PyGEGL is included
in the gegl repository; in order to test this, you might also need the
SVN version of babl. Lastly, in the gegl tree, you can find PyGEGL
source in the bindings/pygegl/ dir.)

I posted this report originally to the gegl-developer list.

Kevin Cozens, the PyGEGL maintainer, said:
> I have only tested pyGEGL with the 2.4 version of Python. It possible (or very
> likely?) that something has changed in the 2.6 version of Python. I don't have
> the 2.6 version installed at the moment so I can't investigate this further.

Sven Neumann said:
> Have you contacted the python developers then? This looks a lot like a
> regression in Python and I guess they would like to hear about it before
> the release the next version.

Hence I'm posting it here. Perhaps someone can shed some light on what
is happening here?

From jcarlson at uci.edu  Fri Jul 20 10:26:13 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Fri, 20 Jul 2007 01:26:13 -0700
Subject: [Python-Dev] PyGEGL instant crash (Python regression?)
In-Reply-To: <23f4e3390707200011q41af8a83sa2675412e030ba84@mail.gmail.com>
References: <23f4e3390707200011q41af8a83sa2675412e030ba84@mail.gmail.com>
Message-ID: <20070720011912.85AA.JCARLSON@uci.edu>


"David Gowers" <00ai99 at gmail.com> wrote:
> Has anyone tried PyGEGL, the Python interface to gegl (www.gegl.org),
> with SVN Python?
> When I 'import gegl', that causes an immediate crash with the
> following backtrace.

I would wager a beer or two that the issue is in the wrapping of gegl.
Having recently started wrapping modules by hand and with Swig, I have
come to notice that making a mistake with refcounts can lead to
segfaults like you are seeing.  If you are getting that immediately upon
import, you may want to check to make sure that the function that is
initializing your module (typically something like init_gegl) is doing
the right things (I can't really offer any suggestions on what to check
for, I literally only started wrapping stuff by hand yesterday;
previously I used Pyrex, which can handle all refcounts for you if
desired).


 - Josiah


> 
> ----
> babl-db.c:100 babl_db_insert()
>        Eeeeek
> Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
> [Thread debugging using libthread_db enabled]
> [New Thread -1210014016 (LWP 30914)]
> 0xffffe410 in __kernel_vsyscall ()
> #0  0xffffe410 in __kernel_vsyscall ()
> #1  0xb7e97933 in waitpid () from /lib/tls/i686/cmov/libc.so.6
> #2  0xb7e413c9 in strtold_l () from /lib/tls/i686/cmov/libc.so.6
> #3  0xb7f6e7dd in system () from /lib/tls/i686/cmov/libpthread.so.0
> #4  0xb6e93df4 in babl_backtrack () at babl-internal.c:68
> #5  0xb6e93e15 in babl_die () at babl-internal.c:74
> #6  0xb6e8d352 in babl_db_insert (db=0x0, item=0x82bbff8) at babl-db.c:100
> #7  0xb6e968be in babl_type_new (first_arg=0xb6ef90d6) at babl-type.c:135
> #8  0xb6ef7dea in init () at CIE-Lab.c:427
> #9  0xb7b191b3 in babl_extension_init () at babl-extension.c:194
> #10 0xb7b16a2f in babl_init () at babl.c:40
> #11 0xb7b3630e in gegl_post_parse_hook (context=0x0, group=0x0,
> data=0x0, error=0x0)
>    at gegl-init.c:199
> #12 0xb7b364d5 in gegl_init (argc=0xbffa1038, argv=0xbffa1034) at gegl-init.c:73
> #13 0xb7f8494d in pygegl_register_classes (d=0xb7d27714) at gegl.override:139
> #14 0xb7f82f21 in initgegl () at geglmodule.c:57
> #15 0x080d742f in _PyImport_LoadDynamicModule (name=0xbffa2177 "gegl",
>    pathname=0xbffa1103
> "/usr/lib/python2.6/site-packages/geglmodule.so", fp=0xfffffe00)
>    at ./Python/importdl.c:53
> #16 0x080d5327 in load_module (name=0xbffa2177 "gegl", fp=0x0,
>    buf=0xbffa1103 "/usr/lib/python2.6/site-packages/geglmodule.so", type=3,
>    loader=0xbffa0974) at Python/import.c:1752
> #17 0x080d578c in import_submodule (mod=0x81343c0, subname=0xbffa2177 "gegl",
>    fullname=0xbffa2177 "gegl") at Python/import.c:2394
> #18 0x080d59d1 in load_next (mod=0x81343c0, altmod=0x81343c0,
> p_name=<value optimized out>,
>    buf=0xbffa2177 "gegl", p_buflen=0xbffa3178) at Python/import.c:2214
> #19 0x080d5e0d in import_module_level (name=0x0, globals=0xb7de2acc,
>    locals=<value optimized out>, fromlist=0x81343c0, level=-1) at
> Python/import.c:1995
> #20 0x080d62de in PyImport_ImportModuleLevel (name=0xb7d23374 "gegl",
> globals=0xb7de2acc,
>    locals=0xb7de2acc, fromlist=0xfffffe00, level=-512) at Python/import.c:2066
> #21 0x080b5658 in builtin___import__ (self=0x0, args=0xfffffe00,
> kwds=0xfffffe00)c:1995
>    at Python/bltinmodule.c:47
> #22 0x0805a8ac in PyObject_Call (func=0xbffa0974, arg=0xfffffe00, kw=0xfffffe00)
>    at Objects/abstract.c:1860
> #23 0x080b9c39 in PyEval_CallObjectWithKeywords (func=0xfffffe00,
> arg=0xb7ddecac, kw=0x0)
>    at Python/ceval.c:3433
> #24 0x080bc631 in PyEval_EvalFrameEx (f=0x81ebf24, throwflag=0) at
> Python/ceval.c:2071
> #25 0x080c133f in PyEval_EvalCodeEx (co=0xb7d9d968,
> globals=0xb7de2acc, locals=0xb7de2acc,
>    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
>    at Python/ceval.c:2840
> #26 0x080c14c6 in PyEval_EvalCode (co=0xfffffe00, globals=0xfffffe00,
> locals=0xfffffe00)
>    at Python/ceval.c:493
> #27 0x080df9dc in PyRun_InteractiveOneFlags (fp=0xfffffe00,
> filename=0x8116d6e "<stdin>",
>    flags=0xbffa3688) at Python/pythonrun.c:1293
> #28 0x080dfbd0 in PyRun_InteractiveLoopFlags (fp=0xb7f37240,
> filename=0x8116d6e "<stdin>",
>    flags=0xbffa3688) at Python/pythonrun.c:723
> #29 0x080e030b in PyRun_AnyFileExFlags (fp=0xb7f37240,
> filename=0x8116d6e "<stdin>",
>    closeit=0, flags=0xbffa3688) at Python/pythonrun.c:692
> #30 0x08056dad in Py_Main (argc=0, argv=0xbffa3724) at Modules/main.c:527
> #31 0xb7e20ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
> #32 0x08056251 in _start () at ../sysdeps/i386/elf/start.S:119
> ----
> 
> I'm pretty sure that the bug lies in either Python or the pygegl module, as I've
> ran the babl and gegl tests successfully (and the gegl editor
> works okay too)
> 
> (btw, this is with both SVN python and SVN gegl -- PyGEGL is included
> in the gegl repository; in order to test this, you might also need the
> SVN version of babl. Lastly, in the gegl tree, you can find PyGEGL
> source in the bindings/pygegl/ dir.)
> 
> I posted this report originally to the gegl-developer list.
> 
> Kevin Cozens, the PyGEGL maintainer, said:
> > I have only tested pyGEGL with the 2.4 version of Python. It possible (or very
> > likely?) that something has changed in the 2.6 version of Python. I don't have
> > the 2.6 version installed at the moment so I can't investigate this further.
> 
> Sven Neumann said:
> > Have you contacted the python developers then? This looks a lot like a
> > regression in Python and I guess they would like to hear about it before
> > the release the next version.
> 
> Hence I'm posting it here. Perhaps someone can shed some light on what
> is happening here?
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jcarlson%40uci.edu


From 00ai99 at gmail.com  Fri Jul 20 10:32:12 2007
From: 00ai99 at gmail.com (David Gowers)
Date: Fri, 20 Jul 2007 18:02:12 +0930
Subject: [Python-Dev] PyGEGL instant crash (Python regression?)
In-Reply-To: <20070720011912.85AA.JCARLSON@uci.edu>
References: <23f4e3390707200011q41af8a83sa2675412e030ba84@mail.gmail.com>
	<20070720011912.85AA.JCARLSON@uci.edu>
Message-ID: <23f4e3390707200132j720dd9a3mf415966fc49ba925@mail.gmail.com>

On 7/20/07, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "David Gowers" <00ai99 at gmail.com> wrote:
> > Has anyone tried PyGEGL, the Python interface to gegl (www.gegl.org),
> > with SVN Python?
> > When I 'import gegl', that causes an immediate crash with the
> > following backtrace.
>
> I would wager a beer or two that the issue is in the wrapping of gegl.
> Having recently started wrapping modules by hand and with Swig, I have
> come to notice that making a mistake with refcounts can lead to
> segfaults like you are seeing.  If you are getting that immediately upon
> import, you may want to check to make sure that the function that is
> initializing your module (typically something like init_gegl) is doing
> the right things (I can't really offer any suggestions on what to check
> for, I literally only started wrapping stuff by hand yesterday;
> previously I used Pyrex, which can handle all refcounts for you if
> desired).
>
Well, okay; but how does that account for the fact that Kevin reports
it works under 2.4, but it doesn't work under 2.6?

From ncoghlan at gmail.com  Fri Jul 20 13:12:00 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 20 Jul 2007 21:12:00 +1000
Subject: [Python-Dev] PyGEGL instant crash (Python regression?)
In-Reply-To: <23f4e3390707200132j720dd9a3mf415966fc49ba925@mail.gmail.com>
References: <23f4e3390707200011q41af8a83sa2675412e030ba84@mail.gmail.com>	<20070720011912.85AA.JCARLSON@uci.edu>
	<23f4e3390707200132j720dd9a3mf415966fc49ba925@mail.gmail.com>
Message-ID: <46A09880.4020004@gmail.com>

David Gowers wrote:
> Well, okay; but how does that account for the fact that Kevin reports
> it works under 2.4, but it doesn't work under 2.6?

The most likely culprit is that some of the code is using PyMem_Free on 
a pointer allocated with PyObject_Malloc (or vice-versa). This has 
always been illegal, but prior to 2.5 the Python memory allocator tied 
itself in knots to try to avoid crashing when client code broke the 
rules. The changes in 2.5 to release unused memory back to the OS 
required that those knots be cut.

The what's new document for each release is a good resource for these 
kinds of problems, especially its porting section:

http://docs.python.org/whatsnew/porting.html

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Fri Jul 20 19:52:14 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 20 Jul 2007 10:52:14 -0700
Subject: [Python-Dev] uuid creation not thread-safe?
Message-ID: <ca471dc20707201052p68883fc5l3efd8ecc5cfd497f@mail.gmail.com>

I discovered what appears to be a thread-unsafety in uuid.py. This is
in the trunk as well as in 3.x; I'm using the trunk here for easy
reference. There's some code around like 395:

    import ctypes, ctypes.util
    _buffer = ctypes.create_string_buffer(16)

This creates a *global* buffer which is used as the output parameter
to later calls to _uuid_generate_random() and _uuid_generate_time().
For example, around line 481, in uuid1():

        _uuid_generate_time(_buffer)
        return UUID(bytes=_buffer.raw)

Clearly if two threads do this simultaneously they are overwriting
_buffer in unpredictable order. There are a few other occurrences of
this too.

I find it somewhat disturbing that what seems a fairly innocent
function that doesn't *appear* to have global state is nevertheless
not thread-safe. Would it be wise to fix this, e.g. by allocating a
fresh output buffer inside uuid1() and other callers?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sat Jul 21 02:17:12 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 20 Jul 2007 17:17:12 -0700
Subject: [Python-Dev] Need help fixing tests in str/unicode branch
Message-ID: <ca471dc20707201717x457f07d2pd841608db5168c2d@mail.gmail.com>

Thanks to all who helped fixing tests in the str/unicode branch! We're
down to about 35 failing tests. I still need help -- especially since
we're now getting into territory that I don't know all that well, for
example the email package or XML support.

The list of unit tests that need help is still on the wiki:
http://wiki.python.org/moin/Py3kStrUniTests

Instructions on how to help and how to avoid duplicate work are also
there. Please help!

Thanks to all those who already fixed one or more tests!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From g.brandl at gmx.net  Sat Jul 21 12:28:28 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 21 Jul 2007 12:28:28 +0200
Subject: [Python-Dev] [ANN] Python documentation team looking for members!
Message-ID: <f7sn4a$5eh$2@sea.gmane.org>

Dear fellow Pythonistas,

as you may have heard, Python is going to get a new documentation system
soon [1].  As part of that effort, and in order to maintain the excellent
quality of the docs, we are looking for members of the maintainers team.
This is your chance to get involved with Python development!

There will be two main objectives of the group, or maybe two subgroups can
be formed:

* Maintaining the documentation contents:
   - processing user submitted comments, bugs and patches
   - helping out developers with docs-related matters, keeping an eye
     on commits to ensure quality
   - keeping the docs up-to-date, e.g. write new sections for new
     Python 3000 features

   The docs source will be in reStructuredText, which is already known to a
   relatively high percentage of Python developers.

   The new online version of the docs will contain features to add comments
   and suggest changes, so it is expected that there will be some amount
   of user involvement.


* Development of the toolset:
   - fixing bugs in the package
   - adding new output formats, e.g. info or pdf
   - adding new features to the web application
   - adapting it to new docutils features

   The software is written in pure Python. It is currently located in the
   docutils Subversion repository, at
   http://svn.berlios.de/viewcvs/docutils/trunk/sandbox/py-rest-doc/

   The README file gives you a rough idea what you find there and how to
   get started, all other questions can be directed to georg at python.org,
   I'll answer them gladly.


An additional objective in the near future will, of course, be handling the
switch to the new system.

Okay, so you've read until here? And you're interested in joining the team?
Wow! Write to the docs at python.org and become a documentation maintainer!

cheers,
Georg


[1] see http://pyside.blogspot.com/2007/06/introducing-py-rest-doc.html
     for some details, and http://pydoc.gbrandl.de:3000/ [2] for a demo.
     (Commenting doesn't work yet, but it's worked upon fiercely...)

[2] the demo server is a small vserver with the application served by a
     single wsgiref instance, and as such not fit to handle large amounts
     of requests, so it may well be that you don't get good reponse times.


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


From status at bugs.python.org  Sun Jul 22 02:00:48 2007
From: status at bugs.python.org (Tracker)
Date: Sun, 22 Jul 2007 00:00:48 +0000 (UTC)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20070722000048.8823978176@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (07/15/07 - 07/22/07)
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.


 1646 open ( +0) /  8584 closed ( +0) / 10230 total ( +0)

Average duration of open issues: 863 days.
Median duration of open issues: 812 days.

Open Issues Breakdown
   open  1646 ( +0)
pending     0 ( +0)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070722/b50c2071/attachment.htm 

From daniel at stutzbachenterprises.com  Thu Jul 12 17:08:08 2007
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Thu, 12 Jul 2007 10:08:08 -0500
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
Message-ID: <eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>

On 7/11/07, Andy C <andychup at gmail.com> wrote:
> The good thing about this is that it's extremely simple -- basically
> 20 lines of C code to add a -z flag that calls a 3-line Python
> function in the runpy module.

Instead of requiring a -z flag, why not have the interpreter peak at
the file to see if it starts with one of the ZIP magic numbers?

That way it Just Works.

-- 
Daniel Stutzbach, Ph.D.             President, Stutzbach Enterprises LLC

From t.kim at mail.utexas.edu  Fri Jul 13 23:18:18 2007
From: t.kim at mail.utexas.edu (Tae-Hee Kim)
Date: Fri, 13 Jul 2007 16:18:18 -0500
Subject: [Python-Dev]  Planned updates for cjkcodecs before 2.4a1
Message-ID: <62842EE5-DDEC-4907-AD1B-75CF83F88A49@mail.utexas.edu>

Hello,

I am e-mailing you because I am looking for a way to use the CJK  
codecs and the CJK module that I found for Python.

I wasn't able to find any documentation on how to use it so I would  
appreciate it if you would let me know where I could find it.

Thank you in advance.



Taehee Kim
------------------
t.kim at mail.utexas.edu

From andychup at gmail.com  Wed Jul 11 08:39:01 2007
From: andychup at gmail.com (Andy C)
Date: Tue, 10 Jul 2007 23:39:01 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
Message-ID: <596909b30707102339j4bab06c8i45132a6a9dc7e2a@mail.gmail.com>

I'd like to request comments on this patch I submitted:

https://sourceforge.net/tracker/index.php?func=detail&aid=1739468&group_id=5470&atid=305470

There are many details given in the comments on that page.

This can be used to deploy Python programs in a very lightweight and
cross-platform way.  You could imagine a cgi script or a light web app
server being deployed like this.  I have personally deployed Python
programs using zip files and this would get rid of the need for
boilerplate needed for each platform.

The good thing about this is that it's extremely simple -- basically
20 lines of C code to add a -z flag that calls a 3-line Python
function in the runpy module.

I don't believe it overlaps with anything that already exists.  py2exe
and py2app are platform specific and bundle the Python interpreter.
This will be a cross platform binary that doesn't bundle the Python
interpreter.  It doesn't require eggs but I think it would work fine
with eggs, and could help fix a little bug as I mentioned on the patch
page.

Nick Coghlan has reviewed the patch and seems to think it's a good
idea.  Thomas Wouters also said he likes it, and I ran it by Guido
earlier and he seemed to think the idea is good, although I don't
think he has seen the implementation.

thanks,
Andy

From aahz at pythoncraft.com  Mon Jul 23 16:08:18 2007
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 23 Jul 2007 07:08:18 -0700
Subject: [Python-Dev] Planned updates for cjkcodecs before 2.4a1
In-Reply-To: <62842EE5-DDEC-4907-AD1B-75CF83F88A49@mail.utexas.edu>
References: <62842EE5-DDEC-4907-AD1B-75CF83F88A49@mail.utexas.edu>
Message-ID: <20070723140818.GA19764@panix.com>

On Fri, Jul 13, 2007, Tae-Hee Kim wrote:
>
> I am e-mailing you because I am looking for a way to use the CJK  
> codecs and the CJK module that I found for Python.
> 
> I wasn't able to find any documentation on how to use it so I would  
> appreciate it if you would let me know where I could find it.

You're asking in the wrong place, please use comp.lang.python; python-dev
is for discussion of bug reports and similar topics.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

This is Python.  We don't care much about theory, except where it intersects 
with useful practice.  

From guido at python.org  Mon Jul 23 18:55:14 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Jul 2007 09:55:14 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
Message-ID: <ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>

On 7/12/07, Daniel Stutzbach <daniel at stutzbachenterprises.com> wrote:
> On 7/11/07, Andy C <andychup at gmail.com> wrote:
> > The good thing about this is that it's extremely simple -- basically
> > 20 lines of C code to add a -z flag that calls a 3-line Python
> > function in the runpy module.
>
> Instead of requiring a -z flag, why not have the interpreter peak at
> the file to see if it starts with one of the ZIP magic numbers?
>
> That way it Just Works.

I guess you wouldn't recognize a zip file if it hits you in the face.
Literally. :-)

Zip files don't start with a magic number.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From crutcher at gmail.com  Mon Jul 23 19:12:40 2007
From: crutcher at gmail.com (Crutcher Dunnavant)
Date: Mon, 23 Jul 2007 10:12:40 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
Message-ID: <7C3F9FEF-0C03-4945-9EBE-C07246BC4191@gmail.com>



Crutcher Dunnavant

On Jul 23, 2007, at 9:55 AM, "Guido van Rossum" <guido at python.org>  
wrote:

> On 7/12/07, Daniel Stutzbach <daniel at stutzbachenterprises.com> wrote:
>> On 7/11/07, Andy C <andychup at gmail.com> wrote:
>>> The good thing about this is that it's extremely simple -- basically
>>> 20 lines of C code to add a -z flag that calls a 3-line Python
>>> function in the runpy module.
>>
>> Instead of requiring a -z flag, why not have the interpreter peak at
>> the file to see if it starts with one of the ZIP magic numbers?
>>
>> That way it Just Works.
>
> I guess you wouldn't recognize a zip file if it hits you in the face.
> Literally. :-)
>
> Zip files don't start with a magic number.

Don't they end with a sentinel? If so, what would be the difference?
>
> -- 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/crutcher%40gmail.com

From guido at python.org  Mon Jul 23 19:34:33 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Jul 2007 10:34:33 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <7C3F9FEF-0C03-4945-9EBE-C07246BC4191@gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
	<7C3F9FEF-0C03-4945-9EBE-C07246BC4191@gmail.com>
Message-ID: <ca471dc20707231034q65da2a89j2567d9696b4889e5@mail.gmail.com>

On 7/23/07, Crutcher Dunnavant <crutcher at gmail.com> wrote:
>
>
> Crutcher Dunnavant
>
> On Jul 23, 2007, at 9:55 AM, "Guido van Rossum" <guido at python.org>
> wrote:
>
> > On 7/12/07, Daniel Stutzbach <daniel at stutzbachenterprises.com> wrote:
> >> On 7/11/07, Andy C <andychup at gmail.com> wrote:
> >>> The good thing about this is that it's extremely simple -- basically
> >>> 20 lines of C code to add a -z flag that calls a 3-line Python
> >>> function in the runpy module.
> >>
> >> Instead of requiring a -z flag, why not have the interpreter peak at
> >> the file to see if it starts with one of the ZIP magic numbers?
> >>
> >> That way it Just Works.
> >
> > I guess you wouldn't recognize a zip file if it hits you in the face.
> > Literally. :-)
> >
> > Zip files don't start with a magic number.
>
> Don't they end with a sentinel? If so, what would be the difference?

There's an ambiguity -- a Zip file could start with a Python (or
shell, or Perl) script that bootstraps execution. This is used
regularly. Changing the semantics just because the file *ends* with
something funny sounds like asking for trouble.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From pje at telecommunity.com  Mon Jul 23 19:54:55 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 23 Jul 2007 13:54:55 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.co
 m>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
Message-ID: <20070723175237.9BCFB3A403D@sparrow.telecommunity.com>

At 09:55 AM 7/23/2007 -0700, Guido van Rossum wrote:
>On 7/12/07, Daniel Stutzbach <daniel at stutzbachenterprises.com> wrote:
> > On 7/11/07, Andy C <andychup at gmail.com> wrote:
> > > The good thing about this is that it's extremely simple -- basically
> > > 20 lines of C code to add a -z flag that calls a 3-line Python
> > > function in the runpy module.
> >
> > Instead of requiring a -z flag, why not have the interpreter peak at
> > the file to see if it starts with one of the ZIP magic numbers?
> >
> > That way it Just Works.
>
>I guess you wouldn't recognize a zip file if it hits you in the face.
>Literally. :-)
>
>Zip files don't start with a magic number.

I've actually started on a patch that uses the standard import hooks 
to figure out how to import __main__ from sys.argv[0], if it's 
something that an import hook can be found for (otherwise, it falls 
back to normal behavior).

At this point, the problem is that __main__ is a builtin module and 
already exists when this processing is being done, so trying to 
reload it in a straightforward way doesn't work.  (Nor does using the 
standard -m logic.)

If I can figure out how to work around that bit, we won't need a -z 
flag, which means a #! line for zipfiles is possible on 'nix, and we 
can support arbitrary import hooks for sys.argv[0].  (Assuming 
they're either built-in or registered via sitecustomize, that is.)


From pje at telecommunity.com  Mon Jul 23 20:02:08 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 23 Jul 2007 14:02:08 -0400
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip  file
In-Reply-To: <ca471dc20707231034q65da2a89j2567d9696b4889e5@mail.gmail.co
 m>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
	<7C3F9FEF-0C03-4945-9EBE-C07246BC4191@gmail.com>
	<ca471dc20707231034q65da2a89j2567d9696b4889e5@mail.gmail.com>
Message-ID: <20070723175949.BE07D3A403D@sparrow.telecommunity.com>

At 10:34 AM 7/23/2007 -0700, Guido van Rossum wrote:
>There's an ambiguity -- a Zip file could start with a Python (or
>shell, or Perl) script that bootstraps execution. This is used
>regularly. Changing the semantics just because the file *ends* with
>something funny sounds like asking for trouble.

Actually, it isn't, because you can't start a zipfile with a Python 
script.  Lord knows I've *tried*, but the Python interpreter just 
won't accept arbitrary binary data as part of a script.  :)

Second, unless you somehow managed to overcome that little obstacle, 
you're not going to be trying to run the zipfile with the Python 
interpreter, anyway.  Instead, the #! line (or .exe header on 
Windows) will be invoking whatever interpreter or program actually 
works for that file.

Third, if you mistakenly pass an existing such zipfile to a new 
Python interpreter that supports zipfiles, and there's no 
__main__.py* file in it, you're just going to get a different error 
message than the syntax error you'd have received from an older 
Python.interpreter to run it with -- but otherwise no difference.

In other words, AFAICT there's really no ambiguity here.


From p.f.moore at gmail.com  Mon Jul 23 23:57:34 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 23 Jul 2007 22:57:34 +0100
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <20070723175949.BE07D3A403D@sparrow.telecommunity.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
	<7C3F9FEF-0C03-4945-9EBE-C07246BC4191@gmail.com>
	<ca471dc20707231034q65da2a89j2567d9696b4889e5@mail.gmail.com>
	<20070723175949.BE07D3A403D@sparrow.telecommunity.com>
Message-ID: <79990c6b0707231457h56fe3014oef4709cbdb938235@mail.gmail.com>

On 23/07/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> Actually, it isn't, because you can't start a zipfile with a Python
> script.  Lord knows I've *tried*, but the Python interpreter just
> won't accept arbitrary binary data as part of a script.  :)

That bit me a while back, hard enough that I thought of putting
together a patch for it (probably just to stop processing the script
at a NUL byte), but never did as I didn't think I could put a
convincing enough case for it being *useful*.

Anyway, I'd be happy enough with the -z patch as it stands, or if
someone comes up with something better, that would suit me too...

Paul.

From pje at telecommunity.com  Tue Jul 24 02:32:23 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 23 Jul 2007 20:32:23 -0400
Subject: [Python-Dev] -z, -i and -m, maybe bug in runpy?
Message-ID: <20070724004010.0E74B3A40AA@sparrow.telecommunity.com>

While trying to get my -z replacement patch to work, I stumbled 
across a bug in the -m implementation (and in runpy).  It seems that 
when you run the code of a -m module, it is *not* run in the __main__ 
module namespace!

So even though __name__=='__main__', globals() is not 
sys.modules['__main__'].__dict__.  This seems wrong to me.  Does 
anybody know why runpy doesn't actually run the code in the target module?

One consequence of this is that the -i option is much less useful 
when you use -m, because the script's globals have disappeared before 
you get to the interpreter prompt.

At this point, I've successfully gotten a -z replacement patch, 
except that it inherits this apparent bug from -m, which for a while 
led me to believe my patch was broken (when in fact it works fine, 
apart from inheriting the -m behavior).

Does anybody know if this behavior is intended, and if so, why?  And 
what are the consequences of changing/fixing it?


From talin at acm.org  Tue Jul 24 04:18:59 2007
From: talin at acm.org (Talin)
Date: Mon, 23 Jul 2007 19:18:59 -0700
Subject: [Python-Dev] Two spaces or one?
Message-ID: <46A56193.6010500@acm.org>

In PEP 9 there's a requirement that PEPs must follow the "emacs 
convention" of 2 spaces after a period. (I didn't know this was an emacs 
convention, I thought it was a convention of people who used typewriters.)

I've tried hard to maintain this textual convention in my own PEPs, even 
though it's very unnatural to me. But I see from looking at the other 
PEPs that that this convention is very inconsistently enforced - some 
have it and some don't. Worse, I've had one person (who apparently 
wasn't aware of the rule) flag my use of extra space after a period as a 
bug in my PEP.

(When I first learned to type, I used one space after a period. Then 
years later, someone convinced me that two spaces was the proper style 
and so I switched to that for a few years. But later I switched back 
because I realized that most modern typographical layout engines seem to 
calculate inter-sentence spacing properly when the number of space 
characters after a period is one. And in HTML [which is how most people 
view PEPs anyway] it doesn't matter since the browser is going to filter 
out the extra space anyway.)

So if we're not going to enforce the rule consistently (and it seems as 
if we're not), can we then just remove it from PEP 9? I'm not saying 
that we should change the rule to one space, I'm suggesting that we just 
drop the requirement and let people use whatever they prefer.

-- Talin

From andychup at gmail.com  Tue Jul 24 04:37:10 2007
From: andychup at gmail.com (Andy C)
Date: Mon, 23 Jul 2007 19:37:10 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <79990c6b0707231457h56fe3014oef4709cbdb938235@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
	<7C3F9FEF-0C03-4945-9EBE-C07246BC4191@gmail.com>
	<ca471dc20707231034q65da2a89j2567d9696b4889e5@mail.gmail.com>
	<20070723175949.BE07D3A403D@sparrow.telecommunity.com>
	<79990c6b0707231457h56fe3014oef4709cbdb938235@mail.gmail.com>
Message-ID: <596909b30707231937p99681d5ld5989aae9072b675@mail.gmail.com>

Just to update everyone on the status of this, the next thing on my
list is to figure out the Windows build and set up the the file
association in the installer.  Actually, I should ask if there's
anything else that I should pay attention to here, e.g. do I have to
add an icon association for Windows or something like that?

Is there any documentation like a wiki page on this?  I looked at the
README in the PC* directories and it doesn't seem to talk about the
installer.  Maybe it will become clearer when I get Visual Studio.

Andy

On 7/23/07, Paul Moore <p.f.moore at gmail.com> wrote:
> On 23/07/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > Actually, it isn't, because you can't start a zipfile with a Python
> > script.  Lord knows I've *tried*, but the Python interpreter just
> > won't accept arbitrary binary data as part of a script.  :)
>
> That bit me a while back, hard enough that I thought of putting
> together a patch for it (probably just to stop processing the script
> at a NUL byte), but never did as I didn't think I could put a
> convincing enough case for it being *useful*.
>
> Anyway, I'd be happy enough with the -z patch as it stands, or if
> someone comes up with something better, that would suit me too...
>
> Paul.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/andychup%40gmail.com
>

From guido at python.org  Tue Jul 24 05:00:28 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Jul 2007 20:00:28 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707231937p99681d5ld5989aae9072b675@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
	<7C3F9FEF-0C03-4945-9EBE-C07246BC4191@gmail.com>
	<ca471dc20707231034q65da2a89j2567d9696b4889e5@mail.gmail.com>
	<20070723175949.BE07D3A403D@sparrow.telecommunity.com>
	<79990c6b0707231457h56fe3014oef4709cbdb938235@mail.gmail.com>
	<596909b30707231937p99681d5ld5989aae9072b675@mail.gmail.com>
Message-ID: <ca471dc20707232000w1309b13rc63bca106d810110@mail.gmail.com>

New icons get added so rarely that each time it happens, Windows has
changed enough to make the instructions invalid... I do remember
creating icon associations for .py, .pyc, .pyo and .pyw, and separate
"open" associations for these. IIRC the two associations are quite
independent. Probably everything has changed though since we now use
MSI.

--Guido

On 7/23/07, Andy C <andychup at gmail.com> wrote:
> Just to update everyone on the status of this, the next thing on my
> list is to figure out the Windows build and set up the the file
> association in the installer.  Actually, I should ask if there's
> anything else that I should pay attention to here, e.g. do I have to
> add an icon association for Windows or something like that?
>
> Is there any documentation like a wiki page on this?  I looked at the
> README in the PC* directories and it doesn't seem to talk about the
> installer.  Maybe it will become clearer when I get Visual Studio.
>
> Andy
>
> On 7/23/07, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 23/07/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > > Actually, it isn't, because you can't start a zipfile with a Python
> > > script.  Lord knows I've *tried*, but the Python interpreter just
> > > won't accept arbitrary binary data as part of a script.  :)
> >
> > That bit me a while back, hard enough that I thought of putting
> > together a patch for it (probably just to stop processing the script
> > at a NUL byte), but never did as I didn't think I could put a
> > convincing enough case for it being *useful*.
> >
> > Anyway, I'd be happy enough with the -z patch as it stands, or if
> > someone comes up with something better, that would suit me too...
> >
> > Paul.
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: http://mail.python.org/mailman/options/python-dev/andychup%40gmail.com
> >
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From jcarlson at uci.edu  Tue Jul 24 05:23:22 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 23 Jul 2007 20:23:22 -0700
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <46A56193.6010500@acm.org>
References: <46A56193.6010500@acm.org>
Message-ID: <20070723201841.7292.JCARLSON@uci.edu>


Talin <talin at acm.org> wrote:
> 
> In PEP 9 there's a requirement that PEPs must follow the "emacs 
> convention" of 2 spaces after a period. (I didn't know this was an emacs 
> convention, I thought it was a convention of people who used typewriters.)

If the PEP is displayed as HTML, then one or two spaces after a period
in plain text might not matter; any browser that I've bothered to check
visually merges space characters unless they are intermixed/replaced
with non-breaking space (&nbsp;). If ReStructured Text converts to
non-breaking space, then they matter.

In terms of text text editing, I think that as long as one is consistant
within a document, that's good enough.


 - Josiah


From martin at v.loewis.de  Tue Jul 24 06:53:57 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 24 Jul 2007 06:53:57 +0200
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <596909b30707231937p99681d5ld5989aae9072b675@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>	<7C3F9FEF-0C03-4945-9EBE-C07246BC4191@gmail.com>	<ca471dc20707231034q65da2a89j2567d9696b4889e5@mail.gmail.com>	<20070723175949.BE07D3A403D@sparrow.telecommunity.com>	<79990c6b0707231457h56fe3014oef4709cbdb938235@mail.gmail.com>
	<596909b30707231937p99681d5ld5989aae9072b675@mail.gmail.com>
Message-ID: <46A585E5.1090304@v.loewis.de>

Andy C schrieb:
> Just to update everyone on the status of this, the next thing on my
> list is to figure out the Windows build and set up the the file
> association in the installer.  Actually, I should ask if there's
> anything else that I should pay attention to here, e.g. do I have to
> add an icon association for Windows or something like that?
> 
> Is there any documentation like a wiki page on this?  I looked at the
> README in the PC* directories and it doesn't seem to talk about the
> installer.  Maybe it will become clearer when I get Visual Studio.

It's all in Tools/msi/msi.py. Just look for the other extensions;
the change should be fairly straight-forward.

Regards,
Martin

From g.brandl at gmx.net  Tue Jul 24 08:20:14 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 24 Jul 2007 08:20:14 +0200
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <46A56193.6010500@acm.org>
References: <46A56193.6010500@acm.org>
Message-ID: <f845mt$3uk$1@sea.gmane.org>

Talin schrieb:
> In PEP 9 there's a requirement that PEPs must follow the "emacs 
> convention" of 2 spaces after a period. (I didn't know this was an emacs 
> convention, I thought it was a convention of people who used typewriters.)

It's an Emacs convention in the sense that its auto-filling function expects
that; it will not break lines after a period which is followed by a
single space only.
(These are the default settings, this being Emacs you can customize it.)


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.


From 00ai99 at gmail.com  Tue Jul 24 10:07:59 2007
From: 00ai99 at gmail.com (David Gowers)
Date: Tue, 24 Jul 2007 17:37:59 +0930
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
Message-ID: <23f4e3390707240107r473f4e36ld2509483f2ccaadb@mail.gmail.com>

On 7/24/07, Guido van Rossum <guido at python.org> wrote:
> On 7/12/07, Daniel Stutzbach <daniel at stutzbachenterprises.com> wrote:
> > On 7/11/07, Andy C <andychup at gmail.com> wrote:
> > > The good thing about this is that it's extremely simple -- basically
> > > 20 lines of C code to add a -z flag that calls a 3-line Python
> > > function in the runpy module.
> >
> > Instead of requiring a -z flag, why not have the interpreter peak at
> > the file to see if it starts with one of the ZIP magic numbers?
> >
> > That way it Just Works.
>
> I guess you wouldn't recognize a zip file if it hits you in the face.
> Literally. :-)
>
> Zip files don't start with a magic number.

ZIP files *do* start with a magic number; either PK\03\04 (non-empty
archive) or PK\05\06 (empty archive). This is rather easy to notice,
as I did in the bad old days of DOS, and i recently doubly verified it
('zip'+'khexedit', and
http://en.wikipedia.org/wiki/ZIP_%28file_format%29; I tried the
infozip website too, but it seems to be down.)

From barry at python.org  Tue Jul 24 14:13:34 2007
From: barry at python.org (Barry Warsaw)
Date: Tue, 24 Jul 2007 08:13:34 -0400
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <46A56193.6010500@acm.org>
References: <46A56193.6010500@acm.org>
Message-ID: <97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 23, 2007, at 10:18 PM, Talin wrote:

> In PEP 9 there's a requirement that PEPs must follow the "emacs
> convention" of 2 spaces after a period. (I didn't know this was an  
> emacs
> convention, I thought it was a convention of people who used  
> typewriters.)
>
[...]
> So if we're not going to enforce the rule consistently (and it  
> seems as
> if we're not), can we then just remove it from PEP 9? I'm not saying
> that we should change the rule to one space, I'm suggesting that we  
> just
> drop the requirement and let people use whatever they prefer.

As an emacs dinosaur, I'd prefer to keep the recommendation, but I  
also acknowledge that the smaller mammals nipping at my heals will  
eventually take over the world.  I've recently had similar  
discussions in another community and I was actually kind of amazed to  
learn that auto-refilling of paragraphs itself was somewhat of an  
anachronism.

Emacs will probably go the way of the vinyl record (though the latter  
is seeing a resurgence lately :).  Changing "must" to "should" in PEP  
9 would encourage but not enforce consistency, and I think that would  
be fine.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRqXs7nEjvBPtnXfVAQLZWAP/UGGslCnGukFXJOvXoOyQE34baFAxKEyY
NmXmZnpGfnhNOgASG1zxpAzPd6PtHQUMzwk0FXwlHVHpwg9Lb+IxFGZlRAgY2Tya
KspvunDYlRFGAlG13Zg+GsQZI6cOOLqjKqwPsAcNXe9NIQhTA8hJ6vYcGSbE/I3q
73INGJg5uU4=
=keXE
-----END PGP SIGNATURE-----

From skip at pobox.com  Tue Jul 24 14:48:31 2007
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 24 Jul 2007 07:48:31 -0500
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
Message-ID: <18085.62751.929027.48149@montanaro.dyndns.org>

I'm with Barry.  I still use Emacs.  Emacs's paragraph filling algorithm,
whether invoked explicitly via M-q or implicitly via auto-wrap mode,
distinguishes the usage of periods based on the number of spaces following
them.  Two or more spaces are used to separate sentences.  One space (for
example, G. D. Montanaro) following a period is considered a non-breakable
space.

Skip

From ncoghlan at gmail.com  Tue Jul 24 14:50:30 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Jul 2007 22:50:30 +1000
Subject: [Python-Dev] -z, -i and -m, maybe bug in runpy?
In-Reply-To: <20070724004010.0E74B3A40AA@sparrow.telecommunity.com>
References: <20070724004010.0E74B3A40AA@sparrow.telecommunity.com>
Message-ID: <46A5F596.4060309@gmail.com>

Phillip J. Eby wrote:
> While trying to get my -z replacement patch to work, I stumbled 
> across a bug in the -m implementation (and in runpy).  It seems that 
> when you run the code of a -m module, it is *not* run in the __main__ 
> module namespace!
> 
> So even though __name__=='__main__', globals() is not 
> sys.modules['__main__'].__dict__.  This seems wrong to me.  Does 
> anybody know why runpy doesn't actually run the code in the target module?

After implementing the runpy explicit relative import tests over the 
last couple of days, it actually occurred to me earlier today that I 
didn't have a test for this scenario. When I thought of the test, I was 
also pretty sure it would fail - it appears I was right :)

> One consequence of this is that the -i option is much less useful 
> when you use -m, because the script's globals have disappeared before 
> you get to the interpreter prompt.
> 
> At this point, I've successfully gotten a -z replacement patch, 
> except that it inherits this apparent bug from -m, which for a while 
> led me to believe my patch was broken (when in fact it works fine, 
> apart from inheriting the -m behavior).
> 
> Does anybody know if this behavior is intended, and if so, why?  And 
> what are the consequences of changing/fixing it?

I think it's a bug - when fiddling with the sys module 
runpy.run_module() only uses the real module name, and not the requested 
run_name. It should actually modify both so that the assertion 
"globals() is sys.modules[__name__].__dict__" is correct when running 
the module.

So, I propose that if runpy.run_module is told it has permission to 
modify the sys module, and run_name is specified and exists in 
sys.modules, then runpy will use that module to execute the code, 
instead of creating a new temporary module.

If run_name isn't in sys.modules, then the temporary module used to 
execute the code will be stored in both places.

This is a semantic change so we can't really backport it, but we can at 
least fix it for 2.6.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From aahz at pythoncraft.com  Tue Jul 24 14:51:33 2007
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 24 Jul 2007 05:51:33 -0700
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <18085.62751.929027.48149@montanaro.dyndns.org>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
Message-ID: <20070724125133.GA19388@panix.com>

On Tue, Jul 24, 2007, skip at pobox.com wrote:
>
> I'm with Barry.  I still use Emacs.  Emacs's paragraph filling algorithm,
> whether invoked explicitly via M-q or implicitly via auto-wrap mode,
> distinguishes the usage of periods based on the number of spaces following
> them.  Two or more spaces are used to separate sentences.  One space (for
> example, G. D. Montanaro) following a period is considered a non-breakable
> space.

There's no need to invoke Emacs to argue for the superiority of two
spaces after each sentence, according to this vi user.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

This is Python.  We don't care much about theory, except where it intersects 
with useful practice.  

From steve at holdenweb.com  Tue Jul 24 16:12:37 2007
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 24 Jul 2007 10:12:37 -0400
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <18085.62751.929027.48149@montanaro.dyndns.org>
References: <46A56193.6010500@acm.org>	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
Message-ID: <f851c5$3t1$1@sea.gmane.org>

skip at pobox.com wrote:
> I'm with Barry.  I still use Emacs.  Emacs's paragraph filling algorithm,
> whether invoked explicitly via M-q or implicitly via auto-wrap mode,
> distinguishes the usage of periods based on the number of spaces following
> them.  Two or more spaces are used to separate sentences.  One space (for
> example, G. D. Montanaro) following a period is considered a non-breakable
> space.
> 
How very twentieth-century :-)

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------


From ncoghlan at gmail.com  Tue Jul 24 16:16:24 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 25 Jul 2007 00:16:24 +1000
Subject: [Python-Dev] -z, -i and -m, maybe bug in runpy?
In-Reply-To: <46A5F596.4060309@gmail.com>
References: <20070724004010.0E74B3A40AA@sparrow.telecommunity.com>
	<46A5F596.4060309@gmail.com>
Message-ID: <46A609B8.3030402@gmail.com>

Nick Coghlan wrote:
> Phillip J. Eby wrote:
>> While trying to get my -z replacement patch to work, I stumbled across 
>> a bug in the -m implementation (and in runpy).  It seems that when you 
>> run the code of a -m module, it is *not* run in the __main__ module 
>> namespace!
>>
>> So even though __name__=='__main__', globals() is not 
>> sys.modules['__main__'].__dict__.  This seems wrong to me.  Does 
>> anybody know why runpy doesn't actually run the code in the target 
>> module?
> 
> After implementing the runpy explicit relative import tests over the 
> last couple of days, it actually occurred to me earlier today that I 
> didn't have a test for this scenario. When I thought of the test, I was 
> also pretty sure it would fail - it appears I was right :)

OK, I've now had a closer look, and the problem isn't what I initially 
thought when I read your message (the test which I expected to fail 
actually passed without changing the current implementation). It turns 
out that while the module is actually executing it does the right thing 
- the problem only arises when the run_module function attempts to clean 
up after itself by reverting some of the changes it makes to the sys module.

The specific problem is this sentence from the run_module docs:
   "Both sys.argv[0] and sys.modules[__name__] are restored to their 
original values before the function returns."

It looks like those semantics are a mistake - the changes to the sys 
module should persist after the function terminates, leaving it to the 
calling code to decide whether or not it wants to restore the original 
state.

>> One consequence of this is that the -i option is much less useful when 
>> you use -m, because the script's globals have disappeared before you 
>> get to the interpreter prompt.

See above - the problem is that the function is cleaning up after itself 
and deleting things that may still be of interest when -i is also specified.

>> At this point, I've successfully gotten a -z replacement patch, except 
>> that it inherits this apparent bug from -m, which for a while led me 
>> to believe my patch was broken (when in fact it works fine, apart from 
>> inheriting the -m behavior).
>>
>> Does anybody know if this behavior is intended, and if so, why?  And 
>> what are the consequences of changing/fixing it?

It was intended enough to be documented that way, but I don't recall 
putting any significant thought into that aspect of the implementation, 
and nor do I remember anyone else questioning it.

The fact that it completely breaks the -i switch seems more than enough 
reason to consider it a bug, though.

I've changed the behaviour in r56520 to simply leave the alterations to 
sys in place when the function terminates. While this is a definite 
change to the interface (and hence not a candidate for direct 
backporting), I think the difference is small enough for the 2.5 to 2.6 
transition.

If enough people prefer, I can switch the code to an approach which 
fixes -m while leaving the semantics of runpy.run_module alone. This 
would involve renaming the version of run_module I just checked into SVN 
have -m invoke that version directly. run_module would be changed to 
wrap the function used by -m in the necessary code to restore the sys 
module to something more closely resembling its original state. That 
would also be the approach to take if we decided we wanted to backport 
this fix to the 2.5 maintenance branch.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From andrewm at object-craft.com.au  Tue Jul 24 16:15:02 2007
From: andrewm at object-craft.com.au (Andrew McNamara)
Date: Wed, 25 Jul 2007 00:15:02 +1000
Subject: [Python-Dev] Calling back into python from C
Message-ID: <20070724141502.82B23600B4E@longblack.object-craft.com.au>

I realise I'm going to get slapped for asking a userish question here -
sorry in advance.  I'm looking for an explanation for why things are the
way they are, the doco and py source aren't providing the missing info,
and it looks like I'm bumping into an old Python bug (fixed in r38830
by mwh on 2005-04-18).

I'm working on an C extension that needs to call back into python.
Generally the GIL has been released when I need to do the callback,
but I can't be sure. So I need to save the GIL state, get the lock,
then restore it at the end.

As far as I can tell from the doco, the recommended way to do this is to
use PyGILState_Ensure() and PyGILState_Release(), but prior to r38830,
PyGILState_Release incorrectly used PyEval_ReleaseThread when it
should have been using PyEval_SaveThread() (I think), and the result is
SEGV. This poses a problem, as I need to support Python versions back
to 2.3.

Am I correct in using PyGILState_Ensure() and PyGILState_Release()? If
so, how do I support back to Py 2.3? Copy the current fixed
PyGILState_Release() into my code (ick)?

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

From ncoghlan at gmail.com  Tue Jul 24 16:44:42 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 25 Jul 2007 00:44:42 +1000
Subject: [Python-Dev] Failure on assorted buildbots - Address already in use
Message-ID: <46A6105A.10908@gmail.com>

A lot of the buildbots are red at the moment, which makes it harder to 
tell if a checkin broke anything new on other platforms.

I've checked in a change to test_resource that should hopefully make 
some of the Debian buildbots happier, but several of the other buildbots 
are reporting a variety of "Address already in use" errors in the 
subthreads created by test_urllib2.

Anyone have any ideas?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Tue Jul 24 16:54:55 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Jul 2007 07:54:55 -0700
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <20070724125133.GA19388@panix.com>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
Message-ID: <ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>

On 7/24/07, Aahz <aahz at pythoncraft.com> wrote:
> On Tue, Jul 24, 2007, skip at pobox.com wrote:
> >
> > I'm with Barry.  I still use Emacs.  Emacs's paragraph filling algorithm,
> > whether invoked explicitly via M-q or implicitly via auto-wrap mode,
> > distinguishes the usage of periods based on the number of spaces following
> > them.  Two or more spaces are used to separate sentences.  One space (for
> > example, G. D. Montanaro) following a period is considered a non-breakable
> > space.

I made this argument in private to Talin before he went here for a
second opinion. Apparently it wasn't strong enough. :-)

> There's no need to invoke Emacs to argue for the superiority of two
> spaces after each sentence, according to this vi user.

Indeed. After all, we're talking about PEP 9, which is a *plaintext*
format. Check out http://www.python.org/dev/peps/pep-0009/ and you'll
see that it is rendered in a fixed-width font with line breaks exactly
where they are in the source, and the two spaces make a difference for
readability.

How about in PEP 9 we keep the recommendation, perhaps weakened to
"should" or "ought"; but in PEP 12 (the ReST equivalent) we remove it
altogether because it doesn't affect the rendering.

And let's please not make this into a bikeshed discussion than it already is.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From facundobatista at gmail.com  Tue Jul 24 17:28:03 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Tue, 24 Jul 2007 12:28:03 -0300
Subject: [Python-Dev] Failure on assorted buildbots - Address already in
	use
In-Reply-To: <46A6105A.10908@gmail.com>
References: <46A6105A.10908@gmail.com>
Message-ID: <e04bdf310707240828o9b0123bs8f0ae394d92b1bee@mail.gmail.com>

2007/7/24, Nick Coghlan <ncoghlan at gmail.com>:

> some of the Debian buildbots happier, but several of the other buildbots
> are reporting a variety of "Address already in use" errors in the
> subthreads created by test_urllib2.

Test pass ok in my machine.

However, if in another terminal I make...

>>> import socket
>>> s = socket.socket()
>>> s.bind(("127.0.0.1", 8080))

...the test fails exactly like in the buildbot.

Maybe the tests should be changed to use a not-so-standard port.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From dalcinl at gmail.com  Tue Jul 24 18:09:06 2007
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Tue, 24 Jul 2007 13:09:06 -0300
Subject: [Python-Dev] Py3k: error byte-compiling with distutils
Message-ID: <e7ba66e40707240909o5e5d617fl19a64b582a74c1e9@mail.gmail.com>

I'm porting some of my code to py3k, and I started from the C size.
After this, all extensions compiled fine, but after a 'setup.py
install', I got the following:

  File "/usr/local/python/3.0/lib/python3.0/distutils/util.py", line
498, in byte_compile
    compile(file, cfile, dfile)
  File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 127, in compile
    py_exc = PyCompileError(err.__class__,err.args,dfile or file)
  File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 48, in __init__
    tbtext = ''.join(traceback.format_exception_only(exc_type, exc_value))
  File "/usr/local/python/3.0/lib/python3.0/traceback.py", line 196,
in format_exception_only
    lines.append("%s: %s\n" % (stype, str(msg)))
UnboundLocalError: local variable 'msg' referenced before assignment


At this point, I had not updated my python code, so it surelly had
some py3k-invalid things. Looking at 'traceback.py', it seems there is
something wrong in 'format_exception_only', so this error.


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From janssen at parc.com  Tue Jul 24 18:35:37 2007
From: janssen at parc.com (Bill Janssen)
Date: Tue, 24 Jul 2007 09:35:37 PDT
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org> 
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
Message-ID: <07Jul24.093546pdt."57996"@synergy1.parc.xerox.com>

> Emacs will probably go the way of the vinyl record (though the latter  
> is seeing a resurgence lately :).

Doubt it.  Even as we speak, there's probably a student planning to
implement Python 3 in ELisp as a SOC project...

Bill


From guido at python.org  Tue Jul 24 18:54:37 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Jul 2007 09:54:37 -0700
Subject: [Python-Dev] Py3k: error byte-compiling with distutils
In-Reply-To: <e7ba66e40707240909o5e5d617fl19a64b582a74c1e9@mail.gmail.com>
References: <e7ba66e40707240909o5e5d617fl19a64b582a74c1e9@mail.gmail.com>
Message-ID: <ca471dc20707240954i69217c17o6761589795112913@mail.gmail.com>

On 7/24/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> I'm porting some of my code to py3k, and I started from the C size.
> After this, all extensions compiled fine, but after a 'setup.py
> install', I got the following:
>
>   File "/usr/local/python/3.0/lib/python3.0/distutils/util.py", line
> 498, in byte_compile
>     compile(file, cfile, dfile)
>   File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 127, in compile
>     py_exc = PyCompileError(err.__class__,err.args,dfile or file)
>   File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 48, in __init__
>     tbtext = ''.join(traceback.format_exception_only(exc_type, exc_value))
>   File "/usr/local/python/3.0/lib/python3.0/traceback.py", line 196,
> in format_exception_only
>     lines.append("%s: %s\n" % (stype, str(msg)))
> UnboundLocalError: local variable 'msg' referenced before assignment
>
>
> At this point, I had not updated my python code, so it surelly had
> some py3k-invalid things. Looking at 'traceback.py', it seems there is
> something wrong in 'format_exception_only', so this error.

Try again -- I think this bug was introduced a few days ago. Kurt
Kaiser promised to roll it bck, but it hasn't happened yet it seems.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Tue Jul 24 19:28:46 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Jul 2007 10:28:46 -0700
Subject: [Python-Dev] Add a -z interpreter flag to execute a zip file
In-Reply-To: <23f4e3390707240107r473f4e36ld2509483f2ccaadb@mail.gmail.com>
References: <596909b30707111943s6a91479cq8cafaebefc34d649@mail.gmail.com>
	<eae285400707120808x58f2c830n5557aa8e9a703b25@mail.gmail.com>
	<ca471dc20707230955i34e5d2d1k7aad5c30fdb1b4c8@mail.gmail.com>
	<23f4e3390707240107r473f4e36ld2509483f2ccaadb@mail.gmail.com>
Message-ID: <ca471dc20707241028s2bfcd887k6e002e98ebecd6c@mail.gmail.com>

On 7/24/07, David Gowers <00ai99 at gmail.com> wrote:
> On 7/24/07, Guido van Rossum <guido at python.org> wrote:
> > On 7/12/07, Daniel Stutzbach <daniel at stutzbachenterprises.com> wrote:
> > > On 7/11/07, Andy C <andychup at gmail.com> wrote:
> > > > The good thing about this is that it's extremely simple -- basically
> > > > 20 lines of C code to add a -z flag that calls a 3-line Python
> > > > function in the runpy module.
> > >
> > > Instead of requiring a -z flag, why not have the interpreter peak at
> > > the file to see if it starts with one of the ZIP magic numbers?
> > >
> > > That way it Just Works.
> >
> > I guess you wouldn't recognize a zip file if it hits you in the face.
> > Literally. :-)
> >
> > Zip files don't start with a magic number.
>
> ZIP files *do* start with a magic number; either PK\03\04 (non-empty
> archive) or PK\05\06 (empty archive). This is rather easy to notice,
> as I did in the bad old days of DOS, and i recently doubly verified it
> ('zip'+'khexedit', and
> http://en.wikipedia.org/wiki/ZIP_%28file_format%29; I tried the
> infozip website too, but it seems to be down.)

You can believe that, but it's not the whole story. You can *prepend*
arbitrary data and the zip tools can still read the archive.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From pje at telecommunity.com  Tue Jul 24 20:20:39 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 24 Jul 2007 14:20:39 -0400
Subject: [Python-Dev] -z, -i and -m, maybe bug in runpy?
In-Reply-To: <46A609B8.3030402@gmail.com>
References: <20070724004010.0E74B3A40AA@sparrow.telecommunity.com>
	<46A5F596.4060309@gmail.com> <46A609B8.3030402@gmail.com>
Message-ID: <20070724181824.705933A40A7@sparrow.telecommunity.com>

At 12:16 AM 7/25/2007 +1000, Nick Coghlan wrote:
>I've changed the behaviour in r56520 to simply leave the alterations to
>sys in place when the function terminates. While this is a definite
>change to the interface (and hence not a candidate for direct
>backporting), I think the difference is small enough for the 2.5 to 2.6
>transition.

Your fix is a definite improvement for me, my "run any importable" 
patch is looking a lot better.  There's just one problem left, which 
is that runpy is overwriting sys.argv[0] even if it doesn't need 
to.  So, when running from a zipfile, sys.argv[0] ends up None, which 
is wrong.

However, if I ask runpy not to mess with sys, it creates a new module 
namespace to run the code in, bringing me right back to square one 
(i.e., not being run in __main__).  Any thoughts?

My fallback at this point would be to add an option to run_module() 
to request that sys.argv[0] be used in place of calling 
_get_filename().  It seems ugly to do that, though, if only because 
there are already so many arguments to that function.


From dalcinl at gmail.com  Tue Jul 24 21:59:31 2007
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Tue, 24 Jul 2007 16:59:31 -0300
Subject: [Python-Dev] Py3k: 'range' fail
Message-ID: <e7ba66e40707241259l4012f08cq20bf239051e66844@mail.gmail.com>

I did a fresh checkout as below (is p3yk the right branch?)

$ svn co http://svn.python.org/projects/python/branches/p3yk python-3k

after building and installing, I get

$ python3.0
Python 3.0x (p3yk:56529, Jul 24 2007, 15:58:59)
[GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> range(0,10,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: NULL result without error in PyObject_Call
>>>




-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From alexandre at peadrop.com  Tue Jul 24 22:50:46 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Tue, 24 Jul 2007 16:50:46 -0400
Subject: [Python-Dev] Py3k: 'range' fail
In-Reply-To: <e7ba66e40707241259l4012f08cq20bf239051e66844@mail.gmail.com>
References: <e7ba66e40707241259l4012f08cq20bf239051e66844@mail.gmail.com>
Message-ID: <acd65fa20707241350h2b53ab53pd15e71287c2aca8e@mail.gmail.com>

Yes, range() on the p3yk branch seems broken. However, this bug has
been fixed in the py3k-struni, the branch where most the development
for Python 3000 is taking place.

-- Alexandre

On 7/24/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> I did a fresh checkout as below (is p3yk the right branch?)
>
> $ svn co http://svn.python.org/projects/python/branches/p3yk python-3k
>
> after building and installing, I get
>
> $ python3.0
> Python 3.0x (p3yk:56529, Jul 24 2007, 15:58:59)
> [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> range(0,10,2)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> SystemError: NULL result without error in PyObject_Call
> >>>

From dalcinl at gmail.com  Wed Jul 25 00:24:20 2007
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Tue, 24 Jul 2007 19:24:20 -0300
Subject: [Python-Dev] Py3k: error during 'make install' in py3k-struni ?
Message-ID: <e7ba66e40707241524v2ad90c51hcb3e63f0a8ea9b08@mail.gmail.com>

Afther checking out the py3k-struni branch, 'make install' issued this:

Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
*** SyntaxError: ('expected string, bytes found',
('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
None))

If this is expected to fail, please forget this.

-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From guido at python.org  Wed Jul 25 00:30:38 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Jul 2007 15:30:38 -0700
Subject: [Python-Dev] Py3k: error during 'make install' in py3k-struni ?
In-Reply-To: <e7ba66e40707241524v2ad90c51hcb3e63f0a8ea9b08@mail.gmail.com>
References: <e7ba66e40707241524v2ad90c51hcb3e63f0a8ea9b08@mail.gmail.com>
Message-ID: <ca471dc20707241530r4957c856ved9bfa5a9a023c6@mail.gmail.com>

Yeah, that particular test is not yet working. (Fixes are welcome --
see http://wiki.python.org/moin/Py3kStrUniTests for how to help.)

I believe I rigged "make install" to continue after this error -- did
the rest of the install complete?

FWIW, a better place to discuss Py3k bleeding edge stuff is
python-3000 at python.org. Sign up at the usual place. (I've CC'ed that
list now -- please remove python-dev from followups.)

--Guido

On 7/24/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> Afther checking out the py3k-struni branch, 'make install' issued this:
>
> Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
> *** SyntaxError: ('expected string, bytes found',
> ('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
> None))
>
> If this is expected to fail, please forget this.
>
> --
> Lisandro Dalc?n
> ---------------
> Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
> Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
> Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
> PTLC - G?emes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg.ewing at canterbury.ac.nz  Wed Jul 25 05:30:20 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Jul 2007 15:30:20 +1200
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <07Jul24.093546pdt.57996@synergy1.parc.xerox.com>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<07Jul24.093546pdt.57996@synergy1.parc.xerox.com>
Message-ID: <46A6C3CC.4080806@canterbury.ac.nz>

Bill Janssen wrote:
 > Someone wrote:
> >Emacs will probably go the way of the vinyl record (though the latter  
> > is seeing a resurgence lately :).
> 
> Doubt it.  Even as we speak, there's probably a student planning to
> implement Python 3 in ELisp as a SOC project...

And run it on a computer built out of valves.
(You get much better sound out of your MP3s
on a valve computer, you know...:-)

--
Greg

From andrew-pythondev at puzzling.org  Wed Jul 25 06:24:04 2007
From: andrew-pythondev at puzzling.org (Andrew Bennetts)
Date: Wed, 25 Jul 2007 14:24:04 +1000
Subject: [Python-Dev] Failure on assorted buildbots - Address already in
	use
In-Reply-To: <e04bdf310707240828o9b0123bs8f0ae394d92b1bee@mail.gmail.com>
References: <46A6105A.10908@gmail.com>
	<e04bdf310707240828o9b0123bs8f0ae394d92b1bee@mail.gmail.com>
Message-ID: <20070725042404.GI15453@steerpike.home.puzzling.org>

Facundo Batista wrote:
> 2007/7/24, Nick Coghlan <ncoghlan at gmail.com>:
> 
> > some of the Debian buildbots happier, but several of the other buildbots
> > are reporting a variety of "Address already in use" errors in the
> > subthreads created by test_urllib2.
> 
> Test pass ok in my machine.
> 
> However, if in another terminal I make...
> 
> >>> import socket
> >>> s = socket.socket()
> >>> s.bind(("127.0.0.1", 8080))
> 
> ...the test fails exactly like in the buildbot.
> 
> Maybe the tests should be changed to use a not-so-standard port.

Or use port 0 to let the operating system pick a free port:

    >>> import socket
    >>> s = socket.socket()
    >>> s.bind(("127.0.0.1", 0))
    >>> s.getsockname()
    ('127.0.0.1', 42669)

-Andrew.


From ncoghlan at gmail.com  Wed Jul 25 12:29:39 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 25 Jul 2007 20:29:39 +1000
Subject: [Python-Dev] -z, -i and -m, maybe bug in runpy?
In-Reply-To: <20070724181824.705933A40A7@sparrow.telecommunity.com>
References: <20070724004010.0E74B3A40AA@sparrow.telecommunity.com>
	<46A5F596.4060309@gmail.com> <46A609B8.3030402@gmail.com>
	<20070724181824.705933A40A7@sparrow.telecommunity.com>
Message-ID: <46A72613.2070805@gmail.com>

Phillip J. Eby wrote:
> At 12:16 AM 7/25/2007 +1000, Nick Coghlan wrote:
>> I've changed the behaviour in r56520 to simply leave the alterations to
>> sys in place when the function terminates. While this is a definite
>> change to the interface (and hence not a candidate for direct
>> backporting), I think the difference is small enough for the 2.5 to 2.6
>> transition.
> 
> Your fix is a definite improvement for me, my "run any importable" patch 
> is looking a lot better.  There's just one problem left, which is that 
> runpy is overwriting sys.argv[0] even if it doesn't need to.  So, when 
> running from a zipfile, sys.argv[0] ends up None, which is wrong.
> 
> However, if I ask runpy not to mess with sys, it creates a new module 
> namespace to run the code in, bringing me right back to square one 
> (i.e., not being run in __main__).  Any thoughts?
> 
> My fallback at this point would be to add an option to run_module() to 
> request that sys.argv[0] be used in place of calling _get_filename().  
> It seems ugly to do that, though, if only because there are already so 
> many arguments to that function.

Adding a get_filename() method to ZipImporter objects would get you 
something better than None in sys.argv[0] (specifically, you would see 
<zipfile_name>/__main__.py)

For a reason I mentioned below, another idea I've had is to tweak the 
run_module semantics again and state that if __name__ already exists in 
sys.modules, then the code will be executed in the existing module, 
rather than in a new module (regardless of the value of the alter_sys 
argument).

This would mean that the -m switch would always use the builtin __main__ 
module, instead of creating a new module the way it does now. This would 
not only fix your current problem, but also avoid any potential issues 
associated with having sys.modules["__main__"] refer to a different 
module while the interpreter is starting up (e.g. while running 
sitecustomize.py, and while doing any package imports needed to locate 
the module to be executed).

I'm actually becoming more and more in favour of reverting run_module 
back to its 2.5 semantics and adding a separate function that does the 
right thing for the -m switch. It is really starting to look like the 
useful behaviour for a module namespace based execfile equivalent and 
the -m switch aren't as closely aligned as I thought they were back when 
I wrote PEP 338.

Cheers,
Nick.



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ironfroggy at gmail.com  Wed Jul 25 14:18:48 2007
From: ironfroggy at gmail.com (Calvin Spealman)
Date: Wed, 25 Jul 2007 08:18:48 -0400
Subject: [Python-Dev] Terminology of "Iterable" and "Iterator"
Message-ID: <76fd5acf0707250518s690ab16dh13bda96abd5d738b@mail.gmail.com>

I got into a discussion about this, which made me think it would make
sense to formalize a distinction between "iterable" and "iterator". To
nearly any python developer I talk with, we can define them as:

iterable - An object which can be passed to the built-in iter()
function, which returns an iterator.

iterator - An object with a .next() method, which is used to invoke
the iteration. An iterator _should_ also be an iterable, and will
nearly always return itself as its own iterator.

Now, the current documentation makes no distinction, and we see this
in the docstring for iter(), which is curious:

    iter(collection) -> iterator

This might indicate that it is using "collection" where I would say
"iterable". Also, the same docstring makes mention of something being
an iterator _or_ a sequence, so I also should bring up that it may be
antiquated, yes?

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/

From ncoghlan at gmail.com  Wed Jul 25 15:26:59 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 25 Jul 2007 23:26:59 +1000
Subject: [Python-Dev] Terminology of "Iterable" and "Iterator"
In-Reply-To: <76fd5acf0707250518s690ab16dh13bda96abd5d738b@mail.gmail.com>
References: <76fd5acf0707250518s690ab16dh13bda96abd5d738b@mail.gmail.com>
Message-ID: <46A74FA3.9090302@gmail.com>

Calvin Spealman wrote:
> This might indicate that it is using "collection" where I would say
> "iterable". Also, the same docstring makes mention of something being
> an iterator _or_ a sequence, so I also should bring up that it may be
> antiquated, yes?

http://docs.python.org/dev/lib/typeiter.html

That page describes the same two categories you do, but doesn't actually 
use the word 'iterable' for the first category (i.e. anything with an 
__iter__ method).

So, yes, I think updating the docs to use the common terminology for 
both categories would be a good thing.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Wed Jul 25 15:30:43 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 25 Jul 2007 23:30:43 +1000
Subject: [Python-Dev] Failure on assorted buildbots - Address already in
 use
In-Reply-To: <20070725042404.GI15453@steerpike.home.puzzling.org>
References: <46A6105A.10908@gmail.com>
	<e04bdf310707240828o9b0123bs8f0ae394d92b1bee@mail.gmail.com>
	<20070725042404.GI15453@steerpike.home.puzzling.org>
Message-ID: <46A75083.3040709@gmail.com>

Andrew Bennetts wrote:
> Facundo Batista wrote:
>> 2007/7/24, Nick Coghlan <ncoghlan at gmail.com>:
>> Maybe the tests should be changed to use a not-so-standard port.
> 
> Or use port 0 to let the operating system pick a free port:
> 
>     >>> import socket
>     >>> s = socket.socket()
>     >>> s.bind(("127.0.0.1", 0))
>     >>> s.getsockname()
>     ('127.0.0.1', 42669)
> 
> -Andrew.

I've changed test_urllib2_localnet to work this way - we'll see if it 
improves matters.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Wed Jul 25 15:38:31 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 25 Jul 2007 23:38:31 +1000
Subject: [Python-Dev] Failure on assorted buildbots - Address already in
 use
In-Reply-To: <46A75083.3040709@gmail.com>
References: <46A6105A.10908@gmail.com>
	<e04bdf310707240828o9b0123bs8f0ae394d92b1bee@mail.gmail.com>
	<20070725042404.GI15453@steerpike.home.puzzling.org>
	<46A75083.3040709@gmail.com>
Message-ID: <46A75257.3030904@gmail.com>

Nick Coghlan wrote:
> Andrew Bennetts wrote:
>> Or use port 0 to let the operating system pick a free port:
>>
>>     >>> import socket
>>     >>> s = socket.socket()
>>     >>> s.bind(("127.0.0.1", 0))
>>     >>> s.getsockname()
>>     ('127.0.0.1', 42669)
>>
>> -Andrew.
> 
> I've changed test_urllib2_localnet to work this way - we'll see if it 
> improves matters.

Yep, looks like that did the trick. Facundo, a similar change may help 
with the GSoC project you're mentoring (the new smtplib tests failed on 
at least one of the buildbots).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From python at rcn.com  Wed Jul 25 16:55:11 2007
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 25 Jul 2007 07:55:11 -0700
Subject: [Python-Dev] Terminology of "Iterable" and "Iterator"
References: <76fd5acf0707250518s690ab16dh13bda96abd5d738b@mail.gmail.com>
Message-ID: <00ee01c7cecb$d2e367b0$f101a8c0@RaymondLaptop1>

The docs do make a distinction and generally follow the definitions given in the glossary for the tuturial.

In the case of iter(collection), I prefer the current wording because the target object need not support __iter__, it is sufficient 
to supply a sequential __getitem__ method.


Raymond




----- Original Message ----- 
From: "Calvin Spealman" <ironfroggy at gmail.com>
To: "Python Mailing List" <python-dev at python.org>
Sent: Wednesday, July 25, 2007 5:18 AM
Subject: [Python-Dev] Terminology of "Iterable" and "Iterator"


>I got into a discussion about this, which made me think it would make
> sense to formalize a distinction between "iterable" and "iterator". To
> nearly any python developer I talk with, we can define them as:
>
> iterable - An object which can be passed to the built-in iter()
> function, which returns an iterator.
>
> iterator - An object with a .next() method, which is used to invoke
> the iteration. An iterator _should_ also be an iterable, and will
> nearly always return itself as its own iterator.
>
> Now, the current documentation makes no distinction, and we see this
> in the docstring for iter(), which is curious:
>
>    iter(collection) -> iterator
>
> This might indicate that it is using "collection" where I would say
> "iterable". Also, the same docstring makes mention of something being
> an iterator _or_ a sequence, so I also should bring up that it may be
> antiquated, yes?
>
> -- 
> Read my blog! I depend on your acceptance of my opinion! I am interesting!
> http://ironfroggy-code.blogspot.com/
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com 

From pje at telecommunity.com  Wed Jul 25 17:18:55 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 25 Jul 2007 11:18:55 -0400
Subject: [Python-Dev] -z, -i and -m, maybe bug in runpy?
In-Reply-To: <46A72613.2070805@gmail.com>
References: <20070724004010.0E74B3A40AA@sparrow.telecommunity.com>
	<46A5F596.4060309@gmail.com> <46A609B8.3030402@gmail.com>
	<20070724181824.705933A40A7@sparrow.telecommunity.com>
	<46A72613.2070805@gmail.com>
Message-ID: <20070725151641.26A273A403D@sparrow.telecommunity.com>

At 08:29 PM 7/25/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> > At 12:16 AM 7/25/2007 +1000, Nick Coghlan wrote:
> >> I've changed the behaviour in r56520 to simply leave the alterations to
> >> sys in place when the function terminates. While this is a definite
> >> change to the interface (and hence not a candidate for direct
> >> backporting), I think the difference is small enough for the 2.5 to 2.6
> >> transition.
> >
> > Your fix is a definite improvement for me, my "run any importable" patch
> > is looking a lot better.  There's just one problem left, which is that
> > runpy is overwriting sys.argv[0] even if it doesn't need to.  So, when
> > running from a zipfile, sys.argv[0] ends up None, which is wrong.
> >
> > However, if I ask runpy not to mess with sys, it creates a new module
> > namespace to run the code in, bringing me right back to square one
> > (i.e., not being run in __main__).  Any thoughts?
> >
> > My fallback at this point would be to add an option to run_module() to
> > request that sys.argv[0] be used in place of calling _get_filename().
> > It seems ugly to do that, though, if only because there are already so
> > many arguments to that function.
>
>Adding a get_filename() method to ZipImporter objects would get you
>something better than None in sys.argv[0] (specifically, you would see
><zipfile_name>/__main__.py)

That's not the goal, actually; I want runpy to leave sys.argv[0] 
alone, so that we maintain the invariant that invoking sys.executable 
with sys.argv will re-run the same effective program.  (And pointing 
to __main__.py inside the zipfile won't work!)


>I'm actually becoming more and more in favour of reverting run_module
>back to its 2.5 semantics and adding a separate function that does the
>right thing for the -m switch.

+1; just make sure it has a way to request *not* overwriting sys.argv[0].


From facundobatista at gmail.com  Wed Jul 25 18:30:33 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 25 Jul 2007 13:30:33 -0300
Subject: [Python-Dev] Failure on assorted buildbots - Address already in
	use
In-Reply-To: <46A75257.3030904@gmail.com>
References: <46A6105A.10908@gmail.com>
	<e04bdf310707240828o9b0123bs8f0ae394d92b1bee@mail.gmail.com>
	<20070725042404.GI15453@steerpike.home.puzzling.org>
	<46A75083.3040709@gmail.com> <46A75257.3030904@gmail.com>
Message-ID: <e04bdf310707250930o7d78af53r5966610c512c8794@mail.gmail.com>

2007/7/25, Nick Coghlan <ncoghlan at gmail.com>:

> Yep, looks like that did the trick. Facundo, a similar change may help
> with the GSoC project you're mentoring (the new smtplib tests failed on
> at least one of the buildbots).

Yes! Alan is already working in this (he sent me today a patch, :).

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From g.brandl at gmx.net  Wed Jul 25 18:52:43 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 25 Jul 2007 18:52:43 +0200
Subject: [Python-Dev] Terminology of "Iterable" and "Iterator"
In-Reply-To: <00ee01c7cecb$d2e367b0$f101a8c0@RaymondLaptop1>
References: <76fd5acf0707250518s690ab16dh13bda96abd5d738b@mail.gmail.com>
	<00ee01c7cecb$d2e367b0$f101a8c0@RaymondLaptop1>
Message-ID: <f87v4p$2qq$1@sea.gmane.org>

Raymond Hettinger schrieb:
> The docs do make a distinction and generally follow the definitions given in
> the glossary for the tuturial.
> 
> In the case of iter(collection), I prefer the current wording because the
> target object need not support __iter__, it is sufficient to supply a
> sequential __getitem__ method.

But as "collection" is never used in that meaning anywhere else, it could
as well be iter(object).

bike-shed-ly yrs,
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.


From greg.ewing at canterbury.ac.nz  Thu Jul 26 04:11:46 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 26 Jul 2007 14:11:46 +1200
Subject: [Python-Dev] Terminology of "Iterable" and "Iterator"
In-Reply-To: <00ee01c7cecb$d2e367b0$f101a8c0@RaymondLaptop1>
References: <76fd5acf0707250518s690ab16dh13bda96abd5d738b@mail.gmail.com>
	<00ee01c7cecb$d2e367b0$f101a8c0@RaymondLaptop1>
Message-ID: <46A802E2.7080504@canterbury.ac.nz>

Raymond Hettinger wrote:
> In the case of iter(collection), I prefer the current wording because the target object need not support __iter__, it is sufficient 
> to supply a sequential __getitem__ method.

Seems to me that should be included in the definition of
an iterable -- i.e. anything for which iter() works is
an iterable.

--
Greg

From pete.forman at westerngeco.com  Thu Jul 26 14:20:57 2007
From: pete.forman at westerngeco.com (Pete Forman)
Date: Thu, 26 Jul 2007 13:20:57 +0100
Subject: [Python-Dev] Two spaces or one?
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
Message-ID: <wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>

The term "French Spacing" is used for two spaces after a period ending
a sentence, for those wishing to do more research.  I have not found
any authoritative answer.  The balance has been towards two spaces
when using a monospaced font.

That points towards a way forward.  Why do programming languages
continue to assume use of a monospaced font?  It was natural when we
used punch cards and line printers, but now?  Python relies on the
indentation but could be flexible about other textual attributes.
-- 
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman at westerngeco.com    -./\.-   the opinion of Schlumberger or
http://petef.port5.com           -./\.-   WesternGeco.


From skip at pobox.com  Thu Jul 26 15:53:18 2007
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 26 Jul 2007 08:53:18 -0500
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
Message-ID: <18088.42830.151782.203270@montanaro.dyndns.org>


    Pete> That points towards a way forward.  Why do programming languages
    Pete> continue to assume use of a monospaced font?  It was natural when
    Pete> we used punch cards and line printers, but now?  Python relies on
    Pete> the indentation but could be flexible about other textual
    Pete> attributes.

Nothing in Python assumes anything about fonts.  That's all a function of
the text editor you use and your editing preferences.  Me, I find it easier
to read code which is displayed or printed with monospaced fonts.  Note,
however, that I've been programming for 30 years.  I started with IBM punch
cards, so I might be a bit biased.

Skip

From ncoghlan at gmail.com  Thu Jul 26 16:08:30 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 27 Jul 2007 00:08:30 +1000
Subject: [Python-Dev] Floating point test_pow failure on the alpha Debian
	buildbot
Message-ID: <46A8AADE.7080506@gmail.com>

test_pow is failing on the alpha Debian buildbot, complaining that a 
negative number can't be raised to a fractional power. Now, to work 
around some bugs in platform implementations of math.fpow(), pow() does 
its own check to see if the exponent is an integer.

The way pow() does that check is to try "iw == floor(iw)", so to see why 
the exception was being triggered, I put a couple of extra output lines 
into the test and got:

*** Number: 1.2299999999999999e+167
*** Floor: 1.2299999999999997e+167

Given that the magnitude of the exponent significantly exceeds the 
precision of an IEEE double, it seems wrong for floor() to be changing 
the mantissa like that (and, on my machine, and all of the other 
buildbots, it doesn't).

I've added an explicit test for this misbehaviour to test_math so at 
least the buildbot gives a clearer indication of what's going wrong, but 
I'm not sure what to do with it beyond that.

Cheers,
Nick.




-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From jcarlson at uci.edu  Thu Jul 26 17:24:22 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu, 26 Jul 2007 08:24:22 -0700
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <18088.42830.151782.203270@montanaro.dyndns.org>
References: <wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
	<18088.42830.151782.203270@montanaro.dyndns.org>
Message-ID: <20070726082147.72AA.JCARLSON@uci.edu>


skip at pobox.com wrote:
> 
> 
>     Pete> That points towards a way forward.  Why do programming languages
>     Pete> continue to assume use of a monospaced font?  It was natural when
>     Pete> we used punch cards and line printers, but now?  Python relies on
>     Pete> the indentation but could be flexible about other textual
>     Pete> attributes.
> 
> Nothing in Python assumes anything about fonts.  That's all a function of
> the text editor you use and your editing preferences.  Me, I find it easier
> to read code which is displayed or printed with monospaced fonts.  Note,
> however, that I've been programming for 30 years.  I started with IBM punch
> cards, so I might be a bit biased.

I started in '98, and I also find monospaced fonts easier to read in
various circumstances (email, code, shells, etc.).  But indeed, Python
makes no assumption about fonts.  A person could use Wingdings for all
Python cares.

 - Josiah


From tim.peters at gmail.com  Thu Jul 26 17:34:02 2007
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 26 Jul 2007 11:34:02 -0400
Subject: [Python-Dev] Floating point test_pow failure on the alpha
	Debian buildbot
In-Reply-To: <46A8AADE.7080506@gmail.com>
References: <46A8AADE.7080506@gmail.com>
Message-ID: <1f7befae0707260834t7832d8d7l5aa5415cac780a23@mail.gmail.com>

[Nick Coghlan]
> test_pow is failing on the alpha Debian buildbot, complaining that a
> negative number can't be raised to a fractional power. Now, to work
> around some bugs in platform implementations of math.fpow(), pow() does
> its own check to see if the exponent is an integer.
>
> The way pow() does that check is to try "iw == floor(iw)", so to see why
> the exception was being triggered, I put a couple of extra output lines
> into the test and got:
>
> *** Number: 1.2299999999999999e+167
> *** Floor: 1.2299999999999997e+167
>
> Given that the magnitude of the exponent significantly exceeds the
> precision of an IEEE double, it seems wrong for floor() to be changing
> the mantissa like that

It is wrong -- the machine representation of test_pow's 1.23e167
literal is an exact integer on any current box, and the floor of any
exact integer is the integer itself.

> (and, on my machine, and all of the other buildbots, it doesn't).
>
> I've added an explicit test for this misbehaviour to test_math so at
> least the buildbot gives a clearer indication of what's going wrong, but
> I'm not sure what to do with it beyond that.

This isn't Python's problem -- a bug report should be opened against
the platform C's implementation of floor(), and the test /should/ fail
in Python so long as the platform floor() remains broken.

From janssen at parc.com  Thu Jul 26 18:48:31 2007
From: janssen at parc.com (Bill Janssen)
Date: Thu, 26 Jul 2007 09:48:31 PDT
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com> 
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
Message-ID: <07Jul26.094838pdt."57996"@synergy1.parc.xerox.com>

> The term "French Spacing" is used for two spaces after a period ending
> a sentence, for those wishing to do more research.  I have not found
> any authoritative answer.

This phrase sounded to me like one of the slurs the English invented
during their various wars with the Dutch and the French (e.g. "Dutch
courage"), so I looked into it a bit.

The practice of double-spacing after a period was standard even with
proportional fonts before the advent of the Linotype machine, the
mechanical design of which didn't accommodate it.

See http://webword.com/reports/period.html.

``If the [Linotype machine] operator typed two spaces in a row, you
had two wedges next to each other, and that tended to gum up the
operation.  Clients who insisted could be accommodated by typing an
en-space followed by a justifier-space, but printers charged extra for
it and ridiculed it as 'French Spacing, oo-la-la, you want it all
fancy, huh? Well it'll cost ya, bub, and plenty too...' and soon it
became unfashionable in the US.''

Bill

From g.brandl at gmx.net  Thu Jul 26 19:04:28 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 26 Jul 2007 19:04:28 +0200
Subject: [Python-Dev] [OT] Monospaced fonts
In-Reply-To: <18088.42830.151782.203270@montanaro.dyndns.org>
References: <46A56193.6010500@acm.org>	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>	<18085.62751.929027.48149@montanaro.dyndns.org>	<20070724125133.GA19388@panix.com>	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
	<18088.42830.151782.203270@montanaro.dyndns.org>
Message-ID: <f8ak6q$g6s$1@sea.gmane.org>

skip at pobox.com schrieb:
>     Pete> That points towards a way forward.  Why do programming languages
>     Pete> continue to assume use of a monospaced font?  It was natural when
>     Pete> we used punch cards and line printers, but now?  Python relies on
>     Pete> the indentation but could be flexible about other textual
>     Pete> attributes.
> 
> Nothing in Python assumes anything about fonts.  That's all a function of
> the text editor you use and your editing preferences.  Me, I find it easier
> to read code which is displayed or printed with monospaced fonts.  Note,
> however, that I've been programming for 30 years.  I started with IBM punch
> cards, so I might be a bit biased.

Though being notably younger ;), I couldn't live without monospaced fonts for
source code.  Apart from being easier to read, it is essential for sketches
or things that must be aligned, such as the class schema in SocketServer.py.

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.


From dalcinl at gmail.com  Thu Jul 26 19:06:47 2007
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Thu, 26 Jul 2007 14:06:47 -0300
Subject: [Python-Dev] interaction between locals, builtins and except clause
Message-ID: <e7ba66e40707261006s71826ce8p73194134992697f3@mail.gmail.com>

Porting to Py3K, I modified a function like the followin, using a
trick for it working in Py2.x .

    def __iter__(self):
        if self == _mpi.INFO_NULL:
            return
        try:    range = xrange
        except: pass
        nkeys = _mpi.info_get_nkeys(self)
        for nthkey in range(nkeys):
            yield _mpi.info_get_nthkey(self, nthkey)

However, I've got in my unittests (running with py3k)

ERROR: testPyMethods (__main__.TestInfo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/unittest/test_info.py", line 123, in testPyMethods
    for key in INFO:
  File "/u/dalcinl/lib/python/mpi4py/MPI.py", line 937, in __iter__
    for nthkey in range(nkeys):
UnboundLocalError: local variable 'range' referenced before assignment


I am not completelly sure if this is expected (it is, regarding
implementation, but perhaps not regarding Python as a language),  so
I post this for your consideration.


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

From g.brandl at gmx.net  Thu Jul 26 19:14:02 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 26 Jul 2007 19:14:02 +0200
Subject: [Python-Dev] interaction between locals,
	builtins and except clause
In-Reply-To: <e7ba66e40707261006s71826ce8p73194134992697f3@mail.gmail.com>
References: <e7ba66e40707261006s71826ce8p73194134992697f3@mail.gmail.com>
Message-ID: <f8akon$hvm$1@sea.gmane.org>

Lisandro Dalcin schrieb:
> Porting to Py3K, I modified a function like the followin, using a
> trick for it working in Py2.x .
> 
>     def __iter__(self):
>         if self == _mpi.INFO_NULL:
>             return
>         try:    range = xrange
>         except: pass
>         nkeys = _mpi.info_get_nkeys(self)
>         for nthkey in range(nkeys):
>             yield _mpi.info_get_nthkey(self, nthkey)
> 
> However, I've got in my unittests (running with py3k)
> 
> ERROR: testPyMethods (__main__.TestInfo)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "tests/unittest/test_info.py", line 123, in testPyMethods
>     for key in INFO:
>   File "/u/dalcinl/lib/python/mpi4py/MPI.py", line 937, in __iter__
>     for nthkey in range(nkeys):
> UnboundLocalError: local variable 'range' referenced before assignment
> 
> 
> I am not completelly sure if this is expected (it is, regarding
> implementation, but perhaps not regarding Python as a language),  so
> I post this for your consideration.

Yes, this is expected. By an assignment to range anywhere in a function
scope, the name is marked as a local and won't ever be looked up in the
global namespace.

I'd move the range = xrange part at the module top, or just bring the 2.x
version in a state where one run of 2to3 produces a working 3.0 version.

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


From hasan.diwan at gmail.com  Fri Jul 27 00:05:48 2007
From: hasan.diwan at gmail.com (Hasan Diwan)
Date: Thu, 26 Jul 2007 15:05:48 -0700
Subject: [Python-Dev] test_asyncore fails intermittently on Darwin
Message-ID: <2cda2fc90707261505tdd9a0f1t861b5801c37ad11e@mail.gmail.com>

test_asyncore fails intermittently on Darwin in trunk rev 56558; it
seems a matter of executing the test too fast and not waiting for the
TCP_WAIT state to expire. I think somebody encountered this problem
previously with another module (socket_server) and I'm unsure how that
was sorted.
-- 
Cheers,
Hasan Diwan <hasan.diwan at gmail.com>

From alan.mcintyre at gmail.com  Fri Jul 27 01:18:43 2007
From: alan.mcintyre at gmail.com (Alan McIntyre)
Date: Thu, 26 Jul 2007 19:18:43 -0400
Subject: [Python-Dev] test_asyncore fails intermittently on Darwin
In-Reply-To: <2cda2fc90707261505tdd9a0f1t861b5801c37ad11e@mail.gmail.com>
References: <2cda2fc90707261505tdd9a0f1t861b5801c37ad11e@mail.gmail.com>
Message-ID: <1d36917a0707261618oac94f20l98f464a2ab1edc4e@mail.gmail.com>

Thanks Hasan, I'll see if I can dig up what they did and make some
changes to fix the asyncore tests.

Regards,
Alan

On 7/26/07, Hasan Diwan <hasan.diwan at gmail.com> wrote:
> test_asyncore fails intermittently on Darwin in trunk rev 56558; it
> seems a matter of executing the test too fast and not waiting for the
> TCP_WAIT state to expire. I think somebody encountered this problem
> previously with another module (socket_server) and I'm unsure how that
> was sorted.
> --
> Cheers,
> Hasan Diwan <hasan.diwan at gmail.com>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/alan.mcintyre%40gmail.com
>

From greg.ewing at canterbury.ac.nz  Fri Jul 27 02:18:59 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 27 Jul 2007 12:18:59 +1200
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
Message-ID: <46A939F3.4020304@canterbury.ac.nz>

Pete Forman wrote:
> Why do programming languages
> continue to assume use of a monospaced font?

Programming *languages* don't -- I know of no
(serious[1]) language that requires a monospaced font
in order to work correctly. Even in Python, as long
as you don't mix tabs and spaces, indentation still
works since it's all at the beginning of a line.

Certain *conventions* sometimes used by programmers
might require it, but that's a different thing.

[1] Brainf**k is an obvious exception.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From greg.ewing at canterbury.ac.nz  Fri Jul 27 02:26:47 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 27 Jul 2007 12:26:47 +1200
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <18088.42830.151782.203270@montanaro.dyndns.org>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
	<18088.42830.151782.203270@montanaro.dyndns.org>
Message-ID: <46A93BC7.6090904@canterbury.ac.nz>

skip at pobox.com wrote:
> Me, I find it easier
> to read code which is displayed or printed with monospaced fonts.  Note,
> however, that I've been programming for 30 years.  I started with IBM punch
> cards, so I might be a bit biased.

I normally use monospaced fonts for Python, but in my
Think Pascal days I wrote most of my Pascal in Geneva.
I thought it actually looked quite nice that way,
especially with TP's auto-formatting.

It depends a lot on the font, though -- I don't think
I'd like to program in Times, for instance.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From greg.ewing at canterbury.ac.nz  Fri Jul 27 02:36:25 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 27 Jul 2007 12:36:25 +1200
Subject: [Python-Dev] [OT] Monospaced fonts
In-Reply-To: <f8ak6q$g6s$1@sea.gmane.org>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
	<18088.42830.151782.203270@montanaro.dyndns.org>
	<f8ak6q$g6s$1@sea.gmane.org>
Message-ID: <46A93E09.9020807@canterbury.ac.nz>

Georg Brandl wrote:
> I couldn't live without monospaced fonts for
> source code.  Apart from being easier to read, it is essential for sketches
> or things that must be aligned, such as the class schema in SocketServer.py.

This just goes to show we're living in the dark
ages wrt source code representation. We should
be able to write our comments in HTML with
embedded SVG diagrams. :-)

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From turnbull at sk.tsukuba.ac.jp  Fri Jul 27 04:58:30 2007
From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Fri, 27 Jul 2007 11:58:30 +0900
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <18088.42830.151782.203270@montanaro.dyndns.org>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
	<18088.42830.151782.203270@montanaro.dyndns.org>
Message-ID: <87wswmimcp.fsf@uwakimon.sk.tsukuba.ac.jp>

skip at pobox.com writes:

 > I started with IBM punch cards

Definitely a character cell format.

From kbk at shore.net  Fri Jul 27 06:09:14 2007
From: kbk at shore.net (Kurt B. Kaiser)
Date: Fri, 27 Jul 2007 00:09:14 -0400 (EDT)
Subject: [Python-Dev] Weekly Python Patch/Bug Summary
Message-ID: <200707270409.l6R49EEW007231@hampton.thirdcreek.com>

Patch / Bug Summary
___________________

Patches :  399 open ( +5) /  3836 closed ( +9) /  4235 total (+14)
Bugs    : 1056 open (+10) /  6776 closed ( +3) /  7832 total (+13)
RFE     :  263 open ( +1) /   294 closed ( +1) /   557 total ( +2)

New / Reopened Patches
______________________

utilize 2.5 try/except/finally in contextlib  (2007-07-19)
       http://python.org/sf/1757118  opened by  Philip Jenvey

Fix ptcp154 encoding cyrillic_asian alias  (2007-07-19)
       http://python.org/sf/1757126  opened by  Philip Jenvey

Add support for seeking/writing beyond EOF to io.BytesIO  (2007-07-20)
CLOSED http://python.org/sf/1757683  opened by  Alexandre Vassalotti

struni: make test_ucn pass  (2007-07-20)
CLOSED http://python.org/sf/1757758  opened by  Alexandre Vassalotti

struni: fix str/bytes errors for test_oldmailbox  (2007-07-20)
CLOSED http://python.org/sf/1757774  opened by  Alexandre Vassalotti

setuptools support for bazaar vcs  (2007-07-20)
CLOSED http://python.org/sf/1757782  opened by  Barry A. Warsaw

struni: make test_mailbox and test_old_mailbox pass  (2007-07-20)
CLOSED http://python.org/sf/1757839  opened by  Alexandre Vassalotti

struni: Fix test_macostools  (2007-07-22)
CLOSED http://python.org/sf/1758570  opened by  Jeffrey Yasskin

pyexpat unit tests - str/uni branch  (2007-07-23)
CLOSED http://python.org/sf/1759016  opened by  Joe Gregorio

clean up Solaris port and allow C99 extension modules  (2007-07-23)
       http://python.org/sf/1759169  opened by  Zooko O'Whielacronx

struni pulldom: Don't use 'types' to check strings  (2007-07-24)
       http://python.org/sf/1759922  opened by  Alexandre Vassalotti

Cross Compiling Python  (2007-07-25)
       http://python.org/sf/1760089  opened by  Yegnesh

ZipFile.write fails with bad modification time  (2007-07-25)
       http://python.org/sf/1760357  opened by  Grzegorz Adam Hankiewicz

struni: Fix test_aepack by converting 4cc's to bytes  (2007-07-26)
       http://python.org/sf/1761465  opened by  Jeffrey Yasskin

Patches Closed
______________

Show Location of Unicode Escape Errors  (2007-07-18)
       http://python.org/sf/1755885  closed by  gvanrossum

Add support for seeking/writing beyond EOF to io.BytesIO  (2007-07-20)
       http://python.org/sf/1757683  closed by  gvanrossum

struni: make test_ucn pass  (2007-07-20)
       http://python.org/sf/1757758  closed by  gvanrossum

struni: fix str/bytes errors for test_oldmailbox  (2007-07-20)
       http://python.org/sf/1757774  closed by  avassalotti

setuptools support for bazaar vcs  (2007-07-20)
       http://python.org/sf/1757782  closed by  pje

struni: make test_mailbox and test_old_mailbox pass  (2007-07-20)
       http://python.org/sf/1757839  closed by  gvanrossum

PEP 3123 implementation  (2007-05-13)
       http://python.org/sf/1718153  closed by  loewis

struni: Fix test_macostools  (2007-07-22)
       http://python.org/sf/1758570  closed by  gvanrossum

pyexpat unit tests - str/uni branch  (2007-07-23)
       http://python.org/sf/1759016  closed by  gvanrossum

New / Reopened Bugs
___________________

Python 2.5.1 fails to build on AIX  (2007-07-18)
       http://python.org/sf/1756343  opened by  Tom Epperly

reference count discrepancy, PyErr_Print vs. PyErr_Clear  (2007-07-18)
       http://python.org/sf/1756389  opened by  Jon Klein

IDLE + BeautifulSoup = Error  (2007-07-19)
       http://python.org/sf/1757057  opened by  Tal Einat

Pickle fails on BeautifulSoup's navigableString instances  (2007-07-19)
       http://python.org/sf/1757062  opened by  Tal Einat

Zipfile robustness  (2007-07-19)
       http://python.org/sf/1757072  opened by  Chris Mellon

Crash in PyObject_Malloc  (2007-07-21)
       http://python.org/sf/1758146  opened by  Tim Bishop

Documentation of descriptors needs more detail  (2007-07-22)
       http://python.org/sf/1758696  opened by  L. Peter Deutsch

unicode(None,charset) raise TypeError  (2007-07-23)
       http://python.org/sf/1758804  opened by  Guillaume

subprocess.call fails with unicode strings in command line  (2007-07-24)
       http://python.org/sf/1759845  opened by  Matt

poll() on cygwin sometimes fails [PATCH]  (2007-07-24)
       http://python.org/sf/1759997  opened by  Brian Warner

No docs for list comparison  (2007-07-25)
       http://python.org/sf/1760423  opened by  Kent Johnson

logging.FileHandler may throw exception in flush()  (2007-07-25)
       http://python.org/sf/1760556  opened by  J Livingston

pickle - cannot unpickle circular deps with custom __hash__  (2007-07-26)
       http://python.org/sf/1761028  opened by  Martin S??kraut

Bugs Closed
___________

struni: help() is broken  (2007-07-11)
       http://python.org/sf/1751932  closed by  kbk

Docstring for codecs.lookup is incorrect  (2007-07-15)
       http://python.org/sf/1754453  closed by  doerwalter

New / Reopened RFE
__________________

splice() function for itertools  (2007-07-20)
CLOSED http://python.org/sf/1757395  opened by  Alexander Dutton

Allow opening just an editor window  (2007-07-21)
       http://python.org/sf/1757831  opened by  Tal Einat

RFE Closed
__________

splice() function for itertools  (2007-07-20)
       http://python.org/sf/1757395  closed by  rhettinger


From g.brandl at gmx.net  Fri Jul 27 08:49:48 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 27 Jul 2007 08:49:48 +0200
Subject: [Python-Dev] [OT] Monospaced fonts
In-Reply-To: <46A93E09.9020807@canterbury.ac.nz>
References: <46A56193.6010500@acm.org>	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>	<18085.62751.929027.48149@montanaro.dyndns.org>	<20070724125133.GA19388@panix.com>	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>	<18088.42830.151782.203270@montanaro.dyndns.org>	<f8ak6q$g6s$1@sea.gmane.org>
	<46A93E09.9020807@canterbury.ac.nz>
Message-ID: <f8c4i9$l0c$1@sea.gmane.org>

Greg Ewing schrieb:
> Georg Brandl wrote:
>> I couldn't live without monospaced fonts for
>> source code.  Apart from being easier to read, it is essential for sketches
>> or things that must be aligned, such as the class schema in SocketServer.py.
> 
> This just goes to show we're living in the dark ages wrt source code
> representation. We should be able to write our comments in HTML with
> embedded SVG diagrams. :-)

PowerPoint, coding edition?

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.


From p.f.moore at gmail.com  Fri Jul 27 10:07:48 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 27 Jul 2007 09:07:48 +0100
Subject: [Python-Dev] [OT] Monospaced fonts
In-Reply-To: <f8c4i9$l0c$1@sea.gmane.org>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
	<18088.42830.151782.203270@montanaro.dyndns.org>
	<f8ak6q$g6s$1@sea.gmane.org> <46A93E09.9020807@canterbury.ac.nz>
	<f8c4i9$l0c$1@sea.gmane.org>
Message-ID: <79990c6b0707270107s27cb9e22g74db9309f1f8a12f@mail.gmail.com>

On 27/07/07, Georg Brandl <g.brandl at gmx.net> wrote:
> PowerPoint, coding edition?

You just had to give them the idea, didn't you? :-)
Paul.

From greg.ewing at canterbury.ac.nz  Sat Jul 28 03:46:25 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 28 Jul 2007 13:46:25 +1200
Subject: [Python-Dev] [OT] Monospaced fonts
In-Reply-To: <f8c4i9$l0c$1@sea.gmane.org>
References: <46A56193.6010500@acm.org>
	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>
	<18085.62751.929027.48149@montanaro.dyndns.org>
	<20070724125133.GA19388@panix.com>
	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>
	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>
	<18088.42830.151782.203270@montanaro.dyndns.org>
	<f8ak6q$g6s$1@sea.gmane.org>
	<46A93E09.9020807@canterbury.ac.nz> <f8c4i9$l0c$1@sea.gmane.org>
Message-ID: <46AA9FF1.6000503@canterbury.ac.nz>

Georg Brandl wrote:
> Greg Ewing schrieb:
>
>>This just goes to show we're living in the dark ages wrt source code
>>representation. We should be able to write our comments in HTML with
>>embedded SVG diagrams. :-)
> 
> PowerPoint, coding edition?

It'll probably be called Microsoft Visual Presentation and
Solution Studio (with Home, Office, Professional and Enterprise
editions).

--
Greg

From martin at v.loewis.de  Sat Jul 28 11:41:31 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 28 Jul 2007 11:41:31 +0200
Subject: [Python-Dev] Two spaces or one?
In-Reply-To: <46A93BC7.6090904@canterbury.ac.nz>
References: <46A56193.6010500@acm.org>	<97B54309-C5D2-4A7D-B18E-EEA637D3A533@python.org>	<18085.62751.929027.48149@montanaro.dyndns.org>	<20070724125133.GA19388@panix.com>	<ca471dc20707240754r322238faqa72edccc4eae8adf@mail.gmail.com>	<wswnxsnq.fsf@wgmail2.gatwick.eur.slb.com>	<18088.42830.151782.203270@montanaro.dyndns.org>
	<46A93BC7.6090904@canterbury.ac.nz>
Message-ID: <46AB0F4B.4000100@v.loewis.de>

> I normally use monospaced fonts for Python, but in my
> Think Pascal days I wrote most of my Pascal in Geneva.

I had to read that sentence twice to understand that
you didn't actually go to Switzerland to write Pascal
(although this would have been very appropriate).

Regards,
Martin

From pc at gafol.net  Sat Jul 28 13:11:23 2007
From: pc at gafol.net (Paul Colomiets)
Date: Sat, 28 Jul 2007 14:11:23 +0300
Subject: [Python-Dev] Bus error in transformer.py
Message-ID: <46AB245B.9050002@gafol.net>

Hi!

I'm still working on bug:
http://python.org/sf/1720241

First thing I've found is that `compile` works OK, but `compiler.parse` not.
And I feel that It's bug in python, or python port, because I'm getting 
Bus error
on some stage when I'm tracing execution and trying to backtrace. Also 
`parser.expr`
passes ok, and error raises in Transformer class.
 
I've attached part of the debugger session, and script I use.

Any hints how to debug it further?

--
Paul.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pdbsession.txt
Url: http://mail.python.org/pipermail/python-dev/attachments/20070728/7f23e2e2/attachment-0001.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1.py
Type: text/x-python
Size: 364 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20070728/7f23e2e2/attachment-0001.py 

From skip at pobox.com  Sat Jul 28 14:00:52 2007
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 28 Jul 2007 07:00:52 -0500
Subject: [Python-Dev] Bus error in transformer.py
In-Reply-To: <46AB245B.9050002@gafol.net>
References: <46AB245B.9050002@gafol.net>
Message-ID: <18091.12276.612867.511850@montanaro.dyndns.org>


    Paul> And I feel that It's bug in python, or python port, because I'm
    Paul> getting Bus error on some stage when I'm tracing execution and
    Paul> trying to backtrace. 

Have you run it under control of a C-level debugger (gdb, dbx, etc) to see
where the bus error occurs?

Skip

From martin at v.loewis.de  Sat Jul 28 15:42:17 2007
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 28 Jul 2007 15:42:17 +0200
Subject: [Python-Dev] Bus error in transformer.py
In-Reply-To: <46AB245B.9050002@gafol.net>
References: <46AB245B.9050002@gafol.net>
Message-ID: <46AB47B9.6010504@v.loewis.de>

> Any hints how to debug it further?

You should run it under gdb, or attach to the interpreter
from gdb.

Could it be that you get a stack overflow? To my knowledge,
stack space is very scarce on FreeBSD if you use threads.

Regards,
Martin


From pc at gafol.net  Sat Jul 28 16:21:42 2007
From: pc at gafol.net (Paul Colomiets)
Date: Sat, 28 Jul 2007 17:21:42 +0300
Subject: [Python-Dev] Bus error in transformer.py
In-Reply-To: <46AB47B9.6010504@v.loewis.de>
References: <46AB245B.9050002@gafol.net> <46AB47B9.6010504@v.loewis.de>
Message-ID: <46AB50F6.4060900@gafol.net>

Martin v. L?wis wrote:
> You should run it under gdb, or attach to the interpreter
> from gdb.
>   
I've run it with gdb before (when posted  a bug),
and sometimes I got a huge traceback with
10000+ lines and sometimes less than 100
full of question marks so I've decided it's not of
a great interest. Today I've got quite good
backtrace :)
> Could it be that you get a stack overflow? To my knowledge,
> stack space is very scarce on FreeBSD if you use threads.
>   
Well, yes it is!

I've tested stack overflow before without using threads,
and it throws an exception as expected.

But this:
  def test():
      test()

  from threading import Thread
  t = Thread(target = test)
  t.start()
  t.join()
Produces "Segmentation fault" on python2.4 and "Bus error" on
python2.5.

Following line:
  threading.stack_size(1<<19)
Fixes this problem for python2.5.

Thanks a lot. I think I'll set up it in sitecustomize.py.
I don't know but maybe you should consider change platform defaults.

--
Paul.

From martin at v.loewis.de  Sat Jul 28 18:18:07 2007
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 28 Jul 2007 18:18:07 +0200
Subject: [Python-Dev] Bus error in transformer.py
In-Reply-To: <46AB50F6.4060900@gafol.net>
References: <46AB245B.9050002@gafol.net> <46AB47B9.6010504@v.loewis.de>
	<46AB50F6.4060900@gafol.net>
Message-ID: <46AB6C3F.8030202@v.loewis.de>

> Thanks a lot. I think I'll set up it in sitecustomize.py.
> I don't know but maybe you should consider change platform defaults.

Such a patch should be contributed by a FreeBSD expert. Different
versions of FreeBSD behave differently, with too many conditions to
consider. It's a mess. The simplest thing to do would be to stop
supporting threading on FreeBSD.

Regards,
Martin

From aahz at pythoncraft.com  Sat Jul 28 20:42:43 2007
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 28 Jul 2007 11:42:43 -0700
Subject: [Python-Dev] Bus error in transformer.py
In-Reply-To: <46AB245B.9050002@gafol.net>
References: <46AB245B.9050002@gafol.net>
Message-ID: <20070728184243.GA10578@panix.com>

On Sat, Jul 28, 2007, Paul Colomiets wrote:
>
> [...]

Because I can't resist: shouldn't that be a "truck error" if you're using
transformer.py?



For those who don't get it:
http://en.wikipedia.org/wiki/Transformers_%28fiction%29
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

This is Python.  We don't care much about theory, except where it intersects 
with useful practice.  

From status at bugs.python.org  Sun Jul 29 02:00:55 2007
From: status at bugs.python.org (Tracker)
Date: Sun, 29 Jul 2007 00:00:55 +0000 (UTC)
Subject: [Python-Dev] Summary of Tracker Issues
Message-ID: <20070729000055.BC10E780BC@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (07/22/07 - 07/29/07)
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.


 1276 open ( +3) / 11101 closed ( +2) / 12377 total ( +5)

Average duration of open issues: 688 days.
Median duration of open issues: 554 days.

Open Issues Breakdown
   open  1274 ( +2)
pending     2 ( +1)

Issues Created Or Reopened (5)
______________________________

struni: Fix test_macostools                                      07/22/07
CLOSED http://bugs.python.org/issue1758570 created  jyasskin       

Documentation of descriptors needs more detail                   07/23/07
       http://bugs.python.org/issue1758696 created  lpd            

unicode(None,charset) raise TypeError                            07/23/07
       http://bugs.python.org/issue1758804 created  guillaumb      

pyexpat unit tests - str/uni branch                              07/23/07
CLOSED http://bugs.python.org/issue1759016 created  jcgregorio     

clean up Solaris port and allow C99 extension modules            07/23/07
       http://bugs.python.org/issue1759169 created  zooko          



Issues Now Closed (3)
_____________________

splice() function for itertools                                    2 days
       http://bugs.python.org/issue1757395 rhettinger     

struni: Fix test_macostools                                        1 days
       http://bugs.python.org/issue1758570 gvanrossum     

pyexpat unit tests - str/uni branch                                0 days
       http://bugs.python.org/issue1759016 gvanrossum     



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070729/350e1acd/attachment.html 

From lcaamano at gmail.com  Sun Jul 29 03:04:29 2007
From: lcaamano at gmail.com (lcaamano)
Date: Sun, 29 Jul 2007 01:04:29 -0000
Subject: [Python-Dev] uuid creation not thread-safe?
In-Reply-To: <ca471dc20707201052p68883fc5l3efd8ecc5cfd497f@mail.gmail.com>
References: <ca471dc20707201052p68883fc5l3efd8ecc5cfd497f@mail.gmail.com>
Message-ID: <1185671069.839769.274620@z28g2000prd.googlegroups.com>


On Jul 20, 1:52 pm, "Guido van Rossum" <gu... at python.org> wrote:
> I discovered what appears to be a thread-unsafety inuuid.py. This is
> in the trunk as well as in 3.x; I'm using the trunk here for easy
> reference. There's some code around like 395:
>
>     import ctypes, ctypes.util
>     _buffer = ctypes.create_string_buffer(16)
>
> This creates a *global* buffer which is used as the output parameter
> to later calls to _uuid_generate_random() and _uuid_generate_time().
> For example, around line 481, in uuid1():
>
>         _uuid_generate_time(_buffer)
>         returnUUID(bytes=_buffer.raw)
>
> Clearly if two threads do this simultaneously they are overwriting
> _buffer in unpredictable order. There are a few other occurrences of
> this too.
>
> I find it somewhat disturbing that what seems a fairly innocent
> function that doesn't *appear* to have global state is nevertheless
> not thread-safe. Would it be wise to fix this, e.g. by allocating a
> fresh output buffer inside uuid1() and other callers?
>


I didn't find any reply to this, which is odd, so forgive me if it's
old news.

I agree with you that it's not thread safe and that a local buffer in
the stack should fix it.

Just for reference, the thread-safe uuid extension we've been using
since python 2.1, which I don't recall where we borrow it from, uses a
local buffer in the stack.  It looks like this:

-----begin uuid.c--------------

static char uuid__doc__ [] =
"DCE compatible Universally Unique Identifier module";

#include "Python.h"
#include <uuid/uuid.h>

static char uuidgen__doc__ [] =
"Create a new DCE compatible UUID value";

static PyObject *
uuidgen(void)
{
uuid_t out;
char buf[48];

    uuid_generate(out);
    uuid_unparse(out, buf);
    return PyString_FromString(buf);
}

static PyMethodDef uuid_methods[] = {
    {"uuidgen", uuidgen, 0, uuidgen__doc__},
    {NULL,      NULL}        /* Sentinel */
};

DL_EXPORT(void)
inituuid(void)
{
    Py_InitModule4("uuid",
               uuid_methods,
               uuid__doc__,
               (PyObject *)NULL,
               PYTHON_API_VERSION);
}

-----end uuid.c--------------


It also seems that using uuid_generate()/uuid_unparse() should be
faster than using uuid_generate_random() and then creating a python
object to call its __str__ method.  If so, it would be nice if the
uuid.py module also provided equivalent fast versions that returned
strings instead of objects.


--
Luis P Caamano
Atlanta, GA, USA


From exarkun at divmod.com  Mon Jul 30 12:02:02 2007
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Mon, 30 Jul 2007 06:02:02 -0400
Subject: [Python-Dev] [Python-3000] test_asyncore fails intermittently
	on Darwin
In-Reply-To: <2cda2fc90707292340k7eb11f2w82003e6f705438c3@mail.gmail.com>
Message-ID: <20070730100205.4947.1525764917.divmod.quotient.16594@ohm>

On Sun, 29 Jul 2007 23:40:29 -0700, Hasan Diwan <hasan.diwan at gmail.com> wrote:
>The issue seems to be in the socket.py close method. It needs to sleep
>socket.SO_REUSEADDR seconds before returning. Yes, it is a simple fix
>in python, but the socket code is C. I found some code in socket.py
>and made the changes. Patch is available at
>http://sourceforge.net/tracker/index.php?func=detail&aid=1763387&group_id=5470&atid=305470
>-- enjoy your week.

Uh, no, that's basically totally wrong.  Details on the ticket.

>--
>Cheers,
>Hasan Diwan <hasan.diwan at gmail.com>
>_______________________________________________
>Python-3000 mailing list
>Python-3000 at python.org
>http://mail.python.org/mailman/listinfo/python-3000
>Unsubscribe: http://mail.python.org/mailman/options/python-3000/exarkun%40divmod.com
>

From alan.mcintyre at gmail.com  Mon Jul 30 12:27:03 2007
From: alan.mcintyre at gmail.com (Alan McIntyre)
Date: Mon, 30 Jul 2007 06:27:03 -0400
Subject: [Python-Dev] [Python-3000] test_asyncore fails intermittently
	on Darwin
In-Reply-To: <2cda2fc90707292340k7eb11f2w82003e6f705438c3@mail.gmail.com>
References: <2cda2fc90707261505tdd9a0f1t861b5801c37ad11e@mail.gmail.com>
	<1d36917a0707261618oac94f20l98f464a2ab1edc4e@mail.gmail.com>
	<2cda2fc90707292338pff060c1i810737dcf6d5df54@mail.gmail.com>
	<2cda2fc90707292340k7eb11f2w82003e6f705438c3@mail.gmail.com>
Message-ID: <1d36917a0707300327sedaf1eate1ed119b3ad6ed04@mail.gmail.com>

Hasan,

We made a change to bind the server to port 0, so that an unused port
is selected for each test.  I wasn't able to reproduce the failure
after making this change; is the current trunk still failing for you?

Cheers,
Alan

On 7/30/07, Hasan Diwan <hasan.diwan at gmail.com> wrote:
> The issue seems to be in the socket.py close method. It needs to sleep
> socket.SO_REUSEADDR seconds before returning. Yes, it is a simple fix
> in python, but the socket code is C. I found some code in socket.py
> and made the changes. Patch is available at
> http://sourceforge.net/tracker/index.php?func=detail&aid=1763387&group_id=5470&atid=305470
> -- enjoy your week.
> --
> Cheers,
> Hasan Diwan <hasan.diwan at gmail.com>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/alan.mcintyre%40gmail.com
>

From facundobatista at gmail.com  Mon Jul 30 15:29:23 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 30 Jul 2007 10:29:23 -0300
Subject: [Python-Dev] [Python-3000] test_asyncore fails intermittently
	on Darwin
In-Reply-To: <20070730100205.4947.1525764917.divmod.quotient.16594@ohm>
References: <2cda2fc90707292340k7eb11f2w82003e6f705438c3@mail.gmail.com>
	<20070730100205.4947.1525764917.divmod.quotient.16594@ohm>
Message-ID: <e04bdf310707300629s53fcb476o4a950dd7a89644f2@mail.gmail.com>

2007/7/30, Jean-Paul Calderone <exarkun at divmod.com>:

> Uh, no, that's basically totally wrong.  Details on the ticket.

I rejected it.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From ndbecker2 at gmail.com  Mon Jul 30 15:50:38 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Mon, 30 Jul 2007 09:50:38 -0400
Subject: [Python-Dev] add bool type to optparse
Message-ID: <f8kqcs$15q$1@sea.gmane.org>

Subject says it all.


From steve at holdenweb.com  Mon Jul 30 20:59:02 2007
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 30 Jul 2007 14:59:02 -0400
Subject: [Python-Dev] Cygwin: Problem detecting subprocess termination after
 _spawn_posix in distutils?
Message-ID: <f8lcd3$9ou$1@sea.gmane.org>

I've been trying to install PIL 1.1.6 for several days now under Cygwin. 
I have tried the Cygwin, Image and distutils lists with nary a pointer, 
so I wondered whether python-dev might lead me to an answer (other than 
"Stop using Cygwin" ;-)

Here's the output from a failed setup run with a couple of debug prints 
inserted which should report how sub-process termination occurred - it 
hangs after this output.

$ python setup.py build
running build
running build_py
running build_ext
building '_imaging' extension
SPAWN: ['gcc', '-fno-strict-aliasing', '-DNDEBUG', '-g', '-O3', '-Wall', 
'-Wstrict-prototypes', '-DHAVE_LIBZ', '-IlibImaging', '-I/usr/include', 
'-I/usr/include/python2.5', '-c', 'libImaging/Chops.c', '-o', 
'build/temp.cygwin-1.5.24-i686-2.5/libImaging/Chops.o'] PATH? 1 V: 0 D:0
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
-DHAVE_LIBZ -IlibImaging -I/usr/include -I/usr/include/python2.5 -c 
libImaging/Chops.c -o build/temp.cygwin-1.5.24-i686-2.5/libImaging/Chops.o
Are we done yet? Waiting on pid 3280

I have to kill a python.exe process that's left running in the 
background if I CTRL/C the build. Otherwise it will spend all night in a 
tight loop. The compilation is finished when I kill the process, and the 
next compile will begin if I repeat the command.

I extracted the _spawn_all function from distutils/spawn.py, hacked some 
exceptions and ran it under command line control.

That worked fine with other subtasks, so I wondered whether this was a 
failure specific to gcc, which would seem kind of unlikely. I ran the 
same compile using my test function standing alone, seeing success:

sholden at bigboy ~/Imaging-1.1.6
$ python ~/Projects/Python/spawntest.py gcc -fno-strict-aliasing 
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -IlibImaging 
-I/usr/include -I/usr/include/python2.5 -c libImaging/Chops.c -o 
build/temp.cygwin-1.5.24-i686-2.5/libImaging/Chops.o
Are we done yet? Waiting on pid 3244
Got pid, status 3244 0
Got WIFEXITED 0

So it appears unlikely to be gcc-specific, leaving me wondering what 
exactly is the difference between the build environment and my tests.

It would be really nice if test_distutils showed any failures, but it 
doesn't so any assistance would be welcome. At this point I can't even 
replicate the failure in a simpler test :-(

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------


From amk at amk.ca  Tue Jul 31 14:02:30 2007
From: amk at amk.ca (A.M. Kuchling)
Date: Tue, 31 Jul 2007 08:02:30 -0400
Subject: [Python-Dev] add bool type to optparse
In-Reply-To: <f8kqcs$15q$1@sea.gmane.org>
References: <f8kqcs$15q$1@sea.gmane.org>
Message-ID: <20070731120230.GA5844@amk-desktop.matrixgroup.net>

On Mon, Jul 30, 2007 at 09:50:38AM -0400, Neal Becker wrote:
> Subject says it all.

Why is boolean support needed, given that optparse has store_true and
store_false actions?  Example usage:

    parser.add_option('--confirm', action='store_true', dest='confirm')

--amk


From ndbecker2 at gmail.com  Tue Jul 31 15:35:06 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 31 Jul 2007 09:35:06 -0400
Subject: [Python-Dev] add bool type to optparse
References: <f8kqcs$15q$1@sea.gmane.org>
	<20070731120230.GA5844@amk-desktop.matrixgroup.net>
Message-ID: <f8ndqn$9o4$1@sea.gmane.org>

A.M. Kuchling wrote:

> On Mon, Jul 30, 2007 at 09:50:38AM -0400, Neal Becker wrote:
>> Subject says it all.
> 
> Why is boolean support needed, given that optparse has store_true and
> store_false actions?  Example usage:
> 
>     parser.add_option('--confirm', action='store_true', dest='confirm')
> 
> --amk

So you can do:
--option=false

Otherwise you have to do something like:
(action='store_false', default=True)

and use:
--no-option

which is OK sometimes, but why not allow a choice?


From guido at python.org  Tue Jul 31 20:09:51 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 31 Jul 2007 11:09:51 -0700
Subject: [Python-Dev] add bool type to optparse
In-Reply-To: <f8ndqn$9o4$1@sea.gmane.org>
References: <f8kqcs$15q$1@sea.gmane.org>
	<20070731120230.GA5844@amk-desktop.matrixgroup.net>
	<f8ndqn$9o4$1@sea.gmane.org>
Message-ID: <ca471dc20707311109o677817epcad33d37f5bcd227@mail.gmail.com>

Why not submit a patch to Greg Ward? http://optik.sourceforge.net/

On 7/31/07, Neal Becker <ndbecker2 at gmail.com> wrote:
> A.M. Kuchling wrote:
>
> > On Mon, Jul 30, 2007 at 09:50:38AM -0400, Neal Becker wrote:
> >> Subject says it all.
> >
> > Why is boolean support needed, given that optparse has store_true and
> > store_false actions?  Example usage:
> >
> >     parser.add_option('--confirm', action='store_true', dest='confirm')
> >
> > --amk
>
> So you can do:
> --option=false
>
> Otherwise you have to do something like:
> (action='store_false', default=True)
>
> and use:
> --no-option
>
> which is OK sometimes, but why not allow a choice?
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From pingmaximus at gmail.com  Tue Jul 31 20:31:49 2007
From: pingmaximus at gmail.com (Vishak Srinivas)
Date: Tue, 31 Jul 2007 14:31:49 -0400
Subject: [Python-Dev] Extending Python by Adding Keywords & Data types
Message-ID: <3b8bbd650707311131j7007f94ejdff92e6c48689d47@mail.gmail.com>

HI all,

I am using python v2.5 and I am an amateur working on python. I am extending
python for my research work and would like some help and guidance w.r.t this
matter from you experienced python developers.

II want to add some more KEYWORDS and DATATYPES into the python script apart
from the existing ones.

It would be really great if anybody could guide me as which files and
modules I need to look to make these additions and enhancements to the
existing python version. Thanks a lot in advance and your help is really
appreciated.

Vishak

-- 
--
Vishak
PhD Grad Student.

We are what we repeatedly do. Excellence, then, is not an act but a habit. -
Aristotle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070731/252a20ff/attachment.html 

From aahz at pythoncraft.com  Tue Jul 31 21:04:47 2007
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 31 Jul 2007 12:04:47 -0700
Subject: [Python-Dev] Extending Python by Adding Keywords & Data types
In-Reply-To: <3b8bbd650707311131j7007f94ejdff92e6c48689d47@mail.gmail.com>
References: <3b8bbd650707311131j7007f94ejdff92e6c48689d47@mail.gmail.com>
Message-ID: <20070731190447.GA24495@panix.com>

On Tue, Jul 31, 2007, Vishak Srinivas wrote:
>
> I am using python v2.5 and I am an amateur working on python. I am extending
> python for my research work and would like some help and guidance w.r.t this
> matter from you experienced python developers.
> 
> II want to add some more KEYWORDS and DATATYPES into the python script apart
> from the existing ones.
> 
> It would be really great if anybody could guide me as which files and
> modules I need to look to make these additions and enhancements to the
> existing python version. Thanks a lot in advance and your help is really
> appreciated.

python-dev is probably not the right place for this discussion.  You have
three good options:

* If you want to propose new keywords and types to get included into the
base language, you should use the python-ideas list.

* If you're doing this for yourself, use comp.lang.python or the capi-sig
list.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

This is Python.  We don't care much about theory, except where it intersects 
with useful practice.  

From martin at v.loewis.de  Tue Jul 31 22:58:34 2007
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 31 Jul 2007 22:58:34 +0200
Subject: [Python-Dev] Python Package Index hostname change
Message-ID: <46AFA27A.4090700@v.loewis.de>

The Python Packaging Index (the software formerly known
as Cheeseshop) is now available at

http://pypi.python.org/pypi

The old addresses (www.python.org/pypi, and
cheeseshop.python.org/pypi) will continue to work,
either as aliases or using HTTP redirections.

The software was renamed to its old name
(PyPI - Python Package Index), as the Cheeseshop
name was ever confusing people unfamiliar with
British television comedy sketch (and puzzling
even to people familiar with the sketch, as
you *can* get packages from the package index).

If you would like to discuss PyPI and its future,
please join catalog-sig at python.org.

Regards,
Martin

From martin at v.loewis.de  Tue Jul 31 23:33:49 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 31 Jul 2007 23:33:49 +0200
Subject: [Python-Dev] Extending Python by Adding Keywords & Data types
In-Reply-To: <3b8bbd650707311131j7007f94ejdff92e6c48689d47@mail.gmail.com>
References: <3b8bbd650707311131j7007f94ejdff92e6c48689d47@mail.gmail.com>
Message-ID: <46AFAABD.8050100@v.loewis.de>

> II want to add some more KEYWORDS and DATATYPES into the python script
> apart from the existing ones.

In addition to what Aahz said: take a look at PEP 306 for adding
keywords. If you don't understand it, *don't* ask here, but on
comp.lang.python instead.

For adding new datatypes, look at xxmodule.c. The same disclaimer
applies: if you have any questions about that, don't ask here.

Regards,
Martin

From martin at v.loewis.de  Tue Jul 31 23:44:33 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 31 Jul 2007 23:44:33 +0200
Subject: [Python-Dev] Cygwin: Problem detecting subprocess termination
 after _spawn_posix in distutils?
In-Reply-To: <f8lcd3$9ou$1@sea.gmane.org>
References: <f8lcd3$9ou$1@sea.gmane.org>
Message-ID: <46AFAD41.9060203@v.loewis.de>

> It would be really nice if test_distutils showed any failures, but it 
> doesn't so any assistance would be welcome. At this point I can't even 
> replicate the failure in a simpler test :-(

My guess is that it's the environment; if not that, the working
directory. Assuming you have already instrumented
ccompiler.CCompiler.spawn, I suggest to dump os.environ and
print os.getcwd(). Assuming you really meant that you run under
Cygwin Python (instead of just using --compiler), you might
want to instrument spawn._spawn_posix instead.

When you say you extracted _spawn_all from distutils/spawn.py:
what version of Python are you talking about? I can't find
_spawn_all in the sources of 2.5.x, or 2.6.

Regards,
Martin

From Cameron at phaseit.net  Thu Jul 26 18:08:37 2007
From: Cameron at phaseit.net (Cameron Laird)
Date: Thu, 26 Jul 2007 16:08:37 +0000
Subject: [Python-Dev] Pythreads and BSD descendants
Message-ID: <20070726160837.GA24583@lairds.us>

Folklore that I remember so unreliably I avoid trying to repeat it here
held that Python threading had problems on BSD and allied Unixes.  What's
the status of this?  I suspect the answer is, "Everything works, and the
only real problem ever was that *signals* have different semantics under
Linux and *BSD."  Anyone who can answer explicitly, though, would repre-
sent a help to me.

From eopadoan at altavix.com  Thu Jul 26 19:27:11 2007
From: eopadoan at altavix.com (Eduardo "EdCrypt" O. Padoan)
Date: Thu, 26 Jul 2007 14:27:11 -0300
Subject: [Python-Dev] [Python-3000] interaction between locals,
	builtins and except clause
In-Reply-To: <e7ba66e40707261006s71826ce8p73194134992697f3@mail.gmail.com>
References: <e7ba66e40707261006s71826ce8p73194134992697f3@mail.gmail.com>
Message-ID: <dea92f560707261027k2462a9beu10b5c4b3398a458d@mail.gmail.com>

On 7/26/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> Porting to Py3K, I modified a function like the followin, using a
> trick for it working in Py2.x .
>
>     def __iter__(self):
>         if self == _mpi.INFO_NULL:
>             return
>         try:    range = xrange
>         except: pass
>         nkeys = _mpi.info_get_nkeys(self)
>         for nthkey in range(nkeys):
>             yield _mpi.info_get_nthkey(self, nthkey)
>
> However, I've got in my unittests (running with py3k)
>
> ERROR: testPyMethods (__main__.TestInfo)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "tests/unittest/test_info.py", line 123, in testPyMethods
>     for key in INFO:
>   File "/u/dalcinl/lib/python/mpi4py/MPI.py", line 937, in __iter__
>     for nthkey in range(nkeys):
> UnboundLocalError: local variable 'range' referenced before assignment
>
>
> I am not completelly sure if this is expected (it is, regarding
> implementation, but perhaps not regarding Python as a language),  so
> I post this for your consideration.
>

Python thinnks range is local, because you referenced it, even if an
error ocurred. Use 'global range' at the top of the file.

But, as I understand, you are trying to target both Python 2.x and 3
with the same code, using tricks like this one. I think that, even if
you succeed, the resulting code will be quite unmaintainable.

-- 
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt