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
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
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
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 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:
>
> 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
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
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
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
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
Greg Ewing wrote:
That's exactly why I think the blocking version should
keep reading until the requested number of bytes is
available (or the buffer is full or EOF occurs).
Do you mean that the blocking version should keep waiting for new bytes
until they show up?
This would not be acceptable,
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
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
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
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
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
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
ACTIVITY SUMMARY (06/12/09 - 06/19/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2239 open (+26) / 15895 closed (+14) / 18134 total (+40)
Open issues with patches: 886
Average
-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 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
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
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
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 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,
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 :
> 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
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 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 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
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.
>
30 matches
Mail list logo
