Brett Cannon, 05.04.2011 01:46:
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
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).
I propose a different view: the AST *is* implementation specific,
although implementations are
Add py.test as an application that uses the AST to support Jython,
PyPy and CPython in a portable way. I always assumed AST was created
*because* bytecode was too CPython specific (but then I've never
implemented a language).
Historically, that's incorrect. The AST structure was introduced
Am 05.04.2011 00:21, schrieb Antoine Pitrou:
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
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
Not if they use the stable ABI. There still might be issues if you
mix CRTs, but none related to the Python ABI - in particular, none
of those
I don't think that the following change conforms to the PEP 399: there
is only a test for the C version.
Victor
Le mardi 05 avril 2011 à 11:34 +0200, raymond.hettinger a écrit :
http://hg.python.org/cpython/rev/a03fb2fc3ed8
changeset: 69150:a03fb2fc3ed8
user:Raymond Hettinger
On Tue, Apr 5, 2011 at 9:46 AM, Brett Cannon br...@python.org wrote:
try:
c_heapq.heappop(Spam())
except TypeError:
# heap argument must be a list
pass
try:
py_heapq.heappop(Spam())
except AttributeError:
# 'Foo' object has no
On 09:55 am, mar...@v.loewis.de wrote:
Am 05.04.2011 00:21, schrieb Antoine Pitrou:
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
On 09:58 am, mar...@v.loewis.de 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
Not if they use the stable ABI. There still might be issues if you
mix CRTs, but none related to the Python
On Tue, Apr 5, 2011 at 07:48, exar...@twistedmatrix.com wrote:
On 09:55 am, mar...@v.loewis.de wrote:
Am 05.04.2011 00:21, schrieb Antoine Pitrou:
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
On 4/4/11, brett.cannon python-check...@python.org wrote:
Draft of PEP 399: Pure Python/C Accelerator Module Compatibiilty
Requirements
+Abstract
+
+
+The Python standard library under CPython contains various instances
+of modules implemented in both pure Python and C. This PEP
On Tue, Apr 5, 2011 at 7:49 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Historically, that's incorrect. The AST structure was introduced to
simplify the implementation of (C)Python. Exposing it to Python modules
was done primarily because it's neat and was easy to do - not because
any
Hello,
For the record, we have 9 stable buildbots, one of which is currently
offline: 3 Windows, 2 OS X, 3 Linux and 1 Solaris.
Paul Moore's XP buildbot is back in the stable stable.
(http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable)
We also have a new 64-bit FreeBSD 8.2
On Tue, Apr 5, 2011 at 01:26, Stefan Behnel stefan...@behnel.de wrote:
Brett Cannon, 05.04.2011 01:46:
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
On Tue, Apr 5, 2011 at 05:01, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Apr 5, 2011 at 9:46 AM, Brett Cannon br...@python.org wrote:
try:
c_heapq.heappop(Spam())
except TypeError:
# heap argument must be a list
pass
try:
I just checked in PEP 396, Module Version Numbers. This is an informational
PEP describing how to specify version numbers using the __version__
attribute. This has already made one round through distutils-sig so it's time
to post it here. Comments welcome of course!
Cheers,
-Barry
P.S. Yeah,
On Apr 5, 2011, at 8:52 AM, exar...@twistedmatrix.com wrote:
On 09:58 am, mar...@v.loewis.de 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
Not if they use the stable ABI. There still
[Brett]
This PEP requires that in these instances that both
the Python and C code must be semantically identical
Are you talking about the guaranteed semantics
promised by the docs or are you talking about
every possible implementation detail?
ISTM that even with pure python code, we get
http://www.python.org/dev/peps/pep-0384/ says functions expecting
FILE* are not part of the ABI, to avoid depending on a specific
version of the Microsoft C runtime DLL on Windows. Can extension
modules that need to read and write files practically avoid all of
those functions?
Certainly!
Does this mean new versions of distutils let you build_ext with any C
compiler, instead of enforcing the same compiler as it has done
previously?
No, it doesn't. distutils was considered frozen, and changes to it to
better support the ABI where rejected.
Regards,
Martin
On 4/5/2011 11:52 AM, Barry Warsaw wrote:
#. Module version numbers SHOULD conform to the normalized version
format specified in PEP 386 [6]_.
From PEP 386:
Roadmap http://www.python.org/dev/peps/pep-0386/#id21
Distutils will deprecate its existing versions class in favor of
Martin v. Löwis wrote:
Not if they use the stable ABI. There still might be issues if you
mix CRTs, but none related to the Python ABI - in particular, none
of those crashing conditions can arise from the stable ABI.
Won't there still be a problem of your extension module
being linked with a
Nick Coghlan wrote:
1. Making docstring an attribute of the Function node rather than
leaving it embedded as the first statement in the suite (this avoids
issues where AST-based constant folding could potentially corrupt the
docstring)
2. Collapsing Num, Str, Bytes, Ellipsis into a single
Am 05.04.2011 22:43, schrieb Greg Ewing:
Martin v. Löwis wrote:
Not if they use the stable ABI. There still might be issues if you
mix CRTs, but none related to the Python ABI - in particular, none
of those crashing conditions can arise from the stable ABI.
Won't there still be a problem of
On Apr 02, 2011, at 10:55 AM, Stefan Krah wrote:
In this case, it's clearly Ubuntu who is going to break things. Still,
the proposed patch could make life a lot easier for many people.
I'd be more concerned about adding some Debian/Ubuntu special code to setup.py
if it wasn't already a rats nest
On 5 Apr, 07:58 pm, mar...@v.loewis.de wrote:
Does this mean new versions of distutils let you build_ext with any C
compiler, instead of enforcing the same compiler as it has done
previously?
No, it doesn't. distutils was considered frozen, and changes to it to
better support the ABI where
On 4/5/2011 3:57 PM, Raymond Hettinger wrote:
[Brett]
This PEP requires that in these instances that both
the Python and C code must be semantically identical
Are you talking about the guaranteed semantics
promised by the docs or are you talking about
every possible implementation detail?
I
27 matches
Mail list logo
