[issue27154] Regression in file.writelines behavior
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_AsCharBuffer due to the way the condition is structured, but this bugginess was what allowed it to work correctly with unicode objects. After the commit unicode objects are treated like any other buffer, and that's why internal UCS2 or UCS4 representation gets written to the file. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27154] Regression in file.writelines behavior
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 written instead of the actual text, which also directly contradicts
documentation, which states "This is equivalent to calling write() for each
string". However on Python 2.7.7+ they are no longer equivalent:
>>> open('testfile.bin', 'wb').writelines([u'Hello, world!'])
>>> open('testfile.bin', 'rb').read()
'H\x00e\x00l\x00l\x00o\x00,\x00 \x00w\x00o\x00r\x00l\x00d\x00!\x00'
>>> open('testfile.bin', 'wb').write(u'Hello, world!')
>>> open('testfile.bin', 'rb').read()
'Hello, world!'
This code worked correctly no Python 2.7.6.
--
components: IO
messages: 266605
nosy: snaury
priority: normal
severity: normal
status: open
title: Regression in file.writelines behavior
type: behavior
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27154>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25531] greenlet header file is missing inside virtualenv
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) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25531] greenlet header file is missing inside virtualenv
Alexey Borzenkov added the comment: I have reproduced this problem on Linux with pyvenv, isn't that part of Python 3.5? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25531] greenlet header file is missing inside virtualenv
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 reproduce on Linux too. -- nosy: +snaury ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18580] distutils compilers are unicode strings on OS X since Python 2.7.4
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 instead of a list it's a unicode string. I couldn't reproduce the problem myself, but I traced it to the following: In Lib/distutils/ccompiler.py, method CCompiler.set_executable, type check is only for str. So if set_executable is called with a unicode string is would not be turned into a list. In Lib/_osx_support.py, function _read_output, the output is always decoded as utf-8 (why?). This function is used in _find_build_tool, which in turn is used in _find_appropriate_compiler, but only if it cannot find the compiler on the PATH (not sure when this could happen, when the user doesn't have Command Line Support installed?). Because of this compiler will be configured as a unicode string and this would probably mean no extensions can be built. I this either _osx_support should be fixed to not decode output as utf-8, or set_executable should be fixed to test for basestring instead of str. -- assignee: eric.araujo components: Distutils messages: 193826 nosy: Alexey.Borzenkov, eric.araujo, tarek priority: normal severity: normal status: open title: distutils compilers are unicode strings on OS X since Python 2.7.4 versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18580 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18071] _osx_support compiler_fixup
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 from Python 3, which in Python 2 it shouldn't use
decode('utf-8') on command output.
--
nosy: +Alexey.Borzenkov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18071
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18071] _osx_support compiler_fixup
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 rep...@bugs.python.org http://bugs.python.org/issue18071 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4494] Python 2.6 fails to build with Py_NO_ENABLE_SHARED
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 defined. The attached patch fixes the problem by wrapping dependent parts in if #ifdef Py_ENABLE_SHARED/#endif. -- components: Windows files: python-2.6-static.patch keywords: patch messages: 76778 nosy: snaury severity: normal status: open title: Python 2.6 fails to build with Py_NO_ENABLE_SHARED type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file12203/python-2.6-static.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4494] Python 2.6 fails to build with Py_NO_ENABLE_SHARED
Changes by Alexey Borzenkov [EMAIL PROTECTED]: -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4494 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
