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

[Raymond Hettinger]

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

> 
> 
> On Wed, Jul 20, 2011 at 11:48, Terry Reedy  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

[Glenn Linderman]

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

On Thu, Jul 21, 2011 at 12:52 PM, R. David Murray  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

[Glenn Linderman]

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

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

[Glenn Linderman]

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

[Nick Coghlan]

On Thu, Jul 21, 2011 at 6:06 PM, Glenn Linderman  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

[Mark Hammond]

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

[Victor Stinner]

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

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

[R. David Murray]

On Thu, 21 Jul 2011 01:06:57 -0700, Glenn Linderman  
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

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

[Brian Curtin]

On Jul 21, 2011 7:15 AM, "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
>
> "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

[Mark Hammond]

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"

[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

Re: [Python-Dev] 3.2.1 encoding surprise

[Paul Moore]

On 21 July 2011 09:13, Glenn Linderman  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

[Michael Foord]

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

On 21 July 2011 09:13, Glenn Linderman  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

[Brett Cannon]

On Wed, Jul 20, 2011 at 23:05, lekmalek  wrote:

> On Sun, 17 Jul 2011 19:19:59 -0700
> Brett Cannon  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  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

[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

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

[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

[Glenn Linderman]

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

[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

[Nick Coghlan]

On Fri, Jul 22, 2011 at 5:20 AM, Terry Reedy  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

[Nick Coghlan]

On Fri, Jul 22, 2011 at 6:05 AM, Glenn Linderman  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 " and "c:\python32\python
" 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"

[Nick Coghlan]

On Thu, Jul 21, 2011 at 11:20 PM, P.J. Eby  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)

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

[Antoine Pitrou]

On Thu, 21 Jul 2011 15:37:01 -0700
Raymond Hettinger  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

[Vlad Riscutia]

Anyone care to take a look at this?

Thank you,
Vlad

On Mon, Jul 11, 2011 at 8:59 AM, Vlad Riscutia wrote:

> 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" wrote:
>
>> 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

[Glenn Linderman]

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\data>>set PYLAUNCH_DEBUG=1
set PYLAUNCH_DEBUG=1

d:\path\to\data>foo.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

[Glenn Linderman]

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

[Glenn Linderman]

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"

[Antoine Pitrou]

On Tue, 19 Jul 2011 23:58:55 -0400
"P.J. Eby"  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

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

[Éric Araujo]

Le 21/07/2011 03:31, Ben Finney a écrit :
> Éric Araujo  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"

[Nick Coghlan]

On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou  wrote:
> On Tue, 19 Jul 2011 23:58:55 -0400
> "P.J. Eby"  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"

[Antoine Pitrou]

Le vendredi 22 juillet 2011 à 09:53 +1000, Nick Coghlan a écrit :
> On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou  wrote:
> > On Tue, 19 Jul 2011 23:58:55 -0400
> > "P.J. Eby"  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"

[Glenn Linderman]

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 Pitrou  wrote:

On Tue, 19 Jul 2011 23:58:55 -0400
"P.J. Eby"  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"

[Antoine Pitrou]

On Thu, 21 Jul 2011 17:31:04 -0700
Glenn Linderman  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

[Mark Hammond]

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"

[Glenn Linderman]

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"

[Nick Coghlan]

On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou  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)

[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  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-dev
> Unsubscribe: http://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"

[Nick Coghlan]

On Fri, Jul 22, 2011 at 10:53 AM, Glenn Linderman  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"

[Antoine Pitrou]

Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit :
> On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou  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)

[É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)

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

[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

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

[Nick Coghlan]

On Fri, Jul 22, 2011 at 11:04 AM, Antoine Pitrou  wrote:
>
> Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit :
>> On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou  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.

It's still an improvement on current Python. There a submodule can be
shadowed uselessly by something that doesn't even exist. For example:

x.py <-- No 'y' attribute
x/__init__.py <-- not needed in PEP 402
x/y.py

from x import y  <-- ImportError now, but would work in PEP 402

However, this does highlight an interesting corner case not yet
covered by the PEP: when building a virtual path to add to an existing
module, what do we do with directories that contain __init__.py[co]
files?

1. Ignore the entire directory (i.e leave it out of the created path)?
(always emit ImportWarning)
2. Ignore the file and add the directory to the created path anyway?
(never emit ImportWarning)
3. Ignore the file and add the directory to the created path anyway?
(emit ImportWarning if __init__.py is not empty)
4. Ignore the file only if it is empty, otherwise ignore the whole
directory? (emit ImportWarning if __init__.py is not empty)
5. Execute the file in the namespace of the existing module?

I suspect option 1 will lead to the fewest quirks, since it preserves
current shadowing behaviour for modules and self-contained packages.

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

[Stephen J. Turnbull]

Glenn Linderman writes:

 > I note in passing that '/usr/bin/env python' is hard-coded in the 
 > launcher, which conforms to the above documentation.

A single character (space or tab) is also hard-coded in Emacs's
python-mode.

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

No, there is no hard requirement; the shebang still is not
standardized AFAIK.  A single space is probably the most portable
choice, however.

It would not be hard to allow arbitrary whitespace, but I think
documenting the restriction is sufficient.

___
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