[Python-ideas] One way to do format and print

[Andrew Barnert]

On Sep 9, 2015, at 15:45, Sven R. Kunze <srkunze at mail.de> wrote:
> 
>> On 09.09.2015 23:50, Andrew Barnert wrote:
>> And if not the docs, what else would it mean to "de-emphasize" %-formatting without deprecating or removing it?
> 
> The docs are most important. Sorry, if that didn't come across clearly.

No problem.

>>> Anyway, Google presented me the version 2.7 of the tutorial.
>> That's a whole other problem. But nobody is going to retroactively change Python 2.7 just to help people who find the 2.7 docs when they should be looking for 3.5.
> 
> The Python docs are not Python. So, what's in the way of adding this note to Python 2.7 docs? The pride of the Python core devs? I anticipate better of you.

First, the Python docs are part of Python. They're owned by the same foundation, managed by the same team, and updated with a similar process.

Second, I'm not a core dev, and since the Python docs are maintained by the core devs, that stands in the way of me personally making that change. :)

Of course I can easily file a docs bug, with a patch, and possibly start a discussion on the relevant list to get wider discussion. But you can do that as easily as I can, and I don't know why you should anticipate better of me than you do of yourself. (If you don't feel capable of writing the change, because you're not a native speaker or your tech writing skills aren't as good as your coding skills or whatever, I won't argue that your English seems good enough to me; just write a "draft" patch and then ask for people to improve it. There are docs changes that have been done this way in the past, and I think there are more than enough people who'd be happy to help.)

>> The solution is to get people to the 3.5 or 3.6 docs in the first place, not to hack up the 2.7 docs.
> 
> You have absolutely no idea why people use 2.7 over 3.5, right? I promise you that is going to take time.

Of course I don't know why _every_ person still using 2.7 is doing so. For myself personally, off the top of my head, recent reasons have included: maintaining an existing, working app that wouldn't gain any benefit from upgrading it; writing a simple script to be deployed on servers that have 2.7 pre-installed; and writing portable libraries to share on PyPI that work on both 2.7 and 3.3+ to make them useful to as many devs as possible. I know other people do it for similarly good reasons, or different ones (e.g., depending on some library that hasn't been ported yet), and also for bad reasons (related to outdated teaching materials or FUD or depending on some library that has been ported but they checked a 6-year-old blog instead of current information). I know that we're still a few years away from the end of the initial transition period, so none of this surprises me much.

But how is any of that, or any additional factors I don't know about, relevant to the fact that using the 2.7 docs (and especially the tutorial) when coding for 3.5 is a bad idea, and a problem to be fixed? How does any of it mean that making the 2.7 docs apply better to 3.5 but worse to 2.7 is a solution?

>>> I still don't understand what's wrong with deprecating %, but okay.
>> Well, have you read the answers given by Nick, me, and others earlier in the thread? If so, what do you disagree with?
> 
> All "blockers" I read so far classify as a) personal preference of % over {} or b) fixable. Both classes do not qualify as real blockers; they can be overcome.
> 
>> You've only addressed one point (that % is faster than {} for simple cases--and your solution is just "make {} faster", which may not be possible given that it's inherently more hookable than % and therefore requires more function calls...).
> 
> Try harder. (If {} is too slow for you.)
> 
> I've read Python 3 is significantly slower than Python 2. So what? I can live with that, when we will make the transition. If we recognize the performance penalty, rest assured I come back here to seek your advice but until that it's no reason not to switch to Python 3. Same goes for string formatting.
> 
>> What about formatting headers for ASCII wire protocols, sharing tables of format strings between programming languages (e.g., for i18n), or any of the other reasons people have brought up?
> Both fixable in some way or another, the rest classifies as described above.

Just saying "I want % deprecated, and I declare that all of the apparent blocking problems are solvable, and therefore I demand that someone else solve them and then deprecate %" is not very useful.

If you think that's the way Python should go, come up with solutions for all of the ones that need to be fixed (and file bugs and ideally patches), and good arguments to dismiss the ones you don't think need to be fixed. Then you can argue that the only remaining reason not to deprecate % is backward compatibility, which isn't compelling enough, and that may well convince everyone.