Josiah Carlson wrote:
> In the integer case, it reminds me of James Knight's tagged integer
> patch to 2.3 [1]. If using long exclusively is 50% slower, why not try
> the improved speed approach?
looks like GvR was -1000 on this idea at the time, though...
> Also, depending on the objects, one
Fredrik Lundh wrote:
> 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
Nick Coghlan wrote:
>> 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,
Thomas Wouters wrote:
> - There's no way to figure out the size of a Py_ssize_t from Python
> code, now. test_support was using a simple-slice to figure it out. I'm
> not sure if there's really a reason to do it -- I don't quite understand
> the use of it.
This isn't quite true, but I will adm
Fredrik Lundh wrote:
> Nick Coghlan wrote:
>
>>> 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 inter
Nick Coghlan wrote:
> I believe you're thinking about something far more sophisticated than what I'm
> suggesting. I'm just talking about a Python data type in a standard library
> module that trades off slower performance with smaller strings (due to extra
> method call overhead) against improved
On Fri, 25 Aug 2006 15:06:13 +0200, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>Nick Coghlan wrote:
>
>> I believe you're thinking about something far more sophisticated than what
>> I'm
>> suggesting. I'm just talking about a Python data type in a standard library
>> module that trades off slower p
Jean-Paul Calderone wrote:
>>> I believe you're thinking about something far more sophisticated than what
>>> I'm
>>> suggesting. I'm just talking about a Python data type in a standard library
>>> module that trades off slower performance with smaller strings (due to extra
>>> method call overhe
On 8/24/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> 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,
On 8/24/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
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 s
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> Jean-Paul Calderone wrote:
>
> >>> I believe you're thinking about something far more sophisticated than
> >>> what I'm
> >>> suggesting. I'm just talking about a Python data type in a standard
> >>> library
> >>> module that trades off slower perfor
On 8/25/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Aside from the scheduled removal of buffer in 3.x, I see no particular
> issue with offering a bytes view and str view in 3.x via two specific
> bytes and str subtypes. With care, very few changes if any would be
> necessary in the str (unico
On Fri, 25 Aug 2006 08:48:34 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 8/25/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>> Aside from the scheduled removal of buffer in 3.x, I see no particular
>> issue with offering a bytes view and str view in 3.x via two specific
>> bytes and str
On 8/24/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Until a few moments ago, I didn't know that str.startswith()
> had any optional arguments
I just looked them up, and they turn out to just be syntactic sugar
for a slice. (Even to the extent of handling omitted arguments as
None.) The stop argu
On 8/25/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> From there, the only quesion is when an operation on a bytes or str
> object should return such a view, and the answer would be never. Return
> views from view objects, the non-views from non-view objects. If you
> want views, wrap your orig
Then you would have to drop the same style of optional arguments from
all string methods.
There is a method to this madness: the slice arguments let you search
through the string without actually making the slice copy. This
matters rarely, but when it does, it can matter a lot -- imagine s
being 1
On 8/25/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >For the record, I think this is a major case of YAGNI. You appear way
> >to obsessed with performance of some microscopic aspect of the
> >language. Please stop firing random proposals until you actually have
> >working code and proof th
On Fri, 25 Aug 2006 10:53:15 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 8/25/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>> >For the record, I think this is a major case of YAGNI. You appear way
>> >to obsessed with performance of some microscopic aspect of the
>> >language. Plea
Nick Coghlan wrote:
> Fredrik Lundh wrote:
>> Nick Coghlan wrote:
>>
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 wou
Jim Jewett wrote:
> The end result is that even if I find a solution that works, I think
> it will be common (and bug-prone) enough that it really ought to be in
> the language, or at least the standard library -- as it is today for
> objects that don't go out of their way to prevent it.
The usua
On 8/25/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >>Twisted's core loop uses string views to avoid unnecessary copying. This
> >>has proven to be a real-world speedup. This isn't a synthetic benchmark
> >>or a micro-optimization.
> >
> >OK, that's the kind of data I was hoping for; if
Josiah Carlson wrote:
> Aside from the scheduled removal of buffer in 3.x, I see no particular
> issue with offering a bytes view and str view in 3.x via two specific
> bytes and str subtypes.
the fact that it's *impossible* to offer a view subtype that's com-
patible with the current PyString C
Guido van Rossum wrote:
> That final remark is a matter of opinion. I've seen too much code that
> mindlessly copied idioms that were supposed to magically speed up
> certain things to believe it. Often, people who don't know what they
> are doing are more worried about speed than people who do, a
Jean-Paul Calderone wrote:
> http://twistedmatrix.com/trac/browser/sandbox/itamar/cppreactor/fusion
This is the same Itamar who, in the talk I linked a few days ago
(http://ln-s.net/D+u) extolled buffer as a very real performance
improvement in fast python networking, and asked for broader and mor
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> But buffer() is on the kick-list for Py3k right now. Perhaps the new
> bytes object will make it possible to write the first example above
> differently; bytes will be mutable which changes everything.
I never learn
"Ron Adam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jim Jewett wrote:
>
>> The end result is that even if I find a solution that works, I think
>> it will be common (and bug-prone) enough that it really ought to be in
>> the language, or at least the standard library -- as it
On 8/25/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > the fact that it's *impossible* to offer a view subtype that's com-
> > patible with the current PyString C API might be an issue, though.
>
> what's the current thinking wrt. the PyString C API, btw. has any of the
> various bytes/wide stri
> the fact that it's *impossible* to offer a view subtype that's com-
> patible with the current PyString C API might be an issue, though.
what's the current thinking wrt. the PyString C API, btw. has any of the
various bytes/wide string design proposals looked at the C API level ?
_
While checking find() uses in the stdlib I noticed that the various
path modules have duplicate code and docstrings for some generic path
manipulations. Delightfully they even have different implementations
and docstrings for identical functions. splitext() is a great bad
example - os2emxpath.spli
Sounds like a great 2.6 project. Beware of things that are
intentionally different between platforms of course!
--Guido
On 8/25/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> While checking find() uses in the stdlib I noticed that the various
> path modules have duplicate code and docstrings for
Paul Prescod wrote:
> I also didn't know about the optional arguments to startswith and wonder
> if they are much used or just cruft.
Looking through the string methods, it appears that only
a few of them, seemingly chosen arbitrarily, have start
and stop arguments.
Seems to me a string-view ob
Ooph, there is some dissonance in the comments and the code. Cut-n-paste
errors I suppose.
-- ntpath.py --
def islink(path):
"""Test for symbolic link. On WindowsNT/95 always returns false"""
return False
# This follows symbolic links, so both islink() and isdir() can be true
# for th
32 matches
Mail list logo
