Re: [Python-Dev] Guidance regarding what counts as breaking backwards compatibility
On 2 February 2014 02:11, Terry Reedy wrote:
>> example, sum({1: 100, 2: 200}) returns 3. If one wanted to reserve the
>> opportunity to handle mappings specifically in the future, without being
>> locked in by backwards-compatibility, how should one handle it?
>>
>> a) document that behaviour with mappings is unsupported and may
>> change in the future;
>
>
> I think the doc should in any case specify the proper domain. In this case,
> I think it should exclude mappings: 'non-empty non-mapping iterable of
> numbers', or 'an iterable of numbers that is neither empty nor a mapping'.
> That makes the behavior at best undefined and subject to change. There
> should also be a caveat about mixing types, especially Decimals, if not one
> already. Perhaps rewrite the above as 'an iterable that is neither empty nor
> a mapping of numbers that are mutually summable'.
Generally, my view would be that users should not rely on undocumented
behaviour. But as documentation is sometimes less than 100% precise,
it's worth in a case like this, documenting that a particular
behaviour is not defined (yet). Then, picking and implementing the
desired behaviour will be a new feature and hence totally acceptable.
Changing the way mappings are treated in a bugfix release (as opposed
to a feature release) is unlikely to be acceptable no matter how you
do it, as there's no way you can reasonably deliberately implement one
behaviour now and claim it's a bug later :-)
Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: whatsnew: move of reload, update new windows-only ssl functions entry.
On Sat, 01 Feb 2014 13:20:48 -0500, Brett Cannon wrote: > On Sat, Feb 1, 2014 at 12:27 PM, r.david.murray > wrote: > > > http://hg.python.org/cpython/rev/b3f034f5000f > > changeset: 4:b3f034f5000f > > parent: 2:19d81cc213d7 > > user:R David Murray > > date:Sat Feb 01 12:27:07 2014 -0500 > > summary: > > whatsnew: move of reload, update new windows-only ssl functions entry. > > > > files: > > Doc/whatsnew/3.4.rst | 10 -- > > 1 files changed, 8 insertions(+), 2 deletions(-) > > > > > > diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst > > --- a/Doc/whatsnew/3.4.rst > > +++ b/Doc/whatsnew/3.4.rst > > @@ -765,6 +765,10 @@ > > it will normally be desirable to override the default implementation > > for performance reasons. (Contributed by Brett Cannon in :issue:`18072`.) > > > > +The :func:`~importlib.reload` function has been moved from :mod:`imp` > > +to :mod:`importlib`. The :func:`mod.reload` name is retained for > > +backward compatibility, but is deprecated. > > + > > > > That wording seems confusing to me. It makes it seem like importlib.reload > is deprecated when in fact it's the imp module itself. I committed that thinking I'd finished working on that entry, but I hadn't. The updated text reads: The reload() function has been moved from imp to importlib as part of the imp module deprecation. Is that clearer? --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: whatsnew: move of reload, update new windows-only ssl functions entry.
On Feb 2, 2014 1:08 PM, "R. David Murray" wrote: > > On Sat, 01 Feb 2014 13:20:48 -0500, Brett Cannon wrote: > > On Sat, Feb 1, 2014 at 12:27 PM, r.david.murray > > wrote: > > > > > http://hg.python.org/cpython/rev/b3f034f5000f > > > changeset: 4:b3f034f5000f > > > parent: 2:19d81cc213d7 > > > user:R David Murray > > > date:Sat Feb 01 12:27:07 2014 -0500 > > > summary: > > > whatsnew: move of reload, update new windows-only ssl functions entry. > > > > > > files: > > > Doc/whatsnew/3.4.rst | 10 -- > > > 1 files changed, 8 insertions(+), 2 deletions(-) > > > > > > > > > diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst > > > --- a/Doc/whatsnew/3.4.rst > > > +++ b/Doc/whatsnew/3.4.rst > > > @@ -765,6 +765,10 @@ > > > it will normally be desirable to override the default implementation > > > for performance reasons. (Contributed by Brett Cannon in :issue:`18072`.) > > > > > > +The :func:`~importlib.reload` function has been moved from :mod:`imp` > > > +to :mod:`importlib`. The :func:`mod.reload` name is retained for > > > +backward compatibility, but is deprecated. > > > + > > > > > > > That wording seems confusing to me. It makes it seem like importlib.reload > > is deprecated when in fact it's the imp module itself. > > I committed that thinking I'd finished working on that entry, but I > hadn't. The updated text reads: > > The reload() function has been moved from imp to importlib as part > of the imp module deprecation. > > Is that clearer? Yep! And thanks for catching the missing entry. -Brett > > --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] News from asyncio
Latest asyncio update: it has a new asyncio.subprocess submodule which provides a high-level API to control subprocesses, similar to subprocess.Popen but using asyncio event loop (and so is asynchronous). It solves the following old and tricky issue: http://bugs.python.org/issue12187 "subprocess.wait() with a timeout uses polling on POSIX" "yield from asyncio.wait_for(proc.wait(), timeout)" is no more a busy loop ;-) Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] News from asyncio
On 27Jan2014 09:15, Devin Jeanpierre wrote: > On Mon, Jan 27, 2014 at 5:21 AM, Victor Stinner > wrote: > > - asyncio.IncompleReadError.expected is the total expected size, not > > the remaining size > > Why not be consistent with the meaning of > http.client.IncompleteRead.expected? The current meaning can be > recovered via len(e.partial) + e.expected. Which you could also expose as a property name ".requested", since this value must have been thought useful or Victor wouldn't have defined .expected to be it:-) Seems reasonable, for all that the above computation is trivial. Just a thought, -- Cameron Simpson Artificial intelligence won't make a micrometer out of a monkeywrench. - Rick Gordon ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
