[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: pickle_unpickle.tar.gz messages: 339308 nosy: vadimf priority: normal severity: normal status: open title: unpickling of a datetime object in 3.5 fails when pickled with 2.7 type: crash versions: Python 2.7, Python 3.5 Added file: https://bugs.python.org/file48240/pickle_unpickle.tar.gz ___ Python tracker <https://bugs.python.org/issue36499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to the correct (presumably) one. The results are also affected by commenting out calls to empty method in lines 143 or 227. The use of dis.dis() affects results of the execution as well. More than, the location of error (the triggered assert) shifts in the code, or it is possible that an Exception is raised. The script was tested in Python 2.5.2 in Windows XP SP2 and SP3, 2.6beta2 in Windows XP SP3 and in 2.5.2 Ubuntu 8.0.4 with consistent results. (I mean that behavior of the script is changed by calling of empty methods or irrelevant print statements. The assert shifts.) Sorry for the long script. I failed to further reduce its size because effect disappears. Expected output: ~ 1 1 1 1 1 1 1 1 1 1 1 1 Congratulations: grid solved! 1 2 3 4 5 6 7 8 910 1 B B B B B . B . . B 2 . B . . B B B B . B 3 . . . . . B B . B B 4 . . . B B B B B B . 5 B . B B B . . B B B ~ Received output (example): ~ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Traceback (most recent call last): File "E:\pet projects\nonograms\nonogramsolver10.py", line 244, in g.solve() File "E:\pet projects\nonograms\nonogramsolver10.py", line 230, in solve seq.simplescan() File "E:\pet projects\nonograms\nonogramsolver10.py", line 99, in simplescan assert self.clues, "a seq with no clues" AssertionError: a seq with no clues ~ -- components: Interpreter Core files: nonogramsolver10.py messages: 70658 nosy: bad severity: normal status: open title: a bug in the interpreter? type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file11045/nonogramsolver10.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 order it is going to be, I can be sure it does not depend on changes in other objects. For example, it does not depend on things like if something is printed, or some dummy method called. I have little doubts that the script contains (or might contain) bugs. I am now trying to use 3.0b2, which shows deterministic (in the sense above) behaviour. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 script) are very consistent. 2 Martin v. Löwis: Thank you very much for the excellent explanation. It was exactly what I needed. I did not realize that hash depends on memory location. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue45544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 since basically always, but if the intention is to not make them part of the limited API, a guard around their declarations in the header should be added so that using them at least results in link-time errors instead of compile-time ones when using limited API. -- components: C API messages: 358813 nosy: VZ priority: normal severity: normal status: open title: PyThread_xxx() not available when using limited API type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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) [MSC v.1916 64 bit (AMD64)] so, compiler version is detected as 1916, while get_msvcr() function supports only versions up to '1600'. -- messages: 368242 nosy: Vadim Godunko priority: normal severity: normal status: open title: distutils/cygwinccompiler.py doesn't support recent msvc versions versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue40530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.1.0/lto-wrapper.exe Target: x86_64-w64-mingw32 gcc version 9.1.0 (Rev3, Built by MSYS2 project) Result of make: Python/initconfig.c: In function 'config_get_locale_encoding': Python/initconfig.c:1427:28: error: implicit declaration of function 'nl_langinfo' [-Werror=implicit-function-declaration] 1427 | const char *encoding = nl_langinfo(CODESET); |^~~ Python/initconfig.c:1427:40: error: 'CODESET' undeclared (first use in this function); did you mean 'ECONNRESET'? 1427 | const char *encoding = nl_langinfo(CODESET); |^~~ |ECONNRESET Python/initconfig.c:1427:40: note: each undeclared identifier is reported only once for each function it appears in Python/initconfig.c: In function 'config_init_env_warnoptions': Python/initconfig.c:1992:18: error: too many arguments to function 'wcstok' 1992 | # define WCSTOK wcstok | ^~ Python/initconfig.c:2015:20: note: in expansion of macro 'WCSTOK' 2015 | for (warning = WCSTOK(env, L",", &context); |^~ In file included from ./Include/Python.h:30, from Python/initconfig.c:1: C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:147:20: note: declared here 147 | wchar_t *__cdecl wcstok(wchar_t * __restrict__ _Str,const wchar_t * __restrict__ _Delim) __MINGW_ATTRIB_DEPRECATED_SEC_WARN; |^~ Python/initconfig.c:1992:18: error: too many arguments to function 'wcstok' 1992 | # define WCSTOK wcstok | ^~ Python/initconfig.c:2017:20: note: in expansion of macro 'WCSTOK' 2017 | warning = WCSTOK(NULL, L",", &context)) |^~ In file included from ./Include/Python.h:30, from Python/initconfig.c:1: C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:147:20: note: declared here 147 | wchar_t *__cdecl wcstok(wchar_t * __restrict__ _Str,const wchar_t * __restrict__ _Delim) __MINGW_ATTRIB_DEPRECATED_SEC_WARN; |^~ cc1.exe: some warnings being treated as errors make: *** [Makefile:1703: Python/initconfig.o] Error 1 -- components: Build, Interpreter Core, Windows messages: 349282 nosy: paul.moore, steve.dower, tim.golden, vengelson, zach.ware priority: normal severity: normal status: open title: Compilation on MINGW64 fails (CODESET,wcstok,...) type: compile error versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue37801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue37801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 and waitpid is unblocked by SIGCHLD. However if parent process happens to fork from main thread everything works correctly and process exits immediately without waiting for daemon to sleep for 3600 seconds. I'm wondering what is the difference between main and background thread in parent. Only one thread survives forking in child and becomes main thread in the child, so there should be no differences in the behavior. Thank you in advance for your help, -- components: Build files: threadforkmodel.py messages: 334886 nosy: vtsozik priority: normal severity: normal status: open title: Forking from background thread type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: https://bugs.python.org/file48103/threadforkmodel.py ___ Python tracker <https://bugs.python.org/issue35902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to my question is probably related to the fact that only main thread handles signaling by default in POSIX. But in the provided example parent background thread becomes main in the child. In parent it doesn't matter if waitpid blocks on main or background thread. The only thing really matters if code forks from main or background threads. -- ___ Python tracker <https://bugs.python.org/issue35902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
python3.7 -m 'import zipimport; zipimport.zipimporter("master.zip")'
# zipimport.ZipImportError: not a Zip file: 'master.zip'
unzip master.zip
zip -r master2.zip black-master
python3.7 -m 'import zipimport; zipimport.zipimporter("master2.zip")'
# OK
--
components: Library (Lib)
messages: 342439
nosy: Vadim Kantorov
priority: normal
severity: normal
status: open
title: zipimport does not load ZIP files produced by GitHub
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue36914>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- ___ Python tracker <https://bugs.python.org/issue34213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue29750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue34237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue34284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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) Another part where we recommend to use "sys.flags.__new__()" doesn't make
much sense, so I choose to delete this advice if there is no `__new__` in a
class.
3) This second part also may suggest a wrong class to call `__new__` from:
In [1]: from collections import namedtuple
In [2]: class A(namedtuple('A', 'z')):
...: pass
...:
In [3]: object.__new__(A)
---
TypeError Traceback (most recent call last)
in ()
> 1 object.__new__(A)
TypeError: object.__new__(A) is not safe, use tuple.__new__()
This should be A.__new__(), not tuple.__new__().
--
___
Python tracker
<https://bugs.python.org/issue34284>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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? There is no sys.flags.__new__, tuple.__new__ is called and it has different __new__. > 2. The change in error message for namedtuples (A) isn't related and (B) > isn't correct. `tuple.__new__(NamedTuple)` works, and produces a namedtuple > object, so tuple.__new__ is what the error should point to. I believe you are right about (A), it's not related and should be discussed separately. -- title: Nonsensical exception message when calling `__new__` on non-instaniable object -> Nonsensical exception message when calling `__new__` on some sys objects ___ Python tracker <https://bugs.python.org/issue34284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.
Isn't it the same? Why should we say anything about `tuple` if a user wants A?
This looks similar to 31506:
>>> from collections import namedtuple
>>> class A(namedtuple('x', 'x')):
... pass
...
>>> A.__new__(1, 2)
Traceback (most recent call last):
File "", line 1, in
File "", line 1, in __new__
TypeError: tuple.__new__(X): X is not a type object (int)
--
___
Python tracker
<https://bugs.python.org/issue34284>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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'; this seems to be a precaution so that old extension types don't suddenly become callable (object.__new__ wouldn't insure the invariants that the extension type's own factory function ensures). Heap types, of course, are under our control, so they do inherit tp_new; static extension types that specify some other built-in type as the default also inherit object.__new__. */ So my current solution is to explicitly set __new__ to the common helper function that raises TypeError in that case. --- Thanks a lot for your comments and ideas. In truth, I feel a little overwhelmed and definitely need further guidance for this issue. -- ___ Python tracker <https://bugs.python.org/issue34284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 _curses_panel.panel.__new__() -- ___ Python tracker <https://bugs.python.org/issue34284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 classes.
The reason: the cPickle needs several optional methods (__getstate__,
__getinitargs__) for each object. In their absence an AttributeError is
generated. It is normally suppressed, but suppression itself causes
recursion. The error in exception processing leads to fancy errors.
The proposed solution: temporary (for call of PyErr_ExceptionMatches())
increase recursion limit.
--
files: !!!
messages: 84915
nosy: bad
severity: normal
status: open
title: cPickle error in case of recursion limit
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13527/!!!
___
Python tracker
<http://bugs.python.org/issue5634>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue17153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue17153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 this issue while installing a new version of Google
Protobuf. But here's a simpler repro:
$ python -c 'import json; print json.__file__'
/usr/lib/python2.7/json/__init__.pyc
$ mkdir json; echo "print 'test'" > json/__init__.py
$ python -c 'import json; print json.__file__'
test
json/__init__.py
$ echo "__import__('pkg_resources').declare_namespace(__name__); print 'test'"
> json/__init__.py
$ python -c 'import json; print json.__file__'
test
/usr/lib/python2.7/json/__init__.pyc
For Protobuf, if you build Python bindings from sources, the google/__init__.py
will contain exactly "__import__('pkg_resources').declare_namespace(__name__)"
and it prevents the freshly-built module from being loaded, even if the module
egg is at the first place in sys.path. So an older version gets loaded and it
screws things up.
Ubuntu 14.10, Python 2.7.8
--
components: Extension Modules
messages: 248948
nosy: Vadim Kantorov
priority: normal
severity: normal
status: open
title: Module location load order is not respected if pkg_resources is imported
and a namespace is declared
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue24907>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 authors more appropriate? -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue24907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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)
except ftplib.error_perm as reason:
raise URLError('ftp error: %r' % reason) from reason
finally:
self.ftp.cwd(pwd)
cmd = 'LIST ' + file
else:
cmd = 'LIST'
conn, retrlen = self.ftp.ntransfercmd(cmd)
and near line 2314:
def init(self):
import ftplib
self.busy = 0
self.ftp = ftplib.FTP()
self.ftp.connect(self.host, self.port, self.timeout)
self.ftp.login(self.user, self.passwd)
_target = '/'.join(self.dirs)
self.ftp.cwd(_target)
The fact is, one can download a file from FTP without accessing the listing of
it's parent directory. Example:
ftp://ftp.apnic.net/apnic/whois-data/APNIC/split/apnic.db.inetnum.gz (African
whois db). So these cwd() calls prevent from successfully downloading the file.
If the corresponding blocks are commented out, the file is downloaded OK.
I am not sure how to fix this, rather than totally remove cwd() stuff.
--
components: Library (Lib)
messages: 261498
nosy: Vadim Markovtsev
priority: normal
severity: normal
status: open
title: urllib.request: ftplib's cwd() can do harm
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue26529>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 cover all possible exceptions). I am working on a big framework and demanding from users to call "thread pool shutdown" function before exit would be yet another thing they must remember and just impossible in some cases. It would ruin the whole abstraction. Python is not C, you know. -- nosy: +Vadim Markovtsev ___ Python tracker <http://bugs.python.org/issue14073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
