Make blurb working in Python 3.5. #143
Conversation
|
Just replaces f-strings with classic string formatting. |
|
Best way to ensure this doesn't regress would be to include a 3.5 configuration in the CI matrix. |
There was a problem hiding this comment.
No. If this is committed, I have to maintain it, and I'm not using %-formatting in 2017. I am quite surprised you used %-formatting, given that it's only still in Python 3 for backwards compatibility. It is NOT recommended for new work.
Sorry, but if you want me to accept this PR, you're going to have to use the "".format or "".format_map methods.
|
Also, is this solving a problem for you? The only other person who suggested backporting to 3.5 was Antoine Pitrou, who also said that he used blurb to create a NEWS item, and therefore it wasn't an actual problem for him. So clearly he was suggesting it as an abstract problem, not a concrete problem affecting him personally. I'd rather not bother with Python 3.5 compatibility if it's not actually a problem. |
I'm running Fedora 25 which is less than 6 months old, and the system Python 3 is still Python 3.5. Please make blurb compatible with Python 3.5 at least. Making it compatible with Python 3.4 would be better. It's a pain to install a custom Python on Linux. Require Python 3.6 only makes contributing to Python harder. It's already hard enough. Larry: there are at least 3 core dev who ask you for 3.5 compatibility: @pitrou, @serhiy-storchaka and now also me. There PR is ready to be merged, I reviewed it. If you prefer format(), please rewrite the PR. |
|
I can provide you with easy instructions on how to install a custom Python on Linux. I do it all the time. I'm sorry, but I'm not so interested in 3.5 support that I'm going to rewrite the PR, nor am I going to accept a PR with %-formatting. I do not accept your making demands on my time in this way. If you can't reasonably expect CPython core developers to be using the current version of Python--which shipped last year--then we might as well all go home. |
|
Is is possible to change .gitignore so blurb will run in the master repository build, as I suggested on pydev, without creating un-ignored artifacts? This would solve the issue for any patch originally applied to master or 3.6 and then backported. |
|
@terryjreedy that question seems off-topic for this pull request. |
|
It is a suggestion that would make this pull request, which Larry does not like, unneeded. I don't consider it 'off-topic' to try to solve a standoff. |
|
Larry:
Oh, it seems like you miss the point here. Maybe you missed Antoine Pitrou's thread on python-dev, "[Python-Dev] Helping contributors with chores (do we have to?)". The point here is to make contributions to Python as easy as possible. Require to compile and install Python, and then install blurb on this "custom" Python, is a non trivial step for new contributors. I would prefer that blurb would be as easy as possible to install. Especially since it seems like blurb will become required to propose a change on CPython, since most changes must be documented with a NEWS entry. Even if the blurb format is not too complex, I don't expect that someone coming from a different project would already know this format. In short, even if you make blurb as easy to install and as easy to use, it still remains a new step to learn for newcomers. So please, don't make harder to install, to because Python 3.6 is cool ;-)
I asked you to write a PR since I don't undestand which kind of formatting do you format. For str.format(), there are "{0}".format(arg), "{}".format(arg), "{arg}".format(arg=arg), "{arg}".format(locals()), etc. But ok, I wrote a PR: PR #146, using "{}".format(arg) syntax. I prefer this style since it's short, don't require to repeat "arg" 3 times, and avoid the magic locals() which kills performances. |
|
Larry:
Hum, why would you be the only maintainer? It seems like other people want to help you, no? Larry:
Well, discussing coding style usually means invoking trolls, but well... I'm not aware of anyone saying that str%args is only used for Python 2 compatibilty. It's like the old legend that str%args is going to be removed when Python 3000 will be released. Nope. FYI I like str%args because the format is super simple, it's very close to C printf that I like, and it's very easy to reformat it on multiple lines, which is sometimes required on project which require a strict maximum number of columns (80 or 120). I feel pain when I try to write "... long string ...".format(... long list of arguments ...) on multiple lines. When I can, I always prefer f-string, so it basically combines all advantages. But I try to restrict myself on using f-string on tests in CPython. But even inside CPython, it becomes painful when then you backport the changes to 3.5, and then to 2.7 (yeah, 2.7 is still maintained ;-)).
Ok, that's what I did ;-) (PR #146) |
|
@terryjreedy the PR is about removing f-strings to make blurb run on Python 3.5, so I guess I'm just not understanding the connection to |
|
@serhiy-storchaka can you change the patch to use |
|
Never mind, we have a new PR: #146 for this. Closing this one. |
|
Just providing my $0.02 to the conversation with my downstream maintainer hat on. Linux distros most of the time come preinstalled with a specific version of python3 so unless you are on a rolling distro, there is no way that people will have the latest python3 release, thus they will not be able to use tooling that is being created with only the latest python3 version in mind. This will drive away a lot of potential contributors. e.g. I remember being a pain to actually use the cherry-picker script which uses f-strings. People do not replace the system installed python3 with a compiled one from sources just because, and contributing to cpython should not consist of messing with your base system installation/workflow etc. |
|
There are of course solutions to have a local Python install without messing system-wide state. But I agree that it's better to not require such an install if we want things to be easy for contributors. As for |
|
Antoine Pitrou:
As for cherry_picker, since it's a tool solely for Python core developers, it can admittedly be a little stricter in its requirements.
I disagree. Python is not only developed by Python core developers,
but a much wider group of contributors. cherry_picker is used by
non-core developers as well. I can give you a long list of backport PR
created by non-core devs ;-)
|
No description provided.