[Python-Dev] PEP 343 question
In gen.throw(), are all three arguments required? Or do the value and traceback Nones need to be listed explicitly? g.throw(MyException) or g.throw(MyException, None, None) FWIW, I prefer the former. That will make throw() as flexible as the raise statement. 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
Guido van Rossum wrote: > 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. I hadn't actually thought about the temptation to try and have multiple 'until' statements inside the suite. Having two suites of the statement included in the loop, while the third is excluded, feels slightly odd, but other than that PEP 315 is fine by me. The fact that PEP 315 only needs a single new keyword is a good thing, as is the fact that it means the 'else' clause still reads correctly. As you said earlier: "It is Pythonically minimal and the motivation rings true" 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
[Python-Dev] refcounting vs PyModule_AddObject
I've just fixed a bug where Py_INCREF wasn't called when it should
have been before a call to PyModule_AddObject (rev. 2.62 of
Modules/threadmodule.c).
So I went looking for other instances of the same problem. I didn't
find any (though I don't understand how _csv.c gets away with line
1579), but what I *did* find were absolutely masses of what seemed
like unnecessary increfs. Consider this code from _hotshot.c:
Py_INCREF(&LogReaderType);
PyModule_AddObject(module, "LogReaderType",
(PyObject *)&LogReaderType);
Py_INCREF(&ProfilerType);
PyModule_AddObject(module, "ProfilerType",
(PyObject *)&ProfilerType);
if (ProfilerError == NULL)
ProfilerError = PyErr_NewException("hotshot.ProfilerError",
NULL, NULL);
if (ProfilerError != NULL) {
Py_INCREF(ProfilerError);
PyModule_AddObject(module, "ProfilerError", ProfilerError);
}
The first two calls are fine; it was an incref like this that was
missing in threadmodule.c. The second seems like a reference "leak":
PyErr_NewException returns a new reference, then the
Py_INCREF/PyModule_AddObject pair is refcount neutral, so control
falls off the end of the function owning a reference to ProfilerError.
I think the Py_INCREF should just be removed, but I'm wondering if I'm
missing something...
Cheers,
mwh
--
MacOSX: Sort of like a pedigree persian cat. Very sleek, very
sexy, but a little too prone to going cross-eyed, biting you on
your thumb and then throwing up on your trousers.
-- Jim's pedigree of operating systems, asr
___
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] Compiling Python with Intel compiler?
On Tue, 14 Jun 2005, "Martin v. Löwis" wrote: > 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.org/sf/1162001 > There is also a patch, python.org/sf/1162023 which works around > the bug. I don't like the work-around, because it assumes that the > compiler binary is called "icc", however, it might be called just > "cc" on some installations. I submitted this bug, patch, and the c.l.p posting and thank Martin for his help with them all. Martin's reservations on the workaround are correct but I can't make more time right now to fix autoconf "properly." To be honest, if icc were more gcc-compatible and returned an error code for -OPT:Olimit=0, that would obviate the need for any patch to Python. I never published these results before but here's what I found in terms of performance (full results available on request): $ python pybench.py -s icc-python -c fedora-python | tail -n 4 Average round time:3677.00 ms -15.95% *) measured against: fedora-python (rounds=10, warp=20) $ python pybench.py -s icc-xN-python -c fedora-python | tail -n 4 Average round time:3911.00 ms -10.61% *) measured against: fedora-python (rounds=10, warp=20) fedora-python: Python 2.4/GCC 3.4.2 20041017 from python.org yum repository icc-python: Python 2.4/icc (8.1) -pthread -fno-strict-aliasing -DNDEBUG -O3 icc-python-xN: Python2.4/icc (8.1) -pthread -fno-strict-aliasing -DNDEBUG -O3 -xN Intel Pentium 4 2.66GHz; 512 KB cache; 507644 kB RAM; Linux 2.6.11-1.14_FC3 While a 16% speedup is nothing to sneeze at, I felt I wasted a lot of time dealing with incompatibilities with extension modules and libcprts.so, and so I no longer run it on my desktop. I do use it for heavy computes on our compute farm when I'm not using extension modules. [Guido] > I think that if someone puts some time in this, they should get a > free Intel T-shirt. I'll accept a free Intel T-shirt if one is offered but I'll probably pass it on to our long-suffering sysadmins who have spent even more time dealing with icc, yet remain evangelists for it. Since this was my first message to python-dev, I think the custom is to introduce myself. I'm a PhD student at the University of Cambridge studying computational biology. I've been using Python for the last three years and have loved almost every minute of it. I've written sequence alignment algorithms in Pyrex, glue to genome database APIs in Jython, and a whole lot of other stuff using CPython. We run Python on a 1145-CPU compute farm that consists of Alpha/Tru64 and Intel/Linux boxes. -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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
> > I believe that Algol 68 loops looked like the following (in somewhat > > more Python-like terms): > > > > [for [from ] [step ] to ] > > [while ] > > do od > As far as I remember, it was: > do > > while > > od > It might be that this could be preceded by a 'for' clause, but memory > fails me there. To be completely sure, I dug out my copy of the "Informal Introduction to Algol 68" by Lindsey and van der Meulen. This book is the official Algol 68 tutorial book. It describes the "loop clause" as follows: for some int identifier, which is hereby declared from some meek int unit by some other meek int unit to a third meek int unit while a meek bool enquiry-clause do a void serial-clause od where any of these keywords and its sequel can be omitted, except for "do" or "od". Here, the term "meek" refers to how aggressively the compiler should try to convert the result to int; it specifies, for example, that if after "from" you write the name of a procedure without arguments, that procedure will be called instead of using the procedure itself as a starting point (which would be nonsensical). ___ 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] refcounting vs PyModule_AddObject
Michael> So I went looking for other instances of the same problem. I Michael> didn't find any (though I don't understand how _csv.c gets away Michael> with line 1579)... Same reason the Py_INCREF of ProfileError isn't necessary I think. PyDict_New() returns a new reference which is passed onto PyModule_AddObject(). No Py_DECREF of the dialects dict occurs, so it exits reference-neutral w.r.t. the dialects object. 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] refcounting vs PyModule_AddObject
Skip Montanaro <[EMAIL PROTECTED]> writes: > Michael> So I went looking for other instances of the same problem. I > Michael> didn't find any (though I don't understand how _csv.c gets away > Michael> with line 1579)... > > Same reason the Py_INCREF of ProfileError isn't necessary I think. > PyDict_New() returns a new reference which is passed onto > PyModule_AddObject(). No Py_DECREF of the dialects dict occurs, so it exits > reference-neutral w.r.t. the dialects object. Oops; I meant line 1590. Cheers, mwh -- Windows 2000: Smaller cow. Just as much crap. -- Jim's pedigree of operating systems, asr ___ 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] refcounting vs PyModule_AddObject
Michael> ... (though I don't understand how _csv.c gets away Michael> with line 1579)... Michael> Oops; I meant line 1590. Hmmm... Me either. Is it possible it was just never DECREF'd? I checked in the obvious fix on both head and the 2.4 release branch. 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] refcounting vs PyModule_AddObject
Hi Michael,
On Wed, Jun 15, 2005 at 01:35:35PM +0100, Michael Hudson wrote:
> if (ProfilerError == NULL)
> ProfilerError = PyErr_NewException("hotshot.ProfilerError",
>NULL, NULL);
> if (ProfilerError != NULL) {
> Py_INCREF(ProfilerError);
> PyModule_AddObject(module, "ProfilerError", ProfilerError);
> }
I think the Py_INCREF is needed here. The ProfilerError is a global
variable that needs the extra reference. Otherwise, a malicious user
could do "del _hotshot.ProfilerError" and have it garbage-collected
under the feet of _hotshot.c which still uses it. What I don't get is
how ProfilerError could fail to be NULL in the first 'if' above, but
that's a different matter.
While we're at strange refcounting problems, PyModule_AddObject() only
decrefs its last argument if no error occurs. This is probably wrong.
In general I've found that the C modules' init code is fragile. This
might be due to the idea that it runs only once anyway, and global
C-module objects are immortal anyway, so sloppiness sneaks in. But for
example, the following is common:
m = Py_InitModule3("xxx", NULL, module_doc);
Py_INCREF(&Xxx_Type);
PyModule_AddObject(m, "Xxx", (PyObject *)&Xxx_Type);
This generates a segfault if Py_InitModule3() returns NULL (however rare
that situation is).
A bientot,
Armin
___
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] [Python-checkins] python/dist/src/Modules _csv.c, 1.37, 1.38
Hi Skip, On Wed, Jun 15, 2005 at 06:35:10AM -0700, [EMAIL PROTECTED] wrote: > Why this worked is a bit mystical. Perhaps it never gets freed because the > object just happens never to be DECREF'd (but that seems unlikely). > /* Add the Dialect type */ > + Py_INCREF(&Dialect_Type); > if (PyModule_AddObject(module, "Dialect", (PyObject *)&Dialect_Type)) > return; Hum, you probably don't want to know, but it works just fine to forget a Py_INCREF before PyModule_AddObject() for the following reason: 1. the reference is stored in the module's dict, so the object is kept alive from there. 2. after the module initialization code is completed, the import mechanism make a copy of the dict (!) just in case some users wants to reload() the module (!!) in which case the module's dict is simplify overwritten with the copy again (!!!). So there is a reference left to the object from this hidden dict, and no way for the user to kill it -- short of using gc.getreferrers(), which is how I figured this out, but gc.getreferrers() is officially dangerous. So unlike what I thought in my previous e-mail, even if the user deletes the entry in the module's normal dict, nothing bad can happend because of this particular feature of import... So it just works. Hum. Armin ___ 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] refcounting vs PyModule_AddObject
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi Michael,
>
> On Wed, Jun 15, 2005 at 01:35:35PM +0100, Michael Hudson wrote:
>> if (ProfilerError == NULL)
>> ProfilerError = PyErr_NewException("hotshot.ProfilerError",
>>NULL, NULL);
>> if (ProfilerError != NULL) {
>> Py_INCREF(ProfilerError);
>> PyModule_AddObject(module, "ProfilerError", ProfilerError);
>> }
>
> I think the Py_INCREF is needed here. The ProfilerError is a global
> variable that needs the extra reference. Otherwise, a malicious user
> could do "del _hotshot.ProfilerError" and have it garbage-collected
> under the feet of _hotshot.c which still uses it.
Hmm. Point. But then how doesn't this apply to things like 'del
thread._local'? (after my recent fix)
> What I don't get is how ProfilerError could fail to be NULL in the
> first 'if' above, but that's a different matter.
Well, could it fail to be NULL in the multiple interpreters case?
Though I'm not at all sure that reusing is wise in that case...
> While we're at strange refcounting problems, PyModule_AddObject() only
> decrefs its last argument if no error occurs. This is probably wrong.
Quite probably :-/
> In general I've found that the C modules' init code is fragile. This
> might be due to the idea that it runs only once anyway, and global
> C-module objects are immortal anyway, so sloppiness sneaks in.
Oh yes.
Cheers,
mwh
--
It's actually a corruption of "starling". They used to be carried.
Since they weighed a full pound (hence the name), they had to be
carried by two starlings in tandem, with a line between them.
-- Alan J Rosenthal explains "Pounds Sterling" on asr
___
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] [Python-checkins] python/dist/src/Modules _csv.c, 1.37, 1.38
Armin Rigo <[EMAIL PROTECTED]> writes: > Hi Skip, > > On Wed, Jun 15, 2005 at 06:35:10AM -0700, [EMAIL PROTECTED] wrote: >> Why this worked is a bit mystical. Perhaps it never gets freed because the >> object just happens never to be DECREF'd (but that seems unlikely). >> /* Add the Dialect type */ >> +Py_INCREF(&Dialect_Type); >> if (PyModule_AddObject(module, "Dialect", (PyObject >> *)&Dialect_Type)) >> return; > > Hum, you probably don't want to know, but it works just fine to forget > a Py_INCREF before PyModule_AddObject() for the following reason: No, it's more complicated than that, at least in an embedded scenario (see bug #1220756). I don't understand how thread._local differed from _cvs.Dialect, though. Cheers, mwh -- faassen: anyway, if nothing else flapping your arms running around will at least give an impression of activity. :) ___ 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] python running in several threads
Thanks both for answers, I read some articles you link and I'd to say - alot discussion around! I also found some notes that mod_python use some technique other than GIL to allow multi-threading in Apache 2.0. Does someone know anything closer? Any links or so? Sorry I raise this old stuff again. Martin Just short notes: > Removing the GIL is easy, but then the interpreter crashes in cases of > simultaneous accesses to dictionaries, reference counters, etc. I know. But under mine conditions is impossible to share dictionaty or ref.counters so this do not happen. This dont happen neither on web server running simmultaniously several .py scripts (same conditions) > This is just not true. On a single-processor machine, the GIL does > *not* degrade performance. Instead, it increases throughput (and > thus performance). Under bigger load yes. It degrades a little under small load, but its usually not big problem. > On a multi-processor machine, you often use multiple operating > system processes to serve request (e.g. in CGI or Apache mpm-prefork, > or even the typical mpm-worker configuration). If you then have > different processes running Python, they don't interfere with > each other at all. Unfortunatelly many configurations dont do that. I run several servers with hyperthreading processors and none of them runs two IISs or apaches just for load-balance python scripts. Regards, Martin ___ 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 question
On 6/15/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > In gen.throw(), are all three arguments required? Or do the value and > traceback Nones need to be listed explicitly? > >g.throw(MyException) > > or > >g.throw(MyException, None, None) > > FWIW, I prefer the former. That will make throw() as flexible as the raise > statement. I don't particularly care much; the analogy with raise makes sense, but the PEP carefully only calls it with 3 arguments, and since there are no use cases outside the PEP, the simpler implementation (requiring 3 arguments) makes more sense to me. If you want to implement this part, feel free to make it the way you like! I consider PEP 343 as accepted at this point as it ever will be; additional tweaks will be found during implementation. -- --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] [Python-checkins] python/dist/src/Modules _csv.c, 1.37, 1.38
Hi Michael, On Wed, Jun 15, 2005 at 03:26:00PM +0100, Michael Hudson wrote: > > Hum, you probably don't want to know, but it works just fine to forget > > a Py_INCREF before PyModule_AddObject() for the following reason: > > No, it's more complicated than that, at least in an embedded > scenario (see bug #1220756). Uh, yes, indeed. I guess that my explanations don't survive an interpreter shutdown, after which the reference counter of the object effectively drops to zero. I don't see how this doesn't crash Python when you exit. It could be that the gc is not called after the reference from the import mechanism was effectively removed -- type objects after a PyType_Ready() are full of ref cycles. But it's all quite obscure. Armin ___ 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] [Python-checkins] python/dist/src/Modules _csv.c, 1.37, 1.38
Armin> But it's all quite obscure. If this was comp.lang.python I'd nominate this for QOTW... 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] refcounting vs PyModule_AddObject
Michael Hudson wrote:
> if (ProfilerError == NULL)
> ProfilerError = PyErr_NewException("hotshot.ProfilerError",
>NULL, NULL);
> if (ProfilerError != NULL) {
> Py_INCREF(ProfilerError);
> PyModule_AddObject(module, "ProfilerError", ProfilerError);
> }
>
>
> I think the Py_INCREF should just be removed, but I'm wondering if I'm
> missing something...
It may be me who is missing something, but...
On reference is added to the dictionary, this is the one the explicit
INCREF creates. The other reference is held in the C variable
ProfilerError; this is the one that creating the exception object
creates.
It is convention that C variables which are explicitly used also
hold their own references, even if they are global, and even if there
is no procedure to clear them. The reason is that they would become
stale if the module object went away. As there is no way to protect
against this case, they just keep a garbage reference.
Regards,
Martin
___
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
Guido van Rossum wrote: > 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. FWIW, I must say I disagree (about "works just fine"). I find PEP 315 counter-intuitive. There's multi-part blocks in Python, but they all behave like a step-sequence where you never come back to a previous step. What I mean is that after entering a finally/except/elif/else, there's no coming back in the try/if/for/while. My first impression when looking at: do: while condition: is that is executed only once. Yes, it would not make any sense since you would write instead: while condition: But, FWIW, that's still my impression. I remember reading Stroustrup saying he was never using do-while loops because he find them counter-intuitive. I feel the same way. I think this is important, because it means that even if do-while is available in C++, some programmers, even the creator himself, are still always using while loops. Even if different languages, I don't see why that would be different in Python. My mental image of a do-while loop looks more like a while-True-if-break Python loop than a PEP315-like loop. For one thing, since the loop content is executed at least once, I think about the condition breaking the loop, not the one maintaining it alive. The keyword 'until' has been proposed; I guess it would be as in Perl where it is an equivalent of "while not". Also, the "do" keyword means nothing to me; maybe something like "loop" would be better. Still, my feeling is that Python is just getting it right with the status quo. Regards, Nicolas ___ 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
Nicolas Fleury <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > 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. > > FWIW, I must say I disagree (about "works just fine"). I find PEP 315 > counter-intuitive. There's multi-part blocks in Python, but they all > behave like a step-sequence where you never come back to a previous > step. What I mean is that after entering a finally/except/elif/else, > there's no coming back in the try/if/for/while. My first impression > when looking at: > > do: > > while condition: > > > is that is executed only once. Indeed. The original poster seems to want something that would work (not necessarily look) like this: do: while with executed once prior to first being tested. But the above is ugly, and you can get much the same effect with Python today: firsttime = True while firsttime or : firsttime = False Seems fairly Pythonic to me. YMMV. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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
Charles Cazabon <[EMAIL PROTECTED]> wrote: > Indeed. The original poster seems to want something that would work (not > necessarily look) like this: > > do: > > while > > with executed once prior to first being tested. But the > above is ugly, and you can get much the same effect with Python today: > > firsttime = True > while firsttime or : > > firsttime = False > > Seems fairly Pythonic to me. YMMV. I agree. It also handles 'else' clauses very well. Heck, even Michael McLay's offering of ... while True: if : break ... doesn't look too bad, and supports the full range of pre and post condition code. Just like the indented "until", it may not be obvious where the breaking condition lies. However, a syntax highlighting editor and a properly located comment or two would solve the problem with "until" and the breaking "if" above. I'm of the opinion that the "do while" and "loop and a half" variants of the while loop should be offered as a recipe somewhere in the documentation. Perhaps not directly in the tutorial (maybe a link), describing quickly how you can use while loops to emulate the full spectrum of looping constructs. - Josiah ___ 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] iter alternate form and *args and **kwargs (Was: Wishlist: dowhile)
Jp Calderone:
> for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''):
> f2.write(chunk)
Phillip J. Eby:
> More seriously, I think your translation makes an excellent argument in
> *favor* of having a do/while statement for greater clarity. :)
Michael Chermside
> Interesting... I had the opposite reaction.
I, too, thought that Jp's solution was quite easy to read, though
every few months I forget about iter()'s alternate form again. ;-)
Perhaps one of the things that makes Jp's solution slightly hard to
read is the fact that f1.read must be wrapped in a function (in Jp's
example, a lambda). It reminds me of one of my minor gripes about the
standard lib -- a number of functions that take another function as an
argument don't take *args and **kwargs to be passed to that function
when it's called. The iter() alternate form is a common example of
this. I would prefer that the alternate iter() form was broken off
into another separate function, say, iterfunc(), that would let me
write Jp's solution something like:
for chunk in iterfunc('', f1.read, CHUNK_SIZE):
f2.write(chunk)
Even better would be to add the *args and **kwargs to iter() directly,
but of course, that would be backwards incompatible.
Anyway, in general, I'd like to see the standard lib in Python 3K
convert functions like iter()'s alternate form to functions like
iterfunc(), i.e. provide *args and **kwargs whenever possible.
Steve
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] iter alternate form and *args and **kwargs (Was: Wishlist: dowhile)
Steven Bethard wrote:
> It reminds me of one of my minor gripes about the standard lib -- a
> number of functions that take another function as an argument don't
> take *args and **kwargs to be passed to that function when it's
> called. The iter() alternate form is a common example of this. I
> would prefer that the alternate iter() form was broken off into
> another separate function, say, iterfunc(), that would let me write
> Jp's solution something like:
>
> for chunk in iterfunc('', f1.read, CHUNK_SIZE):
> f2.write(chunk)
How about 2.5's "partial":
for chunk in iter(partial(f1.read, CHUNK_SIZE), ''):
f2.write(chunk)
--
Benji York
___
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
