Mailman 3 September 2009 - Python-ideas

Re: [Python-ideas] possible attribute-oriented class
by Jan Kaliszewski 05 Sep '09

05 Sep '09

05-09-2009 Steven D'Aprano <steve(a)remove-this-cybersource.com.au> wrote: > On Fri, 04 Sep 2009 22:37:15 +0200, Jan Kaliszewski wrote: > >> 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. [snip] > What sort of extensions did you have in mind? Two useful (from my point of view) concepts have appeared (or been linked to) in this thread -- on python-list and python-ideas: * the namespace/AttrDict concept (see Ken Newton's, Nick Coghlan's and my posts). * record concept (see George Sakkis post). >> The old discussion, the above link points to, shows that such a >> dot-accessible dict-like class is something that many people need and >> repeatedly implemet it (more or less perfectly) for themselves. > > I think it's something which people copy from other languages because > that's what they're used to, not because they need it. I don't think so, especially if we say about the former. IMHO it is simply useful in practice, especially for scripting (but not only) -- being more convenient than using empty class. It offers (in compact way, without additional efforts and verbose syntax -- once you have got such a tool implemented) three things at the same time, without necessity to choose between them: comfortable static attribute access, flexible dict-like dynamic access when needed and possibility of iteration. > It's just a change in syntax. Whether you write x.key or x['key'] is a > matter of convenience. Attribute access is optimized for when you know > the key names at compile time, key access is optimized for when you don't > know the names until runtime. Exactly. It is a matter of *convenience* (as well as large areas of Python) and that's the point. I suppose that that is the reason for people to repeatedly implement it for themselves. 05-09-2009 Steven D'Aprano <steve(a)remove-this-cybersource.com.au> wrote: > On Fri, 04 Sep 2009 22:51:39 -0700, Ken Newton wrote: [snip] >> I would think this is much more than just copy from other language >> styles or 'just' a syntax change -- the apparent widespread use would >> hint at a deeper need. > > "Apparent" is the key word there. There are lots of people who *say* this > this useful functionality, but how many of them *actually* use it? And of > those who do use it, how many of them know what they're doing? There are > an awful lot of bad programmers out there. > > If you do need such functionality, it's easy to implement. Here's one: Neither you nor me have hard evidence about popularity/unpopularity of the idea (number of places where you can find similar, more or less successful, attempts to implement it seems to testify in favour of the idea) -- nor about how it is used or abused. Obviously there are a lot of bad programmers who are able to use globals instead of function arguments etc.... Thats the fate of every language feature. But it's not the reason to resign from a feature that has particular common and proper use-cases. Even official Python tutorial mentions a case that is typical for the matter: http://docs.python.org/3.1/tutorial/classes.html#odds-and-ends > As a > general rule, if obj.x is an attribute, then every valid obj should have > an attribute x. But if obj['x'] is a key/value, then it is data-specific: > some instances will have an 'x' key, and some won't. It's often true but not always (see e.g. the above example in docs). Cheers, *j -- Jan Kaliszewski (zuo) <zuo(a)chopin.edu.pl>

1 0

Re: [Python-ideas] Collect **kw arguments as an ordered dictionary
by Masklinn 05 Sep '09

05 Sep '09

Response to a fairly old (April) thread, but there's another use case to **kwargs being collected in an ordered dictionary: interaction with Objective-C or Smalltalk (but mainly obj-c/Cocoa): since **kwargs is not an ordered dict, Python/Cocoa interop can't use them to emulate ObjC's compound message names (as order is significant), so PyObjC merges the message subparts into a single method and tacks the arguments at the end, transforming calls like [NSString stringWithContentsOfFile:@"/usr/share/dict/propernames" encoding:NSASCIIStringEncoding error:&error]; into NSString.stringWithContentsOfFile_encoding_error_( "/usr/share/dict/propernames", NSASCIIStringEncoding) while the verbosity is similar, the loss in readability is tremendous. With the availability of ordered **kwargs, the bridge could simply have a send method (akin to the ObjC performSelector:) taking a bunch of kwargs and sending the corresponding message to the underlying ObjC object: NSString.send(stringWithContentOfFile="/usr/share/dict/ propernames", encoding=NSASCIIStringEncoding, error=errors) Or variable method names with a bit of massaging e.g. using the first message part as the method name à la MacRuby: NSString.stringWithContentOfFile("/usr/share/dict/propernames", encoding=NSASCIIStringEncoding, error=errors) or splitting that first part between the method name and the first kwarg: NSString.stringWith(ContentOfFile="/usr/share/dict/propernames", encoding=NSASCIIStringEncoding, error=errors)

1 0

Re: [Python-ideas] possible attribute-oriented class
by Jan Kaliszewski 04 Sep '09

04 Sep '09

04-09-2009 Ken Newton <krnewton(a)gmail.com> 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-ideas(a)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.c… > > 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. The old discussion, the above link points to, shows that such a dot-accessible dict-like class is something that many people need and repeatedly implemet it (more or less perfectly) for themselves. Maybe that past proposition (to add a separate namespace module which a number types for viewing, chaining and so on) was too sophisticated? Most common use cases could be covered with one attr-dict-like type, that could be placed in collections module (or even, in time, as a built-in factory function, together with namedtuple?). Cheers, *j

2 1

Re: [Python-ideas] possible attribute-oriented class
by Jan Kaliszewski 04 Sep '09

04 Sep '09

[originally from python-list(a)python.org, crossposted to python-ideas(a)python.org] 04-09-2009 o 00:46:01 Ken Newton <krnewton(a)gmail.com> wrote: > I have created the following class definition with the idea of making > a clean syntax for non-programmers to created structured data within a > python environment. > > I would appreciate comments on this code. First, is something like > this already done? Second, are there reasons for not doing this? If > this seems OK, how could I clean up the string conversion to have > indented format. > > The expected use would have all items in the structure be simple > python types or AttrClass types. Code written in python could walk the > structure in a simple way to locate any desired values. Code in a > C/C++ extension should also be able to walk the structure to use any > value in the structure. > > class AttrClass(object): > """AttrClass lets you freely add attributes in nested manner""" > > def __init__(self): > pass > def __setitem__(self, key, value): > return self.__dict__.__setitem__(key, value) > def __repr__(self): > return "%s(%s)" % (self.__class__.__name__, > self.__dict__.__repr__()) > def __str__(self): > ll = ['{'] > for k,v in self.__dict__.iteritems(): > ll.append("%s : %s" % (k, str(v))) > return '\n'.join(ll) + '}' [snip] I find the idea interesting and close to my own needs in many situations, if I could alter it a bit. Of course, we always can use an empty class ('class MyStruct: pass') or simply use a dict... But both methods are inconvinient in some ways. In the case of dict we are convicted -- even when we need static access -- to mapping notation (obj['member']) which is less convenient and (what's more important) more error-prone than attribute dot-notation. In the case of empty class/object we can use convenient attr dot-notation but dynamic access is less natural... IMHO there could be -- in collections module or even as a built-in factory function -- something (somehow) similar to namedtuple, but mutable and more dict-like. I'am less focused on nesting such structures, and more on making it a namespace-like objects with convenience-and-today-usage features. Please consider the code: class AttrDict(dict): # (or maybe from OrderedDict) "It's only a model. (Shhh!)" def __getattr__(self, name): if name.startswith('_'): raise AttributeError("AttrDict's key can't " "start with underscore") else: return self[name] def __setattr__(self, name, value): self[name] = value def __delattr__(self, name): del self[name] def __repr__(self): return '{0}({1})'.format(self.__class__.__name__, dict.__repr__(self)) def __str__(self): return self._as_str() def _gen_format(self, indwidth, indstate): indst = indstate * ' ' ind = (indstate + indwidth) * ' ' yield ('\n' + indst + '{' if indstate else '{') for key, val in self.items(): valstr = (str(val) if not isinstance(val, AttrDict) else val._as_str(indwidth, indstate + indwidth)) yield '{ind}{key}: {valstr}'.format(ind=ind, key=key, valstr=valstr) yield indst + '}' def _as_str(self, indwidth=4, indstate=0): return '\n'.join(self._gen_format(indwidth, indstate)) def _as_dict(self): return dict.copy(self) # Test code: if __name__ == '__main__': struct = AttrDict() struct.first = 1 struct.second = 2.0 struct.third = '3rd' struct.fourth = [4] print(struct) # output: # { # 'second': 2.0 # 'fourth': [4] # 'third': '3rd' # 'first': 1 # } del struct.fourth print(repr(struct)) # output: # AttrDict({'second': 2.0, 'third': '3rd', 'first': 1}) print(struct.first) # (static access) # output: # 1 for x in ('first', 'second', 'third'): print(struct[x]) # (dynamic access) # output: # 1 # 2.0 # 3rd struct.sub = AttrDict(a=1, b=2, c=89) print(struct._as_dict()) # output: # {'second': 2.0, 'sub': AttrDict({'a': 1, 'c': 89, 'b': 2}),\ # 'third': '3rd', 'first': 1} print(struct._as_str(8)) # output: # { # second: 2.0 # sub: # { # a: 1 # c: 89 # b: 2 # } # third: 3rd # first: 1 # } What do you think about it? Cheers, *j -- Jan Kaliszewski (zuo) <zuo(a)chopin.edu.pl>

2 1

Re: [Python-ideas] Decorator syntax
by Georg Brandl 04 Sep '09

04 Sep '09

MRAB schrieb: > James Y Knight wrote: >> On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote: >> >>> So - the syntax restriction seems not only inconsistent, but >>> pointless; it doesn't forbid anything, but merely means we have to do >>> it in a slightly convoluted (unPythonesque) way. So please, Guido, >>> will you reconsider? >> >> Indeed, it's a silly inconsistent restriction. When it was first added I >> too suggested that any expression be allowed after the @, rather than >> having a uniquely special restricted syntax. I argued from consistency >> of grammar standpoint. But Guido was not persuaded. Good luck to you. :) >> > [snip] > I can see no syntactic reason to restrict what can appear after the @. > If someone chooses to abuse it then that's unPythonic, but not illegal. I do see a reason. I have no problems with @foo.bar @foo.bar[baz] @foo.bar(baz) But this is ugly to me: @a + b def foo(): pass As is this: @a or (c and d) def foo(): pass Having the decorator expression "opened" by @ but not "closed" feels bad. However, this looks better to me: @(a + b) @(a or (c and d)) So, in terms of Grammar/Grammar, what about decorator: '@' atom trailer* NEWLINE [x-post to ideas list] Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

5 6

Re: [Python-ideas] [Python-Dev] Decorator syntax
by Nick Coghlan 02 Sep '09

02 Sep '09

Xavier Morel wrote: > On 2 Sep 2009, at 12:15 , Rob Cliffe wrote: >> >> @Identity(DecoList[0]) # THIS WORKS >> def foo(): >> pass > For what it's worth, you don't need an id function, you can simply write > > @itemgetter(0)(decorators) > def foo(): > 'whatever' > or > > @decorators.__getitem__(0) > def foo(): > 'whatever' To be honest, I'd forgotten the restriction was even there. So +0 on removing it and relying on "consenting adults" and style guides to keep people from getting to obscure with their decorators. However, any such change should also be accompanied by an update to PEP 8 (recommending the current syntactic restrictions as style rules for the standard library). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

2 1

Re: [Python-ideas] [Python-Dev] Decorator syntax
by Carl Johnson 02 Sep '09

02 Sep '09

Crossposting to Python-ideas, I asked for the same change to the grammar a couple months back on python-ideas. See http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787 I'm all for it, but you'll have to convince Guido that this won't result in confusing to read code. My own examples, unfortunately did not advance your cause, as Guido explained, "My brain hurts trying to understand all this. I don't think this bodes well as a use case for a proposed feature." :-D The trouble is that I was using lambdas upon lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come up with some simple, clear use cases though, and I think he might still be persuadable to make a simple change to the grammar. — Carl Johnson Rob Cliffe <rob.cliffe(a)btinternet.com> wrote: > Hi All, > This is my first post to python-dev so I will briefly introduce myself: My > name is Rob Cliffe and I am a commercial programmer living in London, UK. I > have some 30 years of programming experience but have only been using Python > for a couple of years. > First I want to say what a fantastic language Python is. It is THE best > language for development in my opinion, and a joy to use. > > My specific issue: > I eventually got my head round decorator syntax and realised that what came > after the '@' was (basically) a function that took a function as argument > and returned a function as result. > However it seems to me unPythonesque (i.e. an exception to Python's normal > consistency) that the syntax of what follows the '@' should be restricted to > either a single (function) identifier or a single (function) identifier with > an argument list. > The example I tried, which seems not an unreasonable sort of thing to do, > was along the lines of: > > def deco1(func): > <deco1-suite> > def deco2(func): > <deco2-suite> > > DecoList = [deco1, deco2] > > @DecoList[0] # NO - CAUSES SYNTAX ERROR > def foo(): > pass > > I am sure other guys have their own examples. > > I am of course not the first person to raise this issue, and I see that > Guido has a "gut feeling" against allowing a general expression after the > '@'. > > BUT - a general expression can be "smuggled in" very easily as a function > argument: > > def Identity(x): return x > > @Identity(DecoList[0]) # THIS WORKS > def foo(): > pass > > So - the syntax restriction seems not only inconsistent, but pointless; it > doesn't forbid anything, but merely means we have to do it in a slightly > convoluted (unPythonesque) way. So please, Guido, will you reconsider? > > Best wishes > Rob Cliffe

2 1