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

On Wed, Jun 15, 2016 at 04:12:57PM -0700, Nathaniel Smith wrote: > - It's not exactly true that the Python interpreter doesn't need > cryptographic randomness to initialize SipHash -- it's more that > *some* Python invocations need unguessable randomness (to first > approximation: all those which

[Python-Dev] Final round of the Python Language Summit coverage at LWN

Hola python-dev, The final batch of articles from the Python Language Summit is now ready. The starting point is here: https://lwn.net/Articles/688969/ I have added the final six sessions (with SubscriberLinks for those without a subscription): Python 3 in Fedora:

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

On 15 June 2016 at 16:12, Nathaniel Smith wrote: > On Wed, Jun 15, 2016 at 1:01 PM, Nick Coghlan wrote: >> Victor has some additional technical details written up at >> http://haypo-notes.readthedocs.io/pep_random.html and I'd be happy to >> formalise this

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

On Wed, Jun 15, 2016 at 1:01 PM, Nick Coghlan wrote: [...] > For 3.6+, we can instead make it so that the only things that actually > rely on cryptographic quality randomness being available are: > > - calling a secrets module API > - calling a random.SystemRandom method > -

Re: [Python-Dev] Why does base64 return bytes?

Paul Moore: > Finding out whether users/projects typically write such a helper > function for themselves would be a better way of getting this > information. Personally, I suspect they don't, but facts beat > speculation. Well, I did. It was necessary to get 2to3 conversion to work(*). I turned

Re: [Python-Dev] proposed os.fspath() change

On Wed, Jun 15, 2016 at 11:00 PM, Ethan Furman wrote: > On 06/15/2016 12:24 PM, Koos Zevenhoven wrote: >> >> And the other question could be turned into whether to make str and >> bytes also PathLike in __subclasshook__. > > No, for two reasons. > > - most str's and bytes' are

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

On 14 June 2016 at 02:41, Nikita Nemkin wrote: > Is there any rationale for rejecting alternatives like: Good questions - Eric, it's likely worth capturing answers to these in the PEP for the benefit of future readers. > 1. Adding standard metaclass with ordered namespace.

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

On 06/15/2016 01:01 PM, Nick Coghlan wrote: For 3.6+, we can instead make it so that the only things that actually rely on cryptographic quality randomness being available are: - calling a secrets module API - calling a random.SystemRandom method - calling os.urandom directly However, we

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

[whew, actually read the whole thread] On 11 June 2016 at 10:28, Terry Reedy wrote: > On 6/11/2016 11:34 AM, Guido van Rossum wrote: >> >> In terms of API design, I'd prefer a flag to os.urandom() indicating a >> preference for >> - blocking >> - raising an exception >> -

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 12:24 PM, Koos Zevenhoven wrote: On Wed, Jun 15, 2016 at 10:15 PM, Brett Cannon wrote: ABCs like os.PathLike can override __subclasshook__ so that registration isn't required (see https://hg.python.org/cpython/file/default/Lib/os.py#l1136). So registration is definitely good to

Re: [Python-Dev] proposed os.fspath() change

PEP 519 updated: https://hg.python.org/peps/rev/92feff129ee4 On Wed, 15 Jun 2016 at 11:44 Brett Cannon wrote: > On Wed, 15 Jun 2016 at 11:39 Guido van Rossum wrote: > >> OK, so let's add a check on the return of __fspath__() and keep the check >> on

Re: [Python-Dev] proposed os.fspath() change

On Wed, Jun 15, 2016 at 10:15 PM, Brett Cannon wrote: > > > On Wed, 15 Jun 2016 at 12:12 Koos Zevenhoven wrote: >> >> >> if isinstance(filename, os.PathLike): >> >> By the way, regarding the line of code above, is there a convention >> regarding whether

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 12:10 PM, Koos Zevenhoven wrote: if isinstance(filename, os.PathLike): By the way, regarding the line of code above, is there a convention regarding whether implementing some protocol/interface requires registering with (or inheriting from) the appropriate ABC for it to work

Re: [Python-Dev] proposed os.fspath() change

On Wed, 15 Jun 2016 at 12:12 Koos Zevenhoven wrote: > >> if isinstance(filename, os.PathLike): > > By the way, regarding the line of code above, is there a convention > regarding whether implementing some protocol/interface requires > registering with (or inheriting from)

Re: [Python-Dev] proposed os.fspath() change

>> if isinstance(filename, os.PathLike): By the way, regarding the line of code above, is there a convention regarding whether implementing some protocol/interface requires registering with (or inheriting from) the appropriate ABC for it to work in all situations. IOW, in this case, is it

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 11:44 AM, Brett Cannon wrote: On Wed, 15 Jun 2016 at 11:39 Guido van Rossum wrote: OK, so let's add a check on the return of __fspath__() and keep the check on path-like or string/bytes. I'll update the PEP. Ethan, do you want to leave a note on the os.fspath() issue to

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

On 10 June 2016 at 16:36, Neil Schemenauer wrote: > 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

Re: [Python-Dev] proposed os.fspath() change

On Wed, Jun 15, 2016 at 9:29 PM, Nick Coghlan wrote: > On 15 June 2016 at 10:59, Brett Cannon wrote: >> >> >> On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: >>> >>> These are really two separate proposals. >>> >>> I'm okay with

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 10:59 AM, Brett Cannon wrote: On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: These are really two separate proposals. I'm okay with checking the return value of calling obj.__fspath__; that's an error in the object anyways, and it doesn't matter much whether we do this or

Re: [Python-Dev] proposed os.fspath() change

OK, so let's add a check on the return of __fspath__() and keep the check on path-like or string/bytes. --Guido (mobile) On Jun 15, 2016 11:29 AM, "Nick Coghlan" wrote: > On 15 June 2016 at 10:59, Brett Cannon wrote: > > > > > > On Wed, 15 Jun 2016 at

Re: [Python-Dev] proposed os.fspath() change

On Wed, 15 Jun 2016 at 11:39 Guido van Rossum wrote: > OK, so let's add a check on the return of __fspath__() and keep the check > on path-like or string/bytes. > I'll update the PEP. Ethan, do you want to leave a note on the os.fspath() issue to update the code and go

Re: [Python-Dev] proposed os.fspath() change

On 15 June 2016 at 10:59, Brett Cannon wrote: > > > On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: >> >> These are really two separate proposals. >> >> I'm okay with checking the return value of calling obj.__fspath__; that's >> an error in the object

Re: [Python-Dev] proposed os.fspath() change

My proposal at the point of the first PEP draft solved both of these issues. That version of the fspath function passed anything right through that was an instance of the keyword-only `type_constraint`. If not, it would ask __fspath__, and before returning the result, it would check that

Re: [Python-Dev] proposed os.fspath() change

On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: > These are really two separate proposals. > > I'm okay with checking the return value of calling obj.__fspath__; that's > an error in the object anyways, and it doesn't matter much whether we do > this or not (though when

Re: [Python-Dev] Bug in the DELETE statement in sqlite3 module

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2016 12:33 PM, Guido van Rossum wrote: > A point of order: it's not necessary to post three separate "this is > the wrong list" replies. In fact the optimal number is probably close > to zero -- I understand we all want to be helpful, and we

Re: [Python-Dev] proposed os.fspath() change

These are really two separate proposals. I'm okay with checking the return value of calling obj.__fspath__; that's an error in the object anyways, and it doesn't matter much whether we do this or not (though when approving the PEP I considered this and decided not to insert a check for this). But

Re: [Python-Dev] Bug in the DELETE statement in sqlite3 module

A point of order: it's not necessary to post three separate "this is the wrong list" replies. In fact the optimal number is probably close to zero -- I understand we all want to be helpful, and we don't want to send duplicate replies, but someone who posts an inappropriate question is likely to

[Python-Dev] proposed os.fspath() change

I would like to make a change to os.fspath(). Specifically, os.fspath() currently raises an exception if something besides str, bytes, or os.PathLike is passed in, but makes no checks if an os.PathLike object returns something besides a str or bytes. I would like to change that to the opposite:

Re: [Python-Dev] Bug in the DELETE statement in sqlite3 module

On 15 June 2016 at 07:40, ninostephen mathew wrote: > Respected Developer(s), > while writing a database module for one of my applications in python I > encountered something interesting. I had a username and password field in my > table and only one entry which was "Admin"

Re: [Python-Dev] Bug in the DELETE statement in sqlite3 module

> On 2016-06-15, at 08:40 , ninostephen mathew wrote: > > Respected Developer(s), > while writing a database module for one of my applications in python I > encountered something interesting. I had a username and password field in my > table and only one entry which was

Re: [Python-Dev] Bug in the DELETE statement in sqlite3 module

This is not a bug, this is correct behavior of any sql database. 2016-06-15 8:40 GMT+02:00 ninostephen mathew : > Respected Developer(s), > while writing a database module for one of my applications in python I > encountered something interesting. I had a username and password

Re: [Python-Dev] Why does base64 return bytes?

It would be a codec. base64_text in the codecs module. Probably 1 line different than the existing codec. Very easy to use and maintain. Less surprising and less error prone for everyone who thinks base64 should convert between bytes to text. Sounds like an obvious win to me. On Wed, Jun 15, 2016

[Python-Dev] Bug in the DELETE statement in sqlite3 module

Respected Developer(s), while writing a database module for one of my applications in python I encountered something interesting. I had a username and password field in my table and only one entry which was "Admin" and "password". While debugging I purposefully deleted that record. Then I ran the

Re: [Python-Dev] Why does base64 return bytes?

On Wed, 15 Jun 2016, Greg Ewing wrote: Simon Cross wrote: If we only support one, I would prefer it to be bytes since (bytes -> bytes -> unicode) seems like less overhead and slightly conceptually clearer than (bytes -> unicode -> bytes), Whereas bytes -> unicode, followed if needed by

Re: [Python-Dev] Why does base64 return bytes?

On Wed, Jun 15, 2016 at 12:53:15PM +, Daniel Holth wrote: > In that case could we just add a base64_text() method somewhere? Who would > like to measure whether it would be a win? Just call .decode('ascii') on the output of base64.b64encode. Not every one-liner needs to be a standard

Re: [Python-Dev] Why does base64 return bytes?

On 15 June 2016 at 13:53, Daniel Holth wrote: > In that case could we just add a base64_text() method somewhere? Who would > like to measure whether it would be a win? "Just adding" a method in the stdlib, means we'd have to support it long term (backward compatibility). So by

Re: [Python-Dev] Why does base64 return bytes?

In that case could we just add a base64_text() method somewhere? Who would like to measure whether it would be a win? On Wed, Jun 15, 2016 at 8:34 AM Steven D'Aprano wrote: > On Tue, Jun 14, 2016 at 09:40:51PM -0700, Guido van Rossum wrote: > > I'm officially on vacation,

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016 at 09:40:51PM -0700, Guido van Rossum wrote: > I'm officially on vacation, but I was surprised that people now assume > RFCs, which specify internet protocols, would have a bearing on programming > languages. (With perhaps an exception for RFCs that specifically specify > how

Re: [Python-Dev] Why does base64 return bytes?

Simon Cross wrote: If we only support one, I would prefer it to be bytes since (bytes -> bytes -> unicode) seems like less overhead and slightly conceptually clearer than (bytes -> unicode -> bytes), Whereas bytes -> unicode, followed if needed by unicode -> bytes, seems conceptually clearer

Re: [Python-Dev] Why does base64 return bytes?

Stephen J. Turnbull wrote: The RFC is unclear on this point, but I read it as specifying the ASCII coded character set, not the ASCII repertoire of (abstract) characters. Well, I think you've misread it. Or at least there is a more general reading possible that is entirely consistent with the

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016 at 8:42 PM, Terry Reedy wrote: > Thank you for finding that. I reread it and still believe that bytes was > the right choice. Base64 is an generic edge encoding for binary data. It > fits in with the the standard paradigm as a edge encoding. I'd like to