[Python-ideas] Where to put non-collection ABCs (was: Deprecating the old-style sequence protocol)

Wes Turner wes.turner at gmail.com
Thu Dec 31 18:59:57 EST 2015 

On Dec 31, 2015 5:56 PM, "Wes Turner" <wes.turner at gmail.com> wrote:
>
>
> On Dec 31, 2015 11:48 AM, "Brett Cannon" <brett at python.org> wrote:
> >
> >
> >
> > On Thu, Dec 31, 2015, 07:08 Alexander Walters <tritium-list at sdamon.com>
wrote:
> >>
> >> Would it be a good idea to mix 'concrete implementations of ABCs'*
> >> directly in the abc module where the tooling to create ABCs live, or to
> >> put it in a submodule?  I feel it should be a submodule, but that isn't
> >> based on vast experience.
> >>
> >> * Yes, I know, these are not concrete implementations of types... I
find
> >> it a little confusing to describe.
> >
> >
> > It's a possibility. Feel free to comment on the issue if you want to
discuss this further.
> >
> > -Brett
>
> Are these interfaces?
>
> * | Docs: http://docs.zope.org/zope.interface/
> * | Docs:
http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/zca.html
>
> * | Docs:
https://github.com/Pylons/pyramid/blob/master/pyramid/config/zca.py
>   * | Docs:
http://docs.pylonsproject.org/projects/pyramid/en/latest/api/interfaces.html
>   * | Src:
https://github.com/Pylons/pyramid/blob/master/pyramid/interfaces.py

* pyramid.interfaces.IDict

http://docs.pylonsproject.org/projects/pyramid/en/latest/api/interfaces.html#pyramid.interfaces.IDict
* pyramid.interfaces.IMultiDict

http://docs.pylonsproject.org/projects/pyramid/en/latest/api/interfaces.html#pyramid.interfaces.IMultiDict

[source]

>
> >
> >>
> >> On 12/28/2015 22:58, Nick Coghlan wrote:
> >> > On 29 December 2015 at 03:58, M.-A. Lemburg <mal at egenix.com> wrote:
> >> >> On 28.12.2015 18:42, Brett Cannon wrote:
> >> >>> Speaking of using ABCs more, where should we put ABCs which have
nothing to
> >> >>> do with collections? As of right now all ABCs seem to get shoved
into
> >> >>> collections.abc, but e.g. Awaitable and Coroutine are not types of
> >> >>> collections. I personally want to add a context manager ABC with a
default
> >> >>> __exit__.
> >> >>>
> >> >>> I opened http://bugs.python.org/issue25637 to discuss this, but I
figured a
> >> >>> wider discussion wouldn't hurt. Some suggest just putting the ABCs
into the
> >> >>> abc module. We could create an interfaces module (top-level or a
submodule
> >> >>> of ABC). The other option is to put the ABCs in subject-specific
modules,
> >> >>> so my context manager one would go into contextlib (either
top-level or an
> >> >>> abc submodule); don't know where the coroutine ones would go since
it might
> >> >>> be overloading asyncio if we out them there.
> >> >>>
> >> >>> Anyway, the key point is collections.abc is starting to get
non-collections
> >> >>> stuff and if we are going to start pushing ABCs more we should
decide how
> >> >>> we want to organize them in general in the stdlib and instead of
dumping
> >> >>> them into collections.abc.
> >> >> I'd put them into the abc module (perhaps turning this into a
> >> >> package, if things get too crowded).
> >> >>
> >> >> collections.abc could then do a "from abc import *" for b/w
> >> >> compatibility.
> >> > With the benefit of hindsight, I think a broad namespace separation
> >> > like that might have been a good way to go from a data model
> >> > discoverability perspective, as it clearly separates the abstract
> >> > descriptions of data and control flow modelling concepts from the
> >> > concrete implementations of those concepts.
> >> >
> >> > However, we should also keep in mind which standard library modules
> >> > already publish ABCs, which is at least:
> >> >
> >> >    typing
> >> >    io
> >> >    numbers
> >> >    collections.abc
> >> >    selectors
> >> >    email
> >> >
> >> > (That list was collected by grepping Python files for ABCMeta, so I
> >> > may have missed some)
> >> >
> >> > That suggests to me that this design decision has effectively already
> >> > been made, and it's to include the ABCs in the relevant domain
> >> > specific modules. The inclusion of the non-collections related ABCs
in
> >> > collections.abc are the anomaly, which can be addressed by moving
them
> >> > out to a more appropriate location (adjusting the documentation
> >> > accordingly), and then importing them into collections.abc for
> >> > backwards compatibility (taking care not to increase the startup
> >> > import footprint too much in the process).
> >> >
> >> > The current collections.abc interfaces which I think are most at
issue here:
> >> >
> >> >      Callable
> >> >      Iterable
> >> >      Iterator
> >> >      Generator
> >> >      Awaitable
> >> >      Coroutine
> >> >      Awaitable
> >> >      AsyncIterable
> >> >      AsyncIterator
> >> >
> >> > (I'm excluding Hashable from the list, as the main reason that
matters
> >> > is in describing whether or not something is suitable for inclusion
in
> >> > a dict or set)
> >> >
> >> > These differ from the rest of the collections.abc interfaces in that
> >> > they're more closely associated with language level control flow
> >> > syntax than they are with containers specifically:
> >> >
> >> >      Callable - function calls
> >> >      Iterable - for loops, comprehensions
> >> >      Iterator - for loops, comprehensions
> >> >      Generator - generators, generator expressions
> >> >      Awaitable - await expressions
> >> >      Coroutine - async def
> >> >      AsyncIterable - async for
> >> >      AsyncIterator  - async for
> >> >
> >> > Adding ContextManager and AsyncContextManager would give ABCs for the
> >> > protocols related to "with" and "async with".
> >> >
> >> > Since these all correspond to syntactic protocols, I now think it's
> >> > reasonable to include them directly in the "abc" namespace, since
that
> >> > still gives us a clear guideline for which ABCs go there, and which
> >> > belong somewhere else: if it has syntax associated with it, or it's
> >> > part of the ABC machinery itself, then it can go directly in the
"abc"
> >> > namespace. Using the "abc" namespace also ensures there isn't any
> >> > additional import overhead, since that gets imported by all ABC using
> >> > code anyway.
> >> >
> >> > Regards,
> >> > Nick.
> >> >
> >>
> >> _______________________________________________
> >> Python-ideas mailing list
> >> Python-ideas at python.org
> >> https://mail.python.org/mailman/listinfo/python-ideas
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151231/390c56eb/attachment.html>

More information about the Python-ideas mailing list