On Wed, 17 Oct 2007 15:01:09 -0700, kiilerix wrote:
> On Oct 17, 9:11 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
>> On 10/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> > >>> o = object()
>> > >>> o.foo = 7
>>
>> What makes you think it can't be instantiated directly? You just did
>> it
On Oct 17, 9:11 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On 10/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >>> o = object()
> > >>> o.foo = 7
>
> What makes you think it can't be instantiated directly? You just did
> it. It's not, however, suitable for use as an arbitrary thing t
On 10/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Oct 7, 10:24 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> > $ python -mtimeit -s'class A(object):pass' -s'a=A()' 'a.zop=23'
>
> When I know that all instances of classes inheriting from object have
> a namespace, then I would expect e
On Oct 7, 10:24 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> $ python -mtimeit -s'class A(object):pass' -s'a=A()' 'a.zop=23'
When I know that all instances of classes inheriting from object have
a namespace, then I would expect either that all objects have a
namespace or that it was inherited fr
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
>Aahz wrote:
>> In article <[EMAIL PROTECTED]>,
>> Steven Bethard <[EMAIL PROTECTED]> wrote:
>>>
>>> You can use __slots__ [...]
>>
>> Aaaugh! Don't use __slots__!
>>
>> Seriously, __slots__ are for wizards writing appl
Delaney, Timothy (Tim) wrote:
> Licheng Fang wrote:
>
>> This is enlightening. Surely I shouldn't have worried too much about
>> performance before doing some measurement.
>
> And with that statement you have truly achieved enlightenment.
> Or to put it another way ... performance tuning without
Steven Bethard wrote:
> Actually, your posting just used dicts normally.
>
> Kevin is creating a prototype dict with a certain set of keys, and
> then copying that dict and filling in the keys each time he
> creates a new instance. It's basically a poor man's OOP.
And operatively, IMHO, there is
Licheng Fang wrote:
> This is enlightening. Surely I shouldn't have worried too much about
> performance before doing some measurement.
And with that statement you have truly achieved enlightenment.
Or to put it another way ... performance tuning without profiling is a
waste of time.
Tim Delane
Bjoern Schliessmann wrote:
> Kevin wrote:
>> Am I missing something, or am I the only one who explicitly
>> declares structs in python?
>
> Yes -- you missed my posting :)
Actually, your posting just used dicts normally.
Kevin is creating a prototype dict with a certain set of keys, and then
co
Kevin wrote:
> Am I missing something, or am I the only one who explicitly
> declares structs in python?
Yes -- you missed my posting :)
Regards,
Björn
--
BOFH excuse #209:
Only people with names beginning with 'A' are getting mail this week
(a la Microsoft)
--
http://mail.python.org/mailm
On 10/10/07, Kevin <[EMAIL PROTECTED]> wrote:
> Am I missing something, or am I the only one who explicitly declares
> structs in python?
> For example:
> FileObject = {
> "filename" : None,
> "path" : None,
> }
>
> fobj = FileObject.copy()
> fobj["filename"] = "passwd"
> fobj["path"] =
Kevin wrote:
> Am I missing something, or am I the only one who explicitly declares
> structs in python?
>
> For example:
> FileObject = {
> "filename" : None,
> "path" : None,
> }
>
> fobj = FileObject.copy()
> fobj["filename"] = "passwd"
> fobj["path"] = "/etc/"
Yes, I think this i
Am I missing something, or am I the only one who explicitly declares
structs in python?
For example:
FileObject = {
"filename" : None,
"path" : None,
}
fobj = FileObject.copy()
fobj["filename"] = "passwd"
fobj["path"] = "/etc/"
Kevin Kelley
On 10/7/07, Licheng Fang <[EMAIL PROTECTED
On Oct 8, 4:24 am, [EMAIL PROTECTED] (Alex Martelli) wrote:
> Licheng Fang <[EMAIL PROTECTED]> wrote:
>
>...
>
> > Python Tutorial says an empty class can be used to do this. But if
> > namespaces are implemented as dicts, wouldn't it incur much overhead
> > if one defines empty classes as such
Aahz wrote:
> In article <[EMAIL PROTECTED]>,
> Steven Bethard <[EMAIL PROTECTED]> wrote:
>> You can use __slots__ [...]
>
> Aaaugh! Don't use __slots__!
>
> Seriously, __slots__ are for wizards writing applications with huuuge
> numbers of object instances (like, millions of instances).
You
Steven D'Aprano wrote:
> On Mon, 08 Oct 2007 15:15:36 +0200, Diez B. Roggisch wrote:
>
>>> Well, I've read the thread, and I've read the thread it links to, and
>>> for the life of me I'm still no clearer as to why __slots__ shouldn't
>>> be used except that:
>>>
>>> 1 Aahz and Guido say __slots
On Mon, 08 Oct 2007 15:15:36 +0200, Diez B. Roggisch wrote:
>> Well, I've read the thread, and I've read the thread it links to, and
>> for the life of me I'm still no clearer as to why __slots__ shouldn't
>> be used except that:
>>
>> 1 Aahz and Guido say __slots__ are teh suxxor;
>>
>> 2 rumou
Steven D'Aprano wrote:
> On Sun, 07 Oct 2007 21:27:31 -0700, Aahz wrote:
>
>> In article <[EMAIL PROTECTED]>, Steven
>> Bethard <[EMAIL PROTECTED]> wrote:
>>>
>>>You can use __slots__ [...]
>>
>> Aaaugh! Don't use __slots__!
>>
>> Seriously, __slots__ are for wizards writing applications wit
On Sun, 07 Oct 2007 21:27:31 -0700, Aahz wrote:
> In article <[EMAIL PROTECTED]>, Steven
> Bethard <[EMAIL PROTECTED]> wrote:
>>
>>You can use __slots__ [...]
>
> Aaaugh! Don't use __slots__!
>
> Seriously, __slots__ are for wizards writing applications with huuuge
> numbers of object instanc
Brian Elmegaard a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]>
> writes:
>
>> Use dicts, not lists or tuples:
>>
>> a = dict(name='yadda', val=42)
>> print a['name']
>> print a['val']
>
> I guess you will then need a list or tuple to store the dicts?
Should be a list then IMHO. But then it'
On Oct 7, 7:58 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> If you REALLY pine for Pascal's records, you might choose to inherit
> from ctypes.Structure, which has the additional "advantages" of
> specifying a C type for each field and (a real advantage;-) creating an
> appropriate __init__ metho
On Oct 8, 12:27 am, [EMAIL PROTECTED] (Aahz) wrote:
>
> Aaaugh! Don't use __slots__!
+1 QOTW ;)
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
>
>You can use __slots__ [...]
Aaaugh! Don't use __slots__!
Seriously, __slots__ are for wizards writing applications with huuuge
numbers of object instances (like, millions of instances). For an
extended thread about t
Alex Martelli wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>> class Record(object):
>> __slots__ = ["x", "y", "z"]
>>
>> has a couple of major advantages over:
>>
>> class Record(object):
>> pass
>>
>> aside from the micro-optimization that classes using __slots__ are faster
>> and s
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sun, 07 Oct 2007 13:24:14 -0700, Alex Martelli wrote:
>
> > And yes, you CAN save about 1/3 of those 85 nanoseconds by having
> > '__slots__=["zop"]' in your class A(object)... but that's the kind of
> > thing one normally does only to tiny parts of
On Sun, 07 Oct 2007 13:24:14 -0700, Alex Martelli wrote:
> And yes, you CAN save about 1/3 of those 85 nanoseconds by having
> '__slots__=["zop"]' in your class A(object)... but that's the kind of
> thing one normally does only to tiny parts of one's program that have
> been identified by profilin
On 8/10/2007 4:14 AM, Steven Bethard wrote:
> Licheng Fang wrote:
>> Python is supposed to be readable, but after programming in Python for
>> a while I find my Python programs can be more obfuscated than their C/C
>> ++ counterparts sometimes. Part of the reason is that with
>> heterogeneous lists
Licheng Fang wrote:
> Python is supposed to be readable, but after programming in Python for
> a while I find my Python programs can be more obfuscated than their C/C
> ++ counterparts sometimes. Part of the reason is that with
> heterogeneous lists/tuples at hand, I tend to stuff many things into
On Oct 7, 1:07 pm, Licheng Fang <[EMAIL PROTECTED]> wrote:
> Python is supposed to be readable, but after programming in Python for
> a while I find my Python programs can be more obfuscated than their C/C
> ++ counterparts sometimes. Part of the reason is that with
> heterogeneous lists/tuples at
Licheng Fang <[EMAIL PROTECTED]> wrote:
...
> Python Tutorial says an empty class can be used to do this. But if
> namespaces are implemented as dicts, wouldn't it incur much overhead
> if one defines empty classes as such for some very frequently used
> data structures of the program?
Just mea
Bruno Desthuilliers <[EMAIL PROTECTED]>
writes:
> Use dicts, not lists or tuples:
>
> a = dict(name='yadda', val=42)
> print a['name']
> print a['val']
I guess you will then need a list or tuple to store the dicts?
I might have made it with a list of class instances:
class a:
def __init__(s
George Sakkis wrote:
> On Oct 7, 2:14 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
>> Licheng Fang wrote:
>>> Python is supposed to be readable, but after programming in Python for
>>> a while I find my Python programs can be more obfuscated than their C/C
>>> ++ counterparts sometimes. Part of th
On Oct 7, 2:14 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Licheng Fang wrote:
> > Python is supposed to be readable, but after programming in Python for
> > a while I find my Python programs can be more obfuscated than their C/C
> > ++ counterparts sometimes. Part of the reason is that with
>
Licheng Fang wrote:
> struct nameval {
> char * name;
>int val;
> } a;
>
> a.name = ...
> a.val = ...
>
> becomes cryptic
>
> a[0] = ...
> a[1] = ...
?!
(1)
a = {}
a["name"] = ...
a["val"] = ...
(2)
NAME = 0
VAL = 1
a=[]
a[NAME] = ...
a[VAL] = ...
> Python Tutorial says an empty cla
Licheng Fang a écrit :
> Python is supposed to be readable, but after programming in Python for
> a while I find my Python programs can be more obfuscated than their C/C
> ++ counterparts sometimes. Part of the reason is that with
> heterogeneous lists/tuples at hand, I tend to stuff many things in
Licheng Fang wrote:
> Python is supposed to be readable, but after programming in Python for
> a while I find my Python programs can be more obfuscated than their C/C
> ++ counterparts sometimes. Part of the reason is that with
> heterogeneous lists/tuples at hand, I tend to stuff many things into
36 matches
Mail list logo
