Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 06/12/2013 16:51, Piotr Dobrogost wrote: [...] I thought of that argument later the next day. Your proposal does unify access if the old obj.x syntax is removed. As long as obj.x is a very concise way to get attribute named 'x' from object obj it's somehow odd that identifier x is treated not like identifier but like string literal 'x'. If it were treated like an identifier then we would get attribute with name being value of x instead attribute named 'x'. Making it possible to use string literals in the form obj.'x' as proposed this would make getattr basically needless as long as we use only variable not expression to denote attribute's name. But then every time you wanted to get an attribute with a name known at compile time you'd need to write obj.'x' instead of obj.x, thereby requiring two additional keystrokes. Given that the large majority of attribute access Python code uses dot syntax rather than getattr, this seems like it would massively outweigh the eleven keystrokes one saves by writing obj.'x' instead of getattr(obj,'x'). -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Friday, December 6, 2013 3:07:51 PM UTC+1, Neil Cerutti wrote: > On 2013-12-04, Piotr Dobrogost > > wrote: > > > On Wednesday, December 4, 2013 10:41:49 PM UTC+1, Neil Cerutti > > wrote: > > >> not something to do commonly. Your proposed syntax leaves the > >> distinction between valid and invalid identifiers a problem > >> the programmer has to deal with. It doesn't unify access to > > >> attributes the way the getattr and setattr do. > > > > > > Taking into account that obj.'x' would be equivalent to obj.x > > any attribute can be accessed with the new syntax. I don't see > > how this is not unified access compared to using getattr > > instead dot... > > I thought of that argument later the next day. Your proposal does > unify access if the old obj.x syntax is removed. As long as obj.x is a very concise way to get attribute named 'x' from object obj it's somehow odd that identifier x is treated not like identifier but like string literal 'x'. If it were treated like an identifier then we would get attribute with name being value of x instead attribute named 'x'. Making it possible to use string literals in the form obj.'x' as proposed this would make getattr basically needless as long as we use only variable not expression to denote attribute's name. This is just casual remark. Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 2013-12-04, Piotr Dobrogost wrote: > On Wednesday, December 4, 2013 10:41:49 PM UTC+1, Neil Cerutti > wrote: >> not something to do commonly. Your proposed syntax leaves the >> distinction between valid and invalid identifiers a problem >> the programmer has to deal with. It doesn't unify access to >> attributes the way the getattr and setattr do. > > Taking into account that obj.'x' would be equivalent to obj.x > any attribute can be accessed with the new syntax. I don't see > how this is not unified access compared to using getattr > instead dot... I thought of that argument later the next day. Your proposal does unify access if the old obj.x syntax is removed. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wed, 04 Dec 2013 12:35:14 -0800, Piotr Dobrogost wrote: > Right. If there's already a way to have attributes with these > "non-standard" names (which is a good thing) No it is not a good thing. It is a bad thing, and completely an accident of implementation that it works at all. Python does not support names (variable names, method names, attribute names, module names etc.) which are not valid identifiers except by accident. The right way to handle non-identifier names is to use keys in a dictionary, which works for any legal string. As you correctly say in another post: "attribute is quite a different beast then key in a dictionary" attributes are intended to be variables, not arbitrary keys. In some languages, they are even called "instance variables". As they are variables, they should be legal identifiers: spam = 42 # legal identifier name spam\n-ham\n = 42 # illegal identifier name Sticking a dot in front of the name doesn't make it any different. Variables, and attributes, should be legal identifiers. If I remember correctly (and I may not), this issue has been raised with the Python-Dev core developers, including Guido, and their decision was: - allowing non-identifier attribute names is an accident of implementation; - Python implementations are allowed to optimize __dict__ to prohibit non- valid identifiers; - but it's probably not worth doing in CPython. getattr already enforces that the attribute name is a string rather than any arbitrary object. You've also raised the issue of linking attribute names to descriptors. Descriptors is certainly a good reason to use attributes, but it's not a good reason for allowing non-identifier names. Instead of writing: obj.'#$^%\n-\'."' just use a legal identifier name! The above is an extreme example, but the principle applies to less extreme examples. It might be slightly annoying to write obj.foo_bar when you actually want of obj.'foo.bar' or obj.'foo\nbar' or some other variation, but frankly, that's just too bad for you. As far as descriptors go, you can implement descriptor-like functionality by overriding __getitem__. Here's a basic example: class MyDict(dict): def __getitem__(self, key): obj = super(MyDict, self).__getitem__(key) if hasattr(obj, '__get__'): obj = obj.__get__(self) which ought to be close to (but not identical) to the semantics of attribute descriptors. While I can see that there is some benefit to allowing non-identifier attributes, I believe such benefit is very small, and not enough to justify the cost by allowing non-identifier attributes. If I wanted to program in a language where #$^%\n-\'." was a legal name for a variable, I'd program in Forth. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Thursday, December 5, 2013 8:13:49 AM UTC+5:30, Ian wrote: > On Wed, Dec 4, 2013 at 3:09 AM, rusi wrote: > > On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote: > >> On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote: > >> > Its a more fundamental problem than that: > >> > It emerges from the OP's second post) that he wants '-' in the > >> > attributes. > >> > Is that all? > >> > > >> > Where does this syntax-enlargement stop? Spaces? Newlines? > >> > >> At non-strings. > >> > >> >>> setattr(foo, 21+21, 42) > >> Traceback (most recent call last): > >> File "", line 1, in > >> TypeError: attribute name must be string, not 'int' > > > > Not sure what's your point. > > There was no point. My comment was only meant to be amusing. Duh! Im dense! -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/4/2013 6:42 PM, Piotr Dobrogost wrote: On Wednesday, December 4, 2013 11:11:56 PM UTC+1, Terry Reedy wrote: The discussion of keystrokes is also a side-track. To great degree, yes. Having said that I find extra 11 keystrokes needed to access some attributes to be a freaking big and unjustifiable number. Given that there is almost no need to ever use operator chars in attribute names and given that syntax changes have the major undesirable consequence of backward incompatibility, I find it to be a small and inconsequential number. What you are proposing, I believe, is a new grammatical category: attribute-name := identifier or string-literal. This would break the symmetry of the grammatical form identifier '.' identifier and change it to the asymmetrical identifier '.' attribute-name, and that is the Nice description. To put it another way, how does 'obj' get the non-standard attribute 'value-1', when obj is a module or class? The workaround given above for module attributes will not work for classes. The module workaround, which I find pretty ugly, is this: >>> len is __builtins__.len True >>> __globals__ = __import__(__name__) >>> a = 1 >>> a is __globals__.a True I have not checked that the import trick will work when a module is imported, but I believe it will. I'm not sure I see your point. Do you mean that being inside class declaration there's no name that referrs to the current namespace (the way __globals__ refer to module's namespace) thus we can't use proposed syntax to access non-standard attributes from this namespace? Right. Class objects are not created until after the class code runs. Not really. As others have pointed out, getattr is the preferred way to get the value of an attribute when you have an object with attributes and a run-time-only reference to the name in a string variable. Yes, and I think it's very unfortunate in itself. Do you prefer obj.__dict__['name'] to getattr(obj, 'name')? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/04/2013 06:58 PM, Terry Reedy wrote: On 12/4/2013 3:46 PM, Mark Lawrence wrote: On 04/12/2013 20:35, Piotr Dobrogost wrote: there should be a variant of dot access allowing to access these "non-standard" named attributes, too. More opinion. I am sure that I am not the only developer who disagrees. +1 The obvious thing to do is to either raise this on python ideas, or if you're that confident about it raise an issue on the bug tracker with a patch, which would include changes to unit tests and documentation as well as code, get it reviewed and approved and Bob's your uncle, job done. I think the latter would be foolish. Syntax changes have a high bar for acceptance. They should do more than save a few keystrokes. +1 -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/4/2013 3:46 PM, Mark Lawrence wrote:
On 04/12/2013 20:35, Piotr Dobrogost wrote:
On Wednesday, December 4, 2013 2:06:44 AM UTC+1, Tim Chase wrote:
I think random832 is saying that the designed purpose of setattr()
was to dynamically set attributes by name, so they could later be
accessed the traditional way; not designed from the ground-up to
support non-identifier names. But because of the getattr/setattr
machinery (dict key/value pairs), it doesn't prevent you from having
non-identifiers as names as long as you use only the getattr/setattr
method of accessing them.
Right. If there's already a way to have attributes with these
"non-standard" names
Fact.
(which is a good thing)
Opinion, not universally shared by developers, or 'good thing only as
long as kept obscure'.
>> then for uniformity with dot access to attributes with "standard" names
In a later post (after you wrote this) I explained that standard names
are not always accessed with a dot, and that uniformity is impossible.
>> there should be a variant of dot access allowing to access
>> these "non-standard" named attributes, too.
More opinion. I am sure that I am not the only developer who disagrees.
The obvious thing to do is to either raise this on python ideas, or if
you're that confident about it raise an issue on the bug tracker with a
patch, which would include changes to unit tests and documentation as
well as code, get it reviewed and approved and Bob's your uncle, job
done.
I think the latter would be foolish. Syntax changes have a high bar for
acceptance. They should do more than save a few keystrokes. Use of new
syntax makes code backward incompatible. New or changed Python modules
can be backported (as long as they do not use new syntax ;-) either
privately or publicly (on PyPI).
3.2 had no syntax changes; 3.3 one that I know of ('yield from'), which
replaced about 15-20 *lines* of very tricky code; 3.4 has none that I
can remember.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wed, Dec 4, 2013 at 3:09 AM, rusi wrote: > On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote: >> On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote: >> > Its a more fundamental problem than that: >> > It emerges from the OP's second post) that he wants '-' in the attributes. >> > Is that all? >> > >> > Where does this syntax-enlargement stop? Spaces? Newlines? >> >> At non-strings. >> >> >>> setattr(foo, 21+21, 42) >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: attribute name must be string, not 'int' > > Not sure what's your point. There was no point. My comment was only meant to be amusing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 04/12/2013 20:07, Piotr Dobrogost wrote: [...] Unless we compare with what we have now, which gives 9 (without space) or 10 (with space): x = obj.'value-1' x = getattr(obj, 'value-1') That is not a significant enough savings to create new syntax. Well, 9 characters is probably significant enough saving to create new syntax but saving these characters is only a side effect and is not the most important aspect of this proposal which leads us to the next point. Remember the Python philosophy that there ought to be one way to do it. Funny you use this argument against my idea as this idea comes from following this rule whereas getattr goes against it. Using dot is the main syntax to access attributes. Following this, the syntax I'm proposing is much more in line with this primary syntax than getattr is. If there ought to be only one way to access attributes then it should be dot notation. I believe that you are missing the point of getattr. It's not there so that one can use arbitrary strings as attribute names; it's there so that one can get attributes with names that aren't known until run time. For this purpose the dot-notation-with-quotes you suggest above is not good enough. For suppose e.g. that one does this: name = 'attribute' x.name How would the interpreter know whether you're asking for getattr(x, name) or getattr(x, 'name')? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/4/13 6:57 PM, Piotr Dobrogost wrote: On Thursday, December 5, 2013 12:09:52 AM UTC+1, Ethan Furman wrote: Perhaps you should look at different ways of spelling your identifiers? Why can't you use an underscore instead of a hyphen? So that underscore could be left for use inside fields' names? However I think we could use some unique Unicode character for this instead hyphen as long as Python allows any alphanumeric Unicode character inside identifiers which I think it does... Regards, Piotr You object to typing [''] but you don't mind typing an unusual Unicode character? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
In article , Dennis Lee Bieber wrote: > Spaces? I present to you two FORTRAN statements > > DO 10 I = 3 . 14159 > and > DO10I = 3 , 1 4 1 5 9 > > Which is the loop and which is the assignment? I know it's rude to quote oneself, but: http://www.python.org/doc/humor/#bad-habits -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/04/2013 03:57 PM, Piotr Dobrogost wrote: On Thursday, December 5, 2013 12:09:52 AM UTC+1, Ethan Furman wrote: Perhaps you should look at different ways of spelling your identifiers? Why can't you use an underscore instead of a hyphen? So that underscore could be left for use inside fields' names? However I think we could use some unique Unicode character for this instead hyphen as long as Python allows any alphanumeric Unicode character inside identifiers which I think it does... Yes, although I don't remember at which version that became true... -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Thursday, December 5, 2013 12:09:52 AM UTC+1, Ethan Furman wrote: > Perhaps you should look > at different ways of spelling your identifiers? Why can't you use an > underscore instead of a hyphen? So that underscore could be left for use inside fields' names? However I think we could use some unique Unicode character for this instead hyphen as long as Python allows any alphanumeric Unicode character inside identifiers which I think it does... Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 11:11:56 PM UTC+1, Terry Reedy wrote: > > The discussion of enlarging the scope of 'identifier' is not relevant as > you are not proposing that. In particular, you are not asking that > obj.value-1 get the 'value-1' attribute of obj. Right. > The discussion of keystrokes is also a side-track. To great degree, yes. Having said that I find extra 11 keystrokes needed to access some attributes to be a freaking big and unjustifiable number. > What you are proposing, I believe, is a new grammatical category: > attribute-name := identifier or string-literal. This would break the > symmetry of the grammatical form identifier '.' identifier and change it > to the asymmetrical identifier '.' attribute-name, and that is the Nice description. > To put it another way, how does 'obj' get the non-standard attribute > 'value-1', when obj is a module or class? The workaround given above for > module attributes will not work for classes. I'm not sure I see your point. Do you mean that being inside class declaration there's no name that referrs to the current namespace (the way __globals__ refer to module's namespace) thus we can't use proposed syntax to access non-standard attributes from this namespace? > > >> Remember the Python philosophy that there ought to be one way to do > >> it. > > > Funny you use this argument against my idea as this idea comes from > > following this rule whereas getattr goes against it. > > Not really. As others have pointed out, getattr is the preferred way to > get the value of an attribute when you have an object with attributes > and a run-time-only reference to the name in a string variable. Yes, and I think it's very unfortunate in itself. Attribute access is fundamental operation and it's not accident that "operator" for this action is very concise in many languages being one char only. Having to switch to global function to access attribute in case its name is known only at run time is very awkward both when writing and reading code. > It would also be the case that "obj.'value' is obj.value", so the > proposal *would* add duplication. This is not a big deal and that's what you get when someone had already decided that in expression a.b, b is treated literally. Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/04/2013 02:13 PM, Piotr Dobrogost wrote: On Wednesday, December 4, 2013 10:41:49 PM UTC+1, Neil Cerutti wrote: On 2013-12-04, Piotr Dobrogost <> wrote: Right. If there's already a way to have attributes with these "non-standard" names (which is a good thing) At best its a neutral thing. You can use dict for the same purpose with very little effort and no(?) loss of efficiency. As much as many people in this topic would like to put equal sign between attributes and dictionary's keys they are not the same thing. AFAIK descriptor protocol works only with attributes, right? Correct. It is looking very unlikely that you are going to get enough support for this change. Perhaps you should look at different ways of spelling your identifiers? Why can't you use an underscore instead of a hyphen? -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wed, 4 Dec 2013 14:05:11 -0800 (PST), Piotr Dobrogost wrote: Object's attributes and dictionary's keys are quite different things. Right. So if you need arbitrary keys, use a dict. Attributes are keyed by identifiers, which are constrained. No problem. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 10:41:49 PM UTC+1, Neil Cerutti wrote: > On 2013-12-04, Piotr Dobrogost <> wrote: > > > Right. If there's already a way to have attributes with these > > "non-standard" names (which is a good thing) > > At best its a neutral thing. You can use dict for the same > purpose with very little effort and no(?) loss of efficiency. As much as many people in this topic would like to put equal sign between attributes and dictionary's keys they are not the same thing. AFAIK descriptor protocol works only with attributes, right? Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/4/2013 3:07 PM, Piotr Dobrogost wrote: You have proposed to make non-identifier attribute names 'official', rather than discouraged, by abbreviating > x = getattr(obj, 'value-1') or x = obj.__dict__['value-1'] # implementation detail as x = obj.'value-1' The discussion of enlarging the scope of 'identifier' is not relevant as you are not proposing that. In particular, you are not asking that obj.value-1 get the 'value-1' attribute of obj. The discussion of keystrokes is also a side-track. What you are proposing, I believe, is a new grammatical category: attribute-name := identifier or string-literal. This would break the symmetry of the grammatical form identifier '.' identifier and change it to the asymmetrical identifier '.' attribute-name, and that is the problem. Most identifiers are attributes of a namespace and many attributes are set *and accessed* as undotted names in module or class code. The symmetry is at least partly inherent and breaking it does not work very well. >>> len is __builtins__.len True >>> __globals__ = __import__(__name__) >>> a = 1 >>> a is __globals__.a True To put it another way, how does 'obj' get the non-standard attribute 'value-1', when obj is a module or class? The workaround given above for module attributes will not work for classes. Remember the Python philosophy that there ought to be one way to do it. Funny you use this argument against my idea as this idea comes from following this rule whereas getattr goes against it. Not really. As others have pointed out, getattr is the preferred way to get the value of an attribute when you have an object with attributes and a run-time-only reference to the name in a string variable. It would also be the case that "obj.'value' is obj.value", so the proposal *would* add duplication. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Tuesday, December 3, 2013 6:48:38 PM UTC+1, Dave Angel wrote: > On Tue, 3 Dec 2013 09:14:49 -0800 (PST), Piotr Dobrogost > > wrote: > > > What is the reason there's no "natural" syntax allowing to access > > attributes with names not being valid Python identifiers in a similar > > way to other attributes? > > There is. Just use a dictionary. Object's attributes and dictionary's keys are quite different things. What about descriptors? Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 10:41:49 PM UTC+1, Neil Cerutti wrote: > > not something to do commonly. Your proposed syntax leaves the > distinction between valid and invalid identifiers a problem the > programmer has to deal with. It doesn't unify access to > attributes the way the getattr and setattr do. Taking into account that obj.'x' would be equivalent to obj.x any attribute can be accessed with the new syntax. I don't see how this is not unified access compared to using getattr instead dot... Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/04/2013 12:55 PM, Mark Lawrence wrote: On 04/12/2013 20:22, Ethan Furman wrote: On 12/04/2013 12:07 PM, Piotr Dobrogost wrote: If there ought to be only one way to access attributes then it should be dot notation. Not "only one way", it's "one obvious way". Not "one obvious way" it's "There should be one-- and preferably only one --obvious way to do it.". Get it right lad :) I was paraphrasing. ;) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 2013-12-04, Piotr Dobrogost wrote: > On Wednesday, December 4, 2013 2:06:44 AM UTC+1, Tim Chase wrote: >> >> I think random832 is saying that the designed purpose of setattr() >> was to dynamically set attributes by name, so they could later be >> accessed the traditional way; not designed from the ground-up to >> support non-identifier names. But because of the getattr/setattr >> machinery (dict key/value pairs), it doesn't prevent you from having >> non-identifiers as names as long as you use only the getattr/setattr >> method of accessing them. > > Right. If there's already a way to have attributes with these > "non-standard" names (which is a good thing) At best its a neutral thing. You can use dict for the same purpose with very little effort and no(?) loss of efficiency. > then for uniformity with dot access to attributes with > "standard" names there should be a variant of dot access > allowing to access these "non-standard" named attributes, too. New syntax needs more than theoretical justifications; it needs persuasive use cases. Using invalid identifiers as attributes is generally a bad idea, not something to do commonly. Your proposed syntax leaves the distinction between valid and invalid identifiers a problem the programmer has to deal with. It doesn't unify access to attributes the way the getattr and setattr do. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/04/2013 12:58 PM, Jerry Hill wrote: On Wed, Dec 4, 2013 at 3:35 PM, Piotr Dobrogost wrote: Right. If there's already a way to have attributes with these "non-standard" names (which is a good thing) then for uniformity with dot access to attributes with "standard" names there should be a variant of dot access allowing to access these "non-standard" named attributes, too. Given the follow code, what do you think should print? class My_Class(object): pass bar = 1 my_object = My_Class() setattr(my_object, 'foo', 10) setattr(my_object, 'bar', 100) setattr(my_object, 'foo-bar', 1000) print(my_object.foo-bar) Actually, under his proposal it would be: print(my_object."foo-bar") and it would print 1000, while yours would still print 9. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 2:23:24 PM UTC+1, Roy Smith wrote: > In article <17gt99hg615jfm7bdid26185884d2pf...@4ax.com>, > > Tim Roberts <> wrote: > > > Piotr Dobrogost <> wrote: > > > >Attribute access syntax being very concise is very often preferred > > >to dict's interface. > > > It is not "very concise". It is slightly more concise. > > > x = obj.value1 > > x = dct['value1'] > > > You have saved 3 keystrokes. That is not a significant enough savings to > > create new syntax. Remember the Python philosophy that there ought to be > > one way to do it. > > I'll trade typing [ ' ' ] for . any day. Easier to type, easier to > read. It's not just the character count, it's that you need to move > your fingers off the home row (or, at the very least, a big stretch with > your pinkie) to reach the brackets. I suppose that depends on your > particular keyboard layout and typing style/skill. Very true. Just a remark it's actually trading getattr(o,'x') for o.'x' (saving of 11 keystrokes - don't forget shifts :)) as attribute is quite a different beast then key in a dictionary so comparing this to dict's interface is comparing apples to oranges. Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wed, Dec 4, 2013 at 3:35 PM, Piotr Dobrogost wrote: > Right. If there's already a way to have attributes with these "non-standard" > names (which is a good thing) then for uniformity with dot access to > attributes with "standard" names there should be a variant of dot access > allowing to access these "non-standard" named attributes, too. Given the follow code, what do you think should print? class My_Class(object): pass bar = 1 my_object = My_Class() setattr(my_object, 'foo', 10) setattr(my_object, 'bar', 100) setattr(my_object, 'foo-bar', 1000) print(my_object.foo-bar) Today (in python 3.3), it prints 9, because my_object.foo is 10, the local variable bar is equal to 1, and 10 minus 1 is 9.. Under your new proposal, it would print 1000, right? Is there any way for your proposal to be backwards compatible? -- Jerry -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 04/12/2013 20:22, Ethan Furman wrote: On 12/04/2013 12:07 PM, Piotr Dobrogost wrote: If there ought to be only one way to access attributes then it should be dot notation. Not "only one way", it's "one obvious way". -- ~Ethan~ Not "one obvious way" it's "There should be one-- and preferably only one --obvious way to do it.". Get it right lad :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/04/2013 12:07 PM, Piotr Dobrogost wrote: If there ought to be only one way to access attributes then it should be dot notation. Not "only one way", it's "one obvious way". The obvious way to deal with objects that do not have legal identifier names is with a dict. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 04/12/2013 20:35, Piotr Dobrogost wrote: On Wednesday, December 4, 2013 2:06:44 AM UTC+1, Tim Chase wrote: I think random832 is saying that the designed purpose of setattr() was to dynamically set attributes by name, so they could later be accessed the traditional way; not designed from the ground-up to support non-identifier names. But because of the getattr/setattr machinery (dict key/value pairs), it doesn't prevent you from having non-identifiers as names as long as you use only the getattr/setattr method of accessing them. Right. If there's already a way to have attributes with these "non-standard" names (which is a good thing) then for uniformity with dot access to attributes with "standard" names there should be a variant of dot access allowing to access these "non-standard" named attributes, too. Regards, Piotr The obvious thing to do is to either raise this on python ideas, or if you're that confident about it raise an issue on the bug tracker with a patch, which would include changes to unit tests and documentation as well as code, get it reviewed and approved and Bob's your uncle, job done. Too late for Python 3.4 of course, but no problem for 3.5. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 2:06:44 AM UTC+1, Tim Chase wrote: > > I think random832 is saying that the designed purpose of setattr() > was to dynamically set attributes by name, so they could later be > accessed the traditional way; not designed from the ground-up to > support non-identifier names. But because of the getattr/setattr > machinery (dict key/value pairs), it doesn't prevent you from having > non-identifiers as names as long as you use only the getattr/setattr > method of accessing them. Right. If there's already a way to have attributes with these "non-standard" names (which is a good thing) then for uniformity with dot access to attributes with "standard" names there should be a variant of dot access allowing to access these "non-standard" named attributes, too. Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 6:45:05 AM UTC+1, Tim Roberts wrote: > > It is not "very concise". It is slightly more concise. > > x = obj.value1 > x = dct['value1'] > > You have saved 3 keystrokes. Actually only 1 as you should have compared these: x = obj.'value-1' x = dct['value-1'] Unless we compare with what we have now, which gives 9 (without space) or 10 (with space): x = obj.'value-1' x = getattr(obj, 'value-1') > That is not a significant enough savings to create new syntax. Well, 9 characters is probably significant enough saving to create new syntax but saving these characters is only a side effect and is not the most important aspect of this proposal which leads us to the next point. > Remember the Python philosophy that there ought to be one way to do it. Funny you use this argument against my idea as this idea comes from following this rule whereas getattr goes against it. Using dot is the main syntax to access attributes. Following this, the syntax I'm proposing is much more in line with this primary syntax than getattr is. If there ought to be only one way to access attributes then it should be dot notation. Regards, Piotr -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
Op 04-12-13 14:02, rusi schreef: > On Wednesday, December 4, 2013 6:02:18 PM UTC+5:30, Antoon Pardon wrote: >> Op 04-12-13 13:01, rusi schreef: >>> On Wednesday, December 4, 2013 3:59:06 PM UTC+5:30, Antoon Pardon wrote: Op 04-12-13 11:09, rusi schreef: > I used the spaces case to indicate the limit of chaos. > Other characters (that > already have uses) are just as problematic. I don't agree with the latter. As it is now python can make the distinction between from A import Band fromAimportB. I see no a priori reason why this should be limited to letters. A language designer might choose to allow a bigger set of characters in identifiers like '-', '+' and others. In that case a-b would be an identifier and a - b would be the operation. Just as in python fromAimportB is an identifier and from A import B is an import statement. >>> >>> Im not sure what you are saying. >>> Sure a language designer can design a language differently from python. >>> I mentioned lisp. Cobol is another behaving exactly as you describe. >>> >>> My point is that when you do (something like) that, you will need to change >>> the >>> lexical and grammatical structure of the language. And this will make >>> for rather far-reaching changes ALL OVER the language not just in >>> what-follows-dot. >> >> No you don't need to change the lexical and grammatical structure of >> the language. Changing the characters allowed in identifiers, is not a >> change in lexical structure. The only difference in lexical structuring >> would be that '-', '>=' and other similars symbols would have to be >> treated like keyword like 'from', 'as' etc instead of being recognizable >> by just being present. > > Well I am mystified… > Consider the string a-b in a program text. > A Cobol or Lisp system sees this as one identifier. > Python, C (and most modern languages) see this ident, operator, ident. > > As I understand it this IS the lexical structure of the language and the lexer > is the part that implements this: > - in cobol/lisp keeping it as one > - in python/C breaking it into 3 > > Maybe you understand in some other way the phrase "lexical structure"? Yes I do. The fact that a certain string is lexically evaluated differently is IMO not enough to conclude the language has a different lexical structure. It only means that the values allowed within the structure are different. What I see here is that some languages have an other alphabet over which identifiers are allowed. >> And the grammatical structure of the language wouldn't change at all. >> Sure a-b would now be an identifier and not an operation but that is >> of no concern for the parser. > > About grammar maybe what you are saying will hold: presumably if the token-set > is the same, one could keep the same grammar, with the differences being > entirely inter-lexeme ones. And the question is. If the token-set is the same, how is then is the lexical structure different rather than just the possible values associate with the tokens? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/04/2013 03:30 AM, Jussi Piitulainen wrote: rusi writes: How do we decide which '-' are valid identifier components -- hyphens and which minus-signs? I think the OP might be after the JavaScript mechanism where an attribute name can be any string, the indexing brackets are always available, and the dot notation is available when the attribute name looks like a simple identifier. That could be made to work. (I'm not saying should, or should not. Just that it seems technically simple.) Hm. Can't specific classes be made to behave this way even now by implementing suitable underscored methods? No. It is possible to provide attribute access along with key access, but not currently possible to provide attribute access with quoted values -- which is what the OP wants. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
In article <17gt99hg615jfm7bdid26185884d2pf...@4ax.com>, Tim Roberts wrote: > Piotr Dobrogost wrote: > > > >Attribute access syntax being very concise is very often preferred > >to dict's interface. > > It is not "very concise". It is slightly more concise. > > x = obj.value1 > x = dct['value1'] > > You have saved 3 keystrokes. That is not a significant enough savings to > create new syntax. Remember the Python philosophy that there ought to be > one way to do it. I'll trade typing [ ' ' ] for . any day. Easier to type, easier to read. It's not just the character count, it's that you need to move your fingers off the home row (or, at the very least, a big stretch with your pinkie) to reach the brackets. I suppose that depends on your particular keyboard layout and typing style/skill. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 6:02:18 PM UTC+5:30, Antoon Pardon wrote: > Op 04-12-13 13:01, rusi schreef: > > On Wednesday, December 4, 2013 3:59:06 PM UTC+5:30, Antoon Pardon wrote: > >> Op 04-12-13 11:09, rusi schreef: > >>> I used the spaces case to indicate the limit of chaos. > >>> Other characters (that > >>> already have uses) are just as problematic. > >> > >> I don't agree with the latter. As it is now python can make the > >> distinction between > >> > >> from A import Band fromAimportB. > >> > >> I see no a priori reason why this should be limited to letters. A > >> language designer might choose to allow a bigger set of characters > >> in identifiers like '-', '+' and others. In that case a-b would be > >> an identifier and a - b would be the operation. Just as in python > >> fromAimportB is an identifier and from A import B is an import > >> statement. > > > > Im not sure what you are saying. > > Sure a language designer can design a language differently from python. > > I mentioned lisp. Cobol is another behaving exactly as you describe. > > > > My point is that when you do (something like) that, you will need to change > > the > > lexical and grammatical structure of the language. And this will make > > for rather far-reaching changes ALL OVER the language not just in > > what-follows-dot. > > No you don't need to change the lexical and grammatical structure of > the language. Changing the characters allowed in identifiers, is not a > change in lexical structure. The only difference in lexical structuring > would be that '-', '>=' and other similars symbols would have to be > treated like keyword like 'from', 'as' etc instead of being recognizable > by just being present. Well I am mystified… Consider the string a-b in a program text. A Cobol or Lisp system sees this as one identifier. Python, C (and most modern languages) see this ident, operator, ident. As I understand it this IS the lexical structure of the language and the lexer is the part that implements this: - in cobol/lisp keeping it as one - in python/C breaking it into 3 Maybe you understand in some other way the phrase "lexical structure"? > And the grammatical structure of the language wouldn't change at all. > Sure a-b would now be an identifier and not an operation but that is > of no concern for the parser. About grammar maybe what you are saying will hold: presumably if the token-set is the same, one could keep the same grammar, with the differences being entirely inter-lexeme ones. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
Op 04-12-13 13:01, rusi schreef: > On Wednesday, December 4, 2013 3:59:06 PM UTC+5:30, Antoon Pardon wrote: >> Op 04-12-13 11:09, rusi schreef: >>> I used the spaces case to indicate the limit of chaos. >>> Other characters (that >>> already have uses) are just as problematic. >> >> I don't agree with the latter. As it is now python can make the >> distinction between >> >> from A import Band fromAimportB. >> >> I see no a priori reason why this should be limited to letters. A >> language designer might choose to allow a bigger set of characters >> in identifiers like '-', '+' and others. In that case a-b would be >> an identifier and a - b would be the operation. Just as in python >> fromAimportB is an identifier and from A import B is an import >> statement. > > Im not sure what you are saying. > Sure a language designer can design a language differently from python. > I mentioned lisp. Cobol is another behaving exactly as you describe. > > My point is that when you do (something like) that, you will need to change > the > lexical and grammatical structure of the language. And this will make > for rather far-reaching changes ALL OVER the language not just in > what-follows-dot. No you don't need to change the lexical and grammatical structure of the language. Changing the characters allowed in identifiers, is not a change in lexical structure. The only difference in lexical structuring would be that '-', '>=' and other similars symbols would have to be treated like keyword like 'from', 'as' etc instead of being recognizable by just being present. And the grammatical structure of the language wouldn't change at all. Sure a-b would now be an identifier and not an operation but that is of no concern for the parser. People would have to be careful to insert spaces around operators and that might make the language somewhat error prone but that doesn't mean the syntactical structure is different. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 3:59:06 PM UTC+5:30, Antoon Pardon wrote: > Op 04-12-13 11:09, rusi schreef: > > I used the spaces case to indicate the limit of chaos. > > Other characters (that > > already have uses) are just as problematic. > > I don't agree with the latter. As it is now python can make the > distinction between > > from A import Band fromAimportB. > > I see no a priori reason why this should be limited to letters. A > language designer might choose to allow a bigger set of characters > in identifiers like '-', '+' and others. In that case a-b would be > an identifier and a - b would be the operation. Just as in python > fromAimportB is an identifier and from A import B is an import > statement. Im not sure what you are saying. Sure a language designer can design a language differently from python. I mentioned lisp. Cobol is another behaving exactly as you describe. My point is that when you do (something like) that, you will need to change the lexical and grammatical structure of the language. And this will make for rather far-reaching changes ALL OVER the language not just in what-follows-dot. IOW: I dont agree that we have a disagreement :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wed, Dec 4, 2013 at 10:30 PM, Jussi Piitulainen wrote: > Hm. Can't specific classes be made to behave this way even now by > implementing suitable underscored methods? Yup. Definitely possible. I don't think it'd be a good idea, though, not without somehow changing every dict method into a stand-alone function. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
rusi writes: > On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote: > > On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote: > > > Its a more fundamental problem than that: > > > It emerges from the OP's second post) that he wants '-' in the > > > attributes. Is that all? > > > > > > Where does this syntax-enlargement stop? Spaces? Newlines? > > > > At non-strings. > > > > >>> setattr(foo, 21+21, 42) > > Traceback (most recent call last): > > File "", line 1, in > > TypeError: attribute name must be string, not 'int' > > Not sure what's your point. > > OP wants attribute identifiers like > outer_fieldset-inner_fieldset-third_field. > Say I have a python expression: > obj.outer_fieldset-inner_fieldset-third_field > > It can (in the proposed extension) be parsed as above, or as: > obj.outer_fieldset - inner_fieldset-third_field > the first hyphen being minus and the second being part of the > identifier. > > How do we decide which '-' are valid identifier components -- > hyphens and which minus-signs? I think the OP might be after the JavaScript mechanism where an attribute name can be any string, the indexing brackets are always available, and the dot notation is available when the attribute name looks like a simple identifier. That could be made to work. (I'm not saying should, or should not. Just that it seems technically simple.) Hm. Can't specific classes be made to behave this way even now by implementing suitable underscored methods? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 4:03:14 PM UTC+5:30, Chris Angelico wrote: > On Wed, Dec 4, 2013 at 9:09 PM, rusi wrote: > > OP wants attribute identifiers like > > outer_fieldset-inner_fieldset-third_field. > > Say I have a python expression: > > obj.outer_fieldset-inner_fieldset-third_field > > I don't think so. What the OP asked for was: > > my_object.'valid-attribute-name-but-not-valid-identifier' > > Or describing it another way: A literal string instead of a token. This is just pushing the issue one remove away. Firstly a literal string is very much a token -- lexically. Now consider the syntax as defined by the grammar. Let Ident = Set of strings* that are valid python identifiers -- something like [a-zA-Z][a-zA-Z0-9]* Let Exp = Set to strings* that are python expressions * Note that I am using string from the language implementers pov not language user ie the python identifier var is the implementers string "var" whereas the python string literal "var" is the implementer's string "\"var\"" Now clearly Ident is a proper subset of Exp. Now what is the proposal? You want to extend the syntactically allowable a.b set. If the b's can be any arbitrary expression we can have var.fld(1,2) with the grammatical ambiguity that this can be (var.fld)(1,2) -- the usual interpretation Or var.(fld(1,2)) -- the new interpretation -- ie a computed field name. OTOH if you say superset of Ident but subset of Exp, then we have to determine what this new limbo set is to be. ie what is the grammatical category of 'what-follows-a-dot' ?? Some other-language notes: 1. In C there is one case somewhat like this: #include "string" the "string" cannot be an arbitrary expression as the rest of C. But then this is not really C but the C preprocessor 2. In lisp the Ident set is way more permissive than in most languages -- allowing operators etc that would be delimiters in most languages. If one wants to go even beyond that and include say spaces and parenthesis -- almost the only delimiters that lisp has -- one must write |ident with spaces| ie for identifiers the bars behave somewhat like strings' quote marks. Because the semantics of identifiers and strings are different -- the lexical structures need to reflect that difference -- so you cannot replace the bars by quotes. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 2013-12-04 21:33, Chris Angelico wrote: > I don't think so. What the OP asked for was: > > my_object.'valid-attribute-name-but-not-valid-identifier' > > Or describing it another way: A literal string instead of a token. > This is conceivable, at least, but I don't think it gives any > advantage over a dictionary. In both cases (attribute-access-as-dict-functionality and attribute-access-as-avoiding-setattr), forcing a literal actually diminishes Python's power. I like the ability to do a[key.strip().lower()] = some_value setattr(thing, key.strip().lower(), some_value) which can't be done (?) with mere literal notation. What would they look like? a.(key.strip().lower()) = some_value (note that "key.strip().lower()" not actually a "literal" that ast.literal_eval would accept). That's pretty ugly, IMHO :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wed, Dec 4, 2013 at 9:09 PM, rusi wrote: > OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field. > Say I have a python expression: > obj.outer_fieldset-inner_fieldset-third_field I don't think so. What the OP asked for was: my_object.'valid-attribute-name-but-not-valid-identifier' Or describing it another way: A literal string instead of a token. This is conceivable, at least, but I don't think it gives any advantage over a dictionary. What you could do, though, is create a single object that can be indexed either with dot notation or as a dictionary. For that to work, there'd have to be some restrictions (eg no leading underscores - at very least, __token__ should be special still), but it wouldn't be hard to do - two magic methods and the job's done, I think; you might even be able to manage on one. (Code golf challenge, anyone?) Of course, there's still the question of whether that even is an advantage. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
Op 04-12-13 11:09, rusi schreef: > On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote: >> On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote: >>> Its a more fundamental problem than that: >>> It emerges from the OP's second post) that he wants '-' in the attributes. >>> Is that all? >>> >>> Where does this syntax-enlargement stop? Spaces? Newlines? >> >> At non-strings. >> > setattr(foo, 21+21, 42) >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: attribute name must be string, not 'int' > > Not sure what's your point. > > OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field. > Say I have a python expression: > obj.outer_fieldset-inner_fieldset-third_field > > It can (in the proposed extension) be parsed as above, or as: > obj.outer_fieldset - inner_fieldset-third_field > the first hyphen being minus and the second being part of the identifier. > > How do we decide which '-' are valid identifier components -- hyphens > and which minus-signs? > > So to state my point differently: > The grammar of python is well-defined > It has a 'sub-grammar' of strings that is completely* free-for-all ie just > about anything can be put into a string literal. > The border between the orderly and the wild world are the quote-marks. > Remove that border and you get complete grammatical chaos. > [Maybe I should have qualified my reference to 'spaces'. > Algol-68 allowed spaces in identifiers (for readability!!) > The result was chaos] > > I used the spaces case to indicate the limit of chaos. Other characters (that > already have uses) are just as problematic. I don't agree with the latter. As it is now python can make the distinction between from A import Band fromAimportB. I see no a priori reason why this should be limited to letters. A language designer might choose to allow a bigger set of characters in identifiers like '-', '+' and others. In that case a-b would be an identifier and a - b would be the operation. Just as in python fromAimportB is an identifier and from A import B is an import statement. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote: > On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote: > > Its a more fundamental problem than that: > > It emerges from the OP's second post) that he wants '-' in the attributes. > > Is that all? > > > > Where does this syntax-enlargement stop? Spaces? Newlines? > > At non-strings. > > >>> setattr(foo, 21+21, 42) > Traceback (most recent call last): > File "", line 1, in > TypeError: attribute name must be string, not 'int' Not sure what's your point. OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field. Say I have a python expression: obj.outer_fieldset-inner_fieldset-third_field It can (in the proposed extension) be parsed as above, or as: obj.outer_fieldset - inner_fieldset-third_field the first hyphen being minus and the second being part of the identifier. How do we decide which '-' are valid identifier components -- hyphens and which minus-signs? So to state my point differently: The grammar of python is well-defined It has a 'sub-grammar' of strings that is completely* free-for-all ie just about anything can be put into a string literal. The border between the orderly and the wild world are the quote-marks. Remove that border and you get complete grammatical chaos. [Maybe I should have qualified my reference to 'spaces'. Algol-68 allowed spaces in identifiers (for readability!!) The result was chaos] I used the spaces case to indicate the limit of chaos. Other characters (that already have uses) are just as problematic. * Oh well there are some restrictions like quotes need to be escaped, no newlines etc etc -- minor enough to be ignored. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/03/2013 09:45 PM, Tim Roberts wrote: Piotr Dobrogost wrote: Attribute access syntax being very concise is very often preferred to dict's interface. It is not "very concise". It is slightly more concise. x = obj.value1 x = dct['value1'] You have saved 3 keystrokes. That is not a significant enough savings to create new syntax. Remember the Python philosophy that there ought to be one way to do it. That should be "one obvious way". On my keyboard, at least, those are an important three keystrokes! ;) To be clear, I am -1 on the new syntax. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote: > Its a more fundamental problem than that: > It emerges from the OP's second post) that he wants '-' in the attributes. > Is that all? > > Where does this syntax-enlargement stop? Spaces? Newlines? At non-strings. >>> setattr(foo, 21+21, 42) Traceback (most recent call last): File "", line 1, in TypeError: attribute name must be string, not 'int' -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 11:15:05 AM UTC+5:30, Tim Roberts wrote: > Piotr Dobrogost wrote: > > > >Attribute access syntax being very concise is very often preferred > >to dict's interface. > > It is not "very concise". It is slightly more concise. > > x = obj.value1 > x = dct['value1'] > > You have saved 3 keystrokes. That is not a significant enough savings to > create new syntax. Remember the Python philosophy that there ought to be > one way to do it. Its a more fundamental problem than that: It emerges from the OP's second post) that he wants '-' in the attributes. Is that all? Where does this syntax-enlargement stop? Spaces? Newlines? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
Piotr Dobrogost wrote: > >Attribute access syntax being very concise is very often preferred >to dict's interface. It is not "very concise". It is slightly more concise. x = obj.value1 x = dct['value1'] You have saved 3 keystrokes. That is not a significant enough savings to create new syntax. Remember the Python philosophy that there ought to be one way to do it. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 2013-12-03 15:47, Piotr Dobrogost wrote: > > The getattr function is meant for when your attribute name is in a > > variable. Being able to use strings that aren't valid identifiers > > is a side effect. > > Why do you say it's a side effect? I think random832 is saying that the designed purpose of setattr() was to dynamically set attributes by name, so they could later be accessed the traditional way; not designed from the ground-up to support non-identifier names. But because of the getattr/setattr machinery (dict key/value pairs), it doesn't prevent you from having non-identifiers as names as long as you use only the getattr/setattr method of accessing them. I see non-traditional-identifiers most frequently in test code where the globals() dictionary gets injected with various objects for testing purposes, driven by a table with descriptors. Something like (untested) tests = [ dict(desc="Test 1", input=10, expected=42), dict(desc="Test 2", input=314, expected=159), ] for test in tests: test_name = "test_" + test["desc"] globals()[test_name] = generate_test_function( test["input"], test["output"]) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Tuesday, December 3, 2013 6:31:58 PM UTC+1, Ethan Furman wrote: > > When would you have attribute names that are not valid identifiers? > See my answer to rand's post. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Tuesday, December 3, 2013 7:03:41 PM UTC+1, rand...@fastmail.us wrote: > On Tue, Dec 3, 2013, at 12:14, Piotr Dobrogost wrote: > > > Hi! > > > I find global getattr() function awkward when reading code. > > What is the reason there's no "natural" syntax allowing to access > > attributes with names not being valid Python identifiers in a similar way > > to other attributes? > > Something along the line of > > my_object.'valid-attribute-name-but-not-valid-identifier'? > > The getattr function is meant for when your attribute name is in a > variable. Being able to use strings that aren't valid identifiers is a > side effect. Why do you say it's a side effect? Could you elaborate? I see nothing odd in passing literal (string literal in this case) as a value of function's argument. > Why are you designing classes with attributes that aren't > valid identifiers? Attribute access syntax being very concise is very often preferred to dict's interface. That's why various containers expose their elements as attributes. In my case I'm using in-house web form library which provides FieldSet class holding objects of type Field or other FieldSets. This nesting leads to names of the form 'outer_fieldset-inner_fieldset-third_field' which are not valid identifiers due to minus sign. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Tue, Dec 3, 2013, at 12:14, Piotr Dobrogost wrote: > Hi! > > I find global getattr() function awkward when reading code. > What is the reason there's no "natural" syntax allowing to access > attributes with names not being valid Python identifiers in a similar way > to other attributes? > Something along the line of > my_object.'valid-attribute-name-but-not-valid-identifier'? The getattr function is meant for when your attribute name is in a variable. Being able to use strings that aren't valid identifiers is a side effect. Why are you designing classes with attributes that aren't valid identifiers? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/03/2013 09:14 AM, Piotr Dobrogost wrote: I find global getattr() function awkward when reading code. What is the reason there's no "natural" syntax allowing to access attributes with names not being valid Python identifiers in a similar way to other attributes? Something along the line of my_object.'valid-attribute-name-but-not-valid-identifier'? When would you have attribute names that are not valid identifiers? -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Tue, 3 Dec 2013 09:14:49 -0800 (PST), Piotr Dobrogost wrote: I find global getattr() function awkward when reading code. Me too. What is the reason there's no "natural" syntax allowing to access attributes with names not being valid Python identifiers in a similar way to other attributes? There is. Just use a dictionary. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On 12/3/13 12:14 PM, Piotr Dobrogost wrote: Hi! I find global getattr() function awkward when reading code. What is the reason there's no "natural" syntax allowing to access attributes with names not being valid Python identifiers in a similar way to other attributes? Something along the line of my_object.'valid-attribute-name-but-not-valid-identifier'? Regards, Piotr Dobrogost I don't know the real reason, but I imagine it would be that it would be very rarely used. It would need to be an attribute that isn't a valid identifier, and you know the attribute at the time you write the code. I can see scenarios for needing attributes that aren't identifiers, but in many of them you also need to access them through a variable rather than literally. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Why is there no natural syntax for accessing attributes with names not being valid identifiers?
Hi! I find global getattr() function awkward when reading code. What is the reason there's no "natural" syntax allowing to access attributes with names not being valid Python identifiers in a similar way to other attributes? Something along the line of my_object.'valid-attribute-name-but-not-valid-identifier'? Regards, Piotr Dobrogost -- https://mail.python.org/mailman/listinfo/python-list
