Re: [Python-Dev] PEP 343 - Abstract Block Redux
Ron Adam wrote: > He should also be able to put try excepts before the yield, and after > the yield, or in the block. (But not surrounding the yield, I think.) I was given to understand that yield is currently allowed in try-except, just not try-finally. So this would require a non-backwards-compatible change. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tidier Exceptions
Aahz wrote: > On Fri, May 13, 2005, Greg Ewing wrote: > >>Instead of an 'args' attribute, I'd suggest that the constructor take >>keyword arguments and store them in corresponding attributes. > > Sounds reasonable, but it should be equally easy to handle:: > > raise MyError, "message" Certainly, I wasn't suggesting otherwise. To be more explicit, the base exception class would look something like class Exception: def __init__(self, message = None, **kwds): self.message = message self.__dict__.update(kwds) def __str__(self): if self.message is not None: return self.message else: return self.__class__.__name__ Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Phillip J. Eby wrote: > At 08:18 AM 5/16/2005 +1000, Nick Coghlan wrote: > >> Paul Moore wrote: >> > Looping is definitely a wart. Looping may even be a real problem in >> > some cases. There may be cases where an explicit try...finally remains >> > better, simply to avoid an unwanted looping behaviour. >> >> I agree PEP 343 throws away too much that was good about PEP 340 - >> that's why >> I'm still updating PEP 3XX as the discussion continues. > > > Could you please stop calling it PEP 3XX and go ahead and submit it as a > real PEP? Either that, or post its URL *every* time you mention it, > because at this point I don't know where to go to read it, and the same > applies for each new person to enter the discussion. Thanks. Sorry about that - I've been including the URL most of the time, but forgot on this occasion: http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html Anyway, I think it's stable enough now that I can submit it to be put up on www.python.org (I'll notify the PEP editors directly once I fix a couple of errors in the current version - like the missing 'raise' in the statement semantics. . .). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Steven Bethard wrote: > If I've misunderstood, and there are other situations when > "needs_finish" is required, it'd be nice to see some more examples. The problem is try/except/else blocks - those are currently legal, so the programmer has to make the call about whether finalisation is needed or not. I'll put this in the Open Issues section of the PEP - doing it lexically seems a little too magical for my taste (since it suddenly becomes more difficult to do partial iteration on the generator), but the decorator is a definite wart. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
On 5/15/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > Having done the python-dev summary on this topic, You have my deepest sympathy :-) > So in some sense, PEP 340 was the reason for the lack of "enthusiasm"; > with the semantics laid out, people were forced to deal with a specific > implementation instead of a variety of wild suggestions. I'm not sure I agree with that - to me, PEP 340 felt like the consolidation of the previous discussion. My feeling was "cool - we've had the discussion, now we've formalised the results, maybe a few details to tidy up and then we can see the implementation being checked in". Then Nick's proposal *failed* to feel like the tidying up of the details, and PEP 343 felt like giving up on the powerful (but hard) bits. It's all people's impressions, though, so maybe I'm just bitter and cynical :-) Interestingly, some new ideas have started appearing again (the GUI example someone raised yesterday, for instance). But with the current "multiple PEPs" situation, I can't evaluate such ideas, as I've no clue which of the various proposals would support them. > > No-one is looking at PEP 343, or > > Nick's PEP 3XX, and saying "hey, that's neat - I can do XXX with > > that!". This makes me feel that we've thrown out the baby with the > > bathwater. > > I'd be surprised if you can find many examples that PEP 340 can do > that PEP 3XX can't. In which cask, Nick is "marketing" it really badly - I hadn't got that impression at all. And if Nick's proposal really *is* PEP 340 with the issues people had resolved, how come Guido isn't supporting it? (By the way, I agree with Philip Eby - Nick's proposal really needs to be issued as a proper PEP - although if it's that close to just being a fix for PEP 340, it should probably just be the new version of PEP 340). > > (Yes, I know PEP 342 is integral to many of the neat > > features, but I get the impression that PEP 342 is being lost - later > > iterations of the other two PEPs are going out of their way to avoid > > assuming PEP 324 is implemented...) > > Not very far out of their way. Well, PEP 343 uses def template(): before yield after rather than def template(): before try: yield finally: after which I would argue is better - but it needs PEP 342 functionality. OTOH, Guido argues there are other reasons for the PEP 343 style. Also, the discussion has moved to resource objects with special methods rather than generators as templates - which I see as a direct consequence of PEP 342 being excluded. One of the things I really liked about PEP 340 was the "generator template" style of code, with yield as the "block goes here" placeolder > If you want to get people enthused about PEP 342 again (which is the > right way to make sure it gets excepted), what would really help is a > bunch of good examples of how it could be used. In my view, *every* PEP 340/343/3XX example when written in generator form counts as a good example (see above). Neat coroutine tricks and the like are the "additional benefits" - maybe bordering on abuses in some cases, so I don't want to focus on them in case we get into arguments about whether a feature is bad simply because it *can* be abused... But the key use case, for me, *is* the generator-as-template feature. > I'm convinced that such a tone is inevitable after 30 days and over > 700 messages on *any* topic. ;-) Which is why I regret that Guido didn't just go ahead and implement it, consensus be damned :-) I vote for a dictatorship :-) > Ok, back to summarizing this fortnight's 380+ PEP 340 messages. ;-) Best of luck - and in case you need a motivation boost, can I just say that this sort of thread is why I have the greatest respect and appreciation for the job the summarisers do. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Nick Coghlan wrote: > Steven Bethard wrote: > >>If I've misunderstood, and there are other situations when >>"needs_finish" is required, it'd be nice to see some more examples. > > > The problem is try/except/else blocks - those are currently legal, so the > programmer has to make the call about whether finalisation is needed or not. > > I'll put this in the Open Issues section of the PEP - doing it lexically > seems a > little too magical for my taste (since it suddenly becomes more difficult to > do > partial iteration on the generator), but the decorator is a definite wart. I had a better idea - with a decorator being used to create statement templates out of generators, that means the __enter__() and __exit__() methods of generators themselves are available to handle finalisation. So, just as my PEP suggests that files be usable like: with open(filename) as f: for line in f: print line It now suggests generators be usable like: with all_lines(filenames) as lines: for line in lines: print line Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340 keyword: after
"Chris Ryland" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I hate to add to what could be an endless discussion, but... ;-) > > In this case, "while" is the better time-related prefix, whether > keyword (hopeless, due to ages-old boolean-controlled loop association) > or function, since you want to imply that the code block is going > on *while* the lock is held or *while* the file is open (and you also > want to imply that afterwards, something else happens, i.e., cleanup). > > while_locked(myLock): ># code that needs to hold the lock Ah. You mean 'during' :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Guido van Rossum wrote: > [Nick Coghlan] > >>>http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html > I have the same question for Nick. Interestingly, assuming Nick meant > that "raise" to be there, PEP 3XX and PEP 343 now have the same > translation. In rev 1.10 I moved the __enter__ call out of the > try-block again. Having it inside was insane: when __enter__ fails, it > should do its own cleanup rather than expecting __exit__ to clean up > after a partial __enter__. Are you sure? The copy I see on python.org still has it inside the try/finally. But yes, the differences between PEP 343 and PEP 3XX [1] are not huge, particularly if __enter__ is called outside the try/finally block. The key difference is whether or not exceptions are injected into the generators internal frame so that templates can be written using the style from PEP 340. > But some of the claims from PEP 3XX seem to be incorrect now: Nick > claims that a with-statement can abstract an except clause, but that's > not the case; an except clause causes the control flow to go forward > (continue after the whole try statement) but the with-statement (with > the "raise" added) always acts like a finally-clause, which implicitly > re-raises the exception. Steven's correct - there's a raise statement missing. The point I'm trying to make in the PEP is that, even without the ability to suppress exceptions, the __exit__() statement can still react to them. Then the only code that needs to be repeated at the calling site is the actual suppression of the exception. Whether doing such a thing makes sense is going to be application dependent, of course. > Anyway, I think we may be really close at this point, if we can agree > on an API for passing exceptions into generators and finalizing them, > so that the generator can be written using a try/finally around the > yield statement. My PEP punts on providing a general API for passing exceptions into generators by making it an internal operation. The version I submitted to the PEP editors uses __enter__() and __exit__() to handle finalisation, though. Cheers, Nick. [1] I finally submitted it to the PEP editors, so it'll be up on python.org as soon as they find the time to check it in. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Paul Moore wrote: > I'm not sure I agree with that - to me, PEP 340 felt like the > consolidation of the previous discussion. My feeling was "cool - we've > had the discussion, now we've formalised the results, maybe a few > details to tidy up and then we can see the implementation being > checked in". Then Nick's proposal *failed* to feel like the tidying up > of the details, and PEP 343 felt like giving up on the powerful (but > hard) bits. It's all people's impressions, though, so maybe I'm just > bitter and cynical :-) Actually, I agree that the early versions of my proposal failed to tidy things up (I was honestly trying - I just didn't succeed). I'm pretty happy with the version I just submitted to the PEP editors, though: http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html It gives generators inherent ``with`` statement support in order to handle finalisation (similar to the way it suggests files support the ``with`` statement in addition to ``for`` loops). An appropriately defined decorator then provides the ability to write ``with`` statement templates using the PEP 340 generator-based style. >>I'd be surprised if you can find many examples that PEP 340 can do >>that PEP 3XX can't. > > In which cask, Nick is "marketing" it really badly - I hadn't got that > impression at all. And if Nick's proposal really *is* PEP 340 with the > issues people had resolved, how come Guido isn't supporting it? I think this is because I've been changing it too fast. This is also the main reason I hadn't submitted before now - *I* wasn't happy with it, so I wanted to keep it easy to update for a while longer. I hope that the version that appears on python.org will garner a bit more support. I submitted it because I finally felt I'd achieved what I set out to do (cleanly integrate PEP 310 and PEP 340), whereas none of my previous drafts felt that way. > Also, the discussion has moved to resource objects with special > methods rather than generators as templates - which I see as a direct > consequence of PEP 342 being excluded. One of the things I really > liked about PEP 340 was the "generator template" style of code, with > yield as the "block goes here" placeolder My PEP suggests simple cases are best handled by __enter__/__exit__ methods directly on the classes (for efficiency, ease of use, and to avoid cluttering the builtin namespace), but more complex cases (like acquiring two locks, or using a particular lock to protect access to a certain file) be handled using PEP 340 style generator templates. > In my view, *every* PEP 340/343/3XX example when written in generator > form counts as a good example (see above). Neat coroutine tricks and > the like are the "additional benefits" - maybe bordering on abuses in > some cases, so I don't want to focus on them in case we get into > arguments about whether a feature is bad simply because it *can* be > abused... But the key use case, for me, *is* the generator-as-template > feature. PEP 342 isn't about the ability to inject exceptions into generators - it's about yield expressions and enhanced continue statements. We haven't actually identified any use cases for those yet (I'm wondering if there is some way to use the idea to implement accumulators, but getting the final result out is a real challenge) PEP 340 and my PEP are the two PEP's which talk about injecting exceptions in order to write nice statement templates. PEP 288 is the one which would make that mechanism available to Python code. > Which is why I regret that Guido didn't just go ahead and implement > it, consensus be damned :-) I vote for a dictatorship :-) Nah, we'll get something good at the end of it anyway - and this way we'll *know* it's good :) >>Ok, back to summarizing this fortnight's 380+ PEP 340 messages. ;-) > > Best of luck - and in case you need a motivation boost, can I just say > that this sort of thread is why I have the greatest respect and > appreciation for the job the summarisers do. Oyah. I had a hard enough time just identifying all the ideas I wanted to discuss in the "Rejected Options" section of my PEP. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tidier Exceptions
On Mon, May 16, 2005, Greg Ewing wrote: > Aahz wrote: >> On Fri, May 13, 2005, Greg Ewing wrote: >>> >>>Instead of an 'args' attribute, I'd suggest that the constructor take >>>keyword arguments and store them in corresponding attributes. >> >> Sounds reasonable, but it should be equally easy to handle:: >> >> raise MyError, "message" > > To be more explicit, the base exception class would > look something like > >class Exception: > > def __init__(self, message = None, **kwds): >self.message = message >self.__dict__.update(kwds) > > def __str__(self): >if self.message is not None: > return self.message >else: > return self.__class__.__name__ That works. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "And if that makes me an elitist...I couldn't be happier." --JMS ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
[Guido]
> > In rev 1.10 I moved the __enter__ call out of the
> > try-block again. Having it inside was insane: when __enter__ fails, it
> > should do its own cleanup rather than expecting __exit__ to clean up
> > after a partial __enter__.
[Ka-Ping Yee]
> No, it wasn't insane. You had a good reason for putting it there.
I did some introspection, and it was definitely a temporary moment of
insanity: (1) I somehow forgot the obvious solution (that __enter__
should clean up its own mess if it doesn't make it to the finish
line); (2) once a generator raises an exception it cannot be resumed,
so the generator-based example I gave can't work. (I was too lazy to
write down the class-based example, which *can* be made to work of
course.)
> The question is what style of implementation you want to encourage.
>
> If you put __enter__ inside, then you encourage idempotent __exit__,
> which makes resource objects easier to reuse.
But consider threading.RLock (a lock with the semantics of Java's
monitors). Its release() is *not* idempotent, so we couldn't use the
shortcut of making __enter__ and __exit__ methods of the lock itself.
(I think this shortcut may be important for locks because it reduces
the overhead of frequent locking -- no extra objects need to be
allocated.)
> If you put __enter__ outside, that allows the trivial case to be
> written a little more simply, but also makes it hard to reuse.
I skimmed your longer post about that but didn't find the conclusive
evidence that this is so; all I saw was a lot of facts ("you can
implement scenario X in these three ways) but no conclusion.
The real reason I put it inside the try was different: there's a race
condition in the VM where it can raise a KeyboardInterrupt after the
__enter__() call completes but before the try-suite is entered, and
then __exit__() is never called. Similarly, if __enter__() is written
in Python and wraps some other operation, it may complete that other
operation but get a KeyboardInterrupt (or other asynchronous
exception) before reaching the (explicit or implicit) return
statement. Ditto for generators and yield.
But I think this can be solved differently in the actual translation
(as opposed to the "translate-to-valid-pre-2.5-Python"); the call to
__exit__ can be implicit in a new opcode, and then we can at least
guarantee that the interpreter doesn't check for interrupts between a
successful __exit__ call and setting up the finally block.
This doesn't handle an __enter__ written in Python not reaching its
return; but in the presence of interrupts I don't think it's possible
to write such code reliably anyway; it should be written using a "with
signal.blocking()" around the critical code including the return.
I don't want to manipulate signals directly in the VM; it's
platform-specific, expensive, rarely needed, and you never know
whether you aren't invoking some Python code that might do I/O, making
the entire thread uninterruptible for a long time.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
At 06:56 PM 5/16/2005 +1000, Nick Coghlan wrote:
>Anyway, I think it's stable enough now that I can submit it to be put up on
>www.python.org (I'll notify the PEP editors directly once I fix a couple of
>errors in the current version - like the missing 'raise' in the statement
>semantics. . .).
If you have developer checkin privileges, it's best to get a PEP number
sooner rather than later, if the PEP shows any signs of viability at
all. Once you're in the PEP infrastructure people can subscribe to get
notified when you change it, read the revision history, and so on.
Anyway, I took a look at it, and I mostly like it. There appears to be an
error in "Deterministic generator finalisation" (maybe you already know
this): the _inject_exception() should be called with exc_info, not
TerminateIteration, and it should swallow StopIteration instead of
TerminateIteration. IOW, I think it should look like this:
def __exit__(self, *exc_info):
try:
self._inject_exception(*exc_info)
except StopIteration:
pass
Hm. Oh wait, I just realized - you don't mean this at all. You're
describing a use of generators as non-templates. Ugh. I think that might
lead to confusion about the semantics of 'with' and generators. I'll have
to think about it some more, but my second impression after a little bit of
thought is that if you're going to do this, then you should be allowed to
use 'with' with any object, using the object as VAR if there's no
__enter__. My reasoning here is that it then makes it possible for you to
use arbitrary objects for 'with' without needing to know their
implementation details. It should be harmless to use 'with' on objects
that don't need it.
This insight may actually be true regardless of what generators do or don't
do; the point is that if you change from using a generator to a built-in
iterator type, you shouldn't have to change every place you were using the
'with' blocks to work again.
A further part of this insight: perhaps the 'with' block translation should
include a 'del VAR' in its finally block, not to mention the equivalent of
'del stmt_enter,stmt_exit'. In other words, the binding of VAR should not
escape the 'with' block. This would mean that for existing types that use
__del__ for cleanup (e.g. files and sockets), then 'with open("file") as f'
would automatically ensure closing under CPython (but other implementations
would be allowed to wait for GC). In other words, I'm saying that this:
with some_expr() as foo:
# etc.
should also be short for this (in the case where some_expr() has no
__enter__ or __exit__ methods):
foo = some_expr()
try:
# etc.
finally:
del foo
And that could be a useful thing for many existing object types, without
even updating them for PEP 34[0-9]. :) It wouldn't be *as* useful for
non-CPython implementations, but presumably by the time those
implementations catch up, more code will be out there with
__enter__/__exit__ methods. Also, by allowing a default __enter__ to exist
(that returns self), many objects need only implement an __exit__. (For
example, I don't see a point to closed file objects raising an error when
used in a 'with' block; if you're actually using the file you'll already
get an error when you use its other methods, and if you're not actually
using it, there's no point to the error, since close() is idempotent.)
So, at the C API level, I'm thinking something like Py_EnterResource(ob),
that returns ob if ob has no tp_resource_enter slot defined, otherwise it
returns the result of calling the method. Similarly, some sort of
Py_ExitResource() that guarantees an error return after invoking the
tp_resource_exit slot (if any).
Finally, note that this extension now makes 'with' seem more like 'with' in
other languages, because it is now just a scoped variable definition, with
hooks for the object being scoped to be notified about entry and exit from
scope. It does mean that people encountering 'with some_expr()' (without
an "as") may wonder about whether names inside the scope are somehow
relative to 'some_expr', but it will probably become clear from context,
especially via appropriate names. For example 'with self.__locked' might
provide that extra bit of clarity beyond 'with self.__lock'.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
At 04:51 PM 5/16/2005 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > This makes it seem awkward for e.g. "do self.__lock", which doesn't
> > make any sense. But the extra call needed to make it "do
> > locking(self.__lock)" seems sort of gratuitous.
>
>How about
>
>do holding(self.__lock):
I simply mean that having to have any wrapper at all for common cases seems
silly.
>It doesn't work so well when you don't already have an
>object with one obvious interpretation of what you want
>to do 'with' it, e.g. you have a pathname and you want
>to open a file.
Um, what's wrong with 'with open("filename") as f'?
> I've already argued against giving file
>objects __enter__ and __exit__ methods. And I'm -42 on
>giving them to strings. :-)
If strings had them, __enter__ would return self, and __exit__ would do
nothing. I fail to see a problem. :)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
At 04:57 PM 5/16/2005 +1200, Greg Ewing wrote: >Guido van Rossum wrote: > > >>Also, one question: will the "do protocol" be added to built-in "resource" > >>types? That is, locks, files, sockets, and so on? > > > > One person proposed that and it was shot down by Greg Ewing. I think > > it's better to require a separate wrapper. > >It depends on whether the resource is "reusable". Why? If "with" is a "scope statement", then it doesn't make any sense to use it with something you intend to reuse later. The statement itself is an assertion that you intend to "release" the resource at the end of the block, for whatever "release" means to that object. Releasing a file is obviously closing it, while releasing a lock is obviously unlocking it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
At 09:53 PM 5/16/2005 +1000, Nick Coghlan wrote: >My PEP punts on providing a general API for passing exceptions into >generators >by making it an internal operation. Actually, the proposals you made almost subsume PEPs 288 and 325. All you'd need to do is: 1. move the '__del__' code to a 'close()' method and make __del__ call close() 2. make '_inject_exception()' a public API that returns the next yielded value if the exception doesn't propagate And just like that you've cleaned up the open issues from both 288 and 325, IIRC those open issues correctly. I personally think that StopIteration, TerminateIteration, KeyboardInterrupt and perhaps certain other exceptions should derive from some base class other than Exception (e.g. Raisable or some such) to help with the bare-except/except Exception problem. But that's probably best addressed by a separate PEP. :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
Nick's PEP 3XX is here:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
[Phillip J. Eby]
> Anyway, I took a look at it, and I mostly like it.
I like the beginning of Nick's PEP too, since its spec for the with
statement is now identical to PEP 343 apart from the keyword choice
(and I'm leaving that open for a public vote). The fundamental
difference now is that Nick proposes an exception injection and
finalization API for generators. I think that ought to be done as a
separate PEP, since it's relatively separate from the
do-or-with-statement (even though it's clear that PEP 343 would be the
first to benefit).
Maybe Nick can strip his PEP (or start a new one) to only addresses
generator exception injection and generator finalization. I think he's
on to something but it needs to be spec'ed more exactly. Continuing
with Phillip...:
> There appears to be an
> error in "Deterministic generator finalisation" (maybe you already know
> this): the _inject_exception() should be called with exc_info, not
> TerminateIteration, and it should swallow StopIteration instead of
> TerminateIteration. IOW, I think it should look like this:
>
> def __exit__(self, *exc_info):
> try:
> self._inject_exception(*exc_info)
> except StopIteration:
> pass
>
> Hm. Oh wait, I just realized - you don't mean this at all. You're
> describing a use of generators as non-templates. Ugh. I think that might
> lead to confusion about the semantics of 'with' and generators. I'll have
> to think about it some more, but my second impression after a little bit of
> thought is that if you're going to do this, then you should be allowed to
> use 'with' with any object, using the object as VAR if there's no
> __enter__. My reasoning here is that it then makes it possible for you to
> use arbitrary objects for 'with' without needing to know their
> implementation details. It should be harmless to use 'with' on objects
> that don't need it.
I think the issue here is not implementation details but whether it
follows a certain protocol. IMO it's totally acceptable to require
that the expression used in a with-statement support an appropriate
protocol, just like we require the expression used in a for-loop to be
an iterable.
> This insight may actually be true regardless of what generators do or don't
> do; the point is that if you change from using a generator to a built-in
> iterator type, you shouldn't have to change every place you were using the
> 'with' blocks to work again.
Huh? The with-statement doesn't loop, and its use of generators is
such that I don't see how you could ever replace it with a built-in
iterator.
> A further part of this insight: perhaps the 'with' block translation should
> include a 'del VAR' in its finally block, not to mention the equivalent of
> 'del stmt_enter,stmt_exit'. In other words, the binding of VAR should not
> escape the 'with' block.
I've seen Nick's stmt_enter and stmt_exit as implementation details
that probably would be done differently by a real implementation;
personally I don't mind getting the TypeError about a missing __exit__
only when __exit__ is called (after all if this happens the program is
too buggy to care much about the precise semantics) so this is what
PEP 343 does.
About deleting VAR I have mixed feelings. I appreciate the observation
that it's most likely dead after the with-statement is over, but I'm
not sure that explicit deletion is correct. Remember that VAR can be
an arbitrary assignment target, which means it could be a global, or a
tuple, or an indexed list or dict item, or some object's attribute (I
hesitate to write "etc." after such an exhaustive list :-). Example 8
in PEP 340 shows a use case where at least one of the variables (the
error value) could meaningfully survive the block. I think that, given
that we let the for-loop variable survive, we should treat the
with-statement variable the same way. A good compiler can see that
it's dead if it's unused further and delete it earlier, but I don't
think we need more -- especially since in a GC'ed implementation like
Jython or IronPython, deleting it doesn't do us much good.
> This would mean that for existing types that use
> __del__ for cleanup (e.g. files and sockets), then 'with open("file") as f'
> would automatically ensure closing under CPython (but other implementations
> would be allowed to wait for GC). In other words, I'm saying that this:
>
> with some_expr() as foo:
> # etc.
>
> should also be short for this (in the case where some_expr() has no
> __enter__ or __exit__ methods):
>
> foo = some_expr()
> try:
> # etc.
> finally:
> del foo
-1 on this. You're trying to pack too much into a single statement.
> And that could be a useful thing for many existing object types, without
> even updating them for PEP 34[0-9]. :) It wouldn't be *as* useful for
> non-CPython implementations, but
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Greg Ewing wrote: > Brett C. wrote: > > >>Nick's was obviously directly against looping, but, with no offense to Nick, >>how many other people were against it looping? It never felt like it was a >>screaming mass with pitchforks but more of a "I don't love it, but I can deal" >>crowd. > > > My problem with looping was that, with it, the semantics > of a block statement would be almost, but not quite, > exactly like those of a for-loop, which seems to be > flying in the face of TOOWTDI. And if it weren't for > the can't-finalise-generators-in-a-for-loop backward > compatibility problem, the difference would be even > smaller. I wonder if we should reconsider PEP 340, with one change: the block iterator is required to iterate exactly once. If it iterates more than once or not at all, the interpreter raises a RuntimeError, indicating the iterator can not be used as a block template. With that change, 'break' and 'continue' will obviously affect 'for' and 'while' loops rather than block statements. Advantages of PEP 340, with this change, over PEP 343: - we reuse a protocol rather than invent a new protocol. - decorators aren't necessary. - it's a step toward more general flow control macros. At first I wasn't sure people would like the idea of requiring iterators to iterate exactly once, but I just realized the other PEPs have the same requirement. Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
[Guido (responding to Fredrik Lundh's "intuitive -1" on PEP 343)] > > Would it be better if we pulled back in the generator exit handling > > from PEP 340? That's a pretty self-contained thing, and would let you > > write try/finally around the yield. [Nick Coghlan] > That would be good, in my opinion. I updated PEP 3XX to use this idea: > http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html > > With that update (to version 1.6), PEP 3XX is basically PEP 343, but injecting > exceptions that occur into the template generator's internal frame instead of > invoking next(). I'm in favor of the general idea, but would like to separate the error injection and finalization API for generators into a separate PEP, which would then compete with PEP 288 and PEP 325. I think the API *should* be made public if it is available internally; I don't see any implementation reasons why it would simplify the implementation if it was only available internally. Here are some issues to resolve in such a PEP. - What does _inject_exception() return? It seems that it should raise the exception that was passed into it, but I can't find this written out explicitly. - What should happen if a generator, in a finally or except clause reached from _inject_exception(), executes another yield? I'm tempted to make this a legitimate outcome (from the generator's perspective) and reserve it for some future statement that implements the looping semantics of PEP 340; the *_template decorator's wrapper class however should consider it an error, just like other protocol mismatches like not yielding the first time or yielding more than once in response to next(). Nick's code in fact does all this right, Ijust think it should be made explicit. - TerminateIteration is a lousy name, since "terminate" means about the same as "stop", so there could be legitimate confusion with StopIteration. In PEP 340 I used StopIteration for this purpose, but someone explained this was a poor choice since existing generators may contain code that traps StopIteration for other purposes. Perhaps we could use SystemExit for this purpose? Pretty much everybody is supposed to let this one pass through since its purpose is only to allow cleanup upon program (or thread) exit. - I really don't like reusing __del__ as the method name for any kind of destructor; __del__ has all sorts of special semantics (the GC treats objects with a __del__ method specially). - The all_lines() example jars me. Somehow it bugs me that its caller has to remember to care about finalizing it. Maybe it's just not a good example; I don't see what this offers over just writing the obviously correct: for fn in filenames: with opening(fn) as f: for line in f: update_config(line) even if using the template saves a line. I doubt the use case comes up frequently enough to warrant abstracting it out. If I have to import the template to save a line here, I just made my program a bit less readable (since the first-time reader has to look up the definition of the imported all_lines template) and I didn't even save a line unless the template is used at least twice. (Note that Nick's PEP contains two typos here -- it says "print lines" where it should say "print line" and a bit later "print f" where again it should say "print line".) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)
At 11:20 AM 5/16/2005 -0700, Guido van Rossum wrote:
>I think the issue here is not implementation details but whether it
>follows a certain protocol. IMO it's totally acceptable to require
>that the expression used in a with-statement support an appropriate
>protocol, just like we require the expression used in a for-loop to be
>an iterable.
Perhaps I didn't explain well. I mean that whether early release of a
resource is desirable, depends on the resource. For example, consider a
file versus a StringIO. If files support resource release and StringIO's
don't, this pollutes client code with implementation knowledge.
Therefore, the penalty for people trying to clean up resources early is
that they either pollute their client code with checking to see if things
are 'with'-able (which seems insane), or else adding empty __enter__ and
__exit__ methods to things so that their consumers can just use "with"
whenever they want to scope a resource, whether the resource actually needs
it or not.
I'm suggesting that we simply take Nick's proposal to its logical
conclusion, and allow any object to be usable under "with", since it does
not create any problems to do so. (At least, none that I can see.) A
redundant 'with' does no harm; in the worst case it's just a hint to the
reader about the scope within which an expression is used within the
current fuction body.
> > This insight may actually be true regardless of what generators do or don't
> > do; the point is that if you change from using a generator to a built-in
> > iterator type, you shouldn't have to change every place you were using the
> > 'with' blocks to work again.
>
>Huh? The with-statement doesn't loop, and its use of generators is
>such that I don't see how you could ever replace it with a built-in
>iterator.
I'm referring here to Nick's proposal of doing things like this:
with some_function() as items:
for item in items:
# etc.
To ensure that a *normal* generator is finalized. This isn't about
generator templates. So, if you were ever to change 'some_function()' to
return a list instead of being a generator, for example, this code would no
longer work.
>About deleting VAR I have mixed feelings. I appreciate the observation
>that it's most likely dead after the with-statement is over, but I'm
>not sure that explicit deletion is correct. Remember that VAR can be
>an arbitrary assignment target, which means it could be a global, or a
>tuple, or an indexed list or dict item, or some object's attribute (I
>hesitate to write "etc." after such an exhaustive list :-).
Argh. I forgot about that. :( On the other hand, I haven't seen any
examples where arbitrary assignment targets were actually used, so perhaps
it could be limited to local variables (and possibly-nested tuples
thereof). But I also partly agree with the false-sense-of-security thing,
too, so I'm not sure on this either now that you point out the issue. It
also makes me wonder about something like this:
with open("foo") as f:
def callback():
return f.read()
which can't behave sanely if 'callback' is used outside the 'with'
block. Of course, it won't work right even if 'f' remains bound to the
file object, but this does seem to open new implementation complexities to
get all these pieces to work right. :(
> > should also be short for this (in the case where some_expr() has no
> > __enter__ or __exit__ methods):
> >
> > foo = some_expr()
> > try:
> > # etc.
> > finally:
> > del foo
>
>-1 on this. You're trying to pack too much into a single statement.
Note that I was just leaving out the rest of the standard PEP 3XX expansion
above, just highlighting the proposed 'del' portion of the expansion. That
is, I wasn't proposing an alternate expansion, just showing the effect of
the other parts of the expansion being skipped because of null
__enter__/__exit__.
> > And that could be a useful thing for many existing object types, without
> > even updating them for PEP 34[0-9]. :) It wouldn't be *as* useful for
> > non-CPython implementations, but presumably by the time those
> > implementations catch up, more code will be out there with
> > __enter__/__exit__ methods.
>
>Most likely it would just give an implementation-dependent false sense
>of security.
I think I prefer to see the glass half-full here; that is, I think it
increases the safety during a transitional period. But the scoping of
arbitrary VAR expansions makes things trickier, so I'll think about this
some more.
>-1 on the whole thing (and noting that this would be an easy extension
>if at some point in the future we change our mind).
Your post has made me think that I might have the concept
backwards. Instead of guaranteeing that the variable goes out of scope at
the end of the block, what a 'with' block actually guarantees (implicit in
all of the PEP 34x variants) is that EXPR will
[Python-Dev] RFC: rewrite fileinput module to use itertools.
Hi there, Before charging on ahead with this small task, I was wondering if anyone would have any objections to such an upgrade. It seems to me that itertools.chain() could come in handy there, at least. My only objection to the current implementation is that it doesn't reflect the current Python "best practice" for what it does, and it could be really simply made into a live demo of the itertools module. David. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
This PEP is a concrete proposal for exception chaining, to follow up on its mention here on Python-Dev last week as well as earlier discussions in the past year or two. http://www.python.org/peps/pep-0344.html I've tried to summarize the applications for chaining mentioned in these discussions, survey what's available in other languages, and come up with a precise specification. PEP 344 proposes three standard attributes on traceback objects: __context__ for implicit chaining (an unexpected exception occurred during 'except' or 'finally' processing) __cause__ for explicit chaining (intentional translation or augmenting of exceptions, set by "raise EXC from CAUSE") __traceback__ to point to the traceback Hope this is useful. I'd like your feedback. Thanks! -- Ping ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
On Mon, May 16, 2005, Ka-Ping Yee wrote: > > This PEP is a concrete proposal for exception chaining, to follow > up on its mention here on Python-Dev last week as well as earlier > discussions in the past year or two. > > http://www.python.org/peps/pep-0344.html > > I've tried to summarize the applications for chaining mentioned in > these discussions, survey what's available in other languages, and > come up with a precise specification. > > PEP 344 proposes three standard attributes on traceback objects: > > __context__ for implicit chaining (an unexpected exception > occurred during 'except' or 'finally' processing) > > __cause__ for explicit chaining (intentional translation or > augmenting of exceptions, set by "raise EXC from CAUSE") > > __traceback__ to point to the traceback > > Hope this is useful. I'd like your feedback. Thanks! I'll comment here in hopes of staving off responses from multiple people: I don't think these should be double-underscore attributes. The currently undocumented ``args`` attribute isn't double-underscore, and I think that's precedent to be followed. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "And if that makes me an elitist...I couldn't be happier." --JMS ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
In article <[EMAIL PROTECTED]>, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >... > I personally think that StopIteration, TerminateIteration, > KeyboardInterrupt and perhaps certain other exceptions should derive from > some base class other than Exception (e.g. Raisable or some such) to help > with the bare-except/except Exception problem. But that's probably best > addressed by a separate PEP. :) Yes, please!!! I am so sick of writing: except (SystemExit, KeyboardInterrupt): raise except Exception, e: # handle a "real" error but back to lurking on this discussion... -- Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: rewrite fileinput module to use itertools.
David M. Wilson wrote: > Before charging on ahead with this small task, I was wondering if anyone > would have any objections to such an upgrade. It seems to me that > itertools.chain() could come in handy there, at least. > > My only objection to the current implementation is that it doesn't > reflect the current Python "best practice" for what it does, and it > could be really simply made into a live demo of the itertools module. I personally would not care, but if you have fun doing that, go ahead. The major requirement would be that the result is 100% (better 150%) compatible with the old code, even in border cases. I don't know whether this is possible at all, from experience, I would guess that there is a significant chance of breaking something. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
[Ka-Ping Yee] > This PEP is a concrete proposal for exception chaining, to follow > up on its mention here on Python-Dev last week as well as earlier > discussions in the past year or two. > > http://www.python.org/peps/pep-0344.html Here's a bunch of commentary: You're not giving enough credit to Java, which has the "cause" part nailed IMO. I like the motivation and rationale, but I think the spec is weak and would benefit from a better understanding of how exception handling currently works. In particular, please read and understand the comment in ceval.c starting with this line: /* Implementation notes for set_exc_info() and reset_exc_info(): There's too much text devoted early on to examples. I think these should come at the end; in particular, hiding the proposed semantics at the very end of a section that otherwise contains only illustrative examples is a bad idea (especially since the examples are easy enough to guess, if you've read the rationale). I don't think the PEP adequately predicts what should happen in this example: def foo(): try: 1/0 # raises ZeroDivisionError except: bar() raise sys.does_not_exist # raises AttributeError def bar(): try: 1+"" # raises TypeError except TypeError: pass Intuitively, the AttributeError should have the ZeroDivisionError as its __context__, but I think the clearing of the thread's exception context when the except clause in bar() is left will drop the exception context. If you follow the save/restore semantics described in that ceval.c comment referenced above, you'll get the correct semantics, I believe. Also, in that same example, according to your specs, the TypeError raised by bar() has the ZeroDivisionError raised in foo() as its context. Do we really want this? I still have the feeling that perhaps the context ought to be attached later, e.g. only when an exception "passes through" a frame that happens to be handling an exception already (whether in an except clause or in a finally clause). When chaining exceptions, I think it should be an error if the cause is not an exception instance (or None). Yes, this will just substitute a different exception, but I still think it's the right thing to do -- otherwise code walking the chain of causes must be constantly aware of this possibility, and since during normal use it will never happen, that would be a great way to trip it up (perhaps even to cause a circularity!). Do we really need both __context__ and __cause__? Methinks that you only ever need one: either you explicitly chain a new exception to a cause, and then the context is probably the same or irrelevant, or you don't explicitly chain, and then cause is absent. Since the traceback printing code is to prefer __cause__ over __context__, why can't we unify these? About the only reason I can think of is that with __cause__ you know it was intentional and with __context__ you know it wasn't; but when is it important knowing the difference? Do we really need new syntax to set __cause__? Java does this without syntax by having a standard API initCause() (as well as constructors taking a cause as argument; I understand why you don't want to rely on that -- neither does Java). That seems more general because it can be used outside the context of a raise statement. Why insert a blank line between chained tracebacks? In Java, I often find the way chained tracebacks are printed confusing, because the "deepest" stack frame (where the exception originally occurred) is no longer at the top of the printout. I expect the same confusion to happen for Python, since it prints everything in the exact opposite order as Java does, so again the original exception is somewhere in the middle. I don't think I want to fix this by printing the outermost exception first and the chained exception later (which would keep the stack frames in their proper order but emphasizes the low-level exception rather than the one that matches the except clause that would have caught it at the outermost level), but I might want to add an extra line at the very end (and perhaps at each chaining point) warning the user that the exception has a chained counterpart that was printed earlier. Why should the C level APIs not automatically set __context__? (There may be an obvious reason but it doesn't hurt stating it.) You're unclear on how the C code should be modified to ensure that the proper calls to PyErr_SetContext() are made. I was surprised to learn that yield clears the exception state; I wonder if this isn't a bug in the generator implementation? IMO better semantics would be for the exception state to survive across yield. You should at least mention what should happen to string exceptions, even if (as I presume) the only sane approach is not to support this for string exceptions (a string exception may be the end of the chain, but it cannot have a
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
Guido van Rossum wrote: [SNIP - bunch of points from Guido] > Do we really need both __context__ and __cause__? Methinks that you > only ever need one: either you explicitly chain a new exception to a > cause, and then the context is probably the same or irrelevant, or you > don't explicitly chain, and then cause is absent. Since the traceback > printing code is to prefer __cause__ over __context__, why can't we > unify these? About the only reason I can think of is that with > __cause__ you know it was intentional and with __context__ you know it > wasn't; but when is it important knowing the difference? > I am with Guido. I don't think the need to know if an exception was chained explicitly or implicitly will be important enough to warrant a separate attribute. And if people care that much that can tack on a random attribute like explicit_chain or something to the exception on their own. [SNIP] > In Java, I often find the way chained tracebacks are printed > confusing, because the "deepest" stack frame (where the exception > originally occurred) is no longer at the top of the printout. I > expect the same confusion to happen for Python, since it prints > everything in the exact opposite order as Java does, so again the > original exception is somewhere in the middle. I don't think I want > to fix this by printing the outermost exception first and the chained > exception later (which would keep the stack frames in their proper > order but emphasizes the low-level exception rather than the one that > matches the except clause that would have caught it at the outermost > level), but I might want to add an extra line at the very end (and > perhaps at each chaining point) warning the user that the exception > has a chained counterpart that was printed earlier. > Just a simple "[chained exception]" note or something? Sounds good. [SNIP] > You should probably reference the proposal (pending a PEP; I think > Brett is working on it?) My plan is to write the "Exceptions in Python 3000" PEP shortly after I start my internship. Going to put that at a higher priority than the AST branch to make sure I get to it some time before I leave the country. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
[Ron Adam] > So I was wondering if something like the following is feasible? > [...] > > with opening(file1,m),opening(file2,m),opening(file3,m) as f1,f2,f3: > # do stuff with files > > The 'with' (or whatever) statement would need a little more under the > hood, but it might simplify handling multiple resources. > > This also reduces nesting in cases such as locking and opening. Both > must succeed before the block executes. And if something goes wrong, the > "with" statement knows and can handle each resource. The point is, each > resource needs to be a whole unit, opening multiple files in one > resource handler is probably not a good idea anyway. I'm -0 on this, if only because it complicates things a fair bit for a very minor improvement in functionality. There are also some semantic/syntactic questions: should this work only if there are explicit commas in the with-statement (so the compiler can generate code equivalent to nested with-statements) or should it allow a single expression to return a tuple of resource managers dynamically (so the run-time must check fora tuple each time)? It's always something we can add in the future, since it's guaranteed that this syntax (or a tuple value) is invalid in the curernt proposal. So I'd rather punt on this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
On Mon, May 16, 2005 at 06:24:59PM +1200, Greg Ewing wrote: > Brett C. wrote: > > > Nick's was obviously directly against looping, but, with no offense to Nick, > > how many other people were against it looping? It never felt like it was a > > screaming mass with pitchforks but more of a "I don't love it, but I can > > deal" > > crowd. > > My problem with looping was that, with it, the semantics > of a block statement would be almost, but not quite, > exactly like those of a for-loop, which seems to be > flying in the face of TOOWTDI. And if it weren't for > the can't-finalise-generators-in-a-for-loop backward > compatibility problem, the difference would be even > smaller. Nodders, the looping construct seemed to work out fine as code people could use to get their heads around the idea. It was eye-gougingly bad as final solution. Forcing people to write an iterator for something that will almost never loop is as awkward as forcing everyone to write "if" statements as for dummy in range(1): if (somevar): do_true_stuff() break else: do_false_stuff() I still haven't gotten used to Guido's heart-attack inducing early enthusiasm for strange things followed later by a simple proclamation I like. Some day I'll learn that the sound of fingernails on the chalkboard is frequently followed by candy for the whole class. For now the initial stages still give me the shivers. -jackdied ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
At 08:21 PM 5/16/2005 -0400, Jack Diederich wrote: >I still haven't gotten used to Guido's heart-attack inducing early >enthusiasm for strange things followed later by a simple proclamation >I like. Some day I'll learn that the sound of fingernails on the >chalkboard is frequently followed by candy for the whole class. Heh. +1 for QOTW. :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
On Mon, 16 May 2005, Aahz wrote: > I'll comment here in hopes of staving off responses from multiple > people: I don't think these should be double-underscore attributes. The > currently undocumented ``args`` attribute isn't double-underscore, and I > think that's precedent to be followed. That isn't the criterion i'm using, though. Here's my criterion, and maybe then we can talk about what the right criterion should be: System attributes are for protocols defined by the language. (I'm using the term "system attribute" here to mean "an attribute with a double-underscore name", which i picked up from something Guido wrote a while back [1].) For example, __init__, __add__, __file__, __name__, etc. are all attributes whose meaning is defined by the language itself as opposed to the Python library. A good indicator of this is the fact that their names are hardcoded into the Python VM. I reasoned that __cause__, __context__, and __traceback__ should also be system attributes since their meaning is defined by Python. Exceptions are just classes; they're intended to be extended in arbitrary application-specific ways. It seemed a good idea to leave that namespace open. -- ?!ng [1] http://mail.python.org/pipermail/python-dev/2003-June/036239.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
On Mon, May 16, 2005 at 08:09:54PM -0500, Ka-Ping Yee wrote: > On Mon, 16 May 2005, Aahz wrote: > > I'll comment here in hopes of staving off responses from multiple > > people: I don't think these should be double-underscore attributes. The > > currently undocumented ``args`` attribute isn't double-underscore, and I > > think that's precedent to be followed. > > That isn't the criterion i'm using, though. Here's my criterion, and > maybe then we can talk about what the right criterion should be: > > System attributes are for protocols defined by the language. > > (I'm using the term "system attribute" here to mean "an attribute with > a double-underscore name", which i picked up from something Guido > wrote a while back [1].) > > For example, __init__, __add__, __file__, __name__, etc. are all > attributes whose meaning is defined by the language itself as opposed > to the Python library. A good indicator of this is the fact that > their names are hardcoded into the Python VM. I reasoned that > __cause__, __context__, and __traceback__ should also be system > attributes since their meaning is defined by Python. > > Exceptions are just classes; they're intended to be extended in > arbitrary application-specific ways. It seemed a good idea to leave > that namespace open. I prefer trichomomies over dichotomies, but whether single or double underscores are "the bad" or "the ugly" I'll leave to others. In python double underscores can only mean "I don't handle this, my class does" or "I'm a C++ weenie, can I pretend this is private?" Excluding the "private" non-argument the only question is where it goes in the class hierarchy. Is it a property you would normally associate with the instance, the class of an instance, or the class of a class (type). To me it feels like a property of the instance. The values are never shared by expections of the class so just make it a plain variable to remind other people of that too. -jackdied ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
On Mon, May 16, 2005 at 10:11:47PM -0400, Jack Diederich wrote: > The values are never shared by expections of the class ^^ s/expect/except/ Exceptions are expected by except statements - and ispell can't tell the difference. -jackdied ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Guido van Rossum wrote: > [Ron Adam] > >>with opening(file1,m),opening(file2,m),opening(file3,m) as f1,f2,f3: >> # do stuff with files >> > > I'm -0 on this, if only because it complicates things a fair bit for a > very minor improvement in functionality. [...] > It's always something we can add in the future, since it's guaranteed > that this syntax (or a tuple value) is invalid in the curernt > proposal. So I'd rather punt on this. Also, you can already get 90% of this with the combining() wrapper I posted earlier. with combining(opening(file1,m),opening(file2,m),opening(file3,m) ) as f1,f2,f3: # do stuff with files Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Phillip J. Eby wrote: > Why? If "with" is a "scope statement", then it doesn't make any sense > to use it with something you intend to reuse later. The statement > itself is an assertion that you intend to "release" the resource at the > end of the block, for whatever "release" means to that object. > Releasing a file is obviously closing it, while releasing a lock is > obviously unlocking it. I've stopped arguing against giving with-protocol methods to files, etc., since it was pointed out that you'll get an exception if you try to re-use one. I still think it's conceptually cleaner if the object you use to access the resource is created by the __enter__ method rather than being something pre- existing, but I'm willing to concede that PBP here. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks
[Jack Diederich] > I prefer trichomomies over dichotomies, but whether single or double > underscores are "the bad" or "the ugly" I'll leave to others. In python > double underscores can only mean "I don't handle this, my class does" or > "I'm a C++ weenie, can I pretend this is private?" > > Excluding the "private" non-argument the only question is where it goes > in the class hierarchy. Is it a property you would normally associate > with the instance, the class of an instance, or the class of a class (type). > > To me it feels like a property of the instance. The values are never > shared by expections of the class so just make it a plain variable to remind > other people of that too. Can't tell if you're just trying to be funny, but that sounds like nothing remotely like the rule I use in my head to decide whether to make something a system attribute or a regular attribute. My rule has more to do with who "owns" the namespace on the one hand, and with "magic" behavior caused (or indicated) by the presence of the attribute on the other. Class or instance is irrelevant; that most magic attributes live on classes or modules is just because those are places where most of the magic is concentrated. __init__ in a class is a system attribute because it has a magic meaning (invoked automatically on instantiation). __file__ and __name__ in a module (and __module__ and __name__ in a class!) are system attributes because they are "imposing" on the user's use of the namespace. (Note: next was a mistake; it should have been __next__ because of the "magic" rule.) Unfortunately I can't quite decide whether either rule applies in the case of exceptions. I think it's totally plausible to say "all exceptions derive from Throwable, which predefines the following attributes: traceback, cause". OTOH making them system attributes is more backwards compatible. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
[Greg Ewing] > I've stopped arguing against giving with-protocol > methods to files, etc., since it was pointed out that > you'll get an exception if you try to re-use one. > > I still think it's conceptually cleaner if the object > you use to access the resource is created by the > __enter__ method rather than being something pre- > existing, but I'm willing to concede that PBP here. PBP? Google finds "Python Browser Poseur" but no definition of IRC slang. Proven Best Practice? Pakistani Border Patrol? Puffing Billy Posse? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
