P.J. Eby wrote:
Could we at least have some syntax like 'return from yield with 43', to
distinguish it from a regular return, clarify that it's returning a
value to a yield-from statement, and emphasize that you need a
yield-from to call it?
You don't, though -- yield-from just happens to
Brett Cannon wrote:
On Thu, Mar 26, 2009 at 18:05, Terry Reedy wrote:
If one adds type annotations so that values can be unboxed, would not
Cython, etc, do even better for speedup?
Nope as Unladen is planning to re-implement the eval loop, something Cython
doesn't optimize without the need
Jim Jewett wrote:
I still don't see why it needs to be a return statement. Why not make
the intent of g explicit
def g():
yield 42
raise StopIteration(43)
Because it would be tedious and ugly, and would actually make
the intent *less* clear in the intended use cases.
def g():
yield 42
return 43
I don't see how the allowing return values in generators can fail to
be confusing for people new to Python. Of course, there are limits to
the degree that we should let people who are bad at Python dictate our
code practices, but I really just feel
Guido van Rossum wrote:
On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to
change datetime.
In the case of datetime, could perhaps just the
module name be changed so
Greg Ewing wrote:
Guido van Rossum wrote:
(Well here is Greg's requested use case for .send(). :-)
There was a complaint that my return-value-with-send
example was too much of a coroutine scenario, so I
was hoping to find something un-coroutine-like. But
if coroutines are the main uses
Guido van Rossum wrote:
[...] (There could be good reasons not to
complexificate it this way too.)
You've been 'Mercanized. This is the most worstest English I have ever
seen you write.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC
Greg Ewing wrote:
Guido van Rossum wrote:
That +0 could turn into a +1 if there was a way to flag this as an
error (at runtime), at least if the return is actually executed:
def g():
yield 42
return 43
for x in g():
print x# probably expected to print 42 and then 43
P.J. Eby wrote:
One remaining quirk or missing piece: ISTM there needs to be a way to
extract the return value without using a yield-from statement. I mean,
you could write a utility function like:
def unyield(geniter):
try:
while 1: geniter.next()
except
Greetings,
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
The problem of splitting a string like 10.3.40-beta into tuple for
cmp() seems to be dead simple, but the code gets bulky with excepting
errors arised from converting resulting strings for arithmetic
gl...@divmod.com wrote:
On 26 Mar, 07:22 pm, ba...@python.org wrote:
One thing that /would/ be helpful though is the ability to list all
the resources under a specific package path. This is (I think) one
use case that pkg_resource fails to support and it's the one place
that I've had to drop
Collin Winter wrote:
On Thu, Mar 26, 2009 at 8:05 PM, Terry Reedy tjre...@udel.edu wrote:
An ars technica articla just linked to in a python-list post
http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars
calls the following project
2009/3/27 Guido van Rossum gu...@python.org:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete
Please
2009/3/27 Collin Winter coll...@gmail.com:
In particular, Windows support is one of those things we'll need to
address on our end. LLVM's Windows support may be spotty, or there may
be other Windows issues we inadvertently introduce. None of the three
of us have Windows machines, nor do we
on 2009-03-27 05:17 P.J. Eby said the following:
At 04:08 PM 3/27/2009 +1300, Greg Ewing wrote:
You can't expect to improve something like that by
stuffing yield-from into the existing framework, because
the point of yield-from is to render the framework
itself unnecessary.
But it doesn't.
Greg Ewing greg.ewing at canterbury.ac.nz writes:
It's not really about doing away with trampolines anyway.
You still need at least one trampoline-like thing at the
top. What you do away with is the need for creating
special objects to yield, and the attendant syntactic
clumisiness and
anatoly techtonik wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
snip
What do you think about adding cmpversions(first, second,
strict=false) based on distutils into main lib?
distutils _is_ already in the main lib, that is, the standard
Collin Winter wrote:
That would be a bikeshed discussion of such
magnitude, you'd have to invent new colors to paint the thing.
Octarine. Definitely octarine :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
Steve Holden wrote:
I am a *bit* concerned, without really being able to put my finger on
it, that the yield from expression's value comes from inside (the
return from the nested generator) while the yield from expression's
value comes from outside (the value passed to a .send() method call).
I frequently have this situation:
try:
try:
raise Thing
except Thing, e:
# handle Thing exceptions
raise
except:
# handle all exceptions, including Thing
It would be much more readable if there were a way to recatch a named
exception with the generic
Thank you for filing a new Bug report with Debian.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
Your message
Paul Moore p.f.mo...@gmail.com writes:
Please don't move bdist_wininst out of the core, though!
I'd argue that Windows is a special case, as many Windows users
don't have the ability to build their own extensions, so they rely
heavily on binary installers. And there's no Windows packagers
anatoly techtonik wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
Can't you just compare sys.version_info tuples?
sys.version_info
(2, 5, 0, 'final', 0)
Assuming the other possibilities for 'final' are
'alpha' and 'beta', these should compare in
Draft 10 of the PEP. Removed the outer try-finally
from the expansion and fixed it to re-raise
GeneratorExit if the throw call raises StopIteration.
--
Greg
PEP: XXX
Title: Syntax for Delegating to a Subgenerator
Version: $Revision$
Last-Modified: $Date$
Author: Gregory Ewing
On Fri, Mar 27, 2009 at 8:28 PM, Ben Finney
bignose+hates-s...@benfinney.id.au wrote:
I would argue that the Python community has a wealth of people quite
capable of taking on this particular task, and if it makes the core
architecture and maintenance of ‘distutils’ simpler to remove special
Tarek Ziadé wrote:
So if we, for once, forget about the central site-packages and define some
kind of configuration process that is run when every script is launched
to decide what packages should be loaded, we could seperate
python the interpreter from python the pile of packages
If some
Mark Donald wrote:
I frequently have this situation:
try:
try:
raise Thing
except Thing, e:
# handle Thing exceptions
raise
except:
# handle all exceptions, including Thing
How about:
try:
... code that can raise Thing or another exception ...
except
On Fri, Mar 27, 2009 at 5:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
Greg Ewing greg.ewing at canterbury.ac.nz writes:
It's not really about doing away with trampolines anyway.
You still need at least one trampoline-like thing at the
top. What you do away with is the need for creating
Hrvoje Niksic wrote:
How about:
try:
... code that can raise Thing or another exception ...
except Exception, e:
if isinstance(e, Thing):
# handle thing
# generic exception handling
That is indeed the idiomatic way of handling the original poster's use
case without
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete
Should this
On Thu, Mar 26, 2009 at 4:48 PM, Barry Warsaw ba...@python.org wrote:
On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote:
On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw ba...@python.org wrote:
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
One thing that /would/ be helpful though is the ability
On Thu, Mar 26, 2009 at 6:27 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/26 Barry Warsaw ba...@python.org:
Let me clarify my position: I just want the functionality (preferably in the
stdlib); I don't really care how it's spelled (except please not
pkg_resource.whatever() :).
Agreed.
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg m...@egenix.com wrote:
I think that esp. the bdist_* commands help developers a lot by
removing the need to know how to build e.g. RPMs or Windows
installers and let distutils deal with it.
I think it is a big dangerous to build rpm/deb without
M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs
2009/3/27 Jesse Noller jnol...@gmail.com:
That's because most of us who might like this have been patently
avoiding this thread.
I like the syntax, I'm iffy on the exception other than stop iteration
(but I lost track on what was decided on this) and I would like to see
this go in. I think
On Fri, Mar 27, 2009 at 7:49 AM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/27 Guido van Rossum gu...@python.org:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead
On Fri, Mar 27, 2009 at 11:50, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/27 Collin Winter coll...@gmail.com:
In particular, Windows support is one of those things we'll need to
address on our end. LLVM's Windows support may be spotty, or there may
be other Windows issues we
Olemis Lang wrote:
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/27 Guido van Rossum gu...@python.org:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the
On 27 Mar, 2009, at 7:49, M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools
Steve Careful, Glyph. Nobody likes a smart-ass ;-)
I think he'll be ok. He escaped the language summit with only minor wounds
yesterday. wink
Skip
___
Python-Dev mailing list
Python-Dev@python.org
On 2009-03-27 13:58, David Cournapeau wrote:
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg m...@egenix.com wrote:
I think that esp. the bdist_* commands help developers a lot by
removing the need to know how to build e.g. RPMs or Windows
installers and let distutils deal with it.
I think
2009/3/27 David Cournapeau courn...@gmail.com:
Concerning contribution for windows binaries: as the current numpy
developer in charge of windows binaries and windows support for a
while, my experience is that the windows situation for contribution is
very different from the other platforms.
On 2009-03-27 15:00, Ronald Oussoren wrote:
On 27 Mar, 2009, at 7:49, M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in
On Fri, Mar 27, 2009 at 5:50 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/3/27 Collin Winter coll...@gmail.com:
In particular, Windows support is one of those things we'll need to
address on our end. LLVM's Windows support may be spotty, or there may
be other Windows issues we inadvertently
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
On the packaging summit yesterday, people agreed that yes, we should
have something like that in the standard library, and it should be more
powerful than what distutils currently offers.
There was no
Mark Donald wrote:
Thanks for the idea, but I believe it has a different outcome. You'd
have to copy the generic handler into an except clause to get exactly
the behaviour I'm looking for, which is worse than nesting the try
blocks
Then simply change Exception to BaseException. Since all
See http://wiki.python.org/moin/ApplicationInfrastructure , Version
handling below for a possible strict version API.
The page is relevant for the general packaging discussion as well, although
it's not fully fleshed out yet.
MS
On Fri, Mar 27, 2009 at 5:11 PM, Martin v. Löwis
2009/3/27 Thomas Wouters tho...@python.org:
It's not a matter of chipping away support. It's a matter of wishing to not
write our own JIT, but rather leverage other people's work. That currently
means LLVM, but LLVM has a weak Windows story at the moment.
Ah, I see. That's much more
Hello,
Just for the record, I thought I'd point out this slightly exotic and funny
incompatibility between 2.x and py3k. This is due to the fact that list
comprehensions now live in their own frame, so a yield expression inside a
list comprehension turns the comprehension itself into a generator
On 2009-03-27 17:01, Eric Smith wrote:
Martin v. Löwis wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
On the packaging summit yesterday, people agreed that yes, we should
have something like that in the standard library, and it should be more
Martin v. Löwis wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
On the packaging summit yesterday, people agreed that yes, we should
have something like that in the standard library, and it should be more
powerful than what distutils currently
At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
(*) I've had a go at this a few months ago and then found out
that the egg format itself is not documented anywhere.
It's been documented for just under three years now. Here's where
you quoted the email where I announced that documentation,
Instead of trying to parse some version string, distutils should
require defining the version as tuple with well-defined entries -
much like what we have in sys.version_info for Python.
The developer can then still use whatever string format s/he wants.
The version compare function would
Guido van Rossum wrote:
2009/3/26 Toshio Kuratomi a.bad...@gmail.com:
Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
I think Distutils (and therefore Setuptools) should provide some APIs
to play with special files (like resources) and to mark
At 05:08 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
On 2009-03-27 17:01, Eric Smith wrote:
Martin v. Löwis wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
On the packaging summit yesterday, people agreed that yes, we should
have something like
At 03:28 AM 3/27/2009 -0400, Scott Dial wrote:
P.J. Eby wrote:
One remaining quirk or missing piece: ISTM there needs to be a way to
extract the return value without using a yield-from statement. I mean,
you could write a utility function like:
def unyield(geniter):
try:
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help. Most of the code, though, deals with
locating/inspecting installed distributions, resolving version
requirements, and managing
Nick Coghlan wrote:
Collin Winter wrote:
That would be a bikeshed discussion of such
magnitude, you'd have to invent new colors to paint the thing.
Octarine. Definitely octarine :)
I'm not so sure of the color itself, but its name should definitely
rhyme with orange.
--Scott David Daniels
ACTIVITY SUMMARY (03/20/09 - 03/27/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2395 open (+33) / 15008 closed (+21) / 17403 total (+54)
Open issues with patches: 845
I was recently reviewing some Python code for a friend who is a C++
programmer, and he had code something like this:
def foo():
try = 0
while tryMAX:
ret = bar()
if ret: break
++try
I was a bit surprised that this was syntactically valid, and because
the timeout condition
On 2009-03-27 17:07, P.J. Eby wrote:
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help. Most of the code, though, deals with
locating/inspecting installed distributions,
M.-A. Lemburg wrote:
On 2009-03-27 17:07, P.J. Eby wrote:
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help. Most of the code, though, deals with
locating/inspecting installed
On Fri, Mar 27, 2009 at 1:21 PM, Eric Smith e...@trueblade.com wrote:
M.-A. Lemburg wrote:
On 2009-03-27 17:07, P.J. Eby wrote:
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help.
On Fri, Mar 27, 2009 at 12:53 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
That +0 could turn into a +1 if there was a way to flag this as an
error (at runtime), at least if the return is actually executed:
def g():
yield 42
return 43
for x in g():
On 2009-03-27 17:19, P.J. Eby wrote:
At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
(*) I've had a go at this a few months ago and then found out
that the egg format itself is not documented anywhere.
It's been documented for just under three years now. Here's where you
quoted the email
On Fri, Mar 27, 2009 at 1:06 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
P.J. Eby wrote:
Could we at least have some syntax like 'return from yield with 43', to
distinguish it from a regular return, clarify that it's returning a value to
a yield-from statement, and emphasize that you
mal Zip files are great for shipping packages to the end-user, but
mal there's no need to keep them zipped once they get there.
I thought one of the arguments for zip files was a performance increase
(reduced stat(2) calls, etc). I may misremember though.
Skip
Olemis Lang wrote:
I also think the feature should go. If you want functionality that's so
difficult to provide when you install as a zip file, the answer is not to
make things more complex, but to not install as zip files.
What about environments like Google App Engine ? I mean, AFAIK using
Jared Grubb wrote:
I'm not a EBNF expert, but it seems that we could modify the grammar to
be more restrictive so the above code would not be silently valid. E.g.,
++5 and 1+++5 and 1+-+5 are syntax errors, but still keep 1++5,
1+-5, 1-+5 as valid. (Although, '~' throws in a kink...
On Mar 27, 2009, at 3:24 PM, s...@pobox.com wrote:
I thought one of the arguments for zip files was a performance
increase
(reduced stat(2) calls, etc). I may misremember though.
You're memory is working fine, but I don't think the way eggs are used
accomplishes that.
The measurements
On Fri, Mar 27, 2009 at 2:27 PM, Eric Smith e...@trueblade.com wrote:
Olemis Lang wrote:
I also think the feature should go. If you want functionality that's so
difficult to provide when you install as a zip file, the answer is not to
make things more complex, but to not install as zip files.
Please take this to python-ideas.
On Fri, Mar 27, 2009 at 2:15 PM, Joe Smith unknown_kev_...@hotmail.com wrote:
Jared Grubb wrote:
I'm not a EBNF expert, but it seems that we could modify the grammar to
be more restrictive so the above code would not be silently valid. E.g.,
++5 and 1+++5
I got the impression that people are generally happy with what
setuptools provides for version parsing and comparison.
Does anyone think that's not a good model?
Procedurally, I think it's a very bad approach. I don't mind
the setuptools implementation being used as a basis (assuming
it
Martin v. Löwis wrote:
I got the impression that people are generally happy with what
setuptools provides for version parsing and comparison.
Does anyone think that's not a good model?
Procedurally, I think it's a very bad approach. I don't mind
the setuptools implementation being used as
On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith e...@trueblade.com wrote:
M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the
On Mar 27, 2009, at 3:56 PM, Guido van Rossum wrote:
One of the motivations for deprecating this (and for using this
specific example) was that Matthias Klose, the Python packager for
Debian, said he never uses bdist_rpm.
Given that Debian doesn't use RPMs, isn't that expected?
I'm actually
At 08:12 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
On 2009-03-27 17:19, P.J. Eby wrote:
At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
(*) I've had a go at this a few months ago and then found out
that the egg format itself is not documented anywhere.
It's been documented for just under
Here's a wrapup of my notes for the Distutils part (with Jim's help).
The PyPI part will come later.
I have presented the various problems developers have with packaging
today, wether they are using Distutils, Setuptools or any other third
party tools out there.
Here's the short-list:
-
On Fri, Mar 27, 2009 at 2:59 PM, Fred Drake fdr...@acm.org wrote:
On Mar 27, 2009, at 3:56 PM, Guido van Rossum wrote:
One of the motivations for deprecating this (and for using this
specific example) was that Matthias Klose, the Python packager for
Debian, said he never uses bdist_rpm.
On 07:59 pm, fdr...@acm.org wrote:
I'm actually in favor of removing the bdist_* from the standard
library, and allowing 3rd-party tools to implement whatever they need
for the distros. But I don't think what you're presenting there
supports it.
I do think that it's relevant that the
2009/3/27 P.J. Eby p...@telecommunity.com:
Also, it's quite likely that platform-specific dependencies may exist as
well. It might be possible to accommodate these things with a sufficiently
flexible format, but currently, the only way to handle them with
distutils/setuptools is in the setup
gl...@divmod.com schrieb:
On 07:59 pm, fdr...@acm.org wrote:
I'm actually in favor of removing the bdist_* from the standard
library, and allowing 3rd-party tools to implement whatever they need
for the distros. But I don't think what you're presenting there
supports it.
I do think that
I forwarded this to ow...@bugs.debian.org (and the actual submitter)
suggesting that this was misaddressed.
Debian Bug Tracking System wrote:
Thank you for filing a new Bug report with Debian.
This is an automatically generated reply to let you know your message
has been received.
Your
On 2009-03-27 20:56, Guido van Rossum wrote:
On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith e...@trueblade.com wrote:
M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try
On Fri, Mar 27, 2009 at 3:48 PM, M.-A. Lemburg m...@egenix.com wrote:
More importantly:
Why is the non-use of a command by a single Python developer enough
motivation to remove a useful feature of distutils that's been in
use by many others for years ?
From the discussions I had with RPM
On 2009-03-27 21:49, gl...@divmod.com wrote:
On 07:59 pm, fdr...@acm.org wrote:
I'm actually in favor of removing the bdist_* from the standard
library, and allowing 3rd-party tools to implement whatever they need
for the distros. But I don't think what you're presenting there
supports it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 27, 2009, at 7:51 AM, Olemis Lang wrote:
from pkg_resources import *
for fnm in sorted(resource_listdir('mailman.database', 'sql'), \
my_own_cmp ): # Only if needed ... ;)
Thanks, it was pkg_resource.resource_listdir()
On 2009-03-27 20:24, s...@pobox.com wrote:
mal Zip files are great for shipping packages to the end-user, but
mal there's no need to keep them zipped once they get there.
I thought one of the arguments for zip files was a performance increase
(reduced stat(2) calls, etc). I may
I do think that it's relevant that the respective operating system
packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not
very useful to have a bdist_deb that nobody actually builds debs with.
I think that conclusion is invalid: just because the distributions don't
use it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 27, 2009, at 2:27 PM, Eric Smith wrote:
Olemis Lang wrote:
I also think the feature should go. If you want functionality
that's so
difficult to provide when you install as a zip file, the answer is
not to
make things more complex, but
On Mar 27, 2009, at 5:22 PM, M.-A. Lemburg wrote:
Perhaps someone should start working on a tool called FryingPan to
create Omelettes, ie. all eggs squashed into a single ZIP
file... ;-)
I've certainly suggested such a tool in various conversations, but it
usually comes down to not
Following up on yesterday's conversation about 2to3 and 3to2, I wonder if
it's easily possible to run 2to3 with a specific small subset of its fixers?
For example, people not wanting to make the 2-3 leap yet might still be
interersted in the exception handling changes (except Foo as exc)?
Thx,
2009/3/27 s...@pobox.com:
Following up on yesterday's conversation about 2to3 and 3to2, I wonder if
it's easily possible to run 2to3 with a specific small subset of its fixers?
For example, people not wanting to make the 2-3 leap yet might still be
interersted in the exception handling
Yes, you can easily specify the set of fixers to use with a
command-line flag. Each specific transform (e.g. except a, b -
except a as b) can be turned on or off that way.
2009/3/27 s...@pobox.com:
Following up on yesterday's conversation about 2to3 and 3to2, I wonder if
it's easily possible
I just collected the version strings of versions that
got released to PyPI, and put up the list on
http://www.dcl.hpi.uni-potsdam.de/home/loewis/versions
Most of them probably fit into any schema we come up with,
but there are certainly some unconventional ones:
1 to 3
1.*
Verrsion 1
working
Martin v. Löwis wrote:
I do think that it's relevant that the respective operating system
packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not
very useful to have a bdist_deb that nobody actually builds debs with.
I think that conclusion is invalid: just because the
Martin v. Löwis wrote:
I just collected the version strings of versions that
got released to PyPI, and put up the list on
http://www.dcl.hpi.uni-potsdam.de/home/loewis/versions
That's excellent, thank you.
The following chunk of text is present. I don't really care, except that
it might
On 28/03/2009 7:49 AM, gl...@divmod.com wrote:
Perhaps bdist_wininst/_msi could be donated to the
py2exe project if they would be willing to maintain it, and the new
project for _deb and _rpm could be called py2packman or something.
As mentioned, it isn't really a natural fit - but regardless,
Mark Hammond skippy.hammond at gmail.com writes:
As mentioned, it isn't really a natural fit - but regardless, py2exe is
struggling to maintain itself at the moment...
It is the first auto-maintained package I have ever heard of :-)
Regards
Antoine.
1 - 100 of 109 matches
Mail list logo
