Re: [Python-Dev] PEP 506 secrets module

On 16 October 2015 at 12:04, Steven D'Aprano wrote: > On Fri, Oct 16, 2015 at 08:57:24AM +0200, Victor Stinner wrote: >> I don't like the idea how having two functions doing *almost* the same >> thing: randint() and randrange(). There is a risk that these functions >> will be

Re: [Python-Dev] compatibility for C-accelerated types

For what is worth, that level of differences already exists on pypy and it's really hard to get the *exact* same semantics if things are implemented in python vs C or the other way around. Example list of differences (which I think OrderedDict already breaks if moved to C): * do methods like

Re: [Python-Dev] PEP 506 secrets module

2015-10-20 11:11 GMT+02:00 Nick Coghlan : > Folks wanting to simulate die rolls should be using the random module > rather than the secrets module anyway, Hum, why? Dices are used in Casino where security matters because it costs money. A bad API can be more likely misused

Re: [Python-Dev] PEP 506 secrets module

On 20 October 2015 at 11:33, Victor Stinner wrote: > 2015-10-20 11:11 GMT+02:00 Nick Coghlan : >> Folks wanting to simulate die rolls should be using the random module >> rather than the secrets module anyway, > > Hum, why? Dices are used in Casino

Re: [Python-Dev] type(obj) vs. obj.__class__

On 20 October 2015 at 10:21, Serhiy Storchaka wrote: > On 18.10.15 00:45, Eric Snow wrote: >> >> So, would it make sense to establish some concrete guidelines about >> when to use type(obj) vs. obj.__class__? If so, what would those be? >> It may also be helpful to enumerate

Re: [Python-Dev] type(obj) vs. obj.__class__

On 18.10.15 00:45, Eric Snow wrote: So, would it make sense to establish some concrete guidelines about when to use type(obj) vs. obj.__class__? If so, what would those be? It may also be helpful to enumerate use cases for "type(obj) is not obj.__class__". My conclusion of this discussion. In

Re: [Python-Dev] compatibility for C-accelerated types

On Tue, Oct 20, 2015 at 9:10 AM, Guido van Rossum wrote: > Please go ahead and update PEP 399. Will do. -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] compatibility for C-accelerated types

Please go ahead and update PEP 399. On Tue, Oct 20, 2015 at 8:05 AM, Eric Snow wrote: > On Tue, Oct 20, 2015 at 2:38 AM, Maciej Fijalkowski > wrote: > > For what is worth, that level of differences already exists on pypy > > and it's really hard

Re: [Python-Dev] [Python-checkins] Daily reference leaks (d7e490db8d54): sum=61494

These leaks have been here a while. Anyone know the cause? On Tue, 20 Oct 2015 at 01:47 wrote: > results for d7e490db8d54 on branch "default" > > > test_capi leaked [5411, 5411, 5411] references, sum=16233 > test_capi leaked

Re: [Python-Dev] [Python-checkins] Daily reference leaks (d7e490db8d54): sum=61494

> These leaks have been here a while. Anyone know the cause? > > On Tue, 20 Oct 2015 at 01:47 wrote: > >> results for d7e490db8d54 on branch "default" >> >> >> test_capi leaked [5411, 5411, 5411] references, sum=16233 >> test_capi leaked [1421,

Re: [Python-Dev] compatibility for C-accelerated types

On Tue, Oct 20, 2015 at 2:38 AM, Maciej Fijalkowski wrote: > For what is worth, that level of differences already exists on pypy > and it's really hard to get the *exact* same semantics if things are > implemented in python vs C or the other way around. > > Example list of

[Python-Dev] PEP-8 wart... it recommends short names because of DOS

https://www.python.org/dev/peps/pep-0008/#names-to-avoid *"Since module names are mapped to file names, and some file systems are case insensitive and truncate long names, it is important that module names be chosen to be fairly short -- this won't be a problem on Unix, but it may be a problem

Re: [Python-Dev] PEP-8 wart... it recommends short names because of DOS

DOS Python programmers probably can't use `concurrent` or `multiprocessing`. ☺ On Oct 20, 2015 6:26 PM, "Gregory P. Smith" wrote: > https://www.python.org/dev/peps/pep-0008/#names-to-avoid > > *"Since module names are mapped to file names, and some file systems are > case

[Python-Dev] PEP 8 recommends short module names because FAT is still common today (was: PEP-8 wart... it recommends short names because of DOS)

"Gregory P. Smith" writes: > There haven't been computers with less than 80 character file or path > name element length limits in wide use in decades... ;) Not true, your computer will happily mount severely-limited filesystems. Indeed, I'd wager it has done so many times this

Re: [Python-Dev] PEP 8 recommends short module names because FAT is still common today

Guido van Rossum writes: > […] I've removed the offending paragraph from the PEP. Note that it > still recommends short, all-lowercase module and package names -- it > just doesn't use computers to motivate it. That suits me too. I think the justification was valid, but its

Re: [Python-Dev] PEP 8 recommends short module names because FAT is still common today (was: PEP-8 wart... it recommends short names because of DOS)

Even thumb drives use VFAT. Yes it's an ugly hack, but the names aren't limited to 8.3. On Oct 20, 2015 6:59 PM, "Ben Finney" wrote: > "Gregory P. Smith" writes: > > > There haven't been computers with less than 80 character file or path > > name

Re: [Python-Dev] PEP 8 recommends short module names because FAT is still common today (was: PEP-8 wart... it recommends short names because of DOS)

Regardless, I don't think the continued existence of FAT filesystems can be perceived as a threat to module names, so I've removed the offending paragraph from the PEP. Note that it still recommends short, all-lowercase module and package names -- it just doesn't use computers to motivate it. On

Re: [Python-Dev] [Python-checkins] Daily reference leaks (d7e490db8d54): sum=61494

[Adding Raymond to the thread, since he doesn't always follow the lists closely.] On Tue, Oct 20, 2015 at 8:23 PM, Benjamin Peterson wrote: > > > On Tue, Oct 20, 2015, at 15:57, Antoine Pitrou wrote: > > > > > These leaks have been here a while. Anyone know the cause? > > >

Re: [Python-Dev] [Python-checkins] Daily reference leaks (d7e490db8d54): sum=61494

On Tue, Oct 20, 2015, at 15:57, Antoine Pitrou wrote: > > > These leaks have been here a while. Anyone know the cause? > > > > On Tue, 20 Oct 2015 at 01:47 wrote: > > > >> results for d7e490db8d54 on branch "default" > >> > >> > >> test_capi