Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

2013-07-28 Thread Paul Moore 
On 28 July 2013 00:30, Steve Dower  wrote:

> Another issue to consider is that the modification to PATHEXT can't be
> undone when Python is uninstalled, unless each installation adds another
> ".PY" and each uninstall removes only one (so my PATHEXT would look like
> ...;.PY;.PY;.PY;.PY;.PY;.PY;.PY;.PY;.PY;.PY). I haven't checked, but this
> could seriously hurt performance of anything that uses PATHEXT to search
> PATH for anything ending in this extension. I hope that cmd.exe and
> PowerShell check for duplicate extensions, but I wouldn't be betting any
> money that they do.
>

I used the same mechanism in msi.py (which is MSI functionality, I believe)
that is used to add Python's directory to PATH - this adds on install and
removes on ininstall. So it should work just as well as that does.

Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

2013-07-28 Thread Paul Moore 
On 28 July 2013 00:30, Steve Dower  wrote:

> > And if you change the association after the fact, you're presumably just
> as capable
> > of changing PATHEXT.
>
> Not if the association is changed by another installer (presumably with
> the user's explicit permission). It would be very easy for people to go a
> long time without noticing this until some program does ShellExecute(...)
> on a name that happens to be a Python script and Visual Studio pops open...


Mph. I'd argue that as Python "owns" the .py extension, any other
application that changes the default action of .py scripts without both
making that behaviour optional and making it off by default, is at least
unfriendly and arguably even broken. But that's just a matter of opinion...

As regards ShellExecute, I don't know how that is affected by PATHEXT. I
looked quite hard and couldn't find complete "official" documentation on
how PATHEXT is supposed to work, so I'm working a bit on experiment and
best guesses here :-( I'll go and check what the ShellExecute documentation
says on the matter (but I'm surprised - I got the impression that PATHEXT
was purely a console mechanism, so I don't quite understand why
ShellExecute would use it).

Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

2013-07-28 Thread Nick Coghlan 
On 28 July 2013 08:36, Paul Moore  wrote:
> The PEP for pyz and pwz hasn't been accepted yet. If it does, then yes pyz
> should be treated the same way (and we can have the same debate about pwz as
> we do about pyw :-))

Oops, thanks for the reminder. I'll nudge Daniel about that :)

Cheers,
Nick.

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

Re: [Python-Dev] PEP 446: Open issues/questions

2013-07-28 Thread Antoine Pitrou 
On Sun, 28 Jul 2013 02:39:19 +0200
Victor Stinner  wrote:
> Hi,
> 
> I have a few more questions on the PEP 446:
> 
> (A) How should we support support where os.set_inheritable() is not
> supported? Can we announce that os.set_inheritable() is always
> available or not? Does such platform exist?

FD_CLOEXEC is POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html

> (B) Should subprocess make the file descriptors of pass_fds
> inheritable? If yes, should it be done before or after the fork? If it
> is done after the fork and before exec, it only affects the child
> process, at least on Linux (the file descriptor is still
> non-inheritable in the parent process).

If it is done, it should definitely be done after the fork, IMO.
subprocess shouldn't have any long-lasting effects on the process.

> (C) Should we handle standard streams (0: stdin, 1: stdout, 2: stderr)
> differently? For example, os.dup2(fd, 0) should make the file
> descriptor 0 (stdin) inheritable or non-inheritable? On Windows,
> os.set_inheritable(fd, False) fails (error 87, invalid argument) on
> standard streams (0, 1, 2) and copies of the standard streams (created
> by os.dup()).

I have been advocating for that, but I now realize that special-casing
these three descriptors in a myriad of fd-creating functions isn't very
attractive.
(if a standard stream fd has been closed, any fd-creating function can
re-create that fd: including socket.socket(), etc.)

So perhaps only the *original* standard streams should be left
inheritable?

The Windows error is a bit more worrying: will it bubble up to Python
code when set_inheritable(fd, False) is called implicitly by a
fd-creating function? Should set_inheritable() be best effort and
silence that error?

Regards

Antoine.


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

Re: [Python-Dev] PEP 446: Open issues/questions

2013-07-28 Thread Charles-François Natali 
2013/7/28 Antoine Pitrou :
>> (C) Should we handle standard streams (0: stdin, 1: stdout, 2: stderr)
>> differently? For example, os.dup2(fd, 0) should make the file
>> descriptor 0 (stdin) inheritable or non-inheritable? On Windows,
>> os.set_inheritable(fd, False) fails (error 87, invalid argument) on
>> standard streams (0, 1, 2) and copies of the standard streams (created
>> by os.dup()).
>
> I have been advocating for that, but I now realize that special-casing
> these three descriptors in a myriad of fd-creating functions isn't very
> attractive.
> (if a standard stream fd has been closed, any fd-creating function can
> re-create that fd: including socket.socket(), etc.)
>
> So perhaps only the *original* standard streams should be left
> inheritable?

Having stdin/stdout/stderr cloexec (e.g. after a dup() to redirect to
a log file, a socket...) will likely break a lot of code, e.g. code
using os.system(), or code calling exec manually (and I'm sure there's
a bunch of it).

Also, it'll be puzzling to have syscalls automatically set the cloexec
flag. I guess a lot of people doing system programming with Python
will get bitten, but that's a discussion we already had months ago...

cf
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Refactoring test.support into a subpackage

2013-07-28 Thread Nick Coghlan 
On 15 July 2013 20:22, Nick Coghlan  wrote:
> At the PyCon AU sprints, some of the sprinters worked on a plan Chris
> Jerdonek and I came up with months ago to convert test.support from a
> module into a subpackage.
>
> This plan arose from some nasty test suite hacks in the lead up to the
> release of Python 3.3, where some of the pkgutil tests ended up in
> test.test_runpy so they could use the package creation infrastructure
> I have in there without needing to extract a helper module with a
> release imminent.
>
> The scope of the plan covers a few distinct steps:
>
> 1. Move Lib/test/support.py to Lib/test/support/__init__.py
> (http://bugs.python.org/issue15494)
> 2. Add a new (documented) test.support.pkg_helper submodule with the
> package creation support code (http://bugs.python.org/issue15403 and
> http://bugs.python.org/issue15376)
> 3. Move the pkgutil tests to test.test_pkgutil where they belong
> (http://bugs.python.org/issue15358)

Just a heads up that I'm working on these first three steps this
evening, so the Lib/test/support.py -> Lib/test/support/__init__.py
move will happen shortly.

I'll also be landing the patch to add test.support.temp_dir() and
test.support.change_cwd()

This shouldn't affect any other patches, unless they're adding or
change things in test.support.

Cheers,
Nick.

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

Re: [Python-Dev] Official github mirror for CPython?

2013-07-28 Thread Chris Withers 

On 25/07/2013 16:30, Brett Cannon wrote:

Based on the list of people who are members of github.com/python
 it's as official as it's going to get
(depends on who of that group owns it).

But assuming whomever owns it is okay with hosting a mirror, what
exactly is going to be required to have it updated regularly? Someone is
going to have to write the scripts to pull from the hg repo and then
push up to github else it's just going to end up out-of-date on top of
maintaining whatever setup is devised.


Mike Bayer has set up some pretty slick stuff in this area for 
SQLAlchemy and Alembic.


I'm sure he could give pointers to anyone interested in getting it going...

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Refactoring test.support into a subpackage

2013-07-28 Thread Nick Coghlan 
On 28 July 2013 20:20, Nick Coghlan  wrote:
>> The scope of the plan covers a few distinct steps:
>>
>> 1. Move Lib/test/support.py to Lib/test/support/__init__.py
>> (http://bugs.python.org/issue15494)
>> 2. Add a new (documented) test.support.pkg_helper submodule with the
>> package creation support code (http://bugs.python.org/issue15403 and
>> http://bugs.python.org/issue15376)
>> 3. Move the pkgutil tests to test.test_pkgutil where they belong
>> (http://bugs.python.org/issue15358)
>
> Just a heads up that I'm working on these first three steps this
> evening, so the Lib/test/support.py -> Lib/test/support/__init__.py
> move will happen shortly.
>
> I'll also be landing the patch to add test.support.temp_dir() and
> test.support.change_cwd()

The test.support switch (#15494) and the factoring out of the
temporary directory helpers to test.support (#15415) are done for both
3.3 and default (so it should be OK to rely on them without causing
merge conflicts in the tests).

#15403, #15376 and #15358 (the package testing cleanups) are still
open, but are also simpler to deal with now that test.support is a
package.

I also created #18576 to cover moving and documenting script_helper,
and #18578 to cover moving and documenting bytecode_helper.

Cheers,
Nick.

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

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

2013-07-28 Thread Steve Dower 
Windows fully supports *user* customization of file associations and there is 
no concept of ownership. The first program installed that sets up an 
association will normally get it, and as of Win8 the next application will be 
blocked (and suggested to the user next time they open a file). Whether the 
other application stole the extension is irrelevant: a user is allowed to 
associate .py with something other than py.exe.

I'm also working off experience with Windows here, I haven't done any special 
research. It may be that the APIs will assume .exe if no extension is 
specified, but I'd be surprised if backwards compatibility with with DOS, which 
I assume included PATHEXT, hadn't been a consideration. The Run dialog uses 
ShellExecute, so you can test things there easily.

Sent from my Windows Phone

From: Paul Moore
Sent: ‎7/‎28/‎2013 1:00
To: Steve Dower
Cc: Martin v. Löwis; Python 
Dev
Subject: Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 28 July 2013 00:30, Steve Dower 
mailto:[email protected]>> wrote:
> And if you change the association after the fact, you're presumably just as 
> capable
> of changing PATHEXT.

Not if the association is changed by another installer (presumably with the 
user's explicit permission). It would be very easy for people to go a long time 
without noticing this until some program does ShellExecute(...) on a name that 
happens to be a Python script and Visual Studio pops open...

Mph. I'd argue that as Python "owns" the .py extension, any other application 
that changes the default action of .py scripts without both making that 
behaviour optional and making it off by default, is at least unfriendly and 
arguably even broken. But that's just a matter of opinion...

As regards ShellExecute, I don't know how that is affected by PATHEXT. I looked 
quite hard and couldn't find complete "official" documentation on how PATHEXT 
is supposed to work, so I'm working a bit on experiment and best guesses here 
:-( I'll go and check what the ShellExecute documentation says on the matter 
(but I'm surprised - I got the impression that PATHEXT was purely a console 
mechanism, so I don't quite understand why ShellExecute would use it).

Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com