[issue19048] itertools.tee doesn't have a __sizeof__ method

Martin v. Löwis added the comment: Antoine: in (my experience of) memory analysis, the size of a single object is mostly irrelevant. If you need to know how much memory something consumes, you typically want to know the memory of a set of objects. So this is the case that really must be suppor

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

Stefan Behnel added the comment: I'm not entirely happy about the docs anyway. Most people just want to loop over iterparse() and be done (use case being to save memory). The new parser class is a rather special and more complex thing that we shouldn't let innocent users run into that easily.

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

Nick Coghlan added the comment: I clarified the issue title to actually explain the concern and the proposed fix (i.e. close() on XMLPullParser doesn't currently return the root, which is inconsistent with the XMLParser API). This sounds like a reasonable change to me, but the docs also need t

[issue18990] Remove unnecessary API inconsistency from ElementTree.XMLPullParser.close()

Stefan Behnel added the comment: Inviting some more people to get this patch reviewed in a timely fashion. Given that it's a cleanup of a newly introduced API, it must go in before the first beta release of 3.4. The even wider cleanup would be to make XMLPullParser inherit from XMLParser and

[issue19055] Regular expressions: * does not match as many repetitions as possible.

R. David Murray added the comment: The documentation is correct and unambiguous. Regular expressions just aren't very intuitive. The documentation says "Causes the resulting RE to match 0 or more repetitions of the preceding RE, as many repetitions as are possible." "as many repetitions of

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

R. David Murray added the comment: No need to apologize for missing the issue. I missed it too, and I was looking for it because I thought I remembered something...but only found the one I referenced and assumed that that was what I was remembering. -- stage: -> committed/rejected ty

[issue19054] Descriptors howto

Changes by Ned Deily : -- nosy: +rhettinger versions: -Python 2.6, Python 3.1, Python 3.2 ___ Python tracker ___ ___ Python-bugs-list

[issue19045] Make on Solaris 11 x64 with OracleStudio12.3 failed

Changes by Ned Deily : -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: Here is advanced function which counts only objects on which there are no external references. >>> import itertools >>> a, b = itertools.tee(range(1)) >>> max(zip(a, range(100))) (99, 99) >>> sys.getsizeof(a) 32 >>> gettotalinnersizeof(a) 32 >>> gettotali

[issue19055] Regular expressions: * does not match as many repetitions as possible.

Jason Stumpf added the comment: I understand what's happening, but that is not what the documentation describes. If the behaviour is correct, the documentation is incorrect. -- ___ Python tracker

[issue19055] Regular expressions: * does not match as many repetitions as possible.

Matthew Barnett added the comment: The behaviour is correct. Here's a summary of what's happening:- First iteration of the repeated group: Try the first branch. Can match "a". Second iteration of the repeated group: Try the first branch. Can't match "a". Try the second branch. C

[issue19055] Regular expressions: * does not match as many repetitions as possible.

Jason Stumpf added the comment: Sorry, that implication was backwards. I don't think I can prove from just the documentation that '(a|ab)*' can match 'aba' in certain contexts. If the docs said: "* attempts to match again after each match of the preceding regular expression." I think it would

[issue19055] Regular expressions: * does not match as many repetitions as possible.

Jason Stumpf added the comment: Even with the documentation to |, the documentation to * is wrong. >>> re.match('(a|ab)*c',('abac')).group(0) 'abac' >From the doc: In general, if a string p matches A and another string q matches >B, the string pq will match AB. Since '(a|ab)*c' matches 'abac'

[issue19055] Regular expressions: * does not match as many repetitions as possible.

janzert added the comment: The documentation on the | operator in the re module pretty explicitly covers this. http://docs.python.org/2/library/re.html "A|B, where A and B can be arbitrary REs, creates a regular expression that will match either A or B. An arbitrary number of REs can be separa

[issue19055] Regular expressions: * does not match as many repetitions as possible.

Changes by Serhiy Storchaka : -- versions: +Python 3.3, Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue19055] Regular expressions: * does not match as many repetitions as possible.

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

Changes by Joseph Warren : -- resolution: -> duplicate status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

Joseph Warren added the comment: Sorry, this change does appear in 2.7.* I was looking at the wrong mercurial Tag -- ___ Python tracker ___ __

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

Joseph Warren added the comment: Have downloaded an up to date version of Python to develop with, and found that this issue had been fixed in it. This seems to have been done in changeset: 65028:7add45bcc9c6 changeset: 65028:7add45bcc9c6 user:Senthil Kumaran date:Thu Sep 3

[issue19055] Regular expressions: * does not match as many repetitions as possible.

Changes by David Benbennick : -- nosy: +dbenbenn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue19055] Regular expressions: * does not match as many repetitions as possible.

Changes by Jason Stumpf : -- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett ___ Python tracker ___ ___ Python-bugs-l

[issue19055] Regular expressions: * does not match as many repetitions as possible.

New submission from Jason Stumpf: >>> re.match('(a|ab)*',('aba')).group(0) 'a' According to the documentation, the * should match as many repetitions as possible. 2 are possible, it matches 1. Reversing the order of the operands of | changes the behaviour. >>> re.match('(ab|a)*',('aba')).gro

[issue10915] Make the PyGILState API compatible with multiple interpreters

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue15751] Support subinterpreters in the GIL state API

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue15751] Support subinterpreters in the GIL state API

Antoine Pitrou added the comment: I wanted to set issue10915 as duplicate but there is actually a tentative patch there. Unfortunately the discussions are now split apart... -- ___ Python tracker _

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > I like the definition of __sizeof__ that was discussed some time ago: > http://bugs.python.org/issue14520#msg157798 The problem is that that definition isn't helpful. If we ever change itertools.tee to use non-PyObjects internally, suddenly its sys.getsizeof()

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

R. David Murray added the comment: You are making perfect sense. My point in referencing that issue was that you are not crazy, we do indeed not handle continue correctly ;) -- ___ Python tracker

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

Joseph Warren added the comment: Issue1346874 seems similar, but is talking about a failure to handle 100 Continue responses sent by a server to the client, this issue is in server code, and is a failure of BaseHttpServer to send 100 Continue responses to a client which expects them. Please t

[issue19049] itertools.tee isn't 64-bit compliant

Serhiy Storchaka added the comment: We gain stability. I doubt we should change this. However in any case you forgot about tee_reduce(). -- ___ Python tracker ___ _

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > getsizeof() is interesting only if it gives sensible results when used > correctly, especially if you want to sum these values and get a global > memory usage. "Getting a global memory usage" isn't a correct use of getsizeof(), though, because it totally ignor

[issue19049] itertools.tee isn't 64-bit compliant

Antoine Pitrou added the comment: > I doubt we should change this. Currently itertools.tee() will break if more than 2**31 elements are saved in the inner structures. I certainly think it should be fixed, rather than bite someone by surprise one day. > However in any case you forgot about tee_r

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > Optionally we can also not count objects which are referenced from > outside of a graph of objects (this isn't so easy implement in > Python). I.e. gettotalsizeof([1, 'abc', math.sqrt(22)], inner=True) > will count only bare list and a square of 22, because 1 a

[issue19048] itertools.tee doesn't have a __sizeof__ method

Martin v. Löwis added the comment: > The problem is that that definition isn't helpful. > If we ever change itertools.tee to use non-PyObjects internally, s > suddenly its sys.getsizeof() would have to return much larger numbers > despite visible behaviour not having changed at all (and despite

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > I see no problem with that. If the internal representation changes, > nobody should be surprised if sizeof changes. Who is "nobody"? Users aren't aware of internal representation changes. It sounds like you want sys.getsizeof() to be a tool for language implem

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: Optionally we can also not count objects which are referenced from outside of a graph of objects (this isn't so easy implement in Python). I.e. gettotalsizeof([1, 'abc', math.sqrt(22)], inner=True) will count only bare list and a square of 22, because 1 and

[issue3982] support .format for bytes

Augie Fackler added the comment: I'd like to put a nudge towards supporting the __mod__ interface on bytes - for Mercurial this is the single biggest impediment to even getting our testrunner working, much less starting the porting process. -- nosy: +durin42 __

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > It's why sys.getsizeof() is a low-level tool. We need high-level tool > in the stdlib. Even imperfect recursive counting will be better than > confusing for novices sys.getsizeof(). Ok, but I need to see a satisfying version of "gettotalsizeof" before I'm conv

[issue19049] itertools.tee isn't 64-bit compliant

Antoine Pitrou added the comment: > I don't think we need Py_ssize_t for integers from 0 to 57. IMO it's better to use Py_ssize_t there, since it can get combined with other Py_ssize_t values. Avoiding spurious conversions eliminates a common source of errors. We don't gain anything by keeping i

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > Well. itertools._tee is one Python object and > itertools._tee_dataobject is another Python object. sys.getsizeof() > gives you the memory usage of this objects separately. This is great... And how do I know that I need to use gc.get_referents() to get those o

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: (By the way, OrderedDict.__sizeof__ already breaks the rule you are trying to impose) -- ___ Python tracker ___ ___

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: Here is why using get_referents() is stupid in the general case: >>> class C: pass ... >>> c = C() >>> gc.get_referents(c) [] With your method, measuring c's memory consumption also includes the memory consumption of its type object. (and of course this is on

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: > How do you stop walking your graph if it spans the whole graph of Python > objects? We can stop at specific types of objects (for example types and modules). > If sys.getsizeof() is only useful for people who know *already* how an object is implemented int

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: Well. itertools._tee is one Python object and itertools._tee_dataobject is another Python object. sys.getsizeof() gives you the memory usage of this objects separately. -- ___ Python tracker

[issue19049] itertools.tee uses int for indices

Antoine Pitrou added the comment: Ah, my bad, it seems I misunderstood the tee() implementation. So apparenly even index cannot get past 57. It's more of a consistency patch then, and I agree it isn't very important. -- priority: normal -> low stage: needs patch -> patch review title:

[issue19054] Descriptors howto

Changes by Marco Buttu : -- keywords: +patch Added file: http://bugs.python.org/file31820/py3howto.patch ___ Python tracker ___ ___ Py

[issue19048] itertools.tee doesn't have a __sizeof__ method

Amaury Forgeot d'Arc added the comment: getsizeof() is interesting only if it gives sensible results when used correctly, especially if you want to sum these values and get a global memory usage. One usage is to traverse objects through gc.get_referents(); in this case the definition above is

[issue19054] Descriptors howto

Changes by Marco Buttu : Added file: http://bugs.python.org/file31821/py2howto.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > Isn't sys.getsizeof() a low-level debugging tool? What would it help debug exactly? :-) I would hope it gives remotely useful information about the passed object. -- ___ Python tracker

[issue19053] read1() from zipfile returns empty data

Serhiy Storchaka added the comment: Here is a patch. -- keywords: +patch Added file: http://bugs.python.org/file31819/zipfile_read1.patch ___ Python tracker ___ _

[issue19053] read1() from zipfile returns empty data

Changes by Serhiy Storchaka : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue19054] Descriptors howto

New submission from Marco Buttu: I think in the descriptor howto, at this point: >>> class MyClass(object): x = RevealAccess(10, 'var "x"') y = 5 or the prompt should not have been, or there is a wrong indentation. Furthermore, in Python 3: http://docs.python.org/3/howto/descriptor.htm

[issue19049] itertools.tee isn't 64-bit compliant

Serhiy Storchaka added the comment: I don't think we need Py_ssize_t for integers from 0 to 57. -- ___ Python tracker ___ ___ Python-b

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

R. David Murray added the comment: I think we can fix this in maintenance releases without breaking anyone's code, so a patch against both 2.7 and 3.3 would be ideal. A patch against 3.2 will probably apply cleanly to 3.3, so that should be fine as well. Thanks for working on this, and could

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

Joseph Warren added the comment: Cheers, would you suggest I submit a patch then? Also what version of python should I do this against? I've been working with 2.7, but the issue still exists in 3.* and I can conveniently work against 3.2.3-7, and less conveniently work against other versions.

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: Isn't sys.getsizeof() a low-level debugging tool? -- ___ Python tracker ___ ___ Python-bugs-list m

[issue19048] itertools.tee doesn't have a __sizeof__ method

Amaury Forgeot d'Arc added the comment: I like the definition of __sizeof__ that was discussed some time ago: http://bugs.python.org/issue14520#msg157798 With that definition (do we have it somewhere in the docs, by the way?) The current code works gives the correct answer. -- nosy: +am

[issue19051] Unify buffered readers

Changes by Serhiy Storchaka : -- Removed message: http://bugs.python.org/msg198083 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

R. David Murray added the comment: See also issue 1346874. It seems that we do not currently handle 'continue' correctly in general. -- nosy: +r.david.murray ___ Python tracker ___

[issue19051] Unify buffered readers

Serhiy Storchaka added the comment: This primitive doesn't not well fit a case of compressed streams. A chunk of compressed data read from underlied file object can be uncompressed to unpredictable large data. We can't limit the size of buffer. Another point is that buffer interface is not ver

[issue18553] os.isatty() is not Unix only

Senthil Kumaran added the comment: Hello Dmi, > I having a snippet to fix that, should I open a new issue for patch? Please open a new issue. Thanks! -- ___ Python tracker ___

[issue19051] Unify buffered readers

Serhiy Storchaka added the comment: This primitive doesn't not well fit a case of compressed streams. A chunk of compressed data read from underlied file object can be uncompressed to unpredictable large data. We can't limit the size of buffer. Another point is that buffer interface is not ver

[issue12053] Add prefetch() for Buffered IO (experiment)

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

New submission from Joseph Warren: I will add as a disclaimer to this bug report that I am relatively new to both the http spec, and Python programming, so I may have completely misunderstood something. When I make a post request with some data (using libCurl), It sends the headers first, inc

[issue11798] Test cases not garbage collected after run

Antoine Pitrou added the comment: > Unfortunately the TestSuite.addTests api iterates over a suite to add > new tests. i.e. the code that builds a TestSuite for module probably > already iterates over the suites returned by > TestLoader.loadTestsFromTestCase - so the change would need to be > mor

[issue19052] Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.

Changes by Antoine Pitrou : -- nosy: +orsenthil type: performance -> enhancement versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5 ___ Python tracker __

[issue19053] read1() from zipfile returns empty data

New submission from Serhiy Storchaka: Bzip2 is block-based compression with large (up to 800 Kb) size of block. It means that while decompressor not read enough data it can't produce any output (actually this issue exists for other compression algorithms too, but less frequent). And the read1(

[issue18553] os.isatty() is not Unix only

Dmi Baranov added the comment: I found a little difference in isatty implementaions: Windows Determines whether a file descriptor is associated with a character device [1] Unix Test whether a file descriptor refers to a terminal [2] So, we having a same behavior for pipes, but different for I/

[issue19051] Unify buffered readers

Antoine Pitrou added the comment: See issue12053 for a more flexible primitive. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue19051] Unify buffered readers

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file31817/read_bench_cmp ___ Python tracker ___ ___ Python-bugs-list mailing

[issue19051] Unify buffered readers

Serhiy Storchaka added the comment: Here are benchmark script and its results. -- Added file: http://bugs.python.org/file31816/read_bench.py ___ Python tracker ___ __

[issue11798] Test cases not garbage collected after run

Michael Foord added the comment: Having TestLoader.loadTestsFromTestCase() return a "lazy suite" that defers testcase instantiation until iteration is a nice idea. Unfortunately the TestSuite.addTests api iterates over a suite to add new tests. i.e. the code that builds a TestSuite for module

[issue19051] Unify buffered readers

New submission from Serhiy Storchaka: There are some classes in gzip, bz2, lzma, and zipfile modules which implement buffered reader interface. They read chunks of data from underlied file object, decompress it, save in internal buffer, and provide common methods to read from this buffer. Main

[issue10042] functools.total_ordering fails to handle NotImplemented correctly

Drekin added the comment: Hello, I have run into this when I wanted to use OrderedEnum and the example in enum docs seemed too repetitive to me. It's nice to know that it's being worked on. -- nosy: +Drekin ___ Python tracker

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > The point is that your patch breaks functions like gettotalsizeof(). > It makes impossible to get a total size of general object. The thing is, "Total size" is generally meaningless. It can include things such as the object's type, or anything transitively ref

[issue11798] Test cases not garbage collected after run

Antoine Pitrou added the comment: That said, I agree that the __dict__ proposal is a hack, but as is the current _removetestAtIndex mechanism. The only clean solution I can think of would be to have two separate classes: - a TestSpec which contains execution-independent data about a test case,

[issue11798] Test cases not garbage collected after run

Michael Foord added the comment: Ah right, my mistake. Before setUp there shouldn't be test state. (Although tests are free to do whatever they want in __init__ too and I've seen plenty of TestCase subclasses using __init__ when they should be using setUp.) Essentially though _cleanup is a bac

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: The point is that your patch breaks functions like gettotalsizeof(). It makes impossible to get a total size of general object. It will be better to add gettotalsizeof() to the stdlib (or add an optional parameter to sys.getsizeof() for recursive counting).

[issue11798] Test cases not garbage collected after run

Antoine Pitrou added the comment: > If the object state includes mutable objects then restoring the > previous dictionary will just restore the same mutable (and likely > mutated) object. I don't understand what you're talking about. Which mutable objects exactly? I'm talking about copying the d

[issue11798] Test cases not garbage collected after run

Michael Foord added the comment: On 19 Sep 2013, at 14:06, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> That would only be a shallow copy, so I'm not sure it's worth the >> effort. The test has the opportunity in the setUp to ensure that >> initial state is correct - so I

[issue19047] Assorted weakref docs improvements

Nick Coghlan added the comment: I was initially thinking to myself "I have a source checkout right here, I should just fix it, even though I'm at work and want to go home"... and then I realised the potential scope of the fixes needed, given the longstanding misbehaviours these docs assume still

[issue11798] Test cases not garbage collected after run

Antoine Pitrou added the comment: > That would only be a shallow copy, so I'm not sure it's worth the > effort. The test has the opportunity in the setUp to ensure that > initial state is correct - so I would leave that per test. I don't understand your objection. The concern is to get rid of ol

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > Thy are visible by calling gc.get_referents(). That's totally besides the point. The point is that those objects are invisible in normal conditions, not that they can't be read using advanced implementation-dependent tricks. -- __

[issue19050] crash while writing to a closed file descriptor

Daniel Rohlfing added the comment: the correct snippet is: > fd = io.open(sys.stdout.fileno(), 'wb') > fd.close() > sys.stdout.write("now writing on stdout will cause a crash") -- ___ Python tracker __

[issue19050] crash while writing to a closed file descriptor

New submission from Daniel Rohlfing: This snippet let my interpreter crash immediately: > import sys, io > io.open(sys.stdout.fileno(), 'wb') > fd.close() > sys.stdout.write("now writing on stdout will cause a crash") That's happened on Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500

[issue12944] Accept arbitrary files for packaging's upload command

Changes by Florent Rougon : -- nosy: +frougon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue11798] Test cases not garbage collected after run

Michael Foord added the comment: That would only be a shallow copy, so I'm not sure it's worth the effort. The test has the opportunity in the setUp to ensure that initial state is correct - so I would leave that per test. Obviously sharing state between tests is prima facie bad, but any frame

[issue11798] Test cases not garbage collected after run

Antoine Pitrou added the comment: Ideally, test specification should be separate from test execution. That is, it should be possible to keep the TestCase around (or whatever instantiates it, e.g. a factory) but get rid of its per-test-execution attributes. Perhaps restoring the original __dict

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: Thy are visible by calling gc.get_referents(). High-level function can use this to count recursive size of objects. >>> import sys, gc, itertools >>> def gettotalsizeof(*args, seen=None): ... if seen is None: ... seen = {} ... sum = 0 ...

[issue19049] itertools.tee isn't 64-bit compliant

Antoine Pitrou added the comment: Simple patch attached. -- keywords: +patch Added file: http://bugs.python.org/file31814/tee_64b.patch ___ Python tracker ___ ___

[issue19043] Remove detailed listing of all versions from LICENSE, Doc/license.rst

Antoine Pitrou added the comment: Looks good to me. Python 1.5.2 (which I've never used) is the best Python anyway! -- nosy: +pitrou ___ Python tracker ___ _

[issue19047] Assorted weakref docs improvements

Antoine Pitrou added the comment: Doc patches certainly welcome :-) -- nosy: +pitrou, sbt ___ Python tracker ___ ___ Python-bugs-list

[issue19046] SystemError: ..\Objects\weakrefobject.c:903: bad argument to internal function

Antoine Pitrou added the comment: Is there any reason why you don't switch to 2.7.5 and let your application run longer? (FWIW, this may be issue #16602) -- nosy: +pitrou ___ Python tracker __

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: > I'm not sure that sys.getsizeof() should recursively count all Python > subobjects. Those are private subobjects. They are not visible to the programmer (except perhaps by calling __reduce__ or __setstate__). -- __

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: I'm not sure that sys.getsizeof() should recursively count all Python subobjects. That is why I had omitted tee() in my patch. >>> sys.getsizeof([[]]) 36 >>> sys.getsizeof([list(range(1))]) 36 -- ___ Python tr

[issue19048] itertools.tee doesn't have a __sizeof__ method

Changes by Serhiy Storchaka : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: Hmm, no, I'm wrong, it's not a duplication. -- superseder: Correct __sizeof__ support for itertools -> ___ Python tracker ___ ___

[issue19048] itertools.tee doesn't have a __sizeof__ method

Serhiy Storchaka added the comment: This is a duplicate of issue15475. -- superseder: -> Correct __sizeof__ support for itertools ___ Python tracker ___

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: Anywhere, here is a patch. -- keywords: +patch Added file: http://bugs.python.org/file31813/tee_sizeof.patch ___ Python tracker ___

[issue19048] itertools.tee doesn't have a __sizeof__ method

Antoine Pitrou added the comment: I find the implementation of itertools.tee a bit weird: why does teedataobject have to be a PyObject? It seems to complicate things and make them less optimal. -- ___ Python tracker

[issue19049] itertools.tee isn't 64-bit compliant

New submission from Antoine Pitrou: itertools.tee uses ints rather than Py_ssize_t for indices. Using Py_ssize_t would not make the object bigger, since other fields will already be pointer-aligned. -- messages: 198049 nosy: pitrou, rhettinger, serhiy.storchaka priority: normal severit

  1   2   >