[Twisted-Python] PEP3131: non-ascii identifiers

[Wolfgang Rohdewald]

Am Montag, 8. September 2014, 12:04:46 schrieb exarkun at twistedmatrix.com:
> PB supports unicode perfectly well and has for many years.  This is why 
> I asked which specific part of PB has a problem.

PB transfers names of methods and classes as bytes, not as unicode.
Which is logical since PY2 does not support unicode identifiers,
and bytes is already a native PY2 string. Unicode is only used
for content. It not yet always clear to me what is content and
what is a formal string like method names or the *_atom strings
which must be bytes, this needs more testing.

I guess I should patch banana.py such that it dumps all it encodes
or decodes into one file, so I can compare output from PY2/PY3 tests.

I was assuming that suddenly transferring method names as unicode
would really be a break of wire protocol stability, or do you
think otherwise? If you think this is acceptable, I will check
if the existing twisted code can handle getting those as unicode
without source code changes. Not sure. Just tested this with 
Python2.6, and I am surprised that it works:

>>> getattr(A,u'x')
<unbound method A.x>


Supporting PEP3131 would only introduce a backward-incompatibility.

Of course you are right that this is not part of porting.

Right now I have a long list of small unsorted git commits, I will 
have to do a lot of reshuffling and cleaning before I will ask
you how to get it into the official codebase.
Not all of those commits are strictly porting, some just clean
the code, making the porting commits simpler.

> A failing unit test or a minimal example (<http://sscce.org/>) would 
> communicate this most clearly, but perhaps you can just mention a 
> specific API and give an incomplete example of how it will fail when it 
> runs up against the changes defined by PEP 3131.

see my first mail in this thread: take test_pb.py, rename getSimple
to getSimpleä, run the test.

-- 
Wolfgang