New submission from Haoyu Bai divine...@gmail.com:
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
New submission from Haoyu Bai divine...@gmail.com:
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
New submission from Haoyu Bai divine...@gmail.com:
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
New submission from Haoyu Bai divine...@gmail.com:
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
New submission from Haoyu Bai divine...@gmail.com:
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
New submission from Haoyu Bai divine...@gmail.com:
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
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
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
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
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
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
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
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
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
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
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 module
sys.exit(refactor.main(lib2to3/fixes))
File /usr/lib/python3.0
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
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 string, line 1, in module
ValueError: recursion limit exceeded
Changes by Haoyu Bai [EMAIL PROTECTED]:
--
nosy: +bhy
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2799
__
___
Python-bugs-list mailing list
Unsubscribe:
http
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
20 matches
Mail list logo
