Alexey Borzenkov <[EMAIL PROTECTED]> added the comment:
Martin, I cleared the flag bit because filename was changed in-place, to
mark that filename does not need further processing. This was primarily
compatibility concern, to accommodate for situations where users try to
do such decod
New submission from Alexey Borzenkov <[EMAIL PROTECTED]>:
When building python 2.6 with Py_NO_ENABLE_SHARED compilation fails on
PC/getpathp.c, because it uses PyWin_DLLVersionString and
PyWin_DLLhModule unconditionally, which are implemented in PC/dl_nt.c
only when Py_ENABLE_SHARED is d
Changes by Alexey Borzenkov <[EMAIL PROTECTED]>:
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4494>
___
__
New submission from Alexey Borzenkov:
A user reported getting a TypeError when building greenlet on OS X with Python
2.7.4 built with homebrew. The TypeError happens because we subclass build_ext
so before building extensions we can change compiler's compiler_so. The problem
is that in
Alexey Borzenkov added the comment:
I was unaware of this issue (which homebrew works around incorrectly), and
because of this I created issue 18580. The problem is indeed with unicode
strings which are coming from _read_output in _osx_support. This is probably
because this code was merged
Alexey Borzenkov added the comment:
Also, to reproduce it you have to temporarily move away your /usr/bin/cc and
/usr/bin/clang, which then triggers the affected code path.
--
___
Python tracker
<http://bugs.python.org/issue18
New submission from Alexey Borzenkov:
There's a regression in file.writelines behavior for binary files when writing
unicode strings, which seems to have first appeared in Python 2.7.7. The
problem is that when writing unicode strings the internal representation (UCS2
or UCS4) is wr
Alexey Borzenkov added the comment:
Didn't need to bisect, it's very easy to find the problematic commit, since
writelines doesn't change that often:
https://hg.python.org/releases/2.7.11/rev/db842f730432
The old code was buggy in a sense that it always called PyObject_AsCha
Alexey Borzenkov added the comment:
Just wanted to clarify that greenlet.h is not missing in virtualenv, but
headers seem to be installed in venv/include/site/python3.5, when only
venv/include is considered for includes when building extensions. It is not
specific to OSX and it is trivial to
Alexey Borzenkov added the comment:
I have reproduced this problem on Linux with pyvenv, isn't that part of Python
3.5?
--
___
Python tracker
<http://bugs.python.org/is
Alexey Borzenkov added the comment:
I created a simple gist that can show the problem:
https://gist.github.com/snaury/ea167713b1804ffbaf5a (testme.sh builds Python
3.5, creates a venv, install greenlet and tries to compile an extension
11 matches
Mail list logo
