Hi,
> Honestly before writing a lot of code here I'd like to hear more from
> Martin about the spread of mistakes he's observed among his users.
Over the weekend, I tried to classify the mistakes I found. Most of
the times, it's something like "I'm just doing a quick lookup on the
database, that
On Mon, Oct 10, 2016 at 8:59 PM, Martin Teichmann
wrote:
> We would need to know whether the file descriptor we
> read from was created as non-blocking, or whether it was an actual
> file, and how fast the file storage is for this file (SSD: maybe fine,
> Network: to slow, magnetic disk: dunno). A
On Mon, Oct 10, 2016 at 2:59 AM, Martin Teichmann
wrote:
> This is why I got my idea to flag such calls. Unfortunately, I
> realized that it is nearly impossible to tell whether a read call is
> blocking or not. We would need to know whether the file descriptor we
> read from was created as non-bl
I'm aware of "raise ... from None" (from PEP 415). However, how can I
achieve that same effect (of suppressing the "During handling of the above
exception, another exception occurred" message) without having control over
the code that is executed from the except clause? I thought that
sys.exc_clear
On 2016-10-11 01:43, Václav Dvořák wrote:
I'm aware of "raise ... from None" (from PEP 415). However, how can I
achieve that same effect (of suppressing the "During handling of the
above exception, another exception occurred" message) without having
control over the code that is executed from the
On 09/10/16 12:43, Paul Moore wrote:
I'd probably lay this out as
# Less indent needed for keys, so thirdkey fits better in this case
mydict = {
'mykey': 'a very very very very very long value',
'secondkey': 'a short value',
'thirdkey':
'a very very very long value that conti
[please restrict follow-ups to python-ideas]
Let's not get hung up on meta-discussion here - I always thought "massive
clusterf**k" was a precise technical term anyway ;-)
While timing certainly needs to be done more carefully, it's obvious to me
that this approach _should_ pay off significantly
Thanks for looking at this!
That's why I spent months of my life (overall) devising a sequence of
sorting algorithms for Python that reduced the number of comparisons needed.
Yes, that's why I think this is so cool: for a couple dozen lines of code,
we can get (at least for some cases, according
On Tue, Oct 11, 2016 at 2:29 PM, Stephen J. Turnbull
wrote:
> Chris Angelico writes:
>
> > Given that it's not changing semantics at all, just adding info/hints
> > to an error message, it could well be added in a point release.
>
> But it does change semantics, specifically for doctests.
Blah,
On Tue, Oct 11, 2016 at 2:29 PM, Elliot Gorokhovsky
wrote:
> Ya, I think this may be a good approach for floats: if the list is all
> floats, just copy all the floats into a seperate array, use the standard
> library quicksort, and then construct a sorted PyObject* array. Like maybe
> set up a str
Oh no, the idea here is just you would copy over the floats associated with
the PyObject* and keep them in an array of such structs, so that we know
which PyObject* are associated with which floats. Then after the standard
library quicksort sorts them you would copy the PyObject* into the list. So
On Tue, Oct 11, 2016 at 2:41 PM, Elliot Gorokhovsky
wrote:
> Oh no, the idea here is just you would copy over the floats associated with
> the PyObject* and keep them in an array of such structs, so that we know
> which PyObject* are associated with which floats. Then after the standard
> library
It would still be stable. You would copy over {{x,1.0},{y,1.0},{x,1.0}},
and as long as a stable sort is used you would get out the same array,
using the cmp function left->key < right->key. Then you would go in order,
copying back [x,y,x].
On Mon, Oct 10, 2016 at 9:49 PM Chris Angelico wrote:
On Mon, Oct 10, 2016 at 11:30 PM Elliot Gorokhovsky <
[email protected]> wrote:
> - I expect tuples will also be worth specializing (complex sort keys are
> often implemented as tuples).
>
> I'm not sure what you mean here... I'm looking at the types of lo.keys,
> not of saved_ob_item (
Chris Angelico writes:
> Given that it's not changing semantics at all, just adding info/hints
> to an error message, it could well be added in a point release.
But it does change semantics, specifically for doctests.
I seem to recall that that is considered a blocker for this kind of
change i
On Mon, Oct 10, 2016 at 7:56 PM, Elliot Gorokhovsky
wrote:
> So here's a simple attempt at taking lots of measurements just using
> time.time() with lists of ints. The results are great, if they are valid
> (which I leave to you to judge); even for lists with just one element, it's
> 16% faster!
On Mon, Oct 10, 2016 at 10:15 PM Guido van Rossum wrote:
> But that's suspicious in itself -- since no comparisons are needed to
>
> sort a 1-element list, if it's still faster, there must be something
>
> else you're doing (or not doing) that's affecting the time measured.
>
Oh, ya. Duh. So th
On 11 October 2016 at 10:43, Václav Dvořák wrote:
> But I find this misleading, as the original KeyError is not really an error
> at all. I could of course avoid the situation by changing the try/except
> (EAFP) into a test for the key's presence (LBYL) but that's not very
> Pythonic and less thre
Elliot Gorokhovsky wrote:
if the list is all
floats, just copy all the floats into a seperate array, use the standard
library quicksort, and then construct a sorted PyObject* array.
My question would be whether sorting list of just floats
(or where the keys are just floats) is common enough to
Elliot Gorokhovsky wrote:
I will be able to rule that out
when I implement this as a patch instead of an extension module and test
my own build.
You could test it against a locally built Python without
having to go that far.
--
Greg
___
Python-ideas
20 matches
Mail list logo
