[Python-Dev] Summer of Code: call for ideas and mentors

[Martin v. Löwis]

Google Summer of Code is coming up again, and we will again
be participating. Arc Riley will setup infrastructure later
today, and we need to start thinking about possible projects.

Traditionally, people (students and other projects) have been willing
to give the Python Core the highest attention in SoC, as improvements
to Python will help the whole community. Also traditionally, there has
been a shortage of project ideas and mentors for Python Core. My guess
is that the project shortage stems from the assumption that many of the
projects are so tricky that you can't give them to a newcomer. I found
this view both confirmed and rebutted in the past - it all depends on
which students we can attract.

The shortage of mentors is probably more inherent, and reflects the
shortage of volunteers for other tasks. As a long-time mentor, I'd
like to encourage all of you to consider mentoring this year. GSoC/PSF
will have a strict rule "one student per mentor", co-mentorship
is encouraged.

Feel free to discuss Python-Core-GSoC here or on the GSoC mailing
list(s) (soon to appear).

One last cautioning: recently, people started proposing that admin
tasks be done in GSoC. While that indeed may help python-dev most,
they called it summer of *code* deliberately - so the project idea
should be about programming (the hope being, of course, that the
students stay in the project, or at least in open source, when the
summer is over. some do, some don't.).

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Aaron DeVore]

On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley  wrote:
> That way, if the sysadmin does decide to replace the installed "python" file, 
> he can do so without inadvertently deleting the previously installed binary.

Nit pick: Change "he" to "they" to be gender neutral.

-Aaron DeVore
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Piotr Ożarowski]

[Toshio Kuratomi, 2011-03-03]
> On Thu, Mar 03, 2011 at 09:55:25AM +0100, Piotr Ożarowski wrote:
> > If /usr/bin/python will be disallowed in shebangs on the other hand
> > (and all scripts will use /usr/bin/python2, /usr/bin/python3,
> > /usr/bin/python4 or /usr/bin/python2.6 etc.) I don't see a problem with
> > letting administrators choose /usr/bin/python (right now not only
> > changing it from python2.X to python3.X will break the system but also
> > changing it from /usr/bin/python2.X to /usr/bin/python2.Y will break it,
> > and believe me, I know what I'm talking about (one of the guys at work
> > did something like this once))
> > 
> > [all IMHO, dunno if other Debian's python-defaults maintainers agree
> > with me]
> >
> Thinking outside of the box, I can think of something that would satisfy
> your requirements but I don't know how appropriate it is for upstream python
> to ship with.  Stop shipping /usr/bin/python.  Ship "python" in an alternate
> location

to be honest, I didn't want to be so radical, a clear policy (PEP?)
would be enough for me - we'd then replace all /usr/bin/python shebangs
with /usr/bin/python2 at build time (with a warning to report bug
upstream) and forward all complainers to this PEP)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summer of Code: call for ideas and mentors

[Maciej Fijalkowski]

On Fri, Mar 4, 2011 at 10:35 AM, "Martin v. Löwis"  wrote:
> Google Summer of Code is coming up again, and we will again
> be participating. Arc Riley will setup infrastructure later
> today, and we need to start thinking about possible projects.
>
> Traditionally, people (students and other projects) have been willing
> to give the Python Core the highest attention in SoC, as improvements
> to Python will help the whole community. Also traditionally, there has
> been a shortage of project ideas and mentors for Python Core. My guess
> is that the project shortage stems from the assumption that many of the
> projects are so tricky that you can't give them to a newcomer. I found
> this view both confirmed and rebutted in the past - it all depends on
> which students we can attract.
>
> The shortage of mentors is probably more inherent, and reflects the
> shortage of volunteers for other tasks. As a long-time mentor, I'd
> like to encourage all of you to consider mentoring this year. GSoC/PSF
> will have a strict rule "one student per mentor", co-mentorship
> is encouraged.
>
> Feel free to discuss Python-Core-GSoC here or on the GSoC mailing
> list(s) (soon to appear).

Hi Martin.

Would you consider working on benchmarking (http://speed.pypy.org but
also infrastructure for running it) a part of core GSoC work? I can
imagine this to be useful not only for pypy and preferably also
running CPython trunk on benchmarks.

>
> One last cautioning: recently, people started proposing that admin
> tasks be done in GSoC. While that indeed may help python-dev most,
> they called it summer of *code* deliberately - so the project idea
> should be about programming (the hope being, of course, that the
> students stay in the project, or at least in open source, when the
> summer is over. some do, some don't.).
>
> Regards,
> Martin
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Official Roadmap (Re: Let's get PEP 380 into Python 3.3)

[Nick Coghlan]

On Fri, Mar 4, 2011 at 3:26 AM, anatoly techtonik  wrote:
> Yes, there can (or even should) be a way for everybody with Python
> account to vote on items in the Roadmap and subscribe to updates (like
> commits, messages, code reviews, tweets and other stuff related to one
> item). This will give Jesse and teams a better picture, what sprints
> need funding. Tracker doesn't allow this - even though users can
> subscribe to Roundup issues, it just doesn't work for them. And the
> last distinction between Roadmap and Tracker is that the former gives
> you a quick overview of each item without going into the gory details
> of lengthy discussions.

But again, this is yet-another-tool that requires substantial
maintenance and curating. Anyone is free to create such a tool if they
want, and try to convince people to use it, and then try to convince
python-dev that feedback in that form is worth paying attention to.
You could even try to convince the PSF they should fund it. But coming
in and talking about what other people *should* do in an all-volunteer
environment is counterproductive.

Would such a tool really be a huge improvement over the python-ideas
mailing list (which is pretty freewheeling compared to what we
consider on-topic for python-dev itself), anyway? Sure, the tool would
provide more fancy features, but the barriers to participation would
also be much higher. Already, the number of people participating in
even python-list (let alone -ideas or -dev) is utterly dwarfed by the
total number of people using Python. Would a voting mechanism amongst
such a non-representative sample actually mean anything? Or is it
better to stick with the long-standing maxim of rough consensus and
running code?

All that said, if you really want a Roadmap, look at the list of
accepted, open and deferred PEPs in PEP 0. Those are the ideas that
someone has cared enough about to submit a PEP, and it hasn't been
summarily rejected by Guido (or his delegate).

For a nearer term Roadmap, you can look at the release PEP for the
upcoming release (although that is in such an early stage for 3.3 that
not only doesn't it exist yet, we don't even officially have an RM who
is going to write it).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Nick Coghlan]

On Fri, Mar 4, 2011 at 10:58 AM, Victor Stinner
 wrote:
> Hi,
>
> Some months ago, I proposed a patch to display the Python backtrace on a
> segfault. The API was not stable, it was too for Python 3.2, and it was
> enabled by default. I wrote a module instead of a patch so it can be
> used on any version of Python, and it has a better API. And now I would
> like to include the module into Python directly to use it more easily.
> See http://bugs.python.org/issue11393 for the details. The module:
>
>   https://github.com/haypo/faulthandler
>
> It is now possible to dump the backtrace on an user signal (eg. SIGUSR1)
> or after a delay in seconds (it may be useful for buildbot hangs without
> user interaction). You can choose to display the current thread or all
> threads, and in which file the trace is written.
>
> So, what do you think?

+1

It's a very helpful capability, and getting it in early in the 3.3
cycle will give us more time to refine the API and functionality.

Something we may want to consider is enabling it by default in
interactive mode, and also when `-i` is specified on the command line.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Victor Stinner]

Le vendredi 04 mars 2011 à 21:10 +1000, Nick Coghlan a écrit :
> > Some months ago, I proposed a patch to display the Python backtrace on a
> > segfault. The API was not stable, it was too for Python 3.2, and it was
> > enabled by default. I wrote a module instead of a patch so it can be
> > used on any version of Python, and it has a better API. And now I would
> > like to include the module into Python directly to use it more easily.
> > See http://bugs.python.org/issue11393 for the details. The module:
> >
> >   https://github.com/haypo/faulthandler
> >
> > It is now possible to dump the backtrace on an user signal (eg. SIGUSR1)
> > or after a delay in seconds (it may be useful for buildbot hangs without
> > user interaction). You can choose to display the current thread or all
> > threads, and in which file the trace is written.
> >
> > So, what do you think?
> 
> +1
> 
> It's a very helpful capability, and getting it in early in the 3.3
> cycle will give us more time to refine the API and functionality.

Even if it has a complete test suite (for all features), it would be
nice to test it as much as possible. So introduce it quickly into Python
3.3 would be nice.

The API can be completly changed, I don't care of the API :-)

But I will try to continue to maintain the project as a third party
module for older Python versions.

> Something we may want to consider is enabling it by default in
> interactive mode, and also when `-i` is specified on the command line.

In the issue, I proposed:

 * an option on the command line, eg. python -x faulthandler script.py
 * an environment variable, eg. PYTHONFAULTHANDLER=y python script.py

Both have different usages: the command line option can be used once to
try to get more information when trying to reproduce a crash, the
environment variable can be used to always enable it by default on your
computer.

I also would like to enable it by default in regrtest.py.

Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Scott Dial]

On 3/4/2011 6:10 AM, Nick Coghlan wrote:
> On Fri, Mar 4, 2011 at 10:58 AM, Victor Stinner
>  wrote:
>> So, what do you think?
> 
> Something we may want to consider is enabling it by default in
> interactive mode, and also when `-i` is specified on the command line.

I am still bothered by the fact that,

>>> import faulthandler
>>> faulthandler.enable()
>>> import sys
>>> sys.stderr.close()
>>> sys.stderr = open('logs/error.log', 'wb')
>>> faulthandler.sigsegv()

, does the wrong thing. In this incantation, it's easy to say that it's
programmer error, but I think this still precludes it from being on by
default (where the first two statement are implicitly executed by the
interpreter). It's probably uncommon enough to close stderr from an
interactive interpreter session that it doesn't bother me (although I am
not sure the utility of that), but I would hesitate to say that is true
for using '-i'.

Otherwise, the functionality seems generally useful and it's on my list
of things to integrate into my application, and having it in the stdlib
is one less external dependency for me to manage.

-Scott

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unittest.main() --catch parameter

[Michael Foord]

On 04/03/2011 01:33, anatoly techtonik wrote:

On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord
  wrote:

Without this option interrupting a test run with a ctrl-c kills the run
and
reports nothing. Seeing an unexpected failure or error during a long test
run and having to wait to the end of the test run to see the traceback
can
be annoying, this feature solves that problem.

Why not just leave this behavior by default and just return -1 if the
Ctrl-C was pressed?


Because it means installing a signal handler which is not necessarily
appropriate for all test systems. We *could* make it the default in the
future (for the test runner only - not when unittest is used via the api).

What does it mean - "not approriate"? Do signal handlers crash or kill
people on some test systems?


Because the system under test may use its own signal handlers.

If tests are run with output buffering
then it's reasonable to turn off handling of Ctrl-C. If they are
executed by buildbots, I don't see how it hurts the test process. In
any case there should be a way to turn Ctrl-C handing using some
internal flag, but moving it into user command doesn't seem like a
good idea to me.


What's more relevant are the following two facts:

* It isn't guaranteed to work, the keyboard interrupt can interrupt code 
at any arbitrary point so the system *could* be in an unstable state and 
result reporting may then fail.


* It changes the default behaviour of pressing control-c which normally 
stops code immediately. This continues to execute an arbitrary amount of 
code after pressing control-c.


For all these reasons I think it is better to make it a user option than 
on by default. Besides which it is already done and released in two 
major versions of Python (2.7 & 3.2).


(The behaviour *is* configurable / controllable via the api - which I 
guess is what you mean by "some internal flag". The command line option 
is the way to control it when using the default runner and not the api.)



By the way, is calling unittest.main() is using unittest via api?



Not really, that's the standard test runner. Perhaps slightly debatable.


So you want it on by default but are also worried about the backwards
compatibility issues of it even existing as an option? Anyway, your
assertion that the option is or may be useless is unfounded. Don't worry
about it.

I am worried that I won't have space to add more useful options to the
runner or they will be lost for users in the abundance of highly
technical parameters that runner provides. I am concerned that users
will never ever understand the true Awesomeness of the New Runner
(tm). ;)


:-)

Well there are only 52 short alphabetical options available, but yes we 
should be careful with them and I'm not proposing adding any more at the 
moment.


All the best,

Michael Foord

--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Nick Coghlan]

On Fri, Mar 4, 2011 at 5:44 PM, Kerrick Staley  wrote:
> PEP: ???
> Title: The python Utility on Unix-Like Systems

With a few adjustments (formatting, additional info, correction of
typos), I've now added Kerrick's PEP as a proposal on python.org:

http://www.python.org/dev/peps/pep-0394

The full text is included below as well.

Cheers,
Nick.

PEP: 394
Title: The "python" command on Unix-Like Systems
Version: $Revision: 88743 $
Last-Modified: $Date: 2011-03-04 22:04:22 +1000 (Fri, 04 Mar 2011) $
Author: Kerrick Staley ,
Nick Coghlan 
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: 04-Mar-2011


Abstract


This PEP provides a convention to ensure that Python scripts can continue to
be portable across ``*nix`` systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the ``python`` command).

* ``python2`` will refer to some version of Python 2.x
* ``python3`` will refer to some version of Python 3.x
* ``python`` may refer to either, depending on distribution and system


Recommendation
==

* ``*nix`` software distributions should install the ``python2`` command into
  the default path whenever a version of the Python 2 interpreter is
  installed, and the same for ``python3`` and the Python 3 interpreter. When
  invoked, ``python2`` should run some version of the Python 2 interpreter,
  and ``python3`` should run some version of the Python 3 interpreter. The
  same applies for the more general ``python`` command, which should be
  installed whenever any version of Python is installed and should invoke
  some Python interpreter.
* All new code that needs to invoke the Python interpreter should not specify
  ``python``, but rather should specify either ``python2`` or ``python3`` (or
  the more specific ``python2.x`` and ``python3.x`` versions; see the Notes).
  This distinction should be made in shebangs, when invoking from a shell
  script, when invoking via the system() call, or when invoking in any other
  context. Note that, when reinvoking the interpreter from a Python script,
  querying ``sys.executable`` remains the preferred approach.


Rationale
=

This is needed as, even though the majority of distributions still alias the
``python`` command to Python 2, some now alias it to Python 3. Some of
the former also do not provide a ``python2`` command; hence, there is
currently no way for Python 2 code (or any code that invokes the Python 2
interpreter) to reliably run on all systems without modification, because both
the ``python`` and the ``python2`` commands will fail on some systems. The
recommendations in this PEP provide a very simple mechanism to restore
cross-platform support, with minimal additional work required on the part
of distribution maintainers.


Notes
=

* Distributions can alias the ``python`` command to whichever version of the
  Python interpreter they choose (noting that, in the near term, most 3rd
  party scripts will still expect this command to refer to Python 2.x).
* The ``pythonX.X`` (e.g. ``python2.6``) utilities exist on some systems, on
  which they invoke specific minor versions of the Python interpreter. It
  would be wise for distribution-specific packages to take advantage of these
  utilities if they exist, since it will prevent code breakage if the default
  minor version of a given major version is changed. However, scripts
  intending to be cross-platform should not rely on the presence of these
  utilities, but rather should be tested on several recent minor versions of
  the target major version, compensating, if necessary, for the small
  differences that exist between minor versions. This prevents the need for
  sysadmins to install many very similar versions of the interpreter.
* It would be wise for distribution-specific packages to always follow the
  ``python2``/``python3`` convention, even in code that is not intended to
  operate on other distributions. This will prevent problems if the
  distribution later decides to upgrade the version of the Python interpreter
  that the ``python`` command invokes, or if a sysadmin installs a custom
  ``python`` command with a different major version than the distribution
  default. Distributions can test whether they are fully following this
  convention by changing the ``python`` interpreter on a test box and checking
  to see if anything breaks.
* If the above point is adhered to and sysadmins are permitted to change the
  ``python`` command, then the ``python`` command should always be implemented
  as a link to the interpreter binary (or a link to a link) and not vice
  versa. That way, if a sysadmin does decide to replace the installed
  ``python`` file, they can do so without inadvertently deleting the
  previously installed binary.
* The first recommendation can be ignored for systems on which the ``python``
  command itself has traditionally been left undefined and users have always
  had

Re: [Python-Dev] Summer of Code: call for ideas and mentors

[Nick Coghlan]

On Fri, Mar 4, 2011 at 6:35 PM, "Martin v. Löwis"  wrote:
> Google Summer of Code is coming up again, and we will again
> be participating. Arc Riley will setup infrastructure later
> today, and we need to start thinking about possible projects.
>
> Traditionally, people (students and other projects) have been willing
> to give the Python Core the highest attention in SoC, as improvements
> to Python will help the whole community. Also traditionally, there has
> been a shortage of project ideas and mentors for Python Core. My guess
> is that the project shortage stems from the assumption that many of the
> projects are so tricky that you can't give them to a newcomer. I found
> this view both confirmed and rebutted in the past - it all depends on
> which students we can attract.
>
> The shortage of mentors is probably more inherent, and reflects the
> shortage of volunteers for other tasks. As a long-time mentor, I'd
> like to encourage all of you to consider mentoring this year. GSoC/PSF
> will have a strict rule "one student per mentor", co-mentorship
> is encouraged.
>
> Feel free to discuss Python-Core-GSoC here or on the GSoC mailing
> list(s) (soon to appear).

Are proof-of-concept projects acceptable as GSoC projects? I've long
had the belief that Python's import semantics could be bundled up into
an "import engine" object to get away from the process globals in the
sys module (i.e. modules, path, meta_path, path_hooks,
path_importer_cache) as well as the global import lock. The "default
engine" could then be implemented as a subclass that replaced the
essential attributes with properties that read from and wrote through
to the standard locations.

Experimenting with this idea became significantly more feasible since
Brett wrote importlib, but would still require a strong understanding
of Python's import system. I suspect even a proof of concept that was
tested against just filesystem imports and zipimport would prove quite
tricky.

Once the concept has been proven... I'm sure we could figure out
*something* useful to do with the idea. It would depend on the details
of what actually turns out to be feasible.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Nick Coghlan]

On Fri, Mar 4, 2011 at 9:32 PM, Scott Dial
 wrote:
> I am still bothered by the fact that,
>
 import faulthandler
 faulthandler.enable()
 import sys
 sys.stderr.close()
 sys.stderr = open('logs/error.log', 'wb')
 faulthandler.sigsegv()
>
> , does the wrong thing. In this incantation, it's easy to say that it's
> programmer error, but I think this still precludes it from being on by
> default (where the first two statement are implicitly executed by the
> interpreter). It's probably uncommon enough to close stderr from an
> interactive interpreter session that it doesn't bother me (although I am
> not sure the utility of that), but I would hesitate to say that is true
> for using '-i'.

Perhaps the module should be using sys.__stderr__ instead? If anyone
is messing with that, on their own heads be it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r88729 - python/branches/py3k/Modules/posixmodule.c

[Nick Coghlan]

On Fri, Mar 4, 2011 at 2:10 AM, giampaolo.rodola
 wrote:
> Author: giampaolo.rodola
> Date: Thu Mar  3 17:10:51 2011
> New Revision: 88729
>
> Log:
> Issue 11351 - apply patch by Steffen Daode Nurpmeso which should fix 
> TestSendfile.test_headers failure on OSX.
>
> Modified:
>   python/branches/py3k/Modules/posixmodule.c

NEWS entry and a new name in ACKS?

(the query regarding the lack of a NEWS entry applies to your other
recent commits as well).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summer of Code: call for ideas and mentors

[Antoine Pitrou]

On Fri, 04 Mar 2011 09:35:38 +0100
"Martin v. Löwis"  wrote:
> Google Summer of Code is coming up again, and we will again
> be participating. Arc Riley will setup infrastructure later
> today, and we need to start thinking about possible projects.

We've had a couple of people asking questions about GSoC on
#python-dev. Each time I redirected them to Arc's personal email, since
there seems to be no dedicated mailing-list for that. Is there a better
way to inform them?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r88729 - python/branches/py3k/Modules/posixmodule.c

[Nick Coghlan]

On Fri, Mar 4, 2011 at 10:33 PM, Nick Coghlan  wrote:
> On Fri, Mar 4, 2011 at 2:10 AM, giampaolo.rodola
>  wrote:
>> Author: giampaolo.rodola
>> Date: Thu Mar  3 17:10:51 2011
>> New Revision: 88729
>>
>> Log:
>> Issue 11351 - apply patch by Steffen Daode Nurpmeso which should fix 
>> TestSendfile.test_headers failure on OSX.
>>
>> Modified:
>>   python/branches/py3k/Modules/posixmodule.c
>
> NEWS entry and a new name in ACKS?
>
> (the query regarding the lack of a NEWS entry applies to your other
> recent commits as well).

Oops, one of them did have an entry, and a second was just a tweak to
the first one. So the NEWS query only applies to this one and the NNTP
change.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Victor Stinner]

Le vendredi 04 mars 2011 à 06:32 -0500, Scott Dial a écrit :
> On 3/4/2011 6:10 AM, Nick Coghlan wrote:
> > On Fri, Mar 4, 2011 at 10:58 AM, Victor Stinner
> >  wrote:
> >> So, what do you think?
> > 
> > Something we may want to consider is enabling it by default in
> > interactive mode, and also when `-i` is specified on the command line.
> 
> I am still bothered by the fact that,
> 
> >>> import faulthandler
> >>> faulthandler.enable()
> >>> import sys
> >>> sys.stderr.close()
> >>> sys.stderr = open('logs/error.log', 'wb')
> >>> faulthandler.sigsegv()
> 
> , does the wrong thing.

faulthandler.enable() uses sys.stderr by default: it keeps a reference
on this object and stores its descriptor (should be 2). If you close the
file descriptor (eg. sys.stderr.close()), the faulthandler will write
into a closed file, which is not a problem (it doesn't crash or do
something dangerous) except that the backtrace is not displayed.

... in this particulier example, the new opened file (sys.stderr) may
also get the file descriptor 2 (which is a specific value, it is usually
the highest file descriptor at startup on Linux) and so the backtrace
may be written to this file. It is a problem if the new file is a socket
or a critical file. But you enabled explicitly the faulthandler, so you
know what you are doing :-)

>  In this incantation, it's easy to say that it's
> programmer error, but I think this still precludes it from being on by
> default (where the first two statement are implicitly executed by the
> interpreter). It's probably uncommon enough to close stderr from an
> interactive interpreter session that it doesn't bother me (although I am
> not sure the utility of that), but I would hesitate to say that is true
> for using '-i'.

I forgot to give my opinion about enabling faulthandler with -i. I vote
-1 because we have to be careful with this new feature and its side
effects. But we may change that later when I will be more confident in
my own code :-)

Your example is a corner case. Having a segfault after changing
sys.stderr in an interpreter is unlikely. Anyway, if someone had such
problem, it is still possible to workaround it. Call again
faulthandler.enable() after changing sys.stderr: the new call to
enable() will just update the file descriptor variable and so the
backtrace is written to the right file.

crier project (similar to faulthandler) creates the
file /tmp/crier- to dump the backtrace. The tiper projects creates
also a temporary file to dump the backtrace.

But I prefer sys.stderr just because it's enough for me, and I don't
really want to generate a filename or create a new file in the SIGSEGV
handler.

crier dumps the backtrace when a file is created in a specific directory
and tiper dumps the backtrace when a SIGUSR is received. faulthandler
may creates a file after a delay in seconds or on SIGUSR1, but not on a
segmentation fault.

> Otherwise, the functionality seems generally useful and it's on my list
> of things to integrate into my application, and having it in the stdlib
> is one less external dependency for me to manage.

You can already have an optional support of this module. For example:

try:
   import faulthandler
except ImportError:
   pass
else:
   faulthandler.enable()

Integrate it directly into Python should just help users to report more
informations to our bug tracker (don't need to install an extra module
just to report a bug).

Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Antoine Pitrou]

On Fri, 04 Mar 2011 13:40:16 +0100
Victor Stinner  wrote:
> > I am still bothered by the fact that,
> > 
> > >>> import faulthandler
> > >>> faulthandler.enable()
> > >>> import sys
> > >>> sys.stderr.close()
> > >>> sys.stderr = open('logs/error.log', 'wb')
> > >>> faulthandler.sigsegv()
> > 
> > , does the wrong thing.
> 
> faulthandler.enable() uses sys.stderr by default: it keeps a reference
> on this object and stores its descriptor (should be 2). If you close the
> file descriptor (eg. sys.stderr.close())

sys.stderr.close() doesn't close the file descriptor under Python 3:

>>> import sys, os
>>> sys.stderr.close()
>>> os.write(2, b"foo\n")
foo
4

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r88729 - python/branches/py3k/Modules/posixmodule.c

[Giampaolo Rodolà]

Thanks.
I'll try to remember ACKS and NEWS in the future. =)
Fixed in r88744 and r88745.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/

2011/3/4 Nick Coghlan :
> On Fri, Mar 4, 2011 at 10:33 PM, Nick Coghlan  wrote:
>> On Fri, Mar 4, 2011 at 2:10 AM, giampaolo.rodola
>>  wrote:
>>> Author: giampaolo.rodola
>>> Date: Thu Mar  3 17:10:51 2011
>>> New Revision: 88729
>>>
>>> Log:
>>> Issue 11351 - apply patch by Steffen Daode Nurpmeso which should fix 
>>> TestSendfile.test_headers failure on OSX.
>>>
>>> Modified:
>>>   python/branches/py3k/Modules/posixmodule.c
>>
>> NEWS entry and a new name in ACKS?
>>
>> (the query regarding the lack of a NEWS entry applies to your other
>> recent commits as well).
>
> Oops, one of them did have an entry, and a second was just a tweak to
> the first one. So the NEWS query only applies to this one and the NNTP
> change.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Michael Foord]

On 04/03/2011 12:10, Nick Coghlan wrote:

On Fri, Mar 4, 2011 at 5:44 PM, Kerrick Staley  wrote:

PEP: ???
Title: The python Utility on Unix-Like Systems

With a few adjustments (formatting, additional info, correction of
typos), I've now added Kerrick's PEP as a proposal on python.org:

http://www.python.org/dev/peps/pep-0394

The full text is included below as well.


Should any of this also apply to Mac OS X and Windows?

Note that we *do* have alternative distributors [1] of Python for these 
platforms who may wish to follow any recommendations we have for 2.7, 
even if we don't modify those installers for our own distributions.


All the best,

Michael Foord

[1] Activestate and Enthought in particular. Plus possibly others I'm 
not aware of.



Cheers,
Nick.

PEP: 394
Title: The "python" command on Unix-Like Systems
Version: $Revision: 88743 $
Last-Modified: $Date: 2011-03-04 22:04:22 +1000 (Fri, 04 Mar 2011) $
Author: Kerrick Staley,
 Nick Coghlan
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: 04-Mar-2011


Abstract


This PEP provides a convention to ensure that Python scripts can continue to
be portable across ``*nix`` systems, regardless of the default version of the
Python interpreter (i.e. the version invoked by the ``python`` command).

* ``python2`` will refer to some version of Python 2.x
* ``python3`` will refer to some version of Python 3.x
* ``python`` may refer to either, depending on distribution and system


Recommendation
==

* ``*nix`` software distributions should install the ``python2`` command into
   the default path whenever a version of the Python 2 interpreter is
   installed, and the same for ``python3`` and the Python 3 interpreter. When
   invoked, ``python2`` should run some version of the Python 2 interpreter,
   and ``python3`` should run some version of the Python 3 interpreter. The
   same applies for the more general ``python`` command, which should be
   installed whenever any version of Python is installed and should invoke
   some Python interpreter.
* All new code that needs to invoke the Python interpreter should not specify
   ``python``, but rather should specify either ``python2`` or ``python3`` (or
   the more specific ``python2.x`` and ``python3.x`` versions; see the Notes).
   This distinction should be made in shebangs, when invoking from a shell
   script, when invoking via the system() call, or when invoking in any other
   context. Note that, when reinvoking the interpreter from a Python script,
   querying ``sys.executable`` remains the preferred approach.


Rationale
=

This is needed as, even though the majority of distributions still alias the
``python`` command to Python 2, some now alias it to Python 3. Some of
the former also do not provide a ``python2`` command; hence, there is
currently no way for Python 2 code (or any code that invokes the Python 2
interpreter) to reliably run on all systems without modification, because both
the ``python`` and the ``python2`` commands will fail on some systems. The
recommendations in this PEP provide a very simple mechanism to restore
cross-platform support, with minimal additional work required on the part
of distribution maintainers.


Notes
=

* Distributions can alias the ``python`` command to whichever version of the
   Python interpreter they choose (noting that, in the near term, most 3rd
   party scripts will still expect this command to refer to Python 2.x).
* The ``pythonX.X`` (e.g. ``python2.6``) utilities exist on some systems, on
   which they invoke specific minor versions of the Python interpreter. It
   would be wise for distribution-specific packages to take advantage of these
   utilities if they exist, since it will prevent code breakage if the default
   minor version of a given major version is changed. However, scripts
   intending to be cross-platform should not rely on the presence of these
   utilities, but rather should be tested on several recent minor versions of
   the target major version, compensating, if necessary, for the small
   differences that exist between minor versions. This prevents the need for
   sysadmins to install many very similar versions of the interpreter.
* It would be wise for distribution-specific packages to always follow the
   ``python2``/``python3`` convention, even in code that is not intended to
   operate on other distributions. This will prevent problems if the
   distribution later decides to upgrade the version of the Python interpreter
   that the ``python`` command invokes, or if a sysadmin installs a custom
   ``python`` command with a different major version than the distribution
   default. Distributions can test whether they are fully following this
   convention by changing the ``python`` interpreter on a test box and checking
   to see if anything breaks.
* If the above point is adhered to and sysadmins are permitted to change the
   ``python`` command,

[Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[Victor Stinner]

Hi,

Does the bug tracker will continue to support rX links after the
migration to Mercurial? 

Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Simon Cross]

On Fri, Mar 4, 2011 at 2:58 AM, Victor Stinner
 wrote:
> Some months ago, I proposed a patch to display the Python backtrace on a
> segfault. The API was not stable, it was too for Python 3.2, and it was
> enabled by default. I wrote a module instead of a patch so it can be
> used on any version of Python, and it has a better API. And now I would
> like to include the module into Python directly to use it more easily.
> See http://bugs.python.org/issue11393 for the details. The module:

While I like this module I'm against it going into the standard
library so soon. Modules need time to mature, develop and gain wide
adoption outside the standard library where they are less constrained
by maintaining compatibility with old versions and can enjoy shorter
release cycles.

There may be reasons for including a shiny new module in the standard
library despite the drawbacks (the rest of the standard library might
wish to use the new feature, for example). If there are such reasons
it would be nice to see them stated and discussed here.

Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[anatoly techtonik]

We need a mapping for previous commits.
--
anatoly t.



On Fri, Mar 4, 2011 at 2:59 PM, Victor Stinner
 wrote:
> Hi,
>
> Does the bug tracker will continue to support rX links after the
> migration to Mercurial?
>
> Victor
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Nick Coghlan]

On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
 wrote:
> Should any of this also apply to Mac OS X and Windows?

Any platform that considers itself "unix-like" in this context can
decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
aspects of OS X). The main point of the PEP is to get a consensus
recommendation out of python-dev as to the best way forward (and I
think Kerrick did a good job of summarising the position that has been
expressed in this thread).

More generally, Windows and Mac OS X developers seem to be happier
with the idea of bundling a Python interpreter inside the application
than traditional *nix style platforms. This is a PITA for the system
maintainer when it comes time to handle security vulnerabilites, but
certainly more convenient when upgrading the default Python install.

> Note that we *do* have alternative distributors [1] of Python for these
> platforms who may wish to follow any recommendations we have for 2.7, even
> if we don't modify those installers for our own distributions.

The really tricky part on Windows is handling file associations. I
think we're just doomed on that front, unless we want to start
supporting separate .py2 and .py3 extensions (and adding *that* in a
maintenance release would be a far cry from just adding another
symlink).

The lack of near-universal symlink support on Windows filesystems is
also an issue - we would have to duplicate files like python.exe and
pythonw.exe on non-NTFS filesystems in order to provide them under
alternative names.

For *nix, I think there is a simple way forward that is an improvement
over where things stand now. For Windows, I don't think we can do much
better than the status quo and for Mac OS X... I think Apple will do
whatever Apple feel like doing :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Victor Stinner]

Le vendredi 04 mars 2011 à 15:05 +0200, Simon Cross a écrit :
> While I like this module I'm against it going into the standard
> library so soon. Modules need time to mature, develop and gain wide
> adoption outside the standard library where they are less constrained
> by maintaining compatibility with old versions and can enjoy shorter
> release cycles.
> 
> There may be reasons for including a shiny new module in the standard
> library despite the drawbacks (the rest of the standard library might
> wish to use the new feature, for example). If there are such reasons
> it would be nice to see them stated and discussed here.

faulthandler is not so new. I am working on it since september 2008
(issue #3999). It was first an hack to convert a SIGSEGV into a classic
Python exception. I started a reimplementation to just display the
backtrace in may 2010, and I wrote 11 versions to fix all remarks. But
ok, the module itself was created at christmas 2010. Before the
conversion of the patch to module, there was very few options. With the
module, I added new functions with more options.

The module is also small: it has 8 functions (+ 4 functions dedicated to
tests).

faulthandler is also a little bit special, because it is very specific
to CPython: it is based on CPython internal structures. Integrate it
directly into Python would simplify its maintenance, but it would also
help to add more hooks like dumping the backtrace at a fatal error, and
maybe have a finer control on the module (eg. handle child processes
correctly?). (Well, there is a recent addition to Python 3.2 to choose
the function used to display the fatal error message, but I didn't tried
it yet).

Victor

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Nick Coghlan]

On Fri, Mar 4, 2011 at 11:05 PM, Simon Cross
 wrote:
> There may be reasons for including a shiny new module in the standard
> library despite the drawbacks (the rest of the standard library might
> wish to use the new feature, for example). If there are such reasons
> it would be nice to see them stated and discussed here.

Basically, we would like easy access to crash tracebacks on our own
buildbots, and to be able to easily request them on the issue tracker
when someone reports a crash bug that we can't readily reproduce.

Even when the Python traceback isn't enough on its own to pinpoint the
problem, it should help greatly in isolating the cause sufficiently to
reproduce the crash under a C level debugger.

It may be worth installing this as _faulthandler for 3.3 though, at
least initially. We'll still be able to enable it by default in
regrtest, as well as provide a command line option to switch it on,
but there would be a clear indication that the Python facing API may
not be stable yet.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Michael Foord]

On 04/03/2011 13:21, Nick Coghlan wrote:

On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
  wrote:

Should any of this also apply to Mac OS X and Windows?

Any platform that considers itself "unix-like" in this context can
decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
aspects of OS X). The main point of the PEP is to get a consensus
recommendation out of python-dev as to the best way forward (and I
think Kerrick did a good job of summarising the position that has been
expressed in this thread).

Right, but the pep doesn't address those issues for some fairly major 
platforms.



More generally, Windows and Mac OS X developers seem to be happier
with the idea of bundling a Python interpreter inside the application
than traditional *nix style platforms. This is a PITA for the system
maintainer when it comes time to handle security vulnerabilites, but
certainly more convenient when upgrading the default Python install.



However on Mac OS X at least *scripts* have the same issue (what to put 
in the shebang line).



Note that we *do* have alternative distributors [1] of Python for these
platforms who may wish to follow any recommendations we have for 2.7, even
if we don't modify those installers for our own distributions.

The really tricky part on Windows is handling file associations. I
think we're just doomed on that front, unless we want to start
supporting separate .py2 and .py3 extensions (and adding *that* in a
maintenance release would be a far cry from just adding another
symlink).

The lack of near-universal symlink support on Windows filesystems is
also an issue - we would have to duplicate files like python.exe and
pythonw.exe on non-NTFS filesystems in order to provide them under
alternative names.

For *nix, I think there is a simple way forward that is an improvement
over where things stand now. For Windows, I don't think we can do much
better than the status quo and for Mac OS X... I think Apple will do
whatever Apple feel like doing :)



Right, but on Mac OS X we do put a "python3" on the path but not a 
"python2". We also create "python2.x" and "python3.x" variants. So the 
same issues exist yet the pep


On Windows we only have a "python.exe" I believe, but if the user does 
put their Python installs on the path then we *could* usefully create 
"python2.exe" and "python3.exe" for them. I don't see that duplicating 
these binaries on the filesystem is an issue. File associations is just 
unsolvable on Windows, so it isn't something we can address or should 
worry about. (Actually a stub python.exe that looks at the shebang line 
and then delegates to the appropriate pythonX.Y.exe would be a 
possibility but I'm not volunteering to write it.)


All the best,

Michael


Cheers,
Nick.




--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[R. David Murray]

On Fri, 04 Mar 2011 01:44:00 -0600, Kerrick Staley  
wrote:
> * All new code that needs to invoke the Python interpreter should not
> specify "python", but rather should specify either "python2" or "python3"
> (or the more specific "python2.X" and "python3.X" versions; see the Notes).
> This distinction should be made in shebangs, when invoking from a shell
> script, when invoking via the system() call, or when invoking in any other
> context.

If one target for this PEP is script implementors who hadn't thought
about this issue before, it is probably worth mentioning sys.executable
somewhere (a footnote?).

But another issue here (and this speaks against the proposal of not
shipping a /usr/bin/python link) is that it is quite possible to write
a script that will run on either python2 or python3. 

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Simon Cross]

On Fri, Mar 4, 2011 at 3:26 PM, Victor Stinner
 wrote:
> faulthandler is also a little bit special, because it is very specific
> to CPython: it is based on CPython internal structures.

If faulthandler is a public part of the standard library, what should
other Python implementations do about implementing it?

Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate the faulthandler module into Python 3.3?

[Benjamin Peterson]

2011/3/4 Simon Cross :
> On Fri, Mar 4, 2011 at 3:26 PM, Victor Stinner
>  wrote:
>> faulthandler is also a little bit special, because it is very specific
>> to CPython: it is based on CPython internal structures.
>
> If faulthandler is a public part of the standard library, what should
> other Python implementations do about implementing it?

Ignore it as they're free to ignore any other implementation detail.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 16:30-tol lesz a pajton

[Kálmán Gergely]

DD nagytargyalo ebben az idoben. Bocsi a keveresert.

synapse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Westley Martínez]

On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
> On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley  
> wrote:
> > That way, if the sysadmin does decide to replace the installed "python" 
> > file, he can do so without inadvertently deleting the previously installed 
> > binary.
> 
> Nit pick: Change "he" to "they" to be gender neutral.

Nit pick: Change "they" to "he" to be grammatically correct. If we
really have to be gender neutral, change "he" to "he or she".

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Barry Warsaw]

Folks, please stop CC'ing p...@python.org for non-PEP submissions.  They all
get held for moderator approval.  I've approved a few of them, but I'm going
to start rejecting them (so you get a bounce :) unless the message actually
contains a PEP.

cheerfully-co-editing-peps-ly y'rs,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[R. David Murray]

On Fri, 04 Mar 2011 07:03:08 -0800, Westley =?ISO-8859-1?Q?Mart=EDnez?= 
 wrote:
> On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
> > On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley  
> > wrote:
> > > That way, if the sysadmin does decide to replace the installed "python" 
> > > file, he can do so without inadvertently deleting the previously 
> > > installed binary.
> > 
> > Nit pick: Change "he" to "they" to be gender neutral.
> 
> Nit pick: Change "they" to "he" to be grammatically correct. If we
> really have to be gender neutral, change "he" to "he or she".

English is evolving.  I vote for "they".

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Isaac Morland]

On Fri, 4 Mar 2011, R. David Murray wrote:


Nit pick: Change "he" to "they" to be gender neutral.


Nit pick: Change "they" to "he" to be grammatically correct. If we
really have to be gender neutral, change "he" to "he or she".


English is evolving.  I vote for "they".


Sorry, can't resist a further nitpick:  English has not been evolving in 
this particular case, in the sense that "they" has been used as a singular 
since before English was English:


http://motivatedgrammar.wordpress.com/2009/09/10/singular-they-and-the-many-reasons-why-its-correct/

Also interesting:

http://en.wikipedia.org/wiki/Singular_they

Attention "he or she"ists:  Singular "they" won before any of us was born. 
You may want to divert your energies to a more worthy cause, such as 
ensuring proper use of "whom".


Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 395: Module Aliasing

[Nick Coghlan]

There are a bunch of quirks that relate to main modules and
pseudo-packages (like the Python 2.7 and 3.2 style unittest) that
really don't need to be as annoying as they are. This PEP proposes a
few different tricks that should together allow most of those
annoyances to be eliminated.

Full text below, or you can read a nicely formatted version in the usual place:
http://www.python.org/dev/peps/pep-0395/

Cheers,
Nick.


PEP: 395
Title: Module Aliasing
Version: $Revision: 88748 $
Last-Modified: $Date: 2011-03-05 01:26:35 +1000 (Sat, 05 Mar 2011) $
Author: Nick Coghlan 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-Mar-2011
Python-Version: 3.3
Post-History: N/A


Abstract


This PEP proposes new mechanisms that eliminate some longstanding traps for
the unwary when dealing with Python's import system, the pickle module and
introspection interfaces.




What's in a ``__name__``?
=

Over time, a module's ``__name__`` attribute has come to be used to handle a
number of different tasks.

The key use cases identified for this module attribute are:

1. Flagging the main module in a program, using the ``if __name__ ==
   "__main__":`` convention.
2. As the starting point for relative imports
3. To identify the location of function and class definitions within the
   running application
4. To identify the location of classes for serialisation into pickle objects
   which may be shared with other interpreter instances


Traps for the Unwary


The overloading of the semantics of ``__name__`` have resulted in several
traps for the unwary. These traps can be quite annoying in practice, as
they are highly unobvious and can cause quite confusing behaviour. A lot of
the time, you won't even notice them, which just makes them all the more
surprising when they do come up.


Importing the main module twice
---

The most venerable of these traps is the issue of (effectively) importing
``__main__`` twice. This occurs when the main module is also imported under
its real name, effectively creating two instances of the same module under
different names.

This problem used to be significantly worse due to implicit relative imports
from the main module, but the switch to allowing only absolute imports and
explicit relative imports means this issue is now restricted to affecting the
main module itself.


Why are my relative imports broken?
---

PEP 366 defines a mechanism that allows relative imports to work correctly
when a module inside a package is executed via the ``-m`` switch.

Unfortunately, many users still attempt to directly execute scripts inside
packages. While this no longer silently does the wrong thing by
creating duplicate copies of peer modules due to implicit relative imports, it
now fails noisily at the first explicit relative import, even though the
interpreter actually has sufficient information available on the filesystem to
make it work properly.




In a bit of a pickle


Something many users may not realise is that the ``pickle`` module serialises
objects based on the ``__name__`` of the containing module. So objects
defined in ``__main__`` are pickled that way, and won't be unpickled
correctly by another python instance that only imported that module instead
of running it directly. Thus the advice from many Python veterans to do as
little as possible in the ``__main__`` module in any application that
involves any form of object serialisation and persistence.

Similarly, when creating a pseudo-module\*, pickles rely on the name of the
module where a class is actually defined, rather than the officially
documented location for that class in the module hierarchy.

While this PEP focuses specifically on ``pickle`` as the principal
serialisation scheme in the standard library, this issue may also affect
other mechanisms that support serialisation of arbitrary class instances.

\*For the purposes of this PEP, a "pseudo-module" is a package designed like
the Python 3.2 ``unittest`` and ``concurrent.futures`` packages. These
packages are documented as if they were single modules, but are in fact
internally implemented as a package. This is *supposed* to be an
implementation detail that users and other implementations don't need to worry
about, but, thanks to ``pickle``, the details are exposed and effectively
become part of the public API.


Where's the source?
---

Some sophisticated users of the pseudo-module technique described
above recognise the problem with implementation details leaking out via the
``pickle`` module, and choose to address it by altering ``__name__`` to refer
to the public location for the module before defining any functions or classes
(or else by modifying the ``__module__`` attributes of those objects after
they have been defined).

This approach is effective at eliminating the leakage of information via
pickling, but c

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Nick Coghlan]

On Sat, Mar 5, 2011 at 1:10 AM, Barry Warsaw  wrote:
> Folks, please stop CC'ing p...@python.org for non-PEP submissions.  They all
> get held for moderator approval.  I've approved a few of them, but I'm going
> to start rejecting them (so you get a bounce :) unless the message actually
> contains a PEP.

Sorry, I didn't even notice that was on the CC list. Don't add the
PEP, I already created PEP 394 for it :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Nick Coghlan]

On Fri, Mar 4, 2011 at 11:57 PM, R. David Murray  wrote:
> On Fri, 04 Mar 2011 01:44:00 -0600, Kerrick Staley  
> wrote:
>> * All new code that needs to invoke the Python interpreter should not
>> specify "python", but rather should specify either "python2" or "python3"
>> (or the more specific "python2.X" and "python3.X" versions; see the Notes).
>> This distinction should be made in shebangs, when invoking from a shell
>> script, when invoking via the system() call, or when invoking in any other
>> context.
>
> If one target for this PEP is script implementors who hadn't thought
> about this issue before, it is probably worth mentioning sys.executable
> somewhere (a footnote?).

Including a mention of sys.executable is actually one of the changes I
made to Kerrick's text before uploading it as PEP 394.

> But another issue here (and this speaks against the proposal of not
> shipping a /usr/bin/python link) is that it is quite possible to write
> a script that will run on either python2 or python3.

Good point, the PEP should probably mention that.

Sleep is calling me right now, though :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[exarkun]

On 03:30 pm, ncogh...@gmail.com wrote:



Fixing dual imports of the main module
--

Two simple changes are proposed to fix this problem:

1. In ``runpy``, modify the implementation of the ``-m`` switch 
handling to
  install the specified module in ``sys.modules`` under both its real 
name
  and the name ``__main__``. (Currently it is only installed as the 
latter)
2. When directly executing a module, install it in ``sys.modules`` 
under

  ``os.path.splitext(os.path.basename(__file__))[0]`` as well as under
  ``__main__``.

With the main module also stored under its "real" name, imports will 
pick it
up from the ``sys.modules`` cache rather than reimporting it under a 
new name.


Something to consider here is how this will interact with Python files 
which are _not_ modules.  I'm a little uneasy about having 
sys.modules["trial"] refer to the module defined by /usr/bin/trial.


Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Rietveld or Review Board use?

[skip]

Is Rietveld or Review Board being used within the Python core development
community?  I looked at the dev guide but didn't see anything obvious about
code reviews.  I don't see how to search the Rietveld instance at
codereview.appspot.com looking just for Python core review requests.

My aim here is to provide some examples to a colleague at work.  I wanted to
give him some examples related to code with which I'm familiar.

Thx,

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rietveld or Review Board use?

[Victor Stinner]

Le vendredi 04 mars 2011 à 10:05 -0600, s...@pobox.com a écrit :
> Is Rietveld or Review Board being used within the Python core development
> community?  I looked at the dev guide but didn't see anything obvious about
> code reviews.  I don't see how to search the Rietveld instance at
> codereview.appspot.com looking just for Python core review requests.
> 
> My aim here is to provide some examples to a colleague at work.  I wanted to
> give him some examples related to code with which I'm familiar.

I used it at least twice.

Issue #9425: http://codereview.appspot.com/1874048
Issue #3080: http://codereview.appspot.com/3972045

Victor


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Fred Drake]

On Fri, Mar 4, 2011 at 10:59 AM,   wrote:
> Something to consider here is how this will interact with Python files which
> are _not_ modules.  I'm a little uneasy about having sys.modules["trial"]
> refer to the module defined by /usr/bin/trial.

I've long held the position that modules and scripts are distinct, and
should never share a source file.  All the work that's going into
dealing with this just reinforces my position.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Steven D'Aprano]

Westley Martínez wrote:

On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:

On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley  wrote:

That way, if the sysadmin does decide to replace the installed "python" file, 
he can do so without inadvertently deleting the previously installed binary.

Nit pick: Change "he" to "they" to be gender neutral.


Nit pick: Change "they" to "he" to be grammatically correct. If we
really have to be gender neutral, change "he" to "he or she".


Actually, that's a hyper-correction imposed by grammarians in the 18th 
century who were overly influenced by Latin. The use of "they" as a 
generic singular and indeterminate pronoun in written English goes back 
at least to Chaucer in the 14th century, and very likely as long back as 
before English was English, and remains in common use today. Despite the 
distaste for it among (mostly American) grammarians, it is 
linguistically sound and widely accepted in most of the English-speaking 
world, particularly England itself. The use of singular they is 
widespread, natural, and grammatically correct.


http://www.worldwidewords.org/qa/qa-the2.htm
http://en.wikipedia.org/wiki/Singular_they
http://itre.cis.upenn.edu/~myl/languagelog/archivs/005423.html

But for the sake of not upsetting our nuclear-armed cousins on the wrong 
side of the Atlantic *wink*, perhaps the sentence could be reworded to 
refer to system administrators plural, and thus satisfy everyone?


"That way, if sysadmins decide to replace the installed "python" file, 
they can do so without inadvertently deleting the previously installed 
binary."




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rietveld or Review Board use?

[Brian Curtin]

On Fri, Mar 4, 2011 at 10:05,  wrote:

> Is Rietveld or Review Board being used within the Python core development
> community?  I looked at the dev guide but didn't see anything obvious about
> code reviews.  I don't see how to search the Rietveld instance at
> codereview.appspot.com looking just for Python core review requests.
>
> My aim here is to provide some examples to a colleague at work.  I wanted
> to
> give him some examples related to code with which I'm familiar.
>
> Thx,
>
> Skip


I can't find an accompanying issue on Roundup, but participated in a review
of signalmodule.c changes [0] that resulted in a bunch of comments and
subsequent changes, which might be a decent example.

[0] http://codereview.appspot.com/1132041/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Steven D'Aprano]

Fred Drake wrote:

On Fri, Mar 4, 2011 at 10:59 AM,   wrote:

Something to consider here is how this will interact with Python files which
are _not_ modules.  I'm a little uneasy about having sys.modules["trial"]
refer to the module defined by /usr/bin/trial.


I've long held the position that modules and scripts are distinct, and
should never share a source file.  All the work that's going into
dealing with this just reinforces my position.



Perhaps I've misunderstood something, but it seems to me that three out 
of the five problems described in the PEP have nothing to do with 
modules and scripts sharing the same file.




--
Steven

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Ronald Oussoren]

On 04 Mar, 2011,at 02:21 PM, Nick Coghlan  wrote:
For *nix, I think there is a simple way forward that is an improvement
over where things stand now. For Windows, I don't think we can do much
better than the status quo and for Mac OS X... I think Apple will do
whatever Apple feel like doing :) Apple will generally follow what we decide to do for the base install. Anyway, I'd say that OSX should do the same as Unix platforms here and support '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.RonaldP.S. I'm a bit confused about this discussion though, wouldn't adding python2 to the installation be a feature change and as such not something that can be done in a maintenance branch?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Thomas Wouters]

On Fri, Mar 4, 2011 at 07:30, Nick Coghlan  wrote:

> Fixing dual imports of the main module
> --
>
> Two simple changes are proposed to fix this problem:
>
> 1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
>   install the specified module in ``sys.modules`` under both its real name
>   and the name ``__main__``. (Currently it is only installed as the latter)
> 2. When directly executing a module, install it in ``sys.modules`` under
>   ``os.path.splitext(os.path.basename(__file__))[0]`` as well as under
>   ``__main__``.
>
> With the main module also stored under its "real" name, imports will pick
> it
> up from the ``sys.modules`` cache rather than reimporting it under a new
> name.
>

This does nothing to fix another common error: *unwittingly* importing the
main module under its real name -- for example when you intended to import,
say, a standard library module of the same name. ('socket.py' is a
surprisingly common name for a script to experiment with socket
functionality. Likewise, nowadays, 'twitter.py'.) While the proposed change
would make it less *broken* to import the main module again, does it make it
any more *sensible*? Is there really a need to support this? A clear warning
-- or even error -- would seem much more in place. Doing so is not
particularly hard: keep a mapping of modules by canonical filename along
with by modulename, and refuse to add the same file twice. (I'm not talking
about executing a module inside a package, mind, since that can't shadow a
stdlib module by accident anymore.)

Fixing direct execution inside packages
> ---
>
> To fix this problem, it is proposed that an additional filesystem check be
> performed before proceeding with direct execution of a ``PY_SOURCE`` or
> ``PY_COMPILED`` file that has been named on the command line.
>

This should only happen if the file is a valid import target.


> This additional check would look for an ``__init__`` file that is a peer to
> the specified file with a matching extension (either ``.py``, ``.pyc`` or
> ``.pyo``, depending what was passed on the command line).
>

I assume you mean for this to match the normal import rules for packages;
why not just say that? Also, should this consider situations other than the
vanilla run/import-from-filesystem? Should meta-importers and such get a
crack at solving this?


> If this check fails to find anything, direct execution proceeds as usual.
>
> If, however, it finds something, execution is handed over to a
> helper function in the ``runpy`` module that ``runpy.run_path`` also
> invokes
> in the same circumstances. That function will walk back up the
> directory hierarchy from the supplied path, looking for the first directory
> that doesn't contain an ``__init__`` file. Once that directory is found, it
> will be set to ``sys.path[0]``, ``sys.argv[0]`` will be set to ``-m`` and
> ``runpy._run_module_as_main`` will be invoked with the appropriate module
> name (as calculated based on the original filename and the directories
> traversed while looking for a directory without an ``__init__`` file.
>
>
> Fixing pickling without breaking introspection
> --
>
> To fix this problem, it is proposed to add two optional module level
> attributes: ``__source_name__`` and ``__pickle_name__``.
>
> When setting the ``__module__`` attribute on a function or class, the
> interpreter will be updated to use ``__source_name__`` if defined, falling
> back to ``__name__`` otherwise.
>
> ``__source_name__`` will automatically be set to the main module's "real"
> name
> (as described above under the fix to prevent duplicate imports of the main
> module) by the interpreter. This will fix both pickling and introspection
> for
> the main module.
>
> It is also proposed that the pickling mechanism for classes and functions
> be
> updated to use an optional ``__pickle_module__`` attribute when deciding
> how
> to pickle these objects (falling back to the existing ``__module__``
> attribute if the optional attribute is not defined). When a class or
> function
> is defined, this optional attribute will be defined if ``__pickle_name__``
> is
> defined at the module level, and left out otherwise. This will allow
> pseudo-modules to fix pickling without breaking introspection.
>
> Other serialisation schemes could add support for this new attribute
> relatively easily by replacing ``x.__module__`` with ``getattr(x,
> "__pickle_module__", x.__module__)``.
>
> ``pydoc`` and ``inspect`` would also be updated to make appropriate use of
> the new attributes for any cases not already covered by the above rules for
> setting ``__module__``.
>

Is this cornercase really worth polluting the module namespace with more
confusing __*__ names? It seems more sensible to me to simply make pickle
refuse to operate on classes and functions defined in __main__. It wouldn't
even be the least 

Re: [Python-Dev] PEP 395: Module Aliasing

[Steven D'Aprano]

Nick Coghlan wrote:


Fixing direct execution inside packages
---

To fix this problem, it is proposed that an additional filesystem check be
performed before proceeding with direct execution of a ``PY_SOURCE`` or
``PY_COMPILED`` file that has been named on the command line.

This additional check would look for an ``__init__`` file that is a peer to
the specified file with a matching extension (either ``.py``, ``.pyc`` or
``.pyo``, depending what was passed on the command line).

If this check fails to find anything, direct execution proceeds as usual.

If, however, it finds something, execution is handed over to a
helper function in the ``runpy`` module that ``runpy.run_path`` also invokes
in the same circumstances. That function will walk back up the
directory hierarchy from the supplied path, looking for the first directory
that doesn't contain an ``__init__`` file. Once that directory is found, it
will be set to ``sys.path[0]``,


I think you mean that sys.path[0] will be set to the directory path.

Should the current working directory continue to be included in the path 
when running a sub-package module?



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2011-02-25 - 2011-03-04)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open2691 ( +9)
  closed 20487 (+65)
  total  23178 (+74)

Open issues with patches: 1143 


Issues opened (50)
==

#11258: ctypes: Speed up find_library() on Linux by 500%
http://bugs.python.org/issue11258  reopened by pitrou

#11324: ConfigParser(interpolation=None) doesn't work
http://bugs.python.org/issue11324  opened by tbrink

#11329: PyEval_InitThreads() not safe before Py_Initialize()
http://bugs.python.org/issue11329  opened by Juraj.Ivancic

#11332: Increase logging/__init__.py coverage to 97%
http://bugs.python.org/issue11332  opened by drakeol

#11333: Add empty __slots__ to collections.abc abstract base classes
http://bugs.python.org/issue11333  opened by durban

#11335: Memory leak after key function failure in sort
http://bugs.python.org/issue11335  opened by stutzbach

#11337: Nothing refers to footnote [1] on page "6. Simple Statements" 
http://bugs.python.org/issue11337  opened by MLModel

#11338: No list of Python hg repositories
http://bugs.python.org/issue11338  opened by blokeley

#11339: annotation for class being defined
http://bugs.python.org/issue11339  opened by andyharrington

#11342: ResourceWarning: unclosed file <_io.TextIOWrapper
http://bugs.python.org/issue11342  opened by cjejuni2000

#11343: Make errors due to full parser stack identifiable
http://bugs.python.org/issue11343  opened by Trundle

#11344: Add height argument to os.path.dirname()
http://bugs.python.org/issue11344  opened by blokeley

#11346: Generator object should be mentioned in gc module document
http://bugs.python.org/issue11346  opened by ishimoto

#11347: libpython3.so: Broken soname and linking
http://bugs.python.org/issue11347  opened by Arfrever

#11349: _pickle should implement the module finalisation protocol
http://bugs.python.org/issue11349  opened by ncoghlan

#11350: __setitem__()'s problem of dbm.dumb object pointed out by comm
http://bugs.python.org/issue11350  opened by ysj.ray

#11352: Bug in cgi module doc
http://bugs.python.org/issue11352  opened by quentel

#11354: argparse: nargs could accept range of options count
http://bugs.python.org/issue11354  opened by wm

#11355: os.mkdir() and os.mkdirat() don't apply SUID/SGID permissions
http://bugs.python.org/issue11355  opened by Arfrever

#11357: Add support for PEP 381 -- Mirror Authenticity
http://bugs.python.org/issue11357  opened by kelseyhightower

#11361: suggestion for os.kill(pid,CTRL_C_EVENT)
http://bugs.python.org/issue11361  opened by iigor

#11362: image/webp missing from mimetypes.py
http://bugs.python.org/issue11362  opened by Richard.Rabbat

#11363: Curses - add missing functions to doc
http://bugs.python.org/issue11363  opened by sandro.tosi

#11364: Move from distutils.sysconfig to sysconfig in test_osx_env
http://bugs.python.org/issue11364  opened by eric.araujo

#11365: Integrate Buildroot patches (cross-compilation)
http://bugs.python.org/issue11365  opened by haypo

#11366: xml.etree.ElementTree.Element: docs should mention immediate s
http://bugs.python.org/issue11366  opened by techtonik

#11367: xml.etree.ElementTree.find(all): docs are wrong
http://bugs.python.org/issue11367  opened by techtonik

#11368: Document why xml.etree.ElementTree.Element has no reference to
http://bugs.python.org/issue11368  opened by techtonik

#11369: Add caching for the isEnabledFor() computation
http://bugs.python.org/issue11369  opened by William.Hart

#11370: Fix distutils to carry configure's LIBS through to extension m
http://bugs.python.org/issue11370  opened by jszakmeister

#11371: Localization of error messages in getopt
http://bugs.python.org/issue11371  opened by gruszczy

#11373: Fix 2 new typos in the docs
http://bugs.python.org/issue11373  opened by Retro

#11374: pkgutil.extend_path do not recognize py{c,o} file
http://bugs.python.org/issue11374  opened by Alexandre.Badez

#11375: urllib2 over SOCKS doesn't use proxy for DNS
http://bugs.python.org/issue11375  opened by OJW

#11376: Solaris/GCC/shared lib problem
http://bugs.python.org/issue11376  opened by dabrahams

#11379: Remove "lightweight" from minidom description
http://bugs.python.org/issue11379  opened by scoder

#11380: "close failed in file object destructor" when "Broken pipe" ha
http://bugs.python.org/issue11380  opened by ulidtko

#11382: some posix module functions unnecessarily release the GIL
http://bugs.python.org/issue11382  opened by neologix

#11383: compilation seg faults on insanely large expressions
http://bugs.python.org/issue11383  opened by ncoghlan

#11385: TextTestRunner methods are not documented
http://bugs.python.org/issue11385  opened by techtonik

#11387: Tkinter, callback functions
http://bugs.python.org/issue11387  opened by Nikolay.Fomichev

#11388: Implement MutableSequence.clear()
http://bugs.pytho

Re: [Python-Dev] Rietveld or Review Board use?

[Barry Warsaw]

On Mar 04, 2011, at 05:19 PM, Victor Stinner wrote:

>Le vendredi 04 mars 2011 à 10:05 -0600, s...@pobox.com a écrit :
>> Is Rietveld or Review Board being used within the Python core development
>> community?  I looked at the dev guide but didn't see anything obvious about
>> code reviews.  I don't see how to search the Rietveld instance at
>> codereview.appspot.com looking just for Python core review requests.
>> 
>> My aim here is to provide some examples to a colleague at work.  I wanted to
>> give him some examples related to code with which I'm familiar.
>
>I used it at least twice.
>
>Issue #9425: http://codereview.appspot.com/1874048
>Issue #3080: http://codereview.appspot.com/3972045

Yep, I used Rietveld for the PEP 3147/3149 patches and it was pretty nice.
It's not completely well integrated into our workflow, but it's cool enough
that I think we should promote it more.  Will that be easier once we're
permanently on Mercurial?

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summer of Code: call for ideas and mentors

[Martin v. Löwis]

> Would you consider working on benchmarking (http://speed.pypy.org but
> also infrastructure for running it) a part of core GSoC work? I can
> imagine this to be useful not only for pypy and preferably also
> running CPython trunk on benchmarks.

IMO, the question really is if this is "primarily" about coding.
If it is merely setting up software that already exists, it doesn't
convey the feeling of open source programming.

So unless the task is to come up with additional benchmarks (or some
such), I'd be opposed, I think. OTOH, PyPy is its own subgroup within
the PSF GSoC, so this is not for me to decide.

There is also the issue with greenfield projects - if the task is to
come up with a new webapp, it may not well integrate with an existing
code base. However, having that integration is (or should be, IMO)
also a requirement for GSoC.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[Georg Brandl]

On 04.03.2011 13:59, Victor Stinner wrote:
> Hi,
> 
> Does the bug tracker will continue to support rX links after the
> migration to Mercurial? 

Yes.  They will link to http://hg.python.org/lookup/rX, which uses
the conversion metadata to find the correct hg revision.

The syntax for changeset hash links from now on is [hash], e.g.
[1a1ed76a6ae2].

Georg


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summer of Code: call for ideas and mentors

[Martin v. Löwis]

> Are proof-of-concept projects acceptable as GSoC projects?

I'd say so. It's more rewarding (both for the student and the project)
if the code has a chance to be integrated, at least in principle.
However, doing a project and then finding out that the real solution
should be similar but different is perfectly fine, IMO - it gives some
motivation for the student to do the real thing afterwards.

> Experimenting with this idea became significantly more feasible since
> Brett wrote importlib, but would still require a strong understanding
> of Python's import system. I suspect even a proof of concept that was
> tested against just filesystem imports and zipimport would prove quite
> tricky.

That, of course, makes it a difficult GSoC project. Ideally, the student
should have a clear vision of what needs to be done. Failing that, the
mentor should have a clear vision, and would then need frequent
communication with the student.

> Once the concept has been proven... I'm sure we could figure out
> *something* useful to do with the idea. It would depend on the details
> of what actually turns out to be feasible.

It can't hurt to post that idea on the wiki page, with detail as to
what might constitute success of the project. Students are expected
to write proposals elaborating what it is that they want to do, and
a decision on accepting projects is only taken after we have the
proposals (and ideally after the potential mentor had communication
with the student).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Barry Warsaw]

On Mar 04, 2011, at 11:22 AM, Fred Drake wrote:

>On Fri, Mar 4, 2011 at 10:59 AM,   wrote:
>> Something to consider here is how this will interact with Python files which
>> are _not_ modules.  I'm a little uneasy about having sys.modules["trial"]
>> refer to the module defined by /usr/bin/trial.
>
>I've long held the position that modules and scripts are distinct, and
>should never share a source file.  All the work that's going into
>dealing with this just reinforces my position.

I agree.  In fact, so do the distribution tools.  I don't even include actual
scripts in my packages any more, I just add the right goo to setup.py and let
distutils DTRT:


setup(
# ...
entry_points= {
'console_scripts' : list(scripts),
},
# ...
)

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summer of Code: call for ideas and mentors

[Martin v. Löwis]

Am 04.03.2011 13:35, schrieb Antoine Pitrou:
> On Fri, 04 Mar 2011 09:35:38 +0100
> "Martin v. Löwis"  wrote:
>> Google Summer of Code is coming up again, and we will again
>> be participating. Arc Riley will setup infrastructure later
>> today, and we need to start thinking about possible projects.
> 
> We've had a couple of people asking questions about GSoC on
> #python-dev. Each time I redirected them to Arc's personal email, since
> there seems to be no dedicated mailing-list for that. Is there a better
> way to inform them?

Not yet. The students worry too much: there is still plenty of time :-)
However, if they want to start contacting developers, and start
discussing ideas, and if they see Python core as a potential field of
activity, they should actually start talking on python-dev. The idea
is that they do not only bond with the mentor, but with the project.

In principle, talking on IRC is also a good idea, assuming any potential
mentors are listening there. Google recommends students to contact the
IRC channels. I personally don't use instant messaging usually, so
somebody else would need to give them his view on GSoC.

Likewise, if they want to contribute to some other project under the PSF
umbrella, they can start talking to the respective developers on the
respective channels.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[Martin v. Löwis]

Am 04.03.2011 18:17, schrieb Georg Brandl:
> On 04.03.2011 13:59, Victor Stinner wrote:
>> Hi,
>>
>> Does the bug tracker will continue to support rX links after the
>> migration to Mercurial? 
> 
> Yes.  They will link to http://hg.python.org/lookup/rX, which uses
> the conversion metadata to find the correct hg revision.
> 
> The syntax for changeset hash links from now on is [hash], e.g.
> [1a1ed76a6ae2].

Is it really necessary to have the square brackets? ISTM that
the syntax of the short or long hash is unambiguous enough.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Michael Foord]

On 04/03/2011 17:07, Barry Warsaw wrote:

On Mar 04, 2011, at 11:22 AM, Fred Drake wrote:


On Fri, Mar 4, 2011 at 10:59 AM,  wrote:

Something to consider here is how this will interact with Python files which
are _not_ modules.  I'm a little uneasy about having sys.modules["trial"]
refer to the module defined by /usr/bin/trial.

I've long held the position that modules and scripts are distinct, and
should never share a source file.  All the work that's going into
dealing with this just reinforces my position.

I agree.  In fact, so do the distribution tools.  I don't even include actual
scripts in my packages any more, I just add the right goo to setup.py and let
distutils DTRT:




That (below) is not distutils it is setuptools. distutils just uses 
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.


Michael Foord


setup(
 # ...
 entry_points= {
 'console_scripts' : list(scripts),
 },
 # ...
 )

-Barry


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Barry Warsaw]

On Mar 04, 2011, at 05:35 PM, Michael Foord wrote:

>That (below) is not distutils it is setuptools. distutils just uses 
>`scripts=[...]`, which annoyingly *doesn't* work with setuptools.

Sure, but that'll all be moot when distutils2 is integrated into Python
3.3, right? :)

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Michael Foord]

On 04/03/2011 17:24, Barry Warsaw wrote:

On Mar 04, 2011, at 05:35 PM, Michael Foord wrote:


That (below) is not distutils it is setuptools. distutils just uses 
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.

Sure, but that'll all be moot when distutils2 is integrated into Python
3.3, right? :)



Nope. :-) It's still setuptools and not distutils2 format.

Michael


-Barry



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Kerrick Staley]

> Right, but on Mac OS X we do put a "python3" on the path but not a
"python2". We also
> create "python2.x" and "python3.x" variants.

The PEP makes a recommendation for all *nix platform, which includes Mac OS
X. I was not aware that Apple preinstalled Python on OS X, but it doesn't
really matter: Apple is the "distribution maintainer", and they will be
expected to follow the recommendations of this PEP. Even if Apple is
sluggish in getting this change pushed out, it can be resolved on a
per-system basis by the sysadmin.

> On Windows we only have a "python.exe" I believe, but if the user does put
their Python
> installs on the path then we *could* usefully create "python2.exe" and
"python3.exe" for
> them. I don't see that duplicating these binaries on the filesystem is an
issue. File
> associations is just unsolvable on Windows, so it isn't something we can
address or should
> worry about. (Actually a stub python.exe that looks at the shebang line
and then
> delegates to the appropriate pythonX.Y.exe would be a possibility but I'm
not
> volunteering to write it.)

I like your idea for Windows, but it would take time to implement this
solution, and we won't be able to finalize the solution for *nix as quickly
if we also provide a provision for Windows in this same PEP.

We should keep the use of the singular "they"; it's more popular than the
universal "he" (I intended the universal, rather than gender-specific,
meaning in the drafts of the PEP).

-Kerrick Staley

On Fri, Mar 4, 2011 at 9:50 AM, Ronald Oussoren wrote:

>
>
> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan  wrote:
>
>
> For *nix, I think there is a simple way forward that is an improvement
> over where things stand now. For Windows, I don't think we can do much
> better than the status quo and for Mac OS X... I think Apple will do
> whatever Apple feel like doing :)
>
>
> Apple will generally follow what we decide to do for the base install.
>
> Anyway, I'd say that OSX should do the same as Unix platforms here and
> support '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.
>
> Ronald
>
> P.S. I'm a bit confused about this discussion though, wouldn't adding
> python2 to the installation be a feature change and as such not something
> that can be done in a maintenance branch?
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Martin v. Löwis]

>>> Should any of this also apply to Mac OS X and Windows?
>> Any platform that considers itself "unix-like" in this context can
>> decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
>> aspects of OS X). The main point of the PEP is to get a consensus
>> recommendation out of python-dev as to the best way forward (and I
>> think Kerrick did a good job of summarising the position that has been
>> expressed in this thread).
>>
> Right, but the pep doesn't address those issues for some fairly major
> platforms.

Correct. IIUC (i.e. from the viewpoint of the PEP author), that's
deliberate. He just doesn't care about Windows, and, as a PEP author,
he clearly has the right to do so :-)

> 
>> More generally, Windows and Mac OS X developers seem to be happier
>> with the idea of bundling a Python interpreter inside the application
>> than traditional *nix style platforms. This is a PITA for the system
>> maintainer when it comes time to handle security vulnerabilites, but
>> certainly more convenient when upgrading the default Python install.
>>
> 
> However on Mac OS X at least *scripts* have the same issue (what to put
> in the shebang line).

IMO, MacOS does fall under the rule of the PEP - it is unixish.
I agree with all things that Nick said, in particular with the
observation that Apple will do what Apple will do, no matter how
many PEPs we write. Our own "make install", for OSX, should clearly
do something similar to what it does on other Unix systems.

> On Windows we only have a "python.exe" I believe, but if the user does
> put their Python installs on the path then we *could* usefully create
> "python2.exe" and "python3.exe" for them. I don't see that duplicating
> these binaries on the filesystem is an issue. File associations is just
> unsolvable on Windows, so it isn't something we can address or should
> worry about. (Actually a stub python.exe that looks at the shebang line
> and then delegates to the appropriate pythonX.Y.exe would be a
> possibility but I'm not volunteering to write it.)

Here I also agree with Nick: the binary file name might be the least
issue. We had one bug report about 2.x and 3.x interference so far that
was difficult to track down - it seems that many Python users on Windows
set PYTHONPATH, and that is going to break Python 3 installations.

With that problem, and the extension problem, solving the exe name issue
doesn't actually resolve real problems.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Fred Drake]

On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
 wrote:
> That (below) is not distutils it is setuptools. distutils just uses
> `scripts=[...]`, which annoyingly *doesn't* work with setuptools.

Right; distutils scripts are just sad.

OTOH, entry-point based scripts are something setuptools got very,
very right.  Probably not perfect, but... I've not yet needed anything
different in practice.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Martin v. Löwis]

> P.S. I'm a bit confused about this discussion though, wouldn't adding
> python2 to the installation be a feature change and as such not
> something that can be done in a maintenance branch?

Correct. However, IMO, a PEP could propose to break that rule. Having
such a proposal may cause rejection of the PEP (or conditional
acceptance only if that change is not carried out). If the PEP is
accepted, a special case may be special enough to break the rules.

In addition, distributions can add all symlinks they like in their
packages, even if "make install" doesn't create them. Whether or not
*that* is a feature change depends on the distribution policy. For
example, for Debian, it would likely be perfectly reasonable to do
that in the 2.7 installation, since 2.7 will be a new feature for
Debian, anyway.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Barry Warsaw]

On Mar 03, 2011, at 08:09 PM, Toshio Kuratomi wrote:

>Note to dmalcolm: IIRC, that also means that the Feature page you point to
>isn't going to happen either.  Barry -- if other distros adopted stronger
>policies, then that might justify me taking this back to the Packaging
>Committee.

I know Scott Kitterman has talked about updating the Debian policy for various
issues.  Other Debian devs are on this list, but I'll bring it up over there
and get it on the radar.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[Georg Brandl]

On 04.03.2011 18:33, "Martin v. Löwis" wrote:
> Am 04.03.2011 18:17, schrieb Georg Brandl:
>> On 04.03.2011 13:59, Victor Stinner wrote:
>>> Hi,
>>>
>>> Does the bug tracker will continue to support rX links after the
>>> migration to Mercurial? 
>> 
>> Yes.  They will link to http://hg.python.org/lookup/rX, which uses
>> the conversion metadata to find the correct hg revision.
>> 
>> The syntax for changeset hash links from now on is [hash], e.g.
>> [1a1ed76a6ae2].
> 
> Is it really necessary to have the square brackets? ISTM that
> the syntax of the short or long hash is unambiguous enough.

It's not really needed; but since it works with 6+ hex digits there might
be false positives.

Also, since the hashes can look deceptively like words to the eye I find
that they read better when marked clearly.

But of course this is not set in stone yet.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Michael Foord]

On 04/03/2011 17:45, Kerrick Staley wrote:
> Right, but on Mac OS X we do put a "python3" on the path but not a 
"python2". We also

> create "python2.x" and "python3.x" variants.

The PEP makes a recommendation for all *nix platform, which includes 
Mac OS X. I was not aware that Apple preinstalled Python on OS X, but 
it doesn't really matter: Apple is the "distribution maintainer", and 
they will be expected to follow the recommendations of this PEP. Even 
if Apple is sluggish in getting this change pushed out, it can be 
resolved on a per-system basis by the sysadmin.




So there are three issues:

* What Apple does with the system install - out of our control but we 
can make recommendations

* What `make install` does on Mac OS X
* What the standard Mac OS X installer does

The last two of these are in our control. If we actually make changes to 
the build/install scripts of 2.7, rather than just recommendations for 
distributions, then it would be nice to see the changes in the installer 
as well as the build script. This would ultimately be up to Ronald or 
Ned who do the Mac OS X work of course.


> On Windows we only have a "python.exe" I believe, but if the user 
does put their Python
> installs on the path then we *could* usefully create "python2.exe" 
and "python3.exe" for
> them. I don't see that duplicating these binaries on the filesystem 
is an issue. File
> associations is just unsolvable on Windows, so it isn't something we 
can address or should
> worry about. (Actually a stub python.exe that looks at the shebang 
line and then
> delegates to the appropriate pythonX.Y.exe would be a possibility but 
I'm not

> volunteering to write it.)

I like your idea for Windows, but it would take time to implement this 
solution, and we won't be able to finalize the solution for *nix as 
quickly if we also provide a provision for Windows in this same PEP.


I don't think duplicating python.exe as python2.exe or python3.exe would 
be very much work at all, if we decide it is a good thing. Sure it 
doesn't resolve all the myriad problems of Python on Windows but I don't 
think that is a good reason not to consider it. Up to Martin on this one 
though and again depends if we just make recommendations or actually 
change Python 2.7.


All the best,

Michael



We should keep the use of the singular "they"; it's more popular than 
the universal "he" (I intended the universal, rather than 
gender-specific, meaning in the drafts of the PEP).


-Kerrick Staley

On Fri, Mar 4, 2011 at 9:50 AM, Ronald Oussoren 
mailto:ronaldousso...@mac.com>> wrote:




On 04 Mar, 2011,at 02:21 PM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:


For *nix, I think there is a simple way forward that is an
improvement
over where things stand now. For Windows, I don't think we can do
much
better than the status quo and for Mac OS X... I think Apple will do
whatever Apple feel like doing :)

Apple will generally follow what we decide to do for the base
install.

Anyway, I'd say that OSX should do the same as Unix platforms here
and support '#!/usr/bin/env python2'. Adding another symlink is
fairly trivial.

Ronald

P.S. I'm a bit confused about this discussion though, wouldn't
adding python2 to the installation be a feature change and as such
not something that can be done in a maintenance branch?

___
Python-Dev mailing list
Python-Dev@python.org 
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Barry Warsaw]

On Mar 05, 2011, at 01:33 AM, Nick Coghlan wrote:

>On Sat, Mar 5, 2011 at 1:10 AM, Barry Warsaw  wrote:
>> Folks, please stop CC'ing p...@python.org for non-PEP submissions.  They all
>> get held for moderator approval.  I've approved a few of them, but I'm going
>> to start rejecting them (so you get a bounce :) unless the message actually
>> contains a PEP.
>
>Sorry, I didn't even notice that was on the CC list. Don't add the
>PEP, I already created PEP 394 for it :)

Thanks!
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[R. David Murray]

On Fri, 04 Mar 2011 15:50:01 +, Ronald Oussoren  
wrote:
> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan  wrote:
> 
> For *nix, I think there is a simple way forward that is an improvement
> over where things stand now. For Windows, I don't think we can do much
> better than the status quo and for Mac OS X... I think Apple will do
> whatever Apple feel like doing :)
> 
> Apple will generally follow what we decide to do for the base install.
> 
> Anyway, I'd say that OSX should do the same as Unix platforms here and support
> '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.

FYI, Ronald, the text version of your emails looses all quoting
information.  It would be nice if you could use standard email
quoting (leading '>' characters).

> P.S. I'm a bit confused about this discussion though, wouldn't adding python2 
> to
> the installation be a feature change and as such not something that can be 
> done
> in a maintenance branch?

The purpose of the "no new features" rule is to prevent the situation
where a piece of code written for X.X.2 fails to run on X.X.1 because
it relies on a feature introduced in X.X.2.  In this situation, we
*already* have failures because scripts using /usr/bin/python2 that
run on one distro won't run on a different distro where that symlink
isn't defined.  In this case I don't think the "no new features" rule
can be applied blindly, because the feature has *already been introduced*
by third parties.  What we are attempting to do is make it *more* likely
that things will work in the future.

You can argue that having /usr/bin/python2 installed by 2.7.2 means
that code written for 2.7.2 that relies on it won't run on a vanilla
user-install of 2.7.1 or 2.7.  But how likely is that scenario compared
to the scenario where a script written for another distro fails to run
because /usr/bin/python2 doesn't exist?  I think the balance of the
argument comes down in favor of making the change, personally.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Barry Warsaw]

On Mar 03, 2011, at 08:37 PM, Toshio Kuratomi wrote:

>No, alternatives is really only useful for a very small class of problems
>[1]_ and [2]_.

Thanks for the clarification.  I was on the fence about making the suggestion
in the first place. ;)

>For this discussion there's an additional problem which is that alternatives
>works by creating symlinks.  Piotr Ożarowski wants to make /usr/bin/python
>not exist so that scripts would have to use either /usr/bin/python3 or
>/usr/bin/python2.  If alternatives places a symlink there, it defeats the
>purpose of avoiding that path in the package itself.

I don't agree that /usr/bin/python should not be installed.  The draft PEP
language hits the right tone IMHO, and I would favor /usr/bin/python pointing
to /usr/bin/python2 on Debian, but primarily used only for the interactive
interpreter.

Or IOW, I still want users to be able to type 'python' at a shell prompt and
get the interpreter.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Guido van Rossum]

Is there any discussion still going on about the details of the PEP
(now PEP 394)? I'm in favor of the general idea. What about Windows? I
think it should be the same there if possible.

The only thing I note is that the PEP doesn't explicitly state (unless
I missed it) that "python" should invoke the same Python binary as
either "python2" or "python3" and not some other version of Python
{2,3}.x (at least not until python4 is being considered :-).
Similarly, python2 and python3 should refer to one of the existing
python2.x or python3.x binary and not some other one.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rietveld or Review Board use?

[skip]

Thanks for the examples.  I've passed them along to my colleague.  The two
which Victor posted are (I think) particularly instructive because the
changes to support Unicode were so pervasive.  I don't see how you could
easily (if at all) get a decent review of those changes without support from
tools like Rietveld or Review Board.  At the very least it would take a huge
amount of dedication and effort to keep everything straight.

Skip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rietveld or Review Board use?

[Andi Albrecht]

On Fri, Mar 4, 2011 at 5:52 PM, Barry Warsaw  wrote:
> On Mar 04, 2011, at 05:19 PM, Victor Stinner wrote:
>
>>Le vendredi 04 mars 2011 à 10:05 -0600, s...@pobox.com a écrit :
>>> Is Rietveld or Review Board being used within the Python core development
>>> community?  I looked at the dev guide but didn't see anything obvious about
>>> code reviews.  I don't see how to search the Rietveld instance at
>>> codereview.appspot.com looking just for Python core review requests.
>>>
>>> My aim here is to provide some examples to a colleague at work.  I wanted to
>>> give him some examples related to code with which I'm familiar.
>>
>>I used it at least twice.
>>
>>Issue #9425: http://codereview.appspot.com/1874048
>>Issue #3080: http://codereview.appspot.com/3972045
>
> Yep, I used Rietveld for the PEP 3147/3149 patches and it was pretty nice.
> It's not completely well integrated into our workflow, but it's cool enough
> that I think we should promote it more.  Will that be easier once we're
> permanently on Mercurial?

FWIW there's a nice section in the contribution guidelines for the Go
language about code reviews and how they integrate Rietveld into their
development process: http://golang.org/doc/contribute.html#Code_review
They're using a wrapper around the upload.py script bundled as a
Mercurial extension.

And IIRC there's already some Roundup integration done.

-Andi

>
> -Barry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/albrecht.andi%40googlemail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Toshio Kuratomi]

On Fri, Mar 04, 2011 at 01:56:39PM -0500, Barry Warsaw wrote:
> 
> I don't agree that /usr/bin/python should not be installed.  The draft PEP
> language hits the right tone IMHO, and I would favor /usr/bin/python pointing
> to /usr/bin/python2 on Debian, but primarily used only for the interactive
> interpreter.
> 
> Or IOW, I still want users to be able to type 'python' at a shell prompt and
> get the interpreter.
> 
Actually, my post was saying that these two can be decoupled.  ie: It's
possible to not have /usr/bin/python while still allowing users to type
python at a shell prompt and get the interpreter.

This is done by either redefining the PATH to include the directory that the
interpreter named "python" is in or by creating an alias for python to the
proper interpreter.

Using the environment-modules tools is one solution that operated in this
way.  It also, incidentally, would let each user of a system choose whether
python invoked python2 or python3 (and on Debian, which sub-version of
those).  A more hardcoded approach is to have the python package drop some
configuration into /etc/profile.d/ style directories where the distribution
places files that are run by default by the user's shell with the default
startup files.

-Toshio


pgpVTu9R21jxR.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Glyph Lefkowitz]

On Fri, Mar 4, 2011 at 10:03 AM, Westley Martínez wrote:

> On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
> > On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley 
> wrote:
> > > That way, if the sysadmin does decide to replace the installed "python"
> file, he can do so without inadvertently deleting the previously installed
> binary.
> >
> > Nit pick: Change "he" to "they" to be gender neutral.
>
> Nit pick: Change "they" to "he" to be grammatically correct. If we
> really have to be gender neutral, change "he" to "he or she".


This grammatical "rule" is a modern fiction with no particular utility.  Go
ahead and use singular "they" as a gender-neutral pronoun; it was good
enough for Shakespeare, Twain, Austen and Shaw, it should be good enough for
Python.

http://en.wikipedia.org/wiki/Singular_they#Examples_of_generic_they
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial conversion repositories

[Santoso Wijaya]

Hi,

As a mercurial user, I thank you for this effort! One question, where/how do
I send suggestion to what to add into .hgignore file? In particular, I found
these dynamically generated files after a build in Windows (3.2) that
probably should be entered as .hgignore entries:

? PC/python_nt_d.h
? PC/pythonnt_rc_d.h



~/santa


On Mon, Feb 28, 2011 at 1:10 PM, Antoine Pitrou  wrote:

> On Mon, 28 Feb 2011 16:07:48 -0500
> Barry Warsaw  wrote:
> > On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote:
> >
> > >On Mon, 28 Feb 2011 10:08:26 -0500
> > >Barry Warsaw  wrote:
> > >>
> > >> >BTW, I had not heard of hgeditor before, and wrote a small hg
> extension to
> > >> >do what you want (with HG: prefix :) before I saw that others had
> already
> > >> >replied with hgeditor.  The extension had 10 lines of code.
> > >>
> > >> We should find a place (i.e. repository) to stash these useful add-ons
> and
> > >> hacks so that all Python developers can find them.
> > >
> > >I think you can simply add them somewhere on the hg wiki:
> > >http://mercurial.selenic.com/wiki/
> > >and then link to the pages from our own wiki, or the developer's FAQ.
> >
> > If they're of general use to the hg community, sure.  Otherwise, it might
> be
> > good to have a place of our own for our own repository tools.
>
> Well, your diff-in-the-commit-editor-window is certainly not
> CPython-specific ;)
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial conversion repositories

[Martin v. Löwis]

> As a mercurial user, I thank you for this effort! One question,
> where/how do I send suggestion to what to add into .hgignore file? In
> particular, I found these dynamically generated files after a build in
> Windows (3.2) that probably should be entered as .hgignore entries:

All patches should go to the bug tracker. If you host a clone somewhere,
you could start publishing patches by referring to a remote repository,
rather than uploading the diff. I'm curious how this DVCS thing works
out for contributors.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Martin v. Löwis]

Am 04.03.2011 20:14, schrieb Guido van Rossum:
> Is there any discussion still going on about the details of the PEP
> (now PEP 394)? I'm in favor of the general idea. What about Windows? I
> think it should be the same there if possible.

I think a key issue is whether to change future 2.7 bug fix releases or
not. People have been opposed to the very notion of adding this feature
in a bug fix release; not sure how they feel if the change is
PEP-sanctioned.

As for Windows support: we currently don't install a python3.exe binary,
let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
adjust the installer if the PEP asks me to. For the reasons discussed,
I'm -0 on the change (i.e. double-clicking .py will continue to launch
the most-recently installed Python, rather than the "right" one, and
setting PYTHONPATH will continue to break installations).

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[James Y Knight]

On Mar 4, 2011, at 4:21 PM, Martin v. Löwis wrote:
> and setting PYTHONPATH will continue to break installations).

Indeed, it's really *quite* unfortunate that the proposal to make python3 use 
PYTHON3PATH instead of PYTHONPATH was rejected.

James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Martin v. Löwis]

> I don't think duplicating python.exe as python2.exe or python3.exe would
> be very much work at all, if we decide it is a good thing. Sure it
> doesn't resolve all the myriad problems of Python on Windows but I don't
> think that is a good reason not to consider it. Up to Martin on this one
> though and again depends if we just make recommendations or actually
> change Python 2.7.

Changing the installer should be easy - there is a DuplicateFile table
in MSI (*) for this kind of installation task.

I'd still like the PEP to tell me whether it's python3w.exe or
pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
me). It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related question of
whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe)

Regards,
Martin

(*) http://msdn.microsoft.com/en-us/library/aa368335(v=vs.85).aspx
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[Martin v. Löwis]

> It's not really needed; but since it works with 6+ hex digits there might
> be false positives.

I searched the messages, and it turns out that primarily long numbers
would give false positives:

 Python 1.6a2 (#7, Apr 24 2000, 23:02:54)  [GCC pgcc-2.91.66 19990314
 minidom (as the proposed documentation in patch 101821 explains) does
 Closed as Duplicate; see bug 435026 for details.  It's an
 the test is extended to 200 objects on my machine
 IRIX rattler 6.5 10120734 IP32
 hash("DNSSEC") == 8704052292078464
 [New Thread 2305843009213881680 (LWP 23166)]

So I guess mandating square brackets is reasonable - alternatively,
mandating a fixed length could have worked as well, I guess.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[David Malcolm]

On Fri, 2011-03-04 at 18:17 +0100, Georg Brandl wrote:
> On 04.03.2011 13:59, Victor Stinner wrote:
> > Hi,
> > 
> > Does the bug tracker will continue to support rX links after the
> > migration to Mercurial? 
> 
> Yes.  They will link to http://hg.python.org/lookup/rX, which uses
> the conversion metadata to find the correct hg revision.

Are these destinations meant to work yet?

I just tried one of these:
  http://hg.python.org/lookup/r81488
and it's giving me an "Internal Server Error"

FWIW, the above is a commit to release26-maint:
  http://svn.python.org/view?view=revision&revision=81488


Thanks
Dave

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[Antoine Pitrou]

On Fri, 04 Mar 2011 22:45:24 +0100
"Martin v. Löwis"  wrote:
> > It's not really needed; but since it works with 6+ hex digits there might
> > be false positives.
> 
> I searched the messages, and it turns out that primarily long numbers
> would give false positives:
> 
>  Python 1.6a2 (#7, Apr 24 2000, 23:02:54)  [GCC pgcc-2.91.66 19990314
>  minidom (as the proposed documentation in patch 101821 explains) does
>  Closed as Duplicate; see bug 435026 for details.  It's an
>  the test is extended to 200 objects on my machine
>  IRIX rattler 6.5 10120734 IP32
>  hash("DNSSEC") == 8704052292078464
>  [New Thread 2305843009213881680 (LWP 23166)]
> 
> So I guess mandating square brackets is reasonable - alternatively,
> mandating a fixed length could have worked as well, I guess.

The two forms used in hg's output are 10-digit and 40-digit ids
(the latter only with --debug, IIUC). The only reason to use another
form (especially shorter) is if you type the changeset id by hand
rather than paste it, which must not be very common.

And if there are false positives from time to time, well they'll just
link to 404s (unknown ids). I don't think that's an important issue.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial conversion repositories

[Santoso Wijaya]

>
> [...] publishing patches by referring to a remote repository,
>
rather than uploading the diff.
>

Is this a recommended workflow at this point, or should we generate/attach
patch files still? Both, for experimentation?

~/santa


On Fri, Mar 4, 2011 at 1:15 PM, "Martin v. Löwis" wrote:

> > As a mercurial user, I thank you for this effort! One question,
> > where/how do I send suggestion to what to add into .hgignore file? In
> > particular, I found these dynamically generated files after a build in
> > Windows (3.2) that probably should be entered as .hgignore entries:
>
> All patches should go to the bug tracker. If you host a clone somewhere,
> you could start publishing patches by referring to a remote repository,
> rather than uploading the diff. I'm curious how this DVCS thing works
> out for contributors.
>
> Regards,
> Martin
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial conversion repositories

[Antoine Pitrou]

Le vendredi 04 mars 2011 à 14:03 -0800, Santoso Wijaya a écrit :
> [...] publishing patches by referring to a remote repository,
> rather than uploading the diff.
> 
> 
> Is this a recommended workflow at this point, or should we
> generate/attach patch files still? Both, for experimentation? 

Pragmatically, I think we would still prefer patches, but Mercurial
should make it much easier to maintain them - e.g. you can use mq (which
is what Mercurial devs themselves use, actually).

We can also experiment with other forms of publishing changes, but I
think that would require the publisher to somehow collapses their own
changesets, so that it finally amounts to reviewing a patch.  In my
opinion at least, it would be bad if we started integrating intermediate
changesets leading to a final patch just because Mercurial allows us to
do it. I think it's better if the public history line doesn't get
obscured with work-in-progress changesets.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Glenn Linderman]

On 3/4/2011 5:21 AM, Nick Coghlan wrote:

On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord
  wrote:

Should any of this also apply to Mac OS X and Windows?

Any platform that considers itself "unix-like" in this context can
decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y
aspects of OS X). The main point of the PEP is to get a consensus
recommendation out of python-dev as to the best way forward (and I
think Kerrick did a good job of summarising the position that has been
expressed in this thread).

More generally, Windows and Mac OS X developers seem to be happier
with the idea of bundling a Python interpreter inside the application
than traditional *nix style platforms. This is a PITA for the system
maintainer when it comes time to handle security vulnerabilites, but
certainly more convenient when upgrading the default Python install.


Probably because Windows itself is so bloated -- so what is the problem 
with a few extra copies of Python, one per application?


I'm a Windows developer by necessity, rather than choice, but I still 
say ICK to bundling a Python inside my 50-100K Python scripts... bloats 
them to several MB each.




Note that we *do* have alternative distributors [1] of Python for these
platforms who may wish to follow any recommendations we have for 2.7, even
if we don't modify those installers for our own distributions.

The really tricky part on Windows is handling file associations. I
think we're just doomed on that front, unless we want to start
supporting separate .py2 and .py3 extensions (and adding *that* in a
maintenance release would be a far cry from just adding another
symlink).


Supporting .py2 and .py3 extensions is not much harder than adding a 
symlink.  Easier, on versions of windows without symlinks :)


Sadly, Vista (I think) and 7 (for sure) restrict the  "assoc" and 
"ftype" commands with = signs, to being functional only in "Run as 
Administrator" shells, so on those versions, it is harder for the naïve 
to do the reconfigurations themselves.


The extra ftypes and assoc definitions can simply be copied from the 
existing ones, adding or changing a version number.  Would be much nicer 
if the installer did it for the naïve Windows user.




The lack of near-universal symlink support on Windows filesystems is
also an issue - we would have to duplicate files like python.exe and
pythonw.exe on non-NTFS filesystems in order to provide them under
alternative names.


Cheaper to make a couple copies of Python at install, than to bundle the 
whole Python environment in each application.



For *nix, I think there is a simple way forward that is an improvement
over where things stand now. For Windows, I don't think we can do much
better than the status quo and for Mac OS X... I think Apple will do
whatever Apple feel like doing :)


For Windows the status quo is pretty bad, so doing nothing is also 
pretty bad.  I agree the changes are "harder than an extra symlink" on 
Windows, but for someone that understand the installer, adding extra 
ftype and assoc is no harder, as it already knows how to install/replace 
that for .py files.


Sadly, there seems to be strong resistance to the idea of putting the 
Python install directory on the Windows path, of course, without some 
additional solutions (python2.exe, python3.exe, etc.), that doesn't help 
the multi-version install, only the single version install.


It would be _nice_, but harder, and harder to get consensus on, to write 
a little "python launcher" (in a compiled language, not Python, as that 
would double the startup time) to do some grunge on Windows.  Some 
possibilities, not all would be needed.


* Take over the Python.File ftype, look at the Unix #! line, extract the 
version, and run that version of Python from the installed Windows 
location for that version.


* Add .py2 & .py3 assoc and ftype for people that want to use 
Windows-like conventions to launch specific versions of Python.


* Could also add .py24, .py31, or even .py262, .py301, etc., assoc and 
ftype, depending on how many versions of Windows Python are installed.


* Support PYTHONxPATH, and convert to PYTHONPATH before launching 
pythonX.  Only needed if there are is a mix of python major versions 
installed, or PYTHONxPATH is defined in the environment.


* Implement a "Windows #! line" a line just after the "Unix #! line" 
that would specify what Windows executable should be run.  In this case, 
the first item should be adjusted, to use the Windows #! line when it 
exists, instead of extracting the version from the Unix #! line.  In the 
limit, this could be a general utility not limited to Python, that would 
provide Unix like execution of "Windows #! line"-aware applications, 
with or even without, file extensions (without is a little trickier, but 
apparently possible).  This would even allow the use of pythonw.exe to 
be specified for some scripts and not others... the script could choose.
___

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Glenn Linderman]

On 3/4/2011 1:35 PM, "Martin v. Löwis" wrote:

I'd still like the PEP to tell me whether it's python3w.exe or
pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
me). It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related question of
whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe)


I agree the PEP should address these issues.  And since it is 
bikeshedding, as you say, I'm happy to just follow along.


I see no particular advantage to any of the choices, except that both 
"w", and ".exe" are Windows-only things, so making it "just like Unix" + 
Windows-only things would seem more convenient, in some ways.  So I'll 
start the voting for


python VERSION [w] .exe

as the windows sequence.  Whatever form of VERSION, with or without 
dots, is done for Unix seems good for Windows too, as far as I can tell.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Barry Warsaw]

On Mar 4, 2011, at 4:21 PM, Martin v. Löwis wrote:

> Am 04.03.2011 20:14, schrieb Guido van Rossum:
>> Is there any discussion still going on about the details of the PEP
>> (now PEP 394)? I'm in favor of the general idea. What about Windows? I
>> think it should be the same there if possible.
> 
> I think a key issue is whether to change future 2.7 bug fix releases or
> not. People have been opposed to the very notion of adding this feature
> in a bug fix release; not sure how they feel if the change is
> PEP-sanctioned.

I personally don't think it's necessary to change Python 2's build.  Distros 
can easily do it, pointing to the PEP for justification.  But I'm also not 
strongly opposed, so -0 from me.

-Barry

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[Antoine Pitrou]

On Fri, 04 Mar 2011 16:51:15 -0500
David Malcolm  wrote:
> On Fri, 2011-03-04 at 18:17 +0100, Georg Brandl wrote:
> > On 04.03.2011 13:59, Victor Stinner wrote:
> > > Hi,
> > > 
> > > Does the bug tracker will continue to support rX links after the
> > > migration to Mercurial? 
> > 
> > Yes.  They will link to http://hg.python.org/lookup/rX, which uses
> > the conversion metadata to find the correct hg revision.
> 
> Are these destinations meant to work yet?
> 
> I just tried one of these:
>   http://hg.python.org/lookup/r81488
> and it's giving me an "Internal Server Error"

Should be fixed now.

cheers

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Guido van Rossum]

On Fri, Mar 4, 2011 at 1:21 PM, "Martin v. Löwis"  wrote:
> Am 04.03.2011 20:14, schrieb Guido van Rossum:
>> Is there any discussion still going on about the details of the PEP
>> (now PEP 394)? I'm in favor of the general idea. What about Windows? I
>> think it should be the same there if possible.
>
> I think a key issue is whether to change future 2.7 bug fix releases or
> not. People have been opposed to the very notion of adding this feature
> in a bug fix release; not sure how they feel if the change is
> PEP-sanctioned.

Personally I think this is fine -- it 's not like this is affecting
language or library compatibility, but doing this from now on
emphasizes that this is what we want distros to do. As far as I'm
concerned we could go further and add creation of the python2 symlink
to the "make install" target for new bugfix releases of older versions
too.

> As for Windows support: we currently don't install a python3.exe binary,
> let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
> adjust the installer if the PEP asks me to. For the reasons discussed,
> I'm -0 on the change (i.e. double-clicking .py will continue to launch
> the most-recently installed Python, rather than the "right" one, and
> setting PYTHONPATH will continue to break installations).

I'm not a Windows user so I'll leave this part to the group of
interested developers to reach consensus.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Westley Martínez]

On Fri, 2011-03-04 at 22:21 +0100, "Martin v. Löwis" wrote:
> As for Windows support: we currently don't install a python3.exe binary,
> let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
> adjust the installer if the PEP asks me to. For the reasons discussed,
> I'm -0 on the change (i.e. double-clicking .py will continue to launch
> the most-recently installed Python, rather than the "right" one, and
> setting PYTHONPATH will continue to break installations).

I think the python2.exe or python3.exe (or both) for Windows would be a
good idea. I also think we need to seriously consider fixing the
double-click action for Windows. .py2 and .py3 extensions could work,
but seems clumsy.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Brian Curtin]

On Fri, Mar 4, 2011 at 16:04, Glenn Linderman  wrote:
>
> Sadly, there seems to be strong resistance to the idea of putting the
> Python install directory on the Windows path, of course, without some
> additional solutions (python2.exe, python3.exe, etc.), that doesn't help the
> multi-version install, only the single version install.
>

FWIW, I plan on spending time on the PATH issue for 3.3. It seems like much
of the resistance could be quelled with actual code.

It would be _nice_, but harder, and harder to get consensus on, to write a
> little "python launcher" (in a compiled language, not Python, as that would
> double the startup time) to do some grunge on Windows.  Some possibilities,
> not all would be needed.
> 
>
* Could also add .py24, .py31, or even .py262, .py301, etc., assoc and
> ftype, depending on how many versions of Windows Python are installed.
>

-INF
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Westley Martínez]

On Sat, 2011-03-05 at 03:27 +1100, Steven D'Aprano wrote:
> Westley Martínez wrote:
> > On Fri, 2011-03-04 at 00:54 -0800, Aaron DeVore wrote:
> >> On Thu, Mar 3, 2011 at 11:44 PM, Kerrick Staley  
> >> wrote:
> >>> That way, if the sysadmin does decide to replace the installed "python" 
> >>> file, he can do so without inadvertently deleting the previously 
> >>> installed binary.
> >> Nit pick: Change "he" to "they" to be gender neutral.
> > 
> > Nit pick: Change "they" to "he" to be grammatically correct. If we
> > really have to be gender neutral, change "he" to "he or she".
> 
> Actually, that's a hyper-correction imposed by grammarians in the 18th 
> century who were overly influenced by Latin. The use of "they" as a 
> generic singular and indeterminate pronoun in written English goes back 
> at least to Chaucer in the 14th century, and very likely as long back as 
> before English was English, and remains in common use today. Despite the 
> distaste for it among (mostly American) grammarians, it is 
> linguistically sound and widely accepted in most of the English-speaking 
> world, particularly England itself. The use of singular they is 
> widespread, natural, and grammatically correct.
> 
> http://www.worldwidewords.org/qa/qa-the2.htm
> http://en.wikipedia.org/wiki/Singular_they
> http://itre.cis.upenn.edu/~myl/languagelog/archivs/005423.html
> 
> But for the sake of not upsetting our nuclear-armed cousins on the wrong 
> side of the Atlantic *wink*, perhaps the sentence could be reworded to 
> refer to system administrators plural, and thus satisfy everyone?
> 
> "That way, if sysadmins decide to replace the installed "python" file, 
> they can do so without inadvertently deleting the previously installed 
> binary."
> 
> 

All right I have to reply to all these "singular they" remarks. Just
because the singular they has been used for a long time doesn't make it
right. It sounds unnatural, at least to me, and I've always been taught
to use "he or she" which I despise. So all my life I've used the generic
"he". Anyways, I remember reading somewhere that for Python Strunk and
White apply, and neither Strunk nor White like singular theys.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summer of Code: call for ideas and mentors

[Nick Coghlan]

On Sat, Mar 5, 2011 at 3:19 AM, "Martin v. Löwis"  wrote:
>> Experimenting with this idea became significantly more feasible since
>> Brett wrote importlib, but would still require a strong understanding
>> of Python's import system. I suspect even a proof of concept that was
>> tested against just filesystem imports and zipimport would prove quite
>> tricky.
>
> That, of course, makes it a difficult GSoC project. Ideally, the student
> should have a clear vision of what needs to be done. Failing that, the
> mentor should have a clear vision, and would then need frequent
> communication with the student.

I have a reasonably clear vision of what I would like to see. I'm just
not sure if some of the assumptions underlying PEP 302 will make it
unworkable in practice given the current conventions (e.g. there is a
*lot* of code that accesses sys.modules directly. Accommodating such
code without modification would require some reasonably fancy footwork
with either thread local storage or stack frame inspection). If the
issues can't be worked around via TLS or frame inspection, I suspect
several of the PEP 302 interfaces would need to be modified to make
the system work with arbitrary importers and loaders, but actually
implementing something based on importlib (or a fork, if it turns out
interfaces need to change) would be the best way to find out.

I'm a little confused by the
http://wiki.python.org/moin/SummerOfCode/2011 page though. If I'm a
*member* of an approved project (CPython in this case), can I just add
an entry to the table? Or do I need to do something first to be
approved as a prospective mentor?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Nick Coghlan]

On Sat, Mar 5, 2011 at 2:22 AM, Fred Drake  wrote:
> On Fri, Mar 4, 2011 at 10:59 AM,   wrote:
>> Something to consider here is how this will interact with Python files which
>> are _not_ modules.  I'm a little uneasy about having sys.modules["trial"]
>> refer to the module defined by /usr/bin/trial.
>
> I've long held the position that modules and scripts are distinct, and
> should never share a source file.  All the work that's going into
> dealing with this just reinforces my position.

While I actually have a lot of respect for that point of view (the
traps in PEP 395 can be read as a list of justifications for it!),
"python -m timeit", "python -m test", "python -m site" and assorted
other instances in the stdlib disagree with it. I don't think a purity
argument is going to fly here, because the practice of allowing
executable modules is just so damn useful for utility functionality
where a developer doesn't want to worry about global namespace
collisions on the system path . If we turned every module we have in
the stdlib with a little snippet of directly executable functionality
at the bottom into an installed script, I assume the distro packagers
would either outright ignore us or howl the place down with cries of
namespace pollution (and they'd be right to do so - the "-m" switch
*originated* in a discussion about making timeit easier to invoke on
different parallel Python installations without running into namespace
collision problems on the system path).

Besides, this particular ship really sailed way back in the early days
of Python's history when the "if __name__ == '__main__':" convention
was established to allow the same source file to behave differently
depending on how it was invoked (either as a module or as a script).
All PEP 395 is about is trying to make the way that works line up more
closely with people's intuitions.

However, as a slight tangent, note that one of the positive side
effects of the __main__.py file approach to directory and package
execution is that it *does* promote keeping the script behaviour and
the module behaviour in separate files.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Guido van Rossum]

On Fri, Mar 4, 2011 at 4:10 PM, Westley Martínez 
> All right I have to reply to all these "singular they" remarks. Just
> because the singular they has been used for a long time doesn't make it
> right. It sounds unnatural, at least to me, and I've always been taught
> to use "he or she" which I despise. So all my life I've used the generic
> "he". Anyways, I remember reading somewhere that for Python Strunk and
> White apply, and neither Strunk nor White like singular theys.

That's how I felt 20 years ago. But since then I've come to appreciate
they as a much better alternative to either "he or she" or "he". Just
get used to it.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rietveld or Review Board use?

[anatoly techtonik]

On Fri, Mar 4, 2011 at 9:53 PM, Andi Albrecht
 wrote:
> On Fri, Mar 4, 2011 at 5:52 PM, Barry Warsaw  wrote:
>> On Mar 04, 2011, at 05:19 PM, Victor Stinner wrote:
>>
>>>Le vendredi 04 mars 2011 à 10:05 -0600, s...@pobox.com a écrit :
 Is Rietveld or Review Board being used within the Python core development
 community?  I looked at the dev guide but didn't see anything obvious about
 code reviews.  I don't see how to search the Rietveld instance at
 codereview.appspot.com looking just for Python core review requests.

 My aim here is to provide some examples to a colleague at work.  I wanted 
 to
 give him some examples related to code with which I'm familiar.
>>>
>>>I used it at least twice.
>>>
>>>Issue #9425: http://codereview.appspot.com/1874048
>>>Issue #3080: http://codereview.appspot.com/3972045
>>
>> Yep, I used Rietveld for the PEP 3147/3149 patches and it was pretty nice.
>> It's not completely well integrated into our workflow, but it's cool enough
>> that I think we should promote it more.  Will that be easier once we're
>> permanently on Mercurial?
>
> FWIW there's a nice section in the contribution guidelines for the Go
> language about code reviews and how they integrate Rietveld into their
> development process: http://golang.org/doc/contribute.html#Code_review
> They're using a wrapper around the upload.py script bundled as a
> Mercurial extension.

Chromium uses tweaked upload.py script too.

> And IIRC there's already some Roundup integration done.

Yes, you should ask Martin about it. I believe he told about some
performance problems, but I don't remember if he tried to investigate
the source of the problem. Probably he doesn't have enough time.

-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

[anatoly techtonik]

On Sat, Mar 5, 2011 at 1:23 AM, Antoine Pitrou  wrote:
> On Fri, 04 Mar 2011 16:51:15 -0500
> David Malcolm  wrote:
>> On Fri, 2011-03-04 at 18:17 +0100, Georg Brandl wrote:
>> > On 04.03.2011 13:59, Victor Stinner wrote:
>> > > Hi,
>> > >
>> > > Does the bug tracker will continue to support rX links after the
>> > > migration to Mercurial?
>> >
>> > Yes.  They will link to http://hg.python.org/lookup/rX, which uses
>> > the conversion metadata to find the correct hg revision.
>>
>> Are these destinations meant to work yet?
>>
>> I just tried one of these:
>>   http://hg.python.org/lookup/r81488
>> and it's giving me an "Internal Server Error"
>
> Should be fixed now.
>
> cheers

We need some service monitor for all this stuff.
--
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Mark Hammond]

On 5/03/2011 8:21 AM, "Martin v. Löwis" wrote:
...

As for Windows support: we currently don't install a python3.exe binary,
let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
adjust the installer if the PEP asks me to. For the reasons discussed,
I'm -0 on the change (i.e. double-clicking .py will continue to launch
the most-recently installed Python, rather than the "right" one, and
setting PYTHONPATH will continue to break installations).


I agree with the -0 - I simply don't think it will, in practice, make 
anyone's life much easier.  To run python2 and python3 based scripts in 
the same environment already requires some manual work by the machine 
owner (both directories will need to be added to the path) so the 
additional burden of some other steps (eg, .bat files, doskey alaises 
etc) doesn't seem that great.  There is also a small risk of confusion - 
people may believe python.exe and python2.exe/python3.exe have different 
purposes and be confused about when to use which.


I think this discussion should be divorced from this PEP and taken up 
with the discussion about the PATH and the "last installed wins" issue 
Martin mentions - only all of them taken together will "fix" this issue 
- not that I personally consider it particularly broken - more like 
"sub-optimal" :)


Cheers,

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summer of Code: call for ideas and mentors

[Martin v. Löwis]

> I'm a little confused by the
> http://wiki.python.org/moin/SummerOfCode/2011 page though. If I'm a
> *member* of an approved project (CPython in this case), can I just add
> an entry to the table? Or do I need to do something first to be
> approved as a prospective mentor?

It's a wiki, so feel free to edit it. If it gets too unorganized, I'm
sure Arc will post more specific rules. Telling him that you are a
prospective member (with the information he asked for) can't hurt,
though.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 395: Module Aliasing

[Nick Coghlan]

On Sat, Mar 5, 2011 at 3:04 AM, Steven D'Aprano  wrote:
> I think you mean that sys.path[0] will be set to the directory path.

Indeed I did.

> Should the current working directory continue to be included in the path
> when running a sub-package module?

No, it would be similar to the current difference between "python
foo.py" and "python -m foo", with the former forcing path[0] to a
specific directory, while the latter follows the vagaries of the
current working directory.

~/devel$ cat > foo.py
import sys
print (repr(sys.path[0]))
~/devel$ python foo.py
'/home/ncoghlan/devel'
~/devel$ python -m foo
''

I'll elaborate on that point in the next update.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

[Terry Reedy]

On 3/4/2011 7:40 PM, Guido van Rossum wrote:

On Fri, Mar 4, 2011 at 4:10 PM, Westley Martínez

All right I have to reply to all these "singular they" remarks. Just
because the singular they has been used for a long time doesn't make it
right. It sounds unnatural, at least to me, and I've always been taught
to use "he or she" which I despise. So all my life I've used the generic
"he". Anyways, I remember reading somewhere that for Python Strunk and
White apply, and neither Strunk nor White like singular theys.


That's how I felt 20 years ago.


I still feel that way ...


But since then I've come to appreciate
they as a much better alternative to either "he or she" or "he". Just
get used to it.


But I discovered long ago that abstract singulars can nearly always be 
pluralized, as the statement is nearly always about people rather than 
any particular person.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com