On Tuesday 25 January 2005 23:30, Skip Montanaro wrote:
> Python's setup.py has grown way out of control. I'm trying to build
> and install Python 2.4.0 on a Solaris system with Tcl/Tk installed in a
> non-standard place and I can't figure out the incantation to tell setup.py
> to look whe
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
I just submitted a bug report for setup.py:
http://python.org/sf/1109602
It begins:
Python's setup.py has grown way out of control. I'm trying to build and
install Python 2.4.0 on a Solaris system with Tcl/Tk installed in a
non-standard place and I can't figure out the incantati
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, slice(s
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
a
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 MET
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
Jim> would make it easier to verify that new code isn't depending
Jim
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 fas
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
whet
> 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 progr
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 s
[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 bett
> Iterators are for single sequential access. It's a feature that you
> have to import itertools (or at least that you have to invoke its
> special operations) -- iterators are not sequences and shouldn't be
> confused with such.
FWIW, someone (Bengt Richter perhaps) once suggested syntactic suppo
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
> cumber
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
[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 nativ
On Jan 25, 2005, at 12:29, David Ascher wrote:
Steve Holden wrote:
Modulo some SQLServer features we're using.
Well free-text indexing would be my first guess. Anything else of
interest? MySQL's free text indexing really sucks compared with SQL
Server's, which to my mind is a good justification f
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 documenta
Steve Holden wrote:
Modulo some SQLServer features we're using.
Well free-text indexing would be my first guess. Anything else of
interest? MySQL's free text indexing really sucks compared with SQL
Server's, which to my mind is a good justification for the Microsoft
product.
Freetext search is o
[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
> [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
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 applic
G'day,
From: "Anthony Baxter" <[EMAIL PROTECTED]>
> On Thursday 20 January 2005 12:43, Donovan Baarda wrote:
> > On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
> > > The main oddness about python threads (before 2.3) is that they run
> > > with all signals masked. You could play with a
Batista, Facundo wrote:
I think that breaking the common idiom...
for e in something[:]:
something.remove(e)
is a no-no...
The patch doesn't change existing behaviour - anything which is already
sliceable (e.g. lists) goes through the existing __getitem__ or __getslice__
code paths.
All
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 itertools.islice mechanism, rather than Python's na
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
(in
> > In theory, I don't see how you could improve on METH_O and METH_NOARGS.
> > The only saving is the time for the flag test (a predictable branch).
> > Offsetting that savings is the additional time for checking min/max args
> > and for constructing a C call with the appropriate number of args.
27 matches
Mail list logo
