[issue41010] email.message.EmailMessage.get_body

[Andrei Kulakov]

Andrei Kulakov  added the comment:

This issue was fixed by https://github.com/python/cpython/pull/26903
(I confirmed that the error no longer happens with attached file).

This can be closed as fixed.

--
nosy: +andrei.avk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44916] Random behaviour when importing two modules with the same name but different source files

[Steven D'Aprano]

Steven D'Aprano  added the comment:

The importing from multiple threads is possibly also non-deterministic, but I'm 
not an expert on the importlib module.

It looks to me like a another plausible source of random/arbitrary behaviour 
could be:


1. Within a single process, you have two threads running in non-deterministic 
order. So you could have, let's say:

- thread 1 imports M from file m1.py
- thread 2 tries to import M, and the import system sees that
  M is cached in sys.modules and uses that instead.


So even though the two threads are writing to different source files, they both 
call the module M, which means that you can have two threads stomping on each 
other's toes trying to import different classes C from different modules both 
called M.

I don't think this is supported at all. I'm not really qualified to rule out a 
bug in the importlib functions but to me it surely looks like a case of "don't 
do that".

Remember that sys.modules is cached globally per-process, so once you start 
pickling and unpickling your M.C instances, its a lottery which one you will 
get; furthermore, if you have instances:

x = M.C()
replace module M with a new module M
y = M.C()

only y is using the new definition of C from the new module M, instance x is 
still using the original class with its original methods.

I'll leave it to Brett, Nick or Eric to confirm that there's nothing to fix in 
importlib, but my advice is to avoid using dynamically created modules **all 
with the same name** that touch the file system from multiple threads in 
multiple processes at the same time. There is far too many opportunities for 
non-deterministic behaviour to mess up your expectations.

--
nosy: +brett.cannon, eric.snow, ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44916] Random behaviour when importing two modules with the same name but different source files

[Steven D'Aprano]

Steven D'Aprano  added the comment:

"Undefined behaviour" has a particular meaning to C programmers, which is 
relevant to Python because the interpreter is written in C. It's probably best 
not to use that term here.

Let me see if I understand your issue.

* You have two separate Python processes.

* Each process has a thread which dynamically writes a file called "m1.py", 
containing a class C.

* Each process has a second thread which dynamically writes a file called 
"m2.py", also containing a class C.

* Each thread then imports its file using the common name "M", and tries to 
pickle and unpickle objects of type C.

* And seemingly at random, each thread sometimes picks up its class M.C, but 
sometimes the class M.C from the other thread.

* Not sure if you get any cross-process contamination as well (that is, process 
1 picks up the modules from process 2), but it wouldn't surprise me in the 
least.


My instinct here is to back away in horror *wink*

You have a lot of non-deterministic code here. I'm kinda impressed that it ever 
works at all :-)

1. If you have two processes writing to the same file "m1.py", its a lottery 
which one will end up actually written to disk. It is at least theoretically 
possible that the data actually on the disk could be a hybrid of bits of 
process 1's m1.py and bits of process 2's m1.py.

2. Likewise for the file m2.py.

3. When you go to import the files, it is non-deterministic which file you will 
see, e.g.

- process 1 writes its m1.py
- process 2 writes its m1.py, overriding the previous m1.py
- process 1 goes to import m1.py, but ends up reading the m1.py
  created by process 2

So that's how you could get cross-process contamination.

--
nosy: +steven.daprano
title: Undefined/random behaviour when importing two modules with the same name 
but different source files -> Random behaviour when importing two modules with 
the same name but different source files

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19352] unittest loader barfs on symlinks

[Irit Katriel]

Irit Katriel  added the comment:

> this affects python 2.7 only;

--
nosy: +iritkatriel
resolution:  -> out of date
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44895] refleak test failure in test_exceptions

[Irit Katriel]

Irit Katriel  added the comment:

I created issue44917 for the recursion hang because it seems like it's really 
another bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44917] interpreter hangs on recursion in both body and handler of a try block

[Irit Katriel]

Irit Katriel  added the comment:

Perhaps the interpreter should detect that it is about to raise a RecusionError 
whose context is another RecursionError, and raise a FatalError instead?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44917] interpreter hangs on recursion in both body and handler of a try block

[Irit Katriel]

New submission from Irit Katriel :

This was found while investigating issue44895. It may or may not be the cause 
of that issue.


The script below hangs on a mac (it's an extract from 
test_exceptions.test_recursion_in_except_handler).

---
import sys

count = 0
def main():

  def f():
global count
count += 1
try:
f()
except RecursionError:
f()

  sys.setrecursionlimit(30)

  try:
f()
  except RecursionError:
pass

main()
print(count)
---


When I kill it the traceback shows it alternating between the two recursive 
calls, but not in a regular pattern:


... [snipped a lot]

  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  [Previous line repeated 2 more times]
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above 

[issue41082] Error handling and documentation of Path.home()

[Andrei Kulakov]

Andrei Kulakov  added the comment:

In current dev version (3.11), _PosixFlavor doesn't have gethomedir(), and 
instead os.path.expanduser() is used via _NormalAccessor(). So at least for the 
current dev version, the docs are accurate.

--
nosy: +andrei.avk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44862] [docs] make "Deprecated since version {deprecated}, will be removed in version {removed}" translation available

[Éric Araujo]

Éric Araujo  added the comment:

I checked and the directive was indeed made translatable in #32087

So like Terry said, this should be brought to the attention of the PT 
translation team.  The strings seem to be translated 
(https://github.com/python/python-docs-pt-br/blob/3.10/sphinx.po#L46), so 
there’s something else going on (even in the current 3.10 docs).

--
nosy: +eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44916] Undefined/random behaviour when importing two modules with the same name but different source files

[George]

New submission from George :

Warning: There's a higher probability this is "expected" undefined behaviour or 
not even undefined and I'm just a moron. In addtion, I couldn't actually 
replicate it outside of the specific context it happened. But if it sounds 
plausible and it's something that shouldn't happen I can spend more time trying 
to replicate.

1. In two different python processes I'm "dynamically" creating a module named 
`M` using a file `m1.py` that contains a class `C`. Then I create an object of 
tpye `C` and pickle it. (let's call this object `c1`)
2. In a different thread I do the exact same thing, but the file is `m2.py` 
then I create an object of type `C` and pickle it. (call this one `c2`)
3. Then, in the same thread, I recreate the module named `M` from `m1.py` and 
unpickle `c1`, second I create a module named `M` from `m2.py` (this doesn't 
cause an error) and unpickle `c2`.
4. This (spurprisingly?) seems to basically work fine in most cases. Except for 
one (and I can't find why it's special) where for some reason `c2` starts 
calling the methods from a class that's not it's own. In other words `c1` 
usually maps ot `M.C --> m1.py` and `c2` to `M.C --> m2.py` | But randomly `c2` 
will start looking up methods in `M.C --> m1.py`, or at least that's what stack 
traces & debuggers seem to indicate.

The way I create the module `M` in all cases:

```
with open(`m1.py`, 'wb') as fp:
fp.write(code.encode('utf-8'))
spec = importlib.util.spec_from_file_location('M', fp.name)
temp_module = importlib.util.module_from_spec(spec)
sys.modules['M] = temp_module
spec.loader.exec_module(temp_module)

# Note: Same for the other module but using `m2.py`, the code I use here 
contains a class `C` in both cases
```

This seems, unexpected. I wouldn't expect the recreation to cause a crash, but 
I'd expect it to either override the previous `M` for all existing objects 
instantiated from that module in all cases, or in no cases... currently it 
seems that both modules stay loaded and lookups are made randomly.

--
components: Interpreter Core
messages: 399596
nosy: George3d6
priority: normal
severity: normal
status: open
title: Undefined/random behaviour when importing two modules with the same name 
but different source files
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44915] Python keywords as string keys in TypedDict

[Doug Hoskisson]

New submission from Doug Hoskisson :

I'm running into an issue with the syntax of 
https://www.python.org/dev/peps/pep-0589/

```
class C(TypedDict):
to: int
from: int

SyntaxError: invalid syntax
```

I'm not sure any change needs to be made to the specification.
But the interpreter needs to recognize that `from` is a string key to a 
`TypedDict`, not the keyword `from`.

Or if you don't want to have to recognize `from` as a string instead of a 
keyword, we need a specification that allows us to put keywords as keys in 
`TypedDict`.

I was thinking maybe something like:
```
class C(TypedDict):
"to": int
"from": int
```
as an optional way to write the same thing.

--
messages: 399595
nosy: Doug Hoskisson
priority: normal
severity: normal
status: open
title: Python keywords as string keys in TypedDict
type: behavior
versions: Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44896] AttributeError in ast.unparse

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
keywords: +patch
pull_requests: +26245
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27770

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

[Filipe Laíns]

Change by Filipe Laíns :


--
keywords: +patch
pull_requests: +26244
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27769

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44914] tp_version_tag is not unique when test runs with -R :

[Ken Jin]

New submission from Ken Jin :

tp_version_tag is supposed to be unique for different class objects. Under 
normal circumstances, everything works properly:

def good():
class C:
def __init__(self):  # Just to force `tp_version_tag` to update
pass
cls_id = hex(id(C))
tp_version_tag_before = C.v   # v is tp_version_tag of C, exposed to Python
x = C()   # tp_new requires a _PyType_Lookup for 
`__init__`, updating `tp_version_tag`
tp_version_tag_after = C.v
print(f'C ID: {cls_id}, before: {tp_version_tag_before} after: 
{tp_version_tag_after}')

for _ in range(100):
good()

Result:
C ID: 0x2920c2d58d0, before: 0 after: 115
C ID: 0x2920c2d6170, before: 0 after: 116
C ID: 0x2920c2d65c0, before: 0 after: 117
C ID: 0x2920c8f2800, before: 0 after: 118
C ID: 0x2920c8f7150, before: 0 after: 119
C ID: 0x2920c8f6010, before: 0 after: 120
C ID: 0x2920c8f6460, before: 0 after: 121
C ID: 0x2920c8f3d90, before: 0 after: 122
C ID: 0x2920c8f0e20, before: 0 after: 123
C ID: 0x2920c8f41e0, before: 0 after: 124
C ID: 0x2920c8f4a80, before: 0 after: 125
C ID: 0x2920c8f1270, before: 0 after: 126
C ID: 0x2920c8f16c0, before: 0 after: 127
C ID: 0x2920c8f34f0, before: 0 after: 128
C ID: 0x2920c8f5770, before: 0 after: 129
C ID: 0x2920c8f30a0, before: 0 after: 130
...

However, wrapping in a unittest and run under -R : suddenly changes things:

class BadTest(unittest.TestCase):
def test_bad(self):
class C:
def __init__(self):
pass

cls_id = hex(id(C))
tp_version_tag_before = C.v
x = C()
tp_version_tag_after = C.v
print(f'C ID: {cls_id}, before: {tp_version_tag_before} after: 
{tp_version_tag_after}')

Result:
"python_d.exe" -m test test_bad -R 10:10
C ID: 0x1c4c59354b0, before: 0 after: 78
.C ID: 0x1c4c59372e0, before: 0 after: 82
.C ID: 0x1c4c5934370, before: 0 after: 82
.C ID: 0x1c4c5934370, before: 0 after: 82
.C ID: 0x1c4c5933680, before: 0 after: 82
.C ID: 0x1c4c5938cc0, before: 0 after: 82
.C ID: 0x1c4c59354b0, before: 0 after: 82
.C ID: 0x1c4c5935900, before: 0 after: 82
.C ID: 0x1c4c5933680, before: 0 after: 82
.C ID: 0x1c4c59354b0, before: 0 after: 82
.C ID: 0x1c4c59354b0, before: 0 after: 82
.C ID: 0x1c4c59361a0, before: 0 after: 82
.C ID: 0x1c4c5933680, before: 0 after: 82
.C ID: 0x1c4c5931400, before: 0 after: 82
.C ID: 0x1c4c5938cc0, before: 0 after: 82
.C ID: 0x1c4c5938cc0, before: 0 after: 82
.C ID: 0x1c4c5933680, before: 0 after: 82
.C ID: 0x1c4c5936a40, before: 0 after: 82
.C ID: 0x1c4c5931400, before: 0 after: 82
.C ID: 0x1c4c5935900, before: 0 after: 82

Somehow the class is occasionally occupying the same address, and 
tp_version_tag didn't update properly. tp_version_tag being unique is an 
important invariant required for LOAD_ATTR and LOAD_METHOD specialization. I 
bumped into this problem after LOAD_METHOD specialization kept failing 
magically in test_descr.

I think this is related to issue43636 and issue43452, but I ran out of time to 
bisect after spending a day chasing this down. I'll try to bisect soon.

--
components: Interpreter Core
messages: 399594
nosy: Mark.Shannon, kj, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: tp_version_tag is not unique when test runs with -R :
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44896] AttributeError in ast.unparse

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

I don't think this is really an issue considering some other functionalities 
that consumes AST code (e.g `compile`) will expect it to be annotated with 
location metadata. This is why the `ast` module already comes bundled with a 
utility function called `fix_missing_locations` which in your example would 
work;

> print(ast.unparse(bad))
> print(ast.unparse(ast.fix_missing_locations(bad)))

Though I recall seeing this error once before, and since there also some 
counter examples (e.g ast.increment_lineno) that assume an AST node might lack 
of these attributes even though the nodes declare them makes it worth to fix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40899] Document exceptions raised by importlib.import

[meowmeowcat]

meowmeowcat  added the comment:

So.. maybe changing ``the module cannot be imported`` to ``the module is not 
found``?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44913] segfault in call to embedded PyModule_New

[Madhu]

New submission from Madhu :

Attached zip file has a test case which illustrate the problem:

A python process (`dload.py') loads up a shared library (`libfoo1.so')
and makes a call to a foreign function `foo'. `foo' Initializes Python
and creates makes a call to PyModule_New at which point dload.py
crashes.

If the calling process is not python(`dload.c'), there is no crash

This sort of situation occurs with python-pam.  I'm not sure if this
is a programmer error and would welcome correction

[I'm supplying a zip file because I can't attach multiple files
Steps to repeat
1. compile libfoo1.so according to comment
2. Run ./dload.py
3. Optionally compile and run dload.c

--
components: Extension Modules
files: test-case-embedded-1.zip
messages: 399591
nosy: enometh
priority: normal
severity: normal
status: open
title: segfault in call to embedded PyModule_New
versions: Python 3.9
Added file: https://bugs.python.org/file50217/test-case-embedded-1.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41102] ZipFile.namelist() does not match the actual files in .zip file

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Xiaolong: The file no longer exists on the google drive. How big was the file?

--
nosy: +andrei.avk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44895] refleak test failure in test_exceptions

[Dong-hee Na]

Dong-hee Na  added the comment:

GH-27767 is a tooling patch for extract dump easily.
See cpython-1628938551.dump.gz for msg399588.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44895] refleak test failure in test_exceptions

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +26243
pull_request: https://github.com/python/cpython/pull/27767

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44895] refleak test failure in test_exceptions

[Dong-hee Na]

Dong-hee Na  added the comment:

Here is the dump I extracted.

0:00:00 load avg: 2.89 Run tests sequentially
0:00:00 load avg: 2.89 [1/1] test_exceptions
beginning 6 repetitions
123456
..
test_exceptions leaked [6, 6, 6] references, sum=18
test_exceptions leaked [6, 6, 6] memory blocks, sum=18
test_exceptions failed (reference leak)

== Tests result: FAILURE ==

1 test failed:
test_exceptions

1 re-run test:
test_exceptions

Total duration: 5.7 sec
Tests result: FAILURE

--
Added file: https://bugs.python.org/file50216/cpython-1628938551.dump.gz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44898] Path.read_bytes() failed when path contains chinese character

[Steven D'Aprano]

Steven D'Aprano  added the comment:

You're still not giving a reproducible example. The PyPy people will be 
unable to resolve this unless you give them a reproducable example.

'D:/somepath contains chinese character' is not a path with Chinese 
characters in it. If you refuse to give enough information to debug the 
problem, all that anyone can do is close the issue. You are wasting your 
time, and our time, by giving false information in your bug reports, and 
if you do the same to PyPy, you will be wasting their time too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44898] Path.read_bytes() failed when path contains chinese character

[Terry J. Reedy]

Terry J. Reedy  added the comment:

pypy is a separate group of people and tracker.  cpython 3.7 only gets security 
patches.

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44898] Path.read_bytes() failed when path contains chinese character

[russiavk]

russiavk  added the comment:

Sorry.I found it only happen in pypy3
My os is win10 64,and pypy version is "PyPy 7.3.6-alpha0 with MSC v.1929 64 bit"

  File "C:\Program 
Files\pypy-c-jit-102746-9515a976b2ea-win64\lib-python\3\pathlib.py", line 1229, 
in read_bytes
with self.open(mode='rb') as f:
  File "C:\Program 
Files\pypy-c-jit-102746-9515a976b2ea-win64\lib-python\3\pathlib.py", line 1223, 
in open
opener=self._opener)
  File "C:\Program 
Files\pypy-c-jit-102746-9515a976b2ea-win64\lib-python\3\pathlib.py", line 1078, 
in _opener
return self._accessor.open(self, flags, mode)
FileNotFoundError: [Errno 2] No such file or directory: 
WindowsPath('D:/somepath contains chinese character')

--
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40899] Document exceptions raised by importlib.import

[meowmeowcat]

Change by meowmeowcat :


--
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44912] doc: macOS supports os.fsync(fd)

[Ma Lin]

Ma Lin  added the comment:

Unix includes macOS.

Very sorry, close as invalid.

--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com