date:20110721

I've updated PEP 397 - Python launcher for Windows based on recent 
discussions and Vinay's implementation.


http://www.python.org/dev/peps/pep-0397/ and a copy is attached for your 
convenience.


The main changes are:

* All mentions of the Python reference implementation have been removed 
now that a C implementation exists and is a more accurate implementation 
of the PEP than the Python version.


* Some implementation details have been removed and links added to the 
launcher docs.  This was done mainly so the implementation is free to 
make changes based on user feedback and still stay true to the PEP. 
Note that the launcher doc link doesn't exist right now, but should 
magically appear over the next couple of days as Vinay pushes some 
changes I just sent him.


* The recommendation to install into System32 has been changed to a 
recommendation to install directly into \Windows, as the System32 
directory is not on the default path for 32bit processes on a 64bit 
Windows.  Vinay even has a version of an MSI installer which installs 
into this directory.  The PEP also gives installers more leeway on where 
to install the launcher if this directory is not writable.


I think this PEP is getting close to being finalized - please suggest 
whatever changes you feel are necessary ASAP as soon I'll be asking for 
pronouncement.


Thanks - especially to Vinay for taking on the C implementation!

Mark
PEP: 397
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond mhamm...@skippinet.com.au
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 15-Mar-2011
Post-History: 21-July-2011, 17-May-2011, 15-Mar-2011

Abstract

This PEP describes a Python launcher for the Windows platform.  A 
Python launcher is a single executable which uses a number of 
heuristics to locate a Python executable and launch it with a
specified command line.


Rationale

Windows provides file associations so an executable can be associated
with an extension, allowing for scripts to be executed directly in some
contexts (eg., double-clicking the file in Windows Explorer.)  Until now,
a strategy of last installed Python wins has been used and while not
ideal, has generally been workable due to the conservative changes in
Python 2.x releases.  As Python 3.x scripts are often syntactically
incompatible with Python 2.x scripts, a different strategy must be used
to allow files with a '.py' extension to use a different executable based
on the Python version the script targets.  This will be done by borrowing
the existing practices of another operating system - scripts will be able
to nominate the version of Python they need by way of a shebang line, as
described below.

Unix-like operating systems (referred to simply as Unix in this
PEP) allow scripts to be executed as if they were executable images
by examining the script for a shebang line which specifies the
actual executable to be used to run the script.  This is described in
detail in the evecve(2) man page [1] and while user documentation will
be created for this feature, for the purposes of this PEP that man
page describes a valid shebang line.

Additionally, these operating systems provide symbolic-links to
Python executables in well-known directories.  For example, many
systems will have a link /usr/bin/python which references a
particular version of Python installed under the operating-system.
These symbolic links allow Python to be executed without regard for
where Python it actually installed on the machine (eg., without
requiring the path where Python is actually installed to be
referenced in the shebang line or in the PATH.)  PEP 394 'The python
command on Unix-Like Systems' [2] describes additional conventions
for more fine-grained specification of a particular Python version.

These 2 facilities combined allow for a portable and somewhat 
predictable way of both starting Python interactively and for allowing
Python scripts to execute.  This PEP describes an implementation of a 
launcher which can offer the same benefits for Python on the Windows 
platform and therefore allows the launcher to be the executable
associated with '.py' files to support multiple Python versions
concurrently.

While this PEP offers the ability to use a shebang line which should
work on both Windows and Unix, this is not the primary motivation for
this PEP - the primary motivation is to allow a specific version to be
specified without inventing new syntax or conventions to describe it.

An overview of the launcher.

This PEP outlines the general functionality and key guidelines of a
launcher for Windows.  It is accompanied by an implementation [3],
written in C, which defines the detailed implementation.  Over
time, changes to the implementation may be

Re: [Python-Dev] New tests in stable versions

2011-07-21 Thread Raymond Hettinger


On Jul 20, 2011, at 3:16 PM, Brett Cannon wrote:

 
 
 On Wed, Jul 20, 2011 at 11:48, Terry Reedy tjre...@udel.edu wrote:
 On 7/20/2011 12:25 PM, Victor Stinner wrote:
 Le 20/07/2011 17:58, Éric Araujo a écrit :
 Do we have a policy of not adding new test files to stable branches?
 New logging tests failed during some weeks. If we add new tests, we may
 also break some stable buildbots. I don't think that we need to add
 these new tests to a stable version.
 
 When bugs are fixed in stable branches, they are usually accompanied by tests 
 that fail without the bugfix. I have understood the policy to be that new 
 tests go into stable branches. Failure indicates a bug in either the 
 not-really-so-stable branch or the test. In the latter case, remove the test 
 everywhere until fixed. In the former case, either fix the bug in the stable 
 branch immediately or open an issue and attach the test code (skipping the 
 test needed stage) or just disable it and note on the issue that a fix patch 
 should re-enable. The logging tests may have been exceptional some way
 
 Right, but Eric is asking about new tests that do nothing more than improve 
 test coverage, not exercise a fix for a bug.
 
 I say don't add new tests for the sake of coverage or adding new tests to 
 stable branches. Tests for bugfixes are practically required.

I concur with Brett.   Nothing good will come from backporting tests that 
aren't aimed at a specific bugfix.


Raymond

___
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] 3.2.1 encoding surprise


On 7/20/2011 8:22 PM, Nick Coghlan wrote:

On Thu, Jul 21, 2011 at 12:52 PM, R. David Murrayrdmur...@bitdance.com  wrote:

Indeed.  If I want to run a script with a different python version
on a unix-like system, I need to know the path to said script.
We're trying to make python as easy to use on Windows as it is on Unix.
If find-script-on-path is considered a worthwhile feature, then as Mark
said it should be added to base Python (on all platforms), not special-cased
in the Windows launcher.

And given the diverse range of what Python considers to be an
executable script these days, -1000 to that particular feature. Use
`which scriptname`, that's what it's for. The lack of such
functionality in the underpowered cmd shell on Windows isn't Python's
problem to solve - ask MS for a better shell and command line
utilities (assuming Powershell doesn't already offer something
comparable to 'which').

There are reasons I only code specifically for Windows if someone pays
me to do so :P


Interesting feedback.  Well, I have a which program on my machine, but 
as a 32-bit executable, it won't find py in the 64-bit 
c:\windows\system32 directory!  Another good reason to demand pay for 
Windows programming.  There are some interesting gotchas to the way 32- 
vs 64-bit compatibility is achieved in Windows (groan).  I'll find or 
write a better one, in due time.  Meantime, the launcher testing has 
been a good learning exercise for me.


Interesting, David, that you feel it that Python usability on Windows 
should be limited to its usability on Unix, rather than to exceed it. I 
don't see that as a necessary or appropriate limit.  Windows and Unix 
are different.  Unix people are accustomed to using tools like which, 
and using command lines, and path manipulations; Windows people are 
not.  So the use of the command line is already somewhat foreign to 
them, and limiting the launcher so that they have to use other command 
line tools to get the work done, would only serve to frustrate them.  
Now the argument can possibly be made that people that want to use 
launcher from the command line would be those that are already command 
line experts might be realistic, but I will note that Perl has a -S 
option to find its script on the PATH, not that that is a sufficient 
reason to add such to Python, or even to the launcher, but just to note 
that there are at least some people besides myself that might think that 
is a friendly idea.


My goal in writing software is to make it easy to use, regardless of 
whether some other system should be the responsible party or not -- 
especially when I don't control the other system.  But then, I haven't 
found time to write a competing launcher, either, with friendlier 
features.  So, I'll just reiterate that I would find it friendly if the 
launcher searched the path to find the script, and agree that if Python 
had a feature to do so, that would also be friendly to the Windows 
platform, but less necessary on Unix where you can  `which script.py` 
(although that would still require more typing than if the path 
searching were automatic.
___
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] 3.2.1 encoding surprise


On 7/20/2011 5:34 PM, Mark Hammond wrote:

On 21/07/2011 10:13 AM, Glenn Linderman wrote:

On 7/20/2011 2:43 PM, Glenn Linderman wrote:
It's not py's job to walk the path: the shell does that when you 
just type
foo. It locates foo.py, and then invokes py because of file 
association - py
then checks the file for a shebang to decide which Python to 
dispatch it to.


Certainly when the launcher is invoked via an association, this would
be the case.  However, when the launcher is invoked via the command
line, then the unqualified name is passed through.  To be useful from
the command line, the launcher should walk the PATH to find the .py 
file.


The Windows SearchPath API
http://msdn.microsoft.com/en-us/library/aa365527%28v=VS.85%29.aspx
makes it a pretty easy job to walk the PATH.  Would even allow low cost
additional feature of searching for both   foo and foo.py  at the 
same time.


But that would also require us to parse the command-line, understand 
which options require 2 args and which just require 1 (making it 
fragile in the face of later versions introducing new options), then 
re-stitching a modified command-line back together for the child 
process.  IMO that is all out of scope.


Yes it would be more work.



Are you maybe forgetting about the PATHEXT functionality?  If you 
include .py in your PATHEXT and file associations are set so .py files 
are handled by the launcher, you should be able to directly execute 
just 'foo' and have the command processor search the PATH for a foo.py 
and invoke it via the launcher.


Not at all.  I was just testing the use of the launcher from the command 
line, and seeing the cumbersomeness of using it as a prefix to a command 
that would work on its own, but fails when launched by the launcher from 
the command line.  And the SearchPath API has a limited form of PATHEXT 
support built in, which is what I was trying to point out above.  Yes, 
the use of the launcher via file associations can be friendly because it 
leverages Windows features, but its use from the command line presently 
seems rather unfriendly, because it leverages Windows misfeatures.



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] New update to PEP397 - Python launcher for Windows


On 7/20/2011 11:35 PM, Mark Hammond wrote:

 * If the command starts with the definition of a customized command
   followed by a space character, the customized command will be used.
   See below for a description of customized commands.



 Then a shebang line of '#! vpython' in a script named 'doit.py' will
 result in the launcher using the command-line 'c:\bin\vpython.exe -foo
 doit.py'


Shouldn't the second paragraph include a space before the 2nd ' ?  In 
other words, the command as quoted does not show a customized command 
followed by a space character as the definition requires.  I don't know 
why the space character is required, or maybe white space was meant, 
so that the line terminating newline character qualifies also to delimit 
the customized command?


___
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] 3.2.1 encoding surprise

On Thu, Jul 21, 2011 at 6:06 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 Interesting, David, that you feel it that Python usability on Windows should
 be limited to its usability on Unix, rather than to exceed it. I don't see
 that as a necessary or appropriate limit.  Windows and Unix are different.
 Unix people are accustomed to using tools like which, and using command
 lines, and path manipulations; Windows people are not.  So the use of the
 command line is already somewhat foreign to them, and limiting the launcher
 so that they have to use other command line tools to get the work done,
 would only serve to frustrate them.  Now the argument can possibly be made
 that people that want to use launcher from the command line would be those
 that are already command line experts might be realistic, but I will note
 that Perl has a -S option to find its script on the PATH, not that that is a
 sufficient reason to add such to Python, or even to the launcher, but just
 to note that there are at least some people besides myself that might think
 that is a friendly idea.

If a PEP is put forward proposing such a feature, with a reference
implementation that supports at least Windows, *nix and OS X and works
for at least the 4 script types understood by the CPython executable
without a command line option (source and bytecode files along with
directories and zipfiles providing top level __main__ modules), then
I'd be prepared to moderate my response all the way to a +0 (reserving
the extreme negative reaction for proposals that are either platform
specific or only handle some script types).

I believe that is significantly easier said than done, 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] New update to PEP397 - Python launcher for Windows


On 21/07/2011 6:32 PM, Glenn Linderman wrote:

On 7/20/2011 11:35 PM, Mark Hammond wrote:

 * If the command starts with the definition of a customized command
   followed by a space character, the customized command will be used.
   See below for a description of customized commands.



 Then a shebang line of '#! vpython' in a script named 'doit.py' will
 result in the launcher using the command-line 'c:\bin\vpython.exe -foo
 doit.py'


Shouldn't the second paragraph include a space before the 2nd ' ?  In
other words, the command as quoted does not show a customized command
followed by a space character as the definition requires.  I don't know
why the space character is required, or maybe white space was meant,
so that the line terminating newline character qualifies also to delimit
the customized command?


Yes, thanks for pointing that out - I've pushed a new version of the PEP 
with that paragraph reading as:



If the command starts with the definition of a customized command 
followed by a whitespace character (including a newline), the customized 
command will be used.  See below for a description of customized commands.




Thanks,

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/skippy.hammond%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] New tests in stable versions

2011-07-21 Thread Victor Stinner


On 21/07/2011 00:07, Vinay Sajip wrote:

Victor Stinnervictor.stinnerat  haypocalc.com  writes:


New logging tests failed during some weeks. If we add new tests, we may
also break some stable buildbots. I don't think that we need to add
these new tests to a stable version.

Just for my information, which logging test failures are you referring to?
Sorry, I don't remember the details, I just remember that some new tests 
added to test_logging were failing during some days/weeks.


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] 3.2.1 encoding surprise

2011-07-21 Thread R. David Murray

On Thu, 21 Jul 2011 01:06:57 -0700, Glenn Linderman v+pyt...@g.nevcal.com 
wrote:
 Interesting, David, that you feel it that Python usability on Windows 
 should be limited to its usability on Unix, rather than to exceed it. I 
 don't see that as a necessary or appropriate limit.  Windows and Unix 

That wasn't how I intended my comment.  My point was that the goal of
the *PEP* is to make it as usable (and actually just in the specific
case of #! lines), and that if the additional feature is desirable
why not make it available on all platforms?  I can see how you read what
you did in what I wrote, though.

--
R. David Murray   http://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] New update to PEP397 - Python launcher for Windows

2011-07-21 Thread anatoly techtonik

If you're going to include this into standard Python distribution, it
needs more attention from _users_. As a user, I can not find any
references to any user stories in this PEP article. Abstract chapter
is totally useless

This PEP (named 'Python launcher for Windows') describes a Python
launcher for the Windows platform. - it is a waste of time to read
such stuff.

A Python launcher is a single executable which uses a number of
heuristics to locate a Python executable and launch it with a
specified command line. - this doesn't answer main questions - Why
Launcher is needed, i.e. is there a problem? Can it be solved? How
this PEP helps to solve the problem?


I see that this launcher is an .msi file. Shouldn't it be portable and
don't require administrative privileges? How about KISS?
--
anatoly t.



On Thu, Jul 21, 2011 at 9:35 AM, Mark Hammond skippy.hamm...@gmail.com wrote:
 I've updated PEP 397 - Python launcher for Windows based on recent
 discussions and Vinay's implementation.

 http://www.python.org/dev/peps/pep-0397/ and a copy is attached for your
 convenience.

 The main changes are:

 * All mentions of the Python reference implementation have been removed now
 that a C implementation exists and is a more accurate implementation of the
 PEP than the Python version.

 * Some implementation details have been removed and links added to the
 launcher docs.  This was done mainly so the implementation is free to make
 changes based on user feedback and still stay true to the PEP. Note that the
 launcher doc link doesn't exist right now, but should magically appear over
 the next couple of days as Vinay pushes some changes I just sent him.

 * The recommendation to install into System32 has been changed to a
 recommendation to install directly into \Windows, as the System32 directory
 is not on the default path for 32bit processes on a 64bit Windows.  Vinay
 even has a version of an MSI installer which installs into this directory.
  The PEP also gives installers more leeway on where to install the launcher
 if this directory is not writable.

 I think this PEP is getting close to being finalized - please suggest
 whatever changes you feel are necessary ASAP as soon I'll be asking for
 pronouncement.

 Thanks - especially to Vinay for taking on the C implementation!

 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/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] New update to PEP397 - Python launcher for Windows

2011-07-21 Thread Brian Curtin

On Jul 21, 2011 7:15 AM, anatoly techtonik techto...@gmail.com wrote:

 If you're going to include this into standard Python distribution, it
 needs more attention from _users_. As a user, I can not find any
 references to any user stories in this PEP article. Abstract chapter
 is totally useless

 This PEP (named 'Python launcher for Windows') describes a Python
 launcher for the Windows platform. - it is a waste of time to read
 such stuff.

 A Python launcher is a single executable which uses a number of
 heuristics to locate a Python executable and launch it with a
 specified command line. - this doesn't answer main questions - Why
 Launcher is needed, i.e. is there a problem? Can it be solved? How
 this PEP helps to solve the problem?


 I see that this launcher is an .msi file. Shouldn't it be portable and
 don't require administrative privileges? How about KISS?

No. As stated in the title, this is for Windows. It also installs to system
directories which is likely the need for admin access.
___
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] New update to PEP397 - Python launcher for Windows


On 21/07/2011 10:13 PM, anatoly techtonik wrote:

If you're going to include this into standard Python distribution, it
needs more attention from _users_. As a user, I can not find any
references to any user stories in this PEP article. Abstract chapter
is totally useless


Could you please be a little more constructive and offer concrete 
improvements?


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] Draft PEP: Simplified Package Layout and Partitioning

2011-07-21 Thread P.J. Eby


At 11:52 AM 7/21/2011 +1000, Nick Coghlan wrote:

Trying to change how packages are identified at the Python level makes
PEP 382 sound positively appealing. __path__ needs to stay :)


In which case, it should be a list, not a sentinel.  ;-)



Even better would be for these (and sys.path) to be list subclasses
that did the right thing under the hood as Glenn suggested. Code that
*replaces* rather than modifies these attributes would still
potentially break virtual packages, but code that modifies them in
place would do the right thing automatically. (Note that all code that
manipulates sys.path and __path__ attributes requires explicit calls
to correctly support current namespace package mechanisms, so this
would actually be an improvement on the status quo rather than making
anything worse).


I think the simplest thing, if we're keeping __path__ (and on 
reflection, I think we should), would be to simply call 
extend_virtual_paths() automatically on new path entries found in 
sys.path when an import is performed, relative to the previous value 
of sys.path.


That is, we save an old copy of sys.path somewhere, and whenever 
__import__() is called (well, once it gets past checking if the 
target is already in sys.modules, anyway), it checks the current 
sys.path against it, and calls extend_virtual_paths() on any sys.path 
entries that weren't in the old sys.path.


This is not the most efficient thing in the world, as it will cause a 
bunch of stat calls to happen against the new directories, in the 
middle of a possibly-entirely-unrelated import operation, but it 
would certainly address the issue in the Simplest Way That Could Possibly Work.


A stricter (safer) version of the same thing would be one where we 
only update __path__ values that are unchanged since we created them, 
and rather than only appending new entries, we replace the __path__ 
with a newly-computed one.


This version is safer because it avoids corner cases like I imported 
foo.bar while foo.baz 1.1 was on my path, then I prepended a 
directory to sys.path that has foo.baz 1.2, but I still get foo.baz 
1.1 when I import.  But it loses in cases where people do direct 
__path__ manipulation.


On the other hand, it's a lot easier to say you break it, you bought 
it where __path__ manipulation is concerned, so I'm actually pretty 
inclined towards using the strict version.


Hey...  here's a crazy idea.  Suppose that a virtual package __path__ 
is a *tuple* instead of a list?  Now, in order to change it, you 
*have* to replace it.  And we can cache the tuple we initially set it 
to in sys.virtual_package_paths, so we can do an 'is' check before 
replacing it.


Voila: __path__ still exists and is still a sequence for a virtual 
path, but you have to explicitly replace it if you want to do 
anything funky -- at which point you're responsible for maintaining it.


I'm tempted to say, well, why not use a list-subclass proxy, then?, 
but that means more work for no real difference.  I just went through 
dozens of examples of __path__ usage (found via Google), and I found 
exactly two examples of code that modifies a __path__ that is not:


1. In the __init__.py whose __path__ it is (i.e., code that'll still 
have a list), or
2. Modifying the __path__ of an explicitly-named self-contained 
package that's part of the same distribution.


The two examples are from Twisted, and Google AppEngine.  In the 
Twisted case, it's some sort of namespace package-like plugin 
chicanery, and in the AppEngine case, well, I'm not sure what the 
heck it's doing, but it seems to be making sure that you can still 
import stuff that has the same name as stdlib stuff, or something.


The Twisted case (and an apparent copy of the same code in a project 
called flumotion) uses ihooks, though, so I'm not sure it'll even 
get executed for virtual packages.  The Google case loops over 
everything in sys.modules, in a function by the name of 
appengine.dist.fix_paths()...  but I wasn't able to find out who 
calls this function, when and why.


So, pretty much, except for these bits of nosy code, the vast 
majority of code out there seems to only mess with its own 
self-contained paths, making the use of tuples seem like a pretty safe choice.


(Oh, and all the code I found that reads paths without modifying them 
only use tuple-safe operations.)


So, if we implement automatic __path__ updates for virtual packages, 
I'm currently leaning towards the strict approach using tuples, but 
could possibly be persuaded towards read-only list-proxies instead.


Side note: it looks like a *lot* of code out there abuses __path__[0] 
to find data files, so I probably need to add a note to the PEP about 
not doing that when you convert a self-contained package to a virtual 
one.  Of course, I suppose using a sentinel could address *that* 
problem, or an iteration-only proxy.


The main concern here is that using __path__[0] will *seem* to work 
when you first use it with a

Re: [Python-Dev] 3.2.1 encoding surprise

2011-07-21 Thread Paul Moore

On 21 July 2011 09:13, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 Certainly when the launcher is invoked via an association, this would
 be the case.  However, when the launcher is invoked via the command
 line, then the unqualified name is passed through.  To be useful from
 the command line, the launcher should walk the PATH to find the .py file.

It's equally as arguable (and would match my expectations much more
closely) that py a_file.py should do whatever python a_file.py
would do. So path search in that context would only be reasonable if
it were a Python feature rather than a feature of the launcher.

This is what the launcher currently does (so I guess it's not
surprising that I'm happy with the current behaviour).

I can see the benefits of path search, but I'd want it to be a Python
feature (and hence inherited for free by the launcher) and not a
launcher-only one.

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

Re: [Python-Dev] 3.2.1 encoding surprise

2011-07-21 Thread Michael Foord


On 21/07/2011 15:43, Paul Moore wrote:

On 21 July 2011 09:13, Glenn Lindermanv+pyt...@g.nevcal.com  wrote:

Certainly when the launcher is invoked via an association, this would
be the case.  However, when the launcher is invoked via the command
line, then the unqualified name is passed through.  To be useful from
the command line, the launcher should walk the PATH to find the .py file.

It's equally as arguable (and would match my expectations much more
closely) that py a_file.py should do whatever python a_file.py
would do. So path search in that context would only be reasonable if
it were a Python feature rather than a feature of the launcher.

This is what the launcher currently does (so I guess it's not
surprising that I'm happy with the current behaviour).

I can see the benefits of path search, but I'd want it to be a Python
feature (and hence inherited for free by the launcher) and not a
launcher-only one.


What he said ^^. (+1)

py launcher and python binaries behaving differently in this regard 
would be a recipe for confusion and hard to debug problems.


Michael



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/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] Issue10271 - warnings.showwarning should allow any callable object - request commiter

2011-07-21 Thread Brett Cannon

On Wed, Jul 20, 2011 at 23:05, lekmalek lekma...@gmail.com wrote:

 On Sun, 17 Jul 2011 19:19:59 -0700
 Brett Cannon br...@python.org wrote:

  Just so people know, I went ahead and fixed this for 3.3 (but not for
  3.2 since it changes the API in a subtle way).
 Yeah, but that shouldn't break anything.


It won't break any _existing_ code, but it could cause compatibility for
_future_ code. Imagine I wrote some code for 3.2.2 where this change was
backported and worked *only* with this fix. That would mean my code would
fail in any Python 3.2.1 or older interpreter. That's simply not acceptable
as that means that code would be magically busted for some versions of
Python 3.2 but not all of them.



 Anyway, thanks a lot for your help, I'm happy it's in 3.3.


I'm just sorry it took so long to resolve. Life has been crazy for me in
2011.

-Brett



 lekma

 
  On Sat, Jul 16, 2011 at 01:33, lekmalek lekma...@gmail.com wrote:
 
   Hello all,
  
   Can any of you core devs have a look at
   http://bugs.python.org/issue10271. It seems Brett is really busy
   right now and this uncontroversial (AFAICT) one liner only needs
   someone to review it and commit it. The pb is, it's holding me back
   a little bit, and I really would like to have it in the next 3.2
   release if possible.
  
   Thanks for your help,
  
   lekma
   ___
   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/brett%40python.org
  

 ___
 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/brett%40python.org

___
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] Issue10271 - warnings.showwarning should allow any callable object - request commiter

2011-07-21 Thread Terry Reedy


On 7/21/2011 2:15 PM, Brett Cannon wrote:



It won't break any _existing_ code, but it could cause compatibility for
_future_ code. Imagine I wrote some code for 3.2.2 where this change was
backported and worked *only* with this fix. That would mean my code
would fail in any Python 3.2.1 or older interpreter. That's simply not
acceptable as that means that code would be magically busted for some
versions of Python 3.2 but not all of them.


In other words, Python 3.2 is a fixed language, cpython3.2.z's are 
intended to be increasingly better implementations of that language, 
although regressions can and do happen (as with issue 12540).


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

Re: [Python-Dev] New tests in stable versions

2011-07-21 Thread Terry Reedy


On 7/21/2011 2:58 AM, Raymond Hettinger wrote:


I concur with Brett. Nothing good will come from backporting tests that
aren't aimed at a specific bugfix.


They could catch reversions that otherwise would not be caught. This 
would mainly apply to 2.7. It would not be an issue for 3.2 if all fixes 
are forward ported to 3.3 and tested there (before pushing) where there 
are tests not in 3.2. If people fix in 3.2, test, commit, and push, and 
just assume OK in 3.3, the new test will not do any good until someone 
else runs them with the fix.


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

Re: [Python-Dev] Python launcher command line usage (Was: 3.2.1 encoding surprise)

2011-07-21 Thread Terry Reedy


On 7/20/2011 7:55 PM, Mark Hammond wrote:

On 21/07/2011 4:38 AM, Terry Reedy wrote:


Many installers first make an organization directory and then an app
directory within that. This annoys me sometimes when they only have one
app to ever install, but is useful when there might really be multiple
directories, as in our case. (Ditto for start menu entries.) This is
what python should have done a decade ago.



I disagree. If we followed that advice we would also be in \Program
Files.


That is not what I suggested. I said let the use pick.


I have no problem with multiple Python versions installed
directly off the root, especially given most users probably have a very
small number of such installations. I think Python being a developer
tool rather than a user app is a reasonable justification for that (and
the justification used when the existing scheme was decided)


I put the multiple installations and several other directories into 
/programs. On my next machine, on order, I will use /devel.



  The two proposals

overlap but are not mutually exclusive. For future pythons, 'python33'
is easier to remember and type than 'py -v 3.3' or whatever the proposed
encantation is.


'py -3.3' - less chars to type than 'python33' and with no need to have
every Python directory on your PATH.


My proposal, as I clearly said, was for EXACTLY ONE directory to be 
added to PATH. In spite of Microsoft making is damned difficult for 
users to edit PATH, (and deleted programs not deleting their entries) I 
added 'C:/programs;'. I copied python32/python as py32 and 
python27/python as py27. Those are even fewer characters to type (4 
versus 7). Now I can click a 'Command Prompt' icon and enter 'py32 -m 
test.regrtest' and it works without cd-ing to /programs/python32. Of 
course, I will have to re-copy with every install, which is why I would 
like something like this as part of installs.




IMO it is also simple enough that
people will remember it fairly easily.


py32 is even easier to remember.


Also, the launcher supports the ability to select either the 32 or 64bit
implementation - so maybe 'python33.exe' isn't really good enough and
should reflect the bittedness?


Like py32-6? If I install both Pythons on my new 64 bit machine, I will 
think about it, though I have no need for both now.



A python directory also gives a sensible (though optional) place to put
other interpreters and even python-based apps. The launcher does not.


What other interpreters? IMO it doesn't make sense to have IronPython,
jython etc be installed there. Ditto for apps - especially given most
apps tend to be tied to a subset of all possible Python versions.


If I install pypy, /programs is exactly where I would put it until I 
somehow discovered that to be a problem. Its startup could be copied as 
pp26 or something.



My idea may be not so good for general use, even though is now solves my 
problems, but please criticize what I said, allowing for obvious 
modifications like py32 instead of python32, and not a strawman that is 
wildly different.


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

Re: [Python-Dev] 3.2.1 encoding surprise


On 7/21/2011 8:20 AM, Michael Foord wrote:

On 21/07/2011 15:43, Paul Moore wrote:

On 21 July 2011 09:13, Glenn Lindermanv+pyt...@g.nevcal.com  wrote:

Certainly when the launcher is invoked via an association, this would
be the case.  However, when the launcher is invoked via the command
line, then the unqualified name is passed through.  To be useful from
the command line, the launcher should walk the PATH to find the .py 
file.

It's equally as arguable (and would match my expectations much more
closely) that py a_file.py should do whatever python a_file.py
would do. So path search in that context would only be reasonable if
it were a Python feature rather than a feature of the launcher.

This is what the launcher currently does (so I guess it's not
surprising that I'm happy with the current behaviour).

I can see the benefits of path search, but I'd want it to be a Python
feature (and hence inherited for free by the launcher) and not a
launcher-only one.


What he said ^^. (+1)

py launcher and python binaries behaving differently in this regard 
would be a recipe for confusion and hard to debug problems. 


I see the point.  Although the incremental benefit is higher to Windows 
users, and although we are creating a Windows-only piece of code that 
could be the vehicle for adding the functionality, it would be 
beneficial for all platforms, and a common implementation would serve 
that need better.
___
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] Draft PEP: Simplified Package Layout and Partitioning

2011-07-21 Thread P.J. Eby


At 12:59 PM 7/21/2011 -0700, Reliable Domains wrote:
I assume that the implicit extend_virtual_paths() would be smart 
enough to only do real work if there are virtual packages to do it 
in, so much of the performance costs (bunch of stats) are bounded by 
the existence of and number of virtual packages that have actually 
been imported, correct?


Yes - this is true even for an explicit call.  It only does this for 
imported virtual packages, and child virtual packages are only 
checked for if the parent package exists.  So, in the case of a 
directory being added that has no parent packages, then the cost in 
stats is equal to the number of top-level, *imported* virtual packages.


The __path__ wrapper scheme can do this even better, and defer doing 
any of the stat calls until/unless another import occurs for one of 
those packages.  So if you munge sys.path and then don't import 
anything from a virtual package, no extra stat calls would happen at all.


___
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] New tests in stable versions

On Fri, Jul 22, 2011 at 5:20 AM, Terry Reedy tjre...@udel.edu wrote:
 On 7/21/2011 2:58 AM, Raymond Hettinger wrote:

 I concur with Brett. Nothing good will come from backporting tests that
 aren't aimed at a specific bugfix.

 They could catch reversions that otherwise would not be caught. This would
 mainly apply to 2.7. It would not be an issue for 3.2 if all fixes are
 forward ported to 3.3 and tested there (before pushing) where there are
 tests not in 3.2. If people fix in 3.2, test, commit, and push, and just
 assume OK in 3.3, the new test will not do any good until someone else runs
 them with the fix.

None of that contradicts what Raymond and Brett said. Backporting test
improvements that aren't targeting specific known bugs does not make
efficient use of limited development resources. Forward porting of any
changes made to maintenance branches (or explicitly blocking same as
being irrelevant), OTOH, is mandatory.

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] 3.2.1 encoding surprise

On Fri, Jul 22, 2011 at 6:05 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 On 7/21/2011 8:20 AM, Michael Foord wrote:
 py launcher and python binaries behaving differently in this regard would be
 a recipe for confusion and hard to debug problems.

 I see the point.  Although the incremental benefit is higher to Windows
 users, and although we are creating a Windows-only piece of code that could
 be the vehicle for adding the functionality, it would be beneficial for all
 platforms, and a common implementation would serve that need better.

Well that, and the desire to have the Windows launcher *just* find an
interpreter to run, so that py -3.2 args and c:\python32\python
args handle the arguments the same way.

While further discussion of the PATH walking concept should be done in
a new thread on python-ideas, I'll note that I'm no longer actively
opposed to the idea. However, I still think it needs its own PEP to
work out the details (and whether or not it happens at all).

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] Draft PEP: Simplified Package Layout and Partitioning

On Thu, Jul 21, 2011 at 11:20 PM, P.J. Eby p...@telecommunity.com wrote:
 This seems to lean in favor of making a simple reiterable wrapper type for
 the __path__, that only allows you to take the length and iterate over it.
  With an appropriate design, it could actually update itself automatically,
 given a subname and a parent __path__/sys.path.  That is, it could keep a
 tuple copy of the last-seen parent path, and before iteration, compare
 tuple(self.parent_path) to self.last_seen_path.  If they're different, it
 rebuilds the value to be iterated over.

 Voila: transparent updating of all virtual __path__ values from sys.path
 changes (or modifications to self-contained __path__ parents, btw), and
 trying to change it (or read an item from it positionally) will not create
 any silent failures.

 Alright...  *if* we support automatic updates to virtual __paths__, this is
 probably how we should do it.  (It will require, though, that
 imp.find_module be changed to use a different iteration method than
 PyList_GetItem, as it's quite possible a virtual __path__ will get passed
 into it.)

A no-indexing tuple wrapper for virtual package __path__ values that
automatically updates itself in response to parent path modifications
sounds good to me (errors shall not pass silently, etc). This also
allows virtual packages to be indicated clearly just through the type
of their __path__ attribute rather than having to look them up in the
import state.

I still like the idea of keeping sys.virtual_packages as a dict
mapping to the path values, though - it makes it easier to debug
erroneous __path__ replacement in virtual packages by checking
pkg.__path__ is sys.virtual_package_paths[pkg.__name__]

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] devguide: Add a communications section to the devguide FAQ (closes #11690)

2011-07-21 Thread Raymond Hettinger

Please don't add the IRC link to the devguide.

Based on conversations with Guido, he is against it being part of the core 
development process.


Raymond



On Jul 21, 2011, at 4:08 AM, Nick Coghlan wrote:

 On Thu, Jul 21, 2011 at 7:16 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
 
 FWIW you can make #python a link using either irc://chat.freenode.net/python
 (this will open the default IRC app, and I think Firefox even ask if you
 want to use a webchat) or http://webchat.freenode.net/?channels=python (for
 the freenode webchat).  If you are going to do it, it might be worth
 mentioning that the channel requires registration.
 
 I agree with Victor that the network (Freenode or irc.freenode.net) should
 be specified.
 Also the #python-dev channel should be mentioned (it doesn't require
 registration, so links are fine here).
 
 If someone more knowledgeable on IRC matters than me could either
 commit a fix directly to the devguide repo or else put a patch on the
 tracker, that would be great.
 
 Cheers,
 Nick.
 
 -- 
 Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
 ___
 Python-checkins mailing list
 python-check...@python.org
 http://mail.python.org/mailman/listinfo/python-checkins

___
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] devguide: Add a communications section to the devguide FAQ (closes #11690)

On Thu, 21 Jul 2011 15:37:01 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
 Please don't add the IRC link to the devguide.
 
 Based on conversations with Guido, he is against it being part of the core
 development process.

IRC is very much outside of the core development process, but it's
still a reasonable place to ask help in.

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] ctypes: Configurable bitfield allocation strategy

2011-07-21 Thread Vlad Riscutia

Anyone care to take a look at this?

Thank you,
Vlad

On Mon, Jul 11, 2011 at 8:59 AM, Vlad Riscutia riscutiav...@gmail.comwrote:

 Actually I already attached patch implementing everything to the issue (not
 too much time spent :)). I'm hoping someone can review.

 Thank you,
 Vlad


 On Mon, Jul 11, 2011 at 12:47 AM, Martin v. Löwis mar...@v.loewis.dewrote:

 Am 25.06.2011 18:33, schrieb Vlad Riscutia:
  I would like to hear some opinions on this.

 Sounds fine to me in principle. Warnings can be added to the
 documentation at any time; please submit a patch to the tracker.
 As for the API change - make sure you post your proposed API
 to the list before spending time to implement it.

 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] 3.2.1 encoding surprise


On 7/20/2011 5:11 PM, Mark Hammond wrote:
It may be that your copy of the launcher is a little old - some 
changes were pushed just yesterday (but I'm not sure if Vinay made a 
new installer yet).  It has slightly better debug output (although 
generally not what you are asking for yet) and better 
cross-bittedness support. 


Installed new version:

msiexec /i launchwin.amd64.msi ALLUSERS=1

Expected behaviors of registry changes occurred.  Still launches python 
2, though, whereas c:\windows\py.ini contains:


[defaults]
python=3

[commands]
/usr/bin/perl=C:\perl\bin\perl.exe


Here is the debug output.  Seems like it isn't recognizing the python=3, 
even the new version.


d:\path\to\dataset PYLAUNCH_DEBUG=1
set PYLAUNCH_DEBUG=1

d:\path\to\datafoo.py --pyver --clean
foo.py --pyver --clean
launcher build: 64bit
launcher executable: Console
File 'C:\Users\Glenn\AppData\Roaming\py.ini' non-existent
Using global configuration file 'C:\Windows\py.ini'
maybe_handle_shebang: read 256 bytes
maybe_handle_shebang: BOM not found, using UTF-8
locating Pythons in 32bit registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: C:\Python26\python.exe is a 32bit executable
locate_pythons_for_key: C:\Python26\PCBuild\python.exe: The system 
cannot find the path specified.
locate_pythons_for_key: C:\Python26\PCBuild\amd64\python.exe: The system 
cannot find the path specified.

locate_pythons_for_key: C:\Python31\python.exe is a 32bit executable
locate_pythons_for_key: C:\Python31\PCBuild\python.exe: The system 
cannot find the path specified.
locate_pythons_for_key: C:\Python31\PCBuild\amd64\python.exe: The system 
cannot find the path specified.

locating Pythons in native registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: C:\Python32\python.exe is a 64bit executable
locate_pythons_for_key: C:\Python32\PCBuild\python.exe: The system 
cannot find the path specified.
locate_pythons_for_key: C:\Python32\PCBuild\amd64\python.exe: The system 
cannot find the path specified.

found no configured value for 'python'
search for default Python found version 2.6 at 'C:\Python26\python.exe'
run_child: about to run 'C:\Python26\python.exe D:\my\py\foo.py  
--pyver --clean'

  File D:\my\py\foo.py, line 469
SyntaxError: Non-ASCII character '\xc3' in file D:\my\py\foo.py on line 
470, but no encoding declared; see 
http://www.python.org/peps/pep-0263.html for details

child process exit code: 1

d:\path\to\data

So, looking at the code, get_configured_value produces that message, but 
there are 3 places to look for python.  Setting the environment 
variable makes it work.  Eliminating the environment variable, I then 
copied c:\Windows\py.ini to c:\users\glenn\appdata\roaming\py.ini.  That 
worked.  So I guess the syntax of my py.ini file is correct.  But 
apparently it isn't properly using c:\windows\py.ini !!  Yet curiously, 
it reports the correct name for the global configuration file.


Aha!

Bad logic is get_configured_value!  get_configured_value only looks in 
the global configuration file if there is a local configuration file 
that doesn't have the setting.  It should look in the global 
configuration file if there is no local configuration file _OR_ the is a 
local configuration file without the setting.


I'll await a new launcher.


___
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] New update to PEP397 - Python launcher for Windows


On 7/20/2011 11:35 PM, Mark Hammond wrote:

Customized Commands:

 The launcher will support the ability to define Customized Commands in a
 Windows .ini file (ie, a file which can be parsed by the Windows function
 GetPrivateProfileString).  A section called '[commands]' can be created
 with key names defining the virtual command and the value specifying the
 actual command-line to be used for this virtual command.

 For example, if an INI file has the contents:

 [commands]
 vpython=c:\bin\vpython.exe -foo

 Then a shebang line of '#! vpython' in a script named 'doit.py' will
 result in the launcher using the command-line 'c:\bin\vpython.exe -foo
 doit.py'


I experimented, and empirically determined, that a customized command 
can be of the form


[commands]
/usr/bin/perl=C:\perl\bin\perl.exe

and that this works to launch Unix perl scripts on Windows 
(successfully, if the perl script is actually portable).


This does not contradict the above description, but may be surprising to 
some.  I think it is a good thing.


Of course, the extra handling of versions, and locating of corresponding 
installed versions of things applies only to Python, but some may find 
uses for launching non-Python programs.  This also would work for python 
programs using non-CPython implementations that may not set the registry 
in the same way.  However, because virtual commands take precedence over 
Customized Commands, there is no way to override even a specific virtual 
command to point at a Python other than a CPython.  (perhaps some 
serious registry hacking could make a non-CPython masquerade in the 
registry as a version of CPython.)
___
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] New update to PEP397 - Python launcher for Windows


On 7/20/2011 11:35 PM, Mark Hammond wrote:

Virtual commands in shebang lines:

 Virtual Commands are shebang lines which start with strings which would
 be expected to work on Unix platforms - examples include
 '/usr/bin/python', '/usr/bin/env python' and 'python'.  Optionally, the
 virtual command may be suffixed with a version qualifier (see below),
 such as '/usr/bin/python2' or '/usr/bin/python3.2'.  The command executed
 is based on the rules described in Python Version Qualifiers below.


I note in passing that '/usr/bin/env python' is hard-coded in the 
launcher, which conforms to the above documentation.  But there is no 
hard requirement in Unix, if I correctly understand it, that 
'/usr/bin/env' be separated from 'python' (or whatever) by exactly one 
space.  While I doubt it is frequently used with other than a single 
space, I think it would be legal to have 2 or 3 or 10 spaces, and maybe 
even tabs or a mixture, and it would work on Unix... but not in the 
launcher.


It would somewhat complicate the launcher code to have an additional 
case to check for /usr/bin/env, skip following white space, and then 
compare to python, but it would be more robust.


If it is thought that hard-coding a single space covers most of the 
uses, it should at least be emphasized in the documentation that only 
commands of than nature containing a single space will work with the 
launcher.


___
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] Draft PEP: Simplified Package Layout and Partitioning

On Tue, 19 Jul 2011 23:58:55 -0400
P.J. Eby p...@telecommunity.com wrote:
 
 Anyway, to make a long story short, we came up with an alternative 
 implementation plan that actually solves some other problems besides 
 the one that PEP 382 sets out to solve, and whose implementation a 
 bit is easier to explain.  (In fact, for users coming from various 
 other languages, it hardly needs any explanation at all.)

I have a question.

If I have (on sys.path) a module x.py containing, say:

y = 5

and (also on sys.path), a directory x containing a y.py module.

What is from x import y supposed to do?

(currently, it would bind y to its value in x.py)

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] New tests in stable versions

2011-07-21 Thread Éric Araujo

Le 21/07/2011 01:54, Nick Coghlan a écrit :
 [...]
 So slightly more relaxed than Brett's view:
 - definitely apply bug fixes and their tests to affected maintenance branches
 - *optionally* apply coverage enhancements to maintenance branches,
 but don't feel obliged to do so
 
 I see it as a productivity trade-off - time spent improving coverage
 on multiple branches is time not spent on other things. [...]

Thanks all!  Nick’s viewpoint and other people’s more-or-less according
replies are clear and make sense.

Cheers
___
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] Indentation in reStructuredText documents

2011-07-21 Thread Éric Araujo

Le 21/07/2011 03:31, Ben Finney a écrit :
 Éric Araujo mer...@netwok.org writes:
 FYI, reST uses three-space indents, not four (so that blocks align
 nicely under the leading two dots + one space), so I think the change
 was intentional.
 
 No, reST doesn't specify any particular level of indentation.

My phrasing was a shortcut for “the reST files in our documentation”, as
was made clear by followups.

Regards
___
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] Draft PEP: Simplified Package Layout and Partitioning

On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou solip...@pitrou.net wrote:
 On Tue, 19 Jul 2011 23:58:55 -0400
 P.J. Eby p...@telecommunity.com wrote:

 Anyway, to make a long story short, we came up with an alternative
 implementation plan that actually solves some other problems besides
 the one that PEP 382 sets out to solve, and whose implementation a
 bit is easier to explain.  (In fact, for users coming from various
 other languages, it hardly needs any explanation at all.)

 I have a question.

 If I have (on sys.path) a module x.py containing, say:

    y = 5

 and (also on sys.path), a directory x containing a y.py module.

 What is from x import y supposed to do?

 (currently, it would bind y to its value in x.py)

It would behave the same as it does today: the imported value of 'y' would be 5.

Virtual packages only kick in if an import would otherwise fail.

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] Draft PEP: Simplified Package Layout and Partitioning

Le vendredi 22 juillet 2011 à 09:53 +1000, Nick Coghlan a écrit :
 On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou solip...@pitrou.net wrote:
  On Tue, 19 Jul 2011 23:58:55 -0400
  P.J. Eby p...@telecommunity.com wrote:
 
  Anyway, to make a long story short, we came up with an alternative
  implementation plan that actually solves some other problems besides
  the one that PEP 382 sets out to solve, and whose implementation a
  bit is easier to explain.  (In fact, for users coming from various
  other languages, it hardly needs any explanation at all.)
 
  I have a question.
 
  If I have (on sys.path) a module x.py containing, say:
 
 y = 5
 
  and (also on sys.path), a directory x containing a y.py module.
 
  What is from x import y supposed to do?
 
  (currently, it would bind y to its value in x.py)
 
 It would behave the same as it does today: the imported value of 'y' would be 
 5.
 
 Virtual packages only kick in if an import would otherwise fail.

Wouldn't it produce confusing situations like the above example?

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] Draft PEP: Simplified Package Layout and Partitioning


On 7/21/2011 5:00 PM, Antoine Pitrou wrote:

Le vendredi 22 juillet 2011 à 09:53 +1000, Nick Coghlan a écrit :

On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrousolip...@pitrou.net  wrote:

On Tue, 19 Jul 2011 23:58:55 -0400
P.J. Ebyp...@telecommunity.com  wrote:

Anyway, to make a long story short, we came up with an alternative
implementation plan that actually solves some other problems besides
the one that PEP 382 sets out to solve, and whose implementation a
bit is easier to explain.  (In fact, for users coming from various
other languages, it hardly needs any explanation at all.)

I have a question.

If I have (on sys.path) a module x.py containing, say:

y = 5

and (also on sys.path), a directory x containing a y.py module.

What is from x import y supposed to do?

(currently, it would bind y to its value in x.py)

It would behave the same as it does today: the imported value of 'y' would be 5.

Virtual packages only kick in if an import would otherwise fail.

Wouldn't it produce confusing situations like the above example?

Regards

Antoine.


If I have (on sys.path), a directory x containing a y.py module, and 
later (on sys.path), another directory x containing a y.py module, 
what is from x import y supposed to do?


OR

If I have (on sys.path), a module x.py containing, say:

   y = 5

and later (on sys.path), another module x.py containing, say:

   y = 6

what is from x import y supposed to do?


I guess I don't see how this new proposal makes anything more confusing 
than it already is?
___
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] Draft PEP: Simplified Package Layout and Partitioning

On Thu, 21 Jul 2011 17:31:04 -0700
Glenn Linderman v+pyt...@g.nevcal.com wrote:
 
 If I have (on sys.path), a directory x containing a y.py module, and 
 later (on sys.path), another directory x containing a y.py module, 
 what is from x import y supposed to do?
 
 OR
 
 If I have (on sys.path), a module x.py containing, say:
 
 y = 5
 
 and later (on sys.path), another module x.py containing, say:
 
 y = 6
 
 what is from x import y supposed to do?
 
 
 I guess I don't see how this new proposal makes anything more confusing 
 than it already is?

It does. In your two examples, the x.py files (or the x directories)
live in two different base directories; imports are then resolved in
sys.path order, which is expected and intuitive.

However, you can have a x.py file and a x directory *in the same
base directory which is present in sys.path*, meaning sys.path can't
help disambiguate in this case.

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] 3.2.1 encoding surprise


On 22/07/2011 9:02 AM, Glenn Linderman wrote:

Bad logic is get_configured_value!  get_configured_value only looks in
the global configuration file if there is a local configuration file
that doesn't have the setting.  It should look in the global
configuration file if there is no local configuration file _OR_ the is a
local configuration file without the setting.

I'll await a new launcher.


I just pushed a fix and hopefully Vinay will push a new MSI soon.

Thanks,

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] Draft PEP: Simplified Package Layout and Partitioning


On 7/21/2011 5:38 PM, Antoine Pitrou wrote:

However, you can have a x.py file and a x directory *in the same
base directory which is present in sys.path*, meaning sys.path can't
help disambiguate in this case.


Ah yes.  It means there has to be one more rule for disambiguation, 
which Nick supplied.  Your case wasn't clear to me from your first 
description, however.  As long as there is an ordering, and it is 
documented, it is not particularly confusing, however.
___
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] Draft PEP: Simplified Package Layout and Partitioning

On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou solip...@pitrou.net wrote:
 Wouldn't it produce confusing situations like the above example?

I don't see how it is any more confusing than any other form of module
shadowing.

For backwards compatibility reasons, the precedence model will be:

1. Modules and self-contained packages that can satisfy the import
request are checked for first (along the whole length of sys.path).
2. If that fails, the virtual package mechanism is checked

PEP 402 eliminates some cases of package shadowing by making
__init__.py files optional, so your scenario will actually *work*, so
long as the submodule name doesn't conflict with a module attribute.

*Today* if you have:

x.py
x.pyd
x.so
x/__init__.py

in the same sys.path directory, x.py wins (search order is controlled
by the internal order of checks within the import system - and source
files are first on that list).

With PEP 302, x.py still wins, but the submodules within the x
directory become accessible so long as they don't conflict with
*actual* attributes set in the x module.

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 launcher command line usage (Was: 3.2.1 encoding surprise)

2011-07-21 Thread Vlad Riscutia

I'm kind of -1 on changing Python executable name. It would make sense for
different major versions, where there are known incompatibilities, so
python2-python3 would make sense but python31 python32 not that much...

If my team is using Python and it gets pre-installed with other dev-tools,
do I need to let everyone know they must call python*31*? And if we upgrade,
make sure everyone knows they should now call python*32*? What if we have
scripts that call python? Make sure we update all of them whenever minor
version is changed?

The way I look at it, most people have only one version of Python installed
at one time and it's just extra burden to make them remember major+minor
version number they have. If you actually install multiple versions, you do
that for a reason and, since you know what you're doing, you would rather
remember to pass correct -v argument to py than users who *just want to use
Python*.

Thank you,
Vlad

On Thu, Jul 21, 2011 at 12:42 PM, Terry Reedy tjre...@udel.edu wrote:

On 7/20/2011 7:55 PM, Mark Hammond wrote:

On 21/07/2011 4:38 AM, Terry Reedy wrote:

Many installers first make an organization directory and then an app
directory within that. This annoys me sometimes when they only have one
app to ever install, but is useful when there might really be multiple
directories, as in our case. (Ditto for start menu entries.) This is
what python should have done a decade ago.

I disagree. If we followed that advice we would also be in \Program
Files.

That is not what I suggested. I said let the use pick.

I have no problem with multiple Python versions installed
directly off the root, especially given most users probably have a very
small number of such installations. I think Python being a developer
tool rather than a user app is a reasonable justification for that (and
the justification used when the existing scheme was decided)

I put the multiple installations and several other directories into
/programs. On my next machine, on order, I will use /devel.

The two proposals

overlap but are not mutually exclusive. For future pythons, 'python33'
is easier to remember and type than 'py -v 3.3' or whatever the proposed
encantation is.

'py -3.3' - less chars to type than 'python33' and with no need to have
every Python directory on your PATH.

My proposal, as I clearly said, was for EXACTLY ONE directory to be added
to PATH. In spite of Microsoft making is damned difficult for users to edit
PATH, (and deleted programs not deleting their entries) I added
'C:/programs;'. I copied python32/python as py32 and python27/python as
py27. Those are even fewer characters to type (4 versus 7). Now I can click
a 'Command Prompt' icon and enter 'py32 -m test.regrtest' and it works
without cd-ing to /programs/python32. Of course, I will have to re-copy with
every install, which is why I would like something like this as part of
installs.

IMO it is also simple enough that
people will remember it fairly easily.

py32 is even easier to remember.

Also, the launcher supports the ability to select either the 32 or 64bit
implementation - so maybe 'python33.exe' isn't really good enough and
should reflect the bittedness?

Like py32-6? If I install both Pythons on my new 64 bit machine, I will
think about it, though I have no need for both now.

A python directory also gives a sensible (though optional) place to put
other interpreters and even python-based apps. The launcher does not.

What other interpreters? IMO it doesn't make sense to have IronPython,
jython etc be installed there. Ditto for apps - especially given most
apps tend to be tied to a subset of all possible Python versions.

If I install pypy, /programs is exactly where I would put it until I
somehow discovered that to be a problem. Its startup could be copied as pp26
or something.

My idea may be not so good for general use, even though is now solves my
problems, but please criticize what I said, allowing for obvious
modifications like py32 instead of python32, and not a strawman that is
wildly different.

--
Terry Jan Reedy

__**_
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
riscutiavlad%40gmail.comhttp://mail.python.org/mailman/options/python-dev/riscutiavlad%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] Draft PEP: Simplified Package Layout and Partitioning

On Fri, Jul 22, 2011 at 10:53 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 Ah yes.  It means there has to be one more rule for disambiguation, which
 Nick supplied.  Your case wasn't clear to me from your first description,
 however.  As long as there is an ordering, and it is documented, it is not
 particularly confusing, however.

The genuinely confusing part is that x.py still takes precedence, even
if it appears on sys.path *after* x/y.py.

However, we're forced into that behaviour by backwards compatibility
requirements. The alternative of allowing x/y.py to take precedence
has been rejected on those grounds more than once.

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] Draft PEP: Simplified Package Layout and Partitioning


Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit :
 On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou solip...@pitrou.net wrote:
  Wouldn't it produce confusing situations like the above example?
 
 I don't see how it is any more confusing than any other form of module
 shadowing.

The additional confusion lies in the fact that a module can be shadowed
by something which is not a module (a mere global variable). I find it
rather baffling.

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 launcher command line usage (Was: 3.2.1 encoding surprise)

2011-07-21 Thread Éric Araujo

Hi,

Le 22/07/2011 03:03, Vlad Riscutia a écrit :
 I'm kind of -1 on changing Python executable name. It would make sense for
 different major versions, where there are known incompatibilities, so
 python2-python3 would make sense but python31 python32 not that much...
 
 If my team is using Python and it gets pre-installed with other dev-tools,
 do I need to let everyone know they must call python*31*? And if we upgrade,
 make sure everyone knows they should now call python*32*? What if we have
 scripts that call python? Make sure we update all of them whenever minor
 version is changed?

If I understand correctly, adding versioned filenames like python3.3.exe
would happen in addition of python.exe, not in replacement.

Regards
___
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 launcher command line usage (Was: 3.2.1 encoding surprise)

2011-07-21 Thread Vlad Riscutia

If versioned filenames are added in addition to python.exe, it still might
look confusing for most users: Why do I have python and python3.2
executables? What's the difference? I'd rather go with -v argument either
way, for people that *know* they want to call Python 3.2 instead of Python
3.1...

Thank you,
Vlad

On Thu, Jul 21, 2011 at 6:07 PM, Éric Araujo mer...@netwok.org wrote:

 Hi,

 Le 22/07/2011 03:03, Vlad Riscutia a écrit :
  I'm kind of -1 on changing Python executable name. It would make sense
 for
  different major versions, where there are known incompatibilities, so
  python2-python3 would make sense but python31 python32 not that much...
 
  If my team is using Python and it gets pre-installed with other
 dev-tools,
  do I need to let everyone know they must call python*31*? And if we
 upgrade,
  make sure everyone knows they should now call python*32*? What if we have
  scripts that call python? Make sure we update all of them whenever minor
  version is changed?

 If I understand correctly, adding versioned filenames like python3.3.exe
 would happen in addition of python.exe, not in replacement.

 Regards

___
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] Draft PEP: Simplified Package Layout and Partitioning

2011-07-21 Thread P.J. Eby


At 03:04 AM 7/22/2011 +0200, Antoine Pitrou wrote:
The additional confusion lies in the fact that a module can be 
shadowed by something which is not a module (a mere global 
variable). I find it rather baffling.


If you move x.py to x/__init__.py, it does *exactly the same thing* 
in current versions of Python:


Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit 
(Intel)] on win32

Type help, copyright, credits or license for more information.
 from x import y
 import x.y
 x.y
module 'x.y' from 'x\y.py'
 y
5

The PEP does nothing new or different here.  If something is baffling 
you, it's the behavior of from ... import, not the actual importing process.


from x import y means import x; y = x.y.  The PEP does not 
propose we change this.  ;-)


___
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] Draft PEP: Simplified Package Layout and Partitioning