[issue44864] [argparse] Do not translate user-provided strings in `ArgumentParser.add_subparsers()`
Jérémie Detrey added the comment: Hi, Thank you for the clarification! In fact, I'm afraid the localization feature of `argparse` is undocumented. (At least, I couldn't find anything about it in the documentation.) A hint that modules should only take care of their own strings can however be inferred from <https://docs.python.org/3/library/gettext.html#deferred-translations>: “In most coding situations, strings are translated where they are coded.” But the fact remains that the `argparse` module deals with user-provided strings in a non-consistent way: all other user-provided strings (such as the `usage`, `description`, or `epilog` parameters to `ArgumentParser`'s constructor, for instance) are not translated by `argparse` (leaving this responsibility with the caller); only the `title` and `description` parameters to `ArgumentParser.add_subparsers()` will be translated if provided. This behavior discrepancy is what prompted me to report this as a bug in the first place, but since this is an undocumented feature anyway, I'm perfectly fine with this being categorized as an enhancement instead. Kind regards, Jérémie. -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue44864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44865] [argparse] Missing translations
Jérémie Detrey added the comment: Hi again! As for #44864, I've just added a short blurb to the PR. The fact that a few strings are missing calls to the localization function (whereas most of the other strings in `argparse` are already localized) might push this issue toward the bug-fix side, but, as for #44864, this is very minor and I really don't mind if it only gets merged into future releases. Thanks! Kind regards, Jérémie. -- ___ Python tracker <https://bugs.python.org/issue44865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44864] [argparse] Do not translate user-provided strings in `ArgumentParser.add_subparsers()`
Jérémie Detrey added the comment: Hi Terry, Thanks for the feedback! I've just added a blurb to the PR. Regarding the issue type, even though this is indeed translation-related, I'd lean toward a bug report rather than an enhancement request: the fact that user-provided strings get fed to the localization function by the `argparse` module is contrary to the expected behavior, and thus should qualify as a bug. However, since this is very minor, I'm totally fine with this being applied only to future versions! Thanks again! Kind regards, Jérémie. -- ___ Python tracker <https://bugs.python.org/issue44864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44865] [argparse] Missing translations
Change by Jérémie Detrey : -- keywords: +patch pull_requests: +26157 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27668 ___ Python tracker <https://bugs.python.org/issue44865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33775] argparse: the word 'default' (in help) is not marked as translatable
Change by Jérémie Detrey : -- versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.9 ___ Python tracker <https://bugs.python.org/issue33775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44865] [argparse] Missing translations
New submission from Jérémie Detrey : Dear all, There are a few strings in the `argparse` module which are not translatable through the `gettext` API. Some have already been reported: - the "--version" help text at 3.9/Lib/argparse.py:1105 (reported in issue 16786, fixed by PR 12711); - the "default" help text at 3.9/Lib/argparse.py:697 (reported in 33775, fixed by PR 12711). However, some others remain: - the "default" help text for `BooleanOptionalAction` at 3.9/Lib/argparse.py:878 (which, incidentally, will be duplicated when used with `ArgumentDefaultsHelpFormatter`); - the "argument %(argument_name)s: %(message)s" error message at 3.9/Lib/argparse.py:751; - the formatted section heading at 3.9/Lib/argparse.py:225: if the heading itself is translatable, the string "%(heading)s:" is not. More precisely, the colon right after the heading might also require localization, as some languages (e.g., French) typeset colons with a preceding non-breaking space (i.e., "%(heading)s :"). (Okay, I'll admit that this is nitpicking!) I'll submit a pull request with proposed fixes for these strings. Kind regards, Jérémie. -- components: Library (Lib) messages: 399216 nosy: jdetrey priority: normal severity: normal status: open title: [argparse] Missing translations type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16786] argparse doesn't offer localization interface for "version" action
Change by Jérémie Detrey : -- versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5 ___ Python tracker <https://bugs.python.org/issue16786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16786] argparse doesn't offer localization interface for "version" action
Jérémie Detrey added the comment:
Dear all,
As commented on PR 12711
(https://github.com/python/cpython/pull/12711#pullrequestreview-724899323),
there is a slight issue with the proposed patch, as it translates the
`--version` help string as soon as the `argparse` module is imported (at which
point the programmer might not have correctly initialized the `gettext` global
domain yet). The suggested modification of PR 12711 should fix this, so that
the translation only happens when an instance of `_VersionAction` is actually
created:
```
diff a/Lib/argparse.py b/Lib/argparse.py
--- a/Lib/argparse.py
+++ b/Lib/argparse.py
@@ -1042,7 +1042,9 @@ def __init__(self,
version=None,
dest=SUPPRESS,
default=SUPPRESS,
- help="show program's version number and exit"):
+ help=None):
+if help is None:
+help = _("show program's version number and exit")
super(_VersionAction, self).__init__(
option_strings=option_strings,
dest=dest,
```
However, I'm not sure I understand correctly Pavel's comment as to why merging
this patch would make some old programs lose their translation for this string:
since `argparse` does not itself provide any translation, it is up to the
programmers to provide `gettext` translations for `argparse` strings as well.
Adding the call to `_()` here seems harmless to me:
- if a program already has a `gettext` translation string for "show program's
version number and exit", it will be used, as expected;
- otherwise, if it hasn't (and relies on other mechanisms to translate this
string), the string will remain untranslated, and the "custom" translation
mechanisms will be able to process it as before.
In any case, my guess is that localized programs already explicitly pass a
localized help string to the `_VersionAction` constructor in order to
circumvent the nonlocalized default help string:
```
parser.add_argument('-V', action='version', version='%(prog)s 3.9',
help=_("show program's version number and exit"))
```
These programs should also remain completely unaffected by this change.
Thanks!
Kind regards,
Jérémie.
--
nosy: +jdetrey
___
Python tracker
<https://bugs.python.org/issue16786>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44864] [argparse] Do not translate user-provided strings in `ArgumentParser.add_subparsers()`
New submission from Jérémie Detrey :
Dear all,
In the `argparse` module, the `ArgumentParser.add_subparsers()` method may call
the `_()` translation function on user-provided strings. See e.g.
3.9/Lib/argparse.py:1776 and 3.9/Lib/argparse.py:L1777:
def add_subparsers(self, **kwargs):
# [...]
if 'title' in kwargs or 'description' in kwargs:
title = _(kwargs.pop('title', 'subcommands'))
description = _(kwargs.pop('description', None))
When elements `'title'` and/or `'description'` are set in `kwargs`, they will
be popped from the dictionary and then fed to `_()`. However, these are
user-provided strings, and it seems to me that translating them should be the
user's responsibility. This seems to be the expected behavior for all other
user-provided strings in the `argparse` module: see e.g. the `ArgumentParser`'s
`description` parameter (in 3.9/Lib/argparse.py:1704 then
3.9/Lib/argparse.py:1312), which never gets translated by the `argparse` module.
However, the default title string `'subcommands'` should still be localized.
Therefore, I'd suggest restricting the call to `_()` to this string only, as in
the following:
title = kwargs.pop('title', _('subcommands'))
description = kwargs.pop('description', None)
I'll submit a pull request with this change.
Kind regards,
Jérémie.
--
components: Library (Lib)
messages: 399212
nosy: jdetrey
priority: normal
severity: normal
status: open
title: [argparse] Do not translate user-provided strings in
`ArgumentParser.add_subparsers()`
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue44864>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17164] MozillaCookieJar does not handle session cookies
Jérémie Detrey added the comment: Hi again, Attached is a patch for adding test cases to test_cookiejar. Cheers, Jérémie. -- Added file: http://bugs.python.org/file37629/session-cookies-test.patch ___ Python tracker <http://bugs.python.org/issue17164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17164] MozillaCookieJar does not handle session cookies
Jérémie Detrey added the comment: Dear all, Here is a small tentative patch for fixing this issue. Expiry times for session cookies are now written as "0", and both "0" and "" are parsed as valid expiry times for session cookies. Cheers, Jérémie. -- keywords: +patch nosy: +jdetrey versions: +Python 3.6 Added file: http://bugs.python.org/file37627/session-cookies.patch ___ Python tracker <http://bugs.python.org/issue17164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2190] MozillaCookieJar ignore HttpOnly cookies
Changes by Jérémie Detrey : -- versions: +Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue2190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2190] MozillaCookieJar ignore HttpOnly cookies
Jérémie Detrey added the comment: Dear all, In fact, this cookie.txt format is still used by curl. For instance, see https://github.com/bagder/curl/blob/curl-7_39_0/lib/cookie.c#L644 which clearly shows support for the "#HttpOnly_" prefix. Therefore, supporting this format in http.cookiejar.MozillaCookieJar seems quite relevant to me. Attached is an updated patch. Kind regards, Jérémie. -- nosy: +jdetrey Added file: http://bugs.python.org/file37625/httponly.patch ___ Python tracker <http://bugs.python.org/issue2190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20581] Incorrect behaviour of super() in a metaclass-created subclass
Changes by Jérémie Detrey : -- versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue20581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20581] Incorrect behaviour of super() in a metaclass-created subclass
New submission from Jérémie Detrey:
Dear all,
I've been noticing a strange (and probably incorrect) behaviour of the super()
function when using a metaclass in order to automatically replace a class
declaration by a subclass of itself.
In the attached test case, the function `wrap' is used to create such a
subclass: given the original class `cls' in input, it declares and returns the
subclass `Wrapper(cls)' whose constructor calls the original one from `cls':
>>> def wrap(cls):
... print("In wrap() for class %s" % cls.__name__)
... name = cls.__name__
... class Wrapper(cls):
... def __init__(self, *args, **kwargs):
... print("In Wrapper(%s).__init__()" % name)
... super().__init__(*args, **kwargs)
... return Wrapper
...
When `wrap' is used as a decorator (as for class `B' in the test case), the
correct behaviour is observed: the identifier `B' now represents the
`Wrapper(B)' subclass, the MRO is as expected (`Wrapper', then the original
class `B', then `object'), and instantiating a `B' object correctly calls the
constructors in the right order:
>>> @wrap
... class B:
... def __init__(self):
... print("In B.__init__()")
... super().__init__()
...
In wrap() for class B
>>> B.mro()
[.Wrapper'>, , ]
>>> B()
In Wrapper(B).__init__()
In B.__init__()
<__main__.wrap..Wrapper object at 0x7fa8c6adb410>
Now, let us automatically call the `wrap' function from a metaclass' `__new__'
method upon declaration of the class (such as class `A' in the test case):
>>> class Metaclass(type):
... def __new__(meta, name, bases, namespace):
... print("In Metaclass.__new__() for class %s" % name)
... cls = super().__new__(meta, name, bases, namespace)
... return cls if cls.__name__ == 'Wrapper' else wrap(cls)
...
>>> class A(metaclass = Metaclass):
... def __init__(self):
... print("In A.__init__()")
... super().__init__()
...
In Metaclass.__new__() for class A
In wrap() for class A
In Metaclass.__new__() for class Wrapper
The MRO still looks correct:
>>> A.mro()
[.Wrapper'>, , ]
However, instantiating the class `A' creates an infinite recursion in the
original constructor `A.__init__', just as if the `super()' call had somehow
gotten confused between the original class declared as `A' and its subclass,
which is now referred to by the identifier `A':
>>> A()
In Wrapper(A).__init__()
In A.__init__()
In A.__init__()
In A.__init__()
In A.__init__()
[...]
Maybe I'm doing something wrong somewhere, but it seems to me that the
behaviour should at least be the same for classes `A' and `B'.
Kind regards,
Jérémie.
--
components: Interpreter Core
files: bug.py
messages: 210829
nosy: jdetrey
priority: normal
severity: normal
status: open
title: Incorrect behaviour of super() in a metaclass-created subclass
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34020/bug.py
___
Python tracker
<http://bugs.python.org/issue20581>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
