Change by Christoph Reiter :
--
nosy: -lazka
___
Python tracker
<https://bugs.python.org/issue46541>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/scri
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
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
Christoph Reiter added the comment:
ping. The PR looks good to me.
--
___
Python tracker
<https://bugs.python.org/issue41374>
___
___
Python-bugs-list mailin
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/issue43
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
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 sho
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
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/issue42
Change by Christoph Reiter :
--
nosy: +erik.bray
___
Python tracker
<https://bugs.python.org/issue41374>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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/issu
Change by Christoph Reiter :
--
pull_requests: +17370
pull_request: https://github.com/python/cpython/pull/17961
___
Python tracker
<https://bugs.python.org/issue36
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: cr
Christoph Reiter added the comment:
related: issue28859
--
nosy: +lazka
___
Python tracker
<https://bugs.python.org/issue38948>
___
___
Python-bugs-list mailin
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
Christoph Reiter added the comment:
I've filed issue38883
--
___
Python tracker
<https://bugs.python.org/issue36264>
___
___
Python-bugs-list mailing list
Unsub
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?). W
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 potent
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.
--
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.
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
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 en
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 w
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/issue37
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_
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.
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
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
Change by Christoph Reiter :
--
versions: +Python 3.7 -Python 3.5
___
Python tracker
<https://bugs.python.org/issue28859>
___
___
Python-bugs-list mailin
Change by Christoph Reiter :
--
nosy: -lazka
___
Python tracker
<https://bugs.python.org/issue34597>
___
___
Python-bugs-list mailing list
Unsubscribe:
Christoph Reiter added the comment:
related: issue31359
--
nosy: +lazka
___
Python tracker
<https://bugs.python.org/issue34597>
___
___
Python-bugs-list mailin
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
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 conta
Change by Christoph Reiter <reiter.christ...@gmail.com>:
--
nosy: -lazka
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32268>
___
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
---
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/i
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
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"
>>&
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 Pyt
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
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
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/i
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 obj
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
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
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/i
Changes by Christoph Reiter <reiter.christ...@gmail.com>:
--
resolution: -> wont fix
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
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:\\d
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 <
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>
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
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+.
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
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/i
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
F
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
59 matches
Mail list logo
