Patch / Bug Summary
___
Patches : 338 open ( -1) / 2861 closed ( +4) / 3199 total ( +3)
Bugs: 909 open ( +1) / 5047 closed (+11) / 5956 total (+12)
RFE : 188 open ( -1) / 170 closed ( +2) / 358 total ( +1)
New / Reopened Patches
__
byteorder
Guido van Rossum wrote:
> Intel has a free (as in beer) C compiler for Linux. A friend of mine
> is involved in its production and marketing. He would like to see how
> "his" compiler does on Python -- does it work at all, and is there a
> speedup?
There is a bug report on this compiler: python.or
Intel has a free (as in beer) C compiler for Linux. A friend of mine
is involved in its production and marketing. He would like to see how
"his" compiler does on Python -- does it work at all, and is there a
speedup? I promised him I'd look into this, but between PEPs and my
day job I don't seem to
Guido van Rossum wrote:
> On 6/14/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>> From Programming Languages 101 I remember this construct in Algol 68.
>> It was then claimed to be *the* universal loop construct. If that is
>> true __and__ it is easy to implement, I'd say +INF for PEP 315.
>
> It
On 6/14/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
> From Programming Languages 101 I remember this construct in Algol 68.
> It was then claimed to be *the* universal loop construct. If that is
> true __and__ it is easy to implement, I'd say +INF for PEP 315.
It's true, but this both dates you
> > With PEP 315, a do-while loop would look like:
> >
> >do:
> >
> >while :
> >pass
> > But then, I'm reasonably happy with the 'break out of an infinite
> > loop' approach, so *shrug*.
> From Programming Languages 101 I remember this construct in Algol 68.
> It was then
On 6/14/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> Oh. I had the impression that the reason do-while's (or do-until's
> which I like more) wasn't implemented in the language was because it
> was impossible to find an acceptable looking syntax.
No, just because it's fairly redundant.
> > >
Nick Coghlan wrote:
> With PEP 315, a do-while loop would look like:
>
>do:
>
>while :
>pass
>
> But then, I'm reasonably happy with the 'break out of an infinite
> loop' approach, so *shrug*.
From Programming Languages 101 I remember this construct in Algol 68.
It was th
> > 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
On 6/14/05, Vero <[EMAIL PROTECTED]> wrote:
> Hi. My name is Veronica, I am a master student at UNAM. I am working on
> something related to Artificial Inteligence and I have been looking for the
> most appropriated programming language to implement my algorithms. I found
> python to be very clo
On Tue, Jun 14, 2005, Vero wrote:
>
> Hi. My name is Veronica, I am a master student at UNAM. I am working
> on something related to Artificial Inteligence and I have been looking
> for the most appropriated programming language to implement my
> algorithms. I found python to be very close to wh
Hi. My name is Veronica, I am a master student at UNAM. I am working on something related to Artificial Inteligence and I have been looking for the most appropriated programming language to implement my algorithms. I found python to be very close to what I need, but there are still a couple of d
[Bob]
> islice depends on __getitem__.
Incorrect. It uses the iterator protocol.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
"Martin v. Löwis" wrote:
> Fernando Perez wrote:
>> sorry for posting to this list, but I'm not even 100% sure this is a bug.
>> If it is, I'll gladly post it to SF if you folks want it there.
>
> This is not a bug. Most likely, sc_weave.cpp fails to meet the
> requirement documented in
>
> htt
Fernando Perez wrote:
> sorry for posting to this list, but I'm not even 100% sure this is a bug. If
> it
> is, I'll gladly post it to SF if you folks want it there.
This is not a bug. Most likely, sc_weave.cpp fails to meet the
requirement documented in
http://docs.python.org/api/includes.html
Hi all,
sorry for posting to this list, but I'm not even 100% sure this is a bug. If it
is, I'll gladly post it to SF if you folks want it there.
I use scipy a lot, and the weave.inline component in there allows dynamic
inclusion of C/C++ code in Python sources. In particular, it supports Blitz
Phillip J. Eby wrote:
> 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?
Heck, I *suggested* the trick, and still had to look at it a hal
On Jun 14, 2005, at 2:25 AM, Raymond Hettinger wrote:
>> 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
Jp Calderone writes:
> Anything can be a for loop.
>
> for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''):
> f2.write(chunk)
Raymond responds:
> It would be nice to have this encapsulated in a file method:
>
> for chunk in f1.iterblocks(CHUNK_SIZE):
> f2.write(chunk)
What ever
19 matches
Mail list logo
