On 3 March 2017 at 18:29, Ed Kellett wrote:
> I guess I don't have any hope of convincing people who think there's no need
> to ever do this, but I have a couple of questions for the people who think
> the existing solutions are fine:
>
> - Which of the existing things (slice + [default], conditio
Some years ago I started working on a patch for the socket module which
added a couple of utility functions for being able to easily create a
server socket, with the addition of being able to accept both IPv4 and IPv6
connections (as a single socket):
https://bugs.python.org/issue17561
Given that
On Sat, 4 Mar 2017 at 09:46 Steven D'Aprano wrote:
On Fri, Mar 03, 2017 at 10:35:18PM +0100, Michel Desmoulin wrote:
> Since the start of the discussion, contesters have been offering
> numerous solutions, all being contextual and with gotchas, none being
> obvious, simple or elegant.
I do not
On Sun, 5 Mar 2017 at 11:27 Paul Moore wrote:
> On 3 March 2017 at 18:29, Ed Kellett wrote:
>
> - Which of the existing things (slice + [default], conditional on a slice,
> > conditional on a len() call) do you think is the obvious way to do it?
>
> Write a small wrapper function that implements
On 5 March 2017 at 13:03, Ed Kellett wrote:
>
> No. I'm asking: if list.get did exist, are there any cases (compatibility
> with old versions aside) where list.get's semantics would be applicable, but
> one of the alternatives would be the better choice?
Self-evidently no. But what does that prov
Would it be possible to create a PyPI project to experiement the API and
wait until we collected enough user feedback first?
Currently socket is low level. Not sure if I like the idea of putting more
high level features in it? Asyncio is a good place for high level features,
but is limited to asyn
On Sat, Mar 4, 2017 at 11:19 PM, Elliot Gorokhovsky <
[email protected]> wrote:
> (Summary of results: my patch at https://bugs.python.org/issue28685 makes
> list.sort() 30-50% faster in common cases, and at most 1.5% slower in the
> uncommon worst case.)
>
Thanks for the hard work, th
On Sun, Mar 5, 2017 at 4:51 AM, Ed Kellett wrote:
> It's hard to show examples because, generally speaking, when one can't do
> a thing one does something else instead. I can restructure my programs to
> avoid having this problem, or, if I'm in a hurry, I can use one of the many
> ugly h^W^Wobvio
On Sun, Mar 5, 2017 at 10:13 AM, David Mertz wrote:
> Specifically, if I think I'm dealing with a list that is likely to have 20
> items (rather than maybe 4 or fewer), I'm almost sure the best way to deal
> with it is in a list (or comprehension, map(), etc) and NOT by poking into
> large index
On Sun, 5 Mar 2017 at 14:08 Paul Moore wrote:
> Self-evidently no. But what does that prove? That we should implement
> list.get? You could use the dientical argument for *anything*. There
> needs to be another reason for implementing it.
>
I don't think that's true. It's not true for many other
On Sun, 5 Mar 2017 at 18:13 David Mertz wrote:
> But if the next line is:
>
> data = args.get(17, "")
>
> Then I'm pretty sure the programmer thinks she's being passed a very
> different type of collection than is actually available. I'd rather that
> fails right away and in an obvious way t
On Sun, Mar 5, 2017 at 11:22 AM, Ed Kellett wrote:
> On Sun, 5 Mar 2017 at 18:13 David Mertz wrote:
>
>> data = args.get(17, "")
>>
>> Then I'm pretty sure the programmer thinks she's being passed a very
>> different type of collection than is actually available. I'd rather that
>> fails ri
On Mon, Mar 6, 2017 at 6:13 AM, Ed Kellett wrote:
> The point about this as a Python change is that it's a standard. Who does
> the work couldn't be less relevant; what matters is that it would add a
> consistent and easy spelling for something that doesn't have one.
Oh, absolutely! Because a lan
On Sun, 5 Mar 2017 at 19:54 David Mertz wrote:
> In terms of an actual use case, I can see it for "Lists no longer than 4".
>
That's an excessively hard limit.
> Any other use of this hypothetical method would be an anti-pattern
>
What really is the point of this? You (not uniquely) have been
On Sun, Mar 5, 2017 at 12:16 PM, Ed Kellett wrote:
> On Sun, 5 Mar 2017 at 19:54 David Mertz wrote:
>
>> In terms of an actual use case, I can see it for "Lists no longer than 4".
>>
> Any other use of this hypothetical method would be an anti-pattern
>>
>
> That's an excessively hard limit.
>
On Sun, Mar 5, 2017 at 10:51 AM David Mertz wrote:
> Thanks for the hard work, this looks very promising.
>
Thank you!
> Real world data tends to be mostly-sorted. So it would be useful for your
> benchmarks to include:
>
> A) Performance on completely sorted data
> i) Of homogenous type
>
On 05/03/2017 20:16, Ed Kellett wrote:
On Sun, 5 Mar 2017 at 19:54 David Mertz mailto:[email protected]>> wrote:
In terms of an actual use case, I can see it for "Lists no longer
than 4".
That's an excessively hard limit.
Any other use of this hypothetical method would be an anti-pat
On 5 March 2017 at 19:13, Ed Kellett wrote:
>> I think we're going to have to just disagree. You won't convince me
>> it's worth adding list.get unless you can demonstrate some *existing*
>> costs that would be removed by adding list.get, and showing that they
>> are greater than the costs of addi
On 3/4/2017 10:17 PM, Nick Coghlan wrote:
I forget where it came up, but I seem to recall Guido saying that if he
were designing Python today, he wouldn't include the "else:" clause on
loops, since it inevitably confuses folks the first time they see it.
(Hence articles like mine that attempt
Good job. I'll read your work later.
> relatively simple optimization. I would also add that Python dictionaries
> already implement this optimization: they start out optimizing based on the
> assumption that they'll only be seeing string keys, checking to make sure
> that assumption holds as the
On Sun, Mar 5, 2017 at 6:30 PM INADA Naoki wrote:
> Good job. I'll read your work later.
>
Thanks!
So please don't use string-key dict specialization to rationalize
> list-sort specialization.
>
I'm not quite doing that: I agree that dict is a special case because of
internal use. I'm just sa
On 03/05/2017 11:13 AM, Ed Kellett wrote:
I'm not trying to get anyone to implement list.get, I'm trying to get it
centrally
> documented and allowed into list's overly-mappingproxied namespace.
--> dir(list)
# non dunder methods
'append', 'clear', 'copy', 'count', 'extend', 'index', 'insert',
On Sun, Mar 05, 2017 at 07:19:43AM +, Elliot Gorokhovsky wrote:
> You may remember seeing some messages on here about optimizing list.sort()
> by exploiting type-homogeneity: since comparing apples and oranges is
> uncommon (though possible, i.e. float to int), it pays off to check if the
> li
On Mon, Mar 6, 2017 at 12:53 PM, Elliot Gorokhovsky
wrote:
> (1) lists are idiomatically type-homogeneous. To quote the Python
> documentation, "Lists are mutable, and *their elements are usually
> homogeneous* and are accessed by iterating over the list".
> (2) it's not very common to have to "co
This is exactly what I would have done if I didn't think the changes would
be too large-scale to ever be accepted (at least if proposed by someone
without any experience). This is also what my friend suggested when I
explained my project to him. In fact, this is exactly what dictionaries do:
at eac
On Sun, Mar 5, 2017 at 7:50 PM Chris Angelico wrote:
>
> I would be rather curious to know how frequently a list consists of
> "numbers", but a mix of ints and floats. Does it happen a
> lot in real-world code?
>
>
This is of course undecidable to verify statically, so we can't just crawl
PyPI...
On Sun, Mar 5, 2017 at 6:45 PM, Steven D'Aprano wrote:
> Here is a radical thought... why don't lists track their common type
> themselves? There's only a few methods which can add items:
>
I had exactly the same thought. Lists would need to grow a new attribute,
of course. I'm not sure how tha
On Mon, Mar 6, 2017 at 2:03 PM, Elliot Gorokhovsky
wrote:
> On Sun, Mar 5, 2017 at 7:50 PM Chris Angelico wrote:
>>
>>
>> I would be rather curious to know how frequently a list consists of
>> "numbers", but a mix of ints and floats. Does it happen a
>> lot in real-world code?
>>
>
> This is of c
In my experience and/or estimation... well two things:
A. Mixtures of floats/ints seem a lot more common than the 10% being thrown
around. I don't even consider that bad practice currently (it might become
bad practice if Elliot's patch is used, since keeping elements float-only
would allow much
On Sun, Mar 5, 2017 at 8:10 PM Chris Angelico wrote:
>
> Also, the performance hit is so small, and even that is in the very
> worst case (a homogeneous list with one different type at the end). I
> like changes that make stuff run faster.
>
I agree.
_
On Sun, Mar 5, 2017 at 7:16 PM, Elliot Gorokhovsky <
[email protected]> wrote:
> I would imagine that fewer than even 10% of lists in real world code ever
> get sorted. I mean, just crawl PyPI and look for `.sort()` or `sorted()`;
> you'll find it's not that common.
>
I think I must so
On Sun, Mar 5, 2017 at 8:20 PM David Mertz wrote:
>
> B. I think a very large percentage of lists are heterogeneous. But most
> of the time when they are, it's not because there are several different
> numeric types but rather because a list collects some sort of custom
> objects. Maybe those e
On Sun, Mar 5, 2017 at 8:09 PM David Mertz wrote:
>
> If we added __type_hint__ as None/type-object and added those comparisons
> to it on .insert()/.append()/etc, then we would be slower by some increment
> while all we were doing was adding things. There could only be a win when
> the list is
On Sun, Mar 5, 2017 at 8:23 PM David Mertz wrote:
>
> But also, it's not just the number of list objects that are sorted, but
> how often it's done. I could have a 10,000 line program with only one call
> to `my_list.sort()` in it... but that one line is something that is called
> inside an inne
I see the benchmarks, and while I assume the asymptotic complexity is the
same, is there a longer "start-up" time your optimizations need? Do you
have benchmarks where you sort 10, 100...10**6 items to show that beyond
the types you're sorting, you're not amortizing any increased overhead out
to ob
On Sun, Mar 5, 2017 at 8:29 PM Nick Timkovich
wrote:
> I see the benchmarks, and while I assume the asymptotic complexity is the
> same, is there a longer "start-up" time your optimizations need? Do you
> have benchmarks where you sort 10, 100...10**6 items to show that beyond
> the types you're
On 2017-03-06 03:09, Chris Angelico wrote:
On Mon, Mar 6, 2017 at 2:03 PM, Elliot Gorokhovsky
wrote:
On Sun, Mar 5, 2017 at 7:50 PM Chris Angelico wrote:
I would be rather curious to know how frequently a list consists of
"numbers", but a mix of ints and floats. Does it happen a
lot in real
On Sun, Mar 5, 2017 at 9:12 PM MRAB wrote:
>
> Although it's true that both programmers and Python might treat 10 as
> functionally identical to 10.0, in practice the numbers that are being
> added to the list probably come from some code that returns integers
> /or/ floats, rather than a mixture
[Elliot Gorokhovsky ]
> (Summary of results: my patch at https://bugs.python.org/issue28685 makes
list.sort() 30-50%
> faster in common cases, and at most 1.5% slower in the uncommon worst
case.)
> ...
Would someone please move the patch along? I expect it's my fault it's
languished so long, sinc
On Sun, Mar 5, 2017 at 9:25 PM Tim Peters wrote:
>
> Would someone please move the patch along? I expect it's my fault it's
> languished so long, since I'm probably the natural person to review it, but
> I've been buried under other stuff.
>
> But the patch doesn't change anything about the sort
On Sun, Mar 5, 2017 at 8:33 PM, Elliot Gorokhovsky <
[email protected]> wrote:
> On Sun, Mar 5, 2017 at 9:25 PM Tim Peters wrote:
>
>> One subtle thing to look at: thread safety. IIRC, the patch plugged the
>> comparison function into a file global. That's obviously hosed if multipl
On Sun, Mar 5, 2017 at 10:25 PM David Mertz wrote:
>
> Could we make the file global a table of comparison functions and have
> each thread reference a position in the table? It would be fine if multiple
> threads happened to use the position of e.g. the int comparison, just so
> long as each cho
On Sun, Mar 5, 2017 at 10:45 PM Elliot Gorokhovsky <
[email protected]> wrote:
>
> the problem is, how can we get a unique identifier for the thread in a
> platform-independent way? Any ideas?
>
Oh, I could probably just copy over code from threading.get_ident()... not
sure if the key-
On 3/6/17, Tim Peters wrote:
> One subtle thing to look at: thread safety.
One other subtle: Is it gilectomy neutral?
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://p
Another solution: check if there is more than one thread; if there is, then
disable optimization. Is sorting in multithreaded programs common enough to
warrant adding the complexity to deal with it?
On Sun, Mar 5, 2017 at 10:52 PM Elliot Gorokhovsky <
[email protected]> wrote:
> On Sun
2017-03-05 22:08 GMT-08:00 Elliot Gorokhovsky :
> Another solution: check if there is more than one thread; if there is, then
> disable optimization. Is sorting in multithreaded programs common enough to
> warrant adding the complexity to deal with it?
>
I think using a global is unsafe even witho
On Sun, Mar 5, 2017 at 11:21 PM Jelle Zijlstra
wrote:
>
> I think using a global is unsafe even without multithreading, because
> the compare function itself could end up doing list.sort() (it's
> calling arbitrary Python code after all).
>
Right, of course. So, clearly, the only safe solution i
[Elliot Gorokhovsky ]
> Another solution: check if there is more than one thread; if there is, then
> disable optimization. Is sorting in multithreaded programs common enough
> to warrant adding the complexity to deal with it?
Not a solution. Not even close ;-) Even if it made good sense,
there'
On Mon, Mar 6, 2017 at 3:28 PM, Elliot Gorokhovsky
wrote:
> On Sun, Mar 5, 2017 at 11:21 PM Jelle Zijlstra
> wrote:
>>
>>
>> I think using a global is unsafe even without multithreading, because
>> the compare function itself could end up doing list.sort() (it's
>> calling arbitrary Python code a
On Mon, Mar 6, 2017 at 5:31 PM, Tim Peters wrote:
> Not a solution. Not even close ;-) Even if it made good sense,
> there's nothing to stop a custom __lt__ method from creating new
> threads _during_ a sort.
Arbitrary comparison functions let you do anything but whoa, I
cannot imagine any
On Sun, Mar 5, 2017 at 11:39 PM INADA Naoki wrote:
>
> I think there is another safe solution: Gave up unsafe_object_compare.
>
> Compare function of long, float, and unicode must not call list.sort(),
> and must not release GIL.
> So all you need is, backup old compare_function before sort, and
[Chris Angelico ]
> Arbitrary comparison functions let you do anything but whoa, I
> cannot imagine any way that this would ever happen outside of "hey
> look, here's how you can trigger a SystemError"!
CPython is full of defensive code protecting against malicious crap.
That's why it rarely c
On Mon, Mar 6, 2017 at 5:52 PM, Tim Peters wrote:
> [Chris Angelico ]
>> Arbitrary comparison functions let you do anything but whoa, I
>> cannot imagine any way that this would ever happen outside of "hey
>> look, here's how you can trigger a SystemError"!
>
> CPython is full of defensive cod
On Sun, Mar 5, 2017 at 11:31 PM Tim Peters wrote:
>
> The best approach is indeed to pass the function pointer to every
> location that needs it. Note that a MergeState struct is already
> created per sort invocation, That isn't a file global for much the
> same reason.
>
Right. It's a real sha
54 matches
Mail list logo
