On 26 October 2016 at 20:58, Stephen J. Turnbull email@example.com wrote:
import collections def translate_or_drop(string, table): """ string: a string to process table: a dict as accepted by str.translate """ return string.translate(collections.defaultdict(lambda: None, **table))
All OK now?
Not really. I tried with a simple example intab = "ae" outtab = "XM" table = string.maketrans(intab, outtab) collections.defaultdict(lambda: None, **table)
an this gives me TypeError: type object argument after ** must be a mapping, not str
But I probably I misunderstood the idea. Anyway this code does not make much sence to me, I would never in life understand what is meant here. And in my not so big, but not so small, Python experience I *never* had an occasion using collections or lambda.
sets as a single, universal character set. As it happens, although there are differences of opinion over how to handle Unicode in Python, there is consensus that Python does have to handle Unicode flexibly, effectively and efficiently.
I was merely talking about syntax and sources files standard, not about unicode strings. No doubt one needs some way to store different glyph sets.
So I was talking about that if one defines a syntax and has good intentions for readability in mind, there is not so many rationale to adopt the syntax to current "hybrid" system: 7-bit and/or multibyte paradigm. Again this a too far going discussion, but one should not probably much look ahead on those. The situation is not so good in this sense that most standard software is attached to this strange paradigm (even those which does not have anything to do with multi-lingual typography). So IMO something gone wrong with those standard characters.
If you insist on bucking it, you'll have to do it pretty much alone, perhaps even maintaining your own fork of Python.
As for me I would take the path of developing of own IDE which will enable typografic quality rendering and of course all useful glyphs, such as curly quotes, bullets, etc, which all is fundamental to any possible improvements of cognitive qualities of code. And I'll stay in 8-bit boundaries, thats for sure. So if Python will take the path of "unicode" code input (e.g. for some punctuaion characters) this would only add a minor issue for generating valid Python source files in this case.