Re: [Python-Dev] sum(...) limitation
Alexander Belopolsky writes:
> On Sat, Aug 9, 2014 at 3:08 AM, Stephen J. Turnbull
> wrote:
>
> > All the suggestions
> > I've seen so far are (IMHO, YMMV) just as ugly as the present
> > situation.
> >
>
> What is ugly about allowing strings? CPython certainly has a way to to
> make sum(x, '')
sum(it, '') itself is ugly. As I say, YMMV, but in general last I
heard arguments that are usually constants drawn from a small set of
constants are considered un-Pythonic; a separate function to express
that case is preferred. I like the separate function style.
And that's the current situation, except that in the case of strings
it turns out to be useful to allow for "sums" that have "glue" at the
joints, so it's spelled as a string method rather than a builtin: eg,
", ".join(paramlist).
Actually ... if I were a fan of the "".join() idiom, I'd seriously
propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could
deprecate "".join(string_iterable) in favor of "".sum(string_iterable)
(with the same efficient semantics).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc
Chris Angelico writes: > The justification is illogical. However, I personally believe > boilerplate should be omitted where possible; But it mostly can't be omitted. I wrote 22 classes (all trivial) yesterday for a Python 3 program. Not one derived directly from object. That's a bit unusual, but in the three longish scripts I have to hand, not one had more than 30% "new" classes derived from object. As a matter of personal style, I don't use optional positional arguments (with a few "traditional" exceptions); if I omit one most of the time, when I need it I use a keyword. That's not an argument, it's just an observation that's consistent with support for using an explicit parent class of object "most of the time". > that's why we have a whole lot of things that "just work". Why does > Python not have explicit boolification for if/while checks? Because it does have explicit boolification (signaled by the control structure syntax itself). No? I don't think this is less explicit than REXX, because it doesn't happen elsewhere (10 + False == 10 -- not True, and even bool(10) + False != True). > So, my view would be: Py3-only tutorials can and probably should omit > it, But this doesn't make things simpler. It means that there are two syntaxes to define some classes, and you want to make one of them TOOWTDI for classes derived directly from object, and the other TOOWTDI for non-trivial subclasses. I'll grant that in some sense it's no more complex, either, of course. Note that taken to extremes, your argument could be construed as "we should define defaults for all arguments and omit them where possible". Of course for typing in quick programs, and for trivial classes, omitting the derivation from object is a useful convenience. But I don't think it's something that should be encouraged in tutorials. Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.walk() is going to be *fast* with scandir
Hi Larry, On 10 August 2014 08:11, Larry Hastings wrote: >> A small tip from my bzr days - cd into the directory before scanning it > > I doubt that's permissible for a library function like os.scandir(). Indeed, chdir() is notably not compatible with multithreading. There would be a non-portable but clean way to do that: the functions openat() and fstatat(). They only exist on relatively modern Linuxes, though. A bientôt, Armin. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.walk() is going to be *fast* with scandir
On Sun, 10 Aug 2014 13:57:36 +1000, Nick Coghlan wrote: > On 10 August 2014 13:20, Antoine Pitrou wrote: > > Le 09/08/2014 12:43, Ben Hoyt a écrit : > > > >> Just thought I'd share some of my excitement about how fast the all-C > >> version [1] of os.scandir() is turning out to be. > >> > >> Below are the results of my scandir / walk benchmark run with three > >> different versions. I'm using an SSD, which seems to make it > >> especially faster than listdir / walk. Note that benchmark results can > >> vary a lot, depending on operating system, file system, hard drive > >> type, and the OS's caching state. > >> > >> Anyway, os.walk() can be FIFTY times as fast using os.scandir(). > > > > > > Very nice results, thank you :-) > > Indeed! > > This may actually motivate me to start working on a redesign of > walkdir at some point, with scandir and DirEntry objects as the basis. > My original approach was just too slow to be useful in practice (at > least when working with trees on the scale of a full Fedora or RHEL > build hosted on an NFS share). There is another potentially good place in the stdlib to apply scandir: iglob. See issue 22167. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On Aug 10, 2014, at 05:24 PM, Stephen J. Turnbull wrote:
>Actually ... if I were a fan of the "".join() idiom, I'd seriously
>propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could
>deprecate "".join(string_iterable) in favor of "".sum(string_iterable)
>(with the same efficient semantics).
Ever since ''.join was added, there has been vague talk about adding a join()
built-in. If the semantics and argument syntax can be worked out, I'd still
be in favor of that. Probably deserves a PEP and a millithread community
bikeshed paintdown.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc
On Sat, Aug 9, 2014 at 8:44 PM, Steven D'Aprano wrote: > It is certainly required when writing code that will behave the same in > version 2 and 3 > This is not true. An alternative is to put __metaclass__ = type at the top of your module to make all classes in your module new-style in python2. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc
On Aug 10, 2014, at 11:51 AM, Alexander Belopolsky wrote: >This is not true. An alternative is to put > >__metaclass__ = type > >at the top of your module to make all classes in your module new-style in >python2. I like this much better, and it's what I do in my own bilingual code. It makes it much easier to remove the unnecessary cruft when you drop the Python 2 support. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc
On Sun, Aug 10, 2014 at 11:51:51AM -0400, Alexander Belopolsky wrote: > On Sat, Aug 9, 2014 at 8:44 PM, Steven D'Aprano wrote: > > > It is certainly required when writing code that will behave the same in > > version 2 and 3 > > > > This is not true. An alternative is to put > > __metaclass__ = type > > at the top of your module to make all classes in your module new-style in > python2. So it is. I forgot about that, thank you for the correction. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote:
Actually ... if I were a fan of the "".join() idiom, I'd seriously
propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could
deprecate "".join(string_iterable) in favor of "".sum(string_iterable)
(with the same efficient semantics).
Actually, there is no need to wait for 0.sum() to propose "".sum... but
it is only a spelling change, so no real benefit.
Thinking about this more, maybe it should be a class function, so that
it wouldn't require an instance:
str.sum( iterable_containing_strings )
[ or str.join( iterable_containing_strings ) ]
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On Sun, 10 Aug 2014 13:12:26 -0700, Glenn Linderman
wrote:
> On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote:
> > Actually ... if I were a fan of the "".join() idiom, I'd seriously
> > propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could
> > deprecate "".join(string_iterable) in favor of "".sum(string_iterable)
> > (with the same efficient semantics).
> Actually, there is no need to wait for 0.sum() to propose "".sum... but
> it is only a spelling change, so no real benefit.
>
> Thinking about this more, maybe it should be a class function, so that
> it wouldn't require an instance:
>
> str.sum( iterable_containing_strings )
>
> [ or str.join( iterable_containing_strings ) ]
That's how it used to be spelled in python2.
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
On Sun, 10 Aug 2014 13:12:26 -0700, Glenn Linderman
wrote:
> On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote:
> > Actually ... if I were a fan of the "".join() idiom, I'd seriously
> > propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could
> > deprecate "".join(string_iterable) in favor of "".sum(string_iterable)
> > (with the same efficient semantics).
> Actually, there is no need to wait for 0.sum() to propose "".sum... but
> it is only a spelling change, so no real benefit.
>
> Thinking about this more, maybe it should be a class function, so that
> it wouldn't require an instance:
>
> str.sum( iterable_containing_strings )
>
> [ or str.join( iterable_containing_strings ) ]
Sorry, I mean 'string.join' is how it used to be spelled. Making it a
class method is indeed slightly different.
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum(...) limitation
Glenn Linderman writes:
> On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote:
> > Actually ... if I were a fan of the "".join() idiom, I'd seriously
> > propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could
> > deprecate "".join(string_iterable) in favor of "".sum(string_iterable)
> > (with the same efficient semantics).
> Actually, there is no need to wait for 0.sum() to propose "".sum... but
> it is only a spelling change, so no real benefit.
IMO it's worse than merely a spelling change, because (1) "join" is a
more evocative term for concatenating strings than "sum" and (2) I
don't know of any other sums that allow "glue".
I'm overall -1 on trying to change the current situation (except for
adding a join() builtin or str.join class method). We could probably
fix everything in a static-typed language (because that would allow
picking an initial object of the appropriate type), but without that
we need to pick a default of some particular type, and 0 makes the
most sense.
I can understand the desire of people who want to use the same syntax
for summing an iterable of numbers and for concatenating an iterable
of strings, but to me they're really not even formally the same in
practical use. I'm very sympathetic to Steven's explanation that "we
wouldn't be having this discussion if we used a different operator for
string concatenation". Although that's not the whole story: in
practice even numerical sums get split into multiple functions because
floating point addition isn't associative, and so needs careful
treatment to preserve accuracy. At that point I'm strongly +1 on
abandoning attempts to "rationalize" summation.
I'm not sure how I'd feel about raising an exception if you try to sum
any iterable containing misbehaved types like float. But not only
would that be a Python 4 effort due to backward incompatibility, but
it sorta contradicts the main argument of proponents ("any type
implementing __add__ should be sum()-able").
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
