On 06/15/2016 11:45 PM, Barry Warsaw wrote:
So we very clearly provided platform-dependent caveats on the cryptographic
quality of os.urandom(). We also made a strong claim that there's a direct
connection between os.urandom() and /dev/urandom on "Unix-like system(s)".
We broke that particular
On Jun 15, 2016, at 01:01 PM, Nick Coghlan wrote:
>No, this is a bad idea. Asking novice developers to make security
>decisions they're not yet qualified to make when it's genuinely
>possible for us to do the right thing by default is the antithesis of
>good security API design, and os.urandom() *
Steven D'Aprano wrote:
I'm
satisfied that the choice made by Python is the right choice, and that
it meets the spirit (if, arguably, not the letter) of the RFC.
IMO it meets the letter (if you read it a certain way)
but *not* the spirit.
--
Greg
___
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 a
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: https://lwn.net/Articles/6906
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 proposed approach as a PEP (the current
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
> - calling os.urandom dir
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 e
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 not paths;
True. We
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.
Adding metaclasses to
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 do
[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
>> - weaker random bits
>
>
>
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 d
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 path-like or string/bytes.
>>
>
> I'll update
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 implementing some protocol/interface re
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
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) the appropriate ABC
>> 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 suff
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 update
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 library code in Python would spew
> ou
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 checking the return value of calling obj.__fspath__; that's
>>
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
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 09:48 Guido van Rossum wrote:
> >>
> >> Th
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 through where we've used
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 anyways, and it doesn't matter much whe
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 __fspath_
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 approving the PEP I c
-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
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
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 try
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:
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" and "password". While
> 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 "Admin" and "password"
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 field in my
> table
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
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
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 unicod
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 function
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 the time such an ex
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, but I was surprised tha
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 p
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 to
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
43 matches
Mail list logo
