Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

> On 8 Mar 2017, at 22:58, Elliot Gorokhovsky > wrote: > > On Wed, Mar 8, 2017 at 2:14 PM Barry > wrote: > Can you assume that list of of type(list[0]) and use that type's optimised > sort? > But in the optimised sort code check that the types are as required. >

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

On Thu, Mar 9, 2017 at 3:04 AM Barry Scott wrote: > > So you do O(nlogn)*2 pointer compares with my suggestion it seems? Which > is smaller the O(n) pointer checks? > Not sure what you mean here... pretty sure your inequality is backwards? Look -- the point is, we already *do* the pointer check

[Python-ideas] Submitted a PR!

Just submitted a PR implementing this: https://github.com/python/cpython/pull/582 -- just need someone to review it now :) Thanks for all your feedback, everyone! On Sun, Mar 5, 2017 at 12:19 AM Elliot Gorokhovsky < elliot.gorokhov...@gmail.com> wrote: > (Summary of results: my patch at https://

Re: [Python-ideas] dict(default=int)

On Mar 08, 2017, at 05:49 PM, Eric V. Smith wrote: >If we really want to make defaultdict feel more "builtin" (and I don't see >any reason to do so), I'd suggest adding a factory function: > >dict.defaultdict(int) > >Similar in spirit to dict.fromkeys(), except of course returning a >defauldict, n

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

On 9 March 2017 at 21:04, Barry Scott wrote: > It was not clear to me that you need to scan the list at the start to make > sure its homogeneous. Given that the type check is so cheap will it > slow the sort if you do the pointer check in the compare code? I am not > suggesting you run rich compa

Re: [Python-ideas] dict(default=int)

>If we really want to make defaultdict feel more "builtin" (and I don't see > >any reason to do so), I'd suggest adding a factory function: > > > >dict.defaultdict(int) > > Nice. > I agree -- what about: dict.sorteddict() ?? make easy access to various built-in dict variations... -CHB --

Re: [Python-ideas] dict(default=int)

Might make more sense to be dict.default(int), that way it doesn't have redundant dict names. Only problem is then it might be a bit confusing, since you could do {1:2, 3:4}.default(int) and not get the values back. Maybe 'withdefault', and return a copy if called on the instance?

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

On Thu, Mar 9, 2017 at 2:04 AM, Barry Scott wrote: > It was not clear to me that you need to scan the list at the start to make > sure its homogeneous. Given that the type check is so cheap will it > slow the sort if you do the pointer check in the compare code? I am not > suggesting you run rich

Re: [Python-ideas] dict(default=int)

On 09/03/17 23:04, Spencer Brown wrote: Might make more sense to be dict.default(int), that way it doesn't have redundant dict names. I thought that, too. since you could do {1:2, 3:4}.default(int) Could you? Python 3.6.0 (default, Mar 9 2017, 00:43:06) [GCC 5.4.0 20160609] on linux Type

Re: [Python-ideas] dict(default=int)

On Fri, Mar 10, 2017 at 11:29 AM, Erik wrote: > On 09/03/17 23:04, Spencer Brown wrote: >> >> Might make more sense to be dict.default(int), that way it doesn't >> have redundant dict names. > > > I thought that, too. > >> since you could do {1:2, 3:4}.default(int) > > > Could you? > > Python 3.6.

Re: [Python-ideas] Submitted a PR!

Hi. I may be way off-base here, but having scanned the patch I'm not sure I agree that it's the right way forward. What seems to be happening is that the homogeneity of the list is determined somehow (whether tracked with a hint or scanned just-in-time) and then a specific comparison functio

Re: [Python-ideas] Submitted a PR!

There is an "apple to apple" compare function. It's unsafe_object_compare. If you look at the pre-sort check, you will find that if the list is homogeneous but not of float, int, string, or tuple, it sets compare_funcs.key_richcompare = ob_type->tp_richcompare and sets compare_funcs.key_compare = u

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

[Tim Delaney ] > Isn't there already always a scan of the iterable to build the keys array > for sorting (even if no key keyword param is specified)? No - `.sort()` is a list method, and as such has nothing to do with arbitrary iterables, just lists (perhaps you're thinking of the `sorted()` funct

Re: [Python-ideas] Optional parameters without default value

On 3/2/2017 3:03 AM, Serhiy Storchaka wrote: Function implemented in Python can have optional parameters with default value. It also can accept arbitrary number of positional and keyword arguments if use var-positional or var-keyword parameters (*args and **kwargs). In other words, Python signa