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
