[Python-Dev] PEP460 thoughts from a Mercurial dev (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Jan 13 17:51:31 CET 2014

On 13 January 2014 23:57, Augie Fackler <raf at durin42.com> wrote:

(sorry for not piling on any existing threads - I don't subscribe to python-dev due to lack of time)

Brett Cannon asked me to chime in - I haven't actually read the very long thread at this point, I'm just providing responses to things Brett mentioned: 1) What do we need in terms of functionality Best guess, %s, %d, and %f. I've not done a full audit of the code, but some limited looking over the grep hits for % in .py files suggests I'm right, and we could even do without %f (we only use that for 'hg --time' output, which we could do in unicode).

I think PEP 460 will have you covered there, or hopefully asciistr on 3.3+

We also need some way to emit raw bytes (in potentially mixed encodings, yes I know this is "doing it wrong") to stdout/stderr (example: someone changes a file from latin1 to utf8, and then wants to see the resulting diff).

Writing to sys.stdout.buffer may work for that, or else being able to change the encoding of an existing stream. For the latter, Victor had a working patch to _pyio at http://bugs.python.org/issue15216 and general consensus that the semantics were sensible, but it needs to be worked up into a full patch that covers the C version as well (I tried to muster some helpers for that in the leadup to 3.4 feature freeze, but unfortunately without any luck)

2) Would having it as an external library that worked with Python 2 help?

Probably, IF it came with 2.4 support (RHEL support, basically), and we could bundle it in our source tree. It's been extremely valuable to have the install only depend on a working C compiler and Python.

asciicompat.asciistr is just an alias for str on Python 2.x, so if we get that working, it may be something you could vendor into Mercurial for Python 3.3+ support. (There will likely be gaps in what asciistr can do due to interoperability issues in the core types, but the PEP 393 changes to the internal representation mean it should be able to get us pretty close)

3) If this does go in, how long would it take us to port Mercurial to py3? Would it being in 3.5 hold us up?

I'm honestly not sure. I'm still in the outermost layers of this yak shave: fixing cyclic imports. I'll know more when I can at least get 'hg version' to print its own version, because at that point the testsuite failures might be informative. I'd honestly rather this went into 3.5 and got lots of validation by both us and twisted (the other folks that care?) before becoming set in stone by a release. Does that make sense?

Yes, that actually makes a lot of sense to me - there's no point in us rushing to get this into 3.4 and then you folks discovering in 6 months it doesn't quite work for you, and then having to wait for 3.5 anyway (or, worse, Python 3 being locked into a solution that doesn't work for you by it's own internal backwards compatibility requirements).

4) Do we care if it's .format()/%, or could it be in the stdlib? It'd be really nice to not have to boil the oceans as far as editing everyplace in the codebase that does % today. If we do have to do that, it's not going to be much more helpful than something like: def maybestr(a): if isinstance(a, bytes): return a.decode('latin1) return a def sprintf(fmt, *args): (fmt.decode('latin1') % [maybestr(a) for a in args]).encode('latin1) or similar. That was (roughly) what I was figuring I'd do today without any formal bytes-string-formatting support.

Agreed - I think the two solutions that potentially make the most sense are PEP 460 and an interoperable third party type like asciistr. They each have different pros and cons, so I'm actually currently a plan of doing both (if Guido is amenable to my suggestion of providing both ASCII compatible and binary interpolation).

He also mentioned that some are calling for a shortened 3.5 release cycle - I'd rather not see that happen, for the aforementioned reason of wanting time to make sure this is Right - it'd be a shame to do the work and rush it out only to find something missing in an important way.

By shortened, we're mostly talking about ensuring 3.5 is published before the 2.7.9 maintenance release. So early-to-mid 2015 rather than the more typical late 2015.

Feel free to ask further questions - I'll try to respond promptly.

Thanks for the contribution! I found it very helpful :)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list