Am 03.04.2011 23:28, schrieb Nadeem Vawda:
On Sun, Apr 3, 2011 at 8:02 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 03 Apr 2011 18:55:33 +0200
Éric Araujo mer...@netwok.org wrote:
I think we use Misc/ACKS for code+docs contribution like this one,
Doc/ACKS.txt being used for doc-only
As a user of the AST, I as well favor just changing the AST and the
version. IMHO, it is not intended to be stable between Python
releases (similar to bytecode).
Neil
___
Python-Dev mailing list
Python-Dev@python.org
On 4/3/2011 10:02 PM, Guido van Rossum wrote:
Sure, but do we have any indication that the warnings for dis make a difference?
I think there had been a few grumbles about bytecode not being stable.
Without that, it is part of the newish effort to specify in the docs
what is CPython
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
-Frank
___
Python-Dev mailing list
Python-Dev@python.org
2011/4/4 Eugene Toder elto...@gmail.com:
Hello,
CPython source code currently contains a number of python scripts (e.g
Python/makeopcodetargets.py, Objects/typeslots.py, Parser/asdl_c.py)
that are used during the build of the python interpreter itself. For
this reason they are run with
On Mon, 4 Apr 2011 19:11:52 +0200
Amaury Forgeot d'Arc amaur...@gmail.com wrote:
2011/4/4 Eugene Toder elto...@gmail.com:
Hello,
CPython source code currently contains a number of python scripts (e.g
Python/makeopcodetargets.py, Objects/typeslots.py, Parser/asdl_c.py)
that are used
On 04/04/2011 18:05, fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
A lot of tools that work with Python source code use ast - so even
though
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
[and]
On Mon, Apr 4, 2011 at 10:38 AM,
On Apr 4, 2011, at 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py
Guido wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert me!
[and]
On Mon, Apr
In article 20110404191949.07e13...@pitrou.net,
Antoine Pitrou solip...@pitrou.net wrote:
To answer Eugene's question, there's no official policy but the
comment at the top of Python/makeopcodetargets.py can indeed serve as
an useful guideline. I wonder if we still have buildbots with 2.3 as
On 4 April 2011 19:07, Glyph Lefkowitz gl...@twistedmatrix.com wrote:
On Apr 4, 2011, at 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine
On 4/4/2011 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert
Terry wrote:
Are at least some of the implementation methods similar enough that they
could use the same AST? It is, after all, a *semantic* translation into
another
language, and that need not depend on subsequent transforation and
compilation to the ultimate target. A
On 25 March 2011 17:09, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 25 Mar 2011 17:44:26 +0100
Éric Araujo mer...@netwok.org wrote:
Hi,
changeset: 68921:11dc3f270594
user:Thomas Wouters tho...@python.org
date:Fri Mar 25 11:42:37 2011 +0100
summary:
On Mon, Apr 4, 2011 at 12:56 PM, Terry Reedy tjre...@udel.edu wrote:
Moving optimizations from bytecode (where they
are demonstrably a bit fragile) to ast manipulations (where we presume they
will be more robust and can be broader) should be a win in itself
I am still doubtful of that. While
Would it be reasonable to begin supporting Visual Studio 2010 for Windows
builds of 3.3? I now have a personal interest in this happening for some
stuff at work, and there's been a lot of questions in the last few months
about when we'll support it coming from python-list, #python-dev, and in
Am 04.04.2011 22:38, schrieb Brian Curtin:
Would it be reasonable to begin supporting Visual Studio 2010 for
Windows builds of 3.3?
Interesting question. The following concerns have played a role in the
past:
- depending on the timing of the next VS release, Python may actually
want to skip
On Mon, 04 Apr 2011 23:40:33 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
- users have expressed concerns that they constantly need to upgrade
VS releases when developing for Python.
Isn't that kind of a misguided argument? It's not Python who decides the
lifecycle of MSVC releases, it's
On 04/04/2011 23:21, Antoine Pitrou wrote:
On Mon, 04 Apr 2011 23:40:33 +0200
Martin v. Löwismar...@v.loewis.de wrote:
- users have expressed concerns that they constantly need to upgrade
VS releases when developing for Python.
Isn't that kind of a misguided argument? It's not Python who
On 4/4/2011 6:43 PM, Michael Foord wrote:
Won't that still be an issue despite the stable ABI? Extensions on
Windows should be linked to the same version of MSVCRT used to compile
Python - and every time we switch version of Visual Studio it is usually
accompanied by a switch in MSVCRT
On 4/4/2011 4:05 PM, Dino Viehland wrote:
reduce to the core DLR nodes on-demand). We already do a huge amount of
manipulation of those ASTs from optimizations (constant folding being the
primary
one) to re-writing them completely for things like generators or sys.settrace
support and
other
At both the VM and language summits at PyCon this year, the issue of
compatibility of the stdlib amongst the various VMs came up. Two issues came
about in regards to modules that use C code. One is that code that comes in
only as C code sucks for all other VMs that are not CPython since they all
On 05/04/2011 00:12, Scott Dial wrote:
On 4/4/2011 6:43 PM, Michael Foord wrote:
Won't that still be an issue despite the stable ABI? Extensions on
Windows should be linked to the same version of MSVCRT used to compile
Python - and every time we switch version of Visual Studio it is usually
Ok, so it sounds like ast is *not* limited to CPython? That makes it
harder to justify changing it just so as to ease the compilation
process in CPython (as opposed to add new language features).
The changes above are not just for CPython, but to simplify processing
of AST in general, by
To answer Eugene's question, there's no official policy but the
comment at the top of Python/makeopcodetargets.py can indeed serve as
an useful guideline. I wonder if we still have buildbots with 2.3 as
the system Python, by the way.
Ok, I'll use 2.3 as my target. Thanks.
Eugene
26 matches
Mail list logo
