As those of you playing along at home with python-checkins would know, we're
going to be cutting a 2.3.5c1 shortly (in about 12 hours time).
Can people not in the set of the normal release team (you know the drill)
please hold off on checkins to the branch from about UTC, 26th January
On Wednesday 26 January 2005 01:01, Donovan Baarda wrote:
In this case it turns out to be don't do exec() in a thread, because what
you exec can have all it's signals masked. That turns out to be a hell of
a lot of things; popen, os.command, etc. They all only work OK in a
threaded application
[Anthony Baxter]
I didn't see any replies to the last post, so I'll ask again with a
better subject line - as I said last time, as far as I'm aware, I'm
not aware of anyone having done a fix for the issue Tim identified
( http://www.python.org/sf/1069160 )
So, my question is: Is this
[Anthony Baxter]
I didn't see any replies to the last post, so I'll ask again with a
better subject line - as I said last time, as far as I'm aware, I'm
not aware of anyone having done a fix for the issue Tim identified
( http://www.python.org/sf/1069160 )
So, my question is: Is this
Guido van Rossum wrote:
As a trivial example, here's how to skip the head of a zero-numbered list:
for i, item in enumerate(ABCDEF)[1:]:
print i, item
Is this idea a non-starter, or should I spend my holiday on Wednesday
finishing
it off and writing the documentation and tests
[me]
Since we already have the islice iterator, what's the point?
[Nick]
I'd like to see iterators become as easy to work with as lists are. At the
moment, anything that returns an iterator forces you to use the relatively
cumbersome itertools.islice mechanism, rather than Python's native
Nick Coghlan wrote:
In the example below (printing the first 3 items of a sequence), the fact that
sorted() produces a new iterable list, while reversed() produces an iterator
over the original list *should* be an irrelevant implementation detail from
the
programmer's point of view.
You
Nick Coghlan [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Since we already have the islice iterator, what's the point?
I'd like to see iterators become as easy to work with as lists are. At the
moment, anything that returns an iterator forces you to use the relatively
cumbersome
[Anthony Baxter]
I'm
not aware of anyone having done a fix for the issue Tim identified
( http://www.python.org/sf/1069160 )
[Raymond Hettinger]
Any chance of this getting fixed before 2.4.1 goes out in February?
[Timbot]
It probably won't be fixed by me. It would be better if a
Raymond Hettinger [EMAIL PROTECTED] wrote:
FWIW, someone (Bengt Richter perhaps) once suggested syntactic support
differentiated from sequences but less awkward than a call to
itertools.islice().
itertools.islice(someseq, lo, hi) would be rendered as someseq'[lo:hi].
Just to make sure I'm
It was also agreed that deleting deprecated modules was not needed; it breaks
code and disk space is cheap.
It seems that no longer listing documentation and adding a deprecation
warning
is what is needed to properly deprecate a module. By no longer listing
documentation new
M.-A. Lemburg wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
__str__ and __unicode__ as well as the other hooks were
specifically added for the type constructors to use.
However, these were added at a time where sub-classing
of types was not possible, so it's time now to reconsider
On Tue, 25 Jan 2005 16:21:34 -0600, Skip Montanaro [EMAIL PROTECTED] wrote:
Jim Would it make sense to add an attic (or even deprecated)
Jim directory to the end of sys.path, and move old modules there? This
Jim would make the search for non-deprecated modules a bit faster, and
On Tue, 25 Jan 2005 06:42:57 -0500, Raymond Hettinger
[EMAIL PROTECTED] wrote:
I think tested a method I changed from METH_O to METH_ARGS and could
not measure a difference.
Something is probably wrong with the measurements. The new call does much
more work than METH_O or METH_NOARGS.
Neal Norwitz wrote:
So far it seems there isn't any specific problems with the approach.
There are simply concerns. I not sure it would be best to modify this
patch over many iterations and then make one huge checkin. I also
don't want to lose the changes or the results. Perhaps I should make
Steven Bethard wrote:
If we're really looking for a builtin, wouldn't it be better to go the
route of getattr/setattr and have something like getslice that could
operate on both lists and iterators?
Such a builtin should probably be getitem() rather than getslice() (since
getitem(iterable,
Neal Norwitz [EMAIL PROTECTED] writes:
* not handling more than nine arguments,
There are very few functions I've found that take more than 2
arguments. Should 9 be lower, higher? I don't have a good feel.
From what I've seen, 5 may be more reasonable as far as catching 90%
of the cases.
17 matches
Mail list logo
