[issue47187] locale module example is wrong for some platforms

2022-04-01 Thread Sylvain Marie 


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

2021-09-10 Thread Sylvain Marie 


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)

2019-10-10 Thread Sylvain Marie 


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.

2019-09-20 Thread Sylvain Marie 


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)

2019-04-08 Thread Sylvain Marie 


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

2018-04-17 Thread Sylvain Marie 

Sylvain Marie <sylvain.ma...@schneider-electric.com> 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 <rep...@bugs.python.org>
<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

2018-02-22 Thread Sylvain Marie 

Change by Sylvain Marie <sylvain.ma...@schneider-electric.com>:


Added file: https://bugs.python.org/file47457/proposal.py

___
Python tracker <rep...@bugs.python.org>
<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

2018-02-22 Thread Sylvain Marie 

Sylvain Marie <sylvain.ma...@schneider-electric.com> 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 <rep...@bugs.python.org>
<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

2018-02-21 Thread Sylvain Marie 

Sylvain Marie <sylvain.ma...@schneider-electric.com> 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 <rep...@bugs.python.org>
<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

2018-02-21 Thread Sylvain Marie 

Sylvain Marie <sylvain.ma...@schneider-electric.com> 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 <rep...@bugs.python.org>
<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

2018-02-20 Thread Sylvain Marie 

New submission from Sylvain Marie <sylvain.ma...@schneider-electric.com>:

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 <rep...@bugs.python.org>
<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

2018-01-19 Thread Sylvain Marie 

Sylvain Marie <sylvain.ma...@schneider-electric.com> 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 <rep...@bugs.python.org>
<https://bugs.python.org/issue32590>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com