[Python-Dev] (no subject)
hello all I am a member of a team dedicated to make a client server database application and our main concern is the speed with which the system performs. we are very new to python. but after reading a lot of documents and consulting some experts we decided to work it out using PYTHON. we plan to make 2 programs one running in the client systems and one that run in server. can any one please help me by telling the thins that i should take care of while designing the project and what tools and what style we should adopt to make the program optimised. regards ___ 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: Else clause for block statements
GvR wrote:
> [Nick Coghlan]
> > Option 2: mimic if semantics
> >An 'else' clause on a block statement behaves vaguely like the else
clause on
> > an if statement - the clause is executed only if the first suite is
never
> > entered, but no exception occurs (i.e. StopIteration is raised by the
first call
> > to next).
>
> Strange because it's different from the behavior of a for loop, and
> the block-statement doesn't feel like an if-statement at all. But I
> could actually imagine a use case: when acquiring a lock with a
> time-out, the else-clause could be executed when the acquisition times
> out.
>
> block locking(myLock, timeout=30):
> ...code executed with lock held...
> else:
> ...code executed if lock not acquired...
A file-closing block function has the same need, as does any block
function that manages a resource, whose acquisition might fail.
A surrounding try/except doesn't quite cut it; the problem is that the
try-clause will then also cover the suite.
Example:
try:
in opening('file1') as f1:
...
in opening('file2') as f2:
...
except IOError:
print "file1 not available, I'll try again later"
How do I tell try/except that I really only meant to trap
opening('file1'), but opening 'file2' is not supposed to fail so I
want any exception from that propagated? Better if I could write:
in opening('file1') as f1:
...
in opening('file2') as f2:
...
else:
print "file1 not available, I'll try again later"
or even
in opening('file1') as f1:
...
in opening('file2') as f2:
...
except IOError:
print "file1 not available, I'll try again later"
I rather like this version, because it is patently clear what should
happen if there is no except-clause: The exception propagates
normally.
- Anders
___
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] (no subject)
Hi Rijish- The python-dev list is for developers *of* python, not for people developing *with* python. I'd recommend you post this on the python-list, but I see you already have. You'll find they can be very helpful, if you show that you've done some research, and ask a specific question. A subject line always helps, too. Good luck with your project! -John * rijish valoorthodi rajan <[EMAIL PROTECTED]> [2005-05-02 00:29]: > > hello all > I am a member of a team dedicated to make a client server database > application and our main concern is the speed with which the system performs. > we are very new to python. but after reading a lot of documents and > consulting some experts we decided to work it out using PYTHON. we plan to > make 2 programs one running in the client systems and one that run in server. > can any one please help me by telling the thins that i should take care of > while designing the project and what tools and what style we should adopt to > make the program optimised. > > regards ___ 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: Else clause for block statements
Anders J. Munch wrote:
> in opening('file1') as f1:
> ...
> in opening('file2') as f2:
> ...
> except IOError:
> print "file1 not available, I'll try again later"
>
> I rather like this version, because it is patently clear what should
> happen if there is no except-clause: The exception propagates
> normally.
My eyes would expect the exception handler to also catch IOErrors
generated inside the block statement body. My eyes would be deceiving
me, of course, but Python isn't currently so subtle and it probably
shouldn't be.
You could also do this with a suitable iterator.
def opening_or_skipping(fn):
try:
f = open(fn)
except IOError:
print "file1 not available, I'll try again later"
else:
try:
yield f
finally:
f.close()
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 340: Else clause for block statements
Anders> How do I tell try/except that I really only meant to trap
Anders> opening('file1'), but opening 'file2' is not supposed to fail so
Anders> I want any exception from that propagated? Better if I could
Anders> write:
Anders> in opening('file1') as f1:
Anders> ...
Anders> in opening('file2') as f2:
Anders> ...
Anders> else:
Anders> print "file1 not available, I'll try again later"
-1. This has the opposite meaning of the else clause in while/for
statements.
Anders> or even
Anders> in opening('file1') as f1:
Anders> ...
Anders> in opening('file2') as f2:
Anders> ...
Anders> except IOError:
Anders> print "file1 not available, I'll try again later"
Not keen on this either, maybe just because the "in" clause isn't a "try"
clause.
Skip
___
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: Else clause for block statements
On Mon, 02 May 2005 07:46:31 -0600, Shane Hathaway <[EMAIL PROTECTED]> wrote:
>Anders J. Munch wrote:
>> in opening('file1') as f1:
>> ...
>> in opening('file2') as f2:
>> ...
>> except IOError:
>> print "file1 not available, I'll try again later"
>>
>> I rather like this version, because it is patently clear what should
>> happen if there is no except-clause: The exception propagates
>> normally.
>
>My eyes would expect the exception handler to also catch IOErrors
>generated inside the block statement body. My eyes would be deceiving
>me, of course, but Python isn't currently so subtle and it probably
>shouldn't be.
>
>You could also do this with a suitable iterator.
>
>def opening_or_skipping(fn):
>try:
>f = open(fn)
>except IOError:
>print "file1 not available, I'll try again later"
>else:
>try:
>yield f
>finally:
>f.close()
I don't think this version is really of much use. It requires that you
implement a different iterator for each kind of error handling you want to do.
Avoiding multiple different implementations is supposed to be one of the main
selling points of this feature.
Jp
___
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 - possible new name for block-statement
On 4/29/05, Reinhold Birkenfeld wrote: > Date: Sat, 30 Apr 2005 00:53:12 +0200 > From: Reinhold Birkenfeld <[EMAIL PROTECTED]> > Subject: [Python-Dev] Re: PEP 340 - possible new name for >block-statement > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > > FWIW, the first association when seeing > > block something: > > is with the verb "to block", and not with the noun, which is most displeasing. > > Reinhold > Which is the reason I thought of "bracket" instead. Although it's also a noun and a verb, the verb doesn't imply "stop" like block does. However, because one of the main features of python is that it's easy to read, adding "with" to it makes it very clear as in "bracket_with". Ugly at first, but that's just a matter of familiarity. You never notice that your ugly friend is really that ugly anymore, right? bracket_with foo(arg1, arg2) as f: BLOCK seems very explicit to me. However, I do prefer no keyword at all and that would be my first choice, but if we have to choose a keyword, "block" has that "stop" connotation that will certainly confuse more than a few but I doubt people would go with "bracket_with." I certainly hope no-keyword is possible. -- Luis P Caamano Atlanta, GA USA ___ 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: Else clause for block statements
[Guido, prsenting a use case]
> > block locking(myLock, timeout=30):
> > ...code executed with lock held...
> > else:
> > ...code executed if lock not acquired...
[Anders Munch]
> A file-closing block function has the same need, as does any block
> function that manages a resource, whose acquisition might fail.
>
> A surrounding try/except doesn't quite cut it; the problem is that the
> try-clause will then also cover the suite.
>
> Example:
>
> try:
> in opening('file1') as f1:
> ...
> in opening('file2') as f2:
> ...
> except IOError:
> print "file1 not available, I'll try again later"
I thought of this and several other solutions overnight and didn't lik
any. Finally I realized that this use case is better covered by
letting the generator return an error value:
def opening_w_err(filename):
try:
f = open(filename)
except IOError, err:
yield None, err
else:
try:
yield f, None
finally:
f.close()
The user can then write:
block opening_w_err(filename) as f, err:
if f:
...code using f...
else:
...error handling code using err...
Besides, in many cases it's totally acceptable to put a try/except
block around the entire block-statement, if the exception it catches
is specific enough (like IOError). For example:
try:
block opening(filename) as f:
...code using f...
except IOError, err:
...error handling code using err...
So I'm more than ever in favor of keeping the block-statement simple,
i.e. without any additional clauses.
--
--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] Generating nested data structures with blocks
Reading PEP 340, it seems to me that blocks could be used for generating nested data structures: def blist(list): def enter(parent=None): if parent: parent.append(self) yield self x = blist() block x.enter() as x: x.append(1) block blist().enter(x) as x: x.append(2) x.append(3) print x this should print [1, [2], 3] For this to work, the scope of the block variable has to end with the end of the block. Currently the PEP leaves this unspecified. Bye, Walter Dörwald ___ 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] Generating nested data structures with blocks
Walter Dörwald wrote: > [...] > def blist(list): > def enter(parent=None): Of course this was meant to be: class blist(list): der enter(self, parent=None): Bye, Walter Dörwald ___ 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 340 -- loose ends
These are the loose ends on the PEP (apart from filling in some missing sections): 1. Decide on a keyword to use, if any. 2. Decide on the else clause. 3. Decide on Phillip Eby's proposal to have a different API for blocks, so you would have to use a @decorator to turn a generator into something usable in a block. Here are my strawman decisions, to the extent that I'm clear on them: 1. I still can't decide on keyword vs. no keyword, but if we're going to have a keyword, I haven't seen a better proposal than block. So it's either block or nothing. I'll sleep on this. Feel free to start an all-out flame war on this in c.l.py. ;-) 2. No else clause; the use case is really weak and there are too many possible semantics. It's not clear whether to generalize from for/else, or if/else, or what else. 3. I'm leaning against Phillip's proposal; IMO it adds more complexity for very little benefit. Unless there's more discussion on any of these, I'll probably finish up the PEP and post it to c.l.py in a few days. -- --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 340 -- loose ends
At 05:55 PM 5/2/05 -0700, Guido van Rossum wrote: >3. I'm leaning against Phillip's proposal; IMO it adds more complexity >for very little benefit. Little benefit, I'll agree with, even though there are EIBTI and TOOWTDI benefits as well as Errors Should Never Pass Silently. But the only added implementation complexity is the decorator -- balanced against the removal of the need for a 'next()' builtin. I also believe that the approach actually *reduces* pedagogical complexity by not allowing any blurring between the concept of an iterator and the concept of a block template. Since I'm not sure if anybody besides you is aware of what I proposed, I'll attempt to recap here, and then step to allow discussion. If there's no community support, I'll let it die a natural death, because it's ultimately a "purity" question rather than a practical one, though I think that other people who teach Python programming should weigh in on this. 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 template function for use with blocks. Because today's generators were also not written with blocks in mind, it would also be necessary to use a @decorator to declare that a generator is in fact a block template. Possibly something like: @blocktemplate def retry(times): for i in xrange(times): try: yield except StopIteration: return except: continue else: return raise My argument is that this is both Explicit (i.e., better than implicit) and One Obvious Way (because using existing iterators just Another Way to do a "for" loop). It also doesn't allow Errors (using an iterator with no special semantics) to Pass Silently. Of course, since Practicality Beats Purity, I could give this all up. But I don't think the Implementation is Hard to Explain, as it should be just as easy as Guido's proposal. Instead of a 'next()' builtin, one would instead implement a 'blocktemplate' decorator (or whatever it's to be called). The same __next__/__exit__/next methods have to be implemented as in Guido's proposal. Really, the only thing that changes is that you get a TypeError when a template function returns an iterator instead of a block template, and you have to use the decorator on your generators to explicitly label them safe for use with blocks. (Hand-crafted block templates still just implement __next__ and __exit__, in the same way as they would under Guido's proposal, so no real change there.) Guido may also have other reasons to take a different direction that he may not have expressed; e.g. maybe in Py3K there'll be no "for", just "iter(x) as y:"? Or...? I don't claim to have any special smarts about this, but other people (including Guido) have previously expressed reservations about the near-blending of iteration and block control that PEP 340 allows. So, I've thrown out this proposal as an attempt to address those reservations. YMMV. ___ 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 -- loose ends
At 09:39 PM 5/2/05 -0400, Phillip J. Eby wrote: >attempt to recap here, and then step to allow discussion. If there's no Argh. That was supposed to be, "step aside to allow discussion". ___ 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 -- loose ends
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 template > function > for use with blocks. PEP 340 does not address "normal" iterators very well, but a properly-constructed iterator will behave correctly. The PEP though is very generator-focussed. The issues I see for "normal" iterators (and that need to be addressed/stated in the PEP) are: 1. No automatic handling of parameters passed to __next__ and __exit__. In a generator, these will raise at the yield-statement or -expression. A "normal" iterator will have to take care of this manually. This could be an argument to only allow generator-iterators to be used with PEP 340 semantics (i.e. continue , block), but I don't think it's a very compelling one. Although perhaps the initial implementation could be restricted to generator-iterators. So if a for-loop used `continue ` it would have a check (at the start of the for loop) that the iterator is a generator-iterator. Likewise, a block-statement would always include this check. As another option, it might be worthwhile creating a base iterator type with "correct" semantics. Tim Delaney ___ 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 -- loose ends
[Delaney, Timothy] > PEP 340 does not address "normal" iterators very well, but a > properly-constructed iterator will behave correctly. This is by design. > The PEP though is very generator-focussed. Disagree. The PEP describes most everything (e.g. the block statement semantics) in terms of iterators, and then describes how the new APIs behave for generators. > The issues I see for "normal" > iterators (and that need to be addressed/stated in the PEP) are: > > 1. No automatic handling of parameters passed to __next__ and __exit__. >In a generator, these will raise at the yield-statement or -expression. >A "normal" iterator will have to take care of this manually. Not sure what you mean by this. If __next__() is defined, it is passed the parameter; if only next() is defined, a parameter (except None) is an error. That seems exactly right. Also, if __exit__() isn't defined, the exception is raised, which is a very sensible default behavior (and also what will happen to a generator that doesn't catch the exception). > This could be an argument to only allow generator-iterators to be used > with PEP 340 semantics (i.e. continue , block), but I don't think > it's a very compelling one. Neither do I. :-) > Although perhaps the initial implementation could be restricted to > generator-iterators. So if a for-loop used `continue ` it would > have a check (at the start of the for loop) that the iterator is a > generator-iterator. Likewise, a block-statement would always include > this check. But what would this buy you except an arbitrary restriction? > As another option, it might be worthwhile creating a base iterator type > with "correct" semantics. Well, what would the "correct" semantics be? What would passing a parameter to a list iterator's __next__() method mean? -- --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 340 -- loose ends
Guido van Rossum wrote: > [Delaney, Timothy] >> PEP 340 does not address "normal" iterators very well, but a >> properly-constructed iterator will behave correctly. > > This is by design. Yep - I agree. >> The PEP though is very generator-focussed. > > Disagree. The PEP describes most everything (e.g. the block statement > semantics) in terms of iterators, and then describes how the new APIs > behave for generators. Again, agree. What I meant is that there are no examples of how to actually implement the correct semantics for a normal iterator. Doing it right is non-trivial, especially with the __next__ and __exit__ interaction (see below). >> The issues I see for "normal" >> iterators (and that need to be addressed/stated in the PEP) are: >> >> 1. No automatic handling of parameters passed to __next__ and >>__exit__. In a generator, these will raise at the yield >>-statement or -expression. A "normal" iterator will have >>to take care of this manually. > > Not sure what you mean by this. If __next__() is defined, it is passed > the parameter; if only next() is defined, a parameter (except None) is > an error. That seems exactly right. Also, if __exit__() isn't defined, > the exception is raised, which is a very sensible default behavior > (and also what will happen to a generator that doesn't catch the > exception). What I meant is how the iterator is meant to handle the parameters passed to each method. PEP 340 deals with this by stating that exceptions will be raised at the next yield-statement or -expression. I think we need an example though of how this would translate to a "normal" iterator. Something along the lines of:: class iterator (object): def next (self): return self.__next__() def __next__(self, arg=None): value = None if isinstance(arg, ContinueIteration): value = arg.value elif arg is not None: raise arg if value is None: raise StopIteration return value def __exit__(self, type=None, value=None, traceback=None): if (type is None) and (value is None) and (traceback is None): type, value, traceback = sys.exc_info() if type is not None: try: raise type, value, traceback except type, exc: return self.__next__(exc) return self.__next__() >> As another option, it might be worthwhile creating a base iterator type >> with "correct" semantics. > Well, what would the "correct" semantics be? What would passing a > parameter to a list iterator's __next__() method mean? Sorry - I meant for user-defined iterators. And the correct semantics would be something like the example above I think. Except that I think most of it would need to be in a separate method (e.g. _next) for base classes to call - then things would change to be something like:: class iterator (object): ... def _next (self, arg): if isinstance(arg, ContinueIteration): return arg.value elif arg is not None: raise arg def __next__(self, arg=None): value = self._next(arg) if value is None: raise StopIteration return value ... Finally, I think there is another loose end that hasn't been addressed:: When __next__() is called with an argument that is not None, the yield-expression that it resumes will return the value attribute of the argument. If it resumes a yield-statement, the value is ignored (or should this be considered an error?). When the *initial* call to __next__() receives an argument that is not None, the generator's execution is started normally; the argument's value attribute is ignored (or should this be considered an error?). When __next__() is called without an argument or with None as argument, and a yield-expression is resumed, the yield-expression returns None. My opinion is that each of these should be an error. Tim Delaney ___ 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 -- loose ends
[Delaney, Timothy] > What I meant is that there are no examples of how to > actually implement the correct semantics for a normal iterator. Doing it > right is non-trivial, especially with the __next__ and __exit__ > interaction (see below). Depends on what you mean by right. Ignoring the argument to __next__() and not implementing __exit__() seems totally "right" to me. [...] > What I meant is how the iterator is meant to handle the parameters > passed to each method. PEP 340 deals with this by stating that > exceptions will be raised at the next yield-statement or -expression. I > think we need an example though of how this would translate to a > "normal" iterator. Something along the lines of:: > > class iterator (object): > > def next (self): > return self.__next__() > > def __next__(self, arg=None): > value = None > > if isinstance(arg, ContinueIteration): 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? > value = arg.value > elif arg is not None: > raise arg > > if value is None: > raise StopIteration > > return value That's a very strange iterator; it immediately terminates unless you call __next__() with a non-None argument, then it returns the argument value. I'm having a hard time understanding what you meant to say. Also note that the very *first* call to __next__() is not supposed to have an argument. The argument (normally) only comes from "continue EXPR" and that can only be reached after the first call to __next__(). This is exactly right for generators -- the first __next__() call there "starts" the generator at the top of its function body, executing until the first yield is reached. > def __exit__(self, type=None, value=None, traceback=None): > if (type is None) and (value is None) and (traceback is None): > type, value, traceback = sys.exc_info() You shouldn't need to check for traceback is None. Also, even though the PEP suggests that you can do this, I don't see a use case for it -- the translation of a block-statement never calls __exit__() without an exception. > if type is not None: > try: > raise type, value, traceback > except type, exc: > return self.__next__(exc) > >return self.__next__() Ah, here we see the other misconception (caused by not reading the most recent version of the PEP). __exit__() shouldn't call __next__() -- it should just raise the exception passed in unless it has something special to do. Let me clarify all this with an example showing how you could write "synchronized()" as an iterator instead of a generator. class synchronized: def __init__(self, lock): self.lock = lock self.state = 0 def __next__(self, arg=None): # ignores arg if self.state: assert self.state == 1 self.lock.release() self.state += 1 raise StopIteration else: self.lock.acquire() self.state += 1 return None def __exit__(self, type, value=None, traceback=None): assert self.state in (0, 1, 2) if self.state == 1: self.lock.release() raise type, value, traceback > >> As another option, it might be worthwhile creating a base iterator type > >> with "correct" semantics. > > > Well, what would the "correct" semantics be? What would passing a > > parameter to a list iterator's __next__() method mean? > > Sorry - I meant for user-defined iterators. And the correct semantics > would be something like the example above I think. Except that I think > most of it would need to be in a separate method (e.g. _next) for base > classes to call - then things would change to be something like:: > > class iterator (object): > ... > > def _next (self, arg): > if isinstance(arg, ContinueIteration): > return arg.value > elif arg is not None: > raise arg > > def __next__(self, arg=None): > value = self._next(arg) > > if value is None: > raise StopIteration > > return value > > ... I think this is all based on a misunderstanding of the PEP. Also, you really don't need to implement __exit__() unless you have some cleanup to do -- the default behavior of the block translation only calls it if defined, and otherwise simply raises the exception. > Finally, I think there is another loose end that hasn't been addressed:: > > When __next__() is called with an argument that is not None, the > yield-expression that it resumes will return the value attribute > of the argument. If it resumes a yield-st
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 322 open ( +6) / 2832 closed ( +1) / 3154 total ( +7)
Bugs: 920 open (+12) / 4952 closed (+11) / 5872 total (+23)
RFE : 186 open ( +8) / 156 closed ( +3) / 342 total (+11)
New / Reopened Patches
__
Info Associated with Merge to AST (2005-01-07)
http://python.org/sf/1097671 reopened by kbk
Minimal cleanup of run.py (2005-04-26)
http://python.org/sf/1190163 opened by Michiel de Hoon
socketmodule.c's recvfrom on OSF/1 4.0 (2005-04-27)
http://python.org/sf/1191065 opened by Marcel Martin
Simplify logic in random.py (2005-04-28)
CLOSED http://python.org/sf/1191489 opened by Raymond Hettinger
wrong offsets in bpprint() (2005-04-28)
http://python.org/sf/1191700 opened by Pechkinzzz
about shift key (2005-04-28)
http://python.org/sf/1191726 opened by yang
debugger ``condition`` and ``ignore`` exception handling (2005-04-29)
http://python.org/sf/1192590 opened by Jeremy Jones
Use GCC4 ELF symbol visibility (2005-04-30)
http://python.org/sf/1192789 opened by James Henstridge
Patches Closed
__
type conversion methods and subclasses (2005-01-25)
http://python.org/sf/1109424 closed by bcannon
Don't assume all exceptions are SyntaxError's (2005-04-24)
http://python.org/sf/1189210 closed by bcannon
Automatically build fpectl module from setup.py (2005-04-19)
http://python.org/sf/1185529 closed by mwh
Simplify logic in random.py (2005-04-28)
http://python.org/sf/1191489 closed by rhettinger
New / Reopened Bugs
___
[AST] assignment to None allowed (2005-04-25)
CLOSED http://python.org/sf/1190010 opened by Brett Cannon
[AST] distinct code objects not created (2005-04-25)
http://python.org/sf/1190011 opened by Brett Cannon
``from sys import stdin,`` doesn't raise a SyntaxError (2005-04-25)
http://python.org/sf/1190012 opened by Brett Cannon
3.29 site is confusing re site-packages on Windows (2005-04-26)
http://python.org/sf/1190204 opened by Kent Johnson
6.9 First sentence is confusing (2005-04-26)
CLOSED http://python.org/sf/1190451 opened by Nicolas Grilly
os.waitpid docs don't specify return value for WNOHANG (2005-04-26)
http://python.org/sf/1190563 opened by jls
SimpleHTTPServer sends wrong c-length and locks up client (2005-04-26)
http://python.org/sf/1190580 opened by Alexander Schremmer
calendar._firstweekday is too hard-wired (2005-04-26)
http://python.org/sf/1190596 opened by Tres Seaver
dir() docs show incorrect output (2005-04-26)
CLOSED http://python.org/sf/1190599 opened by Martin Chase
bz2 RuntimeError when decompressing file (2005-04-27)
http://python.org/sf/1191043 opened by Chris AtLee
Warning ``error`` filter action is ignored. (2005-04-27)
CLOSED http://python.org/sf/1191104 opened by Ivan Vilata i Balaguer
[AST] Failing tests (2005-04-27)
http://python.org/sf/1191458 opened by Brett Cannon
'clear -1' in pdb (2005-04-29)
http://python.org/sf/1192315 opened by Pechkinzzz
doctest's ELLIPSIS and multiline statements (2005-04-29)
CLOSED http://python.org/sf/1192554 opened by Sébastien Boisgérault
docstring error (2005-04-29)
CLOSED http://python.org/sf/1192777 opened by Christopher Smith
Notation (2005-04-30)
http://python.org/sf/1193001 opened by Mythril
Python and Turkish Locale (2005-04-30)
http://python.org/sf/1193061 opened by S.Çağlar Onur
Embedded python thread crashes (2005-04-30)
http://python.org/sf/1193099 opened by ugodiggi
Strange os.path.exists() results with invalid chars (2005-04-30)
http://python.org/sf/1193180 opened by Daniele Varrazzo
MACOSX_DEPLOYMENT_TARGET checked incorrectly (2005-04-30)
http://python.org/sf/1193190 opened by Bob Ippolito
os.path.expanduser documentation wrt. empty $HOME (2005-05-02)
http://python.org/sf/1193849 opened by Wummel
calendar.weekheader not found in __all__ (2005-05-03)
http://python.org/sf/1193890 opened by George Yoshida
Weakref types documentation bugs (2005-05-02)
http://python.org/sf/1193966 opened by Barry A. Warsaw
bz2.BZ2File doesn't handle modes correctly (2005-05-02)
http://python.org/sf/1194181 opened by Bob Ippolito
Error in section 4.2 of Python Tutorial (2005-05-03)
http://python.org/sf/1194209 opened by Andrina Kelly
Bugs Closed
___
[ast branch] fatal error when compiling test_bool.py (2005-03-19)
http://python.org/sf/1166714 closed by bcannon
[AST] assert failure on ``eval("u'\Ufffe'")`` (2005-04-19)
http://python.org/sf/1186345 closed by bcannon
"Atuple containing default argument values ..." (2005-04-25)
http://python.org/sf/1189819 closed by rhettinger
[AST] assignment to None allowed (2005-04-25)
http://python.org/
Re: [Python-Dev] PEP 340 -- loose ends
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 versions worked that way. This has been going on too long ;) > Ah, here we see the other misconception (caused by not reading the > most recent version of the PEP). __exit__() shouldn't call __next__() > -- it should just raise the exception passed in unless it has > something special to do. Ah - I think this needs to be explained better. In particular, in the specification of the __next__ and __exit__ methods it should state what exceptions are expected to be raised under what circumstances - in particular, that __exit__ is expected to raise the passed in exception or StopIteration. This is only explained in the Generator Exception Handling specification, but it's applicable to all iterators. >> Finally, I think there is another loose end that hasn't been >> addressed:: >> >> When __next__() is called with an argument that is not None, the >> yield-expression that it resumes will return the value attribute >> of the argument. If it resumes a yield-statement, the value is >> ignored (or should this be considered an error?). When the >> *initial* call to __next__() receives an argument that is not >> None, the generator's execution is started normally; the >> argument's value attribute is ignored (or should this be >> considered an error?). When __next__() is called without an >> argument or with None as argument, and a yield-expression is >> resumed, the yield-expression returns None. > > Good catch. > >> My opinion is that each of these should be an error. > > Personally, I think not using the value passed into __next__() should > not be an error; that's about the same as not using the value returned > by a function you call. Now that I understand that the parameter to __next__ is not an exception, I agree. > I agree that calling the initial __next__() of a generator with a > non-None argument should be considered an error; this is likely caused > by some kind of logic error; it can never happen when the generator is > called by a block statement. Cheers. Tim Delaney ___ 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
