>> skip? was this a real design or a Py3K bluesky idea?
Just about nothing I do is a real design. I don't remember the
weather conditions that day either. I was probably just noodling around
based upon discussions on python-dev that were mutated in my brain by gamma
rays from Alpha Centau
On 5/25/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
>
> > IIRC, Skip had developed a smart version that returned lazy string
> > objects that kept a reference and pointers to the original string
> > (instead of making its own copy of the string components). The string
Steve Holden wrote:
> In actual fact the effbot has lately found itself so permeated with
> Windows that it has become constituionally incapable of using a forward
> slash. Don't know what's with the square brackets though ...
I was thinking maybe that message had resulted from
a Windows and a
Tim Peters wrote:
> PyLong_FromString() only sees the starting
> address, and-- as it always does --parses until it hits a character
> that doesn't make sense for the input base.
This is the bug, then. long() shouldn't be using
PyLong_FromString() to convert its argument, but
something that takes
I will certainly look forward to using it.
On May 25, 2006, at 16:21, Fredrik Lundh wrote:
> does anyone remember? given what we're currently working on,
> implementing it would take roughly no time at all. do people still
> think it's a good idea ?
>
>
>
> __
[Bob Ippolito]
> ...
> Unfortunately, this change to the struct module slightly alters the
> documented API for the following format codes: I, L, q, Q. Currently
> it is documented that those format codes will always return longs,
> regardless of their value.
I view that more as having documented
Python ints are a heck of a lot faster to work with than Python longs
and have the additional benefit that psyco can optimize the hell out of int but can't do
anything at all for long. This is important because psyco is
currently in pretty wide-spread use amongst people who need to
squeeze
Giovanni Bajo wrote:
Fredrik Lundh wrote:
does anyone remember? given what we're currently working on,
implementing it would take roughly no time at all. do people still
think it's a good idea ?
I had enquired this before but got no answer. I assume nobody's workin
Steve Holden wrote:
>
> This reminds me I am tasked with trying to find out what the interface
> to timeit.py is supposed to look like. Raymond, your name has been
> mentioned as someone who took part int he discussions. Google hasn't
> given me a lot to go on. Anyone?
>
IIRC, Guido's words we
Fredrik Lundh wrote:
> does anyone remember? given what we're currently working on,
> implementing it would take roughly no time at all. do people still
> think it's a good idea ?
>
>
I had enquired this before but got no answer. I assume nobody's working on
it at the moment. I also proposed
Fredrik Lundh wrote:
Yes. It went to my todo list and is awaiting some free raymond-cycles
to finish it up. I've been task saturated of late but would like to get
this a number of other patches complete for Py2.5.
no need to wait for any raymond-cycles here; just point me
Fredrik Lundh wrote:
> no need to wait for any raymond-cycles here; just point me to the latest
> version of the proposal, and it'll be in the trunk within 30 minutes.
are these still valid?
http://mail.python.org/pipermail/python-dev/2005-August/055764.html
http://mail.python.org/pip
>Brett provided the following direction:
> >Right, I meant change how it (BaseException) is written. Right now
> >it uses PyMethodDef for magic methods and just uses PyType_New()
> >as a constructor. I was wondering if, for some reason, it would be
> >faster if you used a PyType_Type defi
Raymond Hettinger wrote:
> Fredrik Lundh wrote:
>
>
>>does anyone remember? given what we're currently working on,
>>implementing it would take roughly no time at all. do people still
>>think it's a good idea ?
>>
>>
>>
>>
>>
>
>
> Yes. It went to my todo list and is awaiting some free r
does anyone remember? given what we're currently working on,
implementing it would take roughly no time at all. do people still
think it's a good idea ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Georg Brandl wrote:
> Martin v. Löwis wrote:
>> Fredrik Lundh wrote:
>>> >>> -1 * (1, 2, 3)
>>> ()
>>> >>> -(1, 2, 3)
>>> Traceback (most recent call last):
>>>File "", line 1, in
>>> TypeError: bad operand type for unary -
>>>
>>> We Really Need To Fix This!
>>
>> I can't find this incons
Tim Peters wrote:
> [Raymond Hettinger]
> ...
>> Also, I'm not clear on the rationale for transforming negative
>> repetition counts to zero instead of raising an exception.
>
> There are natural use cases. Here's one: you have a string and want
> to right-justify it to 80 columns with blanks if
Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
>
>>>We Really Need To Fix This!
>>>
>>>[\F]
>>
>>Doesn't the real effbot have /F as sig?
>
>
> yeah, we've had some trouble with fake bots lately. I mean, there's a
> timbot posting to this thread, but I know for sure that the real Tim got
>
Guido van Rossum wrote:
>> We Really Need To Fix This!
>>
>> [\F]
>
> Doesn't the real effbot have /F as sig?
yeah, we've had some trouble with fake bots lately. I mean, there's a
timbot posting to this thread, but I know for sure that the real Tim got
tired of hacking on Python earlier tonig
[Raymond Hettinger]
...
> Also, I'm not clear on the rationale for transforming negative
> repetition counts to zero instead of raising an exception.
There are natural use cases. Here's one: you have a string and want
to right-justify it to 80 columns with blanks if it's shorter than 80.
s
On 5/25/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
>
> > >>> -1 * (1, 2, 3)
> >()
> > >>> -(1, 2, 3)
> >Traceback (most recent call last):
> > File "", line 1, in
> >TypeError: bad operand type for unary -
> >
> >We Really Need To Fix This!
> >
> >
>
> The second one
[Fredrik]
> >>> -1 * (1, 2, 3)
> ()
> >>> -(1, 2, 3)
> Traceback (most recent call last):
>File "", line 1, in
> TypeError: bad operand type for unary -
>
> We Really Need To Fix This!
What's broken? It's generally true that
n*s == s*n == empty_container_of_type_type(s)
whenever s is
Fredrik Lundh wrote:
> >>> -1 * (1, 2, 3)
>()
> >>> -(1, 2, 3)
>Traceback (most recent call last):
> File "", line 1, in
>TypeError: bad operand type for unary -
>
>We Really Need To Fix This!
>
>
The second one doesn't bug me. Unary minus on a sequence is meaningless.
The first is a bit o
On Thu, May 25, 2006 at 09:06:49PM +, Georg Brandl wrote:
>Don't tell me that! I was actually working on a patch right now...
While undoubtedly a performance patch, it wasn't on the list of tasks to do
today. You risk Steve's wrath!
Thanks,
Sean
--
In the end, we will remember not the word
Ronald Oussoren wrote:
> I don't know which one Fredrik thinks is wrong, but I think the result
> of -1*(1,2,3) is very surprising. I'd expect an exception here.
I agree, but this has nothing to do with whether or not the unary -
is supported.
Regards,
Martin
_
On 25-mei-2006, at 23:04, Martin v. Löwis wrote:
> Fredrik Lundh wrote:
> -1 * (1, 2, 3)
>> ()
> -(1, 2, 3)
>> Traceback (most recent call last):
>>File "", line 1, in
>> TypeError: bad operand type for unary -
>>
>> We Really Need To Fix This!
>
> I can't find this inconsistency hor
You're joking right?
On 5/25/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> >>> -1 * (1, 2, 3)
> ()
> >>> -(1, 2, 3)
> Traceback (most recent call last):
>File "", line 1, in
> TypeError: bad operand type for unary -
>
> We Really Need To Fix This!
>
> [\F]
Doesn't the real effbot have /F
Martin v. Löwis wrote:
> Fredrik Lundh wrote:
>> >>> -1 * (1, 2, 3)
>> ()
>> >>> -(1, 2, 3)
>> Traceback (most recent call last):
>>File "", line 1, in
>> TypeError: bad operand type for unary -
>>
>> We Really Need To Fix This!
>
> I can't find this inconsistency horrible.
>
> py> +"Hell
Fredrik Lundh wrote:
> >>> -1 * (1, 2, 3)
> ()
> >>> -(1, 2, 3)
> Traceback (most recent call last):
>File "", line 1, in
> TypeError: bad operand type for unary -
>
> We Really Need To Fix This!
I can't find this inconsistency horrible.
py> +"Hello"
Traceback (most recent call last):
F
>>> -1 * (1, 2, 3)
()
>>> -(1, 2, 3)
Traceback (most recent call last):
File "", line 1, in
TypeError: bad operand type for unary -
We Really Need To Fix This!
[\F]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Guido van Rossum wrote:
> Good catch. I think this would save a certain number of unnecessary
> stat() calls.
>
> But it does change semantics, so we can't fix this in 2.4. In 2.5, we
> should warn hook authors that this might affect them.
>
> The PEP ought to be updated to clarify this.
Okay. T
Good catch. I think this would save a certain number of unnecessary
stat() calls.
But it does change semantics, so we can't fix this in 2.4. In 2.5, we
should warn hook authors that this might affect them.
The PEP ought to be updated to clarify this.
--Guido
On 5/25/06, Georg Brandl <[EMAIL PRO
While working on a patch involving sys.path_importer_cache, I discovered
that if a path_hooks import hook has been found for a given sys.path entry,
but isn't able to import a specific module, find_module() tries to import
the module from this sys.path entry as a regular file.
This results in e.g.
[Jean-Paul Calderone]
>> ...
>> Hmm, one reason could be that the general solution doesn't work:
>>
>> [EMAIL PROTECTED]:~$ python
>> Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
>> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
>> Type "help", "copyright", "credits" or "license" for more inform
On 5/25/06, Runar Petursson <[EMAIL PROTECTED]> wrote:
>
> On 5/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > If you really need this for speed, I recommend you make it a custom
> extension.
> >
> >
> The custom extension is a good idea, and what we do now. But now that the
> long al
On 5/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
If you really need this for speed, I recommend you make it a custom extension.
The custom extension is a good idea, and what we do now. But now
that the long algorithm is so fast, it would be nice to expose
it at least at the C level to use a
Bob Ippolito <[EMAIL PROTECTED]> wrote:
> One problem with buffer() is that it does a memcpy of the buffer. A
> zero-copy version of buffer (a view on some object that implements
> the buffer API) would be nice.
Did buffers change? I seem to remember that there were segfaulting
conditions wh
On May 25, 2006, at 3:28 PM, Jean-Paul Calderone wrote:
> On Thu, 25 May 2006 15:01:36 +, Runar Petursson
> <[EMAIL PROTECTED]> wrote:
>> We've been talking this week about ideas for speeding up the
>> parsing of
>> Longs coming out of files or network. The use case is having a
>> larg
Runar Petursson wrote:
> We've been talking this week about ideas for speeding up the parsing
> of Longs coming out of files or network. The use case is having a
> large string with embeded Long's and parsing them to real longs. One
> approach would be to use a simple slice:
> long(mystring[x
On 5/25/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote:
> Conversion functions taking a start and end are the low-hanging fruit, but
> I think in the long term something that does that described I would prefer.
> I believe that Martin is expecting expecting to have something this week
> to try.
On Thu, 25 May 2006 15:01:36 +, Runar Petursson <[EMAIL PROTECTED]> wrote:
>We've been talking this week about ideas for speeding up the parsing of
>Longs coming out of files or network. The use case is having a large string
>with embeded Long's and parsing them to real longs. One approach wo
On Thu, May 25, 2006 at 03:01:36PM +, Runar Petursson wrote:
>simply limit the scope of the parsing. There are other solutions, using
>buffer-like objects and such, but this seems like a simple win for anyone
>parsing a lot of text. I implemented it in a branch
I'll expand on that a little
We've been talking this week about ideas for speeding up the parsing of Longs coming out of files or network. The use case is having a large string with embeded Long's and parsing them to real longs. One approach would be to use a simple slice:
long(mystring[x:y]) an expensive operation in a tigh
Hi,
I'm trying to port ctypes to darwin/x86 (aka the new intel macs),
which went pretty smooth. I am running into some odd behaviour of
distutils now that I'm trying to port those changes to the trunk.
ctypes uses libffi, which contains source files in various platform-
specific directories,
This is probably orthogonal to the problem, however, you may want to
look into trying to speed up Python/errors.c. This link will probably
not work due to sessions, but click on the latest run for python and
Python/errors.c
http://coverage.livinglogic.de/coverage/web/selectEntry.do?template=2850&
45 matches
Mail list logo
