[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.
Change by Christoph Reiter : -- nosy: -lazka ___ Python tracker <https://bugs.python.org/issue46541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46751] Windows-style path is not recognized under cygwin
Christoph Reiter added the comment: Afaik Cywin programs only work with native Windows paths if the paths happen to get directly passed to the OS APIs and not interpreted in any way before that. So I don't think this is a bug and expected behavior. Use "cygpath C:/path/to/script.py" to convert the path to the right format first. -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue46751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.
Christoph Reiter added the comment: Sorry if off topic, but I noticed that CPython doesn't deprecate macros in code, while with gcc/clang it's possible to show compiler warnings for them using some pragma magic: $ gcc a.c a.c: In function 'main': a.c:29:13: warning: Deprecated pre-processor symbol 29 | PySomethingDeprecated (0); | ^~ a.c:30:13: warning: Deprecated pre-processor symbol: replace with "SomethingCompletelyDifferent" 30 | PySomethingDeprecated2 (42); | ^~~~ Here is how glib implements this for example: https://gist.github.com/lazka/4749c74249a3918a059d944040aca4a3 Maybe that makes getting rid of them easier in the long run? -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue46541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46645] Portable python3 shebang for Windows, macOS, and Linux
Christoph Reiter added the comment: (MSYS2 maintainer here) If you run a Python script in MSYS2 bash, the shebang gets interpreted by bash, which looks up in PATH (which by default doesn't include the full Windows PATH to avoid conflicts) and if installed leads to the MSYS2 included CPython to be invoked, either the Cygwin based one, or the MinGW fork, depending on the active MSYS2 environment. In short, there is no System CPython involved in any of this. -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue46645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41374] socket.TCP_* no longer available with cygwin 3.1.6+
Christoph Reiter added the comment: ping. The PR looks good to me. -- ___ Python tracker <https://bugs.python.org/issue41374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43195] Same userbase for 32bit and 64bit install on Windows causing conflicts
Christoph Reiter added the comment: Ah, wonderful. We'll do something similar then. Thanks for the info and the pointer to the resolved issue. Much appreciated! -- ___ Python tracker <https://bugs.python.org/issue43195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43195] Same userbase for 32bit and 64bit install on Windows causing conflicts
New submission from Christoph Reiter : I'm sure this is already filed somewhere, but I couldn't find anything. Currently when installing packages with pip using a 64bit Python to --user and then starting a 32bit Python things fail because they look up packages from the same location: .\python.exe -m site --user-base C:\Users\user\AppData\Roaming\Python For example trying to import numpy from a 32bit Python when it was installed with 64bit: >>> import numpy Traceback (most recent call last): File "", line 1, in File "C:\Users\user\AppData\Roaming\Python\Python39\site-packages\numpy\__init__.py", line 143, in from . import _distributor_init File "C:\Users\user\AppData\Roaming\Python\Python39\site-packages\numpy\_distributor_init.py", line 26, in WinDLL(os.path.abspath(filename)) File "C:\Python39-32\lib\ctypes\__init__.py", line 374, in __init__ self._handle = _dlopen(self._name, mode) OSError: [WinError 193] %1 is not a valid Win32 application I guess this isn't a very common problem, but in MSYS2 we are facing this issue because users can easily switch between 32bit/64bit Python. We could patch things, but I'm wondering if there are any plans to fix this in CPython itself so we don't invent our own thing. thanks -- components: Windows messages: 386804 nosy: lazka, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Same userbase for 32bit and 64bit install on Windows causing conflicts versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42577] Unhelpful syntax error when expression spans multiple lines
Christoph Reiter added the comment: I would expect Python to print the current statement up to the error instead of just the last line: ``` File "error.py", line 3-5 print(((123)) if 2: ^ ``` This would solve this case nicely while in the common case still show one line as before. -- ___ Python tracker <https://bugs.python.org/issue42577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42577] Unhelpful syntax error when expression spans multiple lines
New submission from Christoph Reiter : I don't know if the bug tracker is the right place for this, please point me to the right place if not. Someone faced to the following code (simplified example here) and asked for help: ``` if 3: if 1: print(((123)) if 2: print(123) ``` This results in the following error: ``` File "error.py", line 5 if 2: ^ SyntaxError: invalid syntax ``` which is very confusing to users not familiar with generator expressions. I'm wondering if python could improve syntax errors in this case by adding more context, like point to where it started parsing the current thing and where it gave up instead to just the later. -- messages: 382566 nosy: lazka priority: normal severity: normal status: open title: Unhelpful syntax error when expression spans multiple lines versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42522] [C API] Add _Py_Borrow() private function: call Py_XDECREF() and return the object
Christoph Reiter added the comment: I find it confusing that the function is called Py_Borrow() but steals the reference. -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue42522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41374] socket.TCP_* no longer available with cygwin 3.1.6+
Change by Christoph Reiter : -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue41374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41374] socket.TCP_* no longer available with cygwin 3.1.6+
New submission from Christoph Reiter : The TCP macros are provided by netinet/tcp.h, which for some reason is skipped here: https://github.com/python/cpython/blob/592527f3ee59616eca2bd1da771f7c14cee808d5/Modules/socketmodule.h#L11 Until cygwin 3.1.6 these macros were also provided by sys/socket.h, but this got removed in https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=e037192b505b4f233fca9a6deafc9797210f6693 This leads to socket.TCP_NODELAY for example not being available anymore. git blame leads me to https://github.com/python/cpython/commit/b5daaed30d7c54ba1f516289f3a7a30a864133af introducing this special case, which isn't very helpful. I'd suggest to just remove the cygwin check and always include it (which works fine on my machine) Downstream bug report for extra context: https://github.com/msys2/MSYS2-packages/issues/2050 -- components: Build messages: 374126 nosy: lazka priority: normal severity: normal status: open title: socket.TCP_* no longer available with cygwin 3.1.6+ type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36264] os.path.expanduser should not use HOME on windows
Christoph Reiter added the comment: Config on Windows should go into APPDATA not USERPROFILE/HOME, on macOS it should go to "$HOME/Library/Application Support" and on Linux $XDG_CONFIG_HOME or $HOME/.config. So using using HOME on all platforms for config is not what those platforms recommend, though I understand why it's still done this way by many tools. What about supporting a MYFANCYTOOL_CONFIG_DIR env var that the user can override? That's what I do for example. -- ___ Python tracker <https://bugs.python.org/issue36264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38883] Path.home() should ignore HOME env var like os.path.expanduser()
Change by Christoph Reiter : -- keywords: +patch pull_requests: +17369 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17961 ___ Python tracker <https://bugs.python.org/issue38883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36264] os.path.expanduser should not use HOME on windows
Change by Christoph Reiter : -- pull_requests: +17370 pull_request: https://github.com/python/cpython/pull/17961 ___ Python tracker <https://bugs.python.org/issue36264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39137] create_unicode_buffer() gives different results on Windows vs Linux
New submission from Christoph Reiter :
>>> len(ctypes.create_unicode_buffer("\ud800\udc01", 2)[:])
On Windows: 1
On Linux: 2
Using Python 3.8 on both.
--
components: ctypes
messages: 358885
nosy: lazka
priority: normal
severity: normal
status: open
title: create_unicode_buffer() gives different results on Windows vs Linux
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue39137>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38948] os.path.ismount() returns true in python 3.7.4 and false in 2.7.14
Christoph Reiter added the comment: related: issue28859 -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue38948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38883] Path.home() should ignore HOME env var like os.path.expanduser()
New submission from Christoph Reiter : In issue36264 os.path.expanduser() was changed to no longer use the HOME environment variable on Windows. There are two more ways in the stdlib to get the user directory, pathlib.Path.home() and pathlib.Path.expanduser() which internally use gethomedir() which still uses the HOME environment variable: https://github.com/python/cpython/blob/0aca3a3a1e68b4ca2d334ab5255dfc267719096e/Lib/pathlib.py#L255 Since they are documented to work the same as os.path.expanduser() they should be changed to no longer use HOME as well. -- components: Library (Lib) messages: 357196 nosy: lazka priority: normal severity: normal status: open title: Path.home() should ignore HOME env var like os.path.expanduser() versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36264] os.path.expanduser should not use HOME on windows
Christoph Reiter added the comment: I've filed issue38883 -- ___ Python tracker <https://bugs.python.org/issue36264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36264] os.path.expanduser should not use HOME on windows
Christoph Reiter added the comment:
> Was pathlib forgotten here? Pathlib.home() is documented to return
> the same as expanduser("~") but it still prefers HOME instead of
> USERPROFILE.
>
> Yes, it was forgotten (why doesn't it just use expanduser?). We
> should file a new bug for that.
I'll file one.
> > Note that this change has some effect on cygwin/mingw environments
> which all set HOME and now potentially lead to programs no longer
> being able to find their config files.
>
> Firstly these are not supported environments, so it's not "rushed"
> for us to not preemptively consider them (though we'll happily merge
> most PRs that fix them without impacting supported environments).
Yeah, you're right, sorry, my comment wasn't appropriate.
> And I thought the idea was that they'd use posixpath as os.path
> rather than ntpath? Cygwin in particular, which provides the full
> environment. MinGW is a bit lighter to be closer to normal Windows
> behaviour, which would suggest that using the Windows variables is
> preferable.
I meant executing Python scripts with official Python in bash on Windows which
sets HOME. But I just checked with "git for Windows" and it sets HOME to
USERPROFILE anyway, so that might only affect cygwin/msys2 which have their own
user dir.
--
___
Python tracker
<https://bugs.python.org/issue36264>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36264] os.path.expanduser should not use HOME on windows
Christoph Reiter added the comment:
Was pathlib forgotten here? Pathlib.home() is documented to return the same as
expanduser("~") but it still prefers HOME instead of USERPROFILE.
Note that this change has some effect on cygwin/mingw environments which all
set HOME and now potentially lead to programs no longer being able to find
their config files. Not that I disagree with this change, just that it seems a
bit rushed to me.
--
nosy: +lazka
___
Python tracker
<https://bugs.python.org/issue36264>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38667] PYTHONCOERCECLOCALE=0 ignored
Christoph Reiter added the comment: Thanks! I didn't quite see the relation between PEP 538 and PEP 540 after only reading the former. Anyone else finding this: See "Relationship with the locale coercion" in https://www.python.org/dev/peps/pep-0540/ for the details. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38668] Update os.path documentation regarding recommended types
New submission from Christoph Reiter : At the very top of https://docs.python.org/3.9/library/os.path.html there is this section regarding str and bytes: > The path parameters can be passed as either strings, or bytes. They also accept path-like since Python 3.6, see https://www.python.org/dev/peps/pep-0519/ (Adding a file system path protocol). I'd add path-like to the list. > Unfortunately, some file names may not be representable as strings on Unix, > so applications that need to support arbitrary file names on Unix should use > bytes objects to represent path names. This is no longer true since Python 3.1 and https://www.python.org/dev/peps/pep-0383/ (Non-decodable Bytes in System Character Interfaces). I'd suggest to delete this. > Vice versa, using bytes objects cannot represent all file names on Windows > (in the standard mbcs encoding), hence Windows applications should use string > objects to access all files. This is no longer true since Python 3.6 and https://www.python.org/dev/peps/pep-0529/ (Change Windows filesystem encoding to UTF-8). I'd suggest to delete this as well. -- assignee: docs@python components: Documentation messages: 355878 nosy: docs@python, lazka priority: normal severity: normal status: open title: Update os.path documentation regarding recommended types versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38667] PYTHONCOERCECLOCALE=0 ignored
New submission from Christoph Reiter : Python 3.7.5rc1 and 3.8.0 on Ubuntu 19.10 $ LC_CTYPE=C PYTHONCOERCECLOCALE=warn python3 -c "import sys; print(sys.getfilesystemencoding())" Python detected LC_CTYPE=C: LC_CTYPE coerced to C.UTF-8 (set another locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behavior). utf-8 $ LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -c "import sys; print(sys.getfilesystemencoding())" utf-8 The warning states that passing PYTHONCOERCECLOCALE=0 disables the coercion, but it doesn't change anything in 3.7 and 3.8. What am I missing? -- messages: 355868 nosy: lazka priority: normal severity: normal status: open title: PYTHONCOERCECLOCALE=0 ignored versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue38667> ___ ___ 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,...)
Christoph Reiter added the comment: > I wasn't aware that CPython builds for MSYS2 out of the box, since it's a > POSIX-on-Windows platform like Cygwin. Apparently there are patches that > enable it to build, since MSYS2 has Python available. MSYS2 consists of a cygwin like environment and a mingw one. OP is trying to build with mingw. MSYS2 contains a somewhat heavily patched Python in both environments so it's expected that building plain CPython doesn't work. There are plans to upstream smaller non-MSYS2 specific patches but nothing has come of it so far. -- nosy: +lazka ___ 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
[issue37272] pygit2 won't build
Christoph Reiter added the comment: pygit2 requires libgit2 to build which means you need to install the "libgit2-dev" package through apt. See https://docs.travis-ci.com/user/installing-dependencies/ for how to install packages in your travis-ci setup. The reason it works with stable Python versions is that pygit2 provides pre-built wheels on pypi for those: https://pypi.org/project/pygit2/#files -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue37272> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37191] Python.h contains intermingled declarations
Christoph Reiter added the comment: I've removed -Wdeclaration-after-statement in upstream pygobject: https://gitlab.gnome.org/GNOME/pygobject/merge_requests/119 -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue37191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37076] _thread.start_new_thread(): call sys.unraisablehook() to handle uncaught exceptions
Christoph Reiter added the comment: > _thread.start_new_thread() calls none of these hooks, but directly logs the > exception. It calls sys.excepthook() currently: import _thread import threading import sys done = False def hook(*args): global done print(threading.current_thread()) done = True sys.excepthook = hook def worker(): raise Exception _thread.start_new_thread(worker, tuple()) while not done: pass -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue37076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1230540] sys.excepthook doesn't work in threads
Christoph Reiter added the comment: > Let's say that in Python 3.8 threading.Thread now calls sys.execpthook() to > handle uncaught run() exception. All applications which override > sys.excepthook() on purpose will behave differently: start to log exceptions > from threads. But existing code is unlikely to be prepared to implement black > magic to check if we are a "thread" or the main thread, to decide if we > should display a thread name, and also the "black magic" to get the current > thread name. Note that PyErr_Print() and PyErr_PrintEx() can be called in threads, and CPython itself uses it in some places which can be called in threads and I also use it in thread callbacks in C extensions I work on (PyGObject and pycairo for example). Nothing states currently that it's not allowed to call it in such cases :( -- ___ Python tracker <https://bugs.python.org/issue1230540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36689] docs: os.path.commonpath raises ValueError for different drives
New submission from Christoph Reiter :
Since I just got bit by this despite reading the docs:
https://docs.python.org/3.8/library/os.path.html#os.path.commonpath
It lists various error cases where ValueError is raised but is missing the case
where absolute paths on Windows are on different drives and I forgot to handle
that:
File "C:/building/msys64/mingw64/lib/python3.7\ntpath.py", line 631, in
commonpath
raise ValueError("Paths don't have the same drive")
ValueError: Paths don't have the same drive
--
assignee: docs@python
components: Documentation
messages: 340604
nosy: docs@python, lazka
priority: normal
severity: normal
status: open
title: docs: os.path.commonpath raises ValueError for different drives
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue36689>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36539] Distutils VC 6.0 Errors When Using mingw-w64 GCC
Christoph Reiter added the comment: MSYS2 patches setuptools to work with GCC and the MSYS2 Python, so you can't use setuptools as is from pip. See https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python-setuptools for the current set of patches. -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue36539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28859] os.path.ismount sometimes raises FileNotFoundError on Windows
Change by Christoph Reiter : -- versions: +Python 3.7 -Python 3.5 ___ Python tracker <https://bugs.python.org/issue28859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms
Change by Christoph Reiter : -- nosy: -lazka ___ Python tracker <https://bugs.python.org/issue34597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms
Christoph Reiter added the comment: related: issue31359 -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue34597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1230540] sys.excepthook doesn't work in threads
Christoph Reiter added the comment: To add one more use case for this: concurrent.futures.Future.add_done_callback() currently ignores exceptions for the callback and just logs them which is easy to miss. I assume because it's not clear when and in which thread it gets called, and there is no "right" way to handle it. It would be nice if it would call something like sys.excepthook instead. -- nosy: +lazka ___ Python tracker <https://bugs.python.org/issue1230540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33168] distutils build/build_ext and --debug
New submission from Christoph Reiter <reiter.christ...@gmail.com>: The distutils "build" and "build_ext" commands provide a "--debug" option to enable building with debug information. But this option doesn't have any affect because the default CFLAGS contain "-g" (python3-config --cflags) so debug information is always included and "-g0" isn't passed if debug is False. Is this intentional? -- components: Distutils messages: 314593 nosy: dstufft, eric.araujo, lazka priority: normal severity: normal status: open title: distutils build/build_ext and --debug ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33168> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
Change by Christoph Reiter <reiter.christ...@gmail.com>: -- nosy: -lazka ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
Christoph Reiter <reiter.christ...@gmail.com> added the comment: The documentation [0] states: "input and output must be binary file objects" and you are not passing a binary file object. [0] https://docs.python.org/3.6/library/quopri.html#quopri.decode -- nosy: +lazka ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31443] Possibly out of date C extension documentation
Christoph Reiter added the comment: Building the following with gcc from msys2 (cygwin) worked fine here: https://bpaste.net/show/0cafd5fa8211 -- nosy: +lazka ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31047] Windows: os.path.isabs(os.path.abspath(" ")) == False
New submission from Christoph Reiter:
On Windows os.path.abspath(" ") == " "
While that's not a valid Windows path, similar invalid paths like "" or "?" etc
all produce an absolute path.
Tested on 2.7 and 3.6
--
components: Windows
messages: 299253
nosy: lazka, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: os.path.isabs(os.path.abspath(" ")) == False
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31047>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Christoph Reiter added the comment:
Why not just do the following:
>>> from collections import namedtuple
>>> Point = namedtuple('Point', ['x', 'y'])
>>> Point._source
"from collections import namedtuple\nPoint = namedtuple('Point', ['x', 'y'])\n"
>>>
The docs make it seems as if the primary use case of the _source attribute is
to serialize the definition. Returning a source which produces a class with
different performance/memory characteristics goes against that.
--
nosy: +lazka
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28638>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30684] datetime.fromtimestamp raises OSError on first day after epoch on Windows
New submission from Christoph Reiter: I'm not sure this is a bug since the docs says raising OSError is allowed, but it looks weird to me. On Windows. Using Python 3.4: >>> datetime.datetime.fromtimestamp(0) datetime.datetime(1970, 1, 1, 1, 0) Using Python 3.6.1: >>> datetime.datetime.fromtimestamp(0) OSError: [Errno 22] Invalid argument The first time stamp which works with 3.6 is 86400, so exactly the next day. -- messages: 296191 nosy: lazka priority: normal severity: normal status: open title: datetime.fromtimestamp raises OSError on first day after epoch on Windows versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30527] PyMemoryView_FromBuffer memory leak
Christoph Reiter added the comment: In case someone ends up here with a similar problem, here is my solution using a proxy object: https://github.com/pygobject/pycairo/blob/4ab80df68dd99a8e4bfb0c6a88dc5b2a9b0f3f10/cairo/bufferproxy.c -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30527] PyMemoryView_FromBuffer memory leak
Christoph Reiter added the comment: Ah, so if I understand correctly, exposing always requires something implementing the buffer interface in some way. I might require multiple different memoryviews for this object, so maybe some proxy object implementing it might work. Thanks Stefan for your quick help. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30527] PyMemoryView_FromBuffer memory leak
Christoph Reiter added the comment: hm, ok. Any idea how I can create a memoryview that is usable from Python then? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30527] PyMemoryView_FromBuffer memory leak
New submission from Christoph Reiter:
I'm using the following code
PyObject *
get_memoryview (PyObject *self) {
Py_buffer view;
...
// this takes a ref on self
if (PyBuffer_FillInfo (, self, buffer, length, 0, 0) < 0)
return NULL;
// this returns a object
return PyMemoryView_FromBuffer ();
}
The problem is that when I call release() on the returned memory object
the buffer does not get release and as a result the exporter leaks.
Am I missing something or is this a bug?
--
messages: 294851
nosy: lazka
priority: normal
severity: normal
status: open
title: PyMemoryView_FromBuffer memory leak
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30527>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29647] Python 3.6.0
Christoph Reiter added the comment: That sounds like a problem with wxPython which you should report to them: http://trac.wxwidgets.org/ When you do, try to attach a minimal code example with your instructions so others can reproduce the error. -- nosy: +lazka ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29042] os.path.exists should not throw "Embedded NUL character" exception
Christoph Reiter added the comment:
Raising in case no valid path is passed seems fine to me. There are other cases
where it fails:
python3 -c "import os; os.path.exists('\ud83d')"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/genericpath.py", line 19, in exists
os.stat(path)
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud83d' in position
0: surrogates not allowed
LANG=C python3 -c "import os; os.path.exists('\xff')" ~
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/genericpath.py", line 19, in exists
os.stat(path)
UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in position 0:
ordinal not in range(128)
--
nosy: +lazka
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29042>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29039] Segmentation fault when using PyUnicode_FromString
Christoph Reiter added the comment: You're missing a call to Py_Initialize() [0] [0] https://docs.python.org/3/c-api/init.html#c.Py_Initialize -- nosy: +lazka ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27971] utf-16 decoding can't handle lone surrogates
Changes by Christoph Reiter <reiter.christ...@gmail.com>: -- resolution: -> wont fix status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28859] os.path.mount sometimes raises FileNotFoundError on Windows
New submission from Christoph Reiter:
It returns True for drives which don't exist and raises for paths starting with
drives which don't exist.
>>> os.path.exists("C:\\")
True
>>> os.path.ismount("C:\\")
True
>>> os.path.ismount("C:\\doesnotexist")
False
>>> os.path.exists("F:\\")
False
>>> os.path.ismount("F:\\")
True
>>> os.path.ismount("F:\\doesnotexist")
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\lazka\AppData\Local\Programs\Python\Python35\lib\ntpath.py",
line 290, in ismount
return path.rstrip(seps) == _getvolumepathname(path).rstrip(seps)
FileNotFoundError: [WinError 2] The system cannot find the file specified:
'F:\\doesnotexist'
--
components: Windows
messages: 282241
nosy: lazka, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.mount sometimes raises FileNotFoundError on Windows
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28859>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28341] cpython tip fails to build on Mac OS X 10.11.6 w/ XCode 8.0
Christoph Reiter added the comment: Thanks for your response. I'm using MACOSX_DEPLOYMENT_TARGET etc. and it has worked so far building on 10.9/10/11 for running on 10.6. If I find a cause/fix I'll open a new issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28341> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28341] cpython tip fails to build on Mac OS X 10.11.6 w/ XCode 8.0
Christoph Reiter added the comment: I get the same error when building python on osx 10.12 + xcode 8 for 10.9+ and then running it on 10.11. Any idea what could be the problem? -- nosy: +lazka ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28341> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27971] utf-16 decoding can't handle lone surrogates
Christoph Reiter added the comment: Closing as wontfix if there are concerns regarding compatibility seems fine to me. Thanks for looking into this. I've also found a workaround for my usecase in the meantime: https://github.com/lazka/senf/commit/b7dadb05a29db5f0d74f659971b0a86d5e579028 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27971] utf-16 decoding can't handle lone surrogates
Christoph Reiter added the comment: On Tue, Sep 6, 2016 at 4:10 PM, Eryk Sun <rep...@bugs.python.org> wrote: > Lone surrogate codes aren't valid Unicode. In Python 3 they get used > internally for tricks like the "surrogateescape" error handler. In Python > 3.4+. the 'surrogatepass' error handler allows encoding and decoding lone > surrogates: To add some context: I was writing tests for windows paths containing surrogates (e.g. os.listdir can return them) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27971] utf-16 decoding can't handle lone surrogates
Christoph Reiter added the comment: On Tue, Sep 6, 2016 at 3:43 PM, Xiang Zhang <rep...@bugs.python.org> wrote: > > Xiang Zhang added the comment: > > With the latest build, even encode will fail: With Python 3 you have to use the "surrogatepass" error handler. I assumed this was the default in Python 2 since it worked with other codecs. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27971] utf-16 decoding can't handle lone surrogates
Christoph Reiter added the comment: Same problem on 3.3.6. But works on 3.4.5. So I guess this was fixed but not backported. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27971] utf-16 decoding can't handle lone surrogates
New submission from Christoph Reiter:
Using Python 2.7.12
>>> u"\ud83d".encode("utf-16-le")
'=\xd8'
>>> u"\ud83d".encode("utf-16-le").decode("utf-16-le")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/encodings/utf_16_le.py", line 16, in decode
return codecs.utf_16_le_decode(input, errors, True)
UnicodeDecodeError: 'utf16' codec can't decode bytes in position 0-1:
unexpected end of data
>>>
--
components: Unicode
messages: 274546
nosy: ezio.melotti, haypo, lazka
priority: normal
severity: normal
status: open
title: utf-16 decoding can't handle lone surrogates
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27971>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25493] warnings.warn: wrong stacklevel causes import of local file "sys"
Christoph Reiter added the comment: To add some info why we hit that bug: https://bugs.python.org/issue24305 changed the warning stacklevel needed for import warnings from 8 to 2. As a result any code doing import warnings will likely hit that edge case when run with 3.5 and openafs installed. But I'm not sure if there is much code out there doing import warnings.. so ymmv. For anyone with the same problem looking for a workaround: I went through all Python versions and searched for the needed stacklevel. def get_import_stacklevel(import_hook): """Returns the stacklevel value for warnings.warn() for when the warning gets emitted by an imported module, but the warning should point at the code doing the import. Pass import_hook=True if the warning gets generated by an import hook (warn() gets called in load_module(), see PEP302) """ py_version = sys.version_info[:2] if py_version <= (3, 2): # 2.7 included return 4 if import_hook else 2 elif py_version == (3, 3): return 8 if import_hook else 10 elif py_version == (3, 4): return 10 if import_hook else 8 else: # fixed again in 3.5+, see https://bugs.python.org/issue24305 return 4 if import_hook else 2 -- nosy: +lazka ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
