On 2005 Feb 19, at 06:03, Nick Coghlan wrote:
This is something I've typed way too many times:
Py> class C():
File "", line 1
class C():
^
SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a
function with no arguments still requires parenthe
On Fri, Feb 18, 2005 at 10:06:24AM +0100, "Martin v. L?wis" wrote:
> Donovan Baarda wrote:
> >This patch keeps the current md5c.c, md5module.c files and adds the
> >following; _hashopenssl.c, hashes.py, md5.py, sha.py.
> [...]
> >If all we wanted to do was fix the md5 module
>
> If we want to fix
From: "Martin v. Löwis" <[EMAIL PROTECTED]>
> Donovan Baarda wrote:
> > This patch keeps the current md5c.c, md5module.c files and adds the
> > following; _hashopenssl.c, hashes.py, md5.py, sha.py.
> [...]
> > If all we wanted to do was fix the md5 module
>
> If we want to fix the licensing issues
From: "Armin Rigo" <[EMAIL PROTECTED]>
> Hi Tim,
>
>
> On Thu, Feb 17, 2005 at 01:44:11PM -0500, Tim Peters wrote:
> > >256 ** struct.calcsize('P')
> >
> > Now if you'll just sign and fax a Zope contributor agreement, I'll
> > upgrade ZODB to use this slick trick .
>
> I hereby donate this lin
This is something I've typed way too many times:
Py> class C():
File "", line 1
class C():
^
SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no
arguments still requires parentheses in the definition statement, but defining
> I'm very glad you introduced the optimization of building small
> constant tuples at compile-time. IMO, that was a pure win.
It's been out in the wild for a while now with no issues. I'm somewhat
happy with it.
> the transformation isn't semantically correct on the
> face of it.
Well that
Gregory P. Smith wrote:
fyi - i've updated the python sha1/md5 openssl patch. it now replaces
the entire sha and md5 modules with a generic hashes module that gives
access to all of the hash algorithms supported by OpenSSL (including
appropriate legacy interface wrappers and falling back to the ol
[Tim Peters]
>> grow the list to its final size once, at the start (overestimating if
>> you don't know for sure). Then instead of appending, keep an index to
>> the next free slot, same as you'd do in C. Then the list guts never
>> move, so if that doesn't yield the same kind of speedup without
[Raymond Hettinger]
> ...
> The problem with the transformation was that it didn't handle the case
> where x was non-hashable and it would raise a TypeError instead of
> returning False as it should.
I'm very glad you introduced the optimization of building small
constant tuples at compile-time.
> >>Wouldn't it help a lot more if the compiler would detect that
> >>(1,2,3) is immutable and convert it into a constant at
> >>compile time ?!
> >
> >
> > Yes. We've already gotten it to that point:
. . .
>
> Cool. Does that work for all tuples in the program ?
It is limited to just tuples of
[Phillip J. Eby]
>> Still, it's rather interesting that tuple.__contains__ appears slower than a
>> series of LOAD_CONST and "==" operations, considering that the tuple
>> should be doing basically the same thing, only> without bytecode fetch-and-
>> decode overhead. Maybe it's tuple.__contains__
On Feb 18, 2005, at 17:51, Tim Peters wrote:
grow the list to its final size once, at the start (overestimating if
you don't know for sure). Then instead of appending, keep an index to
the next free slot, same as you'd do in C. Then the list guts never
move, so if that doesn't yield the same kind
[Travis]
> > then how about if arrayobjects can make it in the core, then a check for
> > a rank-0 integer-type
> > arrayobject is allowed before raising an exception?
Sure, *if* you can get the premise accepted.
[David]
> Following up on Bob's point, maybe making rank-0 integer type
> arrayobjec
Raymond Hettinger wrote:
Wouldn't it help a lot more if the compiler would detect that
(1,2,3) is immutable and convert it into a constant at
compile time ?!
Yes. We've already gotten it to that point:
Python 2.5a0 (#46, Feb 15 2005, 19:11:35) [MSC v.1200 32 bit (Intel)] on
win32
import dis
dis.d
On Fri, 18 Feb 2005 15:40:54 -0700, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >>Would it be possible to change
> >>
> >>_PyEval_SliceIndex in ceval.c
> >>
> >>so that rather than throwing an error if the indexing object is not an
> >>integer, the code first checks t
[Tim Peters]
...
>> Then you allocate a small object, marked 's':
>>
>> bbbsfff
[Evan Jones]
> Isn't the whole point of obmalloc
No, because it doesn't matter what follows that introduction:
obmalloc has several points, including exploiting the GIL, heuris
Guido van Rossum wrote:
Would it be possible to change
_PyEval_SliceIndex in ceval.c
so that rather than throwing an error if the indexing object is not an
integer, the code first checks to see if the object has a
tp_as_number->nb_int method and calls it instead.
I don't think this is the rig
> Wouldn't it help a lot more if the compiler would detect that
> (1,2,3) is immutable and convert it into a constant at
> compile time ?!
Yes. We've already gotten it to that point:
Python 2.5a0 (#46, Feb 15 2005, 19:11:35) [MSC v.1200 32 bit (Intel)] on
win32
>>> import dis
>>> dis.dis(compile
Sorry for taking so long to get back to this thread, it has been one of
those weeks for me.
On Feb 16, 2005, at 2:50, Martin v. Löwis wrote:
Evan then understood the feature, and made it possible.
This is very true: it was a very useful exercise.
I can personally accept breaking the code that sti
On Thu, 2005-02-17 at 22:38, Tim Peters wrote:
Then you allocate a small object, marked 's':
bbbsfff
Isn't the whole point of obmalloc is that we don't want to allocate "s"
on the heap, since it is small? I guess "s" could be an object that
might potentiall
On Feb 18, 2005, at 4:36 PM, David Ascher wrote:
On Fri, 18 Feb 2005 13:28:34 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
Would it be possible to change
_PyEval_SliceIndex in ceval.c
so that rather than throwing an error if the indexing object is not
an
integer, the code first checks to se
[Travis]
> > > Would it be possible to change
> > >
> > > _PyEval_SliceIndex in ceval.c
> > >
> > > so that rather than throwing an error if the indexing object is not an
> > > integer, the code first checks to see if the object has a
> > > tp_as_number->nb_int method and calls it instead.
[Guido
On Fri, 18 Feb 2005 13:28:34 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> > Would it be possible to change
> >
> > _PyEval_SliceIndex in ceval.c
> >
> > so that rather than throwing an error if the indexing object is not an
> > integer, the code first checks to see if the object has a
> >
(More readable second paragraph)
Hello again,
There is a great discussion going on the numpy list regarding a proposed
PEP for multidimensional arrays that is in the works.
During this discussion a problem has resurfaced regarding slicing with
objects that are not IntegerType objects but that ha
Travis Oliphant wrote:
Hello again,
There is a great discussion going on the numpy list regarding a proposed
PEP for multidimensional arrays that is in the works.
During this discussion as resurfaced regarding slicing with objects that
are not IntegerType objects but that
have a tp_as_number->nb
> Would it be possible to change
>
> _PyEval_SliceIndex in ceval.c
>
> so that rather than throwing an error if the indexing object is not an
> integer, the code first checks to see if the object has a
> tp_as_number->nb_int method and calls it instead.
I don't think this is the right solution;
Hello again,
There is a great discussion going on the numpy list regarding a proposed
PEP for multidimensional arrays that is in the works.
During this discussion as resurfaced regarding slicing with objects that
are not IntegerType objects but that
have a tp_as_number->nb_int method to convert
Raymond Hettinger wrote:
Based on some ideas from Skip, I had tried transforming the likes of "x
in (1,2,3)" into "x in frozenset([1,2,3])". When applicable, it
substantially simplified the generated code and converted the O(n)
lookup into an O(1) step. There were substantial savings even if the
Raymond Hettinger:
> tried transforming the likes of "x in (1,2,3)" into "x in
> frozenset([1,2,3])".
>... There were substantial savings even if the set contained only a
single entry.
>... where x was non-hashable and it would raise a TypeError instead of
> returning False as it should.
I
Phillip J. Eby wrote:
>>here's the disassembly:
>
> FYI, that's not a dissassembly of what timeit was actually timing; see
> 'template' in timeit.py.
> As a practical matter, the only difference would probably be the use of
> LOAD_FAST instead of
> LOAD_NAME, as
> timeit runs the code in a fun
At 05:52 PM 2/18/05 +0100, Fredrik Lundh wrote:
Phillip J. Eby wrote:
> Were these timings done with the code that turns (1,2,3) into a constant?
I used a stock 2.4 from python.org, which seems to do this (for tuples,
not for lists).
> Also, I presume that these timings still include extra LOAD_FAS
Phillip J. Eby wrote:
> Were these timings done with the code that turns (1,2,3) into a constant?
I used a stock 2.4 from python.org, which seems to do this (for tuples,
not for lists).
> Also, I presume that these timings still include extra LOAD_FAST operations
> that could be replaced
> wit
At 04:45 PM 2/18/05 +0100, Fredrik Lundh wrote:
Phillip J. Eby wrote:
>>Only contains expressions are translated:
>>
>> "if x in [1,2,3]"
>>
>>currently turns into:
>>
>> "if x in (1,2,3)"
>>
>>and I'm proposing that it go one step further:
>>
>> "if x in Seachset([1,2,3])"
>
> ISTM tha
>> > Raymond then
>> translated
>> >
>> > for x in [1,2,3]:
>> >
>> > to
>> >
>> > for x in frozenset([1,2,3]):
Raymond> That's not right. for-statements are not touched.
Thanks for the correction. My apologies for the misstep.
Skip
Phillip J. Eby wrote:
>>Only contains expressions are translated:
>>
>> "if x in [1,2,3]"
>>
>>currently turns into:
>>
>> "if x in (1,2,3)"
>>
>>and I'm proposing that it go one step further:
>>
>> "if x in Seachset([1,2,3])"
>
> ISTM that whenever I use a constant in-list like that,
At 10:15 AM 2/18/05 -0500, Raymond Hettinger wrote:
Only contains expressions are translated:
"if x in [1,2,3]"
currently turns into:
"if x in (1,2,3)"
and I'm proposing that it go one step further:
"if x in Seachset([1,2,3])"
ISTM that whenever I use a constant in-list like that, it's
> > Raymond then
> translated
> >
> > for x in [1,2,3]:
> >
> > to
> >
> > for x in frozenset([1,2,3]):
That's not right. for-statements are not touched.
> I may be missing something here (didn't follow the whole thread) but
> those two are not functionally equal.
> The docstring on fro
Skip Montanaro wrote:
I suggested that since the standard library code is commonly used as an
example of basic Python principles (that's probably not the right word), it
should uphold that ideal tuple/list distinction. Raymond then translated
for x in [1,2,3]:
to
for x in frozenset([1,2,3]
> I'm unclear why the list in "for x in [1,2,3]" or "if x not in
[1,2,3]"
> can't fairly easily be recognized as a constant and just be placed in
the
> constants array.
That part got done (at least for the if-statement).
The question is whether the type transformation idea should be carried a
st
>> Based on some ideas from Skip, I had tried transforming the likes of
>> "x in (1,2,3)" into "x in frozenset([1,2,3])"
Fredrik> savings in what? time or bytecode size? constructed
Fredrik> micro-benchmarks, or examples from real-life code?
Fredrik> do we have any stat
aahz> This should go into Brett's survey of the Python dev process, not
aahz> as official documentation. It's simply an offer made by some of
aahz> the prominent members of python-dev.
As long as it's referred to from www.python.org/dev that's fine.
Skip
___
Hi Tim,
On Thu, Feb 17, 2005 at 01:44:11PM -0500, Tim Peters wrote:
> >256 ** struct.calcsize('P')
>
> Now if you'll just sign and fax a Zope contributor agreement, I'll
> upgrade ZODB to use this slick trick .
I hereby donate this line of code to the public domain :-)
Armin
_
Donovan Baarda wrote:
This patch keeps the current md5c.c, md5module.c files and adds the
following; _hashopenssl.c, hashes.py, md5.py, sha.py.
[...]
If all we wanted to do was fix the md5 module
If we want to fix the licensing issues with the md5 module, this patch
does not help at all, as it keep
Raymond Hettinger wrote:
> Based on some ideas from Skip, I had tried transforming the likes of "x
> in (1,2,3)" into "x in frozenset([1,2,3])". When applicable, it
> substantially simplified the generated code and converted the O(n)
> lookup into an O(1) step. There were substantial savings eve
44 matches
Mail list logo
