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
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
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
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/i
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
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
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 rep...@bugs.python.org
http://bugs.python.org
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
Changes by Alexey Borzenkov [EMAIL PROTECTED]:
--
nosy: +loewis
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4494
___
___
Python-bugs-list mailing
On May 21, 8:12 am, Silver Rock [EMAIL PROTECTED] wrote:
yes, that is the way I a solving the problem. using lists. so it seems
that there is no way around it then..
There's at least one way to do it that I can think of straight away:
selfmodule = __import__(__name__, None, None, (None,))
On Oct 25, 10:00 pm, David S. [EMAIL PROTECTED] wrote:
Does something like operator.getattr exist to perform a chained attr
lookup?
Do you mean something like
class cattrgetter:
def __init__(self, name):
self.names = name.split('.')
def __call__(self, obj):
for name in
After reading PEP-0328 I wanted to give relative imports a try:
# somepkg/__init__.py
empty
# somepkg/test1.py
from __future__ import absolute_import
from . import test2
if __name__ == __main__:
print Test
# somepkg/test2.py
empty
But it complaints:
C:\1\somepkgtest1.py
Traceback (most
[EMAIL PROTECTED] wrote:
Compared to the Python I know and love, Ruby isn't quite the same.
However, it has at least one terrific feature: blocks.
Well, I particularly like how Boo (http://boo.codehaus.org) has done
it:
func(a, b, c) def(p1, p2, p3):
stmts
I was so attached to these
[EMAIL PROTECTED] wrote:
but maybe it reduces code readabilty a bit for people
that have just started to program:
mul2 = def(a, b):
return a * b
Instead of:
def mul2(a, b):
return a * b
For such simple cases, yes. What about:
button.click += def(obj):
# do stuff
You
15 matches
Mail list logo
