Could somebody please clarify the status of PEP 3124? At
http://ftp.python.org/dev/peps/ , it is listed as "under
consideration", but http://ftp.python.org/dev/peps/pep-3124/ says it
has been deferred.
I was reading through the discussion on the python-3000 mailing list
archive, and at one point s
On Sat, Sep 12, 2009 at 9:57 AM, Darren Dale wrote:
> I would be very interested in seeing a framework for generic functions
> in the numpy standard library.
Sorry, I meant to say "python standard library"
___
Python-Dev mailing
Hi Martin,
On Sun, Sep 13, 2009 at 2:29 AM, "Martin v. Löwis" wrote:
>> Could somebody please clarify the status of PEP 3124? At
>> http://ftp.python.org/dev/peps/ , it is listed as "under
>> consideration", but http://ftp.python.org/dev/peps/pep-3124/ says it
>> has been deferred.
>
> This isn't
Hi Paul,
On Sun, Sep 13, 2009 at 10:54 AM, Paul Moore wrote:
> 2009/9/13 Darren Dale :
>>> If Phillip doesn't respond here, you may want to ask him directly.
>>> My impression is that it is deferred because nobody is pursuing it
>>> actively (including Philli
According to http://docs.python.org/reference/datamodel.html , the
reflected operands functions like __radd__ "are only called if the
left operand does not support the corresponding operation and the
operands are of different types. [3] For instance, to evaluate the
expression x - y, where y is an
On Sun, Oct 18, 2009 at 10:50 AM, Darren Dale wrote:
> According to http://docs.python.org/reference/datamodel.html , the
> reflected operands functions like __radd__ "are only called if the
> left operand does not support the corresponding operation and the
> operands are of di
On Thu, Dec 10, 2009 at 7:24 AM, sstein...@gmail.com
wrote:
>
> On Dec 10, 2009, at 3:44 AM, Malthe Borch wrote:
>
>> On 12/8/09 6:16 PM, Tarek Ziadé wrote:
>>> I believe that the current situation is as close to consensus as we
>>> will get on distutils-sig, and in the interests of avoiding month
On Thu, Dec 10, 2009 at 7:43 AM, Malthe Borch wrote:
> 2009/12/10 Darren Dale :
>> Those aren't new proposals, though, they already exist in distutils.
>
> I see. Thanks for clarifying –– maybe the PEP should better explain this.
It is already pretty clear:
"Distu
On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
>>
>> Do you have a better suggestion ? I was thinking about StandardVersion
>> but "Standard"
>> doesn't really express what we want to achieve here I think,
>
> I think StandardVersion is fine.
I prefer Sta
On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé wrote:
> The open question is: do we want to include a full installer that
> takes care of installing / removing dependencies as well ?
>
> I think not. Pip already provides this feature on the top of distutils
> (and distutils2 later I guess) and is no
On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking wrote:
> On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang wrote:
>> My experience is that only `install_requires` is needed (unless you
>> want to create app bundles AFAICR) , but in practice I've noticed that
>> *some* easy_installable packages are not pi
I have a couple questions/comments about the use of PEP 328-style
relative imports. For example, the faq at
http://docs.python.org/py3k/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module
reads:
"Never use relative package imports. If you’re writing code that’s in
the pac
On Tue, Oct 5, 2010 at 12:43 PM, Antoine Pitrou wrote:
> On Tue, 05 Oct 2010 17:18:18 +0100
> Michael Foord wrote:
>> >
>> > Generally I'm +0 on relative imports as a whole.
>>
>> As the OP pointed out, for code that may be *included* in other projects
>> there is no other choice. This is often u
On Tue, Oct 5, 2010 at 1:45 PM, Antoine Pitrou wrote:
> Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit :
>> >>
>> >> As the OP pointed out, for code that may be *included* in other projects
>> >> there is no other choice. This is often useful f
On Tue, Oct 5, 2010 at 3:37 PM, Terry Reedy wrote:
> On 10/5/2010 2:21 PM, Guido van Rossum wrote:
>>
>> On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote:
>>>
>>> The issue is implementing a PEP with nice support for relative
>>> imports, and the
hey have priority.
However, styleguide.html does not explain that the PEPs are more up-to-date.
We shouldn't expect someone to go to the PEPs after finding an answer to
their question in the styleguide.
Perhaps one of these documents could be revised
I suggested at python-ideas a way that the declaration of abstract
properties could be improved to support the decorator syntax:
http://mail.python.org/pipermail/python-ideas/2011-March/009411.html .
A relatively small change to the property builtin would allow
properties to identify themselves as
On Sat, Mar 19, 2011 at 3:06 PM, Darren Dale wrote:
> I suggested at python-ideas a way that the declaration of abstract
> properties could be improved to support the decorator syntax:
> http://mail.python.org/pipermail/python-ideas/2011-March/009411.html .
> A relatively small c
I would like to try to address some shortfalls with the way python deals with
abstract base classes containing descriptors. I originally was just concerned
with improving support for defining abstract properties with the decorator
syntax and converting between abstract and concrete properties, but
On Wed, Jun 8, 2011 at 11:55 AM, Nick Coghlan wrote:
> On Thu, Jun 9, 2011 at 1:01 AM, Darren Dale wrote:
> [snip excellent analysis of the problem]
>
> I have some suggestions regarding a few details of your current code,
> but your basic proposal looks sound to me.
>
>
On Wed, Jun 8, 2011 at 10:01 PM, Nick Coghlan wrote:
> On Thu, Jun 9, 2011 at 8:51 AM, Darren Dale wrote:
>>> for base in bases:
>>> for name in getattr(base, "__abstractmethods__", ()):
>>> # CHANGE 4: Using rpartition
21 matches
Mail list logo
