Groups > comp.lang.python > #60953 > unrolled thread

Why is there no natural syntax for accessing attributes with names not being valid identifiers?

Started by	Piotr Dobrogost <p@google-groups-2013.dobrogost.net>
First post	2013-12-03 09:14 -0800
Last post	2013-12-05 01:50 +0000
Articles	17 on this page of 57 — 20 participants

Back to article view | Back to comp.lang.python

Page 3 of 3 — ← Prev page 1 2 [3]

#61014

From	Chris Angelico <rosuav@gmail.com>
Date	2013-12-04 22:40 +1100
Message-ID	<mailman.3558.1386157205.18130.python-list@python.org>
In reply to	#61013

On Wed, Dec 4, 2013 at 10:30 PM, Jussi Piitulainen
<jpiitula@ling.helsinki.fi> 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

[toc] | [prev] | [next] | [standalone]

#61042

From	Ethan Furman <ethan@stoneleaf.us>
Date	2013-12-04 07:56 -0800
Message-ID	<mailman.3581.1386175350.18130.python-list@python.org>
In reply to	#61013

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~

[toc] | [prev] | [next] | [standalone]

#61070

From	Ian Kelly <ian.g.kelly@gmail.com>
Date	2013-12-04 19:43 -0700
Message-ID	<mailman.3598.1386211480.18130.python-list@python.org>
In reply to	#61004

On Wed, Dec 4, 2013 at 3:09 AM, rusi <rustompmody@gmail.com> 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 "<stdin>", line 1, in <module>
>> 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.

[toc] | [prev] | [next] | [standalone]

#61079

From	rusi <rustompmody@gmail.com>
Date	2013-12-04 20:48 -0800
Message-ID	<893d6e43-ac3b-4459-b72b-3106157a301d@googlegroups.com>
In reply to	#61070

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 "<stdin>", line 1, in <module>
> >> 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!

[toc] | [prev] | [next] | [standalone]

#61063

From	Dennis Lee Bieber <wlfraed@ix.netcom.com>
Date	2013-12-04 19:27 -0500
Message-ID	<mailman.3594.1386203271.18130.python-list@python.org>
In reply to	#60991

On Tue, 3 Dec 2013 22:31:44 -0800 (PST), rusi <rustompmody@gmail.com>
declaimed the following:

>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?

	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?
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#61066

From	Roy Smith <roy@panix.com>
Date	2013-12-04 20:03 -0500
Message-ID	<roy-137A15.20031404122013@news.panix.com>
In reply to	#61063

In article <mailman.3594.1386203271.18130.python-list@python.org>,
 Dennis Lee Bieber <wlfraed@ix.netcom.com> 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

[toc] | [prev] | [next] | [standalone]

#60994

From	Ethan Furman <ethan@stoneleaf.us>
Date	2013-12-04 01:12 -0800
Message-ID	<mailman.3547.1386148372.18130.python-list@python.org>
In reply to	#60990

On 12/03/2013 09:45 PM, Tim Roberts wrote:
> Piotr Dobrogost <p@google-groups-2013.dobrogost.net> 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~

[toc] | [prev] | [next] | [standalone]

#61018

From	Roy Smith <roy@panix.com>
Date	2013-12-04 08:23 -0500
Message-ID	<roy-5898BE.08232404122013@news.panix.com>
In reply to	#60990

In article <17gt99hg615jfm7bdid26185884d2pfdkf@4ax.com>,
 Tim Roberts <timr@probo.com> wrote:

> Piotr Dobrogost <p@google-groups-2013.dobrogost.net> 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.

[toc] | [prev] | [next] | [standalone]

#61050

From	Piotr Dobrogost <p@google-groups-2013.dobrogost.net>
Date	2013-12-04 13:00 -0800
Message-ID	<c6264768-3485-4872-b575-da9d4c070fc7@googlegroups.com>
In reply to	#61018

On Wednesday, December 4, 2013 2:23:24 PM UTC+1, Roy Smith wrote:
> In article <17gt99hg615jfm7bdid26185884d2pfdkf@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

[toc] | [prev] | [next] | [standalone]

#61044

From	Piotr Dobrogost <p@google-groups-2013.dobrogost.net>
Date	2013-12-04 12:07 -0800
Message-ID	<5eb566a0-3911-48fa-ba83-a863da66a55d@googlegroups.com>
In reply to	#60990

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

[toc] | [prev] | [next] | [standalone]

#61047

From	Ethan Furman <ethan@stoneleaf.us>
Date	2013-12-04 12:22 -0800
Message-ID	<mailman.3584.1386190041.18130.python-list@python.org>
In reply to	#61044

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~

[toc] | [prev] | [next] | [standalone]

#61048

From	Mark Lawrence <breamoreboy@yahoo.co.uk>
Date	2013-12-04 20:55 +0000
Message-ID	<mailman.3585.1386190551.18130.python-list@python.org>
In reply to	#61044

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

[toc] | [prev] | [next] | [standalone]

#61053

From	Ethan Furman <ethan@stoneleaf.us>
Date	2013-12-04 13:00 -0800
Message-ID	<mailman.3589.1386193611.18130.python-list@python.org>
In reply to	#61044

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~

[toc] | [prev] | [next] | [standalone]

#61056

From	Terry Reedy <tjreedy@udel.edu>
Date	2013-12-04 17:11 -0500
Message-ID	<mailman.3590.1386195130.18130.python-list@python.org>
In reply to	#61044

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

[toc] | [prev] | [next] | [standalone]

#61061

From	Piotr Dobrogost <p@google-groups-2013.dobrogost.net>
Date	2013-12-04 15:42 -0800
Message-ID	<451d174b-6620-476d-bf84-a76c6b1de87e@googlegroups.com>
In reply to	#61056

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

[toc] | [prev] | [next] | [standalone]

#61074

From	Terry Reedy <tjreedy@udel.edu>
Date	2013-12-04 22:21 -0500
Message-ID	<mailman.3601.1386213683.18130.python-list@python.org>
In reply to	#61061

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

[toc] | [prev] | [next] | [standalone]

#61069

From	Rotwang <sg552@hotmail.co.uk>
Date	2013-12-05 01:50 +0000
Message-ID	<l7om66$219$1@dont-email.me>
In reply to	#61044

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')?

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

csiph-web

Why is there no natural syntax for accessing attributes with names not being valid identifiers?

Contents

#61014

#61042

#61070

#61079

#61063

#61066

#60994

#61018

#61050

#61044

#61047

#61048

#61053

#61056

#61061

#61074

#61069