Re: [Python-Dev] sum(...) limitation
On Fri, Aug 01, 2014 at 02:51:54PM -0700, Guido van Rossum wrote: > No. We just can't put all possible use cases in the docstring. :-) > > > On Fri, Aug 1, 2014 at 2:48 PM, Andrea Griffini wrote: > > help(sum) tells clearly that it should be used to sum numbers and not > strings, and with strings actually fails. > > However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists. > > Is this to be considered a bug? Can you explain the rationale behind this design decision? It seems terribly inconsistent. Why are only strings explicitly restricted from being sum()ed? sum() should either ban everything except numbers or accept everything that implements addition (duck typing). pgpIYO6TwDe04.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Multiline with statement line continuation
This is a problem I sometimes run into when working with a lot of files
simultaneously, where I need three or more `with` statements:
with open('foo') as foo:
with open('bar') as bar:
with open('baz') as baz:
pass
Thankfully, support for multiple items was added in 3.1:
with open('foo') as foo, open('bar') as bar, open('baz') as baz:
pass
However, this begs the need for a multiline form, especially when
working with three or more items:
with open('foo') as foo, \
open('bar') as bar, \
open('baz') as baz, \
open('spam') as spam \
open('eggs') as eggs:
pass
Currently, this works with explicit line continuation, but as all style
guides favor implicit line continuation over explicit, it would be nice
if you could do the following:
with (open('foo') as foo,
open('bar') as bar,
open('baz') as baz,
open('spam') as spam,
open('eggs') as eggs):
pass
Currently, this is a syntax error, since the language specification for
`with` is
with_stmt ::= "with" with_item ("," with_item)* ":" suite
with_item ::= expression ["as" target]
as opposed to something like
with_stmt ::= "with" with_expr ":" suite
with_expr ::= with_item ("," with_item)*
|'(' with_item ("," with_item)* ')'
This is really just a style issue, furthermore a style issue that
requires a change to the languagee grammar (probably, someone who knows
for sure please confirm), so at first I thought it wasn't worth
mentioning, but I'd like to hear what everyone else thinks.
pgp_KoQJlTvy9.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] One-line abstractmethod function?
Hello Python devs,
As a regular Python user, I find the abc module useful for making
Python's duck typing more explicit. In particular, I ofen use it
like a Java interface or C header, to provide methods to implement for a
given "duck type".
90% of the time, it ends up looking something like this:
class Foo(metaclass=abc.ABCMeta):
@abc.abstractmethod
def f1(self):
raise NotImplementedError
@staticmethod
@abc.abstractmethod
def f2(arg1):
raise NotImplementedError
...
What if there was a function, say make_abstract_method (better name
pending), so that the above could be written like:
class Foo(metaclass=abc.ABCMeta):
f1 = abc.make_abstract_method('f1', ['self'])
f2 = staticmethod(abc.make_abstract_method('f2', ['arg1']))
...
I think that it would make ABC definitions a lot more compact for many
use cases, but I welcome any criticisms against this idea.
Allen Li
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 05, 2013 at 10:24:11AM -0800, Guido van Rossum wrote:
> How would you get the docstrings in? It seems cramming that much on a
> single line doesn't help readability (even though I agree there is a
> fair amount of boilerplace).
I was basing my initial suggestion somewhat on collections.namedtuple,
which doesn't support docstring either. One option would be to simply
not allow for docstrings, requiring the boilerplate method, the other
would be to add a parameter for the docstring:
make_abstractmethod(name, arglist, docstring='')
On Thu, Dec 5, 2013 at 2:22 PM, Ethan Furman wrote:
> On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
>
>> On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
>>
>>>
>>> How would you get the docstrings in? [...]
>>>
>>
>> One way to reduce the amount of boilerplate code is to make abstractmethod
>> to supply raise NotImplementedError body when none is given. Then you can
>> write
>>
>> class Foo:
>> @abc.abstractmethod
>> def do_bar(self):
>> """perform bar"""
>>
>> The docstring will be required when skipping the body which is probably a
>> good thing.
>>
>
> How will abstractmethod know its function has no body?
I don't think this is a good idea at all, very magical behavior. It is
not intuitive or explicit that an abstractmethod-decorated empty
function raises NotImplementedError.
On Thu, Dec 05, 2013 at 03:06:00PM -0500, Brett Cannon wrote:
> But I would be very leery of this being a default behaviour. Raising
> NotImplementedError is not necessarily what the default result should be
> for a method. If you are building a class that supports multiple
> inheritance you will be calling super().do_bar() almost blindly which, if
> you are not careful, will raise NotImplementedError and that might not be
> appropriate. Maybe returning None is more reasonable, maybe raising
> TypeError. But support a default blindly like this can promote bad
> practices.
I'm not sure what's considered best practice with super() at the moment.
super() is dangerous if you don't know what you are doing in
multi-inheritance design, so I'd consider calling super() blindly is the
problem here, not raising NotImplementedError. I do think raising
NotImplementedError is reasonable default behavior for an
abstractmethod. The only two alternatives are doing nothing/pass/return
None or having actual code in the method.
The former is only useful to silently ignore blind super() calling, the
latter you would define and decorate the method normally.
On Thu, Dec 05, 2013 at 08:39:05PM +, MRAB wrote:
> An abstract method won't have a body (I'm not counting the docstring).
>
> If it _does_ have a body, then it's _not_ an abstract method!
It could have a body, though I would agree it's not commonly used that
way. Maybe something like the following (though it's a poor example):
class Printer(metaclass=abc.ABCMeta):
@abc.abstractmethod
def print(self):
print("Print done.")
class Foo(Printer):
def print(self):
print('foo')
super().print()
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote: > > The only two alternatives are doing nothing/pass/return > > None or having actual code in the method. > > > > The former is only useful to silently ignore blind super() calling, the > > latter you would define and decorate the method normally. > > Actually if you want to support multiple inheritance of your ABC, your > abstract methods *must* be no-ops (or have some kind of default > behavior that can always be done last). I must respectfully disagree with this. If your ABCs aren't meant to be in the MRO, then you should be @registering them as virtual classes and not inheriting them. The trick with Python multiple inheritance and super() (from personal experience) is to not think of it as multiple inheritance (a tree with cycles), but as building the MRO (linear, the same as single inheritance). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
I just wanted to sum up this thread of discussion.
Proposal:
A function in abc to provide a default abstract method
implementation.
foo = make_abstractmethod('foo', ['self'])
is the same as
@abc.abstractmethod
def foo(self):
pass
Details:
Default behavior, if implemented, should probably be empty/pass/return
None. How to handle docstrings? Either attribute docstring (a separate
discussion) or a parameter in the function call.
Pros:
Save a lot of lines defining interface-like ABCs, especially in small
scripts without docstrings (bad practice, but I do it often =))
Cons:
Do we need it?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility
I'm not a dev, so my comment doesn't have that much weight, but it is possible to stop flooding the mailing list with idle chitchat about something mostly irrelevant and non-productive? There's nothing wrong with the current Python versioning scheme. Python 4 is not planned for the near future. I don't see anything else worthy of discussion on this topic. Allen Li On Mon, Mar 10, 2014 at 10:35:29PM +, Mark Lawrence wrote: > On 10/03/2014 22:28, Greg Ewing wrote: > >Chris Angelico wrote: > >>Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all > >>about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, > >>3.=, 3.>, 3.?, 3.@, 3.A. > > > >And we have all of UCS-4 to play with, so for all > >practical purposes the 3.x line can live forever! > > > >The downside is that we'll get endless complaints > >from jmfauth about the Flexible Version Number > >Representation. :-( > > > > Drat, drat and double drat, you beat me to it :) > > -- > My fellow Pythonistas, ask not what our language can do for you, ask what > you can do for our language. > > Mark Lawrence > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cyberdupo56%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 11:36:03AM -0500, Tim Peters wrote: > There's been a bit of serious study on this. The results are still > open to interpretation, though ;-) Here's a nice summary: > > http://whathecode.wordpress.com/2011/02/10/camelcase-vs-underscores-scientific-showdown/ To summarize the key points of the two papers referenced in this thread: Blinky 2009: Participants were trained in camelCase. camelCase was 13.5% slower, 51.5% more accurate on an identifying task. Sharif 2010: Participants were trained in underscores. Same accuracy, camelCase was 20% slower. It seems like, generalizing, camelCase is slower and more accurate, while training affects both speed and accuracy. But, really, there is no compelling scientific argument here. It really boils down to CONSISTENCY: 1) If the existing code uses one or the other, follow the original code to preserve CONSISTENCY. 2) If you're starting a new project, follow PEP8 (or the standards for the language you're using) to preserve CONSISTENCY. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
