Re: [Python-ideas] possible attribute-oriented class

2009-09-08 Thread Jim Jewett
On Mon, Sep 7, 2009 at 9:02 PM, Jan Kaliszewski wrote:
> 08-09-2009 o 02:15:10 Steven D'Aprano  wrote:

>> ... what's wrong with this?

> a['xyz'] = something['blablabla'] + somethingelse['foobar']
> b['ababababa'] += afun(bobo['dodo']['kookoo'] * pofopofo['gh'][0]['a'])
> cupu['abc'] = (kukumunu['bo'], kukumunu['kuu'].mbmbmb['lalala'])

> a.xyz = something.blablabla + somethingelse.foobar
> b.ababababa += afun(bobo.dodo.kookoo * pofopofo.gh[0].a)
> cupu.abc = (kukumunu.bo, kukumunu.kuu.mbmbmb.lalala)

> For me the latter is definitely easier to read and understand.

I would describe it as "less difficult" rather than "easier".  My
biggest problem is that at that stage, I'm still typing raw, and
inclined to make typos.

The difference between fname and fnam won't be caught either way, but
field access at least keeps me from forgetting quotes, or forgetting
them at one end.

>> ... I often change field names two or three times
>> before I settle in on the final version.

And often because of an ambiguity with another field that I hadn't
originally thought to name.  Neither solution fixes this, but
attribute access is slightly easier to change.

>> [recipe to simplify attr-access]

> I think it depends how often people need to
> implement such boiler-plate code for themselves.

Attribute access is clearly better -- except for one thing.

While I'm doing this, I'm still in exploratory mode, and I *will* need
to clean up the API if I ever want better than quick-and-dirty.  If
the quick-and-dirty is already using attribute access, that makes the
transition a bit trickier.  If the quick-and-dirty is using dict
access, at least I have a clear marker.

-jJ
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: [Python-ideas] possible attribute-oriented class

2009-09-04 Thread George Sakkis
On Fri, Sep 4, 2009 at 4:37 PM, Jan Kaliszewski wrote:
> 04-09-2009 Ken Newton  wrote:
>
>> I like this version very much. I'm ready to put this into practice to see
>> how it works in practice.
>
> [snip]
>
> Not only you (Ken) and me. :-) It appears that the idea is quite old. Nick
> Coghlan replied at python-id...@python.org:
>
>> Jan Kaliszewski wrote:
>>>
>>> What do you think about it?
>>
>> It reminds me a bit of the old (short-lived) namespaces module:
>>
>>
>> http://web.archive.org/web/20060216094030/http://namespace.python-hosting.com/
>>
>> Steven's draft PEP on the topic is still available in the python-list
>> archives:
>>
>> http://mail.python.org/pipermail/python-list/2005-February/307235.html
>>
>> The problem we found with it was that the basic solutions (empty class
>> and now named_tuple) were good enough that it wasn't worth the hassle
>> involved in grabbing an extra library for it.
>
> Named tuples (which indeed are really very nice) are read-only, but the
> approach they represent could (and IMHO should) be extended to some kind
> of mutable objects.

Maybe something like http://code.activestate.com/recipes/576555/ ?

George
-- 
http://mail.python.org/mailman/listinfo/python-list