Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 01:13:10PM +0200, Victor Stinner wrote: > Hi, > > Last weeks, I made researchs on how to get stable and reliable > benchmarks, especially for the corner case of microbenchmarks. The > first result is a serie of article, here are the first three: Thank you for this! I am

[Python-Dev] Stop using timeit, use perf.timeit!

Hi, Last weeks, I made researchs on how to get stable and reliable benchmarks, especially for the corner case of microbenchmarks. The first result is a serie of article, here are the first three: https://haypo.github.io/journey-to-stable-benchmark-system.html

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan wrote: > I'm guessing Ethan is suggesting defining it as: > > __definition_order__ = tuple(ns["__definition_order__"]) > > When the attribute is present in the method body. Ah. I'd rather stick to "consenting adults" in the

Re: [Python-Dev] PEP 468

On Thu, Jun 9, 2016 at 12:41 PM, wrote: > Is there any further thoughts on including this in 3.6? I don't have any plans and I don't know of anyone willing to champion the PEP for 3.6. Note that the implementation itself shouldn't take very long. > Similar to the > recent

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On 6/10/2016 9:20 AM, Steven D'Aprano wrote: On Fri, Jun 10, 2016 at 01:13:10PM +0200, Victor Stinner wrote: Hi, Last weeks, I made researchs on how to get stable and reliable benchmarks, especially for the corner case of microbenchmarks. The first result is a serie of article, here are the

Re: [Python-Dev] PEP 468

I would be super excited for this feature, so if there's a reasonable chance of it being picked up I don't mind doing the implementation work. On Fri, Jun 10, 2016, at 11:54 AM, Eric Snow wrote: > On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote: > > As stated by Guido (and

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On 6/10/2016 11:07 AM, Victor Stinner wrote: I started to work on visualisation. IMHO it helps to understand the problem. Let's create a large dataset: 500 samples (100 processes x 5 samples): As I finished by response to Steven, I was thinking you should do something like this to get real

Re: [Python-Dev] PEP 468

On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote: > As stated by Guido (and pointed out in the PEP): > > Making **kwds ordered is still open, but requires careful design and > implementation to avoid slowing down function calls that don't benefit. > > The PEP has not been

Re: [Python-Dev] Stop using timeit, use perf.timeit!

2016-06-10 17:09 GMT+02:00 Paul Moore : > Also, the way people commonly use > micro-benchmarks ("hey, look, this way of writing the expression goes > faster than that way") doesn't really address questions like "is the > difference statistically significant". If you use the

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

I somehow feel compelled to clarify that (perhaps unlike Larry) my concern is not the strict rules of backwards compatibility (if that was the case I would have objected to changing this in 3.5.2). I just don't like the potentially blocking behavior, and experts' opinions seem to widely vary on

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On Thu, 9 Jun 2016 at 19:53 Mark Lawrence via Python-Dev < python-dev@python.org> wrote: > On 10/06/2016 00:43, Brett Cannon wrote: > > > > That's not what I'm saying at all (nor what I think Nick is saying); > > more tooling to ease the transition is always welcomed. The point we are > > trying

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Guido van Rossum wrote: > I just don't like the potentially blocking behavior, and experts' opinions > seem to widely vary on how insecure the fallback bits really are, how > likely you are to find yourself in that situation, and how probable an > exploit would be. This is not

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Sebastian Krause > Sent: Friday, June 10, 2016 1:01 PM > To: python-dev@python.org > Subject: Re: [Python-Dev] BDFL ruling request: should we block forever > waiting for

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 05:07:18PM +0200, Victor Stinner wrote: > I started to work on visualisation. IMHO it helps to understand the problem. > > Let's create a large dataset: 500 samples (100 processes x 5 samples): > --- > $ python3 telco.py --json-file=telco.json -p 100 -n 5 > --- > >

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, 10 Jun 2016 at 10:11 Steven D'Aprano wrote: > On Fri, Jun 10, 2016 at 05:07:18PM +0200, Victor Stinner wrote: > > I started to work on visualisation. IMHO it helps to understand the > problem. > > > > Let's create a large dataset: 500 samples (100 processes x 5

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On 6/10/2016 10:49 AM, Nick Coghlan wrote: What Brett said is mostly accurate for me, except with one slight caveat: I've been explicitly trying to nudge you towards making the *existing tools better*, rather than introducing new tools. With modernize and futurize we have a fairly clear

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On 10 June 2016 at 09:42, Eric Snow wrote: > On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan wrote: >> That restriction would be comparable to what we do with __slots__ today: >> >> >>> class C: >> ... __slots__ = 1 >> ... >>

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

This is fairly academic, since I do not anticipate needing to do this myself, but I have a specific question. I'll assume that Python 3.5.2 will go back to the 2.6-3.4 behavior in which os.urandom() never blocks on Linux. Moreover, I understand that the case where the insecure bits might be

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 10, 2016, at 2:55 PM, Donald Stufft wrote: > > So really, out of the recommended solutions you really only have find a way > to interface with the getrandom() function, or just consume /dev/urandom and > hope it’s been initialized. I’d note, this is one of the

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On 9 June 2016 at 16:43, Brett Cannon wrote: > That's not what I'm saying at all (nor what I think Nick is saying); more > tooling to ease the transition is always welcomed. What Brett said is mostly accurate for me, except with one slight caveat: I've been explicitly trying to

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On 10 June 2016 at 07:09, Cody Piersall wrote: >> One problem is that the str literals should be bytes >> literals. Comparison with None needs to be avoided. >> >> With Python 2 code runs successfully. With Python 3 the code >> crashes with a traceback. With my

Re: [Python-Dev] Stop using timeit, use perf.timeit!

Hi all, I wrote a blog post about this. http://blog.kevmod.com/2016/06/benchmarking-minimum-vs-average/ We can rule out any argument that one (minimum or average) is strictly better than the other, since there are cases that make either one better. It comes down to our expectation of the

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, Jun 10, 2016 at 11:29 AM, David Mertz wrote: > This is fairly academic, since I do not anticipate needing to do this > myself, but I have a specific question. I'll assume that Python 3.5.2 will > go back to the 2.6-3.4 behavior in which os.urandom() never blocks on

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 10, 2016, at 3:05 PM, David Mertz wrote: > > OK. My understanding is that Guido ruled out introducing an os.getrandom() > API in 3.5.2. But would you be happy if that interface is added to 3.6? > > It feels to me like the correct spelling in 3.6 should probably be

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On 10 June 2016 at 11:00, Neil Schemenauer wrote: > On 6/10/2016 10:49 AM, Nick Coghlan wrote: >> More -3 warnings in Python 2.7 are definitely welcome (since those can >> pick up runtime behaviors that the static analysers miss), and if >> there are things the existing code

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 10, 2016, at 2:29 PM, David Mertz wrote: > > If I *were* someone who needed to write a Linux system initialization script > using Python 3.5.2, what would the code look like. I think for this use > case, requiring something with a little bit of "code smell" is fine,

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 6:13 AM, Victor Stinner wrote: The second result is a new perf module which includes all "tricks" > discovered in my research: compute average and standard deviation, > spawn multiple worker child processes, automatically calibrate the > number

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Ok, so you’re looking for how would you replicate the blocking behavior of os.urandom that exists in 3.5.0 and 3.5.1? In that case, it’s hard. I don’t think linux provides any way to externally determine if /dev/urandom has been initialized or not. Probably the easiest thing to do would be to

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

OK. My understanding is that Guido ruled out introducing an os.getrandom() API in 3.5.2. But would you be happy if that interface is added to 3.6? It feels to me like the correct spelling in 3.6 should probably be secrets.getrandom() or something related to that. On Fri, Jun 10, 2016 at 11:55

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 9 June 2016 at 19:21, Barry Warsaw wrote: > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > >>Deprecation of current "zero-initialised sequence" behaviour >> >> >>Currently, the ``bytes`` and ``bytearray``

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

My hypothetical is "Ensure good random bits (on Python 3.5.2 and Linux), and block rather than allow bad bits." I'm not quite sure I understand all of your question, Donald. On Python 3.4—and by BDFL declaration on 3.5.2—os.urandom() *will not* block, although it might on 3.5.1. On Fri, Jun 10,

Re: [Python-Dev] PEP 468

Eric, have you any work in progress on compact dicts? On Fri, Jun 10, 2016 at 12:54 PM, Eric Snow wrote: > On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote: >> As stated by Guido (and pointed out in the PEP): >> >> Making **kwds ordered is still

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[David Mertz] > OK. My understanding is that Guido ruled out introducing an os.getrandom() > API in 3.5.2. But would you be happy if that interface is added to 3.6? > > It feels to me like the correct spelling in 3.6 should probably be > secrets.getrandom() or something related to that.

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Ooops thinko there! Of course `secrets` won't exist in 3.5.1, so that's a 3.6 matter instead. On Fri, Jun 10, 2016 at 12:29 PM, David Mertz wrote: > I believe that secrets.token_bytes() and secrets.SystemRandom() should be > changed even for 3.5.1 to use getrandom() on

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/10/2016 12:29 PM, David Mertz wrote: I believe that secrets.token_bytes() and secrets.SystemRandom() should be changed even for 3.5.1 to use getrandom() on Linux. Surely you meant 3.5.2? 3.5.1 shipped last December. //arry/ ___ Python-Dev

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, Jun 10, 2016 at 12:55 PM, Larry Hastings wrote: > On 06/10/2016 12:29 PM, David Mertz wrote: > > I believe that secrets.token_bytes() and secrets.SystemRandom() should be > changed even for 3.5.1 to use getrandom() on Linux. > > Surely you meant 3.5.2? 3.5.1 shipped

Re: [Python-Dev] PEP 468

On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee wrote: > Eric, have you any work in progress on compact dicts? Nope. I presume you are talking the proposal Raymond made a while back. -eric ___ Python-Dev mailing list

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

I will observe that feelings have gotten a little heated, so without making any suggestions to how the python-dev community should decide things, let me offer some observations that might perhaps shed a little light, and perhaps dispell a little bit of the heat. As someone who has been working in

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On 11 June 2016 at 04:09, Victor Stinner wrote: ..> We should design a CLI command to do timeit+compare at once. http://judge.readthedocs.io/en/latest/ might offer some inspiration There's also ministat -

Re: [Python-Dev] Stop using timeit, use perf.timeit!

2016-06-10 20:47 GMT+02:00 Meador Inge : > Apologies in advance if this is answered in one of the links you posted, but > out of curiosity was geometric mean considered? > > In the compiler world this is a very common way of aggregating performance > results. FYI I chose to

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

I believe that secrets.token_bytes() and secrets.SystemRandom() should be changed even for 3.5.1 to use getrandom() on Linux. Thanks for fixing my spelling of the secrets API, Donald. :-) On Fri, Jun 10, 2016 at 12:17 PM, Donald Stufft wrote: > > On Jun 10, 2016, at 3:05 PM,

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, 10 Jun 2016 at 12:20 Donald Stufft wrote: > > On Jun 10, 2016, at 3:05 PM, David Mertz wrote: > > OK. My understanding is that Guido ruled out introducing an > os.getrandom() API in 3.5.2. But would you be happy if that interface is > added to 3.6? >

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Jun 10, 2016, at 12:05 PM, David Mertz wrote: >OK. My understanding is that Guido ruled out introducing an os.getrandom() >API in 3.5.2. But would you be happy if that interface is added to 3.6? I would. >It feels to me like the correct spelling in 3.6 should probably be

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On 6/10/2016 12:09 PM, Victor Stinner wrote: 2016-06-10 17:09 GMT+02:00 Paul Moore : Also, the way people commonly use micro-benchmarks ("hey, look, this way of writing the expression goes faster than that way") doesn't really address questions like "is the difference

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/10/2016 12:54 PM, Theodore Ts'o wrote: So even on Python pre-3.5.0, realistically speaking, the "weakness" of os.random would only be an issue (a) if it is run within the first few seconds of boot, and (b) os.random is used to directly generate a long-term cryptographic secret. If you

Re: [Python-Dev] PEP 468

I am. I was just wondering if there was an in-progress effort I should be looking at, because I am interested in extensions to it. P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Random832] > So, I have a question. If this "weakness" in /dev/urandom is so > unimportant to 99% of situations... why isn't there a flag that can be > passed to getrandom() to allow the same behavior? Isn't that precisely the purpose of the GRND_NONBLOCK flag?

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 10.06.2016 21:17, Donald Stufft wrote: On Jun 10, 2016, at 3:05 PM, David Mertz > wrote: OK. My understanding is that Guido ruled out introducing an os.getrandom() API in 3.5.2. But would you be happy if that interface is added to 3.6? It

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 10, 2016, at 3:33 PM, Brett Cannon wrote: > > If that's the case then we should file a bug so we are sure this is the case > and we need to decouple the secrets documentation from random so that they > can operate independently with secrets always doing whatever is

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/10/2016 11:55 AM, Donald Stufft wrote: Ok, so you’re looking for how would you replicate the blocking behavior of os.urandom that exists in 3.5.0 and 3.5.1? In that case, it’s hard. I don’t think linux provides any way to externally determine if /dev/urandom has been initialized or not.

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Fri, Jun 10, 2016 at 11:29 AM, Nick Coghlan wrote: > On 10 June 2016 at 09:42, Eric Snow wrote: >> On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan wrote: >>> That restriction would be comparable to what we do with __slots__

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

David Mertz wrote: > It feels to me like the correct spelling in 3.6 should probably be > secrets.getrandom() or something related to that. Since there already is a secrets.randbits(k), I would keep the naming similar and suggest something like: secrets.randbytes(k, *,

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Tim Peters wrote: > secrets.token_bytes() is already the way to spell "get a string of > messed-up bytes", and that's the dead obvious (according to me) place > to add the potentially blocking implementation. I honestly didn't think that this was the dead obvious function

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Tim] >> secrets.token_bytes() is already the way to spell "get a string of >> messed-up bytes", and that's the dead obvious (according to me) place >> to add the potentially blocking implementation. [Sebastian Krause] > I honestly didn't think that this was the dead obvious function to > use. To

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/10/2016 01:01 PM, David Mertz wrote: So yes, I think 3.5.2 should restore the 2.6-3.4 behavior of os.urandom(), That makes... five of us I think ;-) (Larry Guido Barry Tim David) and the NEW APIs in secrets should use the "best available randomness (even if it blocks)" I'm not

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 10.06.2016 20:55, Donald Stufft wrote: > Ok, so you’re looking for how would you replicate the blocking behavior of > os.urandom that exists in 3.5.0 and 3.5.1? > > In that case, it’s hard. I don’t think linux provides any way to externally > determine if /dev/urandom has been initialized or

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, Jun 10, 2016, at 15:54, Theodore Ts'o wrote: > So even on Python pre-3.5.0, realistically speaking, the "weakness" of > os.random would only be an issue (a) if it is run within the first few > seconds of boot, and (b) os.random is used to directly generate a > long-term cryptographic

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 10, 2016, at 5:21 PM, Tim Peters wrote: > > Isn't that precisely the purpose of the GRND_NONBLOCK flag? It doesn’t behave exactly the same as /dev/urandom. If the pool hasn’t been initialized yet /dev/urandom will return possibly predictable data whereas

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2016-06-03 - 2016-06-10) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5553 (+16) closed 33491 (+75) total 39044 (+91) Open issues

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

Nick Coghlan wrote: > It could be very interesting to add an "ascii-warn" codec to Python > 2.7, and then set that as the default encoding when the -3 flag is > set. I don't think that can work. The library code in Python would spew out warnings even in the cases when

Re: [Python-Dev] Stop using timeit, use perf.timeit!

Hi, 2016-06-10 20:37 GMT+02:00 Kevin Modzelewski via Python-Dev : > Hi all, I wrote a blog post about this. > http://blog.kevmod.com/2016/06/benchmarking-minimum-vs-average/ Oh nice, it's even better to have different articles to explain the problem of using the minimum

[Python-Dev] Cutoff time for patches for upcoming releases

A question for each of the three release managers: when is the earliest that you might tag your release and cutoff submission of further patches for the release? 2.7.12 ('6-12')? 3.5.2 ('6-12')? 3.6.0a2 ('6-13')? -- Terry Jan Reedy ___ Python-Dev

[Python-Dev] Reminder: 3.6.0a2 snapshot 2016-06-13 12:00 UTC

Just a quick reminder that the next alpha snapshot for the 3.6 release cycle is coming up in a couple of days. This is the second of four alphas we have planned. Alpha 2 follows the development sprints at the PyCon US 2016 in Portland. Thanks to all of you who were able to be there and

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Sat, Jun 11, 2016 at 12:06:31AM +0200, Victor Stinner wrote: > > Victor if you could calculate the sample skewness of your results I think > > that would be very interesting! > > I'm good to copy/paste code, but less to compute statistics :-) Would > be interesed to write a pull request, or

Re: [Python-Dev] Cutoff time for patches for upcoming releases

2016-06-11 18:00 UTC On Fri, Jun 10, 2016, at 14:37, Terry Reedy wrote: > A question for each of the three release managers: > when is the earliest that you might tag your release and > cutoff submission of further patches for the release? > > 2.7.12 ('6-12')? > > 3.5.2 ('6-12')? > > 3.6.0a2

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 11:22:42PM +0200, Victor Stinner wrote: > 2016-06-10 20:47 GMT+02:00 Meador Inge : > > Apologies in advance if this is answered in one of the links you posted, but > > out of curiosity was geometric mean considered? > > > > In the compiler world this is a

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

Neil Schemenauer writes: > I have to wonder if you guys actually ported at lot of Python 2 > code. Python 3 (including stdlib) itself is quite a bit of code. > According to you guys, there is no problem No, according to us, there are problems, but in the code, not in the language or its

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On 10 June 2016 at 03:13, Barry Warsaw wrote: > In my own experience, and IIRC Amber had a similar experience, the ease of > porting to Python 3 really comes down to how bytes/unicode clean your code > base is. Almost all the other pieces are either pretty manageable or fairly

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Nathaniel Smith wrote: > (This is based on the assumption that the only time that explicitly > calling os.urandom is the best option is when one cares about the > cryptographic strength of the result -- I'm explicitly distinguishing > here between the hash seeding issue that

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On 10 June 2016 at 15:09, Cody Piersall wrote: >> One problem is that the str literals should be bytes >> literals. Comparison with None needs to be avoided. >> >> With Python 2 code runs successfully. With Python 3 the code >> crashes with a traceback. With my

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On 10 June 2016 at 15:34, David Malcolm wrote: >> The problem is that random noise can only ever slow the code down, it >> cannot speed it up. [...] > Isn't it possible that under some circumstances the 2nd process could > prefetch memory into the cache in such a way that the

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, 2016-06-10 at 23:20 +1000, Steven D'Aprano wrote: > On Fri, Jun 10, 2016 at 01:13:10PM +0200, Victor Stinner wrote: > > Hi, > > > > Last weeks, I made researchs on how to get stable and reliable > > benchmarks, especially for the corner case of microbenchmarks. The > > first result is a

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

> One problem is that the str literals should be bytes > literals. Comparison with None needs to be avoided. > > With Python 2 code runs successfully. With Python 3 the code > crashes with a traceback. With my modified Python 3.6, the code > runs successfully but generates the following