On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel stefan...@behnel.de wrote:
I think this social problem of the PEP can only be solved if the CPython
project stops doing the major share of the stdlib maintenance, thus freeing
its own developer capacities to focus on CPython related improvements
Nick Coghlan, 19.04.2011 10:57:
On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote:
I think this social problem of the PEP can only be solved if the CPython
project stops doing the major share of the stdlib maintenance, thus freeing
its own developer capacities to focus on CPython related
On Tue, Apr 19, 2011 at 1:06 AM, Stefan Behnel stefan...@behnel.de wrote:
[snip]
This PEP has received a lengthy discussion by now, so here's why I think
it's being fought so heavily by several CPython core developers,
specifically those who have traditionally carried a large part of the
On Tue, Apr 19, 2011 at 10:57 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel stefan...@behnel.de wrote:
I think this social problem of the PEP can only be solved if the CPython
project stops doing the major share of the stdlib maintenance, thus freeing
On Tue, Apr 19, 2011 at 8:17 AM, Maciej Fijalkowski fij...@gmail.com wrote:
On Tue, Apr 19, 2011 at 10:57 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel stefan...@behnel.de wrote:
I think this social problem of the PEP can only be solved if the CPython
On Tue, Apr 19, 2011 at 12:01 PM, Stefan Behnel stefan...@behnel.de wrote:
Nick Coghlan, 19.04.2011 10:57:
On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote:
I think this social problem of the PEP can only be solved if the CPython
project stops doing the major share of the stdlib
Once this move is made/accepted, I would expect the other
implementation to rapidly move away from their custom implementations
of the stdlib and contribute to the shared code base and
documentation. Yes, this places a burden on CPython, but in the long
term in benefits *all* of the projects
On Tue, 19 Apr 2011 07:06:09 +0200, Stefan Behnel stefan...@behnel.de wrote:
That's what makes the PEP feel so unfair to CPython developers, because
they are the ones who carry most of the burden of maintaining the stdlib in
the first place, and who will most likely continue to carry it,
On Tue, 19 Apr 2011 10:37:41 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Tue, 19 Apr 2011 07:06:09 +0200, Stefan Behnel stefan...@behnel.de wrote:
That's what makes the PEP feel so unfair to CPython developers, because
they are the ones who carry most of the burden of maintaining
On Tue, 19 Apr 2011 12:01:44 +0200, Stefan Behnel stefan...@behnel.de wrote:
A related question is: when other Python VM projects try to port a given C
module, would they actually invest the time to write a pure Python version
that may or may not run within acceptable performance bounds for
On Tue, 19 Apr 2011 14:29:24 +0200, Maciej Fijalkowski fij...@gmail.com wrote:
Once this move is made/accepted, I would expect the other
implementation to rapidly move away from their custom implementations
of the stdlib and contribute to the shared code base and
documentation. Yes, this
On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
On Sat, Apr 16, 2011 at 14:23, Stefan Krah ste...@bytereef.org wrote:
Brett Cannon br...@python.org wrote:
In the grand python-dev tradition of silence
On 18 April 2011 08:05, Maciej Fijalkowski fij...@gmail.com wrote:
On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Almost none of the concerns that have been raised has been addressed. Does
the PEP only apply to purely algorithmic modules such as heapq
On Mon, 18 Apr 2011 09:36:20 +0100
Paul Moore p.f.mo...@gmail.com wrote:
On 18 April 2011 08:05, Maciej Fijalkowski fij...@gmail.com wrote:
On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Almost none of the concerns that have been raised has been
On Mon, 18 Apr 2011 09:36:20 +0100, Paul Moore p.f.mo...@gmail.com wrote:
On 18 April 2011 08:05, Maciej Fijalkowski fij...@gmail.com wrote:
On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
The PEP seems to be predicated on a notion that anything
Hi,
We try very hard to optimize for usual python idioms. They're very
often much better than specific cpython hacks. Unless you mean things
like rebiding a global into default a pythonic idiom. We had to
rewrite places in standard library which are precisely not very
pythonic.
If I
Hi,
Perhaps we need a @python_implementation_detail skip decorator?
That’s called test.support.cpython_only (see also
test.support.check_impl_detail). You’re welcome.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
On Apr 18, 2011, at 10:11 AM, Maciej Fijalkowski wrote:
* we usually target CPython version that's already frozen, which is
pretty inconvinient to post this changes back. Example would be a
socket module where it has changed enough in 3.x that 2.7 changes make
no sense.
Do you have any
On Mon, 18 Apr 2011 18:34:06 +0200, =?UTF-8?Q?=C3=89ric_Araujo?=
mer...@netwok.org wrote:
Perhaps we need a @python_implementation_detail skip decorator?
Thatâs called test.support.cpython_only (see also
test.support.check_impl_detail). Youâre welcome.
Nope. That's not what I was
Maciej Fijalkowski, 18.04.2011 19:11:
On Mon, Apr 18, 2011 at 6:32 PM, Éric Araujo wrote:
We try very hard to optimize for usual python idioms. They're very
often much better than specific cpython hacks. Unless you mean things
like rebiding a global into default a pythonic idiom. We had to
Raymond Hettinger, 18.04.2011 19:26:
On Apr 18, 2011, at 10:11 AM, Maciej Fijalkowski wrote:
* we usually target CPython version that's already frozen, which is
pretty inconvinient to post this changes back. Example would be a
socket module where it has changed enough in 3.x that 2.7 changes
R. David Murray, 18.04.2011 14:30:
On Mon, 18 Apr 2011 09:36:20 +0100, Paul Moore wrote:
On 18 April 2011 08:05, Maciej Fijalkowski wrote:
On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger wrote:
The PEP seems to be predicated on a notion that anything written in C is
bad and that all
I just want to say upfront that my personal life has just gotten very hectic
as of late (green card stuff for my wife who is Canadian) and probably will
not let up until June. So if I go a while without replying to points being
made for quite a while, I apologize. Luckily there seem to be others
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
On 4/17/2011 1:32 AM, R. David Murray wrote:
As Brett said, people do come to depend on the details of the
implementation. But IMO the PEP should be clarified to say that the
tests we are talking about should be tests *of the published API*.
That is, blackbox tests, not whitebox tests.
I
In the grand python-dev tradition of silence means acceptance, I consider
this PEP finalized and implicitly accepted.
I haven't seen any responses that said, yes this is a well thought-out
proposal
that will actually benefit any of the various implementations.
In that case it may well
On Sun, 17 Apr 2011 01:32:15 -0400
R. David Murray rdmur...@bitdance.com wrote:
I personally have no problem with the 100% coverage being made a
recommendation in the PEP rather than a requirement. It sounds like
that might be acceptable to Antoine. Actually, I would also be fine with
On 17 April 2011 06:32, R. David Murray rdmur...@bitdance.com wrote:
I don't think the PEP is asking this either (or if it is I agree it
shouldn't be). The way to get full branch coverage (and yes Exarkun is
right, this is about individual branches; see coverage.py --branch)
One thing I'm
On Sun, 17 Apr 2011 00:30:22 -0700, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
In the grand python-dev tradition of silence means acceptance, I
consider
this PEP finalized and implicitly accepted.
I haven't seen any responses that said, yes this is a well thought-out
In the grand python-dev tradition of silence means acceptance, I consider
this PEP finalized and implicitly accepted.
On Tue, Apr 12, 2011 at 15:07, Brett Cannon br...@python.org wrote:
Here is the next draft of the PEP. I changed the semantics requirement to
state that 100% branch coverage is
Brett Cannon br...@python.org wrote:
In the grand python-dev tradition of silence means acceptance, I consider
this PEP finalized and implicitly accepted.
I did not really see an answer to these concerns:
http://mail.python.org/pipermail/python-dev/2011-April/110672.html
On Sat, Apr 16, 2011 at 14:23, Stefan Krah ste...@bytereef.org wrote:
Brett Cannon br...@python.org wrote:
In the grand python-dev tradition of silence means acceptance, I
consider
this PEP finalized and implicitly accepted.
I did not really see an answer to these concerns:
On Sat, 16 Apr 2011 14:45:52 -0700
Brett Cannon br...@python.org wrote:
On Sat, Apr 16, 2011 at 14:23, Stefan Krah ste...@bytereef.org wrote:
Brett Cannon br...@python.org wrote:
In the grand python-dev tradition of silence means acceptance, I
consider
this PEP finalized and
On Sat, Apr 16, 2011 at 3:54 PM, Antoine Pitrou solip...@pitrou.net wrote:
Hmm, what's the difference between the Python stdlib and CPython's
stdlib?
I'm also not sure how you would enforce that anyway. If it means
using ctypes to interface with system C libraries, I'm -10 on it :)
Sounds
On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
On Sat, Apr 16, 2011 at 14:23, Stefan Krah ste...@bytereef.org wrote:
Brett Cannon br...@python.org wrote:
In the grand python-dev tradition of silence means acceptance, I consider
this PEP finalized and implicitly accepted.
I haven't
On 16 Apr, 11:03 pm, st...@pearwood.info wrote:
Brett Cannon wrote:
In the grand python-dev tradition of silence means acceptance, I
consider
this PEP finalized and implicitly accepted.
How long does that silence have to last?
I didn't notice a definition of what counts as 100% branch
On Sat, 16 Apr 2011 19:19:32 -0700, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
On Sat, Apr 16, 2011 at 14:23, Stefan Krah ste...@bytereef.org wrote:
Brett Cannon br...@python.org wrote:
In the grand python-dev tradition of
Here is the next draft of the PEP. I changed the semantics requirement to
state that 100% branch coverage is required for any Python code that is
being replaced by accelerated C code instead of the broad must be
semantically equivalent. Also tweaked wording here and there to make
certain things
On Thu, Apr 7, 2011 at 3:15 PM, Stefan Behnel stefan...@behnel.de wrote:
Assuming there always is an equivalent Python implementation anyway, what
about using that as a fallback for input types that the C implementation
cannot deal with?
Or would it be a larger surprise for users if the code
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
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, 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 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
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
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
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
-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 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
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
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
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 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:
[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
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
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
72 matches
Mail list logo
