Szorc: Mercurial's Journey to and Reflections on Python 3
Szorc: Mercurial's Journey to and Reflections on Python 3
Posted Jan 25, 2020 11:03 UTC (Sat) by smurf (subscriber, #17840)In reply to: Szorc: Mercurial's Journey to and Reflections on Python 3 by togga
Parent article: Szorc: Mercurial's Journey to and Reflections on Python 3
Python3 source code is Unicode. Python attribute access is written as "object.attr". This "attr" part therefore must be Unicode. Why would you want to use anything else? If you need bytestrings as keys, or integers for that matter, use a dict.
Posted Jan 25, 2020 21:44 UTC (Sat)
by togga (subscriber, #53103)
[Link] (3 responses)
>Why would you want to use anything else?
>"use a dict."
>>> a=type('A', (object,), {})()
Posted Jan 29, 2020 12:32 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (2 responses)
Sure, if you want to be pedantic you can use "-*- coding: iso-8859-1 -*-" (or whatever) in the first two lines and write your code in Latin1 (or whatever), but that's just the codec Python uses to read the source. It's still decoded to Unicode internally.
> >"use a dict."
Currently. In CPython. Other Python implementations, or future versions of CPython, may or may not use what is, or looks like, a generic dict to do that.
Yes, I do question why anybody would want to use attributes which then can't be accessed with `obj.attr` syntax. That's useless.
Use a (real) dict.
Posted Feb 12, 2020 20:40 UTC (Wed)
by togga (subscriber, #53103)
[Link] (1 responses)
As I said above, it's a necessity due to the design of library APIs. Examples of needed, otherwise unnecessary, encode/decode are plenty (and error-prone). Article mentions a few, I've already mentioned ctypes where for instance structure field names (often read from binary APIs such as c strings, etc) is required to be attributes.
This thread has become a bit off topic. The interesting question for me is Python 2to3 language regressions or which migrations that are feasible, that stage was done in ~ 2010 to 2013 with several Python3 failed migration attempts. Nothing of value has changed since. Half of my Python2 use-cases is not suited for Python3 due to it's design choices and I do not intend to squeeze any problem in a tool not suited for it. That's more of a fact.
The question back of my head for me is about the other half of my use-cases that fits Python3. Given the experience of python leadership attitudes, decisions, migration pains, etc which the article is one example of. Is python3 a sound language choice for new projects?
Posted Feb 12, 2020 20:47 UTC (Wed)
by togga (subscriber, #53103)
[Link]
Oops.. it should read the opposite. "is not" Python 2to3 language regressions
Szorc: Mercurial's Journey to and Reflections on Python 3
Mostly due to library API:s requiring attributes for many thing. This is a big source for py3 encode/decode errors.
This is what attributes does:
>>> setattr(a, 'b', 22)
>>> setattr(a, b'c', 12)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: attribute name must be string, not 'bytes'
>>> a.__dict__
{'b': 22}
>>> type(a.__dict__)
<class 'dict'>
>>> a.__dict__[b'c']=12
>>> a.__dict__
{'b': 22, b'c': 12}
Szorc: Mercurial's Journey to and Reflections on Python 3
> This is what attributes does:
Also, it's not just bytes, arbitrary strings frequently contains hyphens, dots, or even start with digits.
Szorc: Mercurial's Journey to and Reflections on Python 3
Szorc: Mercurial's Journey to and Reflections on Python 3