Max Bachmann added the comment:
Thanks Dennis. This helped me track down the issue in rapidfuzz.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Max Bachmann added the comment:
It appears this only occurs when a C Extension is involved. When the so is
imported first it is preferred over the .py file that the user would like to
import. I could not find any documentation on this behavior, so I assume that
this is not the intended.
My
New submission from Max Bachmann :
In my environment I installed the following two libraries:
```
pip install rapidfuzz
pip install python-Levenshtein
```
Those two libraries have the following structures:
rapidfuzz
|-distance
|- __init__.py (from . import Levenshtein)
|- Levenshtein.*.so
Max Bachmann added the comment:
As far as a I understood this is caused by the same reason:
```
>>> s = '123\U00010900456'
>>> s
'123𐤀456'
>>> list(s)
['1', '2', '3', '𐤀', '4', '5',
Max Bachmann added the comment:
> That is using Python 3.9 in the xfce4-terminal. Which xterm are you using?
This was in the default gnome terminal that is pre-installed on Fedora 34 and
on windows I directly opened the Python Terminal. I just installed
xfce4-terminal on my Fedora 34 mach
Max Bachmann added the comment:
This is the result of copy pasting example posted above on windows using
```
Python 3.7.8 (tags/v3.7.8:4b47a5b6ba, Jun 28 2020, 08:53:46) [MSC v.1916 64 bit
(AMD64)] on win32
```
which appears to run into similar problems:
```
>>> s
New submission from Max Bachmann :
I noticed that when using the Unicode character \U00010900 when inserting the
character as character:
Here is the result on the Python console both for 3.6 and 3.9:
```
>>> s = '0𐤀00'
>>> s
'0𐤀00'
>>> ls = l
New submission from Max Bachmann :
The documentation stated, that the PyUnicode_KIND macro has the following
interface:
- int PyUnicode_KIND(PyObject *o)
However it actually returns a value of the underlying type of the
PyUnicode_Kind enum. This could be e.g. an unsigned int as well
New submission from Max Bachmann :
The documentation of PyObject_Call here:
https://docs.python.org/3/c-api/call.html#c.PyObject_Call
states, that it is the equivalent of the Python expression: callable(*args,
**kwargs).
so I would expect:
PyObject* args = PyTuple_New(0);
PyObject* kwargs
