[issue45544] Close 2to3 issues and list them here

Change by Vadim Pushtaev : -- nosy: +Vadim Pushtaev nosy_count: 7.0 -> 8.0 pull_requests: +27390 pull_request: https://github.com/python/cpython/pull/24244 ___ Python tracker <https://bugs.python.org/issu

[issue40530] distutils/cygwinccompiler.py doesn't support recent msvc versions

New submission from Vadim Godunko : Prebuild Python 3.7 package can't be used with GObjectIntrospection library on Windows due to miss of support of used MSVC compiler by distutils/cygwinccompiler.py module. sys.version returns: 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [

[issue39123] PyThread_xxx() not available when using limited API

New submission from Vadim Zeitlin : These functions (e.g. PyThread_allocate_lock() etc) are not declared inside #if !defined(Py_LIMITED_API) in pythread.h, yet they're not exported from python3.lib. IMHO, ideal would be to just provide these functions in the library, as they exist

[issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...)

Vadim Engelson added the comment: (code from Python-3.8.0b3, but Python-3.7.2 had similar issues) -- ___ Python tracker <https://bugs.python.org/issue37

[issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...)

New submission from Vadim Engelson : Compilation on MINGW64 fails (CODESET,wcstok,...) I am using the latest MINGW64 (http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20190524.exe) Versions: Python-3.7.2, Python-3.8.0b3 $ gcc -v Using built-in specs. COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe

[issue36914] zipimport does not load ZIP files produced by GitHub

New submission from Vadim Kantorov : Python does not like source code zip-files produced by GitHub (zipimporting source from GitHub can be useful in some ad-hoc scripting scenarios e.g. I wanted to use it in Mozilla Iodide context) wget https://github.com/python/black/archive/master.zip

[issue36499] unpickling of a datetime object in 3.5 fails when pickled with 2.7

New submission from Vadim : Unpickling fails when pickling is performed with 2.7 (pickledatetime.py) and unpickling is done with 3.5 (Tested on Ubuntu 16.04) Please see detailed error description and workaround in the comments to the attached files. -- components: Library (Lib) files

[issue35902] Forking from background thread

Vadim Tsozik added the comment: Thank you for your reply. I understand that forking and threads do not mix well if developer is not careful and child doesn't clear/reset synchronization variables inherited from parent. However this is not the case in provided code sample. The answer

[issue35902] Forking from background thread

New submission from Vadim Tsozik : Attached is code sample that forks child process either from main or from background thread. Child starts and joins all of its threads except a sleeping daemon. If parent forks child from main thread program exits immediately after child threads are joined

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Vadim Pushtaev added the comment: Also for `curses.panel.panel`: >>> from curses.panel import panel >>> panel.__new__(panel) Traceback (most recent call last): File "", line 1, in TypeError: object.__new__(_curses_panel.panel) is not safe, use

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Vadim Pushtaev added the comment: Usually, tp_new==NULL means that __new__ is inherited, but not always. Here is the comment from typeobject.c: /* The condition below could use some explanation. It appears that tp_new is not inherited for static types whose base class is 'object&#

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Vadim Pushtaev added the comment: Sorry for the delay, I'm still working on a new PR. -- ___ Python tracker <https://bugs.python.org/issue34284> ___ ___

[issue34284] Nonsensical exception message when calling `__new__` on non-instaniable objects

Vadim Pushtaev added the comment: > See also issue31506 Okay, I admit, reporting `tuple.__new__` instead of `sys.flags` is misleading. But what about this? > `tuple.__new__(NamedTuple)` works, and produces a namedtuple object, so > tuple.__new__ is what the error should point to.

[issue34284] Nonsensical exception message when calling `__new__` on some sys objects

Vadim Pushtaev added the comment: > 1. In this case, this will produce the error "tuple.__new__(sys.flags) is not > safe". But I didn't call "tuple.__new__", I called sys.flags.__new__, and > type(X).__new__(type(X)) should always be safe Should it? Th

[issue34284] Nonsensical exception message when calling `__new__` on some sys objects

Change by Vadim Pushtaev : -- keywords: +patch pull_requests: +8083 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34284> ___ ___ Py

[issue34284] Nonsensical exception message when calling `__new__` on some sys objects

Vadim Pushtaev added the comment: Here is what I learned: 1) Nothing is wrong with that "tuple.__new__(sys.flags) is not safe" part. `__new__` is deleted from `type(sys.flags)`, so parent's `__new__` is called. `tuple` is indeed a base class for `type(sys.flags)`. 2) Anothe

[issue34284] Nonsensical exception message when calling `__new__` on some sys objects

Vadim Pushtaev added the comment: I'm trying to do something about this. Let me know if you have some ideas. -- nosy: +Vadim Pushtaev ___ Python tracker <https://bugs.python.org/is

[issue34237] faq/design: PEP 572 adds assignment expressions

Vadim Pushtaev added the comment: Okay then. -- ___ Python tracker <https://bugs.python.org/issue34237> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34237] faq/design: PEP 572 adds assignment expressions

Vadim Pushtaev added the comment: This indeed doesn't make much sense now. I'll try to send a PR today. -- nosy: +Vadim Pushtaev ___ Python tracker <https://bugs.python.o

[issue29750] smtplib doesn't handle unicode passwords

Vadim Pushtaev added the comment: That's OK, you can do it. -- ___ Python tracker <https://bugs.python.org/issue29750> ___ ___ Python-bugs-list m

[issue29750] smtplib doesn't handle unicode passwords

Vadim Pushtaev added the comment: Hello. I would like to work on this, should the issue be assigned on me or this comment is enough? -- nosy: +Vadim Pushtaev ___ Python tracker <https://bugs.python.org/issue29

[issue34213] Frozen dataclass __init__ fails for "object" property"

Vadim Pushtaev added the comment: Hello. This is my solution for this problem - https://github.com/python/cpython/pull/8452 Sorry if I'm not supposed to do anything about the already assigned issue, feel free to ignore my PR. -- ___ P

[issue34213] Frozen dataclass __init__ fails for "object" property"

Change by Vadim Pushtaev : -- nosy: +Vadim Pushtaev ___ Python tracker <https://bugs.python.org/issue34213> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32299] unittest.mock.patch.dict.__enter__ should return the dict

Change by Vadim Tsander : -- keywords: +patch pull_requests: +4726 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32299> ___ ___ Py

[issue17153] tarfile extract fails when Unicode in pathname

Vadim Markovtsev added the comment: Relevant issue in pip: https://github.com/pypa/setuptools/issues/710 -- ___ Python tracker <http://bugs.python.org/issue17

[issue17153] tarfile extract fails when Unicode in pathname

Vadim Markovtsev added the comment: So... The bug persists in 3.5 ad 3.6. It prevents from e.g. unpacking tarballs coming from GitHub repos with Unicode file names. -- nosy: +Vadim Markovtsev2 ___ Python tracker <http://bugs.python.org/issue17

[issue26529] urllib.request: ftplib's cwd() can do harm

Changes by Vadim Markovtsev : -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue26529> ___ ___ Python-bugs-

[issue26529] urllib.request: ftplib's cwd() can do harm

New submission from Vadim Markovtsev: urllib/request.py, near line 2345 # Set transfer mode to ASCII! self.ftp.voidcmd('TYPE A') # Try a directory listing. Verify that directory exists. if file: pwd = self.ftp.pwd() try: try: self.ftp.cwd(file)

[issue24907] Module location load order is not respected if pkg_resources is imported and a namespace is declared

Vadim Kantorov added the comment: >From my (novice) standpoint, it's very weird that importing pkg_resources in a >module's __init__.py causes Python to deviate from its core module import >rules / sequence. Would you consider reporting this issue to pkg_resources's a

[issue24907] Module location load order is not respected if pkg_resources is imported and a namespace is declared

New submission from Vadim Kantorov: If module's __init__.py contains "__import__('pkg_resources').declare_namespace(__name__)", the module is not loaded, even though it's located in the current directory and should mask other modules. Originally I stumbled upon

[issue23720] __del__() order is broken since 3.4.0

Vadim Markovtsev added the comment: +1 -- nosy: +Vadim Markovtsev ___ Python tracker <http://bugs.python.org/issue23720> ___ ___ Python-bugs-list mailin

[issue14073] allow per-thread atexit()

Vadim Markovtsev added the comment: I agree that there must be some way to join the threads before exiting, with a callback or anything else. Currently, my thread pool implementation has to monkey patch sys.exit and register SIGINT handler to shutdown itself and avoid the hangup (100+ LoC to

[issue11397] os.path.realpath() may produce incorrect results

Changes by Vadim Fint : -- nosy: +Vadim.Fint ___ Python tracker <http://bugs.python.org/issue11397> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5634] cPickle error in case of recursion limit

New submission from vadim suvorov : In case of heavily recursive data structure cPickle produces intermittent random exceptions (AttributeError, etc.). The expected is RuntimeError: ('maximum recursion depth exceeded in ...'). In addition, the behavior differs for classic/new cla

[issue3497] a bug in the interpreter?

vadim suvorov <[EMAIL PROTECTED]> added the comment: Tim, Martin, thank you very much. I think now it is not an issue, and the record can be closed. Thank you very much again, and please accept my apology. 2 Guilherme Polo: I ran it many times. The results in WinXP (with constant scrip

[issue3497] a bug in the interpreter?

vadim suvorov <[EMAIL PROTECTED]> added the comment: Thank you very much, Tim. I am still very much confused, how change in print statement changes order in which items are removed from a set. I presumed it to be undefined but deterministic (similar to dict()): while I cannot tell which

[issue3497] a bug in the interpreter?

Changes by vadim suvorov <[EMAIL PROTECTED]>: -- versions: +Python 2.4 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ __

[issue3497] a bug in the interpreter?

vadim suvorov <[EMAIL PROTECTED]> added the comment: tested Python 2.4.4 on WinXP SP3. It required minor modifications of the code (removing conditional expressions), but the effect stayed. ___ Python tracker <[EMAIL PROTECTED]> <http://

[issue3497] a bug in the interpreter?

Changes by vadim suvorov <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11046/nonogramsolver09.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3497] a bug in the interpreter?

New submission from vadim suvorov <[EMAIL PROTECTED]>: The result of the attached script execution is extremely unstable. The change in the print statement in line 146 from 'print "1"' to 'print 1' (string literal to numerical) changes the result of execution