> 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 = rando
[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/listi
>> 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
---
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
pr
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
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 p
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 gene
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:
>>
>>
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 tr
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:
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 expressi
> > [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
> > >>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:
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
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(
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():
>
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
> usi
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 extende
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
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
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
> > 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
[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
__
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 Del
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
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
<-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 PROTECT
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)
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
> >> 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:
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
>>>
>>>
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
> > m
> 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 gen
33 matches
Mail list logo
