Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


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

Re: Bug? Feature? setattr(foo, '3', 4) works!

Started byCem Karan <cfkaran2@gmail.com>
First post2014-12-20 08:30 -0500
Last post2014-12-20 08:30 -0500
Articles 1 — 1 participant

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Bug? Feature? setattr(foo, '3', 4) works! Cem Karan <cfkaran2@gmail.com> - 2014-12-20 08:30 -0500

#82696 — Re: Bug? Feature? setattr(foo, '3', 4) works!

FromCem Karan <cfkaran2@gmail.com>
Date2014-12-20 08:30 -0500
SubjectRe: Bug? Feature? setattr(foo, '3', 4) works!
Message-ID<mailman.17070.1419082228.18130.python-list@python.org>
On Dec 19, 2014, at 10:33 AM, random832@fastmail.us wrote:

> On Fri, Dec 19, 2014, at 07:23, Ben Finney wrote:
>> Cem Karan <cfkaran2@gmail.com> writes:
>>> I'd like to suggest that getattr(), setattr(), and hasattr() all be
>>> modified so that syntactically invalid statements raise SyntaxErrors.
>> 
>> What syntactically invalid statements? The only syntactically invalid
>> statements I see you presenting are ones that *already* raise
>> SyntaxError.
>> 
>> I think you mean that setting an attribute on an object should be a
>> SyntaxError if the resulting attribute's name is not a valid identifier.
>> But why should a valid statement produce SyntaxError?
>> 
>> I'm −1 on such a change.
> 
> And some APIs - ctypes, for example - actually require using getattr
> with an invalid identifier in some cases (where attribute access is used
> for an underlying concept with names that are usually, but not always,
> valid identifiers: in ctypes' case, looking up symbols from DLLs.)

This is the one part I didn't know of; if ctypes requires this behavior, then it can't be changed.

Dave Angel, the reason I wanted to raise a SyntaxError is because from a user's point of view they look like the same type of error.  That said, you're right that for anyone trying to debug the interpreter itself raising SyntaxError would make things confusing. 

Regardless, because ctypes requires it, it can't be changed.  I'm dropping the suggestion.

Thanks,
Cem Karan

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web