> Right, but it's supposed to be cross platform, as mentioned in the
> patch. This will work on Windows.
But in the description, you said that you do the same on Windows
by making a file that is both a zip file and a batch file. So my
approach is also cross-platform, no?
How do you get the -z op
On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Right, but it's supposed to be cross platform, as mentioned in the
> patch. This will work on Windows.
But in the description, you said that you do the same on Windows
by making a file that is both a zip file and a batch file. So my
ap
On 7/12/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Right, but it's supposed to be cross platform, as mentioned in the
> > > patch. This will work on Windows.
> >
> > But in the description, you said that you do the same on Windows
I'm in general in favor of this. I will accept it once there is a
working implementation that is satisfactory.
Are we planning on supporting this in 2.6? It might break some 2.5
code that messes with modules and packages?
--Guido
On 7/10/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon
On 08:41 am, [EMAIL PROTECTED] wrote:
>On 7/12/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>>I disagree with both statements. The bagage is much less than
>>zipimport
>>itself, which has proven to be quite useful. Nevertheless, zipimport
>>built
>>into the interpreter was by no means necessary
On 12/07/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I wonder, is it even necessary to say anything, after:
> >+1.
[...]
> In fact, I distinctly remember thinking "You know, if Python had an
> equivalent to Java's '-jar' option, this would be a whole lot easier."
I'm also +1 on this, for ex
On 12/07/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Right, but it's supposed to be cross platform, as mentioned in the
> > patch. This will work on Windows.
>
> But in the description, you said that you do the same on Windows
> by making a file that is both a zip file and a batch file. S
At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote:
>"" should not be removed from sys.path. It is *not* meant to be
>the current directory, but the directory where the main script
>lives.
Right; it should be replaced with the zipfile path instead.
I would personally rather see this option define
On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> But in the description, you said that you do the same on Windows
> by making a file that is both a zip file and a batch file. So my
> approach is also cross-platform, no?
>
> How do you get the -z option to work on Windows? What extension
>
On 7/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote:
> >"" should not be removed from sys.path. It is *not* meant to be
> >the current directory, but the directory where the main script
> >lives.
>
> Right; it should be replaced with the zipfil
Phillip J. Eby wrote:
> At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote:
>> "" should not be removed from sys.path. It is *not* meant to be
>> the current directory, but the directory where the main script
>> lives.
>
> Right; it should be replaced with the zipfile path instead.
>
> I would pe
On 7/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> ... there is a heavy Google bias in the existing survey sample ...
Not just this survey...
There are many python developers at Google and that is not likely to
change anytime soon. This means that it's even more important to hear
diffe
At 01:46 AM 7/13/2007 +1000, Nick Coghlan wrote:
>The current version of runpy doesn't accept any options, but it
>would be pretty easy to make the following changes:
>
>1. Accept a -p option that prepends path entries. These path entries
>would be combined into a single list from left to right o
At 08:11 AM 7/12/2007 -0700, Andy C wrote:
>Is __main__ a good idea considering that is used for something
>similar but implemented completely differently (the module name)?
That would be why it *is* a good idea; it's the One Obvious Way To Do It. :)
Now we just need an option abbreviation that'
Hi,
There seems to be a typo in the doc of itertools.dropwhile() :
Make an iterator that drops elements from the iterable as long as the
predicate is true; afterwards, returns every element. Note, the iterator
does not produce *any* output until the predicate is true, so it may have a
lengthy st
Neal> We need to hear more from people outside of Google to ensure we
Neal> are doing the best possible job. It would also be great to have
Neal> more active committers that don't work at Google.
Are you worried that Google might get hit by a bus?
Skip
_
> The approach is cross-platform, in that you can use the approach on
> different platforms. The result of the approach, however, is not
> cross-platform. You can't distribute your single zip-as-executable to
> both Windows and bourne-shell-using platforms. The -z argument does
> allow that.
I sti
> The patch suggests using .pyz and adding a default association to the
> installer (much like .py and .pyw have).
Ok. It would be good if the patch actually added that extension, rather
than merely suggesting that it should be added.
Regards,
Martin
__
> The relevant shebang line to be prepended to a zip file would then look
> something like:
>
> #!/usr/bin/env python -m runpy -p
I might be confusing things, but I think some systems only allow a
single argument in the shebang line.
Regards,
Martin
__
I'm tasked with performing a number of merge operations across
various Python branches. Can somebody please share a command
line that I should use to continue with the merge tracking that
has been used? Is that documented somewhere?
Regards,
Martin
___
P
On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I'm tasked with performing a number of merge operations across
> various Python branches. Can somebody please share a command
> line that I should use to continue with the merge tracking that
> has been used? Is that documented somewhere?
On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > The patch suggests using .pyz and adding a default association to the
> > installer (much like .py and .pyw have).
>
> Ok. It would be good if the patch actually added that extension, rather
> than merely suggesting that it should be adde
At 10:53 PM 7/12/2007 +0200, Martin v. Löwis wrote:
> > The approach is cross-platform, in that you can use the approach on
> > different platforms. The result of the approach, however, is not
> > cross-platform. You can't distribute your single zip-as-executable to
> > both Windows and bourne-she
>> #!/usr/bin/env python -m runpy -p
Martin> I might be confusing things, but I think some systems only allow
Martin> a single argument in the shebang line.
It's always been my impression that all Unix or Linux systems have that
constraint. I've never heard of that restriction being
At 03:52 PM 7/12/2007 -0700, Andy C wrote:
>On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > The patch suggests using .pyz and adding a default association to the
> > > installer (much like .py and .pyw have).
> >
> > Ok. It would be good if the patch actually added that extension, ra
After installing the x64 version of Python 2.5.1 via the MSI file on
python.org, I noticed most of the registry keys are "missing". Further
investigation shows they aren't actually missing, but have simply been
"virtualized", so they actually appear under the Wow6432Node key.
This Wow6432Node key
On 7/12/07, Mark Hammond <[EMAIL PROTECTED]> wrote:
> I'm afraid my knowledge of MSI is very limited, so I'm not sure where to
> start. One thing I did notice is that msilib\__init__.py has a variable
> 'Win64' set, hard-coded to 0 - but I've no idea if it is relevant.
> Presumably it is relevant
At 03:52 PM 7/12/2007 -0700, Andy C wrote:
>So does everyone agree that there should be a new extension called
>.pyz? And that the definition of this is a .zip file with a
>__zipmain__.py module at its root? If so, I can make the change... I
>haven't looked around the codebase yet but it soun
On 7/12/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
>
> Phillip Eby:
> > Testing your package before you zip it, would be one. :) My
> > personal main interest was in being able to add an item to sys.path
> > without having to set $PYTHONPATH on Windows. That's why I'd like it
> > to b
[Matthieu on itertools.dropwhile() docs]
> Make an iterator that drops elements from the iterable as long as the
> predicate is true; afterwards, returns every element. Note,
> the iterator does not produce any output until the predicate is true, so it
> may have a lengthy start-up time.
>
> It
On 7/12/07, Mark Hammond <[EMAIL PROTECTED]> wrote:
> Why wouldn't it work for x64 machines? Is it simply because msilib only
> handles Intel64 when that flag is set?
Right - it sets the template summary to include Intel64, not x64.
Furthermore only one architecture may be set in the template sum
Brett Cannon wrote:
> On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> I'm tasked with performing a number of merge operations across
>> various Python branches. Can somebody please share a command
>> line that I should use to continue with the merge tracking that
>> has been used? Is th
On 7/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:52 PM 7/12/2007 -0700, Andy C wrote:
> >On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > > The patch suggests using .pyz and adding a default association to the
> > > > installer (much like .py and .pyw have).
> > >
> > > O
> Per the requirements documented at
> http://msdn2.microsoft.com/En-US/library/aa372396.aspx, the behavior
> you describe is expected for a 32-bit installer.
Agreed - but unless I'm missing something, this release is not expected to
be a 32bit installer.
> (To install files and
> registry to 64-
Another issue I see is that -m and -c have command line parsing
semantics, and -z follows those now.
python -z foo.zip -z bar
As implemented, this would pass sys.argv[0:3] == ['foo.zip', '-z', 'bar']
If you allow multiple -z flags to be meaningful, this gets confusing.
The foo.zip program could
2007/7/13, Raymond Hettinger <[EMAIL PROTECTED]>:
[Matthieu on itertools.dropwhile() docs]
> Make an iterator that drops elements from the iterable as long as the
predicate is true; afterwards, returns every element. Note,
> the iterator does not produce any output until the predicate is true,
Dave Harrison writes:
> While I can't claim to have spent alot of time with DARCS, my
> experience was that it took a fair whack of unintuitive pain to work
> out how to extract a patch that I could send upstream to be submitted
> to a project.
This doesn't seem to be a common issue with Darc
Raymond Hettinger writes:
> [Matthieu on itertools.dropwhile() docs]
> > Note, the iterator does not produce any output until the
> > predicate is true
> it did return EVERY element from the first false
Shouldn't the "until" in the doc be "while"? Alternatively, "true"
could be changed to
"Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Raymond Hettinger writes:
|
| > [Matthieu on itertools.dropwhile() docs]
|
| > > Note, the iterator does not produce any output until the
| > > predicate is true
|
| > it did return EVERY element from the first fa
Andy C wrote:
> So does everyone agree that there should be a new extension called
> .pyz?
How about .pyzip instead? To make it more obvious, and not mistakable for
.py.z.
- Anders
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
40 matches
Mail list logo
