[issue17227] devguide: buggy heading numbers

Chris Jerdonek added the comment: > Levels beyond 2 are getting numbered 25 (the number of the top level) instead > of having their numbering suppressed (as I would expect it to). Actually, what I meant to say is that I would expect the "tocdepth" to affect only the level of the table of conte

[issue17241] Python-2.3.5.exe file possibly corrupt

Stefan Krah added the comment: I'm getting the complete file here, too. -- nosy: +skrah status: open -> pending ___ Python tracker ___ ___

[issue17227] devguide: buggy heading numbers

Antoine Pitrou added the comment: Georg, do you know how to fix this? -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-li

[issue17227] devguide: buggy heading numbers

Chris Jerdonek added the comment: I noticed this before and wasn't able to fix it after trying a few things. I wonder if this is a limitation or bug in Sphinx. At the top, the FAQ page has-- :tocdepth: 2 Levels beyond 2 are getting numbered 25 (the number of the top level) instead of having

[issue17251] LWPCookieJar load() set domain_specifed wrong

New submission from B. Kyven: Hello, I am using LWPCookieJar to store cookies. But I am having trouble. Saving is fine, load is wrong. I use Cookie.domain_specified to judge if domain exist. save the following to test.lwp - #LWP-Cookies-2.0 Set-Cookie3: name=value; path="/ddd/"

[issue15587] IDLE is pixelated on the Macbook Pro with Retina Display

Ned Deily added the comment: Thanks, Tyler. The 2.7.4 and 3.2.4 maintenance releases have been delayed due to some critical issues and so we don't have a new availability date for the first release candidates. I'll try to remember to ping here when that happens. -- status: open -> pe

[issue11732] Skip decorator for tests requiring manual intervention on Windows

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29130/nopopup.diff ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue11732] Skip decorator for tests requiring manual intervention on Windows

Changes by Ezio Melotti : Removed file: http://bugs.python.org/file29129/nopopup.diff ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue11732] Skip decorator for tests requiring manual intervention on Windows

Changes by Ezio Melotti : Added file: http://bugs.python.org/file29129/nopopup.diff ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue11732] Skip decorator for tests requiring manual intervention on Windows

Ezio Melotti added the comment: Here is a proof of concept patch that defines a context manager that disables the crash popups using SetErrorMode [0]. I tested it only on Windows 7 (and Linux, where it's a no-op). As an example, the patch fixes the crash popup caused by test_capi. [0]: htt

[issue17145] memoryview(array.array)

Demian Brecht added the comment: Yes, I agree that passage is a little garbled. I've reworked that particular paragraph in the new patch. I had included a little information about 2.6 as it was in the revision prior to my patch (and there was also some historical context back to 1.6). I think

[issue17145] memoryview(array.array)

Terry J. Reedy added the comment: I am looking at this as a naive user, and can only assume that the claims are correct. +The new C-level buffer API has been backported to Python 2.6 and the +Python-level :class:`memoryview` object has been backported to Python 2.7. +To be clear, in Python 2.6

[issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows

Ezio Melotti added the comment: Vinay commit made the test pass, but the popup is still present. Removing the popup is discussed in #11732. -- nosy: +ezio.melotti versions: +Python 3.3, Python 3.4 ___ Python tracker

[issue17032] Misleading error message: global name 'X' is not defined

Terry J. Reedy added the comment: +NAME_ERROR_MSGy, name); will give a NameError ;-). The patch undoes the change from 'name' to 'global name'. Skimming the PEP, I do not see this change mandated or justified by the PEP. So my current view: while it is true that it is the final, global nam

[issue17250] argparse: Issue 15906 patch; positional with nargs='*' and string default

Changes by Chris Jerdonek : -- nosy: +bethard, chris.jerdonek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue17250] argparse: Issue 15906 patch; positional with nargs='*' and string default

New submission from paul j3: The production argparse applies the type conversion to a string default whether it is needed or not. With the 12776 and 15906 patch, that conversion is postponed, so that it is applied only once. However, for a positional argument with nargs='*', that conversion

[issue15587] IDLE is pixelated on the Macbook Pro with Retina Display

Tyler Crompton added the comment: I will gladly test the changes. Where would I find these to download? -- status: pending -> open ___ Python tracker ___

[issue15004] add weakref support to types.SimpleNamespace

Changes by Eric Snow : Removed file: http://bugs.python.org/file29094/simplenamespace-weakref.diff ___ Python tracker ___ ___ Python-bugs-list

[issue15004] add weakref support to types.SimpleNamespace

Eric Snow added the comment: Good point. Thanks. I've updated the test. Does that cover it? -- Added file: http://bugs.python.org/file29127/simplenamespace-weakref.diff ___ Python tracker ___

[issue15767] add ImportNotFoundError

Eric Snow added the comment: Right. Sorry I wasn't more clear. Existing code will continue to work either way. The point is in exposing the distinct module/name-not-found case, which I consider to be the common case for catching ImportError. My examples cover the case where you want to han

[issue4963] mimetypes.guess_extension result changes after mimetypes.init()

R. David Murray added the comment: I'd forgotten about this issue. I wonder if the dictionary randomization makes the problem worse. -- components: +email nosy: +barry versions: +Python 3.2, Python 3.3, Python 3.4 ___ Python tracker

[issue17249] reap threads in test_capi

New submission from Ezio Melotti: The attached patch fixes the following warning: $ ./python -m test test_capi [1/1] test_capi Warning -- threading._dangling was modified by test_capi 1 test altered the execution environment: test_capi This test was introduced in f7993dc6bf26, and it seems

[issue7981] False failure with doctest NORMALIZE_WHITESPACE in 3.1.1

R. David Murray added the comment: This doesn't have anything to do with NORMALIZE_WHITESPACE. In python3, .write returns the number of bytes written, instead of None. If you add the 38 to the end of your test line, the test will pass. This is not a bug in doctest, but a difference in 'write'

[issue17143] trace.py uses _warn without importing it

Ezio Melotti added the comment: This should be fixed now. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailin

[issue17247] int and float should detect inconsistent format strings

Changes by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue17248] test_posix chown -1, 0 tests fail if user has group root

New submission from R. David Murray: I'm a member of group root, and the _test_all_chown_common tests that use -1, 0 fail for me, because I'm allowed to set group root on a file. -- components: Tests messages: 182461 nosy: r.david.murray, serhiy.storchaka priority: normal severity: norm

[issue7842] py_compile.compile SyntaxError output

R. David Murray added the comment: Better late than never. Be nice if someone would contribute a test, but I'm not going let that hold things up for such a simple patch that is already in default with no test. -- nosy: +r.david.murray resolution: -> fixed stage: patch review -> commi

[issue15767] add ImportNotFoundError

Serhiy Storchaka added the comment: Why not just try: from _thread import _local as local except ImportError: from _threading_local import local ? -- ___ Python tracker ___

[issue7842] py_compile.compile SyntaxError output

Roundup Robot added the comment: New changeset c7f04c09dc56 by R David Murray in branch '2.7': #7842: backport fix for py_compile.compile syntax error message handling. http://hg.python.org/cpython/rev/c7f04c09dc56 -- nosy: +python-dev ___ Python trac

[issue17143] trace.py uses _warn without importing it

Roundup Robot added the comment: New changeset 662f97427acf by Ezio Melotti in branch '3.3': #17143: fix buildbot failures on Windows. http://hg.python.org/cpython/rev/662f97427acf New changeset 1bf0ff7db856 by Ezio Melotti in branch 'default': #17143: merge with 3.3. http://hg.python.org/cpytho

[issue6541] SpooledTemporaryFile breakages

R. David Murray added the comment: Thanks for the report, and sorry we didn't handle it when you reported it. This issue was re-reported and fixed in issue #10355. -- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Sp

[issue15767] add ImportNotFoundError

Eric Snow added the comment: The common case for catching ImportError is exactly what ModuleNotFoundError represents. If people are already going to change their code to handle just this special case, I'd think having the subclass would be the better route. I find it simpler (both to update

[issue6623] Lib/ftplib.py Netrc class should be removed.

R. David Murray added the comment: Thanks for the report. ftplib.Netrc has been deprecated (via its doc string) since at least Python 2.4, and is no longer documented in the library reference. I've added an explicit DeprecationWarning in Python 3.4, and have altered this issue to call for it

[issue6623] Lib/ftplib.py netrc class parsing problem

Roundup Robot added the comment: New changeset acf247d25f17 by R David Murray in branch 'default': #6623: Add explicit deprecation warning for ftplib.Netrc. http://hg.python.org/cpython/rev/acf247d25f17 -- nosy: +python-dev ___ Python tracker

[issue17247] int and float should detect inconsistent format strings

Stefan Krah added the comment: With int and float it's also possible to specify both conflicting alignments and fill characters: >>> "{:x<06}".format(1.2) '1.2xxx' So I really think that the builtins should be changed to detect the conflict. -- assignee: skrah -> components: +Inter

[issue17247] Decimal doesn't support aligned fill

Stefan Krah added the comment: Christian Heimes wrote: > The output is from Python 3.3. Why has Python 3.3 a less informative error > message than 3.2? Because the error is discovered in libmpdec and it would require a significant amount of work to provide fine-grained error messages. > I als

[issue17247] Decimal doesn't support aligned fill

Christian Heimes added the comment: The output is from Python 3.3. Why has Python 3.3 a less informative error message than 3.2? I also wonder why it works with floats if it has a special meaning? Either float or Decimal is broken. -- ___ Python tr

[issue17247] Decimal doesn't support aligned fill

Stefan Krah added the comment: 3.2 has a better error message: >>> "{:<06}".format(Decimal("1.2")) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.2/decimal.py", line 3632, in __format__ spec = _parse_format_specifier(specifier, _localeconv=_localeconv) F

[issue17192] libffi-3.0.12 import

Matthias Klose added the comment: before the updates, ... there seem to be two test failures on sparc solaris. the local libffi/src/sparc/v8.S change was integrated upstream, so I don't yet what could cause these failures. or did they fail before too? -- __

[issue17247] Decimal doesn't support aligned fill

Changes by Ezio Melotti : -- nosy: +ezio.melotti, mark.dickinson stage: -> needs patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue17247] Decimal doesn't support aligned fill

New submission from Christian Heimes: >>> "{:<06}".format(1.2) '1.2000' >>> "{:<06}".format(decimal.Decimal(1.2)) Traceback (most recent call last): File "", line 1, in ValueError: invalid format string -- assignee: skrah messages: 182447 nosy: christian.heimes, skrah priority: normal

[issue17246] cgitb fails when frame arguments are deleted (due to inspect bug I think)

New submission from Andrew Lutomirski: inspect.formatargvalues assumes (incorrectly) that every argument in args is a key in values. This isn't very hard to break -- see the attachment for a complete example. -- components: Library (Lib) files: test_cgitb.py messages: 182446 nosy: And

[issue12014] str.format parses replacement field incorrectly

Ben Wolfson added the comment: "My own preference is to let this quote from PEP 3101 dominate the behaviour: "The rules for parsing an item key are very simple. If it starts with a digit, then it is treated as a number, otherwise it is used as a string." That means Petri's suggested solution (

[issue17192] libffi-3.0.12 import

Gregory P. Smith added the comment: http://bugs.python.org/issue17245 filed to track the stack alignment issue. The only reason i set this as release blocker is to let a release manager decide which of these two issues to proceed with for 2.7.4 and 3.2.4 (and 3.3.1). --

[issue17192] libffi-3.0.12 import

Benjamin Peterson added the comment: By all means, upgrade it. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue17245] ctypes libffi needs to align the x86 stack to 16 bytes

New submission from Gregory P. Smith: The problem: without the stack being 16-byte aligned, code generated by modern compilers like recent gcc/g++ or clang assumed that the stack is 16 byte aligned and uses SSE instructions in some circumstances that require this. Without this fix, any ctypes

[issue17237] m68k aligns on 16bit boundaries.

mirabilos added the comment: @pitrou: As for performance, 2-byte and 4-byte are the same on m68k, given that they usually have RAM which doesn’t benefit from that kind of alignment, and systems that are structured accordingly. The “best” cpp define I don’t know, but my system defines __m68k__

[issue17192] libffi-3.0.12 import

Gregory P. Smith added the comment: An update to libffi is needed for all maintained versions of Python. In 2.7, we're running into the stack being misaligned in 32-bit x86 code which is something a libffi update fixes. It is a simple patch: http://patchwork.ozlabs.org/patch/58128/ which co

[issue17237] m68k aligns on 16bit boundaries.

Stefan Krah added the comment: mirabilos wrote: > Please dont break what works. We have almost complete (about three quarters > of roughly 10'000 source packages) Debian unstable working on m68k, with > several versions of Python in use. Thanks! Are you saying that the complete test suite works

[issue17237] m68k aligns on 16bit boundaries.

Antoine Pitrou added the comment: > We had a similar issue in the Linux kernel, where it used the lower > two bits of an address for flags (urgh…) which could only be solved by > using GCC’s __attribute__((__aligned__(4))) on the quantities in > question, but that may or may not be the required c

[issue15767] add ImportNotFoundError

Barry A. Warsaw added the comment: On Feb 19, 2013, at 07:49 PM, Brett Cannon wrote: >Serihy & Barry: no. We do that now and it's already a nasty little hack. It >would be better to let people catch an exception signaling that an import >didn't happen because some module is missing than require

[issue17237] m68k aligns on 16bit boundaries.

mirabilos added the comment: @skrah: “I don't think we should support this platform officially.” Please don’t break what works. We have almost complete (about three quarters of roughly 10'000 source packages) Debian unstable working on m68k, with several versions of Python in use. Thanks! @pi

[issue17237] m68k aligns on 16bit boundaries.

Serhiy Storchaka added the comment: Perhaps we should disable not only assert, but all optimized code inside #if SIZEOF_LONG <= SIZEOF_VOID_P / #endif block. Benchmarks needed to measure either unaligned writing speedup or slowdown decoding. -- ___

[issue17237] m68k aligns on 16bit boundaries.

Antoine Pitrou added the comment: Ok, so we could simply disable the assert on m68k, if you can confirm it works. Do you want to provide a patch? I don't know what the preprocessor conditional should look like. -- components: +Interpreter Core -Build stage: -> needs patch type: -> cr

[issue17237] m68k aligns on 16bit boundaries.

Alan Hourihane added the comment: Oh, and as for pointer alignment, I probably just wasn't clear in the initial report. But we agree on m68k C ABI. -- ___ Python tracker ___ ___

[issue17244] py_compile.compile() fails to raise exceptions when writing of target file fails

Brett Cannon added the comment: It's because of this try/except to silence failed bytecode creation: http://hg.python.org/cpython/file/d404d33a999c/Lib/importlib/_bootstrap.py#l1105 I hate the py_compile module. -- ___ Python tracker

[issue17237] m68k aligns on 16bit boundaries.

Alan Hourihane added the comment: It's GCC 4.6.3. GCC has the -malign-int but mentions this isn't in best interest of m68k ABI compatibility if it's used. -- components: +Build -Unicode type: crash -> versions: -Python 3.4 ___ Python tracker

[issue17237] m68k aligns on 16bit boundaries.

Antoine Pitrou added the comment: > It must be about pointer alignment, because that's the whole point of > the ASSERT. Indeed, it's about pointer alignment, but it's not about the CPU. It's about the compiler (or the platform's C ABI). Apparently the compiler doesn't align struct fields to nat

[issue17237] m68k aligns on 16bit boundaries.

Changes by Serhiy Storchaka : -- components: +Unicode -Build nosy: +ezio.melotti versions: +Python 3.4 ___ Python tracker ___ ___ Pyth

[issue17237] m68k aligns on 16bit boundaries.

Serhiy Storchaka added the comment: What will happened if you just remove this line? -- nosy: +serhiy.storchaka type: -> crash ___ Python tracker ___ ___

[issue17237] m68k aligns on 16bit boundaries.

Alan Hourihane added the comment: It must be about pointer alignment, because that's the whole point of the ASSERT. As for the backtrace, the gdb support on the platform isn't great yet, but here it is Breakpoint 1, ascii_decode (start=0x30c5b04 "__len__", end=0x30c5b0b "", dest=0x1a

[issue6975] symlinks incorrectly resolved on POSIX platforms

Arfrever Frehtes Taifersar Arahesis added the comment: You could probably test '.\\.' and '..\\..' etc. in these tests on Windows. -- ___ Python tracker ___ __

[issue17244] py_compile.compile() fails to raise exceptions when writing of target file fails

New submission from Arfrever Frehtes Taifersar Arahesis: Since d4eb02b6aac9 py_compile.compile() fails to raise exceptions when writing of target file fails. $ cd /tmp $ touch test.py $ mkdir dir $ chmod a-w dir mode of ‘dir’ changed from 0755 (rwxr-xr-x) to 0555 (r-xr-xr-x) $ python3.3 -c 'imp

[issue17032] Misleading error message: global name 'X' is not defined

Changes by Philip Jenvey : -- nosy: +pjenvey ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue17243] The changes made for issue 4074 should be documented

New submission from R. David Murray: The section of the reference on the gc module goes into some detail on what the thresholds control and when collections are run, but does not currently document the backoff algorithm used when deciding whether or not to collect generation 2. This should pr

[issue17032] Misleading error message: global name 'X' is not defined

Ezio Melotti added the comment: GLOBAL_NAME_ERROR_MSG has been introduced in fd8c7203251f as part of PEP 227 by Jeremy Hylton, so I'm adding him to the nosy to see if he agrees with the change (also adding a couple more devs to see if they have any comments). There's also a typo in the last ch

[issue12869] PyOS_StdioReadline is printing the prompt on stderr

Changes by Ezio Melotti : -- components: +Extension Modules type: -> behavior versions: +Python 3.3, Python 3.4 ___ Python tracker ___ __

[issue11763] assertEqual memory issues with large text inputs

Ezio Melotti added the comment: There are some tests in the issue11763-2.diff patch. -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue17242] Fix code highlight in devguide/docquality.rst

Changes by Ezio Melotti : -- assignee: -> ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon added the comment: Exactly, and I don't want to have to slice up the internal API anymore in order to support this edge case which I don't think is important enough to support. -- ___ Python tracker _

[issue17237] m68k aligns on 16bit boundaries.

Antoine Pitrou added the comment: Ok, could you post the whole C stack trace? (using e.g. gdb) By the way, this is not about the alignment of m68k architectures: x86 can align on a byte boundary and doesn't trigger the assert. -- ___ Python tracker

[issue17242] Fix code highlight in devguide/docquality.rst

Ezio Melotti added the comment: Fixed, thanks for the patch! -- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement ___ Python tracker __

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: Ah, right. Well, there would be an argument not to use os.replace() in py_compile, since it's an offline processing step which generally shouldn't race with another (online) processing step. Still, I wonder what the use case is (apart from the /dev/null case f

[issue17242] Fix code highlight in devguide/docquality.rst

Roundup Robot added the comment: New changeset 6015789cbce0 by Ezio Melotti in branch 'default': #17242: fix code highlight. Patch by Berker Peksag. http://hg.python.org/devguide/rev/6015789cbce0 -- nosy: +python-dev ___ Python tracker

[issue17237] m68k aligns on 16bit boundaries.

Alan Hourihane added the comment: As mention in the versions. It is Python 3.3.0. -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon added the comment: I think Arfever is more frustrated by the os.replace() call than the permissions. -- ___ Python tracker ___ _

[issue15767] add ImportNotFoundError

Brett Cannon added the comment: Chris: Having a more generic name for import-from at the eval loop level on top of NoModuleFoundError is breaking the "practicality over purity" rule. ImportSearchFailed might be the closest we can come to a generic name for what occurred. Serihy & Barry: no. W

[issue17239] XML vulnerabilities in Python

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

[issue15767] add ImportNotFoundError

Antoine Pitrou added the comment: > >Can this be the same ImportError but with special flag? > > Like an attribute on the exception? +1 ImportError.has_different_meaning_but_too_lazy_to_create_a_distinct_exception_class_for_it ? (or perhaps you would prefer the camelCase version :-)) --

[issue17033] RPM spec file has old config_binsuffix value

Taavi Burns added the comment: I'm not sure my vote means much, but the spec file didn't work for me on CentOS 5 anyway (weird issue with the -dev RPM trying to find "python2.72.7"). I think I'd prefer a README with suggested places to look for a working spec file than have this "blessed"-but-

[issue17242] Fix code highlight in devguide/docquality.rst

New submission from Berker Peksag: See for the current version: http://docs.python.org/devguide/docquality.html#helping-with-the-developer-s-guide -- components: Devguide files: devguide-highlight.diff keywords: patch messages: 182412 nosy: berker.peksag, ezio.melotti priority: normal s

[issue15767] add ImportNotFoundError

Barry A. Warsaw added the comment: On Feb 19, 2013, at 07:24 PM, Serhiy Storchaka wrote: >Can this be the same ImportError but with special flag? Like an attribute on the exception? +1 -- ___ Python tracker

[issue17237] m68k aligns on 16bit boundaries.

Antoine Pitrou added the comment: Which branch or version of Python is that? -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-l

[issue15767] add ImportNotFoundError

Serhiy Storchaka added the comment: Can this be the same ImportError but with special flag? -- ___ Python tracker ___ ___ Python-bugs-

[issue17241] Python-2.3.5.exe file possibly corrupt

Jeff Mansfield added the comment: Ezio, It is what was in use on my old machine, and I don't want to move versions. Thanks, Jeff -- ___ Python tracker ___ _

[issue14219] make the Classes tutorial more gentle

Changes by Tshepang Lekhonkhobe : -- title: start the Class tutorial in a more gentle manner -> make the Classes tutorial more gentle versions: +Python 3.4 ___ Python tracker __

[issue17241] Python-2.3.5.exe file possibly corrupt

Ezio Melotti added the comment: I tried to download it on a win xp machine and I succeeded at the first attempt (even thought it seemed to be stuck for a few seconds before reaching 100%). I was also able to start the installer, even thought I didn't install it. This is the version I downloade

[issue17240] argparse: subcommand name and arity

Chris Jerdonek added the comment: > This is not satisfactory. I would prefer: > import argparse > argparser = argparse.ArgumentParser() > subparsers = argparser.add_subparsers('cmd1') % name here Have you tried passing by keyword? subparsers = argparser.add_subparsers(dest='cmd1') It seems to

[issue17241] Python-2.3.5.exe file possibly corrupt

New submission from Jeff Mansfield: Python-2.3.5.exe seems to be corrupt. I’ve tried downloading Python-2.3.5.exe a number of times in the past week, and so have a few of my colleagues. It always transfers in an incomplete manner, resulting in only 4.7 out of 9.1 MB. I have tried from several d

[issue15767] add ImportNotFoundError

Chris Jerdonek added the comment: If we can promise not to use it in the from-import case :) I'm okay with the more specific name (in fact it is preferable). From Brett's response, it sounds like we have flexibility there and don't need it to be the same? For from-import I would prefer the g

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > Of course, this won't recreate symlinks and the like. But I don't think > we can do something for that anyway, since we want to replace to happen > automatically. I meant: we want the replace to happen atomically :-) -- __

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > Use the mode how exactly? I mean isn't the problem the os.replace() > call and not os.open() on the source file? If you want to reproduce the original file's access rights, you have to pass the right mode flags to os.open(). Of course, this won't recreate syml

[issue15767] add ImportNotFoundError

Brett Cannon added the comment: Technically it should be ModuleOrSomeObjectNotFoundBecauseFromListIsTheBaneOfMyExistenceError, but we might be starting to mix paints for paints a shed shortly. Fine, that's 1 to 1 for ModuleNotFoundError vs. ImportNotFoundError. -- ___

[issue17239] XML vulnerabilities in Python

Changes by Franck Michea : -- nosy: +kushou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon added the comment: Use the mode how exactly? I mean isn't the problem the os.replace() call and not os.open() on the source file? -- ___ Python tracker ___

[issue13700] imaplib.IMAP4.authenticate authobject does not work correctly in python3

Roundup Robot added the comment: New changeset 3d4302718e7c by R David Murray in branch '3.2': #13700: Make imap.authenticate with authobject work. http://hg.python.org/cpython/rev/3d4302718e7c New changeset b21f955b8ba2 by R David Murray in branch '3.3': Merge: #13700: Make imap.authenticate wi

[issue13700] imaplib.IMAP4.authenticate authobject does not work correctly in python3

R. David Murray added the comment: Demian: thanks for the reminder, and the confirmation that it works on a real server. Erno: thanks for the test fix. That was a pretty stupid mistake on my part :) -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> clo

[issue17222] py_compile.compile() explicitly sets st_mode for written files

Antoine Pitrou added the comment: > Unless there is some way that I can't think of to have the atomic write > still exist but not change the type of file it replaces How about using the `mode` to write_atomic? (which, incidentally, is already used to mirror the .py file's permissions in Source

[issue15767] add ImportNotFoundError

Antoine Pitrou added the comment: > The original need was for internal importlib usage, but upon > reflection it could also be used by the eval loop for that > (http://hg.python.org/cpython/file/83d70dd58fef/Python/ceval.c#l4560), > so I'm fine with changing the name to ImportNotFoundError. I do

[issue17240] argparse: subcommand name and arity

New submission from Thibault Kruse: I realize there have been several suggestions around argparse subcommands. Mine is related to this isse: http://bugs.python.org/issue9253 In short, I suggest that the add_subparsers() function take an argument like nargs that determines how many times user m

  1   2   >