Problem of Readability of Python

[Licheng Fang]

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
the list and *assume* a structure of the list or tuple, instead of
declaring them explicitly as one will do with C structs. So, what used
to be

struct nameval {
char * name;
int val;
} a;

a.name = ...
a.val = ...

becomes cryptic

a[0] = ...
a[1] = ...

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?

Any elegant solutions?

[Steven Bethard]

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 is the only time I've ever seen that. I think the
normal way of doing this in Python is:

class FileObject(obje ct):
def __init__(self, filename, path):
self.filename = filename
self.path = path

fobj = FileObject(file name='passwd', path='etc')

STeVe

[Joe Riopel]

On 10/10/07, Kevin <wy******@gmail .comwrote:

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/"

I am pretty new to python, but isn't that just a dictionary?

[Bjoern Schliessmann]

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)

[Steven Bethard]

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
copying that dict and filling in the keys each time he creates a new
instance. It's basically a poor man's OOP.

STeVe

[Bjoern Schliessmann]

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 no difference.

Regards,
Björn

--
BOFH excuse #176:

vapors from evaporating sticky-note adhesives

[Aahz]

In article <oc************ *************** ***@comcast.com >,
Steven Bethard <st************ @gmail.comwrote :

>Aahz wrote:

>In article <2t************ *************** ***@comcast.com >,
Steven Bethard <st************ @gmail.comwrote :

>>>
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 clipped me saying that __slots__ are for performance tweaks:

You can use __slots__ to make objects consume less memory and have
slightly better attribute-access performance. Classes for objects
that need such performance tweaks should start like...

I fully agree that __slots__ are for applications with huge numbers of
instances. But if you have that situation, you really do want to be
using __slots__.

Well, then, just make sure to put big honking warnings up whenever you
mention __slots__. ;-)
--
Aahz (aa**@pythoncra ft.com) <* http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.

[kiilerix]

On Oct 17, 9:11 pm, "Chris Mellon" <ar*****@gmail. comwrote:

On 10/17/07, ki******@gmail. com <ki******@gmail .comwrote:

>>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 to stick
attributes on.

Which is a little sad, but a necessary requirement for things like
int() and str() to be small and fast.

So it's an optimization with side effects, giving a special case where
the simple and otherwise "right" way to do it doesn't work? Too bad :-
(

Ok; I'll continue to create dummy classes inheriting from object. And
hope that one day it will be simpler.

Thanks,
Mads

[Marc 'BlackJack' Rintsch]

On Wed, 17 Oct 2007 15:01:09 -0700, kiilerix wrote:

On Oct 17, 9:11 pm, "Chris Mellon" <ar*****@gmail. comwrote:

>On 10/17/07, ki******@gmail. com <ki******@gmail .comwrote:

>>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 to stick
attributes on.

Which is a little sad, but a necessary requirement for things like
int() and str() to be small and fast.

So it's an optimization with side effects, giving a special case where
the simple and otherwise "right" way to do it doesn't work? Too bad :-
(

Ok; I'll continue to create dummy classes inheriting from object. And
hope that one day it will be simpler.

I'm using the following "dummy" class with a little extra functionality:

def Bunch(object):
def __init__(self, **kwargs):
self.__dict__.u pdate(kwargs)

person = Bunch(name='Eri c', age=42)
print person.name
point = Bunch(x=4711, y=23)

Ciao,
Marc 'BlackJack' Rintsch