2009/6/20 Collin Winter :
> Is this intended to include performance changes? Clearly no-one will
> complain if things simply get faster, but I'm thinking about cases
> where, say, a function runs in half the time but uses double the
> memory (or vice versa).
I don't think we can say anything about
gl...@divmod.com wrote:
On 07:06 pm, pyt...@rcn.com wrote:
Not sure why we need yet another pep on the subject. Just update PEP
5 if needed.
I agree. The draft covers the same ground. Two PEPs on the same subject
would be redundant where they agree but would create confusion where
they do
On Thu, Jun 18, 2009 at 7:17 PM, Benjamin Peterson wrote:
[snip]
> Backwards Compatibility Rules
> =
>
> This policy applys to all public APIs. These include the C-API, the standard
> library, and the core language including syntax and operation as defined by
> the
> r
On 19 Jun, 09:08 pm, benja...@python.org wrote:
2009/6/19 :
On 02:09 pm, benja...@python.org wrote:
2009/6/19 �:
�What about side-effects, or exceptional conditions? �What about
interactions with subclasses? (Changing a class in a library from
old-style
to new-style has serious re
On Fri, Jun 19, 2009, Benjamin Peterson wrote:
> 2009/6/19 Aahz :
>> On Fri, Jun 19, 2009, Georg Brandl wrote:
>>>
>>> Yet another rather pointless bikeshed: if this becomes policy, maybe it
>>> should get a PEP number < 100, like PEP 5 or 6.
>>
>> +1 -- I was debating whether to say something.
>
On 07:06 pm, pyt...@rcn.com wrote:
Not sure why we need yet another pep on the subject. Just update PEP 5
if needed.
Hmm. This is a good point; it might make sense to have a more specific
PEP for library compatibility as opposed to language compatibility
though, since language compatibility
2009/6/19 Aahz :
> On Fri, Jun 19, 2009, Georg Brandl wrote:
>>
>> Yet another rather pointless bikeshed: if this becomes policy, maybe it
>> should get a PEP number < 100, like PEP 5 or 6.
>
> +1 -- I was debating whether to say something.
Is that a +1 to numbering or bike shedding?
--
Regards
On Fri, Jun 19, 2009, Georg Brandl wrote:
>
> Yet another rather pointless bikeshed: if this becomes policy, maybe it
> should get a PEP number < 100, like PEP 5 or 6.
+1 -- I was debating whether to say something.
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
2009/6/19 :
> On 02:09 pm, benja...@python.org wrote:
>> 2009/6/19 :
>>> What is "behavior"? Software is composed of behavior. If no behavior
>>> changes, then nothing can ever happen.
>
>> I mean that if you pass X and Y into a function and get Z in 2.6, then
>> you should be able to get Z fro
R. David Murray schrieb:
> On Fri, 19 Jun 2009 at 14:15, Antoine Pitrou wrote:
>
>> Benjamin Peterson python.org> writes:
>>>
>>> I mean that if you pass X and Y into a function and get Z in 2.6, then
>>> you should be able to get Z from passing X and Y in 2.7 even if
>>> there's a new argument t
2009/6/19 Georg Brandl :
> Benjamin Peterson schrieb:
>> Backwards compatibility seems to be an issue that arises a lot here. I
>> think we all have an idea of it is, but we need some hard place to
>> point to. So here's my attempt:
>
> Yet another rather pointless bikeshed: if this becomes policy,
Benjamin Peterson schrieb:
> Backwards compatibility seems to be an issue that arises a lot here. I
> think we all have an idea of it is, but we need some hard place to
> point to. So here's my attempt:
Yet another rather pointless bikeshed: if this becomes policy, maybe it
should get a PEP number
2009/6/19 Raymond Hettinger :
> Not sure why we need yet another pep on the subject. Just update PEP 5 if
> needed.
Hmm. I didn't know about that one.
>
> Also, I think there is a certain amount of wishful thinking here. Ideally,
> we could approve a tiny PEP with just a few bullet points and i
Not sure why we need yet another pep on the subject. Just update PEP 5 if
needed.
Also, I think there is a certain amount of wishful thinking here. Ideally, we could approve a tiny PEP with just a few bullet
points and it would eliminate the need for all of the complicated decision making tha
On 02:09 pm, benja...@python.org wrote:
2009/6/19 :
On 02:17 am, benja...@python.org wrote:
I've taken a stab at this myself in the past while defining a policy
for
Twisted
Yes, that's helpful. Thanks.
Glad you found it useful.
The questions that follow might seem satirical or parodi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
> There is always the possibility that a new feature breaks existing code, for
> example because it relies on a similarly named attribute, or on some obscure
> internal condition. I think this should be qualified so that it only
On Fri, 19 Jun 2009 at 14:15, Antoine Pitrou wrote:
Benjamin Peterson python.org> writes:
I mean that if you pass X and Y into a function and get Z in 2.6, then
you should be able to get Z from passing X and Y in 2.7 even if
there's a new argument that returns Z' if you pass True to it.
Wel
Benjamin Peterson python.org> writes:
>
> I mean that if you pass X and Y into a function and get Z in 2.6, then
> you should be able to get Z from passing X and Y in 2.7 even if
> there's a new argument that returns Z' if you pass True to it.
Well, except if returning Z rather than Z' was a bug
2009/6/19 :
>
> On 02:17 am, benja...@python.org wrote:
>>
>> Backwards compatibility seems to be an issue that arises a lot here. I
>> think we all have an idea of it is, but we need some hard place to
>> point to. So here's my attempt:
>
>> PEP: 387
>> Title: Backwards Compatibility Policy
>
> T
2009/6/19 Antoine Pitrou :
> Benjamin Peterson python.org> writes:
>>
>> This policy applys to all public APIs.
>
> applies?
Yes, thanks.
>
>> * The behavior of an API *must* not change between any two consecutive
>> releases.
>>
>> * A feature cannot be removed without notice between any two con
On 11:13 am, fuzzy...@voidspace.org.uk wrote:
Just to note that Twisted (along with Bazaar) are one of the few 'good
citizens' in the Python community running their tests on Python trunk.
Both projects have caught incompatibilities *before* release of new
versions which is greatly preferable to
On 11:11 am, solip...@pitrou.net wrote:
divmod.com> writes:
This is a false dichotomy; for core developers, the list needs to be
exhaustive. Everything that can change needs to be described as
either
compatible or incompatible.
How do you enumerate "everything that can change"? It does n
Michael Foord voidspace.org.uk> writes:
>
> And this is why expressing a finite list of things we guarantee won't
> change is a virtually impossible task - unless one of you is
> volunteering to write an official spec for Python and its libraries...
Well, we *can* enumerate a list of things t
Benjamin Peterson wrote:
Backwards compatibility seems to be an issue that arises a lot here. I
think we all have an idea of it is, but we need some hard place to
point to. So here's my attempt:
Should this PEP include a note about features which require new syntax,
particularly new keywor
Antoine Pitrou wrote:
divmod.com> writes:
This is a false dichotomy; for core developers, the list needs to be
exhaustive. Everything that can change needs to be described as either
compatible or incompatible.
How do you enumerate "everything that can change"? It does not look like
gl...@divmod.com wrote:
[snip...]
For example, I think it was wrong to change the name of a
test-skipping unittest
method just so that it wouldn't clash with a method created by Twisted
subclassing unittest (besides, self.skip() was much nicer than
self.skipTest()
;-)). Just because some class
divmod.com> writes:
>
> This is a false dichotomy; for core developers, the list needs to be
> exhaustive. Everything that can change needs to be described as either
> compatible or incompatible.
How do you enumerate "everything that can change"? It does not look like a
finite set to me (but
On 09:21 am, solip...@pitrou.net wrote:
divmod.com> writes:
In order for any changes to be possible, there needs to be a clearly
labeled mine-field: don't touch or depend on these things in your
Python
application or it *will* break every time Python is released.
I think the "frozen area"
divmod.com> writes:
>
> In order for any changes to be possible, there needs to be a clearly
> labeled mine-field: don't touch or depend on these things in your Python
> application or it *will* break every time Python is released.
I think the "frozen area" should be defined positively (explic
On 02:17 am, benja...@python.org wrote:
Backwards compatibility seems to be an issue that arises a lot here. I
think we all have an idea of it is, but we need some hard place to
point to. So here's my attempt:
PEP: 387
Title: Backwards Compatibility Policy
Thanks for getting started on this
2009/6/19 Benjamin Peterson :
> Backwards compatibility seems to be an issue that arises a lot here. I
> think we all have an idea of it is, but we need some hard place to
> point to. So here's my attempt:
Nice :-)
A general point - it's probably worth clarifying that you're referring
to major re
Benjamin Peterson python.org> writes:
>
> This policy applys to all public APIs.
applies?
> * The behavior of an API *must* not change between any two consecutive
> releases.
>
> * A feature cannot be removed without notice between any two consecutive
> releases.
By induction, this would me
Backwards compatibility seems to be an issue that arises a lot here. I
think we all have an idea of it is, but we need some hard place to
point to. So here's my attempt:
PEP: 387
Title: Backwards Compatibility Policy
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson
Status: Dra
33 matches
Mail list logo
