[issue47187] locale module example is wrong for some platforms
New submission from Sylvain Marie : The example in the doc shows ```python >>> import locale >>> loc = locale.getlocale() # get current locale # use German locale; name might vary with platform >>> locale.setlocale(locale.LC_ALL, 'de_DE') >>> locale.strcoll('f\xe4n', 'foo') # compare a string containing an umlaut >>> locale.setlocale(locale.LC_ALL, '') # use user's preferred locale >>> locale.setlocale(locale.LC_ALL, 'C') # use default (C) locale >>> locale.setlocale(locale.LC_ALL, loc) # restore saved locale ``` However locale.getlocale() does not return the locale for all categories (locale.LC_ALL is even not allowed) but the locale for the LC_CTYPE category. Therefore restoring it using `locale.setlocale(locale.LC_ALL, loc)` does not actually restore the initial settings, and may even fail on some platforms (on mine it does). The correct example should have the first line of code replaced with ``` >>> loc = locale.setlocale(locale.LC_ALL) # get current locale ``` Note: this issue was first reported in the `pandas` library at https://github.com/pandas-dev/pandas/issues/46595 -- assignee: docs@python components: Documentation messages: 416487 nosy: docs@python, smarie priority: normal severity: normal status: open title: locale module example is wrong for some platforms versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue47187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44452] Allow paths to be joined without worrying about a leading slash
Sylvain Marie added the comment: +1 on this, I am totally in line with the original post. The / operator semantics should not imply any notion of drive or of "cd" command on a shell. It should simply stick to "concatenate", i.e. "create child path" (and actually this is what the doc states https://docs.python.org/3/library/pathlib.html#operators ) Thanks Zbyszek for putting this on the table ! -- nosy: +smarie ___ Python tracker <https://bugs.python.org/issue44452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36553] inspect.is_decorator_call(frame)
Sylvain Marie added the comment: Quick update on this feature: for the following example to work: from inspect import is_decorator_call def set_hello_tag(tag='world'): if is_decorator_call(): # called without parenthesis! # the decorated object is `tag` return set_hello_tag()(tag) # note that `is_decorator_call` should not return True for this call else: def decorate(f): setattr(f, 'hello', tag) # set a hello tag on the decorated f return f return decorate Then `is_decorator_call` should be callable without arguments (default to current frame) and should return `True` only if the current frame is the one directly following decorator application. In nested frames (such as the one obtained after first recursive call to `set_hello_tag` above, `is_decorator_call` should return `False`. -- ___ Python tracker <https://bugs.python.org/issue36553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30129] functools.partialmethod should look more like what it's impersonating.
Sylvain Marie added the comment: For future reference if this topic re-opens, there is now an alternative here: https://smarie.github.io/python-makefun/#removing-parameters-easily Note: it relies on a dynamic `compile` statement so of course it is less optimal than the one in functools. But at least it can serve as a reference... -- nosy: +smarie ___ Python tracker <https://bugs.python.org/issue30129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36553] inspect.is_decorator_call(frame)
New submission from Sylvain Marie : Python decorators are frequently proposed by libraries as an easy way to add functionality to user-written functions: see `attrs`, `pytest`, `click`, `marshmallow`, etc. A common pattern in most such libraries, is that they do not want to provide users with two different symbols for the same function. So they end up implementing decorators that can be used both as decorators (no arguments no parenthesis) AND decorator factories (arguments in parenthesis). This is convenient and intuitive for users. Unfortunately this is not something trivial to implement because the python language does not make any difference between a no-parenthesis decorator call and a with-parenthesis decorator factory call. So these libraries have to rely on "tricks", the most common one being to check existence of a non-default first parameter that is a callable. Examples: https://github.com/python-attrs/attrs/blob/c2a9dd8e113a0dc72f86490e330f25bc0111971a/src/attr/_make.py#L940 https://github.com/pytest-dev/pytest/blob/13a9d876f74f17907ad04b13132cbd4aa4ad5842/src/_pytest/fixtures.py#L1041 https://github.com/marshmallow-code/marshmallow/blob/ec51dff98999f2189a255fb8bbc22e549e3cc673/src/marshmallow/decorators.py#L161 Implementing these tricks is a bit ugly, but more importantly it is a waste of development time because when one changes his decorators signatures, the trick has to possibly be changed (order of arguments, default values, etc). Therefore it is quite a brake to agile development in the first phase of a project, where the api is not very stable. I regrouped all known and possible tricks in a library https://github.com/smarie/python-decopatch/ to provide a handy way to solve this problem. But it is still "a bunch of tricks". This library, or the manual implementations such as the examples above, could be much faster/efficient if there were at least, a way to determine if a frame is a call to `@`. So this is a request to at least have a `inspect.is_decorator_call(frame)` feature in the stdlib. That function would return `True` if the frame is a decorator call using `@`. Note that a more convenient way to solve this problem is also proposed in https://smarie.github.io/python-decopatch/pep_proposal/#2-preserving-backwards-compatibility : it would be to offer a `@decorator_factory` helper in the stdlib. But first feedback from python-ideas mailing list showed that this was maybe too disruptive :) -- components: Library (Lib) messages: 339599 nosy: smarie priority: normal severity: normal status: open title: inspect.is_decorator_call(frame) type: enhancement ___ Python tracker <https://bugs.python.org/issue36553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32886] new Boolean ABC in numbers module
Sylvain Marie added the comment: Mark I get your point. Mine is just to have a common abstraction between python's primitive bool and numpy bool (and possibly other future alternate booleans) for consistency with `numbers` and to be used in common type hints (PEP484). If I get you correctly, then the minimal `Boolean` ABC would only need to contain the `__bool__` method, without the bitwise operations. That's perfectly fine, as long as it correctly describes the minimal boolean logic (truth value for `if`/..., and `and`/`or`/`not`) and is compliant both with python and numpy bool. A separate ABC for bitwise operations is then indeed a good idea to open in a separate thread. Finding a good name will be tough here though... `BitwiseOperable` ? `BitsContainer` ? ... :) Regards -Sylvain -- ___ Python tracker <https://bugs.python.org/issue32886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32886] new Boolean ABC in numbers module
Change by Sylvain Marie : Added file: https://bugs.python.org/file47457/proposal.py ___ Python tracker <https://bugs.python.org/issue32886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32886] new Boolean ABC in numbers module
Sylvain Marie added the comment: @Mark : the '__invert__' method is out of the game since Josh comment (and my reply https://bugs.python.org/issue32886#msg312478 ) So the remaining operations *are* an abstraction of both python bool and numpy bool_ behaviour (and a minimal representation of boolean logic operations that will seem natural to anyone, don't you think ?) -- ___ Python tracker <https://bugs.python.org/issue32886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32886] new Boolean ABC in numbers module + Integral>Integer renaming
Sylvain Marie added the comment: @Mark: you are right. That's why the proposed ABC does NOT inherit from Integral/Integer and focuses on boolean logic in its simplest form (not, and, or, xor). This one is common to both python bool and np.bool_. @Serhiy: thanks for this interesting suggestion ! However having been in the software development world for 12 years, I never met these concepts in practice yet. I suspect that therefore I will not be the only one - I'm afraid that might make this ABC hard to understand. Besides, I am not sure that numpy bool and python bool implement this correctly: >>> True > False True >>> np.bool_(True) > np.bool_(False) True This does not seem to comply with the description I found in https://en.wikipedia.org/wiki/Material_conditional For these reasons I would suggest these operations to be part of a separate class. -Sylvain -- ___ Python tracker <https://bugs.python.org/issue32886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32886] new Boolean ABC in numbers module + Integral>Integer renaming
Sylvain Marie added the comment: Thanks ! 1. > ok 2. > ok 3. > That's simply 'the latest state' in the discussion. I guess that having Boolean in numbers is better than it being in its own module, since it is consistent with the other ABCs (and bool is a subclass of both Boolean and Integral-er). To quote Guido's answer in the discussion thread GVR> A thought just occurred to me. Maybe we should just add a Boolean class to numbers? (several positive answers) SMA > I would rather suggest to keep that Boolean ABC class independent of Integral (see proposal in first post) to let it remain 'pure', i.e. represent logical booleans only. However nothing prevents us to register python bool as a virtual subclass of *both* Integral and Boolean - while np.bool would be registered as a virtual subclass of Boolean only. This would reflect quite well the reality - the fact that python bool is both a Boolean and an Integer, while numpy bool is only a Boolean. GVR> OK, that could work. At this point I think you should just file an issue on bugs.python.org (but since Python 3.7 is in feature freeze, expect this to be put on the 3.8 track). 4. > Very good point. I do not know how do handle this at this point. As long as bool is a subclass of int (changing this is another discussion), the only way to go for now is probably to remove the 'invert' method from this ABC - if I am interpreting your answer correctly? Finally let's note that the Integral > Integer renaming is now handled in a separate thread https://bugs.python.org/issue32891 -- ___ Python tracker <https://bugs.python.org/issue32886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32886] new Boolean ABC in numbers module + Integral>Integer renaming
New submission from Sylvain Marie : This issue is created following the discussion [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module. The following items are suggested: - adding a 'Boolean' ABC class to the 'numbers' module - register python 'bool' as a virtual subclass of both 'Boolean' and 'Integral' - register numpy bool ('np.bool_') as a virtual subclass of 'Boolean' only - rename 'Integral' 'Integer' and leave 'Integral' as an alias for backwards compatibility Below is a proposal Boolean class: - class Boolean(metaclass=ABCMeta): """ An abstract base class for booleans. """ __slots__ = () @abstractmethod def __bool__(self): """Return a builtin bool instance. Called for bool(self).""" @abstractmethod def __and__(self, other): """self & other""" @abstractmethod def __rand__(self, other): """other & self""" @abstractmethod def __xor__(self, other): """self ^ other""" @abstractmethod def __rxor__(self, other): """other ^ self""" @abstractmethod def __or__(self, other): """self | other""" @abstractmethod def __ror__(self, other): """other | self""" @abstractmethod def __invert__(self): """~self""" # register bool and numpy bool_ as virtual subclasses # so that issubclass(bool, Boolean) = issubclass(np.bool_, Boolean) = True Boolean.register(bool) try: import numpy as np Boolean.register(np.bool_) except ImportError: # silently escape pass # bool is also a virtual subclass of Integral. np.bool_ is not. Integral.register(bool) -- components: Library (Lib) messages: 312416 nosy: smarie priority: normal severity: normal status: open title: new Boolean ABC in numbers module + Integral>Integer renaming type: enhancement versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32590] Proposal: add an "ensure(arg)" builtin for parameter validation
Sylvain Marie added the comment: Very much interested by the topic. For reference I tried to summarize the status of inline type and value validation here: https://smarie.github.io/python-valid8/why_validation/ And I proposed a solution with a library here https://smarie.github.io/python-valid8 (with a somewhat smart handling of the ValueError / TypeError inheritance dilemma, for what's worth) -- nosy: +smarie ___ Python tracker <https://bugs.python.org/issue32590> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com