On 15 April 2016 at 00:01, Random832 wrote:
> On Thu, Apr 14, 2016, at 09:50, Chris Angelico wrote:
>> Adding integers and floats is considered "safe" because most people's
>> use of floats completely compasses their use of ints. (You'll get
>> OverflowError if it can't be represented.) But float
Le vendredi 15 avril 2016, Stefan Behnel a écrit :
> How can that be achieved? If the tag is just a sequentially growing number,
> creating two dicts and applying one operation to the first one should give
> both the same version tag, right?
>
Armin didn't propose to get ride of the global versi
It's easy to implement this function (in the native language of your Python
implemenation), it's short. I'm not sure that a Python version is really
safe.
The secrets module is for Python 3.6, in this version the hmac already
"requires" the compare_digest() function no?
Victor
___
Victor Stinner gmail.com> writes:
>
> Hi,
>
> 2016-04-14 22:42 GMT+02:00 Armin Rigo tunes.org>:
> > Hi Victor,
> >
> > On 14 April 2016 at 17:19, Victor Stinner
gmail.com> wrote:
> >> Each time a dictionary is created, the global
> >> version is incremented and the dictionary version is initia
Victor Stinner schrieb am 15.04.2016 um 10:20:
> Le vendredi 15 avril 2016, Stefan Behnel a écrit :
>
>> How can that be achieved? If the tag is just a sequentially growing number,
>> creating two dicts and applying one operation to the first one should give
>> both the same version tag, right?
>>
On Fri, Apr 15, 2016 at 10:26:31AM +0200, Victor Stinner wrote:
> It's easy to implement this function (in the native language of your Python
> implemenation), it's short. I'm not sure that a Python version is really
> safe.
>
> The secrets module is for Python 3.6, in this version the hmac alread
2016-04-15 11:01 GMT+02:00 Antoine Pitrou :
> Victor Stinner gmail.com> writes:
>> You're right that incrementing the global version is useless for these
>> specific cases, and using the version 0 should work. It only matters
>> that the version (version? version tag?) is different.
>
> Why do thi
Hi,
Would it make sense to add a function to generate a random UUID4 (as a
string) in secrets?
The current implement in uuid.py of CPython 3.6 already uses os.urandom():
def uuid4():
"""Generate a random UUID."""
return UUID(bytes=os.urandom(16), version=4)
Victor
__
2016-04-15 11:21 GMT+02:00 Steven D'Aprano :
> This isn't just a question about the secrets module. PEP 399 suggests
> than any C classes/functions should have a pure Python version as
> fallback, but compare_digest doesn't. I don't know whether it should or
> not.
The hmac module is responsible t
On 15 April 2016 at 10:35, Victor Stinner wrote:
> 2016-04-15 11:21 GMT+02:00 Steven D'Aprano :
>> This isn't just a question about the secrets module. PEP 399 suggests
>> than any C classes/functions should have a pure Python version as
>> fallback, but compare_digest doesn't. I don't know whethe
On 15 April 2016 at 00:52, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > The use case for returning bytes from __fspath__ is DirEntry, so you
> > can write things like this in low level code:
> >
> > def myscandir(dirpath):
> > for entry in os.scandir(dirpath):
> >
On 15 April 2016 at 19:39, Victor Stinner wrote:
> Hi,
>
> Would it make sense to add a function to generate a random UUID4 (as a
> string) in secrets?
>
> The current implement in uuid.py of CPython 3.6 already uses os.urandom():
>
> def uuid4():
> """Generate a random UUID."""
> return U
On 15 April 2016 at 14:52, Steven D'Aprano wrote:
> Now that PEP 506 has been approved, I've checked in the secrets module,
> but an implementation question has come up regarding compare_digest.
>
> Currently, the module tries to import hmac.compare_digest, and if that
> fails, then it falls back
ACTIVITY SUMMARY (2016-04-08 - 2016-04-15)
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:
open5489 (+12)
closed 33039 (+46)
total 38528 (+58)
Open issues wit
After a fruitful discussion on python-ideas I've decided that it's fine to
break lines *before* a binary operator. It looks better and Knuth
recommends it.
The head of the python-ideas discussion:
https://mail.python.org/pipermail/python-ideas/2016-April/039752.html
See also the discussion in the
Hum.
if (width == 0
and height == 0
and color == 'red'
and emphasis == 'strong'
or highlight > 100):
raise ValueError("sorry, you lose")
Please remove one space to vertically align "and" operators with the
opening parenthesis:
[Guido]
> After a fruitful discussion on python-ideas I've decided that it's fine to
> break lines *before* a binary operator. It looks better and Knuth recommends
> it.
> ...
> Therefore it is permissible to break before or
> after a binary operator, as long as the convention is consistent
> local
On 15 April 2016 at 18:03, Victor Stinner wrote:
> Hum.
>
> if (width == 0
> and height == 0
> and color == 'red'
> and emphasis == 'strong'
> or highlight > 100):
> raise ValueError("sorry, you lose")
>
> Please remove one space
On Fri, Apr 15, 2016 at 10:03 AM, Victor Stinner
wrote:
> Hum.
>
> if (width == 0
> and height == 0
> and color == 'red'
> and emphasis == 'strong'
> or highlight > 100):
> raise ValueError("sorry, you lose")
>
> Please remove on
On 15.04.16 20:03, Victor Stinner wrote:
Hum.
if (width == 0
and height == 0
and color == 'red'
and emphasis == 'strong'
or highlight > 100):
raise ValueError("sorry, you lose")
Please remove one space to vertically align
The update is already serving its real purpose: showing that style is
debatable and cannot always easily be reduced to fixed rules.
On Fri, Apr 15, 2016 at 10:24 AM, Serhiy Storchaka
wrote:
> On 15.04.16 20:03, Victor Stinner wrote:
>
>> Hum.
>>
>> if (width == 0
>> and hei
On 2016-04-15 18:03, Victor Stinner wrote:
> Hum.
>
> if (width == 0
> and height == 0
> and color == 'red'
> and emphasis == 'strong'
> or highlight > 100):
> raise ValueError("sorry, you lose")
>
> Please remove one space
On Thu Apr 14 11:19:42 EDT 2016, Victor Stinner posted the latest
draft of PEP 509; dict version_tag
(1) Meta Question: If this is really only for CPython, then is
"Standards Track" the right classification?
(2) Why *promise* not to update the version_tag when replacing a
value with itself?
On Apr 15, 2016, at 09:53 AM, Guido van Rossum wrote:
>After a fruitful discussion on python-ideas I've decided that it's fine to
>break lines *before* a binary operator.
Thanks Guido, your changes look great.
-Barry
___
Python-Dev mailing list
Python-
On 15 April 2016 at 18:54, Jim J. Jewett wrote:
>
> [2A] Do you want to promise that replacing a value with a
> non-identical object *will* trigger a version_tag update *even*
> if the objects are equal?
>
> I would vote no, but I realize backwards-compatibility may create
> such a promise implici
2016-04-15 19:54 GMT+02:00 Jim J. Jewett :
> (1) Meta Question: If this is really only for CPython, then is
> "Standards Track" the right classification?
Yes, I think so. It doesn't seem to be an Informal nor a Process:
https://www.python.org/dev/peps/pep-0001/#pep-types
> (2) Why *promise* n
Cross posting the comment I’d left on the issue [1].
> My preference is to actually break that logic up and avoid the wrapping in
> the first place, as in [2]. Which in this particular class has the side
> benefit of that value being used again in the same function anyways.
> I'm starting to re
On Fri, Apr 15, 2016, at 16:41, Victor Stinner wrote:
> If the dictionary values are modified during the loop, the dict
> version is increased. But it's allowed to modify values when you
> iterate on *keys*.
Why is iterating over items different from iterating over keys?
in other words, why do I
On 04/15/2016 01:41 PM, Victor Stinner wrote:
2016-04-15 19:54 GMT+02:00 Jim J. Jewett:
(2) Why *promise* not to update the version_tag when replacing a
value with itself?
It's an useful property. For example, let's say that you have a guard
on globals()['value']. The guard is created with
2016-04-15 23:07 GMT+02:00 Random832 :
> Why is iterating over items different from iterating over keys?
>
> in other words, why do I have to write:
>
> for k in dict:
> v = dict[k]
> ...do some stuff...
> dict[k] = something
>
> rather than
>
> for k, v in dict.items():
> ...do som
2016-04-15 23:16 GMT+02:00 Ethan Furman :
>> It's an useful property. For example, let's say that you have a guard
>> on globals()['value']. The guard is created with value=3. An unit test
>> replaces the value with 50, but then restore the value to its previous
>> value (3). Later, the guard is ch
Hi,
FYI I updated the implementation of the PEP 509:
https://bugs.python.org/issue26058
2016-04-15 11:01 GMT+02:00 Antoine Pitrou :
> Why do this? It's a nice property that two dicts always have different
> version tags, and now you're killing this property for... no obvious
> reason?
>
> Do you
On Fri, Apr 15, 2016 at 4:41 PM, Victor Stinner
wrote:
> 2016-04-15 19:54 GMT+02:00 Jim J. Jewett :
>> (2) Why *promise* not to update the version_tag when replacing a
>> value with itself?
> It's an useful property. For example, let's say that you have a guard
> on globals()['value']. The guar
.2016-04-15 23:45 GMT+02:00 Jim J. Jewett :
>> It's an useful property. For example, let's say that you have a guard
>> on globals()['value']. The guard is created with value=3. An unit test
>> replaces the value with 50, but then restore the value to its previous
>> value (3). Later, the guard is
If Python ever adopts the BCPL rule for implicit line continuation if the
last thing on a line is an operator (or if there's an open parentheses),
then the break-after-an-operator rule would be more persuasive.
;)
[IIRC, the BCPL rule was that there was an implicit continuation if the
grammar woul
On Fri, Apr 15, 2016, at 23:46, Peter Ludemann via Python-Dev wrote:
> If Python ever adopts the BCPL rule for implicit line continuation if
> the last thing on a line is an operator (or if there's an open
> parentheses), then the break-after-an-operator rule would be more
> persuasive. ;)
>
> [IIR
36 matches
Mail list logo