Re: [Python-Dev] raw_input prompt not printed on sys.stderr

[Tal Einat]

On Mon, Jul 6, 2015 at 11:45 PM, Clement Rouault
 wrote:
> Hi,
>
> While playing with non-standard sys.stdout/stderr, I noticed that the
> prompt of raw_input was printed on stderr (not sys.stderr) (see
> Parser/myreadline.c:120).
>
> I found an issue (http://bugs.python.org/issue1927) from 2008 talking
> about changing stderr to stdout. But nobody in the thread seems
> bothered by the use of stdout/err over the ones in the sys module.
>
> So, is there any good reason I might not be aware of that justifies
> the use of stderr over sys.stderr ?

See issue #24402: input() uses sys.__stdout__ instead of sys.stdout for prompt

That issue was deemed probably a bug, and includes a simple patch
which appears to fix the issue (without tests).

- Tal Einat
___
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] cpython: Minor bit of factoring-out common code.

[Serhiy Storchaka]

On 07.07.15 05:08, raymond.hettinger wrote:

https://hg.python.org/cpython/rev/5088f2cd6293
changeset:   96866:5088f2cd6293
user:Raymond Hettinger 
date:Mon Jul 06 19:08:49 2015 -0700
summary:
   Minor bit of factoring-out common code.



+if (rv < 0)
+goto error;
  if (rv) {
-if (set_add_entry(result, key, hash)) {
-Py_DECREF(it);
-Py_DECREF(result);
-Py_DECREF(key);
-return NULL;
-}
+if (set_add_entry(result, key, hash))
+goto error;
  }
  Py_DECREF(key);
  }


In tight loop it may be worth to rewrite the code

if (rv < 0)
goto error;
if (rv) {
expensive_operation();
}
// if (rv == 0) do nothing

in the form:

if (rv) {
if (rv < 0)
goto error;
expensive_operation();
}

This looks less clear, but needs only one test in the case of rv == 0.


___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Serhiy Storchaka]

On 07.07.15 05:03, raymond.hettinger wrote:

https://hg.python.org/cpython/rev/c9782a9ac031
changeset:   96865:c9782a9ac031
user:Raymond Hettinger 
date:Mon Jul 06 19:03:01 2015 -0700
summary:
   Tighten-up code in the set iterator to use an entry pointer rather than 
indexing.

files:
   Objects/setobject.c |  35 
   1 files changed, 13 insertions(+), 22 deletions(-)


diff --git a/Objects/setobject.c b/Objects/setobject.c
--- a/Objects/setobject.c
+++ b/Objects/setobject.c
@@ -766,8 +766,8 @@
  PyObject_HEAD
  PySetObject *si_set; /* Set to NULL when iterator is exhausted */
  Py_ssize_t si_used;
-Py_ssize_t si_pos;
  Py_ssize_t len;
+setentry *entry;
  } setiterobject;

  static void
@@ -845,8 +845,6 @@

  static PyObject *setiter_iternext(setiterobject *si)
  {
-PyObject *key;
-Py_ssize_t i, mask;
  setentry *entry;
  PySetObject *so = si->si_set;

@@ -860,25 +858,18 @@
  si->si_used = -1; /* Make this state sticky */
  return NULL;
  }
-
-i = si->si_pos;
-assert(i>=0);
-entry = so->table;
-mask = so->mask;
-while (i <= mask && (entry[i].key == NULL || entry[i].key == dummy))
-i++;
-si->si_pos = i+1;
-if (i > mask)
-goto fail;
+if (si->len <= 0) {
+Py_DECREF(so);
+si->si_set = NULL;
+return NULL;
+}
+entry = si->entry;
+while (entry->key == NULL || entry->key == dummy)
+entry++;
  si->len--;
-key = entry[i].key;
-Py_INCREF(key);
-return key;
-
-fail:
-Py_DECREF(so);
-si->si_set = NULL;
-return NULL;
+si->entry = entry + 1;
+Py_INCREF(entry->key);
+return entry->key;
  }

  PyTypeObject PySetIter_Type = {
@@ -923,8 +914,8 @@
  Py_INCREF(so);
  si->si_set = so;
  si->si_used = so->used;
-si->si_pos = 0;
  si->len = so->used;
+si->entry = so->table;
  _PyObject_GC_TRACK(si);
  return (PyObject *)si;
  }


What if so->table was reallocated during the iteration, but so->used is 
left the same? This change looks unsafe to me.



___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Serhiy Storchaka]

On 07.07.15 10:42, Serhiy Storchaka wrote:

On 07.07.15 05:03, raymond.hettinger wrote:

https://hg.python.org/cpython/rev/c9782a9ac031
changeset:   96865:c9782a9ac031
user:Raymond Hettinger 
date:Mon Jul 06 19:03:01 2015 -0700
summary:
   Tighten-up code in the set iterator to use an entry pointer rather
than indexing.



What if so->table was reallocated during the iteration, but so->used is
left the same? This change looks unsafe to me.


There is crash reproducer.

http://bugs.python.org/issue24581

___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Victor Stinner]

Maybe such issue can be detected if Raymond uses the bug tracker for
code review? I remember many cases where Serhiy and Raymond
collaborated successfully and wrote better code thanks to the code
review.

Victor

2015-07-07 9:42 GMT+02:00 Serhiy Storchaka :
> On 07.07.15 05:03, raymond.hettinger wrote:
>>
>> https://hg.python.org/cpython/rev/c9782a9ac031
>> changeset:   96865:c9782a9ac031
>> user:Raymond Hettinger 
>> date:Mon Jul 06 19:03:01 2015 -0700
>> summary:
>>Tighten-up code in the set iterator to use an entry pointer rather than
>> indexing.
>>
>> files:
>>Objects/setobject.c |  35 
>>1 files changed, 13 insertions(+), 22 deletions(-)
>>
>>
>> diff --git a/Objects/setobject.c b/Objects/setobject.c
>> --- a/Objects/setobject.c
>> +++ b/Objects/setobject.c
>> @@ -766,8 +766,8 @@
>>   PyObject_HEAD
>>   PySetObject *si_set; /* Set to NULL when iterator is exhausted */
>>   Py_ssize_t si_used;
>> -Py_ssize_t si_pos;
>>   Py_ssize_t len;
>> +setentry *entry;
>>   } setiterobject;
>>
>>   static void
>> @@ -845,8 +845,6 @@
>>
>>   static PyObject *setiter_iternext(setiterobject *si)
>>   {
>> -PyObject *key;
>> -Py_ssize_t i, mask;
>>   setentry *entry;
>>   PySetObject *so = si->si_set;
>>
>> @@ -860,25 +858,18 @@
>>   si->si_used = -1; /* Make this state sticky */
>>   return NULL;
>>   }
>> -
>> -i = si->si_pos;
>> -assert(i>=0);
>> -entry = so->table;
>> -mask = so->mask;
>> -while (i <= mask && (entry[i].key == NULL || entry[i].key == dummy))
>> -i++;
>> -si->si_pos = i+1;
>> -if (i > mask)
>> -goto fail;
>> +if (si->len <= 0) {
>> +Py_DECREF(so);
>> +si->si_set = NULL;
>> +return NULL;
>> +}
>> +entry = si->entry;
>> +while (entry->key == NULL || entry->key == dummy)
>> +entry++;
>>   si->len--;
>> -key = entry[i].key;
>> -Py_INCREF(key);
>> -return key;
>> -
>> -fail:
>> -Py_DECREF(so);
>> -si->si_set = NULL;
>> -return NULL;
>> +si->entry = entry + 1;
>> +Py_INCREF(entry->key);
>> +return entry->key;
>>   }
>>
>>   PyTypeObject PySetIter_Type = {
>> @@ -923,8 +914,8 @@
>>   Py_INCREF(so);
>>   si->si_set = so;
>>   si->si_used = so->used;
>> -si->si_pos = 0;
>>   si->len = so->used;
>> +si->entry = so->table;
>>   _PyObject_GC_TRACK(si);
>>   return (PyObject *)si;
>>   }
>
>
> What if so->table was reallocated during the iteration, but so->used is left
> the same? This change looks unsafe to me.
>
>
> ___
> 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/victor.stinner%40gmail.com
___
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] PEP 493: Redistributor guidance for Python 2.7 HTTPS

[Mark Lawrence]

On 07/07/2015 03:10, Stephen J. Turnbull wrote:

Cross-posted to redirect discussion.  Replies directed to Python-Ideas.

Erik Bray writes on Python-Dev:
  > On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou  wrote:
  > > On Mon, 6 Jul 2015 14:22:46 +1000, Nick Coghlan  
wrote:
  > >>
  > >> The main change from the last version discussed on python-ideas
  > >
  > > Was it discussed there? That list has become totally useless, I've
  > > stopped following it.
  >
  > Considering that a useful discussion of a useful PEP occurred there
  > (not to mention other occasionally useful discussions) I'd say that
  > such a value judgment is not only unnecessary but also inaccurate.

As you point out, the words "totally" and "useless" were unnecessary
and inaccurate respectively.

However, the gist of his post, that the S/N on Python-Ideas has become
substantially lower in the last few months, seems accurate to me.  At
least two recent threads could have been continued on Python-List,
where they would have benefited a lot more users, and they didn't seem
profitable on Python-Ideas since it was quite evident that Those Who
Know About Python were adamantly opposed to the idea as discussed in
the thread, while the proponent kept pushing on that brick wall rather
than seeking a way around it.

I myself continue to follow Python-Ideas, Nick and other committers
are posting here daily, and even Guido manages to pop up occasionally,
so that may be no problem (or even a good thing if it results in
educating and inviting new committers in the long run).  But I think
it's worth considering whether it we should cultivate a bit more
discipline here.

Again, discussion on Python-Ideas, please.



From https://mail.python.org/mailman/listinfo/python-ideas


This list is to contain discussion of speculative language ideas for 
Python for possible inclusion into the language. If an idea gains 
traction it can then be discussed and honed to the point of becoming a 
solid proposal to put to python-dev as appropriate.



Relative to the above I believe that far too many proposals are for 
trivial ideas, mainly targetted at the stdlib, that would be better 
suited to the main python list.


As for gaining traction, it's often the complete opposite, flogging a 
dead horse is an understatement for some threads.  Gently putting the OP 
down with a firm but polite "it ain't gonna happen" would save a lot of 
time all around.


Just my £0.02p worth.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Maciej Fijalkowski]

I must say I completely fail to understand the procedures under which
python is developed. If the change (unreviewed, just randomly applied)
causes crashes, then surely it should be reverted first and continued
on bug tracker instead of lingering (and the complain sitting on bug
tracker)?

On Tue, Jul 7, 2015 at 10:10 AM, Serhiy Storchaka  wrote:
> On 07.07.15 10:42, Serhiy Storchaka wrote:
>>
>> On 07.07.15 05:03, raymond.hettinger wrote:
>>>
>>> https://hg.python.org/cpython/rev/c9782a9ac031
>>> changeset:   96865:c9782a9ac031
>>> user:Raymond Hettinger 
>>> date:Mon Jul 06 19:03:01 2015 -0700
>>> summary:
>>>Tighten-up code in the set iterator to use an entry pointer rather
>>> than indexing.
>
>
>> What if so->table was reallocated during the iteration, but so->used is
>> left the same? This change looks unsafe to me.
>
>
> There is crash reproducer.
>
> http://bugs.python.org/issue24581
>
>
> ___
> 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/fijall%40gmail.com
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Antoine Pitrou]

On Tue, 7 Jul 2015 12:04:34 +0200
Maciej Fijalkowski  wrote:
> I must say I completely fail to understand the procedures under which
> python is developed. If the change (unreviewed, just randomly applied)
> causes crashes, then surely it should be reverted first and continued
> on bug tracker instead of lingering (and the complain sitting on bug
> tracker)?

+1, especially as the commit doesn't seem to come with any concrete
explanation of what is being fixed or improved.

("tighten-up code" is really a platonic motivation... not necessarily
bad, but should be trumped such as operational concerns, e.g.
crashes :-))

Regards

Antoine.


___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Guido van Rossum]

FYI, do we have any indication that Raymond even read the comment? IIRC he
doesn't regularly read python-dev. I also don't think code review comments
ought to go to python-dev; the commiters list would seem more appropriate?
(Though it looks like python-checkins is configured to direct replies to
python-dev. Maybe we need to revisit that?)

On Tue, Jul 7, 2015 at 1:24 PM, Antoine Pitrou  wrote:

> On Tue, 7 Jul 2015 12:04:34 +0200
> Maciej Fijalkowski  wrote:
> > I must say I completely fail to understand the procedures under which
> > python is developed. If the change (unreviewed, just randomly applied)
> > causes crashes, then surely it should be reverted first and continued
> > on bug tracker instead of lingering (and the complain sitting on bug
> > tracker)?
>
> +1, especially as the commit doesn't seem to come with any concrete
> explanation of what is being fixed or improved.
>
> ("tighten-up code" is really a platonic motivation... not necessarily
> bad, but should be trumped such as operational concerns, e.g.
> crashes :-))
>
> Regards
>
> Antoine.
>
>
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] PEP 493: Redistributor guidance for Python 2.7 HTTPS

[Guido van Rossum]

On Tue, Jul 7, 2015 at 11:24 AM, Mark Lawrence 
wrote:

> From https://mail.python.org/mailman/listinfo/python-ideas
>
> 
> This list is to contain discussion of speculative language ideas for
> Python for possible inclusion into the language. If an idea gains traction
> it can then be discussed and honed to the point of becoming a solid
> proposal to put to python-dev as appropriate.
> 
>
> Relative to the above I believe that far too many proposals are for
> trivial ideas, mainly targetted at the stdlib, that would be better suited
> to the main python list.
>
> As for gaining traction, it's often the complete opposite, flogging a dead
> horse is an understatement for some threads.  Gently putting the OP down
> with a firm but polite "it ain't gonna happen" would save a lot of time all
> around.
>
> Just my £0.02p worth.
>

Agreed. It's also probably easier to just ignore an obviously bad or poorly
thought-out idea than to try to engage the OP in lengthy explanations of
why that is so. After all there's a huge amount of subjectivity -- we won't
change our minds, but it takes forever to explain to someone who's new to
Python core development.

-- 
--Guido van Rossum (python.org/~guido)
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Antoine Pitrou]

On Tue, 7 Jul 2015 14:14:49 +0200
Guido van Rossum  wrote:
> FYI, do we have any indication that Raymond even read the comment? IIRC he
> doesn't regularly read python-dev. I also don't think code review comments
> ought to go to python-dev; the commiters list would seem more appropriate?

Well, do we have to keep a record of what ML each developer reads? Or
is post-commit review to be faced each times with dilemmas such as the
present: """does this core developer really read that mailing-list? should I
email him/her privately, or is that too intrusive? what about writing
to that other mailing-list? if they don't answer, did they at least see
the message amongst the other threads?"""

(this is a nice thing with pre-commit review: you can usually be sure
the developer will read your comments, unless there's something
seriously wrong with the setup)

> (Though it looks like python-checkins is configured to direct replies to
> python-dev. Maybe we need to revisit that?)

My own preference would be to keep it that way. If python-dev becomes
annoying to read, then probably python-checkins isn't very exciting
either ;-)
(just MHO, of course)

Regards

Antoine.
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Guido van Rossum]

A simple way to address this would have been to CC Raymond on the issue.
But the reply-to header probably makes that hard. Agreed that post-commit
reviews don't really scale to our size. It's hard to teach old dogs new
tricks though. I now realize that my main point, however, was that Raymond
and Serhiy might have sorted this out offline already without either of
them bothering to CC python-dev on the fix, so perhaps the discussion about
our broken process might well have been premature. Certainly I don't think
automatically rolling back commits is something we should start to do
without a bigger overhaul of our process -- which takes time and may well
already be underway.

On Tue, Jul 7, 2015 at 2:25 PM, Antoine Pitrou  wrote:

> On Tue, 7 Jul 2015 14:14:49 +0200
> Guido van Rossum  wrote:
> > FYI, do we have any indication that Raymond even read the comment? IIRC
> he
> > doesn't regularly read python-dev. I also don't think code review
> comments
> > ought to go to python-dev; the commiters list would seem more
> appropriate?
>
> Well, do we have to keep a record of what ML each developer reads? Or
> is post-commit review to be faced each times with dilemmas such as the
> present: """does this core developer really read that mailing-list? should
> I
> email him/her privately, or is that too intrusive? what about writing
> to that other mailing-list? if they don't answer, did they at least see
> the message amongst the other threads?"""
>
> (this is a nice thing with pre-commit review: you can usually be sure
> the developer will read your comments, unless there's something
> seriously wrong with the setup)
>
> > (Though it looks like python-checkins is configured to direct replies to
> > python-dev. Maybe we need to revisit that?)
>
> My own preference would be to keep it that way. If python-dev becomes
> annoying to read, then probably python-checkins isn't very exciting
> either ;-)
> (just MHO, of course)
>
> Regards
>
> Antoine.
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Maciej Fijalkowski]

On Tue, Jul 7, 2015 at 2:14 PM, Guido van Rossum  wrote:
> FYI, do we have any indication that Raymond even read the comment? IIRC he
> doesn't regularly read python-dev. I also don't think code review comments
> ought to go to python-dev; the commiters list would seem more appropriate?
> (Though it looks like python-checkins is configured to direct replies to
> python-dev. Maybe we need to revisit that?)

I kind of thought that python does pre-commit reviews (at least seems
to apply to most people), so in case someone is completely exempt from
that, maybe he should read python-dev or wherever the reply is set to?
That also does not explain why a crashing commit has not been
reverted.
___
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] Importance of "async" keyword

[Nick Coghlan]

On 7 July 2015 at 06:08, Sven R. Kunze  wrote:
> I would like to rewrite/amend it to work asynchronously with minimal effort
> such as:
>
> def business_new():
> content1 = fork open('big.file').read()  # wraps up the calls into
> awaitables
> content2 = fork open('huge.file').read() # and put them into the event
> loop
> return content1 + content2   # variables are used => await
> evaluation
>
> I might have missed something but I think you get my point.

No, you haven't missed anything, but I think the convenience APIs
we're discussing in this thread are what you need, rather than
async/await.

Specifically, your main application would remain synchronous, but the
event loop could be used to run selected operations in a background
thread:

def business_new():
future1 = asyncio.call_async(open('big.file').read)
future2 = asyncio.call_async(open('huge.file').read)
content1 = asyncio.wait_for_result(future1)
content2 = asyncio.wait_for_result(future2)
return content1 + content2

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Guido van Rossum]

It's more complicated than that.

FWIW a crash reproducer doesn't mean it's a common or likely crash.
Apparently no unittests broke. Also, please give Raymond time to wake up
(I'm in Europe, but Raymond is probably recovering from a three-day weekend
in the US).

On Tue, Jul 7, 2015 at 2:32 PM, Maciej Fijalkowski  wrote:

> On Tue, Jul 7, 2015 at 2:14 PM, Guido van Rossum  wrote:
> > FYI, do we have any indication that Raymond even read the comment? IIRC
> he
> > doesn't regularly read python-dev. I also don't think code review
> comments
> > ought to go to python-dev; the commiters list would seem more
> appropriate?
> > (Though it looks like python-checkins is configured to direct replies to
> > python-dev. Maybe we need to revisit that?)
>
> I kind of thought that python does pre-commit reviews (at least seems
> to apply to most people), so in case someone is completely exempt from
> that, maybe he should read python-dev or wherever the reply is set to?
> That also does not explain why a crashing commit has not been
> reverted.
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] What's New editing

[Nick Coghlan]

On 7 July 2015 at 01:38, David Mertz  wrote:
> Hi Folks,
>
> I hereby volunteer to write "What's New for Python 3.5?" if folks on
> python-dev are fine with me taking the job (i.e. I ran it by Travis, my boss
> at Continuum, and he's happy to allow me to do that work within my salaried
> hours... so having time isn't a problem).

Huzzah - thanks for offering, and thanks Travis/Continuum for granting
you the paid time :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Python-Dev] Review/CI infrastructure status (was Re: cpython: Tighten-up code in the set iterator to use an entry pointer rather than)

[Nick Coghlan]

On 7 July 2015 at 22:31, Guido van Rossum  wrote:
> A simple way to address this would have been to CC Raymond on the issue. But
> the reply-to header probably makes that hard. Agreed that post-commit
> reviews don't really scale to our size. It's hard to teach old dogs new
> tricks though. I now realize that my main point, however, was that Raymond
> and Serhiy might have sorted this out offline already without either of them
> bothering to CC python-dev on the fix, so perhaps the discussion about our
> broken process might well have been premature. Certainly I don't think
> automatically rolling back commits is something we should start to do
> without a bigger overhaul of our process -- which takes time and may well
> already be underway.

Only sort of - the three principals (myself, Donald Stufft, Brett
Cannon) have all had quite a few other things on our plates in the
last few months, so the forge.python.org proposals haven't progressed
beyond where they were at the Language Summit in April :(

It did occur to me that we could potentially get the moral equivalent
of a "gated trunk" *without* disrupting current commit workflows by
introducing a separate "cpython-ci" repo that was only updated after
the BuildBots gave a commit a clean bill of health. That would also
provide a better basis for other folks to do CI against, since they'd
know the commit was at least passing our own test suite before they
tried it.

It would mean yet another piece of workflow infrastructure to set up
and maintain, though :(

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Serhiy Storchaka]

On 07.07.15 15:32, Maciej Fijalkowski wrote:

I kind of thought that python does pre-commit reviews (at least seems
to apply to most people), so in case someone is completely exempt from
that, maybe he should read python-dev or wherever the reply is set to?
That also does not explain why a crashing commit has not been
reverted.


There is no haste. Only developed branch is affected and we have enough 
time to fix it. No buildbots is broken. Just rolling back this changeset 
can be impossible because Raymond committed other changes after it. I'm 
not sure that this changeset is culprit, it can be previous one. Raymond 
is the most experienced person in this file, and writing good fix that 
conform to Raymond's view by other person can take more time than the 
time that is needed to Raymond to awake and read this topic.


___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Serhiy Storchaka]

On 07.07.15 15:14, Guido van Rossum wrote:

FYI, do we have any indication that Raymond even read the comment? IIRC
he doesn't regularly read python-dev. I also don't think code review
comments ought to go to python-dev; the commiters list would seem more
appropriate? (Though it looks like python-checkins is configured to
direct replies to python-dev. Maybe we need to revisit that?)


I would have commented on the tracker, if any issue number was 
corresponded to this commit. I was not sure there is real crash until 
trying to write a reproducer, the code just looked suspicious to me.


Another suspicious commit was changeset 637e197be547 [1]. Looks as 
Raymond missed my comment on Python-Dev [2]. I still have no reproducer 
for this particular possible crash, found example crashes also with 3.5 
[3], this can be a consequence of other change.


[1] https://hg.python.org/cpython/rev/637e197be547
[2] http://comments.gmane.org/gmane.comp.python.cvs/110808
[3] https://bugs.python.org/issue24583


___
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] What's New editing

[Barry Warsaw]

On Jul 06, 2015, at 09:32 PM, Raymond Hettinger wrote:

>FWIW, it took me 100+ hours.   Doing this right is a non-trivial undertaking
>(in modern times, there are an astonishing number of changes per release).
>That said, it is rewarding work that makes a difference.

Indeed.  During distro Python version transitions (including the 3.5 one I'm
currently working on), verifying intentional changes via NEWS entries has been
really critical.

I'll point again to https://wiki.python.org/moin/PortingToPy3k/34to35 which
I'm using to document the changes that I've seen break actual packages.

Thanks for volunteering to do this work David, and for doing it in the past
other-David!

Cheers,
-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] PEP 493: Redistributor guidance for Python 2.7 HTTPS

[s.krah]

Erik Bray  wrote:

> On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou  
wrote: 
>> On Mon, 6 Jul 2015 14:22:46 +1000 
>> Nick Coghlan  wrote: 
>>> 
>>> The main change from the last version discussed on python-ideas 
>> 
>> Was it discussed there? That list has become totally useless, I've 
>> stopped following it. 
 
> Considering that a useful discussion of a useful PEP occurred there 
> (not to mention other occasionally useful discussions) I'd say that 
> such a value judgment is not only unnecessary but also inaccurate. 
> That's fine if it's uninteresting to you and you don't want to follow 
> it, but let's please avoid judgments on entire mailing lists and, by 
> extension, the people holding conversations there. 

In an informal setting, exaggeration is used widely in continental Europe.
I found the remark funny and was glad to hear that I'm not the only one
who has problems with python-ideas.


Stefan Krah


___
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] PEP 493: Redistributor guidance for Python 2.7 HTTPS

[Nick Coghlan]

On 7 July 2015 at 21:49, s.krah  wrote:
>
>
> Erik Bray  wrote:
>
>> On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou 
>> wrote:
>>> On Mon, 6 Jul 2015 14:22:46 +1000
>>> Nick Coghlan  wrote:

 The main change from the last version discussed on python-ideas
>>>
>>> Was it discussed there? That list has become totally useless, I've
>>> stopped following it.
>
>> Considering that a useful discussion of a useful PEP occurred there
>> (not to mention other occasionally useful discussions) I'd say that
>> such a value judgment is not only unnecessary but also inaccurate.
>> That's fine if it's uninteresting to you and you don't want to follow
>> it, but let's please avoid judgments on entire mailing lists and, by
>> extension, the people holding conversations there.
>
> In an informal setting, exaggeration is used widely in continental Europe.
> I found the remark funny and was glad to hear that I'm not the only one
> who has problems with python-ideas.

Folks are free to make all the jokes they want about python-ideas over
drinks at a conference, or when bouncing their heads off their desks
at how far off the rails a particular thread has gone - we wouldn't be
human if we didn't need to vent our frustrations sometimes.

That doesn't make it OK to vent those frustrations *here*. Here,
python-ideas needs to be accepted as a useful component of the
development process - it's the location where more freewheeling "this
*might* be a good idea" design discussions can happen with input from
experienced core developers and other community members without
bothering the folks that aren't interested in those kinds of
conversations, before python-dev and the issue tracker come into play
to provide more ruthless weeding out of the bad ideas. An awful lot of
what we discuss on python-ideas will turn out to be a bad idea, just
be sheer weight of probability. However, even weeding out the bad
ideas is a useful exercise in refining our collective understanding of
what "good" looks like (I know I've learned a *lot* from the many
occasions where Guido or someone else has persuaded me that one of my
ideas wasn't as good as I originally thought it was).

It's OK if folks aren't interested in participating in the noisy early
stages of that process - that's why the activity was long since moved
out to a dedicated list. It's not OK to make the jump from "I don't
consider participating in that to be the best possible use of my own
time" to "it isn't worth doing".

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Maciej Fijalkowski]

On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka  wrote:
> On 07.07.15 15:32, Maciej Fijalkowski wrote:
>>
>> I kind of thought that python does pre-commit reviews (at least seems
>> to apply to most people), so in case someone is completely exempt from
>> that, maybe he should read python-dev or wherever the reply is set to?
>> That also does not explain why a crashing commit has not been
>> reverted.
>
>
> There is no haste. Only developed branch is affected and we have enough time
> to fix it. No buildbots is broken. Just rolling back this changeset can be
> impossible because Raymond committed other changes after it. I'm not sure
> that this changeset is culprit, it can be previous one. Raymond is the most
> experienced person in this file, and writing good fix that conform to
> Raymond's view by other person can take more time than the time that is
> needed to Raymond to awake and read this topic.

Then maybe a good option would be to add the crasher to the test
suite, so the buildbots *are* actually broken showing the problem
exists?
___
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] PEP 493: Redistributor guidance for Python 2.7 HTTPS

[Antoine Pitrou]

On Wed, 8 Jul 2015 00:10:09 +1000
Nick Coghlan  wrote:
> 
> It's OK if folks aren't interested in participating in the noisy early
> stages of that process - that's why the activity was long since moved
> out to a dedicated list. It's not OK to make the jump from "I don't
> consider participating in that to be the best possible use of my own
> time" to "it isn't worth doing".

Ok. As Stefan points out, exageration is a common rhetoric device - for
the better or (mostly perhaps :-)) for the worse. Sorry if that
*actually* offended some people.

In this case, though, I was a bit miffed since I didn't notice that
PEP appearing on python-ideas (or perhaps I already forget discussing
it?), which made me frustrated that *perhaps* with less pointless
drifting I would have seen it. Being one of the principal maintainers
of the ssl module I was definitely interested on giving my opinion.

Whether the time required to properly follow python-ideas is a
productive involvement for the average core dev is another question.
The problem I see with python-ideas is that it may select on free time
more than on actual, concrete contribution...

(note that python-list has a similar problem with some of its old-timers
and regular ranters; the difference is that python-list has a ready
alternative in StackOverflow, with perhaps higher-quality answers...
it's less and less relevant in the grand scheme of things)

Regards

Antoine.


___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Serhiy Storchaka]

On 07.07.15 17:33, Maciej Fijalkowski wrote:

On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka  wrote:

There is no haste. Only developed branch is affected and we have enough time
to fix it. No buildbots is broken.


Then maybe a good option would be to add the crasher to the test
suite, so the buildbots *are* actually broken showing the problem
exists?


This will make harder to notice (and fix!) other regressions.


___
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] PEP 493: Redistributor guidance for Python 2.7 HTTPS

[s.krah]

Nick Coghlan  wrote:

> It's OK if folks aren't interested in participating in the noisy early 
> stages of that process - that's why the activity was long since moved 
> out to a dedicated list. It's not OK to make the jump from "I don't 
> consider participating in that to be the best possible use of my own 
> time" to "it isn't worth doing".

Well yes, to me it was an exaggeration which a German or French person
would interpret as "not the best possible use of one's time". ;)


Leaving phrasing and timing aside (Antoine has already explained himself),
how are people who don't go to Pycons supposed to know the opinion of
other core-devs if no one ever voices a complaint on a mailing list?


Stefan Krah








 



___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Brett Cannon]

The overhaul of the development process is still on hold while I deal with
trying to get settled in new city and starting a new job next week (writing
this on a tablet because I don't even have a computer ATM). My hope is
everything will settle down enough that I can pick up the work on trying to
update our development process starting in August.

On Tue, Jul 7, 2015, 05:32 Guido van Rossum  wrote:

> A simple way to address this would have been to CC Raymond on the issue.
> But the reply-to header probably makes that hard. Agreed that post-commit
> reviews don't really scale to our size. It's hard to teach old dogs new
> tricks though. I now realize that my main point, however, was that Raymond
> and Serhiy might have sorted this out offline already without either of
> them bothering to CC python-dev on the fix, so perhaps the discussion about
> our broken process might well have been premature. Certainly I don't think
> automatically rolling back commits is something we should start to do
> without a bigger overhaul of our process -- which takes time and may well
> already be underway.
>
> On Tue, Jul 7, 2015 at 2:25 PM, Antoine Pitrou 
> wrote:
>
>> On Tue, 7 Jul 2015 14:14:49 +0200
>> Guido van Rossum  wrote:
>> > FYI, do we have any indication that Raymond even read the comment? IIRC
>> he
>> > doesn't regularly read python-dev. I also don't think code review
>> comments
>> > ought to go to python-dev; the commiters list would seem more
>> appropriate?
>>
>> Well, do we have to keep a record of what ML each developer reads? Or
>> is post-commit review to be faced each times with dilemmas such as the
>> present: """does this core developer really read that mailing-list?
>> should I
>> email him/her privately, or is that too intrusive? what about writing
>> to that other mailing-list? if they don't answer, did they at least see
>> the message amongst the other threads?"""
>>
>> (this is a nice thing with pre-commit review: you can usually be sure
>> the developer will read your comments, unless there's something
>> seriously wrong with the setup)
>>
>> > (Though it looks like python-checkins is configured to direct replies to
>> > python-dev. Maybe we need to revisit that?)
>>
>> My own preference would be to keep it that way. If python-dev becomes
>> annoying to read, then probably python-checkins isn't very exciting
>> either ;-)
>> (just MHO, of course)
>>
>
>> Regards
>>
>> Antoine.
>> ___
>> 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/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>  ___
> 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/brett%40python.org
>
___
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

[Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

[Barry Warsaw]

Larry and others,

I'd like to bring your attention to issue #15014.  This issue added arbitrary
auth methods to smtplib, which is a good thing.  Implicitly though, a
regression was introduced w.r.t. RFC 4954's optional initial-response for the
AUTH command, for authentication methods that support it.

An example is AUTH PLAIN, which does not require a challenge.  It's possible
that SMTP servers are not prepared to handle challenge/responses for
authentication methods that support initial-response, and regressions have
been seen in the wild while testing against Python 3.5.  In Python 3.4, AUTH
PLAIN included an initial-response.

After discussion on the issue, RDM and I agreed on a refinement to the
authobject() protocol, such that they would be called first with
challenge=None.  If the auth method implemented by the authobject() supports
an initial response, it can return the bytes to be encoded and sent along with
AUTH .  If it returns None, then a challenge is required, and the
normal SMTP challenge/response can proceed.

A minor complication is that clients using smtplib might want to force
challenge/response instead of initial-response even for authentication methods
that support the latter.  There are various reasons for this, including test
suites (such as Python's own test_smtplib.py).

So I added an optional keyword argument called *initial_response_ok* to
SMTP.auth() and SMTP.login(), with a default value of True.  Thus for
authentication methods that support it, smtplib will by default send an
initial-response, but it can easily be overridden.  Defaulting to True
restores compatibility with Python 3.4.

Technically, this is a new feature even though it addresses a regression in
Python 3.5.  Assuming a positive response by RDM or anybody else who would
like to review the patch, I'd like to get a beta release exemption for the
change.

Patch on the issue includes implementation, test, and docs.

Cheers,
-Barry


pgpmv5dAdlx7Z.pgp
Description: OpenPGP digital signature
___
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] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

[Terry Reedy]

On 7/7/2015 1:52 PM, Barry Warsaw wrote:

Larry and others,

I'd like to bring your attention to issue #15014.  This issue added arbitrary
auth methods to smtplib, which is a good thing.  Implicitly though, a
regression was introduced w.r.t. RFC 4954's optional initial-response for the
AUTH command, for authentication methods that support it.

An example is AUTH PLAIN, which does not require a challenge.  It's possible
that SMTP servers are not prepared to handle challenge/responses for
authentication methods that support initial-response, and regressions have
been seen in the wild while testing against Python 3.5.  In Python 3.4, AUTH
PLAIN included an initial-response.

After discussion on the issue, RDM and I agreed on a refinement to the
authobject() protocol, such that they would be called first with
challenge=None.  If the auth method implemented by the authobject() supports
an initial response, it can return the bytes to be encoded and sent along with
AUTH .  If it returns None, then a challenge is required, and the
normal SMTP challenge/response can proceed.

A minor complication is that clients using smtplib might want to force
challenge/response instead of initial-response even for authentication methods
that support the latter.  There are various reasons for this, including test
suites (such as Python's own test_smtplib.py).

So I added an optional keyword argument called *initial_response_ok* to
SMTP.auth() and SMTP.login(), with a default value of True.  Thus for
authentication methods that support it, smtplib will by default send an
initial-response, but it can easily be overridden.  Defaulting to True
restores compatibility with Python 3.4.

Technically, this is a new feature


From what you said above, this is not an independent new feature, in 
that you would not have proposed it without the prior patch, but rather, 
in effect, an amendment to the original patch, to make the combined 
effect what the original patch should have been.



even though it addresses a regression in Python 3.5.


The main purpose of releases after feature freeze is to text and fix 
bugs and regressions in added features. The alternative fix would be to 
revert enough of the additions to avoid the regression, and defer such 
to 3.6.


To me, the main question is whether you are sure that your proposal is 
the right fix, or whether you might reasonably do something different 
(with the new arguments) if changes were reverted for the present and 
you two took more time to think about the problem.  My impression is 
that the latter is unlikely because the problem is inherent in the new 
auth methods.


--
Terry Jan Reedy

___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Ethan Furman]

On 07/07/2015 08:15 AM, Serhiy Storchaka wrote:

On 07.07.15 17:33, Maciej Fijalkowski wrote:

On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka wrote:



There is no haste. Only developed branch is affected and we have enough time
to fix it. No buildbots is broken.


Then maybe a good option would be to add the crasher to the test
suite, so the buildbots *are* actually broken showing the problem
exists?


This will make harder to notice (and fix!) other regressions.


I don't understand what you are trying to say.  If a bug is worth fixing, it's 
worth having a test so we don't have to fix it again in the future.

--
~Ethan~
___
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] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

[Barry Warsaw]

On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote:

>To me, the main question is whether you are sure that your proposal is the
>right fix, or whether you might reasonably do something different (with the
>new arguments) if changes were reverted for the present and you two took more
>time to think about the problem.  My impression is that the latter is
>unlikely because the problem is inherent in the new auth methods.

I generally like the approach that initially added with issue #15014.  This is
a subtle corner of the RFC and an unexpected regression from Python 3.4.

Cheers,
-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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Zachary Ware]

On Tue, Jul 7, 2015 at 2:03 PM, Ethan Furman  wrote:
> On 07/07/2015 08:15 AM, Serhiy Storchaka wrote:
>> This will make harder to notice (and fix!) other regressions.
>
> I don't understand what you are trying to say.  If a bug is worth fixing,
> it's worth having a test so we don't have to fix it again in the future.

I believe Serhiy's point is that there's no need to commit the test
before the fix, so that the buildbots won't be unnecessarily red until
the fix is committed.  The fix should, of course, include a test.

-- 
Zach
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Zachary Ware]

On Tue, Jul 7, 2015 at 3:16 PM, Brett Cannon  wrote:
> The test could be marked as an expected failure in the interim somitnisnt
> forgotten.

True, but in this case things would be a bit more difficult since the
testcase segfaults rather than just throwing an exception.

-- 
Zach
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Brett Cannon]

 On Tue, Jul 7, 2015, 12:17 Zachary Ware 
wrote:

On Tue, Jul 7, 2015 at 2:03 PM, Ethan Furman  wrote:
> On 07/07/2015 08:15 AM, Serhiy Storchaka wrote:
>> This will make harder to notice (and fix!) other regressions.
>
> I don't understand what you are trying to say.  If a bug is worth fixing,
> it's worth having a test so we don't have to fix it again in the future.

I believe Serhiy's point is that there's no need to commit the test
before the fix, so that the buildbots won't be unnecessarily red until
the fix is committed.  The fix should, of course, include a test.


The test could be marked as an expected failure in the interim somitnisnt
forgotten.

-Brett


--
Zach
___
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/brett%40python.org
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Skip Montanaro]

Just thinking out loud here, but could you devote a single buildbot to the
cause? It would only ever try to build from the "crasher" branch. When a
crash is discovered like this one, you can do whatever is necessary to
merge the code and a crasher test case to that branch. It would then turn
red. Might a segfault provide enough output to debug?

Skip
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

[Raymond Hettinger]

> On Jul 7, 2015, at 12:42 AM, Serhiy Storchaka  wrote:
> 
> What if so->table was reallocated during the iteration, but so->used is left 
> the same? This change looks unsafe to me.


FWIW, the mutation detection code in the iterator logic has always been 
vulnerable to being fooled the way you describe. The difference this time is 
that it results in a crash rather than a wrong answer.  I've rolled back the 
commit so we are back to where we've always been.


Raymond


P.S.  I don't think python-dev post was necessary or helpful (and I still 
haven't had a chance to read the whole thread).  It would have been sufficient 
to assign the tracker entry back to me.
___
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