[issue9068] "from . import *"
New submission from Haoyu Bai : "from . import *" is valid syntax in CPython (both 2.6 and py3k) but in the language reference it is not allowed: http://docs.python.org/dev/py3k/reference/simple_stmts.html#the-import-statement -- components: Interpreter Core messages: 108507 nosy: bhy priority: normal severity: normal status: open title: "from . import *" type: behavior ___ Python tracker <http://bugs.python.org/issue9068> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6223] Make _PyUnicode_AsString as public API
New submission from Haoyu Bai : Why _PyUnicode_AsString and _PyUnicode_AsStringAndSize are not public API? They are very useful when porting extension module to Python 3, because they have the semantic as same as PyString_AsString. For extension author, these API can be used for replacing PyString_AsString without any other change in code logic. So why not make these API public? Any consideration? If we can document these API, then C extension author can know them and use them, without spending a lot of time to dig them out from Python source code. Thanks! -- assignee: georg.brandl components: Documentation, Extension Modules, Interpreter Core, Unicode messages: 89007 nosy: bhy, georg.brandl severity: normal status: open title: Make _PyUnicode_AsString as public API type: feature request versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6222] 2to3 except fixer failed in certain case
New submission from Haoyu Bai : The 2to3 except fixer will be failed with this code: try: raise TypeError except TypeError, x: pass with this code, 2to3 will produce an empty diff, i.e. it fixes nothing. But when change it to the following, 2to3 works again: try: raise TypeError except TypeError, x: pass with this, 2to3 will provide a correct diff. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 89005 nosy: bhy severity: normal status: open title: 2to3 except fixer failed in certain case versions: Python 2.6, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue6222> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3020] doctest should have lib2to3 integration
Changes by Haoyu Bai : -- nosy: +bhy ___ Python tracker <http://bugs.python.org/issue3020> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6115] Header and doc related to PyNumber_Divide and PyNumber_InPlaceDivide should be removed in py3k
New submission from Haoyu Bai : As function implementation of PyNumber_Divide and PyNumber_InPlaceDivide are already removed, there are still function declaration in abstract.h, and also entries in document: http://docs.python.org/dev/py3k/c-api/number.html?highlight=pynumber_divide I got some symbol undefined problem because of this. Please see the attached patch for fixing either the header and doc. Thank you! -- assignee: georg.brandl components: Documentation, Interpreter Core files: divide.patch keywords: patch messages: 88360 nosy: bhy, georg.brandl severity: normal status: open title: Header and doc related to PyNumber_Divide and PyNumber_InPlaceDivide should be removed in py3k versions: Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14078/divide.patch ___ Python tracker <http://bugs.python.org/issue6115> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5566] Minor error in document of PyLong_AsSsize_t
New submission from Haoyu Bai : In 2.6 and 2.7 development document, PyLong_AsSsize_t is said "New in version 2.5". It is not correct because I checked Python 2.5.4 and there's only _PyLong_AsSsize_t(). You can check it here: http://docs.python.org/dev/c-api/long.html#PyLong_AsSsize_t In 3.0 and 3.1 development document, PyLong_AsSsize_t is appeared twice, there must be one duplicated. Check it here: http://docs.python.org/dev/py3k/c-api/long.html#PyLong_AsSsize_t Thanks! -- assignee: georg.brandl components: Documentation messages: 84178 nosy: bhy, georg.brandl severity: normal status: open title: Minor error in document of PyLong_AsSsize_t versions: Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5517] 2to3 haven't convert buffer object to memoryview
New submission from Haoyu Bai :
The following example is valid in Python 2.6:
a = 'abc'
b = buffer(a)
print([repr(c) for c in b])
After 2to3 it, the 'buffer' isn't changed to memoryview, so then it is
not valid program in Python 3:
Traceback (most recent call last):
File "bufferobj3.py", line 2, in
b = buffer(a)
NameError: name 'buffer' is not defined
However even it changed to memoryview the program still not valid because:
>>> memoryview('a')
Traceback (most recent call last):
File "", line 1, in
TypeError: cannot make memory view because object does not have the
buffer interface
I can reporduce this on both Python 3.0.1 and Python 3.1a1+ (py3k:70310).
Thanks!
--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 83802
nosy: bhy
severity: normal
status: open
title: 2to3 haven't convert buffer object to memoryview
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue5517>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3836] 2to3 broken due to mixed 2.5 and 3.0 syntax
Haoyu Bai <[EMAIL PROTECTED]> added the comment: A patch on main.py to fix this. -- keywords: +patch Added file: http://bugs.python.org/file11464/fix_syntax.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3836] 2to3 broken due to mixed 2.5 and 3.0 syntax
New submission from Haoyu Bai <[EMAIL PROTECTED]>:
In the py3k SVN head(r66389) of lib2to3, the main.py used Python 2.x's
print syntax, and the refactor.py used Python 3.0's exception syntax. So
the 2to3 finally broken on both Python 2.5 and 3.0.
Well, it able to run with Python 2.6, but also have a lot of errors like
this:
Traceback (most recent call last):
File "/usr/bin/2to3", line 6, in
sys.exit(main("lib2to3.fixes"))
File "/home/kid/python-site/lib2to3/main.py", line 71, in main
rt = refactor.RefactoringTool(fixer_names, rt_opts, explicit=explicit)
File "/home/kid/python-site/lib2to3/refactor.py", line 119, in __init__
self.pre_order, self.post_order = self.get_fixers()
File "/home/kid/python-site/lib2to3/refactor.py", line 138, in get_fixers
mod = __import__(fix_mod_path, {}, {}, ["*"])
File "/home/kid/python-site/lib2to3/fixes/fix_dict.py", line 38, in
class FixDict(fixer_base.BaseFix):
File "/home/kid/python-site/lib2to3/fixes/fix_dict.py", line 76, in
FixDict
p1 = patcomp.compile_pattern(P1)
File "/home/kid/python-site/lib2to3/patcomp.py", line 186, in
compile_pattern
return PatternCompiler().compile_pattern(pattern)
File "/home/kid/python-site/lib2to3/patcomp.py", line 57, in
compile_pattern
root = self.driver.parse_tokens(tokens, debug=debug)
File "/home/kid/python-site/lib2to3/pgen2/driver.py", line 45, in
parse_tokens
for quintuple in tokens:
File "/home/kid/python-site/lib2to3/patcomp.py", line 34, in
tokenize_wrapper
tokens = tokenize.generate_tokens(driver.generate_lines(input).__next__)
AttributeError: 'generator' object has no attribute '__next__'
--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 73037
nosy: bhy, collinwinter
severity: normal
status: open
title: 2to3 broken due to mixed 2.5 and 3.0 syntax
type: crash
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3836>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3131] 2to3 can't find fixes_dir
Haoyu Bai <[EMAIL PROTECTED]> added the comment: I tried the patch and it works well. Thanks Georgij! So, why the patch havn't merged into SVN? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3208] function annotation for builtin and C function
Haoyu Bai <[EMAIL PROTECTED]> added the comment: I found the explanation of why buitl-ins are immutable: For the curious: there are two reasons why changing built-in classes is disallowed. First, it would be too easy to break an invariant of a built-in type that is relied upon elsewhere, either by the standard library, or by the run-time code. Second, when Python is embedded in another application that creates multiple Python interpreters, the built-in class objects (being statically allocated data structures) are shared between all interpreters; thus, code running in one interpreter might wreak havoc on another interpreter, which is a no-no. (From http://www.python.org/download/releases/2.2.3/descrintro/) Is the statement still valid for current version of Python? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3208] function annotation for builtin and C function
Haoyu Bai <[EMAIL PROTECTED]> added the comment: As I understand, at least C extension modules, which built as shared library, would be shared among Python interpreter in different process space. Is that correct? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3208] function annotation for builtin and C function
Haoyu Bai <[EMAIL PROTECTED]> added the comment: I think there is reason that CFunctionObjects are immutable: single CFunctionObject is shared by mutiple Python interpreters, so any change of CFunctionObject would affect other Python interpreters. Is that right? If it should be immutable, then we should use something like static array to assign annotations to CFunctionObject, and the value also should be immutable, that means the value couldn't be abitrary PyObject. (by value I mean the value of every __annotations__ dict items.) For SWIG, there's a way to bypass the Python side proxy, eg. for a simple C function, in the shadow module we directly let 'func=_cmod.func', where _cmod is the C DLL module. So the annotation information would be lost if we can't directly assign annotation to C function. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3208] function annotation for builtin and C function
Haoyu Bai <[EMAIL PROTECTED]> added the comment: By considering the implementing, some problems emerged. First of all, as we know, all CFunctionObject and their attributes are imutable, but the __annotations__ attribute should be a dict, and dict is mutable. So how to solve this? Secondly, the annotation value can be abitrary expression, and then, for extension module, would it be reasonable to restrict these value to string? Thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3208] function annotation for builtin and C function
Haoyu Bai <[EMAIL PROTECTED]> added the comment: Sorry I haven't state the issue clearly. For this issue I mean the built-in function should able to define an __annotations__ attribute, just like the __doc__ attribute, but not to access it in extension module. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3208] function annotation for builtin and C function
New submission from Haoyu Bai <[EMAIL PROTECTED]>: It is better if the function annotation(PEP 3107) can be supported by built-in function and C function writtin in extension module, just like the __doc__ attribute. -- messages: 68783 nosy: bhy severity: normal status: open title: function annotation for builtin and C function type: feature request versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3131] 2to3 can't find fixes_dir
New submission from Haoyu Bai <[EMAIL PROTECTED]>:
After install Python 3.0 r64319 on my Linux system, running 2to3 given
the below error:
$ 2to3 hello23.py
Traceback (most recent call last):
File "/usr/bin/2to3", line 5, in
sys.exit(refactor.main("lib2to3/fixes"))
File "/usr/lib/python3.0/lib2to3/refactor.py", line 81, in main
rt = RefactoringTool(fixer_dir, options)
File "/usr/lib/python3.0/lib2to3/refactor.py", line 160, in __init__
self.pre_order, self.post_order = self.get_fixers()
File "/usr/lib/python3.0/lib2to3/refactor.py", line 180, in get_fixers
fix_names = get_all_fix_names(self.fixer_dir)
File "/usr/lib/python3.0/lib2to3/refactor.py", line 95, in
get_all_fix_names
names = os.listdir(fixer_dir)
OSError: [Errno 2] No such file or directory: 'lib2to3/fixes'
--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 68319
nosy: bhy, collinwinter
severity: normal
status: open
title: 2to3 can't find fixes_dir
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3131>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2957] recursion limit exceeded when importing .pyc module
New submission from Haoyu Bai <[EMAIL PROTECTED]>: To reproduce the bug, save the uploaded huge.py, then import the module twice: $ python3 -c 'import huge' $ python3 -c 'import huge' Traceback (most recent call last): File "", line 1, in ValueError: recursion limit exceeded But there's no such problem in Python 2.5.2. -- components: Interpreter Core files: huge.py messages: 67290 nosy: bhy severity: normal status: open title: recursion limit exceeded when importing .pyc module type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file10423/huge.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2957> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2956] 2to3 should have a way to disable some fixers
New submission from Haoyu Bai <[EMAIL PROTECTED]>: Sometime we need to enable all fixers but one or two, eg. the 'import' fixer. So it would be fine if there's a way to do that. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 67289 nosy: bhy, collinwinter severity: normal status: open title: 2to3 should have a way to disable some fixers type: feature request versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2956> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2799] Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
Changes by Haoyu Bai <[EMAIL PROTECTED]>: -- nosy: +bhy __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2799> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2899] Fixes find, rfind, etc in 'string' module
New submission from Haoyu Bai <[EMAIL PROTECTED]>: Functions like find() rfind() index() rindex() has been removed in Python 3.0. So there should be a 2to3 fix for it. Eg. fix if string.find(s, "hello") >= 0: to if str.find(s, "hello") >= 0: Thank you! -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 66993 nosy: bhy, collinwinter severity: normal status: open title: Fixes find, rfind, etc in 'string' module type: feature request versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2899> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
