On 17 October 2011 15:20, Vinay Sajip wrote:
> Sam Partington gmail.com> writes:
>
>> That sounds like an explanation of why it hasn't been implemented
>> before, not an explanation of why it should continue that way.
>
> From a desire to keep the launcher as simple as possible, and to minimise t
On Mon, Oct 17, 2011 at 8:00 PM, Mark Hammond wrote:
> On 18/10/2011 3:24 AM, PJ Eby wrote:
>
>> What about -S (no site.py) and -E (no environment)? These are needed
>> for secure setuid scripts on *nix; I don't know how often they'd be used
>> in practice on Windows. (Basically, they let you is
Le lundi 17 octobre 2011 23:27:09, Antoine Pitrou a écrit :
> On Mon, 17 Oct 2011 02:04:38 +0200
>
> Victor Stinner wrote:
> > Le lundi 17 octobre 2011 01:16:36, Victor Stinner a écrit :
> > > For example, IN.INT_MAX is 2147483647, whereas it should
> > > be 9223372036854775807 on my 64-bit Linux
On 18/10/2011 3:24 AM, PJ Eby wrote:
On Mon, Oct 17, 2011 at 8:55 AM, Sam Partington
mailto:sam.parting...@gmail.com>> wrote:
Yes it is a bit annoying to have to treat those specially, but other
than -c/-m it does not need to understand pythons args, just check
that the arg is not
On 17 October 2011 17:24, PJ Eby wrote:
> What about -S (no site.py) and -E (no environment)? These are needed for
> secure setuid scripts on *nix; I don't know how often they'd be used in
> practice on Windows. (Basically, they let you isolate a script's effective
> sys.path; there may be some
On Mon, 17 Oct 2011 02:04:38 +0200
Victor Stinner wrote:
> Le lundi 17 octobre 2011 01:16:36, Victor Stinner a écrit :
> > For example, IN.INT_MAX is 2147483647, whereas it should
> > be 9223372036854775807 on my 64-bit Linux.
>
> Oops, wrong example: INT_MAX is also 2147483647 on 64 bits. I me
It's just an outdated link; fixed now.
Georg
Am 17.10.2011 15:16, schrieb Michael Foord:
> Hey folks,
>
> The title of the "Global Module Index" for 3.2 documentation is "Python 3.1.3
> documentation".
>
> http://docs.python.org/py3k/modindex.html
>
> See the report below (attached screenshot
On 10/17/2011 9:16 AM, Michael Foord wrote:
Hey folks,
The title of the "Global Module Index" for 3.2 documentation is "Python
3.1.3 documentation".
http://docs.python.org/py3k/modindex.html
Verified. Clicking [index] in upper right goes to
http://docs.python.org/py3k/genindex.html
3.2.2 vers
> Hmm, clicking the link in the email works here. but just to be safe:
>
> http://goo.gl/pC48e
>
Thanks - looks nice! What is the license which applies to the code? Is it
available in a public repository?
Regards,
Vinay Sajip
___
Python-Dev mailin
On Mon, Oct 17, 2011 at 8:55 AM, Sam Partington wrote:
> Yes it is a bit annoying to have to treat those specially, but other
> than -c/-m it does not need to understand pythons args, just check
> that the arg is not an explicit version specifier. -q/-Q etc have no
> impact on how to treat the fi
Sam Partington gmail.com> writes:
> That sounds like an explanation of why it hasn't been implemented
> before, not an explanation of why it should continue that way.
From a desire to keep the launcher as simple as possible, and to minimise the
need to synchronise the launcher with command line
Paul Moore gmail.com> writes:
> Correct me if I'm wrong, but if we standardised on a particular
> structure, the hooks.py contents could actually be integrated into the
> core, if we wanted? People could still write hooks for more complex
> cases, but the basic binary build case could work out of
Hey folks,
The title of the "Global Module Index" for 3.2 documentation is "Python
3.1.3 documentation".
http://docs.python.org/py3k/modindex.html
See the report below (attached screenshot removed).
All the best,
Michael Foord
Original Message
Subject:Issue with t
On 17 October 2011 13:23, Mark Hammond wrote:
> On 17/10/2011 9:10 PM, Sam Partington wrote:
>>
>> "Only the first command-line argument will be checked for a shebang line
>> and only if that argument does not start with a '-'."
>>
>> But I can't really see why that should be the case. What
On 17/10/2011 9:10 PM, Sam Partington wrote:
Hello all,
I was surprised to see that the excellent pylauncher doesn't do the
magic shebang processing if you give it any python command line
options. e.g. Given
#!/usr/bin/env python2.6
import sys
print(sys.executable)
C:\>py test.py
C:\Python26\
On 17 October 2011 10:15, Vinay Sajip wrote:
> It may not work for you, because in the default branch, packaging is currently
> missing some functionality or has bugs (I've raised about a dozen issues since
> trying to get packaging working with virtual environments).
Ah. That might be part of th
Hello all,
I was surprised to see that the excellent pylauncher doesn't do the
magic shebang processing if you give it any python command line
options. e.g. Given
#!/usr/bin/env python2.6
import sys
print(sys.executable)
C:\>py test.py
C:\Python26\python.exe
C:\>py -utt test.py
C:\Python27\pyth
Paul Moore gmail.com> writes:
> Interesting. That's not a use case that I have encountered, but I can
> see it could be an issue. I have been working on the basis that a
> bdist_simple format that matches the functionality of bdist_wininst is
> at least good enough for those projects that current
18 matches
Mail list logo
