On Fri, Dec 15, 2017 at 03:38:20AM +0100, Xen wrote: > Colin Watson schreef op 09-12-2017 13:51: > > Even as somebody generally very sympathetic to the needs of > > localisation, I've got this wrong because Python 2 had just too many > > ways to make mistakes in this area. > > So you are basically saying that you still don't agree but you have somehow > accepted your own fallibility in that something you like is wrong and > something you dislike is right.
No - you're putting words in my mouth that are the opposite of what I'm saying. Kindly don't reply to try to convince me otherwise. In general, I dislike programming idioms that are too easy to get wrong. > I happen to know the % operator ;-). > > It is ridiculous that you cannot use it for binary-only text, or what I > would call just.... byte strings. You can use the % operator on bytes, as of Python 3.5. Please spend more time checking the assertions you make. It's the much newer "format" method that still isn't supported on bytes, and from https://bugs.python.org/issue3982#msg268160 it sounds like that's intentional and well-founded. https://docs.python.org/3/whatsnew/3.5.html#whatsnew-pep-461 (Python 3.5 is in Ubuntu 16.04; while some people may care, I'm not personally especially interested in earlier versions of Python 3 at this point, although I've been using it on and off since 3.2 or so.) While I know there are exceptions, some mentioned in that issue link above, on the whole my impression is that old Python code isn't likely to be using str.format very much anyway, since it's a relatively modern innovation compared to Python 2; it was introduced in 2.6. > This example really says it all: > > Python 2: b'Content-length: {}\r\n'.format(length) > > Python 3: b''.join([b'Content-length: ', (bytes if bytes is str else > str)(length).encode('ascii'), b'\r\n']) > > Or well, that is 2<>3 compatible code. Sure, if you work at it you can always construct unnecessarily complicated examples. "bytes if bytes is str else str" is strictly identical to "str", on both Python 2 and 3. (Glyph is an extremely experienced and competent developer, so I'm sure this was just an oversight.) But you can just do this instead, which in fact is roughly what Twisted, the source of the above comment, now does: Python 2/3: b'Content-Length: %d\r\n' % length (As mentioned above, str.format was new in Python 2.6, so this is just a return to the status quo ante for bytes.) > So if this person does keep maintaining this project and it gets some > traction, you could have a 'supported' python 2 interpretor being callable > by "python2" or "python2.7" or even "python2.8" for some time to come. > > If more people rally around that you could even have an unofficial > 'official' Python 2.8 specification ;-). > > Of which Tauthon would then be one interpreter ;-). > > You could then move Tauthon (package "tauthon") to universe around the time > that you would move python 2.7 out of it. If it turns out that the maintainer of Tauthon builds a sustained track record of doing a good job with it, then I'd support it being available in Ubuntu. There's still quite a while until Python 2.7 is in any danger of being removed from Ubuntu, so there's time for them to develop such a track record. (I don't think we should hold back other packaged libraries to support it, though; for example, Django 2.0 dropped support for Python 2. So it might be that Tauthon users would end up in practice with an Ubuntu-packaged interpreter and then using packages from PyPI in a virtualenv for most things that aren't in the standard library, or something like that. That would possibly work well enough; the audience for something like Tauthon probably also wants to stick with old library versions as well, at least until they can upgrade in a tightly-controlled fashion.) -- Colin Watson [cjwat...@ubuntu.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
