> 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
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
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
>>>
>>>
> >> 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 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
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)
<-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
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
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
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
[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
__
> > 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 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
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
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
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
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
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():
>
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(
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
> > >>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:
> > [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
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
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
Python-Dev@python.org
http:
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
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:
>>
>>
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
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
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
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
>> 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
---
[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
Python-Dev@python.org
http://mail.python.org/mailman/listi
> 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
33 matches
Mail list logo
