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 Python 3 type(obj) and obj.__class__ are the same in common case. Assigning obj.__class__ is a way to change type(obj). If the assignment is successful, type(obj) becomes the same as obj.__class__. This is used in importlib for lazy importing and some clever classes like the RingBuffer recipe. But __class__ assignment has many restrictions, and changing Python to C implementation or adding __slots__ for sure adds new restrictions. obj.__class__ is different from type(obj) in proxy classes like weakref or Mock. isinstance() and pickle take __class__ to account to support proxies. Unless we write proxy class or code that should handle proxy classes, we shouldn't care about the difference between type(obj) and obj.__class__, and can use what is the more convenient. In Python this is obj.__class__ (avoids globals lookup), and in C this is type(obj) (much simpler and reliable code). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 items call special methods like __getitem__ (I think it's undecided anyway) * what happens if you take a method and rebind it to another subclass, does it automatically become a method (there are differences between built in and pure python) * atomicity of operations. Some operations used to be non-atomic in Python will be atomic now. I personally think those (and the __class__ issue) are unavoidable On Mon, Oct 19, 2015 at 11:47 PM, Serhiy Storchaka wrote: > On 20.10.15 00:00, Guido van Rossum wrote: >> >> Apart from Serhiy's detraction of the 3.5 bug report there wasn't any >> discussion in this thread. I also don't really see any specific >> questions, so maybe you don't have any. Are you just asking whether it's >> okay to merge your code? Or are you asking for more code review? > > > I think Eric ask whether it's okay to have some incompatibility between > Python and C implementations. > > 1. Is it okay to have a difference in effect of __class__ assignment. Pure > Python and extension classes have different restrictions. For example > (tested example this time) following code works with Python implementation > in 3.4, but fails with C implementation in 3.5: > > from collections import OrderedDict > od = OrderedDict() > class D(dict): pass > > od.__class__ = D > > 2. Is it okay to use obj.__class__ in Python implementation and type(obj) in > C implementation for the sake of code simplification? Can we ignore subtle > differences? > > 3. In general, is it okay to have some incompatibility between Python and C > implementations for the sake of code simplification, and where the border > line lies? > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 misused. I consider that I know some stuff on PRNG but I'm >> still confused by randint() and randrange(). Usually, I open python >> and type: >> >> >>> x=[s.randrange(1,6) for n in range(100)] >> >>> min(x), max(x) >> (1, 5) > > Wouldn't help(randrange) be easier? :-) > > Choose a random item from range(start, stop[, step]). > > This fixes the problem with randint() which includes the > endpoint; in Python this is usually not what you want. > > > I always find that comment amusing. While it is true that in slicing, > half-open ranges are more useful than closed ranges, but when it comes > to generating random numbers (say, simulating dice) I find randint much > more useful and intuitive. > > But I appreciate that some people think differently. Folks wanting to simulate die rolls should be using the random module rather than the secrets module anyway, so the "only offer secrets.randbelow()" approach Guido suggested in his last email makes sense to me. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 use cases for "type(obj) is not >> obj.__class__". > > > My conclusion of this discussion. In Python 3 type(obj) and obj.__class__ > are the same in common case. Assigning obj.__class__ is a way to change > type(obj). If the assignment is successful, type(obj) becomes the same as > obj.__class__. This is used in importlib for lazy importing and some clever > classes like the RingBuffer recipe. But __class__ assignment has many > restrictions, and changing Python to C implementation or adding __slots__ > for sure adds new restrictions. > > obj.__class__ is different from type(obj) in proxy classes like weakref or > Mock. isinstance() and pickle take __class__ to account to support proxies. > > Unless we write proxy class or code that should handle proxy classes, we > shouldn't care about the difference between type(obj) and obj.__class__, and > can use what is the more convenient. In Python this is obj.__class__ (avoids > globals lookup), and in C this is type(obj) (much simpler and reliable > code). Right, this is a good summary. Weakref proxies provide one of the simplest demonstrations of cases where the two diverge: >>> from weakref import proxy >>> class C: pass ... >>> obj = C() >>> ref = proxy(obj) >>> type(ref) >>> ref.__class__ When we use "obj.__class__", we're treating proxies as their target, when we use "type(obj)", we're treating them as the proxy object. Which of those to use depends greatly on what we're doing. For Eric's original question that started the thread: proxy types shouldn't inherit from a concrete container type like OrderedDict, so type(self) and self.__class__ should *always* give the same answer, even in subclasses. Cheers, Nick. P.S. Proxy types are actually quite hard to right correctly, so if anyone *does* need to implement one, they're likely to be best served by starting with an existing library like wrapt: http://wrapt.readthedocs.org/en/latest/wrappers.html -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 and introduce security vulnerability. The C rand() API is a good example: 1+rand()%6 is not uniform... Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 where security matters because it > costs money. True, I was thinking of just-for-fun games, but in gambling games unbiased randomness can be significantly more important. > A bad API can be more likely misused and introduce security > vulnerability. The C rand() API is a good example: 1+rand()%6 is not > uniform... "1 + secrets.randbelow(6)" would be uniform, though. As Tim pointed out, the *lack* of flexibility in randbelow() is a feature here, since it focuses on producing a uniformly random distribution of a given size, which can then be transformed deterministically. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 differences (which I think OrderedDict already breaks > if moved to C): > > * do methods like items call special methods like __getitem__ (I think > it's undecided anyway) > > * what happens if you take a method and rebind it to another subclass, > does it automatically become a method (there are differences between > built in and pure python) > > * atomicity of operations. Some operations used to be non-atomic in > Python will be atomic now. > > I personally think those (and the __class__ issue) are unavoidable Yeah, I figured as much. Thanks for pointing those out. Perhaps it would be useful to enumerate specific cases like these in PEP 399? They could go near the part that says "as close to the pure Python implementation as reasonable". -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 items call special methods like __getitem__ (I think > > it's undecided anyway) > > > > * what happens if you take a method and rebind it to another subclass, > > does it automatically become a method (there are differences between > > built in and pure python) > > > > * atomicity of operations. Some operations used to be non-atomic in > > Python will be atomic now. > > > > I personally think those (and the __class__ issue) are unavoidable > > Yeah, I figured as much. Thanks for pointing those out. Perhaps it > would be useful to enumerate specific cases like these in PEP 399? > They could go near the part that says "as close to the pure Python > implementation as reasonable". > > -eric > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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, 1423, 1423] memory blocks, sum=4267 > test_functools leaked [0, 2, 2] memory blocks, sum=4 > test_threading leaked [10820, 10820, 10820] references, sum=32460 > test_threading leaked [2842, 2844, 2844] memory blocks, sum=8530 > > > Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', > '3:3:/home/psf-users/antoine/refleaks/reflogyrNnBL', '--timeout', '7200'] > ___ > Python-checkins mailing list > python-check...@python.org > https://mail.python.org/mailman/listinfo/python-checkins > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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, 1423, 1423] memory blocks, sum=4267 >> test_functools leaked [0, 2, 2] memory blocks, sum=4 >> test_threading leaked [10820, 10820, 10820] references, sum=32460 >> test_threading leaked [2842, 2844, 2844] memory blocks, sum=8530 Bisection shows they were probably introduced by: changeset: 97413:dccc4e63aef5 user:Raymond Hettinger date:Sun Aug 16 19:43:34 2015 -0700 files: Doc/library/operator.rst Doc/whatsnew/3.6.rst Lib/operator.py Lib/test/test_operator.py description: Issue #24379: Add operator.subscript() as a convenience for building slices. If you comment out `@object.__new__` on line 411 in operator.py, or if you remove the __slots__ assignment (which is a bit worrying), the leak seems suppressed. You can reproduce using: $ ./python -m test -m SubinterpreterTest -R 3:3 test_capi [1/1] test_capi beginning 6 repetitions 123456 .. test_capi leaked [5443, 5443, 5443] references, sum=16329 test_capi leaked [1432, 1434, 1434] memory blocks, sum=4300 1 test failed: test_capi Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 when the code is transported to older Mac or Windows versions, or DOS."* There haven't been computers with less than 80 character file or path name element length limits in wide use in decades... ;) -gps ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 when the code is transported to older Mac or Windows versions, > or DOS."* > > There haven't been computers with less than 80 character file or path name > element length limits in wide use in decades... ;) > > -gps > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 year. It is *filesystems* that limit the length of filesystem entries, and the FAT filesystem is still in very widespread use — on devices mounted by the computers you use today. Yes, we have much better filesystems today, and your primary desktop computer will almost certainly use something better than FAT for its primary storage's filesystem. That does not mean Python programmers should assume your computer will never mount a FAT filesystem (think small flash storage), nor that a program you run will never need to load Python modules from that filesystem. You'd like FAT to go away forever? Great, me too. Now we need to convince all the vendors of every small storage device – USB thumb drives, network routers, all manner of single-purpose devices – to use modern filesystems instead. Then, maybe after another human generation has come and gone, we can finally expect every filesystem, in every active device that might run any Python code, to be using something with a reasonably-large limit for filesystem entries. Until then, the advice in PEP 8 to keep module names short is reasonable. -- \ “The most common of all follies is to believe passionately in | `\the palpably not true. It is the chief occupation of mankind.” | _o__)—Henry L. Mencken | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 year. > > It is *filesystems* that limit the length of filesystem entries, and the > FAT filesystem is still in very widespread use — on devices mounted by > the computers you use today. > > Yes, we have much better filesystems today, and your primary desktop > computer will almost certainly use something better than FAT for its > primary storage's filesystem. > > That does not mean Python programmers should assume your computer will > never mount a FAT filesystem (think small flash storage), nor that a > program you run will never need to load Python modules from that > filesystem. > > > You'd like FAT to go away forever? Great, me too. Now we need to > convince all the vendors of every small storage device – USB thumb > drives, network routers, all manner of single-purpose devices – to use > modern filesystems instead. > > Then, maybe after another human generation has come and gone, we can > finally expect every filesystem, in every active device that might run > any Python code, to be using something with a reasonably-large limit for > filesystem entries. > > Until then, the advice in PEP 8 to keep module names short is reasonable. > > -- > \ “The most common of all follies is to believe passionately in | > `\the palpably not true. It is the chief occupation of mankind.” | > _o__)—Henry L. Mencken | > Ben Finney > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 leaked [5411, 5411, 5411] references, sum=16233 > >> test_capi leaked [1421, 1423, 1423] memory blocks, sum=4267 > >> test_functools leaked [0, 2, 2] memory blocks, sum=4 > >> test_threading leaked [10820, 10820, 10820] references, sum=32460 > >> test_threading leaked [2842, 2844, 2844] memory blocks, sum=8530 > > Bisection shows they were probably introduced by: > > changeset: 97413:dccc4e63aef5 > user:Raymond Hettinger > date:Sun Aug 16 19:43:34 2015 -0700 > files: Doc/library/operator.rst Doc/whatsnew/3.6.rst > Lib/operator.py Lib/test/test_operator.py > description: > Issue #24379: Add operator.subscript() as a convenience for building > slices. > > > If you comment out `@object.__new__` on line 411 in operator.py, or if > you remove the __slots__ assignment (which is a bit worrying), the leak > seems suppressed. The problem is that the "subscript" class is not a GC type, but participates in a cycle through its type. I suspect it's type to force all heap types to have GC. Armin Rigo found previous examples where this special case caused problems, and I don't see what it buys anyway. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Tue, Oct 20, 2015 at 7:02 PM, David Mertz wrote: > 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 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 year. >> >> It is *filesystems* that limit the length of filesystem entries, and the >> FAT filesystem is still in very widespread use — on devices mounted by >> the computers you use today. >> >> Yes, we have much better filesystems today, and your primary desktop >> computer will almost certainly use something better than FAT for its >> primary storage's filesystem. >> >> That does not mean Python programmers should assume your computer will >> never mount a FAT filesystem (think small flash storage), nor that a >> program you run will never need to load Python modules from that >> filesystem. >> >> >> You'd like FAT to go away forever? Great, me too. Now we need to >> convince all the vendors of every small storage device – USB thumb >> drives, network routers, all manner of single-purpose devices – to use >> modern filesystems instead. >> >> Then, maybe after another human generation has come and gone, we can >> finally expect every filesystem, in every active device that might run >> any Python code, to be using something with a reasonably-large limit for >> filesystem entries. >> >> Until then, the advice in PEP 8 to keep module names short is reasonable. >> >> -- >> \ “The most common of all follies is to believe passionately in | >> `\the palpably not true. It is the chief occupation of mankind.” | >> _o__)—Henry L. Mencken | >> Ben Finney >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx >> > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 absence doesn't harm the PEP. -- \ “I busted a mirror and got seven years bad luck, but my lawyer | `\thinks he can get me five.” —Steven Wright | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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? > > > > > > 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, 1423, 1423] memory blocks, sum=4267 > > >> test_functools leaked [0, 2, 2] memory blocks, sum=4 > > >> test_threading leaked [10820, 10820, 10820] references, sum=32460 > > >> test_threading leaked [2842, 2844, 2844] memory blocks, sum=8530 > > > > Bisection shows they were probably introduced by: > > > > changeset: 97413:dccc4e63aef5 > > user:Raymond Hettinger > > date:Sun Aug 16 19:43:34 2015 -0700 > > files: Doc/library/operator.rst Doc/whatsnew/3.6.rst > > Lib/operator.py Lib/test/test_operator.py > > description: > > Issue #24379: Add operator.subscript() as a convenience for building > > slices. > > > > > > If you comment out `@object.__new__` on line 411 in operator.py, or if > > you remove the __slots__ assignment (which is a bit worrying), the leak > > seems suppressed. > > The problem is that the "subscript" class is not a GC type, but > participates in a cycle through its type. I suspect it's type to force > all heap types to have GC. Armin Rigo found previous examples where this > special case caused problems, and I don't see what it buys anyway. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
