[issue15494] Move test/support.py into a test.support subpackage

Martin v. Löwis added the comment: -1. test.support is not at all too large for a single module; there is no point in refactoring it. Without a specific patch to review which proposes some specific change, I'm rejecting this change request. -- nosy: +loewis resolution: -> rejected st

[issue15232] email.generator.Generator doesn't mangle "From " lines in MIME preamble

Chris Pickett added the comment: Thanks everyone! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue15471] importlib's __import__() argument style nit

Meador Inge added the comment: How about the attached? -- keywords: +patch nosy: +meador.inge stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file26592/issue-15471.patch ___ Python tracker

[issue15497] correct characters in TextWrapper.replace_whitespace docs

New submission from Chris Jerdonek: This issue is to correct the list of whitespace characters to replace in the documentation for the textwrap module's TextWrapper.replace_whitespace attribute. The documentation says this list is string.whitespace: http://docs.python.org/dev/library/textwrap

[issue15494] Move test/support.py into a test.support subpackage

Nick Coghlan added the comment: Note that I don't think test.support itself should be broken up - I don't see any good reason to split the current grab bag of functionality out into submodules, so you'd just have support/__init__.py open instead. This is really about giving us a better way to

[issue15496] harden directory removal for tests on Windows

New submission from Jeremy Kloth: Currently, removing directories during testing on Windows w/NTFS can causing sporadic failures due to access denied errors. This is caused by other processes getting a handle to the directory itself (change notifications) or a handle to a file within the dire

[issue15494] Move test/support.py into a test.support subpackage

Ezio Melotti added the comment: I'd prefer to keep test.support as a single module, rather than converting it to a package. Most of the time I open up test.support when I'm trying to find some function, so having more files will only make this more complicated. -- nosy: +ezio.melotti t

[issue15454] Allow dircmp.report() output stream to be customized

Changes by Chris Calloway : -- nosy: +cbc ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue15495] enable type truncation warnings for gcc builds

Changes by Antoine Pitrou : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue15495] enable type truncation warnings for gcc builds

New submission from Jeremy Kloth: It would seem that enabling GCC's type conversion/truncation warnings would be a good thing for Python builds. This would bring GCC builds in line with MSVC builds and reduce the burden on the Windows developers in fixing them. Also, it would bring attention

[issue15403] Refactor package creation support code into a common location

Chris Jerdonek added the comment: > Later today I will create an issue to move test/support.py into a > test.support subpackage post-release. I created issue 15494 for this. -- ___ Python tracker

[issue15494] Move test/support.py into a test.support subpackage

Chris Jerdonek added the comment: If people are okay with populating test/support/__init__.py with code (at least initially), the first patch could be to move support.py into test/support/__init__.py. One nice thing about this approach is that the calling code won't need to change. The seco

[issue15403] Refactor package creation support code into a common location

Chris Jerdonek added the comment: Sounds good. Later today I will create an issue to move test/support.py into a test.support subpackage post-release. We can continue the discussion of how to organize it there. -- ___ Python tracker

[issue15494] Move test/support.py into a test.support subpackage

New submission from Chris Jerdonek: This issue is to move test/support.py into a test.support subpackage as discussed in issue 15403. This can be done post-release. -- components: Tests messages: 166848 nosy: cjerdonek, ncoghlan, pitrou priority: normal severity: normal status: open ti

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Nick Coghlan added the comment: The "release blocker" status comes from the test case I added in order to demonstrate the ability to strip a new frame sequence without needing to modify the C code. Currently that test (failing to write the PYC file) fails with an IsADirectory traceback that i

[issue15452] Improve the security model for logging listener()

Nick Coghlan added the comment: Yep, that's exactly the kind of hook I had in mind. That way the user can decide for themselves what level of scrutiny they want to apply. -- title: Eliminate the use of eval() in the logging config implementation -> Improve the security model for loggin

[issue15403] Refactor package creation support code into a common location

Nick Coghlan added the comment: Discoverability is definitely a problem - part of that is a docs issue, since test.support is currently the only one mentioned in the prose docs. One advantage to moving to a support subpackage is that we can lose the "helper" suffix from the names, while still

[issue14803] Add feature to allow code execution prior to __main__ invocation

Antoine Pitrou added the comment: Le lundi 30 juillet 2012 à 00:55 +, Nick Coghlan a écrit : > However, the -C option doesn't cover the case of *implicit* invocation > of subprocesses. This is where the PYTHONRUNFIRST suggestion comes in > - the idea would that, unless -E is specified, then -

[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

Antoine Pitrou added the comment: > This is especially so with Python 2.7 still having a couple of years > of full maintenance left - that's a long time to leave it with a known > broken memoryview implementation. I'm less worried about 3.2, since > the upgrade path to 3.3 is easier in that case,

[issue14803] Add feature to allow code execution prior to __main__ invocation

Nick Coghlan added the comment: There are two different use cases here. "-C" tackles one of them, "PYTHONRUNFIRST" the other. My original use case came from working on the Python test suite. In that suite, we have "test.script_helper" which spawns Python subprocesses in order to test various

[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

Nick Coghlan added the comment: I suspect the need to preserve the C ABI would make a complete backport a challenge. I'm still tempted though, mainly to give third parties a robust core implementation of the buffer API to test against. This is especially so with Python 2.7 still having a coupl

[issue15482] __import__() change between 3.2 and 3.3

Brett Cannon added the comment: On Jul 29, 2012 5:58 AM, "Martin v. Löwis" wrote: > > > Martin v. Löwis added the comment: > > So should 3.2 be changed to adjust the default value to match the documentation? It is probably safe to do so. -brett > > -- > nosy: +loewis > > _

[issue15473] importlib no longer uses imp.NullImporter

Brett Cannon added the comment: On Jul 29, 2012 12:21 AM, "Nick Coghlan" wrote: > > > Nick Coghlan added the comment: > > See the porting notes: http://docs.python.org/dev/whatsnew/3.3.html#porting-python-code > > With the removal of the implicit default finder, the 3.3 semantics are that both N

[issue15464] ssl: add set_msg_callback function

Thiébaud Weksteen added the comment: I've updated the patch with this method of testing. -- Added file: http://bugs.python.org/file26589/ssl_msg_callback-0.2.patch ___ Python tracker ___

[issue15295] Import machinery documentation

Brett Cannon added the comment: On Jul 29, 2012 2:09 AM, "Nick Coghlan" wrote: > > > Nick Coghlan added the comment: > > General comment: > > runpy, pkgutil, et al should all get "See Also" links at the top pointing to the new import system section. > > Import system intro: > > As noted above, I

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

Chris Jerdonek added the comment: > > (3) the branch name should be diplayed somewhere on the page when > > browsing (or better yet, also in the URL itself). > > This seems to be a bug in hgweb, and you should report it upstream. I filed an issue for this upstream as you suggested: http://bz.s

[issue14973] restore python2 unicode literals in "ur" strings

Christian Heimes added the comment: As of #15096 I've closed this bug as "won't fix". -- nosy: +christian.heimes resolution: -> wont fix status: open -> closed ___ Python tracker __

[issue15493] No more Daily OS X installers

Martin v. Löwis added the comment: > Well, I said it ("The upload directory is wrong in the buildmaster > configuration, I'm trying to fix that"), but perhaps it was too late. Yes, tough luck. -- ___ Python tracker

[issue15493] No more Daily OS X installers

Roundup Robot added the comment: New changeset 89d9874dfd13 by Antoine Pitrou in branch 'default': Closes #15493: fix link to daily DMG installer http://hg.python.org/devguide/rev/89d9874dfd13 -- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed

[issue15493] No more Daily OS X installers

Antoine Pitrou added the comment: Well, I said it ("The upload directory is wrong in the buildmaster configuration, I'm trying to fix that"), but perhaps it was too late. -- ___ Python tracker

[issue15493] No more Daily OS X installers

Martin v. Löwis added the comment: Actually, I had created a different directory. I wish you had said from the beginning that you were going to look into it; it would have saved me some time. -- ___ Python tracker

[issue15493] No more Daily OS X installers

Martin v. Löwis added the comment: > No need to create it, I've already pointer the master.cfg to another > directory (/data/www/buildbot/daily-dmg). And indeed, that's the directory that I have just created. I also had it put into the master.cfg, but you apparently overwrote my edit. -

[issue15493] No more Daily OS X installers

Antoine Pitrou added the comment: > I have now created the upload directory, let's see whether it fills > (and no, it's still not on dinsdale). No need to create it, I've already pointer the master.cfg to another directory (/data/www/buildbot/daily-dmg). --

[issue15493] No more Daily OS X installers

Martin v. Löwis added the comment: > I'm not sure who set up the web site link. The current version of that link comes from Antoine Pitrou; I believe I put the original version on the website (before Brett moved it into the devguide). The DMG uploading really can't work anymore since buildbot

[issue15493] No more Daily OS X installers

Antoine Pitrou added the comment: > It looks like the buildbot is still building them: > http://buildbot.python.org/all/buildslaves/bolen-dmg > > I'm not sure who set up the web site link. The upload directory is wrong in the buildmaster configuration, I'm trying to fix that. -- _

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

Ezio Melotti added the comment: > So there may be three issues here: > (1) the Dev Guide links to the revision list rather than directly > to the browser, This is now fixed. > (2) browsing defaults to browsing 2.7 rather than the default branch, This is fixed as well. FTR it's not defaulting

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

Roundup Robot added the comment: New changeset 54ec1b493006 by Ezio Melotti in branch 'default': #15491: change a couple more links to point to the "default" branch. http://hg.python.org/devguide/rev/54ec1b493006 -- ___ Python tracker

[issue15493] No more Daily OS X installers

Ned Deily added the comment: It looks like the buildbot is still building them: http://buildbot.python.org/all/buildslaves/bolen-dmg I'm not sure who set up the web site link. -- ___ Python tracker ___

[issue15493] No more Daily OS X installers

New submission from Antoine Pitrou: The "Daily OS X installer" link in the devguide points to an empty directory (http://www.python.org/dev/daily-dmg/). -- components: Devguide messages: 166822 nosy: ezio.melotti, ned.deily, pitrou, ronaldoussoren priority: low severity: normal status:

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

Antoine Pitrou added the comment: The "snapshot of py3k" link has the same issue. -- nosy: +pitrou ___ Python tracker ___ ___ Python-b

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

Roundup Robot added the comment: New changeset 0529e2062ec7 by Ezio Melotti in branch 'default': #15491: link to the file list of the "default" branch. http://hg.python.org/devguide/rev/0529e2062ec7 -- nosy: +python-dev ___ Python tracker

[issue15489] Correct __sizeof__ support for BytesIO

Antoine Pitrou added the comment: Thank you! -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___

[issue15489] Correct __sizeof__ support for BytesIO

Roundup Robot added the comment: New changeset 1d3155750808 by Antoine Pitrou in branch '3.2': Issue #15489: Add a __sizeof__ implementation for BytesIO objects. http://hg.python.org/cpython/rev/1d3155750808 New changeset 917295aaad76 by Antoine Pitrou in branch 'default': Issue #15489: Add a __

[issue15421] Calendar.itermonthdates OverflowError

Changes by Ezio Melotti : -- nosy: +belopolsky, ezio.melotti, rhettinger stage: -> patch review type: enhancement -> behavior versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker __

[issue15451] PATH is not honored in subprocess.Popen in win32

Richard Oudkerk added the comment: > What I understand you two as saying is that there seems to be an > undocumented difference in execxxe between unix and windows which has been > carried over to subprocess. No. There is no difference between the platforms in the behaviour of os.execvpe().

[issue1859] textwrap doesn't linebreak on "\n"

Chris Jerdonek added the comment: If people are interested, I filed a new issue (issue 15492) about textwrap's tab expansion that I noticed while working on this issue. -- ___ Python tracker ___

[issue15492] textwrap.wrap expand_tabs does not behave as expected

New submission from Chris Jerdonek: While working on issue 1859, I noticed that textwrap.wrap()'s tab expansion does not seem to behave sensibly. In particular, the documentation says, "If expand_tabs is true, then all tab characters in text will be expanded to zero or more spaces, *depending

[issue15490] Correct __sizeof__ support for StringIO

Martin v. Löwis added the comment: The question really is what memory blocks can "leak out" of the object, and those don't really belong to the container. Those shouldn't be accounted for, since somebody else may get hold of them, and pass them to sys.sizeof. For the PyAccu, AFAICT, objects ca

[issue15490] Correct __sizeof__ support for StringIO

Antoine Pitrou added the comment: > > For some value of "correct", since the internal accumulator could hold > > alive some unicode strings. > > This is not a concern of __sizeof__, because these lists and strings are > managed by GC. It is, since they are private and not known by the user. -

[issue15490] Correct __sizeof__ support for StringIO

Serhiy Storchaka added the comment: > For some value of "correct", since the internal accumulator could hold > alive some unicode strings. This is not a concern of __sizeof__, because these lists and strings are managed by GC. > There's no narrow build anymore on 3.3. I mean 2.7 and 3.2. I ha

[issue1859] textwrap doesn't linebreak on "\n"

Chris Jerdonek added the comment: Sorry, that link should have been-- http://hg.python.org/cpython/file/1d811e1097ed/Lib/textwrap.py#l12 (hg.python.org seems to default to the 2.7 branch. I just filed an issue about this.) -- ___ Python tracker <

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

New submission from Chris Jerdonek: I'm not sure if I'm filing this in the right place since I don't see hg.python.org in the tracker "components" list, but if one clicks on the "Browse online" link of the Dev Guide here: http://docs.python.org/devguide/ One is taken to-- http://hg.python.or

[issue1859] textwrap doesn't linebreak on "\n"

Chris Jerdonek added the comment: In working on the patch for this issue, I also noticed that there is a minor error in the documentation of the replace_whitespace attribute. The docs say that string.whitespace is used, but the code uses a hard-coded string and includes a comment explaining wh

[issue15490] Correct __sizeof__ support for StringIO

Antoine Pitrou added the comment: > Here is a patch that implements correct __sizeof__ for C implementation of > io.StringIO. For some value of "correct", since the internal accumulator could hold alive some unicode strings. > I haven't tested the patch on narrow build. There's no narrow buil

[issue15490] Correct __sizeof__ support for StringIO

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26587/stringio_sizeof-3.2.patch ___ Python tracker ___ ___ Python-bugs-li

[issue15490] Correct __sizeof__ support for StringIO

New submission from Serhiy Storchaka: Here is a patch that implements correct __sizeof__ for C implementation of io.StringIO. I haven't tested the patch on narrow build. -- components: IO, Library (Lib) files: stringio_sizeof-3.3.patch keywords: patch messages: 166807 nosy: benjamin.pe

[issue15490] Correct __sizeof__ support for StringIO

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26588/stringio_sizeof-2.7.patch ___ Python tracker ___ ___ Python-bugs-li

[issue15489] Correct __sizeof__ support for BytesIO

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26584/bytesio_sizeof-3.2.patch ___ Python tracker ___ ___ Python-bugs-lis

[issue15489] Correct __sizeof__ support for BytesIO

New submission from Serhiy Storchaka: Here is a patch that implements correct __sizeof__ for C implementation of io.BytesIO. -- components: IO, Library (Lib) files: bytesio_sizeof-3.3.patch keywords: patch messages: 166806 nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach pri

[issue15489] Correct __sizeof__ support for BytesIO

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26585/bytesio_sizeof-2.7.patch ___ Python tracker ___ ___ Python-bugs-lis

[issue15469] Correct __sizeof__ support for deque

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26582/deque_sizeof-2.7-2.patch ___ Python tracker ___ ___ Python-bugs-lis

[issue15469] Correct __sizeof__ support for deque

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26581/deque_sizeof-3.2-2.patch ___ Python tracker ___ ___ Python-bugs-lis

[issue15469] Correct __sizeof__ support for deque

Serhiy Storchaka added the comment: Patches updated. Now __sizeof__ is O(1) as Martin advised. -- Added file: http://bugs.python.org/file26580/deque_sizeof-3.3-2.patch ___ Python tracker ___

[issue15488] Closed files keep their buffer alive

Benjamin Peterson added the comment: Sounds reasonable to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15451] PATH is not honored in subprocess.Popen in win32

Terry J. Reedy added the comment: What I understand you two as saying is that there seems to be an undocumented difference in execxxe between unix and windows which has been carried over to subprocess. In particular, for both, the PATH component of the env parameter is used to search for the f

[issue633930] Nested class __name__

Stefan Mihaila added the comment: Only an issue in Python2. >>> A.B.__qualname__ 'A.B' >>> repr(A.B) "" -- nosy: +mstefanro versions: +Python 2.6, Python 2.7 ___ Python tracker ___

[issue15488] Closed files keep their buffer alive

Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue15488] Closed files keep their buffer alive

Changes by Antoine Pitrou : -- nosy: +benjamin.peterson, hynek, stutzbach ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue15488] Closed files keep their buffer alive

New submission from Antoine Pitrou: >>> f = open("LICENSE", "rb") >>> sys.getsizeof(f) 4296 >>> f.close() >>> sys.getsizeof(f) 4296 Instead of waiting for the file object's deallocation, perhaps we should free the buffer when it is closed? -- components: IO, Library (Lib) messages: 166

[issue15487] Correct __sizeof__ support for buffered I/O

Antoine Pitrou added the comment: Le dimanche 29 juillet 2012 à 17:45 +, Meador Inge a écrit : > Anyway, the way you are implementing the tests has the same issue as Martin > pointed > out for the 'object.__sizeof__' method in issue15402. I could replace the > 'buffered_sizeof' implementat

[issue15487] Correct __sizeof__ support for buffered I/O

Meador Inge added the comment: On Sun, Jul 29, 2012 at 11:50 AM, Serhiy Storchaka wrote: >> Serhiy, I didn't analyze it too in depth, but why aren't the test cases >> using the __sizeof__ support work you implemented for issue15467? I think >> these tests should be using the more exact method

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Antoine Pitrou added the comment: That said, given the nature of the patch (a cleanup without any functional impact), I don't think it should be a release blocker. -- ___ Python tracker ___

[issue15452] Eliminate the use of eval() in the logging config implementation

Vinay Sajip added the comment: > As far as your other suggestion goes, don't reinvent crypto badly - > if you want to provide authentication support in listener(), provide a > hook that allows the application to decide whether or not to accept > the configuration before it gets applied. Well, th

[issue15436] __sizeof__ is not documented

Martin v. Löwis added the comment: > I think there is one difference between __len__ and __sizeof__. __sizeof__ > should be overloaded only for C-implemented classes. IMHO, it is a part of C > API. That is a reasonable point. So documenting it along with the type slots might be best.

[issue15487] Correct __sizeof__ support for buffered I/O

Antoine Pitrou added the comment: Thanks for the patch :) -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue15487] Correct __sizeof__ support for buffered I/O

Roundup Robot added the comment: New changeset 1102e86b8739 by Antoine Pitrou in branch '2.7': Issue #15487: Add a __sizeof__ implementation for buffered I/O objects. http://hg.python.org/cpython/rev/1102e86b8739 -- ___ Python tracker

[issue15403] Refactor package creation support code into a common location

Antoine Pitrou added the comment: Le dimanche 29 juillet 2012 à 17:00 +, Chris Jerdonek a écrit : > Chris Jerdonek added the comment: > > > Less favorable, because it produces longer import strings > ("test.support.some_helper" instead of "test.some_helper"). > > This can be addressed by ex

[issue15487] Correct __sizeof__ support for buffered I/O

Roundup Robot added the comment: New changeset 8a02a93c803a by Antoine Pitrou in branch '3.2': Issue #15487: Add a __sizeof__ implementation for buffered I/O objects. http://hg.python.org/cpython/rev/8a02a93c803a New changeset 1d811e1097ed by Antoine Pitrou in branch 'default': Issue #15487: Add

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

Georg Brandl added the comment: Please reopen if you think it should be backported. -- ___ Python tracker ___ ___ Python-bugs-list m

[issue15403] Refactor package creation support code into a common location

Chris Jerdonek added the comment: > Less favorable, because it produces longer import strings ("test.support.some_helper" instead of "test.some_helper"). This can be addressed by exposing the API in __init__.py though (as does, say, the unittest package), no? -- __

[issue15436] __sizeof__ is not documented

Serhiy Storchaka added the comment: > sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not > just an implementation detail of sys.getsizeof, just as __len__ is not an > implementation detail of len(). Authors of extension types are supposed to > implement it if object.__sizeof_

[issue15403] Refactor package creation support code into a common location

Antoine Pitrou added the comment: > Are you opposed to (2), or is it simply less favorable? Less favorable, because it produces longer import strings ("test.support.some_helper" instead of "test.some_helper"). -- ___ Python tracker

[issue15403] Refactor package creation support code into a common location

Chris Jerdonek added the comment: Thanks for your thoughts. For the purposes of this patch, I will change to putting the new support functionality in test.support. Going forward, if we could do some of the refactoring for 3.3.1, that would be great. :) I worry that the third option may make

[issue15487] Correct __sizeof__ support for buffered I/O

Serhiy Storchaka added the comment: > Serhiy, I didn't analyze it too in depth, but why aren't the test cases > using the __sizeof__ support work you implemented for issue15467? I think > these tests should be using the more exact method like your other > '__sizeof__' patches. Because struct ha

[issue14803] Add feature to allow code execution prior to __main__ invocation

Chris Jerdonek added the comment: Okay, then in the interest of understanding why various alternatives fail, I'll just throw out the suggestion or question that I had in mind because I don't see it mentioned above or on the web page. Why wouldn't it work to define an alias or script that invok

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue15487] Correct __sizeof__ support for buffered I/O

Serhiy Storchaka added the comment: > Instead of putting this in MiscIOTest, you could use the relevant > class-specific test cases. Thank you, good advice. Here is updated patch. -- Added file: http://bugs.python.org/file26579/bufferedio_sizeof-2.patch

[issue15487] Correct __sizeof__ support for buffered I/O

Meador Inge added the comment: Serhiy, I didn't analyze it too in depth, but why aren't the test cases using the __sizeof__ support work you implemented for issue15467? I think these tests should be using the more exact method like your other '__sizeof__' patches. -- nosy: +meador.in

[issue15436] __sizeof__ is not documented

Martin v. Löwis added the comment: rhettinger: users frequently need sys.getsizeof. See, for example, http://stackoverflow.com/questions/1331471/in-memory-size-of-python-stucture http://stackoverflow.com/questions/449560/how-do-i-determine-the-size-of-an-object-in-python http://stackoverflow.com

[issue15475] Correct __sizeof__ support for itertools

Serhiy Storchaka added the comment: Sorry, on Martin's remarks. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue15475] Correct __sizeof__ support for itertools

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26578/itertools_sizeof-2.7-2.patch ___ Python tracker ___ ___ Python-bugs

[issue15475] Correct __sizeof__ support for itertools

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file26577/itertools_sizeof-3.2-2.patch ___ Python tracker ___ ___ Python-bugs

[issue15475] Correct __sizeof__ support for itertools

Serhiy Storchaka added the comment: Patches updated on Meador's remarks. Tests updated to use new test.support helpers. -- Added file: http://bugs.python.org/file26576/itertools_sizeof-3.3-2.patch ___ Python tracker

[issue14803] Add feature to allow code execution prior to __main__ invocation

Ned Batchelder added the comment: Chris, I'm not sure how to answer your questions. The more powerful and flexible, the better. There is no "must" here. I'm looking for a way to avoid the hacks coverage.py has used in the past to measure coverage in subprocesses. A language feature that al

[issue15467] Updating __sizeof__ tests

Changes by Meador Inge : -- stage: -> committed/rejected type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15403] Refactor package creation support code into a common location

Antoine Pitrou added the comment: I don't mind refactoring test support routines in maintenance release. I said it was too late for 3.3 because the beta period is closing; but it could be fine for 3.3.1 ;) As for the way forward, I see three possibilites: 1) put everying in test.support, as a si

[issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename

Atsuo Ishimoto added the comment: +1 for keeping the file name unchanged. This solution is not very compatible with prior versions, but simple and least-surprise. I prefer other platforms than Windows to use same method to build OSError. -- ___ Pyth

[issue15403] Refactor package creation support code into a common location

Chris Jerdonek added the comment: At this point, would you advise me to add even more to the existing hodge podge, or to create a third sibling test support module? My patch adds closely related test support functionality. Incidentally, this discussion relates to the point I was getting at in

[issue633930] Nested class __name__

Cheer Xiao added the comment: There is a bigger problem: >>> class C: ... class D: ... pass ... >>> repr(C) "" >>> repr(C.D) "" Default repr on nested classes produce specious results. The problem become pratical when you have two nested classes C1.D and C2.D in module m, which en

[issue15403] Refactor package creation support code into a common location

Antoine Pitrou added the comment: > I feel like it is already too large (it is over 1750 lines), and I did > not want to create a third sibling test support module (there is also > test/script_helper.py that overlaps with test.support). Do you think > that the community would be open to refactor

  1   2   >