[issue38805] locale.getlocale() returns a non RFC1766 language code
Riccardo Polignieri added the comment:
> `locale.getlocale()` is now returning strange results
Not really "strange results" - fact is, now "getlocale()" returns the locale
name *as if* it were already set from the beginnning (because it is, at least
in part).
Before:
>>> import locale # Python 3.7, new shell
>>> locale.getlocale()
(None, None)
>>> locale.setlocale(locale.LC_ALL, '') # say Hi from Italy
'Italian_Italy.1252'
>>> locale.getlocale()
('Italian_Italy', '1252')
now:
>>> import locale # Python 3.8, new shell
>>> locale.getlocale()
('Italian_Italy', '1252')
As for why returned locale names are "a little different" in Windows, I found
no better explanation that Eryk Sun's essays in
https://bugs.python.org/issue37945. Long story short, it's not even a bug
anymore... it's a hot mess and it won't be solved anytime soon.
But it's not the problem at hand, here. Returned locale names have not changed
between 3.7 and 3.8.
What *is* changed, though, is that now Python on Windows appears to set the
locale, implicitly, right from the start.
Except - maybe it does not, really:
>>> import locale # Python 3.8, new shell
>>> locale.getlocale()
('Italian_Italy', '1252')
>>> locale.localeconv()
{'int_curr_symbol': '', 'currency_symbol': '', 'mon_decimal_point': '',
'mon_thousands_sep': '', 'mon_grouping': [], 'positive_sign': '',
'negative_sign': '', 'int_frac_digits': 127, 'frac_digits': 127,
'p_cs_precedes': 127, 'p_sep_by_space': 127, 'n_cs_precedes': 127,
'n_sep_by_space': 127, 'p_sign_posn': 127, 'n_sign_posn': 127, 'decimal_point':
'.', 'thousands_sep': '', 'grouping': []}
As you can see, we have an Italian locale only in the name: the conventions are
still those of the default C locale.
If we explicitly set the locale, on the other hand...
>>> locale.setlocale(locale.LC_ALL, '')
'Italian_Italy.1252'
>>> locale.localeconv()
{'int_curr_symbol': 'EUR', 'currency_symbol': '€', ... ... }
... now we enjoy a real Italian locale - pizza, pasta, gelato and all.
What happened?
Unfortunately, this change of behaviour is NOT documented, except for a passing
note here: https://docs.python.org/3/whatsnew/changelog.html#id144. It's buried
*very* deep:
"""
bpo-34485: On Windows, the LC_CTYPE is now set to the user preferred locale at
startup. Previously, the LC_CTYPE locale was “C” at startup, but changed when
calling setlocale(LC_CTYPE, “”) or setlocale(LC_ALL, “”).
"""
This explains... something. Python now pre-sets *only* the LC_CTYPE category,
and that's why the other conventions remain unchanged.
Unfortunately, setting *that* one category changes the result yielded by
locale.getlocale(). But this is not a bug either, because it's the same
behaviour you would have in Python 3.7:
>>> locale.setlocale(locale.LC_CTYPE, '') # Python 3.7
'Italian_Italy.1252'
>>> locale.getlocale()
('Italian_Italy', '1252')
...and that's because locale.getlocale() with no arguments default, wait for
it, to getlocale(category=LC_CTYPE), as documented!
So, why Python 3.8 now pre-sets LC_CTYPE on Windows? Apparently, bpo-34485 is
part of the ongoing shakespearian feud between Victor Stinner and the Python
locale code. If you squint hard enough, you will see the answer here:
https://vstinner.github.io/locale-bugfixes-python3.html but at this point, I
don't know if anyone still keeps the score.
To sum up:
- there's nothing new about locale names - still the same mess;
- if locale names as returned by locale.getlocale() bother you, you should
follow Victor's advice here: https://bugs.python.org/issue37945#msg361806. Use
locale.setlocale(category, None) instead;
- if you relied on getlocale() with no arguments to test your locale, assuming
that either a locale is unset or it is "fully set", then you should stop now. A
locale can also be "partially set", and in fact it's just what happens now on
Windows by default. You should test for a specific category instead;
- changing the way the locale is set by default on Windows can be... rather
surprising and can lead to misunderstandings. I would certainly add a note in
the locale documentation to explain this new behaviour.
--
nosy: +ricpol
___
Python tracker
<https://bugs.python.org/issue38805>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: Three years later, this problem seems on the way to fix itself (https://xkcd.com/1822/). Versioned shebangs (and versioned "/env" shebangs) used to be a more prominent issue when you needed a way to tell Python 2 / Python 3 scripts apart. With the sunset of Python 2.7-3.3 almost completed, now we have a reasonably homogeneous block of inter-compatible Pythons. True, py.exe won't cope very well with versioned shebangs, but this seems to become less and less annoying by the day. As for the other problem from issue 39785, ie Python 2 still being selected as "default" in deference to some arcane Linux convention that we have been dragging for ten years (even on Windows!)... it would be nice to finally have *that* fixed. But then again, having Python 2 installed on your Windows box is becoming increasingly rare. Most users are likely never hitting this weirdness any more. In the meantime, now we have yet another way of installing Python on Windows... versioned executables from the Store! With no py.exe! So, who knows, maybe py.exe is the past, versioned executable are the future... To sum up, while I would certainly add a note to the docs, to clarify that py.exe does not support versioned "/env" shebangs, IMO today the work needed to specify a behaviour for all possible cases, possibly even extending/modifying Linux conventions, is just too much to be worth the effort. -- ___ Python tracker <https://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist
Change by Riccardo Polignieri : -- nosy: +ricpol ___ Python tracker <https://bugs.python.org/issue38671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33189] pygettext doesn't work with f-strings
Riccardo Polignieri <riccardo.poligni...@gmail.com> added the comment:
> the error should be better
Yes, that's what I maeant - sorry I should have phrased better.
I marked by mistake a couple of f-strings for translation and totally forgot
about it for a while... it took me some time to figure out what was going on
with this NameError popping out of nowhere.
Curiously, xgettext handles this thing better (...or, far worse actually): it
just parses the f-string as a regular one, producing something like
msgid "hello {x}"
msgstr ""
But then of course Python will fail *silently* at runtime, never picking up the
translated version of the string...
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33189>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33189] pygettext doesn't work with f-strings
New submission from Riccardo Polignieri <riccardo.poligni...@gmail.com>:
Tested (on windows) with python 3.6, but I guess it's the same in py3.7:
# test.py
def hello(x):
print(_(f'hello {x}'))
> py pygettext.py test.py
Traceback (most recent call last):
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 623, in
if __name__ == '__main__':
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 597, in main
for _token in tokens:
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 328, in
__call__
## 'tstring:', tstring
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 382, in
__openseen
elif ttype == tokenize.STRING:
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 236, in
safe_eval
# unwrap quotes, safely
File "", line 1, in
NameError: name 'x' is not defined
--
components: Demos and Tools
messages: 314712
nosy: Riccardo Polignieri
priority: normal
severity: normal
status: open
title: pygettext doesn't work with f-strings
type: behavior
versions: Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33189>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: @Jens Lindgren I know, pretty annoying right? But see previous answer by Paul here http://bugs.python.org/issue28686#msg287181 > The Unix ability to have 2 different versions of Python on PATH > and select which you use based on executable name doesn't exist > on Windows, and so there's no equivalent of the > Unix "#!/usr/bin/env pythonX[.Y]" Now if you ask me, I would expect py.exe to handle all common types of shebang you may find in the wild. But I assume that the correct answer instead is that "#!/usr/bin/env pythonX[.Y]" is not a portable shebang, and you just should stop using it. If you happen to find such a shebang in someone else's script, file a bug report there. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: Paul: > When inside a venv: - If you want to execute a script, use a shebang of #!/usr/bin/env python and then use `py myscript.py` Yes, I'm totally on board with this - that is, as far as I run my own scripts. I just wonder, what if one day I pip install someone else's work, and then bang!, 'py' is just working differently now, for a non-local reason, and without alerting me. It's true that all major libraries use the "right" kind of shebang these days... Still, I find it a bit disturbing nevertheless. But thanks for the clarifications, anyways - now 'py' expected behavior is much more clear to me. Eryk: > it's far simpler to just support versioned executable names Keeping my fingers crossed about this. > Even if we don't install links/copies with these names, I don't see the harm > in allowing the launcher to look for them. Users can create the links manually True, but It would allow for yet another possible source of confusion I'm afraid. No, if py were to look for versioned executables, then versioned executable should be supplied imo. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: Paul: > it's not possible to tell by inspection the version of a Python interpreter. True, but it's an implementation detail. Couldn't be solved? Versioned interpreters a la Linux, of course, or maybe how about including some kind of manifest file? Steve: > including versioned executables wouldn't that resolve this issue naturally? Definitely. Paul: > 1. Use the Python executable that's first on PATH: "py" Except, that's currently *almost never* true when I'm inside a venv! (For this to be true, I must give up on versioned shebangs). Now, if only 'py' could *always* look at the PATH *only*, ignoring shebangs - well this would be at least consistent behavior. Now, the absolute worst scenario here is when you have a prompt like "(myenv) $>" screaming to your face that you are inside a venv, and you go "py foo.py" expecting the venv interpreter to execute foo.py, because you are inside a venv, right? But wait!, foo.py was actually written by some Linux hacker, therefore *versioned* shebang, therefore 'py' fetches the wrong (system) Python, therefore no dependencies found, therefore crash. How I'm supposed to solve this? Paul: > The only change I'd consider reasonable here would be a doc change Thanks, it would really help, because I'm afraid I can't make it work for me. Most of all, I would really appreciate some sort of "best practice" suggestion on how to put together 'py', venvs and shebang. At the moment, I'm afraid my provisional policy is as follows: - when outside a venv (almost never) it's ok to 'py'; - when inside a venv (almost always) go 'python' the old way, because 'py' is unreliable here, *unless* you manually check the shebang of your scripts before you execute them. Which practically means - almost never use 'py'. Is this the correct way to go? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: > I'm inclined to say YAGNI, and we simply leave "/usr/bin/env python3" > undefined. I can't say I'm really happy with this answer. Fact is, 1) you almost always have to work from within a virtual env these days, 2) you really want to have meaningful shebangs (ie, version-specific) in your scripts because, well, 2017 and the world is still split between py2 and py3, 3) the py.exe launcher is the new shiny thing and we all just want to use it. So, it *could* annoy some people to find out that py.exe just can't handle both venvs and shebangs in a meaningful way, and you must give up on either venvs, or shebangs, or py.exe. As far as I know (3.6.0 and 2.7.13), you have 3 ways to invoke a script: 1) "version-specific" launcher (eg "py -3 foo.py"): this will always pick the system interpreter, never abides neither venvs nor shebangs. A perfectly defined, utterly useless behavior. 2) invoke interpreter (eg "python foo.py", the good old way): this will always be venvs-complaint, will never parse shebangs. And yet at the moment, it's probably your best option *when* inside a venv - and the worst when outside, of course. 3) "version-agnostic" launcher (eg "py foo.py"). Outside a venv, this will always abide version-specific shebangs (ie, "#!python3"); the only quirk being that when facing a generic shebang instead, it will pick Python 2 (because, 2017 and Linux...). Oh well, I can live with that. But when you are inside a venv, then - if it finds a "not-env" shebang (ie "python" or "/usr/bin/python"), then it will NOT abide the venv - frustrating, yet correct I suppose; - if it finds any kind of version-specific shebang (EVEN a "env"-type of shebang!), then again it will follow the shebang but NOT the venv, and will pick up the system interpreter. That, even when you are inside a venv that perfectly matches the shebang prescription. Now, this can be very frustrating because a useless "/usr/bin/env python" shebang triggers the correct behavior both inside and outside a venv, BUT a much more useful "usr/bin/env python3" will fail even if we are inside a matching venv. I feel that all it needs to be perfect is some kind of behavior like this: dear py.exe, - when you are invoked in a version-agnostic way, and - when you find an "env"-and-version-specific shebang in the script, then please, - just look at my %path% before doing anything else. It could be that the first interpreter you find there will just match the requirement from the shebang (that is, because on occasion I just know what I'm doing, and I've just activated a matching venv, you see). If so, just give me that Python and I will be ok; - otherwise, my bad: feel free to resume any other search strategy you find appropriate, and I will humbly accept whatever interpreter you may fetch, even a php one. I think this would be just reasonable enough. What I'm missing here? -- nosy: +ricpol ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
