Jack Diederich wrote:
> If folks like the way this partial set looks I'll convert the rest.
+1 from here (beautifying the standard lib was one of the justifications for
partition, after all).
>
>
> Index: Lib/CGIHTTPServer
Josiah Carlson wrote:
> Also, in the talk he gave at Google on July 21, somewhere around the
> 7:45-11 minute mark, he talks about how 3.x features are to be
> backported to 2.7 or so, specifically so that there is a larger subset
> of Python that will run in both 2.x and 3.x . Smells like an atte
Guido van Rossum wrote:
> Here's the patch (by Hasan Diwan, BTW) for people's perusal. It just
> gets rid of all *uses* of find/rfind from Lib; it doesn't actually
> modify stringobject.c or unicodeobject.c. It doesn't use
> [r]partition()'; someone could look for opportunities to use that
> separ
Guido van Rossum wrote:
>for c in ph.loggerMap.keys():
>if string.find(c.parent.name, alogger.name) <> 0:
>alogger.parent = c.parent
>c.parent = alogger
>
> This is either a really weird way of writing "if not
> c.parent.name.startswith(alogger.n
Guido van Rossum wrote:
> I don't find the current attempts to come up with a better substring
> search API useful.
>
> [...]
>
> I appreciate the criticism on the patch -- clearly it's not ready to
> go in, and more work needs to be put in to actually *improve* the
> code, using [r]partition()
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>> I don't find the current attempts to come up with a better substring
>> search API useful.
>>
>> [...]
>>
>> I appreciate the criticism on the patch -- clearly it's not ready to
>> go in, and more work needs to be put in to actually *improve* th
Nick Coghlan wrote:
> With a variety of "view types", that work like the corresponding builtin type,
> but reference the original data structure instead of creating copies
support for string views would require some serious interpreter surgery, though,
and probably break quite a few extensions...
Jack Diederich writes:
> I make a go at doing an idiomatic convertion [...] patch attached.
>
> WOW, I love partition. In all the instances that weren't a simple "in"
> test I ended up using [r]partition. In some cases one of the returned
> strings gets thrown away but in those cases it is guaran
Michael Chermside wrote:
>> WOW, I love partition. In all the instances that weren't a simple "in"
>> test I ended up using [r]partition. In some cases one of the returned
>> strings gets thrown away but in those cases it is guaranteed to be small.
>> The new code is usually smaller than the old
Fredrik Lundh wrote:
> note that partition provides an elegant solution to an important *subset* of
> all
> problems addressed by find/index.
>
> just like lexical scoping vs. default arguments and map vs. list
> comprehensions,
> it doesn't address all problems right out of the box, and should
On 8/24/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> (which reminds me that speeding up handling of optional arguments to C
> functions
> would be an even better use of this energy)
If this patch: http://python.org/sf/1107887 is integrated with some
of my current work, it should do the job n
On 8/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Specifically his reponse to the "Here's my suggestion:" paragraph.
> Unless I completely misunderstood his response, and his later asking
> whether I want to help author the transition PEP (presumably for at
> least dict.keys(), bur more likel
Zitat von Jack Diederich <[EMAIL PROTECTED]>:
> +if (sep_found):
This should be
if sep_found:
> If folks like the way this partial set looks I'll convert the rest.
Otherwise, it looks fine.
Martin
___
Python-3000 mailing list
On 8/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I know that you are dreaming of a world where all transitions areeasy. But it's just a dream. 3.0 will require hard work and for manylarge apps it will take years to migrate -- the best approach isprobably to make it coincide with a planned ma
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> What I *do* want to do is:
>
> (a) Add an option to Python 2.6 or 2.7 that starts spewing out
> warnings about certain things that will change semantics in 3.0 and
> are hard to detect by source code inspection alone, just like the
> current -Q opti
On 8/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Another change that is unlikely to be available in 2.x is the
> rationalization of comparisons. In 3.0, "1 < 'abc'" will raise a
> TypeError; there's just no way to backport this behavior, since again
> it requires pervasive changes to the i
For doctestst etc., it's easy to create a consistent order:
sorted(X, key=lambda x: (str(type(x)), x))
This sorts by the name of the type first, then by value within each
type. This is assuming the type itself is sortable -- in 3.0, many
types won't be sortable, e.g. dicts. (Even in 2.x, sets i
Jim Jewett writes:
> Given an arbitrary collection of objects, I want to be able to order
> them in a consistent manner, at least within a single interpreter
> session.
I think this meets your specifications:
>>> myList = [2.5, 17, object(), 3+4j, 'abc']
>>> myList.sort(key=id)
I prefer Guido's
Walter Dörwald wrote:
[...]
> Using find(), the code looks like this:
>
> def splitfind(s):
> pos = 0
> while True:
> posstart = s.find("{", pos)
> if posstart < 0:
> break
> posarg = s.find(" ", posstart)
> if posarg < 0:
> break
>
Fredrik Lundh wrote:
> (on the other hand, "s[:len(t)] == t" is usually faster than
> "s.startswith(t)" for short
> prefixes,
That's surprising. Any idea why this might be?
--
Greg
___
Python-3000 mailing list
[email protected]
http://mail.python
I spent my time at the Google sprint working on removing simple slices from Py3k, in the p3yk-noslice branch. The work is pretty much done, except for some minor details and finishing touches. There are a few items that should probably be discussed, though.
The state of the tree: - The SLICE, STORE
[Fredrik Lundh]
>> (on the other hand, "s[:len(t)] == t" is usually faster than
"s.startswith(t)" for short
>> prefixes,
[Greg Ewing]
> That's surprising. Any idea why this might be?
Perhaps it has to do with the rest of his message ;-):
>> (which reminds me that speeding up handling of optional
Tim Peters wrote:
> Perhaps it has to do with the rest of his message ;-):
>
>>>(which reminds me that speeding up handling of optional arguments
>>>to C functions would be an even better use of this energy)
Until a few moments ago, I didn't know that str.startswith()
had any optional arguments,
Here is a quick status of the int_unification branch,
summarizing what I did at the Google sprint in NYC.
- the int type has been dropped; the builtins int and long
now both refer to long type
- all PyInt_* API is forwarded to the PyLong_* API. Little
changes to the C code are necessary; the m
[EMAIL PROTECTED] wrote:
> I'm not sure whether this performance change is
> acceptable; at this point, I'm running out of ideas
> how to further improve the performance.
without really digging into the patch, is it perhaps time to switch to
unboxed integers for the CPython interpreter ?
(suppo
Tim Peters wrote:
> [Greg Ewing]
>> That's surprising. Any idea why this might be?
>
> Perhaps it has to do with the rest of his message ;-):
>
>>> (which reminds me that speeding up handling of optional arguments
>>> to C functions would be an even better use of this energy)
in my experience,
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > I'm not sure whether this performance change is
> > acceptable; at this point, I'm running out of ideas
> > how to further improve the performance.
>
> without really digging into the patch, is it perhaps time to switch
27 matches
Mail list logo
