-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
#. ``__version_info__`` SHOULD be of the format returned by PEP 386's
``parse_version()`` function.
The only reference to parse_version in PEP 386 I could find was the
setuptools implementation which is pretty odd:
In other words,
On Wed, Apr 6, 2011 at 12:05 AM, Antoine Pitrou solip...@pitrou.net wrote:
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.
On Tue, 5 Apr 2011 12:57:13 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
* I would like to see a restriction on the use of
the concrete C API such that it is *only* used
when a exact type match has been found or created
(i.e. if someone writes Py_ListNew(), then it
is
Le mercredi 06 avril 2011 à 23:55 +1000, Nick Coghlan a écrit :
On Wed, Apr 6, 2011 at 12:05 AM, Antoine Pitrou solip...@pitrou.net wrote:
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
On Wed, Apr 6, 2011 at 5:57 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Wed, Apr 6, 2011 at 11:59 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 5 Apr 2011 12:57:13 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
* I would like to see a restriction on the use of
the concrete C API such that it is *only* used
when a exact type match has
On 05/04/2011 20:57, Raymond Hettinger wrote:
[snip...]
[Brett]
(sorry, Raymond, for picking on heapq, but is
was what bit the PyPy people most recently =).
No worries, it wasn't even my code. Someone
donated it. The was a discusion on python-dev
and collective agreement to allow it to have
On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
With more standardization of versions, should the version module be promoted
to stdlib directly?
When Tarek lands packaging (i.e. what distutils2 becomes in the
Python 3.3 stdlib), the standardised version handling
On Thu, Apr 7, 2011 at 12:01 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le mercredi 06 avril 2011 à 23:55 +1000, Nick Coghlan a écrit :
Since it appears the intermittent failures affecting these platforms
have been dealt with, is it time to switch python-committers email
notifications back
On Wed, 06 Apr 2011 15:17:05 +0100
Michael Foord fuzzy...@voidspace.org.uk wrote:
On 05/04/2011 20:57, Raymond Hettinger wrote:
[snip...]
[Brett]
(sorry, Raymond, for picking on heapq, but is
was what bit the PyPy people most recently =).
No worries, it wasn't even my code. Someone
On Tue, Apr 5, 2011 at 09:05, Antoine Pitrou solip...@pitrou.net wrote:
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.
On Thu, Apr 7, 2011 at 1:03 AM, James Y Knight f...@fuhm.net wrote:
Perhaps the argument handling for C functions ought to be enhanced to work
like python's argument handling, instead of trying to hack it the other way
around?
Oh, definitely. It is just that you pretty much have to use the
On Apr 6, 2011, at 10:08 AM, Nick Coghlan wrote:
On Wed, Apr 6, 2011 at 5:57 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
Le 06/04/2011 03:39, exar...@twistedmatrix.com a écrit :
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
Hello Guys,
I would like to present my proposal for the Google Summer of Code,
concerning the idea of porting the benchmarks to Python 3.x for
speed.pypy.org. I think I have successfully integrated the feedback I
got from prior discussions on the topic and I would like to hear your
opinion.
On Tue, Apr 5, 2011 at 06:10, Jim Jewett jimjjew...@gmail.com wrote:
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
No worries, it wasn't even my code. Someone
donated it. The was a discusion on python-dev
and collective agreement to allow it to have
semantic differences that would let it run faster.
IIRC, the final call was made by Uncle Timmy.
The bug link is here:
http://bugs.python.org/issue3051
On Tue, Apr 5, 2011 at 12:57, Raymond Hettinger raymond.hettin...@gmail.com
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
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:
On Apr 6, 2011, at 10:24 AM, Maciej Fijalkowski wrote:
I saw no need to complicate the pure python code for this.
if you complicate the C code for this, then please as well complicate
python code for this since it's breaking stuff.
Do you really need a PEP for this one extraordinary and
Am 06.04.2011 03:39, schrieb exar...@twistedmatrix.com:
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
On 4/6/2011 1:24 PM, Maciej Fijalkowski wrote:
No worries, it wasn't even my code. Someone
donated it. The was a discusion on python-dev
and collective agreement to allow it to have
semantic differences that would let it run faster.
IIRC, the final call was made by Uncle Timmy.
...
And, for
Brett Cannon br...@python.org wrote:
* We also suffer from inconsistency in choice of
exceptions (i.e. overly large sequence indices
raising either an IndexError, OverflowError, or
ValueError).
Once again, a general issue in our C code and not special to this PEP.
Not
On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
Since people are taking my semantically identical point too strongly for
what I mean (there is a reason I said except in cases
where implementation details of a VM prevents [semantic equivalency]
entirely), how about we change the requirement
On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
Since people are taking my semantically identical point too strongly
for what I mean (there is a reason I said except in cases
where implementation details
James Y Knight, 06.04.2011 17:03:
On Apr 6, 2011, at 10:08 AM, Nick Coghlan wrote:
Argument handling is certainly a tricky one - getting positional only
arguments requires a bit of a hack in pure Python code (accepting
*args and unpacking the arguments manually), but it comes reasonably
On Wed, 6 Apr 2011 13:22:09 -0700
Brett Cannon br...@python.org wrote:
On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
Since people are taking my semantically identical point too strongly
for what I
Brett How about the test suite needs to have 100% test coverage (or as
Brett close as possible) on the pure Python version?
Works for me, but you will have to define what 100% is fairly clearly.
100% of the lines get executed? All the branches are taken? Under what
circumstances might
On Apr 6, 2011, at 1:22 PM, Brett Cannon wrote:
On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
Since people are taking my semantically identical point too strongly for
what I mean (there is a
On Apr 6, 2011, at 1:22 PM, Brett Cannon wrote:
How about the test suite needs to have 100% test coverage (or as close as
possible) on the pure Python version? That will guarantee that the C code
which passes that level of test detail is as semantically equivalent as
possible. It also
Hello,
For the record, I've tried to make the force build form clearer on the
buildbot Web UI. See e.g.:
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%20custom
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Apr 7, 2011 at 6:22 AM, Brett Cannon br...@python.org wrote:
How about the test suite needs to have 100% test coverage (or as close as
possible) on the pure Python version? That will guarantee that the C code
which passes that level of test detail is as semantically equivalent as
On 4/6/2011 7:26 AM, Nick Coghlan wrote:
On Wed, Apr 6, 2011 at 6:22 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
With more standardization of versions, should the version module be promoted
to stdlib directly?
When Tarek lands packaging (i.e. what distutils2 becomes in the
Python 3.3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/06/2011 04:37 PM, Antoine Pitrou wrote:
On Wed, 6 Apr 2011 13:22:09 -0700
Brett Cannon br...@python.org wrote:
On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger raymond.hettin...@gmail.com
wrote:
On Apr 6, 2011, at 10:39 AM, Brett Cannon
On Apr 6, 2011, at 2:40 PM, Antoine Pitrou wrote:
For the record, I've tried to make the force build form clearer on the
buildbot Web UI. See e.g.:
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%20custom
Much improved. Thanks.
Raymond
On Wed, 06 Apr 2011 18:05:57 -0400, Tres Seaver tsea...@palladion.com wrote:
On 04/06/2011 04:37 PM, Antoine Pitrou wrote:
On Wed, 6 Apr 2011 13:22:09 -0700 Brett Cannon br...@python.org wrote:
How about the test suite needs to have 100% test coverage (or as close as
possible) on the pure
On Apr 6, 2011, at 4:44 PM, s...@pobox.com wrote:
Brett How about the test suite needs to have 100% test coverage (or as
Brett close as possible) on the pure Python version?
Works for me, but you will have to define what 100% is fairly clearly.
100% of the lines get executed? All
On 4/6/2011 2:54 PM, Terry Reedy wrote:
I believe that at the time of that decision, the Python [heapq] code was only
intended for humans, like the Python (near) equivalents in the itertools
docs to C-coded itertool functions. Now that we are aiming to have
stdlib Python code be a reference
Is it a good idea to have code highlighting in tracker?
I'd like to gather independent unbiased opinion for a little research
of Python development. Unfortunately, there is no way to create a
poll, but if you just say yes or no without reading all other comments
- that would be fine. Thanks.
--
2011/4/6 anatoly techtonik techto...@gmail.com:
Is it a good idea to have code highlighting in tracker?
Why would we need it?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Thu, Apr 7, 2011 at 7:58 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Perhaps a different technique would be that if packaging is in use, that it
could somehow inject the version from setup.cfg into the module, either by
tweaking the source as it gets packaged, or installed, or tweaking
On Thu, Apr 7, 2011 at 7:40 AM, Antoine Pitrou solip...@pitrou.net wrote:
For the record, I've tried to make the force build form clearer on the
buildbot Web UI. See e.g.:
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%20custom
Looks good - trying it out on my LHS precedence
On Thu, Apr 7, 2011 at 1:37 PM, anatoly techtonik techto...@gmail.com wrote:
Is it a good idea to have code highlighting in tracker?
The tracker doesn't display code. Only the code review tool and the
repository browser display code (and syntax highlighting is useful but
not essential for those
On 4/6/2011 9:08 PM, Nick Coghlan wrote:
On Thu, Apr 7, 2011 at 7:58 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
Perhaps a different technique would be that if packaging is in use, that it
could somehow inject the version from setup.cfg into the module, either by
tweaking the source as it
Brett Cannon, 06.04.2011 19:40:
On Tue, Apr 5, 2011 at 05:01, Nick Coghlan wrote:
However, there actually *is* a significant semantic discrepancy in the
heapq case, which is that py_heapq is duck-typed, while c_heapq is
not:
TypeError: heap argument must be a list
That's true. I will re-word
45 matches
Mail list logo
