On Sat, May 25, 2013 at 11:49 PM, Łukasz Langa wrote:
> I guess I should explain myself more clearly: __subclasses__() already
> computes its result on-the-fly (it must weed out dead weakrefs) (*). So
> the visible behaviour of __subclasses__ wouldn't change, except for
> ordering.
>
>
> +1
>
> Ma
On 2013-05-25 09:18, Antoine Pitrou wrote:
Hello,
In http://bugs.python.org/issue17936, I proposed making tp_subclasses
(the internal container implementing object.__subclasses__) a dict.
This would make the return order of __subclasses__ completely
undefined, while it is right now slightly pre
On 26/05/13 09:07, PJ Eby wrote:
"""
Transforms a function into a single-dispatch generic function. A **generic
function** is composed of multiple functions implementing the same
operation for different types. Which
implementation should be used during a call is determined by the
dispatch algori
On Sun, May 26, 2013 at 9:07 AM, PJ Eby wrote:
> On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa wrote:
>> So, the latest document is live:
>> http://www.python.org/dev/peps/pep-0443/
>>
>> The code is here:
>> http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363
Hmm, I find the us
On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa wrote:
> So, the latest document is live:
> http://www.python.org/dev/peps/pep-0443/
>
> The code is here:
> http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363
>
> The documentation here:
> http://hg.python.org/features/pep-443/file/t
On Sat, 25 May 2013 22:16:04 +0200
Łukasz Langa wrote:
> On 25 maj 2013, at 17:13, Nick Coghlan wrote:
>
> > So I think I'd prefer flipping this around - you can't provide a
> > custom registry mapping, but you *can* get access to a read only view
> > of it through a "registry" attribute on the
On 25 maj 2013, at 17:13, Nick Coghlan wrote:
> So I think I'd prefer flipping this around - you can't provide a
> custom registry mapping, but you *can* get access to a read only view
> of it through a "registry" attribute on the generic function.
You guys convinced me. Both the PEP and the imp
On Sun, May 26, 2013 at 2:48 AM, PJ Eby wrote:
> On Sat, May 25, 2013 at 10:59 AM, Nick Coghlan wrote:
>> Given the global nature of the cache invalidation, it may be better as
>> a module level abc.get_cache_token() function.
>
> Well, since the only reason to ever use it is to improve performan
On Sat, May 25, 2013 at 9:18 AM, Antoine Pitrou wrote:
> In http://bugs.python.org/issue17936, I proposed making tp_subclasses
> (the internal container implementing object.__subclasses__) a dict.
> This would make the return order of __subclasses__ completely
> undefined, while it is right now sl
On Sat, May 25, 2013 at 10:59 AM, Nick Coghlan wrote:
> Given the global nature of the cache invalidation, it may be better as
> a module level abc.get_cache_token() function.
Well, since the only reason to ever use it is to improve performance,
it'd be better to expose it as an attribute than as
On Sun, May 26, 2013 at 1:09 AM, Łukasz Langa wrote:
> On 25 maj 2013, at 16:59, Nick Coghlan wrote:
>
> I think I added an issue on the tracker for that somewhere... yup:
> http://bugs.python.org/issue16832
>
> Given the global nature of the cache invalidation, it may be better as
> a module lev
On Sun, May 26, 2013 at 12:53 AM, Łukasz Langa wrote:
> On 25 maj 2013, at 16:08, PJ Eby wrote:
>
>> ISTM there should be some way to get at the raw
>> registration info, perhaps by exposing a dictproxy for the registry.
>
> Is that really useful? Just today Antoine asked about changing
> behavio
On 25 maj 2013, at 16:59, Nick Coghlan wrote:
> I think I added an issue on the tracker for that somewhere... yup:
> http://bugs.python.org/issue16832
>
> Given the global nature of the cache invalidation, it may be better as
> a module level abc.get_cache_token() function.
I assigned myself to
On Sun, May 26, 2013 at 12:08 AM, PJ Eby wrote:
> On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa wrote:
>> The most important
>> change in this version is that I introduced ABC support and completed
>> a reference implementation.
>
> Excellent! A couple of thoughts on the implementation...
>
> Wh
On 25 maj 2013, at 16:08, PJ Eby wrote:
> ISTM there should be some way to get at the raw
> registration info, perhaps by exposing a dictproxy for the registry.
Is that really useful? Just today Antoine asked about changing
behaviour of __subclasses__(), suspecting it isn't used in real world
co
On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa wrote:
> The most important
> change in this version is that I introduced ABC support and completed
> a reference implementation.
Excellent! A couple of thoughts on the implementation...
While the dispatch() method allows you to look up what impleme
On 25 maj 2013, at 15:45, Antoine Pitrou wrote:
> On Sat, 25 May 2013 15:26:58 +0200
> Antoine Pitrou wrote:
>
>> On Sat, 25 May 2013 06:23:56 -0700
>> Eli Bendersky wrote:
>>> On Sat, May 25, 2013 at 6:18 AM, Antoine Pitrou wrote:
>>>
Hello,
In http://bugs.python.org/i
On Sat, 25 May 2013 15:26:58 +0200
Antoine Pitrou wrote:
> On Sat, 25 May 2013 06:23:56 -0700
> Eli Bendersky wrote:
> > On Sat, May 25, 2013 at 6:18 AM, Antoine Pitrou wrote:
> >
> > >
> > > Hello,
> > >
> > > In http://bugs.python.org/issue17936, I proposed making tp_subclasses
> > > (the in
On Sat, 25 May 2013 06:23:56 -0700
Eli Bendersky wrote:
> On Sat, May 25, 2013 at 6:18 AM, Antoine Pitrou wrote:
>
> >
> > Hello,
> >
> > In http://bugs.python.org/issue17936, I proposed making tp_subclasses
> > (the internal container implementing object.__subclasses__) a dict.
> > This would m
On Sat, May 25, 2013 at 6:18 AM, Antoine Pitrou wrote:
>
> Hello,
>
> In http://bugs.python.org/issue17936, I proposed making tp_subclasses
> (the internal container implementing object.__subclasses__) a dict.
> This would make the return order of __subclasses__ completely
> undefined, while it i
Hello,
In http://bugs.python.org/issue17936, I proposed making tp_subclasses
(the internal container implementing object.__subclasses__) a dict.
This would make the return order of __subclasses__ completely
undefined, while it is right now slightly predictable. I have never seen
__subclasses__ ac
Hello,
Since the initial version, several minor changes have been made to the
PEP. The history is visible on hg.python.org. The most important
change in this version is that I introduced ABC support and completed
a reference implementation.
No open issues remain from my point of view.
PEP: 443
On Sat, May 25, 2013 at 8:17 PM, Chris McDonough wrote:
> On Sat, 2013-05-25 at 17:57 +1000, Nick Coghlan wrote:
>> I think the simplest thing to do is just append the "3" to the binary
>> name (as we do ourselves for pydoc) and then abide by the
>> recommendations in PEP 394 to reference the corr
On Sat, 2013-05-25 at 17:57 +1000, Nick Coghlan wrote:
> I think the simplest thing to do is just append the "3" to the binary
> name (as we do ourselves for pydoc) and then abide by the
> recommendations in PEP 394 to reference the correct system executable.
I'm curious if folks have other concre
On Sat, May 25, 2013 at 5:56 AM, Barry Warsaw wrote:
> Have any other *nix distros addressed this, and if so, how do you solve it?
I believe Fedora follows the lead set by our own makefile and just
appends a "3" to the script name when there is also a Python 2
equivalent (thus ``pydoc3`` and ``py
On Fri, 24 May 2013 15:56:29 -0400
Barry Warsaw wrote:
> Here's something that seems to come up from time to time in Debian.
>
> Take a Python application like tox, nose, or pyflakes. Their executables work
> with both Python 2 and 3, but require a #! line to choose which interpreter to
> invoke
On Fri, 2013-05-24 at 15:56 -0400, Barry Warsaw wrote:
> Here's something that seems to come up from time to time in Debian.
>
> Take a Python application like tox, nose, or pyflakes. Their executables work
> with both Python 2 and 3, but require a #! line to choose which interpreter to
> invoke.
27 matches
Mail list logo
