Guido van Rossum wrote:
The new exception could either be a designated (built-in) subclass of
StopIteration, or not;
I think it would have to not be; otherwise any existing
code that catches StopIteration would catch the new
exception as well without complaint.
Using a different exception rai
Eric Smith writes:
> And I personally use bdist_rpm for my work, which I distribute to a farm
> of servers under my control. So no doubt it's used.
Sure, but use for internal distribution is very different from to
problem its being asked to solve now, isn't it? IIUC, you're
basically using RP
On Fri, Mar 27, 2009 at 1:33 PM, Jesse Noller wrote:
> Antoine Pitrou:
>> As a matter of fact, the people whom this PEP is supposed to benefit haven't
>> expressed a lot of enthusiasm right now. That's why it looks so academic.
> That's because most of us who might like this have been patently
> a
On Mar 27, 2009, at 6:25 PM, P.J. Eby wrote:
At 03:06 PM 3/27/2009 -0500, Tarek Ziadé wrote:
They both aim at the
same goal besides a few differences, and they both rely
on a new metadata introduced by setuptools, wich is.
"install_requires". This new metadata extends the metadata.
describ
On Fri, Mar 27, 2009 at 8:45 PM, P.J. Eby wrote:
> At 12:53 PM 3/28/2009 +1200, Greg Ewing wrote:
>> Guido van Rossum wrote:
>>> Perhaps the crux is that *if* you accidentally use "return " in
>>> a vanilla generator expecting the value to show up somewhere, you are
>>> probably enough of a newbie
At 12:53 PM 3/28/2009 +1200, Greg Ewing wrote:
Guido van Rossum wrote:
Perhaps the crux is that *if* you accidentally use "return " in
a vanilla generator expecting the value to show up somewhere, you are
probably enough of a newbie that debugging this will be quite hard.
I'd like not to have s
On Mar 27, 2009, at 6:22 PM, P.J. Eby wrote:
At 10:22 PM 3/27/2009 +0100, 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... ;-)
They're called baskets actually. ;-) There's no tool
At 03:06 PM 3/27/2009 -0500, Tarek Ziadé wrote:
They both aim at the
same goal besides a few differences, and they both rely
on a new metadata introduced by setuptools, wich is.
"install_requires". This new metadata extends the metadata.
described in PEP 314 but is slightly different fro
At 10:22 PM 3/27/2009 +0100, 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... ;-)
They're called baskets actually. ;-) There's no tool to do it, but
pkg_resources does support multipl
2009/3/27 Collin Winter :
> 2009/3/27 :
>> 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 exc
Guido van Rossum wrote:
Perhaps the crux is that *if* you accidentally use "return " in
a vanilla generator expecting the value to show up somewhere, you are
probably enough of a newbie that debugging this will be quite hard.
I'd like not to have such a newbie trap lying around.
Okay, so would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
Mark Hammond 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.
___
Pyth
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
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 mean
"Martin v. Löwis" writes:
> I don't mind the setuptools implementation being used as a basis
> (assuming it gets contributed), but *independently* I think a
> specfication is needed what version strings it actually understands.
> Such specification must precede the actual implementation (in
> dis
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 distributi
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 pr
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 :
> Following up on yesterday's conversation about 2to3 and 3to2, I wonder if
> it's easily possible to run 2t
2009/3/27 :
> 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
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
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 wan
-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 to
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 doesn't
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 ma
-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() th
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
>> sup
On Fri, Mar 27, 2009 at 3:48 PM, M.-A. Lemburg 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 packagers, bd
On 2009-03-27 20:56, Guido van Rossum wrote:
> On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith 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
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 messag
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 thi
2009/3/27 P.J. Eby :
> 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 script.
>
Yes, we
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 respec
On Fri, Mar 27, 2009 at 2:59 PM, Fred Drake 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.
>
> Given t
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 u
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:
- Distutil
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 in
On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith 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 st
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 a
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 gets
Please take this to python-ideas.
On Fri, Mar 27, 2009 at 2:15 PM, Joe Smith 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" and "1+-+5" a
On Fri, 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 to not install as zip files.
>>>
>
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 t
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 kin
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
Z
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
On Fri, Mar 27, 2009 at 1:06 AM, Greg Ewing 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 need a yield-from to c
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 th
On Fri, Mar 27, 2009 at 12:53 AM, 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
On Fri, Mar 27, 2009 at 1:21 PM, Eric Smith 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 a
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 distri
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 distribution
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 tryI was a bit surprised that this was syntactically valid, and because
the timeout condition only occurred in exceptional cases, the error
has n
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
Average
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
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
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 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 someth
Mart Sõmermaa wrote:
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.
Guido van Rossum wrote:
> 2009/3/26 Toshio Kuratomi :
>> Guido van Rossum wrote:
>>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
I think Distutils (and therefore Setuptools) should provide some APIs
to play with special files (like resources) and to mark them as being
speci
> 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 wo
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, p
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
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 offers
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
2009/3/27 Thomas Wouters :
> 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 encouraging. On the other
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" wrote:
> Corr
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 excep
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 conclusi
On Fri, Mar 27, 2009 at 5:50 AM, Paul Moore wrote:
> 2009/3/27 Collin Winter :
>> 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
>
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 functi
2009/3/27 David Cournapeau :
> 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. The mentality is
On 2009-03-27 13:58, David Cournapeau wrote:
> On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg 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
Steve> Careful, Glyph. Nobody likes a smart-ass ;-)
I think he'll be ok. He escaped the language summit with only minor wounds
yesterday.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
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 built
Olemis Lang wrote:
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore wrote:
2009/3/27 Guido van Rossum :
- 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 tool
On Fri, Mar 27, 2009 at 11:50, Paul Moore wrote:
> 2009/3/27 Collin Winter :
> > 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
On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore wrote:
> 2009/3/27 Guido van Rossum :
>> - 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 o
On Fri, Mar 27, 2009 at 7:49 AM, 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
2009/3/27 Jesse Noller :
> 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 this is going
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 c
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg 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 knowing how to
On Thu, Mar 26, 2009 at 6:27 PM, Paul Moore wrote:
> 2009/3/26 Barry Warsaw :
>> 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.
+1
--
Regards,
Olemis.
B
On Thu, Mar 26, 2009 at 4:48 PM, Barry Warsaw wrote:
> On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote:
>> On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw wrote:
>>> On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
>>>
>>> One thing that /would/ be helpful though is the ability to list all
>>
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 t
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 wit
On Fri, Mar 27, 2009 at 5:56 AM, Antoine Pitrou wrote:
> Greg Ewing 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 yi
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 Ex
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"
>
>
On Fri, Mar 27, 2009 at 8:28 PM, Ben Finney
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
> cases for binary installers,
Carl Johnson wrote:
> I think part of the appeal of using "return" is that return is what's
> used in ordinary functions, but if you think about it, you already
> have to make your cooperative multitasking mini-thread different from
> an ordinary function anyway by sprinkling yields throughout i
Paul Moore 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"
> organisation
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 ha
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 (catch-all
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
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
Status: Draft
Type
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
-
anatoly techtonik wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
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 library.
Greg Ewing 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 inefficienc
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. Yo
1 - 100 of 111 matches
Mail list logo
