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
"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
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
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
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,
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
[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
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
> 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-
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
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, 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
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, 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
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
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
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
>> #!/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
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
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?
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
> 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
__
> 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 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
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
_
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
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'
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
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
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, 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
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
>
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 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
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 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
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 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
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
> 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
40 matches
Mail list logo
