[issue46142] python --help output is too long
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46090] C extensions can't swap out live frames anymore
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
Barry A. Warsaw added the comment: I think it does a better service to users to explain how Python returns None implicitly if a function doesn't have any other explicit return value. If the print() docs had this note, it would be confusing why other similar functions don't. It's also worth explaining that when a function is designed to *explicitly* return None in certain cases (e.g. dict.get()) that it shouldn't do so implicitly, but should include an explicit `return None` for readability. -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
Barry A. Warsaw added the comment: > Barry: The PEP 8 'return None' recommendation could be added to the Reference > entry for 'return'. But I think this should be a separate issue as 1) it is > about coding rather than documentation and 2) there is the possible objection > that choosing completely explicit 'return None' versus half explicit, half > implicit 'return' and the latter versus completely implicit > should be left to the style PEP. I do think it's a question of style. Section 7.6 of the language reference says: > If an expression list is present, it is evaluated, else None is substituted. which is the important concept that beginners should learn. I agree that the admonition in PEP 8 is really trying to say "don't mix implicit and explicit return styles". Implicit None return is fine if all exit paths are implicit. But once you add an explicit value to a return path, all return paths should use explicit values, including those that return None. IME, while I do occasionally encounter push back on this when doing reviews, most folks come around to this p.o.v. -- ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Barry A. Warsaw added the comment: I've never personally needed this, but I could see where it could come in handy. I wonder if __iter__() would be the right API for that? I wonder then if we should also implement __contains__()? Would you be interested in creating a PR for the feature? -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Barry A. Warsaw added the comment: I think you’re right that the iterator API isn’t very helpful. I also agree that you probably really want to answer the “why identifiers are in this template?” question. As for repeats, there’s two ways to think about it. You could return all the identifiers in the order in which they’re found in the template (and you can unique-ify them if you want by passing that list to set()). But maybe you don’t really need that either. get_identifiers() works for me! On Jan 8, 2022, at 18:51, Ben Kehoe wrote: > > Ben Kehoe added the comment: > > Happy to make a PR! In my mind I had been thinking it would be the > get_identifiers() method with the implementation above, returning a list. > > As for __iter__, I'm less clear on what that would look like: > > t = string.Template(...) > for identifier in t: > # what would I do here? > # would it include repeats if they appear more than once in the template? > > I guess there are two ways to think about it: one is "what identifiers are in > this template?" which I think should return a list with no repeats, which I > can then iterate over or check if a value is in it. The other is, "what are > the contents of the template?" in the style of string.Formatter.parse(). > > Given that string.Template is supposed to be the "simple, no-frills" thing in > comparison to string.Formatter, I see less use for the latter option. -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46321] Don't need delineators on lists
Barry A. Warsaw added the comment: As Dennis points out, this is not a bug, it's already valid Python syntax. -- nosy: +barry resolution: -> not a bug status: pending -> open ___ Python tracker <https://bugs.python.org/issue46321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46328] add sys.exception()
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46328] add sys.exception()
Barry A. Warsaw added the comment: sys.exception() seems like a decent enough trade-off. I've always disliked the abbreviations in "exc_info". It doesn't feel big enough for a PEP to me. -- ___ Python tracker <https://bugs.python.org/issue46328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46330] Simplify the signature of __exit__
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46330> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46528] Simplify the VM's stack manipulations
Barry A. Warsaw added the comment: What are the (unoptimized) performance implications of replacing one instruction with multiple instructions? -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46528] Simplify the VM's stack manipulations
Barry A. Warsaw added the comment: Very interesting. Do we have any current (or even cutting edge, i.e. 3.11) timings for individual instructions? Or a breakdown of how frequently different instructions are invoked? I remember Carl Shapiro presenting his findings here several years ago (I think in the penultimate in-person Language Summit). -- ___ Python tracker <https://bugs.python.org/issue46528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46528] Simplify the VM's stack manipulations
Barry A. Warsaw added the comment: IIRC, Carl got a lot of benefit out of reordering the opcodes in the main loop to put the most common ones at the top. I don't know if that is still relevant or whether computed gotos, when enabled, change that calculus. -- ___ Python tracker <https://bugs.python.org/issue46528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46543] Add sys._getfunc
Barry A. Warsaw added the comment: > Usually the calling function object should be enough. I want to at least provide some historical context on why sys._getframe() exists. I originally wrote that to support PEP 292 and internationalization in Mailman. This has since been extracted into the flufl.i18n package. Here is the use of sys._getframe() in that library: https://gitlab.com/warsaw/flufl.i18n/-/blob/main/src/flufl/i18n/_translator.py#L65 You can see that the reason this exists is to dig out the local and globals of the context in which the _() function is invoked. This greatly reduces the need to repeat yourself in i18n call sites. https://flufli18n.readthedocs.io/en/stable/using.html#substitutions-and-placeholders I'm not saying sys._getfunc() is or isn't useful, but it won't change original need for sys._getframe(). -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46896] add support for watching writes to selected dictionaries
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1259] string find and rfind methods give a TypeError that is misleading
Barry A. Warsaw added the comment: I believe this is because string_find_internal() uses an O& with _PyEval_SliceIndex() to convert its start and end arguments, but the latter function does not accept None. To fix this, you'd have to change string_find_internal() to do its own argument checking for None before calling _PyEval_SliceIndex. -- nosy: +barry __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1259> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1259] string find and rfind methods give a TypeError that is misleading
Barry A. Warsaw added the comment: facundo, robert and i looked at this patch and it seems okay. suggestions: document the reference count semantics of _ParseTupleFinds() and include a definition of that function in a .h file. since its non-public, maybe find.h is the right place to put it? there also some random addition of trailing whitespace in the last hunk of stringobject.c __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1259> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Barry A. Warsaw added the comment: On Sep 12, 2011, at 12:34 PM, Nick Coghlan wrote: >It wouldn't surprise me at all if the laptop's links were a little off - I >started with a Kubuntu image off VMWare's site quite some time ago, then >dist-upgraded it through a couple of releases as they came out. I'll try to get a VM up with the latest Oneiric Kubuntu image and see what happens. -- ___ Python tracker <http://bugs.python.org/issue11715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13021] Resource is not released before returning from the functiion
Barry A. Warsaw added the comment: Suman, good eye, confirmed! Thanks for the patch, I'll commit this to 3.2 and 3.3. -- assignee: -> barry ___ Python tracker <http://bugs.python.org/issue13021> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13021] Resource is not released before returning from the function
Changes by Barry A. Warsaw : -- title: Resource is not released before returning from the functiion -> Resource is not released before returning from the function ___ Python tracker <http://bugs.python.org/issue13021> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13021] Resource is not released before returning from the function
Changes by Barry A. Warsaw : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue13021> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7732] imp.find_module crashes Python if there exists a directory named "__init__.py"
Barry A. Warsaw added the comment: Note that Python 2.6 is also vulnerable to the crash. While we do not have an exploit, we did get a report on security@ which led to this bug. I could be convinced to allow the patch to 2.6 on grounds that if the crasher can be exploited, better to apply it now rather than wait. Certainly if it's easier to apply 2.6 and forward port, I'm fine with that. Victor's pyfile_fromfile_close.patch looks good to me and fixes the problem with no discernible ill effects. On IRC, he said he'll apply it to 2.7, 3.2, and 3.3. I will approve it for 2.6 if he wants to apply it there too. -- nosy: +barry versions: +Python 2.6, Python 3.1 ___ Python tracker <http://bugs.python.org/issue7732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7732] imp.find_module crashes Python if there exists a directory named "__init__.py"
Changes by Barry A. Warsaw : -- versions: -Python 3.1 ___ Python tracker <http://bugs.python.org/issue7732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw added the comment: On Oct 04, 2011, at 01:03 PM, Boštjan Mejak wrote: >I have a better idea... Why don't we change the "linux2" string into just >"linux". That way we will never run into this kind of issue, even in the >future when Linux kernel version 4 is going to exist. Any thoughts on this? Python 3.3 already sets sys.platform to 'linux'. It can't be done for older versions due to backward compatibility. -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13110] test_socket.py failures on ARM
New submission from Barry A. Warsaw : Initial results from warsaw-ubuntu-arm buildbot indicates two failures in test_socket.py == ERROR: test_create_connection_timeout (test.test_socket.NetworkConnectionNoServer) -- Traceback (most recent call last): File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/test/test_socket.py", line 1198, in test_create_connection_timeout socket.create_connection((HOST, 1234)) File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/socket.py", line 571, in create_connection raise err error: [Errno 97] Address family not supported by protocol == FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer) -- Traceback (most recent call last): File "/var/lib/buildbot/buildarea/2.7.warsaw-ubuntu-arm/build/Lib/test/test_socket.py", line 1191, in test_create_connection self.assertEqual(cm.exception.errno, errno.ECONNREFUSED) AssertionError: 97 != 111 -- I'm still investigating, but wanted to file the bug now so there's an issue number to reference. -- components: Tests messages: 144974 nosy: barry priority: normal severity: normal status: open title: test_socket.py failures on ARM versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13110> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13110] test_socket.py failures on ARM
Changes by Barry A. Warsaw : -- versions: +Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue13110> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13110] test_socket.py failures on ARM
Barry A. Warsaw added the comment: This appears to be the problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/868812 I'm going to close this Python bug since it seems to be related to the Linux kernel on armel. Editing the /etc/hosts file gets around the problem and lets the test pass. I could imagine that the test should be able to deal with the unexpected exceptions though. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue13110> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11250] 2to3 truncates files at formfeed character
Barry A. Warsaw added the comment: Was this patch ever folded into Python 3.2? Looking at the hg repository, I think the answer is "no". It does appear to have made it into Python 2.7 and trunk though (afaict). In point of fact, this bug is hitting me now with 3.2.2. -- nosy: +barry status: closed -> open ___ Python tracker <http://bugs.python.org/issue11250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11250] 2to3 truncates files at formfeed character
Changes by Barry A. Warsaw : -- assignee: -> barry ___ Python tracker <http://bugs.python.org/issue11250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11250] 2to3 truncates files at formfeed character
Barry A. Warsaw added the comment: I also noticed that test_parser.py isn't being run in either 3.2 or 3.3. I'll fix that at the same time I port this patch to 3.2. -- ___ Python tracker <http://bugs.python.org/issue11250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11250] 2to3 truncates files at formfeed character
Barry A. Warsaw added the comment: Okay, re-enabling test_parser.py introduces a number of test failures in test_all_project_files(). Because I don't want to continue to shave the yak on this one, I'm going to wrap this test in @expectedFailure and open a separate bug for it. -- ___ Python tracker <http://bugs.python.org/issue11250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12681] unittest expectedFailure could take a message argument like skip does
Barry A. Warsaw added the comment: It would be nice if expectedFailure took a bug number and printed a url to the tracker. -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue12681> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13125] test_all_project_files() expected failure
New submission from Barry A. Warsaw : In working on issue 11250, I noticed that lib2to3's test_parser.py tests were not enabled. Fixing that was easy enough, but then test_all_project_files() in TestParserIdempotency began failing. I've shaved enough yaks for the day so I am going to leave test_parser enabled but mark test_all_project_files() with @expectedFailure. Note that there are a number of failures here. There are two ParseErrors, one in main.py and one in pytree_idempotency.py. These both seem to fail on print(..., file=foo). After that, bom.py fails idempotency because the BOM does not show up in the converted file. -- components: Tests messages: 145122 nosy: barry, benjamin.peterson priority: normal severity: normal status: open title: test_all_project_files() expected failure versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11250] 2to3 truncates files at formfeed character
Changes by Barry A. Warsaw : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue11250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10976] json.loads() throws TypeError on bytes object
Barry A. Warsaw added the comment: I'll just mention that the elimination of bytes handling is a bit unfortunate, since this idiom which works in Python 2 no longer works: fp = urlopen(url) json_data = json.load(fp) /me sad -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue10976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13167] Add get_metadata to packaging
Barry A. Warsaw added the comment: On Oct 13, 2011, at 04:01 PM, Éric Araujo wrote: >The PEP 376 implementation in packaging.database has been called ugly and >opaque. When discussing PEP 396 for example (that’s why I’m adding Barry and >Antoine to nosy, for their feedback), >get_distribution(name).metadata['Version'] did not seem to agree with >everyone. (Note that there are shortcuts for two metadata fields: name and >version also exist as get_distribution(name).name / .version.) I don't entirely remember my objections to the API, but I wonder if you couldn't provide attribute access via properties on .metadata? Or are there keys that can't be mapped to identifiers (modulo typical dash-to-underscore mappings)? >I’m not sure how we can make it less opaque, unless we force people to read >documentation: PEP 376 proposes a database of installed distributions; >packaging.database offers get_distribution, which returns an object with some >attributes. I can’t have an outside view on this, so maybe you can explain >what’s opaque and ugly so that we can try to improve it. > >I’ve found in distutils-sig archives from two or three years ago that people >intended to offer a get_metadata function that would take a distribution name >(i.e. pyOpenSSL, Babel, flufl.enum) and return a mapping object with the >metadata read from the installed dist-info/METADATA file. Does that look >better to you? So, that would mean instead of get_distribution(name).metadata['Version'] you'd use get_metadata(name)['Version'] ? I'm not sure that's really buys you much. Maybe we just need to live with the current API for a while before we try to improve it. -- ___ Python tracker <http://bugs.python.org/issue13167> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13125] test_all_project_files() expected failure
Barry A. Warsaw added the comment: Note that I think it's best to fix the underlying failures rather than silence them. ;) -- ___ Python tracker <http://bugs.python.org/issue13125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13239] Remove <> operator from Grammar/Grammar
Barry A. Warsaw added the comment: On Oct 21, 2011, at 06:35 PM, Benjamin Peterson wrote: >Benjamin Peterson added the comment: > >Or perhaps we don't need joke backward compatibility? (That's nearly 3 years >old.) OTOH, __future__ imports (even jokes) should never be removed. -- ___ Python tracker <http://bugs.python.org/issue13239> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13239] Remove <> operator from Grammar/Grammar
Barry A. Warsaw added the comment: On Oct 21, 2011, at 07:33 PM, Antoine Pitrou wrote: >Antoine Pitrou added the comment: > >> OTOH, __future__ imports (even jokes) should never be removed. > >But their meaning can be altered? >(as part of another joke if you want :) Well, you have 6 months to work that out then. :) -- ___ Python tracker <http://bugs.python.org/issue13239> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Ubuntu 11.10
Barry A. Warsaw added the comment: Still investigating, but FTR, this isn't technically an Ubuntu issue as much as it is a Debian issue (and thus inherited by Ubuntu). I can reproduce the failure in Python 3.3 on Debian Wheezy. -- ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Changes by Barry A. Warsaw : -- title: test_ssl failures on Ubuntu 11.10 -> test_ssl failures on Debian/Ubuntu ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Barry A. Warsaw added the comment: TL;DR: Let's rip out the false assumption that an SSLv23 client cannot connect to an SSLv3/TLSv1 server. I now believe this is simply an erroneous assumption on the part of the Python test suite, namely that SSLv23 method clients cannot connect to SSLv3 or TLSv1 servers. Here is an excerpt from openssl's CHANGES file: Changes between 0.9.7g and 0.9.7h [11 Oct 2005] ... *) Change the client implementation for SSLv23_method() and SSLv23_client_method() so that is uses the SSL 3.0/TLS 1.0 Client Hello message format if the SSL_OP_NO_SSLv2 option is set. (Previously, the SSL 2.0 backwards compatible Client Hello message format would be used even with SSL_OP_NO_SSLv2.) [Bodo Moeller] It looks like it's been this way for a long time too. What may have changed recently on Debian/Ubuntu though is that, as of Ubuntu version 1.0.0d-2ubuntu1 (in Ubuntu 11.04), we now use the no-ssl configuration option to disable SSLv2. My guess is that "the SSL_OP_NO_SSLv2 option" gets set by this configuration option, which is what switches the client hello to use SSLv3/TLSv1 format, thus enabling such connections. I'm not entirely sure which Debian version of the package this got changed in, but it certainly works the same way on Wheezy as it does in Oneiric. It's probably too difficult, and not really Python's responsibility, to determine whether SSL_OP_NO_SSLv2 is set. Rather, I think the test is simply bogus and should be disabled or removed. Antoine implies as such in http://bugs.python.org/issue13218#msg145912 A couple of other things: it is not true that Ubuntu (or Debian for that matter) is changing the semantics of a library here. It's simply using a supported upstream configuration option to disable SSLv2, and the openssl library itself changes the semantics of client/server connection success based on that. Also, I think @skip_if_broken_ubuntu_ssl is both a misnomer (since all that behavior is inherited from Debian) and besides, it's useless now since on Debian/Ubuntu, ssl.PROTOCOL_SSLv2 will never be defined, at least with modernish versions of both OS's. But I guess ripping that out is a task for a different bug. -- ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Barry A. Warsaw added the comment: On Oct 25, 2011, at 09:56 AM, Antoine Pitrou wrote: > >Antoine Pitrou added the comment: > >> It looks like it's been this way for a long time too. > >But tests have always passed here using OpenSSL 1.0.0. Right, sorry, what I meant was this particular behavior (switching to SSLv3 client hello when SSLv2 is disabled) appears to have been in upstream openssl since about 2005. What's changed recently is that instead of patching openssl to disable SSLv2 (and thereby not triggering the client hello switch), Debian has started to use the no-ssl Configure option, which is what probably started allowing this test to unexpectedly succeed. >> It's probably too difficult, and not really Python's responsibility, >> to determine whether SSL_OP_NO_SSLv2 is set. > >See http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.options Interesting, thanks for the pointer. >> Rather, I think the test is simply bogus and should be disabled or >> removed. > >I think it would be good to keep a simplified/minimal (and, of course, >working :-)) version of these tests. >Patches welcome, anyway. I can't really test with Debian's OpenSSL. I'll work up a patch. -Barry -- ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Barry A. Warsaw added the comment: I'm not sure I particularly like this patch, and I can't test it on anything other than Debian/Ubuntu right now, but it does "fix" the test (defined as: making it pass :). AFAICT, there's no way to tell openssl to revert back to trying SSLv2 client hello when the library has been compiled with no-ssl, but still setting OP_NO_SSLv2 or OP_NO_TLSv1 kind of seems like keeping a couple of tests that can't possibly succeed (because neither v2 nor v3, nor tlsv1 will be tried). The other thing is that testing the flags on the client context doesn't seem to work: Python 3.2.2+ (3.2:03ef6108beae, Oct 25 2011, 10:57:32) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> cc = ssl.SSLContext(ssl.PROTOCOL_SSLv23) >>> cc.options & ssl.OP_NO_SSLv2 0 Now, the other way to go is to set OP_NO_SSLv2 on both tests and change the sense of it from False to True, so that we'd always expect the connection to succeed. I'll attach that patch next, and it does seem a bit more sane. Let me know what you think. -- Added file: http://bugs.python.org/file23517/issue13218.diff ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Barry A. Warsaw added the comment: Here's the diff that disables SSLv2 and changes the expected sense of the connection results. Again, I can't test this on other than Debian/Ubuntu atm, so feedback would be useful. -- Added file: http://bugs.python.org/file23518/issue13218-true.diff ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Barry A. Warsaw added the comment: On further reflection, I don't much like my second patch either. I don't think it'll be portable. I suggest just removing this test. -- ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Barry A. Warsaw added the comment: On Oct 27, 2011, at 10:08 PM, Antoine Pitrou wrote: >Antoine Pitrou added the comment: > >For the record, both patches work fine here (Mageia 1, OpenSSL 1.0.0d). Cool. I'll try to verify them on OS X 10.6 (and maybe 10.7). If they work there I'll figure out one of them to commit. -- ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Barry A. Warsaw added the comment: I can't test this on OS X 10.7 because of issue 13241 but it works fine on OS X 10.6. I'm going to go with the first diff (i.e. the non-sense changing version). I can't say why I favor that version but since you've both verified it works on !Ubuntu, we'll go with that and let people scream if it starts failing for them. I'll apply to 3.2 and 3.3, back port to 2.7, and then watch the buildbots. -- ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13218] test_ssl failures on Debian/Ubuntu
Changes by Barry A. Warsaw : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue13218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13173] Default values for string.Template
Barry A. Warsaw added the comment: When I need defaults, I make them part of the mapping that gets passed into .substitute() and .safe_substitute(). It doesn't feel to me like it's necessary to attach them to the Template instance. Also, couldn't you just subclass string.Template if you wanted defaults? OTOH, since it can be done in a backward compatible way, I guess I'm -0 on the change. -- ___ Python tracker <http://bugs.python.org/issue13173> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11374] pkgutil.extend_path do not recognize py{c,o} file
Barry A. Warsaw added the comment:
On Nov 29, 2011, at 12:50 PM, Éric Araujo wrote:
>Before you put more work into this, it would be nice to get confirmation from
>one import expert that the bug is valid: I know the import system only
>superficially, and I’m not sure that package/__init__.pyc / .pyo is supported
>by import (if not, then pkgutil should also not support it).
It's an interesting question. Under Python 2, I'd say yes, it should support
source-less imports, just as Python does. Under Python 3, with PEP 3147, I'm
not so sure:
$ cat > foo.py
print('hello world')
$ cat > bar.py
import foo
$ ls
bar.py foo.py
$ python3 bar.py
hello world
$ ls
bar.py foo.py __pycache__/
$ ls __pycache__/
foo.cpython-32.pyc
$ rm -f foo.py
$ python3 bar.py
Traceback (most recent call last):
File "bar.py", line 1, in
import foo
ImportError: No module named foo
Then:
$ mv __pycache__/foo.cpython-32.pyc foo.pyc
$ ls
bar.py foo.pyc __pycache__/
$ python3 bar.py
hello world
So Python 3 source-less imports are still supported, but only when legacy
.pyc/.pyo locations are explicitly used.
My inclination is then -0 on extend_path() supporting .pyc/.pyo but only
*outside* the context of PEP 3147. I.e. do not use imp.cache_from_source().
--
___
Python tracker
<http://bugs.python.org/issue11374>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument, effects code which includes Python.h
Barry A. Warsaw added the comment: Confirmed, and this is really annoying. I'm of the mind to apply your second idea. -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue11147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument, effects code which includes Python.h
Barry A. Warsaw added the comment: Sorry, I meant your first option. -- ___ Python tracker <http://bugs.python.org/issue11147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument, effects code which includes Python.h
Changes by Barry A. Warsaw : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue11147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13572] import _curses fails because of UnicodeDecodeError('utf8' codec can't decode byte 0xb5 ...') on ARM Ubuntu 3.x
Barry A. Warsaw added the comment: Fails in exactly the same way when built from my shell account using current hg head. Does not fail on same version of OS on amd64. -- ___ Python tracker <http://bugs.python.org/issue13572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue1294232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13508] ctypes' find_library breaks with ARM ABIs
Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue13508> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
New submission from Barry A. Warsaw : This is already publicly known and in deep discussion on python-dev. The proper fix is still TBD. Essentially, hash collisions can be exploited to DoS a web framework that automatically parses input forms into dictionaries. Start here: http://mail.python.org/pipermail/python-dev/2011-December/115116.html -- components: Interpreter Core messages: 150522 nosy: barry, benjamin.peterson, georg.brandl priority: release blocker severity: normal status: open title: Hash collision security issue type: security versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Barry A. Warsaw added the comment: On Jan 03, 2012, at 08:24 PM, Antoine Pitrou wrote: >I think on the contrary it must be enabled by default. Leaving security >holes open is wrong. Unless there's evidence of performance regressions or backward incompatibilities, I agree. -- ___ Python tracker <http://bugs.python.org/issue13703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Barry A. Warsaw added the comment: On Jan 03, 2012, at 09:43 PM, Benjamin Peterson wrote: >Barry, when this gets fixed, shall we coordinate release times? Yes! -- ___ Python tracker <http://bugs.python.org/issue13703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Barry A. Warsaw added the comment: On Jan 04, 2012, at 07:30 AM, Raymond Hettinger wrote: >Why is this listed as a release blocker? It is questionable whether it >should be done at all? It is a very aggressive change. It's a release blocker so that the issue won't get ignored before the next release. That doesn't necessarily mean it must be fixed. -- ___ Python tracker <http://bugs.python.org/issue13704> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Barry A. Warsaw added the comment: On Jan 04, 2012, at 06:00 AM, Paul McMillan wrote: >Developers would be startled to find that ordering stays consistent on a 64 >bit build but varies on 32 bit builds. Well, one positive outcome of this issue is that users will finally viscerally understand that dictionary (and set) order should never be relied upon, even between successive runs of the same Python executable. -- ___ Python tracker <http://bugs.python.org/issue13703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13744] raw byte strings are described in a confusing way
New submission from Barry A. Warsaw : The lexical analysis documentation says this: http://docs.python.org/py3k/reference/lexical_analysis.html?highlight=raw%20bytes "Bytes literals are always prefixed with 'b' or 'B';..." "Both string and bytes literals may optionally be prefixed with a letter 'r' or 'R';..." But that would lead you to believe that to get raw byte strings you should use rb"foo". In fact, that's a SyntaxError in Python 2.6+ and Python 3. What *does* work though is br"foo". Either Python should accept both spellings (harder) or the documentation should make it clear that the 'b' must preceded the 'r'. -- assignee: docs@python components: Documentation messages: 150936 nosy: barry, docs@python priority: normal severity: normal status: open title: raw byte strings are described in a confusing way versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13744> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13744] raw byte strings are described in a confusing way
Barry A. Warsaw added the comment: On Jan 09, 2012, at 03:15 PM, Antoine Pitrou wrote: > >Antoine Pitrou added the comment: > >> Either Python should accept both spellings > >+1. Been annoyed several times by this. The $64k question: is this a new feature or a bug? :) -- ___ Python tracker <http://bugs.python.org/issue13744> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13744] raw byte strings are described in a confusing way
Barry A. Warsaw added the comment: On Jan 09, 2012, at 03:35 PM, Antoine Pitrou wrote: > >Antoine Pitrou added the comment: > >> The $64k question: is this a new feature or a bug? :) > >Most certainly a feature... In that case, since we can only add the new prefixes to 3.3, I still think we need to fix the documentation to remove the confusion for stable releases. -- ___ Python tracker <http://bugs.python.org/issue13744> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13748] Allow rb"" literals as an equivalent to br""
Barry A. Warsaw added the comment: On Jan 09, 2012, at 07:27 PM, Antoine Pitrou wrote: >Updated patch with doc. Nicely done. +1 -- ___ Python tracker <http://bugs.python.org/issue13748> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12194] Fix LDFLAGS on Ubuntu 11.04+
Changes by Barry A. Warsaw : -- resolution: -> duplicate status: open -> closed superseder: -> Building Python on multiarch Debian and Ubuntu ___ Python tracker <http://bugs.python.org/issue12194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12226] use secured channel for uploading packages to pypi
Barry A. Warsaw added the comment: Given that 2.6.7 is rc2 with a final release scheduled in 2 days, I don't want to apply this to 2.6 right now. Can you guarantee this won't regress for anybody? If so, then I'm also +0 for 2.6 after the 2.6.7 release. -- ___ Python tracker <http://bugs.python.org/issue12226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12248] __dir__ semantics changed in Python 2.7.2
New submission from Barry A. Warsaw : I'm making this a release blocker for 2.7.2 because I want to ensure that the change is deliberate and appropriate. This is triggered by a bug report in Ubuntu where the change in behavior was noticed: https://bugs.launchpad.net/nova/+bug/791221/+index I have two problems with the change that I'd like to describe. First is the NEWS file entry: - Correct lookup of __dir__ on objects. Among other things, this causes errors besides AttributeError found on lookup to be propagated. This isn't associated with a tracker issue, so it's hard to know why this change was made, or whether there was any discussion of its impact. Second, is this change appropriate for a maintenance release? What problem does it fix and is that worth breaking existing packages for it? I'll attach a simple test program. Run this under 2.7.1 and it works, run it under 2.7.2rc1 and you get a TypeError. -- assignee: benjamin.peterson components: Interpreter Core files: foo.py messages: 137500 nosy: barry, benjamin.peterson priority: release blocker severity: normal status: open title: __dir__ semantics changed in Python 2.7.2 type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file5/foo.py ___ Python tracker <http://bugs.python.org/issue12248> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12248] __dir__ semantics changed in Python 2.7.2
Barry A. Warsaw added the comment: Using sorted() makes sense to me. Note that I've at least accomplished one goal, which is to have a tracker issue that discusses the merits of the change. That way, no matter what the RM decides, I can at least point to an issue for justification when I resolve the downstream bug. :) Thanks! -- ___ Python tracker <http://bugs.python.org/issue12248> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12291] file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3
Changes by Barry A. Warsaw : -- nosy: +georg.brandl priority: normal -> release blocker ___ Python tracker <http://bugs.python.org/issue12291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12248] __dir__ semantics changed in Python 2.7.2
Barry A. Warsaw added the comment: Raymond, I like your patch and I think it addresses the issue nicely. I made one small change, which is to add a test for non-list-sequenceness instead of changing the existing __dir__is_list test. I think both tests are useful to keep. Benjamin, what do you think about this for 2.7.2? -- Added file: http://bugs.python.org/file22302/12248.diff ___ Python tracker <http://bugs.python.org/issue12248> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12335] pysetup create will clobber an existing setup.cfg
New submission from Barry A. Warsaw : I have both a setup.py and a setup.cfg in my package. I wanted to use `pysetup create` to add the new packaging stanzas to my setup.cfg, but instead, pysetup clobbered everything. I think it should instead append (or prepend) the new stuff to the existing file. -- components: Library (Lib) messages: 138348 nosy: barry priority: normal severity: normal status: open title: pysetup create will clobber an existing setup.cfg versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue12335> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12313] make install misses packaging module
Barry A. Warsaw added the comment: Nice to see my search didn't find this bug. ;) I already committed a change to install packaging, but you may want to revert that and commit the patch in this issue. I'll leave that for you to decide! -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue12313> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12335] pysetup create will clobber an existing setup.cfg
Barry A. Warsaw added the comment: On Jun 15, 2011, at 02:04 PM, Éric Araujo wrote: >Well, create is not update :) In its current form, create will save an >existing setup.cfg as setup.cfg.old and generate a new one. The human >operator will then have to merge both files if necessary. Automatically >merging the old file into the new one would raise issues with respect to >comments, whitespace and all that in Pythons < 3.2. > >The doc and help messages are probably unclear about that. I missed the setup.cfg.old. I think that's fine. Probably `create` should print a message that it moved setup.cfg to setup.cfg.old. -- ___ Python tracker <http://bugs.python.org/issue12335> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12370] Use of super overwrites use of __class__ in class namespace
Barry A. Warsaw added the comment: That work around seems ugly. Why not back port the fix? It doesn't seem like it could break anything and it's not even arguably a new feature, right? -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue12370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12370] Use of super overwrites use of __class__ in class namespace
Barry A. Warsaw added the comment: Ah okay, I didn't see that in the changeset. -- ___ Python tracker <http://bugs.python.org/issue12370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12417] Inappropriate copyright on profile files
Barry A. Warsaw added the comment: I think we should apply this to earlier applicable versions too. I would accept this change for Python 2.6. -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue12417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12417] Inappropriate copyright on profile files
Barry A. Warsaw added the comment: Thanks Benjamin! -- ___ Python tracker <http://bugs.python.org/issue12417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12518] In string.Template it's impossible to transform delimiter in the derived class
Barry A. Warsaw added the comment: I don't know that anybody relies on the current behavior and computers are now a bazillion times faster than they were in 2004, so who needs that micro optimization any more? -- ___ Python tracker <http://bugs.python.org/issue12518> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
Barry A. Warsaw added the comment: I'm running into this while trying to backport Python 2.7.2 to Ubuntu 10.04. Our build machines are throwing an error because they catch the implicit cast so as to prevent problems on ia64 and amd64. http://wiki.debian.org/IMplicitPointerConversions I haven't quite gotten the patch to work yet, but when I do, I'll look at applying this patch upstream as well. -- nosy: +barry versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue10309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
Changes by Barry A. Warsaw : -- assignee: -> barry ___ Python tracker <http://bugs.python.org/issue10309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
Barry A. Warsaw added the comment: Python 3.1 is in security only mode, so this patch cannot be applied to that version. -- versions: +Python 3.3 -Python 3.1 ___ Python tracker <http://bugs.python.org/issue10309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
Changes by Barry A. Warsaw : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue10309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12576] urlib.request fails to open some sites
Barry A. Warsaw added the comment: I think this is also a regression in Python 2.7, as reported here: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/813295 -- nosy: +barry versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue12576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12576] urlib.request fails to open some sites
Barry A. Warsaw added the comment: Re-opening, as I think this needs to still be applied to Python 2.7. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue12576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12576] urlib.request fails to open some sites
Barry A. Warsaw added the comment: Never mind. This changeset got applied to 2.7 (thanks!) but didn't get linked in the tracker. changeset: 71523:b66bbbdc7abd branch: 2.7 parent: 71518:73ae3729b8fe user:Senthil Kumaran date:Wed Jul 27 09:37:17 2011 +0800 summary: merge from 3.2 - fix urlopen behavior on sites which do not send (or obsfuscates) Connection: Close header. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue12576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12652] Move documentation of test.support into the devguide
Barry A. Warsaw added the comment: As I just mentioned on python-dev (via Gmane), I'm uncomfortable with moving the documentation for test.support into the devguide. -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue12652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12657] Cannot override JSON encoding of basic type subclasses
New submission from Barry A. Warsaw : I found this out while experimenting with enum types that inherit from int. The json library provides for extending the encoder to handle non-basic types; in those cases, your class's .default() method is called. However, it is impossible to override how basic types are encoded. Worse, if you subclass int, you cannot override how instances of your subclass get encoded, because _iterencode() does isinstance() checks. So enum values which subclass int cannot be properly encoded. I think the isinstance checks should be changed to explicit type equality tests, e.g. `type(o) is int`. -- components: Library (Lib) messages: 141406 nosy: barry priority: normal severity: normal status: open title: Cannot override JSON encoding of basic type subclasses versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue12657> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12752] locale.normalize does not take unicode strings
Barry A. Warsaw added the comment:
A cheap way of fixing this would be to test for str-ness of localename and if
it's a unicode, just localname.encode('ascii')
Or is that completely insane?
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue12752>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12752] locale.normalize does not take unicode strings
Barry A. Warsaw added the comment:
For example:
diff -r fb49394f75ed Lib/locale.py
--- a/Lib/locale.py Mon Aug 15 14:24:15 2011 +0300
+++ b/Lib/locale.py Mon Aug 15 16:47:23 2011 -0400
@@ -355,6 +355,8 @@
"""
# Normalize the locale name and extract the encoding
+if isinstance(localename, unicode):
+localename = localename.encode('ascii')
fullname = localename.translate(_ascii_lower_map)
if ':' in fullname:
# ':' is sometimes used as encoding delimiter.
diff -r fb49394f75ed Lib/test/test_locale.py
--- a/Lib/test/test_locale.py Mon Aug 15 14:24:15 2011 +0300
+++ b/Lib/test/test_locale.py Mon Aug 15 16:47:23 2011 -0400
@@ -412,6 +412,11 @@
locale.setlocale(locale.LC_CTYPE, loc)
self.assertEqual(loc, locale.getlocale())
+def test_normalize_issue12752(self):
+# Issue #1813 caused a regression where locale.normalize() would no
+# longer accept unicode strings.
+self.assertEqual(locale.normalize(u'en_US'), 'en_US.ISO8859-1')
+
def test_main():
tests = [
--
___
Python tracker
<http://bugs.python.org/issue12752>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12752] locale.normalize does not take unicode strings
Changes by Barry A. Warsaw : -- keywords: +patch Added file: http://bugs.python.org/file22904/issue12752.diff ___ Python tracker <http://bugs.python.org/issue12752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12752] locale.normalize does not take unicode strings
Changes by Barry A. Warsaw : -- assignee: -> barry ___ Python tracker <http://bugs.python.org/issue12752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12752] locale.normalize does not take unicode strings
Changes by Barry A. Warsaw : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue12752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw added the comment: @Sandro: >> FTR, for Debian and derivatives, doko chose to use 'linux2' when building on >> linux3. >Luckily that has just been reverted. No, I don't think it has: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633015 On Debian Wheezy and Ubuntu 11.10: $ python2.7 -c 'import sys; print sys.platform' linux2 $ python3.2 -c 'import sys; print(sys.platform)' linux2 oneiric$ uname -a Linux resist 3.0.0-8-generic #11-Ubuntu SMP Fri Aug 12 20:23:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux wheezy$ uname -a Linux chemistry 3.0.0-1-amd64 #1 SMP Sun Jul 24 02:24:44 UTC 2011 x86_64 GNU/Linux I agree with MvL that Python 3.3 should set sys.platform to 'linux' and all stable releases should be patched to return 'linux2' on MACHDEP='linux3' systems. configure.in already special cases cygwin* and darwin* to the major-version-number-less platform string, so this doesn't seem like much of a stretch to me for linux. Since applications/libraries that already test against literal sys.platform values will be broken no matter what we do (except perhaps retain 'linux2' for perpetuity, which doesn't seem like a good idea), I think we should make a clean break from the major version number in Python 3.3 and keep backward compatibility for released Pythons. Seems like the least worst option to me. -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw added the comment: On Aug 16, 2011, at 02:28 PM, Sandro Tosi wrote: >that's because you're on wheezy, that has 2.7.2-3, while the version >which has the change reverted is -4 (still not transition to testing, >since outdated on kbsd-i386) I think it's back in -5 though. $ apt-cache show python2.7 | grep Version Version: 2.7.2-5 (On Ubuntu) -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw added the comment: On Aug 18, 2011, at 01:20 AM, James Y Knight wrote: >James Y Knight added the comment: > >> I will backport the fix to 2.7 and 3.2. > >Uh, wait, so does that mean you're *not* going to do the >compatibility-preserving thing and force sys.platform to stay linux2 even >when python is built (BUILT! not run!) on a machine where the active kernel >is linux 3.x? My question too! I would say that stable releases should probably not get this change, but should force sys.platform to linux2 on 3.x kernels. BTW, does anybody think sys.platform should use a more dynamic approach for calculating its value? Well, maybe not necessary if Python 3.3 will just say 'linux'. -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw added the comment: On Aug 18, 2011, at 01:15 PM, Charles-François Natali wrote: >Charles-François Natali added the comment: > >> My question too! I would say that stable releases should probably not get >> this change, but should force sys.platform to linux2 on 3.x kernels. > >The point is precisely that we don't change anything: applications >checking against sys.platform are already broken, there's no reason to >comfort them into using this defective check. >The applications that encountered the problem (chromium, matplotlib >and probably others) already performed the change to >sys.platform.startswith(), so it's really the only way to go. I still think that sys.platform for the stable releases should never report 'linux3'. Updating the various conditionals *probably* has low risk of regression, but I think you have to check that very carefully. >> BTW, does anybody think sys.platform should use a more dynamic approach for >> calculating its value? Well, maybe not necessary if Python 3.3 will just >> say 'linux'. > >There's already platform.system() for that. TOOWTDI -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
