[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 ___

[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

[issue15488] Closed files keep their buffer alive

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

[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 ___

[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

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

[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

[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/file26584/bytesio_sizeof-3.2.patch ___ Python tracker ___ ___ Python-bugs-lis

[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

[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/file26587/stringio_sizeof-3.2.patch ___ Python tracker ___ ___ Python-bugs-li

[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

[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

[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: 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 <

[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

[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

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

[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

[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 ___

[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().

[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 __

[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 __

[issue15489] Correct __sizeof__ support for BytesIO

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

[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

[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

[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:

[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 ___

[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

[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

[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. -- _

[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: > 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: > 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

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

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

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

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

[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 __

[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

[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

[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 ___

[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

[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 > > _

[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

[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

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

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 -

[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

[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

[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

[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

[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

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: > 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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

<    1   2