Re: [Python-Dev] Wishlist: dowhile
> In contrast, the dowhile solution only takes about 30 seconds to get > used to. Maybe that idea should follow the path of the genexp PEP, get > rejected now, and then get resurrected as a bright idea two years from > now. Or maybe not. dowhile foo != 42: <10 lines of body> foo = random.randint(1, 50) Now it becomes annoying because the name is visible long before it is bound to something. I would like to have do-while's like this: do: until But I'm sure that has problems too. -- mvh Björn ___ 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] Wishlist: dowhile
[BJörn Lindqvist] > I would like to have do-while's like this: > > do: > > until > > But I'm sure that has problems too. That looks nice to me. Raymond ___ 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] Wishlist: dowhile
>> do: >> >> until > That looks nice to me. Except this puts loop entry statement (do) and loop condition test (until) on different levels of indentation, which is I don't quite like. Compared to the existing loop statements, --- while Cond: body else: exit --- for Iter: body else: exit --- This would seem more logical: --- do: body while Cond: else: exit --- do: body until Cond: else: exit --- Although the trailing colon is still a bit unpleasant: --- do: body while Cond: # no else here --- Sincerely, Dmitry Dvoinikov http://www.targeted.org/ --- Original message follows --- > [BJörn Lindqvist] >> I would like to have do-while's like this: >> >> do: >> >> until >> >> But I'm sure that has problems too. > That looks nice to me. > Raymond > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dmitry%40targeted.org ___ 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] Multiple expression eval in compound if statement?
Raymond> I think it unwise to allow x to be any expression. How do you decide what's "too complex"? Even an apparently simple variable can have side effects, so the semantic change bit is important no matter how complex the expression. (Consider the builtin help object. Type it at the prompt with no parens.) Like I said, "I'm horsing around with...". If this never makes it into Python I can accept that. The interesting thing for me at this point is the code generation anyway. I figure if Guido reconsiders PEP 275 (I think it covers all the bases), then the code generation stuff will probably be of some use. 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] Multiple expression eval in compound if statement?
Skip writes: > Even an apparently simple variable can have side effects [...] Consider > the builtin help object. Type it at the prompt with no parens. I tried. As far as I can tell, the result (in the interactive interpreter) is the same as with any other object except None: the _ variable gets set, the interpreter prints out the __str__ of the object, sets the _ variable, and prints a new '>>>' prompt. It happens that the __str__ of the help object is: 'Type help() for interactive help, or help(object for help about object.' ... but if there's some side effect going on here, I don't see it. What am I missing? -- Michael Chermside ___ 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] Multiple expression eval in compound if statement?
A few thought's on Skip's idea here: Skip: > I can't imagine anyone relying on a side-effect when evaluating x in this > context, and if someone did, their code would be truly fragile. Yeah... people like that really annoy me. If people just wouldn't write code that depends on the FULL dynamics possible, then it'd be a lot easier for the VM to optimize. Unfortunately, we have to support such people. Raymond: I think it unwise to allow x to be any expression. Besides altering existing semantics, it leads to code redundancy and to a fragile construct (where the slightest alteration of any of the expressions triggers a silent reversion to O(n) behavior). Skip's proposal isn't the problem here. The syntax of the if-elif-else statement requires that when it is used in lieu of C's switch() statement that the switch() argument be repeated in each elif clause. Repeating it DOES violate once-and-only-once, but we've decided that that's an acceptable price to pay to avoid needing an extra kind of flow control statement for which there wasn't a really elegent syntax anyhow. A reasonably tradeoff, I agree, but the cost is that we DO violate once-and-only-once. The REAL danger from the "slightest alteration of any of the expressions" is not that it will alter from O(1) behavior to O(n) behavior, the REAL danger is that you may have MEANT it to be the same everywhere and the alteration is a typo and a bug! Guido: > I think it would be wiser if you only did this when x is a simple > local variable. I agree. I think of Skip's proposal as just an optimization, of the sort that the Python interpreter is allowed to make when there's no possible semantic effect. It would then restrict the use to situations where the 'switch() argument' was a local variable and the 'case values' were string literals, integer literals, float literals (but that shouldn't count because it's a really bad idea anyhow), None, and perhaps (I wouldn't bother, myself) tuples of the above. It sounds pretty restricted, which raises the question of whether it's worth it given the harsh restrictions on when the optimization would kick in. I write such things with local variables and literal strings quite often. On the other hand, I don't usually have more than 4-10 values though, so O(1) and O(n) may not be THAT different. It's one of those cases where the only thing I'd really believe was experiments done on real code. But it's a cool optimization if it actually pays off. -- Michael Chermside ___ 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] Wishlist: dowhile
Raymond Hettinger wrote: > [BJörn Lindqvist] > >>I would like to have do-while's like this: >> >>do: >> >>until >> >>But I'm sure that has problems too. > > > That looks nice to me. And this could easily be extended to allow code both before and after the 'until', giving a fully general loop: do: until else: In fact, this would simply be giving "looks like executable pseudocode" syntactic sugar for the current 'do-until' workarounds: while 1: if : break And: _exit = False: while not _exit: _exit = else: The 'until' is less hidden than the 'yield' that turns a function into a generator, and its presence is obviously signalled by the preceding 'do'. Its also less hidden than the 'if'/'break' construct in the infinite loop workaround, and about as hidden as the exit flag in the other style of workaround (although the 'until' can be more easily picked out by a syntax highlighter). 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] Wishlist: dowhile
On Mon, 13 Jun 2005 01:25:51 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >At 09:01 PM 6/12/2005 -0700, Guido van Rossum wrote: >>If we have to do this, PEP 315 has my +0. >> >>It is Pythonically minimal and the motivation rings true: I've often >>written code like this in the past: >> >> line = f.readline() >> while line: >> >> line = f.readline() >> >>But these days we do that using "for line in f". > >Block-copying a file with read() has the same pattern (e.g. in shutil), but >you can't make it a for loop. Anything can be a for loop. for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): f2.write(chunk) 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 343 - next steps
Guido van Rossum wrote: > We considered this at some point during the PEP 340/343/346 discussion > (in fact I had it this way in an early version of one of the PEPs), > and in the end decided against it. I believe the argument was that any > failure *before* __enter__() returns can be handled by try/except > clauses inside __init__() or __enter__(). Hmm, you're right. Also, given implementation of PEP 343, code which genuinely has to care about this can do so manually: with async_exceptions_blocked(): with critical_resource(): with async_exceptions_unblocked(): # Do the real work This ensures acquisition of the critical resource is not interrupted. Even better, the above can be wrapped up in a template and still give the desired guarantees: @stmt_template def safe_acquisition(resource): with async_exceptions_blocked(): with resource(): with async_exceptions_unblocked(): yield None with safe_acquisition(critical_resource): # Do the real work 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] Multiple expression eval in compound if statement?
Michael> ... but if there's some side effect going on here, I don't see Michael> it. What am I missing? Mea culpa. I was thinking of the print as a side efefct. Obviously mistaken. 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] Multiple expression eval in compound if statement?
On Monday 13 June 2005 21:14, Skip Montanaro wrote: > Raymond> I think it unwise to allow x to be any expression. > > How do you decide what's "too complex"? Even an apparently simple variable > can have side effects, so the semantic change bit is important no matter > how complex the expression. (Consider the builtin help object. Type it at > the prompt with no parens.) Note also that saying 'just a simple local variable' doesn't cut it, either, because you will break on something like: class stupid: v = 0 def __eq__(self, other): self.v += 1 return self.v == other Really, you'd have to make sure you didn't optimise any LHS that defined a comparision operator (I _think_ that covers all the cases). Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Wishlist: dowhile
> > [BJörn Lindqvist] > > > >>I would like to have do-while's like this: > >> > >>do: > >> > >>until > >> > >>But I'm sure that has problems too. > > [Raymond Hettinger] > > That looks nice to me. [Nick Coghlan] > And this could easily be extended to allow code both before and after > the 'until', giving a fully general loop: > >do: > >until > >else: > Which is exactly like PEP 315 except there 'until' must be spelled 'while not' and the while is properly indented. (I'm still not sure whether BJörn *meant* the 'until' to be indented or whether he simply made a mistake; his proposal resembles a Pythonic version of Pascal's repeat-until, which would have an unindented until-clause.) > The 'until' is less hidden than the 'yield' that turns a function into > a generator, and its presence is obviously signalled by the preceding > 'do'. Its also less hidden than the 'if'/'break' construct in the > infinite loop workaround, and about as hidden as the exit flag in the > other style of workaround (although the 'until' can be more easily > picked out by a syntax highlighter). Why are you so excited about having until indented? You didn't give any examples with multiple occurrences. A single occurrence works just fine unindented, as PEP 315 has already shown. The indented until sounds like unnecessary syntactic sugar for 'if X: break' -- not very Pythonic. -- --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] Wishlist: dowhile
> > >>do: > > >> > > >>until > > >> > > >>But I'm sure that has problems too. > > > > [Raymond Hettinger] > > > That looks nice to me. > > [Nick Coghlan] > > And this could easily be extended to allow code both before and after > > the 'until', giving a fully general loop: > > > >do: > > > >until > > > >else: > > > > Which is exactly like PEP 315 except there 'until' must be spelled > 'while not' and the while is properly indented. > > (I'm still not sure whether BJörn *meant* the 'until' to be indented > or whether he simply made a mistake; his proposal resembles a Pythonic > version of Pascal's repeat-until, which would have an unindented > until-clause.) Sorry, I should have made that clear. I *meant* for 'until' to be indented. I envisonaged it to be treatened similar to how the raise, pass and return statements work. Those statements are indented in a suite and they always end the current block. Well, technically you can write stuff like this: suite: raise Exception But 'block2' will always be dead code. Emacs, for example, always dedents when you write any of those three statements. The reason I suggested was not so that you could extend it to fully general loops like Nick suggested (which I can't comment on because I never use else: in looping constructs and always keep the condition check and the top or bottom), but because I thought that a dedented 'until' would be very hard to parse and in general look very unpythonic: do: until Written like this it is not very obvious that the 'unil' is part of the do-until suite. I also imagine it to be difficult to parse and it breaks the rule that suites end when there is a dedentation. So, IMHO using an indented 'until' is the least evil of a number of evils. > Why are you so excited about having until indented? You didn't give > any examples with multiple occurrences. A single occurrence works just > fine unindented, as PEP 315 has already shown. > > The indented until sounds like unnecessary syntactic sugar for 'if X: > break' -- not very Pythonic. Yes, but grepping the stdlib produces over 300 hits for "while 1:" and "while True:" combined. Some of those a "if : break" in the middle and some would be better written as generators, but lots of them would be rewritten as do-while's. So I think there is more than enough use cases for syntactic sugar for do-while loops. -- mvh Björn ___ 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] Summer of Code: Developing complete SSL support for Python
Gustavo J. A. M. Carneiro wrote: [...] > > 4. In the socket module documentation: > > > ssl( > sock[, keyfile, certfile]) > Initiate a SSL connection over the socket sock. keyfile is the > name of a PEM formatted file that contains your private key. > certfile is a PEM formatted certificate chain file. On success, > a new SSLObject is returned. > > Warning: This does not do any certificate verification! > >I would make it a top priority to enable certificate verification in > ssl sockets. I don't see the point in doing SSL without certificate > verification. It's just false security. Maybe adding a callback asking > the application what to do if certificate validation fails, so that > application writers can show a GUI dialogue or something like that... > > Best regards. > I believe that SSL sockets without certificate verification will still retain the advantages of encryption ind integrity checking, though you are right to say that *authentication* is lost without certificate checking: the certificate is essentially the CA's assertion that they have applied the process described in their Certification Practices Statement to identify the subject. Then you must consider which CA's will be acceptable certificate issuers, and build trust for their certificates into the system in some modifiable way - we need to be able to add CA's - by the incorporation of the CAs' self-signed certificates, as in the browsers. So almost certainly if the platform has a certificate repository it might be good to offer an interface to that, as well as offering a private certificate repository. regards Steve -- Steve Holden+1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.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] Wishlist: dowhile
At 08:14 AM 6/13/2005 -0400, Jp Calderone wrote: >On Mon, 13 Jun 2005 01:25:51 -0400, "Phillip J. Eby" ><[EMAIL PROTECTED]> wrote: > >Block-copying a file with read() has the same pattern (e.g. in shutil), but > >you can't make it a for loop. > >Anything can be a for loop. > > for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): > f2.write(chunk) Showoff. ;) More seriously, I think your translation makes an excellent argument in *favor* of having a do/while statement for greater clarity. :) ___ 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 - next steps
At 10:40 PM 6/13/2005 +1000, Nick Coghlan wrote: >Hmm, you're right. Also, given implementation of PEP 343, code which >genuinely has to care about this can do so manually: > >with async_exceptions_blocked(): >with critical_resource(): >with async_exceptions_unblocked(): ># Do the real work > >This ensures acquisition of the critical resource is not interrupted. >Even better, the above can be wrapped up in a template and still give >the desired guarantees: > >@stmt_template >def safe_acquisition(resource): >with async_exceptions_blocked(): >with resource(): >with async_exceptions_unblocked(): >yield None > > >with safe_acquisition(critical_resource): ># Do the real work Ow. My head hurts. :) Seriously, though, wouldn't it make more sense to put the 'with async_exceptions_blocked()' in the __init__ or __enter__ of 'critical_resource'? Or am I still missing something? ___ 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] Wishlist: dowhile
On 6/13/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > do: > > until > > Written like this it is not very obvious that the 'unil' is part of > the do-until suite. I also imagine it to be difficult to parse and it > breaks the rule that suites end when there is a dedentation. So, IMHO > using an indented 'until' is the least evil of a number of evils. Not difficult to parse at all, nor un-Pythonic. Multi-part blocks abound in Python: if / elif / else, try / finally, etc. > > Why are you so excited about having until indented? You didn't give > > any examples with multiple occurrences. A single occurrence works just > > fine unindented, as PEP 315 has already shown. > > > > The indented until sounds like unnecessary syntactic sugar for 'if X: > > break' -- not very Pythonic. > > Yes, but grepping the stdlib produces over 300 hits for "while 1:" and > "while True:" combined. Some of those a "if : break" in the > middle and some would be better written as generators, but lots of > them would be rewritten as do-while's. So I think there is more than > enough use cases for syntactic sugar for do-while loops. The PEP 315 solution looks much better than an "until" that isn't what it looks like. -- --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] Wishlist: dowhile
On Monday 13 June 2005 08:07, Nick Coghlan wrote: > Raymond Hettinger wrote: > > [BJörn Lindqvist] > > > >>I would like to have do-while's like this: > >> > >>do: > >> > >>until > >> > >>But I'm sure that has problems too. > > > > That looks nice to me. > > And this could easily be extended to allow code both before and after > the 'until', giving a fully general loop: > >do: > >until > >else: > > > In fact, this would simply be giving "looks like executable > pseudocode" syntactic sugar for the current 'do-until' workarounds: > >while 1: > > if : > > break > Yet another way to spell this would be make the default for the while statement be true so the 1 could be omitted and then add a condition to break. while: break : I think this would be feature creep. It complicates the language for a very small gain. While the added syntax would be intuitive, it only saves a line or two over the existing syntax. ___ 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] Wishlist: dowhile
Michael McLay <[EMAIL PROTECTED]> writes:
> I think this would be feature creep. It complicates the language
> for a very small gain. While the added syntax would be intuitive, it
> only saves a line or two over the existing syntax.
FWIW, this is my opinion too (and I've written a bunch of while
True:...if x: break loops today, even).
It would be much nicer if people spent time worrying about the
threads in multiple subinterpreters bug, or why
def sc(*classes):
return type('', classes, {})
sc(sc(str), sc(str))
fails.
Cheers,
mwh
--
Guido (like us!) is a bit schizophrenic here: he wants to be a
benevolent dictator, but also wants to treat people like
grownups. This probably worked better before Python got a large
American audience <0.9 wink>. -- Tim Peters, 10 Feb 2000
___
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] AIX 4.3, Python 2.4.1 fails in test_exceptions with a core dump
I'm attempting to switch from 2.3.2 to 2.4.1 on our AIX 4.3 development system. I have no problems building Python 2.3.2. I build Python 2.4.1 using 'configure --without-threads; gmake; gmake test', and always get a coredump during the tests on 'test_exceptions'. I've searched for any reports of this problem on the Sourceforge bug list and here, with no success. Has anyone seen this 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] Wishlist: dowhile
Jp Calderone writes: > for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): > f2.write(chunk) Phillip J. Eby responds: > Showoff. ;) > > More seriously, I think your translation makes an excellent argument in > *favor* of having a do/while statement for greater clarity. :) Interesting... I had the opposite reaction. I often see someone do something "far too clever", which looks cute and impresses me, but makes me think that one would be wiser to avoid clever tricks and just write straightforward (if dull) code. But when I read JP's code I immediately thought that it WAS the straightforward way to write that code, and that I was just not smart enough to have realized it until he showed me. -- Michael Chermside ___ 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 - next steps
> > But I cannot do this: > > > > def f(x as (a, b)): > > # ... > > which is what I was suggesting. > Yeah, I knew that. How important is that to you? I would really have liked it for a program I was working on at one time that had lots of small methods that passed around values of forms such as (a,(b,c)). Each method would pick one or more of the components out of its compound value and then would sometimes pass the entire value down to the next level. Of course I could do it this way: def f(x): (a,(b,c)) = x # ... but in this particular application, "as" would have offered significant extra convenience. I understand that this is not a real big deal, which is why I haven't written up a 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] Wishlist: dowhile
[Jp Calderone] > Anything can be a for loop. > > for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): > f2.write(chunk) It would be nice to have this encapsulated in a file method: for chunk in f1.iterblocks(CHUNK_SIZE): f2.write(chunk) Raymond ___ 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 342 - Enhanced Iterators
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 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] AIX 4.3, Python 2.4.1 fails in test_exceptions with a core dump
On Mon, Jun 13, 2005, Michael Kent wrote: > > I'm attempting to switch from 2.3.2 to 2.4.1 on our AIX 4.3 > development system. I have no problems building Python 2.3.2. I > build Python 2.4.1 using 'configure --without-threads; gmake; > gmake test', and always get a coredump during the tests on > 'test_exceptions'. I've searched for any reports of this problem on > the Sourceforge bug list and here, with no success. Has anyone seen > this problem? Your question is more on the borderline than most, but please try comp.lang.python before posting here; although you've got more core developers on python-dev, there's a broader spectrum on c.l.py. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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 342 - Enhanced Iterators
Good idea, done.
On 6/13/05, Delaney, Timothy C (Timothy) <[EMAIL PROTECTED]> wrote:
> 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 Delaney
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--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 342 - Enhanced Iterators
<-Original Message->
> From: "Guido van Rossum" <[EMAIL PROTECTED]>
> To: "Delaney, Timothy C (Timothy)" <[EMAIL PROTECTED]>
> Cc:
> Sent: 2005-06-14 10:31
> Subject: Re: [Python-Dev] PEP 342 - Enhanced Iterators
Good idea, done.
On 6/13/05, Delaney, Timothy C (Timothy) <[EMAIL PROTECTED]> wrote:
> 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 Delaney
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--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/iextream%40naver.com
네이버 :: 똑! 소리나게 바뀐 네이버 메일을 만나보세요.
http://mail.naver.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] Wishlist: dowhile
Phillip J. Eby wrote: > By the way, whatever happened to "and while"? i.e.: > > while True: > data = inp.read(blocksize) > and while data: > out.write(data) My favourite version of this is while: data = inp.read(blocksize) gives data: out.write(data) -- 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] Wishlist: dowhile
On Jun 13, 2005, at 10:20 PM, Greg Ewing wrote: > Phillip J. Eby wrote: > > >> By the way, whatever happened to "and while"? i.e.: >> >> while True: >> data = inp.read(blocksize) >> and while data: >> out.write(data) >> > > My favourite version of this is > >while: > data = inp.read(blocksize) >gives data: > out.write(data) Well, we could always just make iterator factories for the common cases and stuff them in itertools. I do need to use this pattern from time to time, but primarily for this exact use case, so an "itertools.readby" or the like would probably solve this problem for most people most of the time. -bob ___ 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] Wishlist: dowhile
> >> By the way, whatever happened to "and while"? i.e.: > >> > >> while True: > >> data = inp.read(blocksize) > >> and while data: > >> out.write(data) > >> > > > > My favourite version of this is > > > >while: > > data = inp.read(blocksize) > >gives data: > > out.write(data) > > Well, we could always just make iterator factories for the common > cases and stuff them in itertools. I do need to use this pattern > from time to time, but primarily for this exact use case, so an > "itertools.readby" or the like would probably solve this problem for > most people most of the time. Doesn't work. You still need to be able to pass through the blocksize argument and the target bound method. To get what you want, there would need to be a new method in the file API. The reason is roughly similar to why we have iteritems as part of the mapping API and not as a standalone itertool. for data in inp.read(blocksize): . . . Raymond ___ 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] Wishlist: dowhile
On Jun 14, 2005, at 1:25 AM, Raymond Hettinger wrote: By the way, whatever happened to "and while"? i.e.: while True: data = inp.read(blocksize) and while data: out.write(data) >>> >>> My favourite version of this is >>> >>>while: >>> data = inp.read(blocksize) >>>gives data: >>> out.write(data) >>> >> >> Well, we could always just make iterator factories for the common >> cases and stuff them in itertools. I do need to use this pattern >> from time to time, but primarily for this exact use case, so an >> "itertools.readby" or the like would probably solve this problem for >> most people most of the time. >> > > Doesn't work. You still need to be able to pass through the blocksize > argument and the target bound method. To get what you want, there > would > need to be a new method in the file API. The reason is roughly > similar > to why we have iteritems as part of the mapping API and not as a > standalone itertool. > > for data in inp.read(blocksize): > . . . Reality check? def readby(inp, blocksize=1024): while True: data = inp.read(blocksize) if not data: break yield data for data in readby(inp, blocksize): . . . I always thought was that iteritems is part of the mapping API and not as a standalone itertool because it is the *most primitive* way to iterate over the key/value pairs. It is simply not implementable without access to the private guts of the dict. That is simply not the case here. If you need an ultra-flexible (but less obvious) implementation you should just use the sentinel version of the iter function as JP demonstrated. -bob ___ 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] Thoughts on stdlib evolvement
Gustavo Niemeyer wrote: > > > moving the main trunk and main development over to the Python CVS is > > > another thing, entirely. > > > > (as I've said many times before, both the user community and the developer > > community would benefit if the core standard library were made smaller, and > > more externally maintained packages were included in the standard releases) > > An issue to consider about this is that maintainers (not talking about > you or anyone else specifically) have different concepts of stability, > and while it may seem perfectly ok to refactor external modules between > two stable releases, doing so in the standard library would spread fear > and "python is so untrustful" feelings. I think you're seriously underestimating the competence of other developers, and seriously overestimating the competence of the python core developers. in my experience, any external library that supports more than one Python version on more than one platform is likely to be more robust than code in the core. add the multilevel volunteer approach de- described by Steven (with the right infrastructure, things like that just appear), and you get more competent manpower contributing to the standard distribution than you can get in any other way. ___ 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] Wishlist: dowhile
> def readby(inp, blocksize=1024): > while True: > data = inp.read(blocksize) > if not data: > break > yield data > > for data in readby(inp, blocksize): > . . . readby() relies on the existence of a read() method for inp. itertools work with generic iterators, not ones with a specific API. Law of Demeter. Raymond ___ 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
