On Wed, Jun 8, 2011 at 10:01 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Jun 9, 2011 at 8:51 AM, Darren Dale dsdal...@gmail.com wrote:
for base in bases:
for name in getattr(base, __abstractmethods__, ()):
# CHANGE 4: Using rpartition better tolerates weird
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 ncogh...@gmail.com wrote:
On Thu, Jun 9, 2011 at 1:01 AM, Darren Dale dsdal...@gmail.com 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
On Sat, Mar 19, 2011 at 3:06 PM, Darren Dale dsdal...@gmail.com 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
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
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
On Tue, Oct 5, 2010 at 12:43 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 05 Oct 2010 17:18:18 +0100
Michael Foord fuzzy...@voidspace.org.uk 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
On Tue, Oct 5, 2010 at 1:45 PM, Antoine Pitrou solip...@pitrou.net 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 for packages shared
between one
On Tue, Oct 5, 2010 at 3:37 PM, Terry Reedy tjre...@udel.edu wrote:
On 10/5/2010 2:21 PM, Guido van Rossum wrote:
On Tue, Oct 5, 2010 at 11:17 AM, Darren Daledsdal...@gmail.com wrote:
The issue is implementing a PEP with nice support for relative
imports, and then documenting that it should
On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé ziade.ta...@gmail.com 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
On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking i...@colorstudy.com wrote:
On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang ole...@gmail.com 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*
On Thu, Dec 10, 2009 at 7:24 AM, sstein...@gmail.com
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
On Thu, Dec 10, 2009 at 7:43 AM, Malthe Borch mbo...@gmail.com wrote:
2009/12/10 Darren Dale dsdal...@gmail.com:
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
On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou solip...@pitrou.net wrote:
Tarek Ziadé ziade.tarek at 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
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 dsdal...@gmail.com 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
Hi Martin,
On Sun, Sep 13, 2009 at 2:29 AM, Martin v. Löwis mar...@v.loewis.de 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
Hi Paul,
On Sun, Sep 13, 2009 at 10:54 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/9/13 Darren Dale dsdal...@gmail.com:
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 Phillip Eby
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
On Sat, Sep 12, 2009 at 9:57 AM, Darren Dale dsdal...@gmail.com 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 list
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 to make the situation more
clear?
Thanks,
Darren Dale
21 matches
Mail list logo
