> 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
_
> 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 red
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
acco
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
en
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
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 vers
On 04/04/2011 23:21, Antoine Pitrou wrote:
On Mon, 04 Apr 2011 23:40:33 +0200
"Martin v. Löwis" 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
lifecy
On Mon, 04 Apr 2011 23:40:33 +0200
"Martin v. Löwis" 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 Microsoft. We ca
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
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
perso
On Mon, Apr 4, 2011 at 12:56 PM, Terry Reedy 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 in theory it is
On 25 March 2011 17:09, Antoine Pitrou wrote:
> On Fri, 25 Mar 2011 17:44:26 +0100
> Éric Araujo wrote:
> > Hi,
> >
> > > changeset: 68921:11dc3f270594
> > > user:Thomas Wouters
> > > date:Fri Mar 25 11:42:37 2011 +0100
> > > summary:
> > > Revert the Lib/test/test_bigmem.py
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 multiple-implemen
On 4/4/2011 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, 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, A
On 4 April 2011 19:07, Glyph Lefkowitz 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
>> 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 ha
In article <20110404191949.07e13...@pitrou.net>,
Antoine Pitrou 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
> the system Pyth
Guido wrote:
> On Mon, Apr 4, 2011 at 10:05 AM, 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 a
On Apr 4, 2011, at 2:00 PM, Guido van Rossum wrote:
> On Mon, Apr 4, 2011 at 10:05 AM, 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!
On Mon, Apr 4, 2011 at 10:05 AM, 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, Michael Foord
wrote
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, 4 Apr 2011 19:11:52 +0200
"Amaury Forgeot d'Arc" wrote:
> 2011/4/4 Eugene Toder :
> > 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 pyt
2011/4/4 Eugene Toder :
> 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 system installed
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
http://mail.python.org/mailm
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 specific.
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
http://mail.python.org/mailman/li
Am 03.04.2011 23:28, schrieb Nadeem Vawda:
> On Sun, Apr 3, 2011 at 8:02 PM, Antoine Pitrou wrote:
>> On Sun, 03 Apr 2011 18:55:33 +0200
>> Éric Araujo wrote:
>>> I think we use Misc/ACKS for code+docs contribution like this one,
>>> Doc/ACKS.txt being used for doc-only changes. This second file
26 matches
Mail list logo
