On 2006-08-27, Jacob Hallen <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Patrick Maupin <[EMAIL PROTECTED]> wrote:
>
> Unfortunately there is a side effect to slots. They change the behaviour of
> the objects that have slots in a way that can be abused by control freaks
> and stat
Dieter Maurer wrote:
> "Patrick Maupin" <[EMAIL PROTECTED]> writes on 26 Aug 2006 12:51:44 -0700:
> > ...
> > The only
> > problem I personally know of is that the __slots__ aren't inherited,
>
> "__slots__" *ARE* inherited, although the rules may be a bit
> complex.
Yes, I didn't write that corr
"Patrick Maupin" <[EMAIL PROTECTED]> writes on 26 Aug 2006 12:51:44 -0700:
> ...
> The only
> problem I personally know of is that the __slots__ aren't inherited,
"__slots__" *ARE* inherited, although the rules may be a bit
complex.
>>> class B(object):
... __slots__ = ('f1', 'f2',)
...
>>> cla
"Jacob Hallen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Unfortunately there is a side effect to slots. They change the behaviour
of
> the objects that have slots in a way that can be abused by control freaks
> and static typing weenies. This is bad, because the contol freaks s
Jacob Hallen wrote:
> Patrick Maupin <[EMAIL PROTECTED]> wrote:
> >Also, as I noted, I _do_ use them on occasion, so if there really _are_
> >potential pitfalls there, I would like to understand exactly what they
> >are, so my ears perk up whenever I notice a __slots__ discussion, but
> >so far I
In article <[EMAIL PROTECTED]>,
Patrick Maupin <[EMAIL PROTECTED]> wrote:
>I didn't actually sense any dander on your part, so it was probably a
>bit unfortunate that I chose to respond to that particular message. I
>do (rightly or wrongly) sense some dander on Aahz's part, and this was
>the secon
Patrick Maupin wrote:
> The only assertion that was made explicitly enough to be testable came
> about in a followup to Aahz's original post, only AFTER someone asked
> what the side-effects associated with __slots__ were. Aahz responded:
>
> > The main one is that inheritance becomes difficult t
Jarek Zgoda wrote:
> Having that said, should we hope __slots__ would disappear in (some)
> future (tomorrow?!, in next 10 microseconds?!)? Please, don't left us
> hopeless.
>
Are you saying you _do_ hope that __slots__ disappear? Why?
Regards,
Pat
--
http://mail.python.org/mailman/listinfo/p
[EMAIL PROTECTED] wrote:
> Aahz> Taking a look at __slots__ is fine as long as you don't actually
> Aahz> use them.
>
> Gabriel> Why?
>
> Skip>
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/451ad25f9c648404/f4ac2dfde32b16fd?lnk=st&q=Python+__slots__+aahz&rnum=
[EMAIL PROTECTED] napisał(a):
> That said, It's not mentioned on the Python3.0 page of the wiki:
>
> http://wiki.python.org/moin/Python3.0
>
> or in PEP 3000:
>
> http://www.python.org/dev/peps/pep-3000/
>
> and I see no discussion about it in the Python 3000 mailing list archives:
>
Aahz> Taking a look at __slots__ is fine as long as you don't actually
Aahz> use them.
Gabriel> Why?
Skip>
http://groups.google.com/group/comp.lang.python/browse_thread/thread/451ad25f9c648404/f4ac2dfde32b16fd?lnk=st&q=Python+__slots__+aahz&rnum=2#f4ac2dfde32b16fd
Patrick>
[EMAIL PROTECTED] wrote:
> Aahz> Taking a look at __slots__ is fine as long as you don't actually
> Aahz> use them.
>
> Gabriel> Why?
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/451ad25f9c648404/f4ac2dfde32b16fd?lnk=st&q=Python+__slots__+aahz&rnum=2#f4ac2dfde32b16
Aahz wrote:
> Taking a look at __slots__ is fine as long as you don't actually use them.
I remember the recent discussion about such matters... but I don't
understand its dangers fully still.
I assume __slots__ may be removed in Python 3.0, but maybe "experts"
need it now an then. Or maybe a "expe
Aahz> Taking a look at __slots__ is fine as long as you don't actually
Aahz> use them.
Gabriel> Why?
http://groups.google.com/group/comp.lang.python/browse_thread/thread/451ad25f9c648404/f4ac2dfde32b16fd?lnk=st&q=Python+__slots__+aahz&rnum=2#f4ac2dfde32b16fd
Skip
--
http://mail.pyt
At Friday 25/8/2006 11:34, Aahz wrote:
>The results seem okay. Python is a dynamic language, object attributes
>(and methods, etc) are kept inside a dict, where you can add and remove
>them when you like. So using a dict is faster.
>You can also take a look at __slots__
Taking a look at __slots_
Fredrik Lundh wrote:
>> I am, actually, because I would have assumed that attribute access
>> with an object should be faster because lookup can be precompiled.
>
> huh? you're using a reflection API; there's no way the compiler can
> figure out in advance what you're going to pass to getattr().
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>Andre Meyer:
>>
>> Is the test meaningful and are you surprised by the results?
>> I am, actually, because I would have assumed that attribute access
>> with an object should be faster because lookup can be precompiled.
>
>The results see
Andre Meyer wrote:
> So, what it means is that the test is not meaningful, because of the
> different way that object attributes are accessed (not as o.x, which
> could be compiled).
correct, but you may be overestimating what the compiler can do. here's
the byte code for the various cases:
#
Peter Otten wrote:
> $ python -m timeit -s'class A(object): pass' -s 'a = A(); a.alpha = 42'
> 'a.__getattribute__("alpha")'
> 100 loops, best of 3: 0.674 usec per loop
also:
timeit -s "class A(object): pass" -s "a = A(); a.alpha = 42"
"a.__getattribute__('alpha')"
100 loops,
Good points! It's always good to learn from the pros!
So, what it means is that the test is not meaningful, because of the
different way that object attributes are accessed (not as o.x, which
could be compiled).
Nevertheless, the general impression remains that dicts *are* faster
than objects, be
Andre Meyer wrote:
> Is the test meaningful and are you surprised by the results?
surprised by the amount of code you needed to test this, at least. and you
might wish to use the proper spelling for
v = self.obj.__getattribute__(a)
which is
v = getattr(obj, a)
Andre Meyer wrote:
> Hi all
>
> I was wondering about the performance comparison of either using a
> dictionary or an object for a large collection of "things". Therefore
> I have run the attached test. I create a dictionary and an object.
> Both get the same number of items/attributes, respectiv
Andre Meyer:
> Is the test meaningful and are you surprised by the results?
> I am, actually, because I would have assumed that attribute access
> with an object should be faster because lookup can be precompiled.
The results seem okay. Python is a dynamic language, object attributes
(and methods,
Hi all
I was wondering about the performance comparison of either using a
dictionary or an object for a large collection of "things". Therefore
I have run the attached test. I create a dictionary and an object.
Both get the same number of items/attributes, respectively. Then, for
both the values
24 matches
Mail list logo
