On Dec 31, 2015 5:56 PM, "Wes Turner" <wes.turner@gmail.com> wrote:
>
>
> On Dec 31, 2015 11:48 AM, "Brett Cannon" <brett@python.org> wrote:
> >
> >
> >
> > On Thu, Dec 31, 2015, 07:08 Alexander Walters <tritium-list@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@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@python.org
> >> https://mail.python.org/mailman/listinfo/python-ideas
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/