There's a thread on c.l.py at the moment (Controlling a generator the
pythonic way) which is basically coming up with PEP 342. I've pointed
them to PEP 342, but it's made me think that the name of the PEP could
better indicate what it does.
I propose Coroutines via Enhanced Iterators.
Tim
Phillip J. Eby wrote:
That's not a bug, it's a feature. If the object doesn't have a
'close()'
method, clearly it doesn't need to be closed. If it's the wrong
object
for what you're using it for in the body of the 'with' block, it'll
show up
there, so this doesn't hide any errors.
James Y Knight wrote:
Of course you can already do similar with current python, it just
can't be spelled as nicely, and the default traceback printer won't
use the info:
try:
raise AError
except:
newException = BError()
newException.cause=sys.exc_info()
raise newException
Greg Ewing wrote:
Nick Coghlan wrote:
Hmm, with that approach, a code inspection tool like pychecker could
be used to pick up the slack, and flag generators which have a yield
inside a try/finally or a user defined statement without applying
the needs finalisation decorator
What about
Greg Ewing wrote:
I'm still bothered by the idea of for-loops not participating
in the new generator finalization protocol.
I agree - that's always been nagging at me too.
The problem with it is that then you either:
1. Have a guarantee that an iterator will be exhausted when the for loop
Nick Coghlan wrote:
Ah, someone else did post this idea first :)
I knew I was standing on the shoulders of others :)
To deal with the generator issue, one option would be to follow up on
Phillip's idea of a decorator to convert a generator (or perhaps any
standard iterator) into a block
Guido van Rossum wrote:
I'd like the block statement to be defined exclusively in terms of
__exit__() though.
This does actually suggest something to me (note - just a thought - no
real idea if it's got any merit).
Are there any use cases proposed for the block-statement (excluding the
Delaney, Timothy C (Timothy) wrote:
Guido van Rossum wrote:
I'd like the block statement to be defined exclusively in terms of
__exit__() though.
1. If an iterator declares __exit__, it cannot be used in a for-loop.
For-loops do not guarantee resource cleanup.
2. If an iterator
Phillip J. Eby wrote:
Specifically, I propose that PEP 340 *not* allow the use of normal
iterators. Instead, the __next__ and __exit__ methods would be an
unrelated protocol. This would eliminate the need for a 'next()'
builtin,
and avoid any confusion between today's iterators and a
Guido van Rossum wrote:
Oops. Read the most recent version of the PEP again. __next__()
doesn't take an exception argument, it only takes a value. Maybe this
removes your concern?
Actually, I misinterpreted it, assuming that the value passed in was an
exception instance because the previous
Nick Coghlan wrote:
# A decorator that does not alter its argument
def register(callable):
# Register the callable somewhere
...
return callable
# Decorated factory function
@register
def factory():
pass
# Post-decorated class
class factory:
Jeff Bauer wrote:
I'm not specifically lobbying for its inclusion in
stdlib, but I often find an ordered dict useful when I
want both ordered and random access, e.g. situations:
- database table fields/attributes
- drop down field selectors
Yep - these are also cases that are
Steven Bethard wrote:
def filterdups(iterable):
seen = set()
for item in iterable:
if item not in seen:
seen.add(item)
yield item
Adding this to, say, itertools would cover all my use cases. And as
long as you don't have too many duplicates,
Greg Ward wrote:
I'll attach another approach to the same problem, an ordered
dictionary object. I believe the semantics of
adding/readding/deleting keys is the same as java.util.LinkedHashMap
-- certainly it seems the most sensible and easy-to-implement
semantics.
That's essentially the
Guido van Rossum wrote:
Keeping im_class would be tricky -- the information isn't easily
available when the function is defined, and adding it would require
changing unrelated code that the patch so far didn't have to get near.
Also, it would not be compatible -- the unbound method sets
Guido van Rossum wrote:
and the cumbersome way in which you have to invoke super.
Given Python's dynamic nature I couldn't think of a way to make it
less cumbersome. I see you tried (see below) and couldn't either. At
this point I tend to say put up or shut up.
Well, there's my autosuper
While grabbing the link to the copyright restrictions FAQ (for someone
on python-list) I noticed a few out-of-date FAQ entries - specifically,
most stable version and Why doesn't list.sort() return the sorted
list?. Bug reports have been submitted (and acted on - Raymond, you
work too fast ;)
I
Martin v. Löwis wrote:
Not at all. I'm talking about the release process, and prerequisites
required in that process. This is worth mentioning because the list
of prerequisites you need to perform a Python release is already quite
long:
Ah - sorry - misinterpreted.
What is the size of the
Adam Bark wrote:
Now this might sound a bit stupid but I've only been programming in
python for about 6 months and before that about the same on VB. Anyway
here goes, as python is built in C C++ surely every piece of python
code has a corresponding piece of C/C++ albeit more complex. So
19 matches
Mail list logo
