On Tue, 19 Apr 2011 14:29:24 +0200, Maciej Fijalkowski 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 places a b
On Tue, 19 Apr 2011 12:01:44 +0200, Stefan Behnel 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 them, or
> would
On Tue, 19 Apr 2011 10:37:41 -0400
"R. David Murray" wrote:
> On Tue, 19 Apr 2011 07:06:09 +0200, Stefan Behnel 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
On Tue, 19 Apr 2011 07:06:09 +0200, Stefan Behnel 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, because
> other impl
>
> 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 pro
On Tue, Apr 19, 2011 at 12:01 PM, Stefan Behnel 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 maintenance, t
On Tue, Apr 19, 2011 at 8:17 AM, Maciej Fijalkowski wrote:
> On Tue, Apr 19, 2011 at 10:57 AM, Nick Coghlan wrote:
>> 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
On Tue, Apr 19, 2011 at 10:57 AM, Nick Coghlan wrote:
> 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
On Tue, Apr 19, 2011 at 1:06 AM, Stefan Behnel 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
> optimisation load in
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 impr
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 improvements and
> optimisations
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 that
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 he
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 testin
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 ma
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
rew
On Mon, 18 Apr 2011 18:34:06 +0200, =?UTF-8?Q?=C3=89ric_Araujo?=
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 talking about.
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 an
On Mon, Apr 18, 2011 at 6:32 PM, Éric Araujo wrote:
> 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 stand
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
http://mail.python.org/
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 understa
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 testing is good.
> >
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:
>
> >> Almost none of the concerns that have been raised has been addressed. Does
> >> the PEP only apply to purely algorit
On 18 April 2011 08:05, Maciej Fijalkowski wrote:
> On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
> 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 or does it
>> apply to anything written
On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
wrote:
>
> On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
>
>
> On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
>>
>> Brett Cannon wrote:
>> > In the grand python-dev tradition of "silence means acceptance", I
>> > consider
>> > this PEP fin
On Sun, 17 Apr 2011 00:30:22 -0700, Raymond Hettinger
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
> >> proposa
On 17 April 2011 06:32, R. David Murray 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 definitely uncomfortab
On Sun, 17 Apr 2011 01:32:15 -0400
"R. David Murray" 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
> saying "comprehensi
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 tha
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 thin
On Sat, 16 Apr 2011 19:19:32 -0700, Raymond Hettinger
wrote:
> On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
>
> >
> >
> > On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
> > Brett Cannon wrote:
> > > In the grand python-dev tradition of "silence means acceptance", I
> > > consider
> > >
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 cov
On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote:
>
>
> On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
> Brett Cannon 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 sai
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 coverage".
Apologies if I merely failed to notice it
On Sat, Apr 16, 2011 at 3:54 PM, Antoine Pitrou 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 like Br
On Sat, 16 Apr 2011 14:45:52 -0700
Brett Cannon wrote:
> On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
>
> > Brett Cannon wrote:
> > > In the grand python-dev tradition of "silence means acceptance", I
> > consider
> > > this PEP finalized and implicitly accepted.
> >
> > I did not really s
On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote:
> Brett Cannon 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/pyt
Brett Cannon 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
http://mail.python.org/pipermail/py
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 wrote:
> Here is the next draft of the PEP. I changed the semantics requirement to
> state that 100% branch coverage is required for
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 m
On Thu, Apr 7, 2011 at 3:15 PM, Stefan Behnel 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 ran slower wh
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
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 impl
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?
On Wed, 06 Apr 2011 18:05:57 -0400, Tres Seaver wrote:
> On 04/06/2011 04:37 PM, Antoine Pitrou wrote:
> > On Wed, 6 Apr 2011 13:22:09 -0700 Brett Cannon wrote:
> >> How about the test suite needs to have 100% test coverage (or as close as
> >> possible) on the pure Python version?
> >
> > Let's
-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 wrote:
>> On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger >> wrote:
>>
>>>
>>> On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
Since people are taki
On Thu, Apr 7, 2011 at 6:22 AM, 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 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 Apr 6, 2011, at 1:22 PM, Brett Cannon wrote:
>
>
> On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger
> 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 "excep
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 mig
On Wed, 6 Apr 2011 13:22:09 -0700
Brett Cannon wrote:
> On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger > 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 "
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
naturall
On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger 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 of a VM prevents [se
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 requ
Brett Cannon 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 only in th
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 t
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 extraordinar
On Tue, Apr 5, 2011 at 05:01, Nick Coghlan wrote:
> On Tue, Apr 5, 2011 at 9:46 AM, Brett Cannon wrote:
> > try:
> > c_heapq.heappop(Spam())
> > except TypeError:
> > # "heap argument must be a list"
> > pass
> >
> > try:
> > py_heapq.heappop(Spam())
>
On Tue, Apr 5, 2011 at 12:57, 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 imp
> 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/issue3
On Apr 6, 2011, at 10:08 AM, Nick Coghlan wrote:
> On Wed, Apr 6, 2011 at 5:57 AM, 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
>> promi
On Thu, Apr 7, 2011 at 1:03 AM, James Y Knight 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 *args
hack w
On Wed, 06 Apr 2011 15:17:05 +0100
Michael Foord 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
> > donated it.
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
s
On Wed, Apr 6, 2011 at 11:59 PM, Antoine Pitrou wrote:
> On Tue, 5 Apr 2011 12:57:13 -0700
> Raymond Hettinger 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 so
On Wed, Apr 6, 2011 at 5:57 AM, 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 impl
On Tue, 5 Apr 2011 12:57:13 -0700
Raymond Hettinger 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 okay to use Py_ListSet
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
[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 prob
On Tue, Apr 5, 2011 at 05:01, Nick Coghlan wrote:
> On Tue, Apr 5, 2011 at 9:46 AM, Brett Cannon wrote:
> > try:
> > c_heapq.heappop(Spam())
> > except TypeError:
> > # "heap argument must be a list"
> > pass
> >
> > try:
> > py_heapq.heappop(Spam())
>
On Tue, Apr 5, 2011 at 01:26, Stefan Behnel 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 code. One is
On Tue, Apr 5, 2011 at 9:46 AM, Brett Cannon 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 attribute
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 that
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
74 matches
Mail list logo
