Re: dict!ident as equivalent of dict[ident]

2006-05-22 Thread Alexander Kozlovsky
Edward Elliott wrote:
 With this suggestion,   mapping!identifier
 becomes fully equivalent to mapping[identifier]
 
 Penny-wise, pound-foolish.  Saves 3 character strokes at the cost of a new
 special-purpose operator which only works in limited circumstances.  To
 avoid parsing ambiguity, identifier can only contain (as the name implies)
 alphanumerics and _.  So your ! is limited not only to dicts but to certain
 keys in certain dicts.  More complicated than it's worth.

Yes, it is limited use-case, but IMHO important one.
The benefits are:
1. Code looks more neat, because IDE will highlight it as identifier,
   and not as string
2. Limited form of code completion (as in PythonWin) becomes possible
3. A bit easier to type, and to read

Anyway, I don't intent strongly on this, I just like to see
common attitude

 So your ! is limited not only to dicts

Not only to dict, but to any class with __getitem__ or __setitem__
methods

-- 
Best regards,
 Alexander  mailto:[EMAIL PROTECTED]

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


Re: dict!ident as equivalent of dict[ident]

2006-05-21 Thread Alexander Kozlovsky
Roy Smith wrote:
 Define a class (perhaps a subclass of dict, if you like)
 with a __getattr__ method.  Then you can just do
 
 foo.bar.baz.x = y
 
 with no changes needed to the language.

I think, your solution is very error-prone. If such enhanced
dictionary contains keys key, what is meaning of d.keys?
Is it bound method or dictionary item? After you introduce
such dictionary, you cannot add any new method for it, because
it may destroy user code, if acciddent name clashing take place.

Consider SQLTable class, which have name attribute, and
bunch of dynamically created named columns. With __getattr__
method you can use SQLTable.column_1 syntax for column access,
but what if same column have name name? It may be very
psychologically inconvenient for user of such class to use
same foo.bar syntax for two different purposes.

In most real cases it is important to distinguish between
two different namespaces - members namespace with methods
properties etc., and items namespace with truly dynamic
content. In todays Python such distinction accomplished
with two different methods - __getattr(ibute)__ and __getitem__.

It is not possible to successfully use only __getattr__
to serve two different purposes. Hense I suggest use
__getitem__ for its direct purpose, and only add some
syntactic sugar for it

Dan Sommers wrote:
 Take a look at the Bunch recipe in the Python Cookbook:
 
 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52308

This recipe is what is stated in its name - collector
of a bunch of named stuff. It is not suitable for
elaborate classes with many methods (such as SQLTable),
for above mentioned reason - name cluttering between
methods, properties and dynamic content.


-- 
Best regards,
 Alexander  mailto:[EMAIL PROTECTED]

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