Mailman 3 March 2011 - Python-ideas

Re: [Python-ideas] [Python-Dev] Dict access with double-dot (syntactic sugar)
by Santoso Wijaya 25 Mar '11

25 Mar '11

I just want to chip in that, as far as syntactic sugar go, `somedict:foo` looks better than `somedict..foo`. 2c... ~/santa On Thu, Mar 24, 2011 at 4:40 AM, Jameson Quinn <jameson.quinn(a)gmail.com>wrote: > "class attrdict" is a perennial dead-end for intermediate pythonistas who > want to save 3 characters/5 keystrokes for item access. Other languages such > as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so > why not python? Well, there are a number of reasons why not, beginning with > all the magic method names in python. > > But saving keystrokes is still a reasonable goal. > > So what about a compromise? Allow "somedict..foo", with two dots, to take > that place. It still saves 2 characters (often 4 keystrokes; and I find even > ', "[", or "]" harder to type than "."). > > The "foo" part would of course have to obey attribute/identifier naming > rules. So there would be no shortcut for "somedict['$#!%']". But for any > identifier-legal foo, the interpreter would just read ..foo as ['foo']. > > I would not be surprised if I'm not the first person to suggest this. If > so, and there's already well-known reasons why this is a bad idea, I > apologize. But if the only reason not to is "we never did it that way > before" or "it would be too addictive, and so people would never want to use > older python versions" or "headache for tools like pylint", I think we > should do it. > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com > >

3 2

Re: [Python-ideas] [Python-Dev] Dict access with double-dot (syntactic sugar)
by Josiah Carlson 24 Mar '11

24 Mar '11

Pardon me for the run-by comment. Your proposed double-dot syntax foo..bar (that is something whose __*item__ methods you want to invoke) is visually indistinguishable from a mistyped goo..baz (whose __*item__ methods you do not want to invoke) . The only way a 3rd party could know what you meant is if they subsequently scanned all nearby code to see if that particular access pattern was repeated, or if they knew that you really wanted to access the contents of the dictionary and not the attributes of an object. It also seems to me that the use of a dictionary instead of a container for attributes (via AttrDict) is also a mistake (I've written these myself, but only because of their convenience, not because I like them conceputally). Consistency for the sake of sanity is something that I strive for, especially when writing code that others are to read. If you feel the need to have an AttrDict class, might I suggest a very simple wrapper that ensures that you aren't mixing access patterns that would confuse. >>> class AttrDict(object): ... def __init__(self, dict): ... self.__dict__ = dict ... >>> b = {} >>> c = AttrDict(b) >>> c.a Traceback (most recent call last): File "<console>", line 1, in <module> AttributeError: 'AttrDict' object has no attribute 'a' >>> b['a'] = 1 >>> c.a 1 No need to implement *any* magic method beyond __init__. Of course you can't access it like a dictionary, but I thought that was what you were trying to avoid. The claimed reduction in keystrokes is false economy. While you may save a few keystrokes (the square brackets and quote marks) for some accesses, "syntax should not look like grit on my monitor", and an extra period is the most grit-like of any syntax I've ever seen. And finally, for the sake of consistency, if foo..bar is allowed, why not allow for foo..1? Lists are also used with container[index]? Oh, because of the ambiguity. Did we mean foo[1], or did we mean foo['1']. Therein lies the rub, as while previously the behavior was consistent for all container types (foo[bar] does the same thing, for all possible bar), now accessing a string key in a container gets special syntax via foo..string . That doesn't feel right to me. For all of these reasons, I'm -1 . Regards, - Josiah On Thu, Mar 24, 2011 at 8:20 AM, Jameson Quinn <jameson.quinn(a)gmail.com> wrote: > 2011/3/24 Brian Curtin <brian.curtin(a)gmail.com> >> >> On Thu, Mar 24, 2011 at 06:40, Jameson Quinn <jameson.quinn(a)gmail.com> >> wrote: >>> >>> "class attrdict" is a perennial dead-end for intermediate pythonistas who >>> want to save 3 characters/5 keystrokes for item access. Other languages such >>> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so >>> why not python? Well, there are a number of reasons why not, beginning with >>> all the magic method names in python. >>> But saving keystrokes is still a reasonable goal. >> >> Code is read far more often than it is written, so readability tends to >> count more than most other metrics. >>> >>> So what about a compromise? Allow "somedict..foo", with two dots, to take >>> that place. It still saves 2 characters (often 4 keystrokes; and I find even >>> ', "[", or "]" harder to type than "."). >> >> I don't see the benefit, but maybe it'll save a few bytes in file size. >> Anyone reviewing your code now has to think "does this need one or two >> dots?" >> Anyways, why not just do something like this: >> class AttrDict(dict): >> def __getattr__(self, attr): >> return super(AttrDict, self).__getitem__(attr) >> >>> d = AttrDict() >> >>> d["a"] = 1 >> >>> d.a >> 1 > > There are a few reasons not to do it your way. For one, you could easily > forget about one of the built-in dict methods (e.g. d.get != d["get"]). For > another, if you look on the web, you'll find at least 15 different recipes > for that thing you just made, several of which have more-or-less subtle > errors waiting to get you. Furthermore, the whole point is to have this > available for built-in dicts. Say you get a dict as json - you can either > subclass your own json decoder, with all the pitfalls, or you can explicitly > pass the decoded dict to AttrDict, causing an extra object to be created and > obfuscating your code. And finally, who wants to copy that AttrDict code for > the 137th time? > As for the question of "one or two dots", it's exactly the same question you > face now with "dot or bracket", so I don't see the problem. > It's not merely a matter of saving keystrokes. To me, it would be actually > easier to read code in this style. When I'm doing things like accessing my > json data, that is essentially attribute access; why should my syntax > colorer color it the same as my UI strings? > In sum: > -Saves keystrokes > -saves bugs from miscooked recipes > -faster and less memory than any such recipe > -more-readable code > -very low-risk for old code > Jameson > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com > >

1 0

Fwd: Dict access with double-dot (syntactic sugar)
by Jameson Quinn 24 Mar '11

24 Mar '11

"class attrdict" is a perennial dead-end for intermediate pythonistas who want to save 3 characters/5 keystrokes for item access. Other languages such as javascript allow "somedict.foo" to mean the same as "somedict['foo']", they think, so why not python? Well, there are a number of reasons why not, beginning with the possible conflicts with keywords or any of the magic method names in python. But saving keystrokes is still a reasonable goal. So what about a compromise? Allow "somedict..foo", with two dots, to take that place. It still saves 2 relatively-hard-to-type characters. The "foo" part would of course have to obey attribute/identifier naming rules. So there would be no shortcut for "somedict['$#!%']". But for any identifier-legal foo, the interpreter would just read ..foo as ['foo']. I would not be surprised if I'm not the first person to suggest this. If so, and there's already well-known reasons why this is a bad idea, I apologize. But if the only reason not to is "we never did it that way before" or "it would be too addictive, and so people would never want to use older python versions" or "headache for tools like pylint", I think we should do it.

4 3

Re: [Python-ideas] [Python-Dev] Dict access with double-dot (syntactic sugar)
by Dirkjan Ochtman 24 Mar '11

24 Mar '11

On Thu, Mar 24, 2011 at 12:40, Jameson Quinn <jameson.quinn(a)gmail.com> wrote: > "class attrdict" is a perennial dead-end for intermediate pythonistas who > want to save 3 characters/5 keystrokes for item access. Other languages such > as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so > why not python? Well, there are a number of reasons why not, beginning with > all the magic method names in python. This should go on python-ideas. Cheers, Dirkjan

1 0

Function multiple arguments assignment
by Giampaolo Rodolà 23 Mar '11

23 Mar '11

It's likely this has already been proposed in past, I don't know, anyway... This occurred to me while using subprocess module yesterday. I had to do something like this: subprocess.Popen(["exe"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE) Would it be appropriate to permit something similar to multiple variable assignment such as: subprocess.Popen(["exe"], stdin=stdout=stderr=subprocess.PIPE) ...? Regards --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/psutil

9 9

Re: [Python-ideas] A user story concerning things knowing their own names
by Guido van Rossum 21 Mar '11

21 Mar '11

[+python-ideas] On Thu, Mar 17, 2011 at 10:12 PM, Ian Bicking <ianb(a)colorstudy.com> wrote: > Did you have any opinion on __addtoclass__? It seemed to me to address most > of the use cases (even Greg's as far as I understood it). [Reminder: Ian's proposal is to call attr.__addtoclass__(cls, name) for all attributes of the class that have the method, at class construction time.] You know, somehow I missed that when skimming. :-( It nicely encapsulates the main reason for having a metaclass in many of these cases. There's another pattern where all class attributes that have a certain property are also collected in a per-class datastructure, and at that point we're back to the custom metaclass; but standardizing on __addtoclass__ with the proposed signature would be a first step. We could either have a standard metaclass that does this, or we could just make it part of 'type' (the default metaclass) and be done with it. -- --Guido van Rossum (python.org/~guido)

4 9

Linking Doug's stdlib documentation to our main modules doc.
by Tarek Ziadé 21 Mar '11

21 Mar '11

Hey, As I told Doug during Pycon, I think it would be a good idea to link his PyMOTW pages to our modules documentation in docs.python.org so people have more examples etc. Cheers Tarek -- Tarek Ziadé | http://ziade.org

18 53

Would it possible to define abstract read/write properties with decorators?
by Darren Dale 21 Mar '11

21 Mar '11

I'm a big fan of the decorator syntax introduced in python-2.6 to define properties: class Foo(object): @property def bar(self): return 1 @bar.setter def bar(self, val): pass Lately I've been learning about ABCs at http://www.python.org/dev/peps/pep-3119/ and http://docs.python.org/py3k/library/abc.html . The documentation states that abstract read-only properties can be defined with the decorator syntax, but the "long-form" [bar=property(getbar, setbar)] property declaration is required for read/write properties. Would it be possible to support the decorator syntax for read/write properties in python-3.3? In python-3.2, this is valid code that (sort-of) produces an abstract read/write property: class Foo(metaclass=ABCMeta): @abstractproperty def bar(self): return 1 @bar.setter def bar(self, val): pass but subclasses of Foo can be instantiated even if they do not define a bar.setter: class Baz(Foo): @property def bar(self): return 1 baz=Baz() which must have been the reason for requiring the long-form property declaration syntax. It seems like it should be possible for Python to support the decorator syntax for declaring abstract read/write properties. The most elegant approach might be the following, if it could be supported: class Foo(metaclass=ABCMeta): # Note the use of @property rather than @abstractproperty: @property @abstractmethod def bar(self): return 1 @bar.setter @abstractmethod def bar(self, val): pass I thought that would work with Python-3.2, but Foo is instantiable even though there are abstractmethods. If python's property could be tweaked to recognize those abstract methods and raise the usual TypeError, then we could subclass the abstract base class Foo in the usual way: class Baz(Foo): @Foo.bar.getter def bar(self): return 2 this is not yet instantiable, Baz.bar.setter is still abstract... @bar.setter def bar(self, val): pass Now Baz could be instantiated. Is this feasible? Darren

2 7

Add links in manual to test_modules.
by Terry Reedy 20 Mar '11

20 Mar '11

I am already making use of the source links added to the 3.2 manuals. I propose that we also add links to test-modules where appropriate, both in the language and library manuals. 1. It would help developers. 2. It could help users. Each test module is a set of examples of how to use the corresponding aspect of Python both correctly and incorrectly, with many corner cases that might not be clear from the manual. Each test module should exercise every feature of the stdlib module or other area covered. In addition, unlike external sets of examples, the test suite is updated and expected to run with the corresponding version. As language and implementation tests are better separated, people could better see which behavior is which. 3. Exposing the test suite would expose deficiencies and encourage improvements. -- Terry Jan Reedy

7 6

A user story concerning things knowing their own names
by Greg Ewing 18 Mar '11

18 Mar '11

I just experienced an obscure bug resulting from copying and pasting an overridable_property and forgetting to change the passed-in name: content_size = overridable_property('size', "Size of the content area.") which should have been content_size = overridable_property('content_size', "Size of the content area.") This was quite difficult to track down, because the result was to effectively make it an alias of *another* property I have called 'size'. They happen to be near enough to the same thing that the error went unnoticed for quite some time. If I could write my overridable_property declarations without having to repeat the name, this kind of thing would not be able to happen. -- Greg

11 18