From report at bugs.python.org Fri Jun 1 00:00:13 2012 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 31 May 2012 22:00:13 +0000 Subject: [issue14972] listcomp with nested classes In-Reply-To: <1338500454.97.0.157911114425.issue14972@psf.upfronthosting.co.za> Message-ID: <1338501613.86.0.236425203655.issue14972@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 00:04:02 2012 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Thu, 31 May 2012 22:04:02 +0000 Subject: [issue14972] listcomp with nested classes In-Reply-To: <1338500454.97.0.157911114425.issue14972@psf.upfronthosting.co.za> Message-ID: <1338501842.79.0.24380775071.issue14972@psf.upfronthosting.co.za> Westley Mart?nez added the comment: $ python Python 3.2.3 (default, Apr 23 2012, 23:35:30) [GCC 4.7.0 20120414 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... x = 42 ... y = [x for _ in '1'] ... Traceback (most recent call last): File "", line 1, in File "", line 3, in A File "", line 3, in NameError: global name 'x' is not defined >>> x = 42 >>> class A: ... x = 12 ... y = [x for _ in '1'] ... >>> A.y [42] It seems that the list comprehension is looking at the module's scope as opposed to the class scope. This definitely seems incorrect to me. ---------- nosy: +anikom15 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 00:05:14 2012 From: report at bugs.python.org (rurpy the second) Date: Thu, 31 May 2012 22:05:14 +0000 Subject: [issue14973] restore python2 unicode literals in "ru" strings Message-ID: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za> New submission from rurpy the second : PEP 414 proposes restoring the "u" string prefix (semantically as a "noop") to make porting from Python2 easier. I would like to propose that "ru"-strings also interpret embedded "\uxxxx" unicode literals in the python2 fashion (as a single unicode character) rather than in the python 3.2 fashion (as 6 characters). Many Python2 programs use unicode literals in strings because they can be represented and displayed in source code with the ascii character set. For example, I often write ur" \u3000\u3042\t" rather than ur" ?? " because the former is much clearer in source code than the latter and does not require the viewer to have a Japanese font installed. However such a string must be manually converted for Python3 because the former string has a very different meaning in Python3 than Python2. The equivalent in Python3 is " \u3000\u3042\\t". AFAIK, 2to3 does not fix this. Because there are no longer unicode literals in Python3 raw strings, any string with a unicode literal *has* to be a non-raw string (AFAICT). This means that strings used as regexes, that have a lot of backslashes and have unicode literals, must have the backslashes doubled. Doubling the backslashes in the above example is trivial but it is not trival in more realistic regexes. This was one of the main reasons for having raw strings in Python2 I thought. It is unfortunate that one looses this ability (in the presence of unicode literals) in Python3. When I raised this issue on the Python user's list [*1], Terry Reedy made the suggestion that since the "u" string prefix was being reintroduced for python 3.3, that having the prefix also restore the python2 unicode literal handling would not introduce any incompatibilties and would greatly increase the ease of porting to Python3 for some programs.[*2] He subsequently raised the issue on the dev list.[*3] An argument might be made that this is an extra feature that would encourage the use of the "u"-prefix beyond that of easing porting from Python2. Perhaps so but there is currently a hole in Python's capability that is difficult to work around, and I've seen no other proposals to fix it. So it seems to me that the benefits of this proposal greatly outweigh that somewhat purist argument. ---- [*1] http://mail.python.org/pipermail/python-list/2012-May/1292870.html [*2] http://mail.python.org/pipermail/python-list/2012-May/1292887.html [*3] http://mail.python.org/pipermail/python-dev/2012-May/119760.html ---------- components: Unicode messages: 162025 nosy: ezio.melotti, rurpy2 priority: normal severity: normal status: open title: restore python2 unicode literals in "ru" strings type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 00:07:51 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 31 May 2012 22:07:51 +0000 Subject: [issue14972] listcomp with nested classes In-Reply-To: <1338500454.97.0.157911114425.issue14972@psf.upfronthosting.co.za> Message-ID: <1338502071.93.0.92933499187.issue14972@psf.upfronthosting.co.za> R. David Murray added the comment: This is doubtless a result of the way the class namespace scope is handled, coupled with the fact that in Python3 list comprehensions have a local scope. The class scope is a somewhat unique beast. I agree that this is unfortunate, but I have a feeling that doing anything about it is distinctly non-trivial. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 00:14:22 2012 From: report at bugs.python.org (Alexis Metaireau) Date: Thu, 31 May 2012 22:14:22 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index Message-ID: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za> New submission from Alexis Metaireau : PyPI is the name of a particular index, whereas "index" is a generic term. So ISTM that it would be better to use the latter, semantically-wise. ---------- assignee: alexis components: Distutils2 messages: 162027 nosy: alexis, tarek priority: normal severity: normal stage: needs patch status: open title: rename packaging.pypi to packaging.index type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 00:21:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 31 May 2012 22:21:43 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset bd2c2def77a7 by Hynek Schlawack in branch 'default': #14814: Remove stale __hex__ method from ipaddress http://hg.python.org/cpython/rev/bd2c2def77a7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 00:26:14 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 31 May 2012 22:26:14 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index In-Reply-To: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za> Message-ID: <1338503174.79.0.779088652497.issue14974@psf.upfronthosting.co.za> Hynek Schlawack added the comment: While I can see your point, I think that "index" is way too generic. I also think that the pypi term is overloaded with both meanings. ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 00:42:25 2012 From: report at bugs.python.org (YF) Date: Thu, 31 May 2012 22:42:25 +0000 Subject: [issue14975] import unicodedata, DLL load failed on Python 2.7.3 Message-ID: <1338504145.87.0.920765614951.issue14975@psf.upfronthosting.co.za> New submission from YF : Before I use the Python 2.7.2 on Windows XP, today I tried to upgrade to the Python 2.7.3, but encountered a problem. When running any .py file encountered "import unicodedata" or directly run the command always returns: Traceback (most recent call last): ...... import unicodedata ImportError: DLL load failed: ????????? "????????" corresponding English is "Cannot find the specified program". I unable provide more information because I am only a user rather than developer. After that, I manually delete "C:\Python27\DLLs\unicodedata.pyd" file (this step must be, otherwise no effect), then reinstall (Repair) Python 2.7.2 the problem disappeared. ---------- components: Unicode messages: 162030 nosy: ezio.melotti, yfdyh000 priority: normal severity: normal status: open title: import unicodedata, DLL load failed on Python 2.7.3 type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 01:17:25 2012 From: report at bugs.python.org (lesha) Date: Thu, 31 May 2012 23:17:25 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338506245.08.0.535698672346.issue6721@psf.upfronthosting.co.za> lesha added the comment: I am really alarmed by the reinit_locks patches. I scanned the comment history, and looked at the patch. I may have missed something, but it looks to me like the basic behavior is this: "After fork(), all locks are replaced by brand-new lock objects that are NOT locked." *Grim Prediction*: This is going to cause some disastrous, unexpected, and hilarious data loss or corruption for somebody. Here is why: class MySQLConn: def __init__(self): self.lock = Lock() def doWork(self): self.lock.acquire() # do a sequence of DB operations that must not be interrupted, # and cannot be made transactional. self.lock.release() Run this in a thread: def thread1(conn): while True: conn.doWork() time.sleep(0.053) Run this in another thread: def thread2(conn): while True: conn.doWork() time.sleep(0.071) Run this in a third thread: def thread2(): while True: subprocess.call(["ls", "-l"]) time.sleep(0.3) With reinit_locks(), this will eventually break horribly. a) fork() is called with the DB lock held by thread1. b) Some time passes before the child gets to exec(). c) In that time, the child's thread2 gets to doWork(). d) Simultaneously, the parent's doWork is still running and holding a lock. e) Thanks to reinit_locks, the child's thread2 does not have a lock, and it will merrily proceed to corrupt the parent's work. So I think this approach is basically doomed. I think my approach of marking _some_ locks as safe to reinit upon fork is workable (i.e. to solve the bad interaction with logging or import). However, there's also an orthogonal approach that might work well: 1) Right before the first thread gets created in any Python program, fork off a fork() server. >From then on, subprocess will only use the fork server to call commands. Thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 01:34:03 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 31 May 2012 23:34:03 +0000 Subject: [issue14972] listcomp with nested classes In-Reply-To: <1338500454.97.0.157911114425.issue14972@psf.upfronthosting.co.za> Message-ID: <1338507243.17.0.0565229298082.issue14972@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 01:36:07 2012 From: report at bugs.python.org (Michael Foord) Date: Thu, 31 May 2012 23:36:07 +0000 Subject: [issue14971] (unittest) loadTestsFromName does not work on method with a decorator In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za> Message-ID: <1338507367.89.0.969625389225.issue14971@psf.upfronthosting.co.za> Michael Foord added the comment: Whilst functools.wraps would fix the problem it still sounds like a bug (or at the very least a reasonable feature request). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 01:52:04 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 31 May 2012 23:52:04 +0000 Subject: [issue14959] ttk.Scrollbar in Notebook widget freezes In-Reply-To: <1338340992.23.0.15573788402.issue14959@psf.upfronthosting.co.za> Message-ID: <1338508324.92.0.546177186344.issue14959@psf.upfronthosting.co.za> Ned Deily added the comment: Another data point: I just tried the same test using a Python 3.2.3 linked with an X11 Tk 8.5 (MacPorts) rather than the ActiveState Cocoa Tk 8.5.11 (python.org Python). I was not able to get the test to fail with X11 Tk so that tends to support the idea that the root cause is somewhere in Aqua Tk. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 02:11:00 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 01 Jun 2012 00:11:00 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338509460.97.0.669745711306.issue6721@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > a) fork() is called with the DB lock held by thread1. > b) Some time passes before the child gets to exec(). > c) In that time, the child's thread2 gets to doWork(). > d) Simultaneously, the parent's doWork is still running and holding a lock. > e) Thanks to reinit_locks, the child's thread2 does not have a lock, and > it will merrily proceed to corrupt the parent's work. You seem to be saying that all three threads survive the fork. I think forkall() on Solaris acts like that, but the normal fork() function does not. Only the thread which performs fork() will survive in the child process. So doWork() never runs in the child process, and the lock is never used in the child process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 02:14:27 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 01 Jun 2012 00:14:27 +0000 Subject: [issue14975] import unicodedata, DLL load failed on Python 2.7.3 In-Reply-To: <1338504145.87.0.920765614951.issue14975@psf.upfronthosting.co.za> Message-ID: <1338509667.04.0.21677823088.issue14975@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I do not believe that this is a problem in Python. Instead, it appears that your Python installation got corrupted somehow. I recommend to run a virus scanner. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 02:25:02 2012 From: report at bugs.python.org (lesha) Date: Fri, 01 Jun 2012 00:25:02 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338510302.26.0.284042780947.issue6721@psf.upfronthosting.co.za> lesha added the comment: > I think forkall() on Solaris acts like that, but the normal fork() > function does not. Only the thread which performs fork() will survive > in the child process. Sorry, brain fail. A slightly more contrived failure case is this: subprocess.Popen( ..., preexec_fn=lambda: conn.doWork() ) Everything else is the same. Another failure case is: class MySQLConn: ... doWork as before ... def __del__(self): self.doWork() Followed by: def thread3(conn): while True: subprocess.call(['nonexistent_program']) time.sleep(0.1) The destructor will fire in the child and corrupt the parent's data. An analogous example is: conn = MySQLConn() start_thread1(conn) start_thread2(conn): while True: if os.fork() == 0: # child raise Exception('doom') # triggers destructor Basically, it is really really dangerous to release locks that protect any resources that are not copied by fork (i.e. network resources, files, DB connections, etc, etc). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 03:11:33 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 01 Jun 2012 01:11:33 +0000 Subject: [issue14969] Use __suppress_context__ in contextlib.ExitStack.__exit__ In-Reply-To: <1338471704.64.0.423710323237.issue14969@psf.upfronthosting.co.za> Message-ID: <1338513093.21.0.350724186564.issue14969@psf.upfronthosting.co.za> Nick Coghlan added the comment: Electronic contributor forms are actually on the PSF wishlist. We'll get there some day (maybe after the website update). Getting back to the problem at hand, I think you might be on to something with the idea of exploiting PEP 409 to handle this. Specifically, where we reraise a caught exception when there are no exception details active, we should be able to replace the bare raise with something like: # A containing with statement will automatically add the exception # context back in after it gets suppressed. Avoid displaying it. if suppressed_exc and exc_details == (None, None, None): raise exc from None raise That way, the exception *display* of escaping exceptions will still match that of nested with statements, even though the attributes are subtly different (__suppress_context__ being set to True, rather than __context__ being None) ---------- title: Restore sys.exc_clear()? -> Use __suppress_context__ in contextlib.ExitStack.__exit__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 03:16:42 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 01 Jun 2012 01:16:42 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338513402.36.0.761205879606.issue6721@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Anyone using a preexec function in subprocess has already declared that they like deadlocks so that isn't an issue. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 03:20:23 2012 From: report at bugs.python.org (lesha) Date: Fri, 01 Jun 2012 01:20:23 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338513623.28.0.790967315796.issue6721@psf.upfronthosting.co.za> lesha added the comment: Deadlocks are dandy, but corruption is cruel. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 03:26:56 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 01 Jun 2012 01:26:56 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338514016.43.0.891727016505.issue6721@psf.upfronthosting.co.za> Gregory P. Smith added the comment: threading locks cannot be used to protect things outside of a single process. Any code using them to do that is broken. In your examples you are suggesting a class that wants to do one or more mysql actions within a destructor and worried that the __del__ method would be called in the fork()'ed child process. With the subprocess module, this will never happen. the child exec's or does a hard exit. http://hg.python.org/cpython/file/bd2c2def77a7/Modules/_posixsubprocess.c#l634 When someone is using os.fork() directly, they are responsible for all destructors in their application behaving sanely within the child process. Destructors are an evil place to put code that does actual work and are best avoided. When required, they must be written defensively because they really cannot depend on much of the Python execution environment around them being in a functional state as they have no control over _when_ they will be called during shutdown. Nothing new here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 03:51:39 2012 From: report at bugs.python.org (lesha) Date: Fri, 01 Jun 2012 01:51:39 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338515499.2.0.752476076503.issue6721@psf.upfronthosting.co.za> lesha added the comment: Re "threading locks cannot be used to protect things outside of a single process": The Python standard library already violates this, in that the "logging" module uses such a lock to protect the file/socket/whatever, to which it is writing. If I had a magic wand that could fix all the places in the world where people do this, I'd accept your argument. In practice, threading locks are abused in this way all the time. Most people don't even think about the interaction of fork and threads until they hit a bug of this nature. Right now, we are discussing a patch that will take broken code, and instead of having it deadlock, make it actually destroy data. I think this is a bad idea. That is all I am arguing. I am glad that my processes deadlocked instead of corrupting files. A deadlock is easier to diagnose. You are right: subprocess does do a hard exit on exceptions. However, the preexec_fn and os.fork() cases definitely happen in the wild. I've done both of these before. I'm arguing for a simple thing: let's not increase the price of error. A deadlock sucks, but corrupted data sucks much worse -- it's both harder to debug, and harder to fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 04:41:19 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 02:41:19 +0000 Subject: [issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move In-Reply-To: <1333576900.91.0.0583021085072.issue14499@psf.upfronthosting.co.za> Message-ID: <1338518479.82.0.456125130675.issue14499@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 04:43:09 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 02:43:09 +0000 Subject: [issue14957] Improve docs for str.splitlines In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za> Message-ID: <1338518589.56.0.0545826166646.issue14957@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +easy nosy: +eric.araujo stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 04:51:28 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 02:51:28 +0000 Subject: [issue14950] packaging.install does not have a clear API. In-Reply-To: <1338288446.67.0.0715913421745.issue14950@psf.upfronthosting.co.za> Message-ID: <1338519088.06.0.996062086103.issue14950@psf.upfronthosting.co.za> ?ric Araujo added the comment: To summarize the high-level API needed: install from an index (argument is a version requirement as string), install archive file, install from directory (containing setup.cfg or setup.py). When #8668 is implemented, an ?editable? option will be nice too. (Need to check pip doc and use cases to see if only the install from directory should get it.) For the implementation, as discussed on IRC we want to go with classes to represent the various kinds of installable things (requirement, path to a file, path to a dir) and one or more high-level functions to wrap them for common cases (see Nick?s good article http://www.boredomandlaziness.org/2012/05/djangos-cbvs-are-not-mistake-but.html ). I would prefer having two functions, one that takes a version req and another one that takes a path; it?s easy to distinguish between file (archive) and directory but I don?t like guessing between name and path (see the not-cool code in pysetup actions). ---------- nosy: +eric.araujo versions: +3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 04:52:48 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 02:52:48 +0000 Subject: [issue14950] Make packaging.install API less confusing and more extensible In-Reply-To: <1338288446.67.0.0715913421745.issue14950@psf.upfronthosting.co.za> Message-ID: <1338519168.82.0.73241134396.issue14950@psf.upfronthosting.co.za> ?ric Araujo added the comment: BTW I suggest you work off a d2 checkout; I have not ported all changes from Montreal sprints to cpython/p7g at the moment. ---------- title: packaging.install does not have a clear API. -> Make packaging.install API less confusing and more extensible _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 04:53:22 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 02:53:22 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1338519202.23.0.0611680498103.issue14965@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo stage: -> needs patch versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 04:54:54 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 02:54:54 +0000 Subject: [issue14968] Section "Inplace Operators" of :mod:`operator` should be a subsection In-Reply-To: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za> Message-ID: <1338519294.76.0.168361446341.issue14968@psf.upfronthosting.co.za> ?ric Araujo added the comment: Good catch, +1 for the patch. ---------- nosy: +eric.araujo, sandro.tosi stage: -> commit review versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 05:01:19 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 03:01:19 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index In-Reply-To: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za> Message-ID: <1338519679.32.0.432312763449.issue14974@psf.upfronthosting.co.za> ?ric Araujo added the comment: We could use ?catalog? (see how the interest group for PyPI is named catalog-sig), but it sounds a bit abstract to me, and at the same time fails to convey that this module deals with finding things (in an index/catalog) and also download them (from PyPI or third-party sites). Anyway I don?t think names can be perfect; just like distutils2.database may be ambiguous if one doesn?t know that it works with the database of installed projects, distutils2.index can be ambiguous if one doesn?t know that the repository of information (and sometimes downloads) is called an index. +1 for distutils2.index +0.3 for distutils2.repository (long, and mostly used with VCS these days) ?0 for distutils2.pypi ---------- nosy: +eric.araujo versions: +3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 05:22:47 2012 From: report at bugs.python.org (Roger Serwy) Date: Fri, 01 Jun 2012 03:22:47 +0000 Subject: [issue14958] IDLE 3 and PEP414 - highlighting unicode literals In-Reply-To: <1338338268.62.0.441053102014.issue14958@psf.upfronthosting.co.za> Message-ID: <1338520967.8.0.937572580748.issue14958@psf.upfronthosting.co.za> Roger Serwy added the comment: Attached is a backport to 2.7. ---------- keywords: +patch versions: +Python 2.7 Added file: http://bugs.python.org/file25778/issue14958_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 06:10:21 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Jun 2012 04:10:21 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338523821.53.0.0562582374601.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: This patch incorporates types.SimpleNamespace and makes the repr show all attributes. Tests and docs for types.SimpleNamespace are also included. The patch skips 3 tests (which I added) that are failing. One has a segfault due to a recursive repr (where I had a hunch that something funny would happen). One is a situation that I mentioned earlier in this ticket. However, the third one was entiredly unexpected. None of these pathologies impact sys.implementation. I will be working on fixing them regardless. If you want to wait until I fix the corner cases, I'm fine with that. However, the patch should be good to go as far as sys.implementation is concerned. ---------- Added file: http://bugs.python.org/file25779/issue14673_full.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 06:16:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jun 2012 04:16:51 +0000 Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a29ae1c2b8b2 by Eli Bendersky in branch 'default': Issue #14007: make XMLParser a real subclassable type exported from _elementtree. +cleanups http://hg.python.org/cpython/rev/a29ae1c2b8b2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 07:06:47 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Jun 2012 05:06:47 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338527207.2.0.848002559883.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: Guess I should have tested the docs before posting the patch. ;) ---------- Added file: http://bugs.python.org/file25780/issue14673_full.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 07:07:01 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Jun 2012 05:07:01 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338527221.74.0.264154957237.issue14673@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file25779/issue14673_full.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 07:31:41 2012 From: report at bugs.python.org (josmiley) Date: Fri, 01 Jun 2012 05:31:41 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1338528701.59.0.292169877908.issue14965@psf.upfronthosting.co.za> josmiley added the comment: >>> class DerivedProp(BaseProp): ... @property ... def p(self): ... return super(DerivedProp, self).p * 2 ... @p.setter ... def p(self, value): ... BaseProp.p.__set__(self,value / 2) ---------- nosy: +josmiley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 07:38:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jun 2012 05:38:08 +0000 Subject: [issue14973] restore python2 unicode literals in "ur" strings In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za> Message-ID: <1338529088.81.0.109915338198.issue14973@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue3665. ---------- nosy: +storchaka title: restore python2 unicode literals in "ru" strings -> restore python2 unicode literals in "ur" strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:25:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jun 2012 06:25:32 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1338531932.68.0.609146334611.issue3665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't think it is worth to target it for 2.7 and 3.2 (it's new feature, not bugfix), but for 3.3 it will be very useful. Since PEP 393 conversion to the surrogate pairs is no longer relevant. ---------- components: +Regular Expressions, Unicode nosy: +storchaka type: behavior -> enhancement versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:35:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jun 2012 06:35:08 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1338532508.25.0.311585179622.issue3665@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25781/re_unicode_escapes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:36:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jun 2012 06:36:02 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1338532562.4.0.738956247542.issue3665@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25782/3665.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:36:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jun 2012 06:36:47 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1338532607.75.0.516377738466.issue3665@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file25781/re_unicode_escapes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:37:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jun 2012 06:37:02 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1338532622.43.0.874732591746.issue3665@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file25782/3665.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:43:09 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 01 Jun 2012 06:43:09 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338532989.67.0.921508654456.issue6721@psf.upfronthosting.co.za> Gregory P. Smith added the comment: We could make any later attempt to acquire or release a lock that was reinitialized while it was held raise an exception. Such exception raising behavior should be conditional at lock construction time; some code (such as logging) never wants to deal with one because it is unacceptable for it to ever fail or deadlock. It should also be possible for the exception to be usefully handled if caught; locks should gain an API to clear their internal "reinitialized while held" flag. Q: Should .release() raise the exception? Or just warn? I'm thinking no exception on release(). Releasing a lock that was held during re-initialization could just reset the "reinitialized while held" flag. The acquire() that would deadlock or crash today would be where raising an exception makes the most sense. Deadlocks are unacceptable. The whole point of this bug is that we can do better. An exception would provide a stack trace of exactly which thing where caused the offending operation so that the code can be fixed to not misuse locks in the first place or that specific lock can be changed to silent reinitialization on fork. (or better yet, the fork can be removed entirely) Both behaviors are better than today. This change would surface bugs in people's code much better than difficult to debug deadlocks. It should be a pretty straightforward change to reinit_locks_2 (Patch Set 6) to behave that way. Looking back, raising an exception is pretty much what I suggested in http://bugs.python.org/issue6721#msg94115 2.5 years ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:43:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jun 2012 06:43:52 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1338533032.94.0.886377937856.issue3665@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25783/re_unicode_escapes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:44:38 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jun 2012 06:44:38 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1338533078.52.0.697452043511.issue3665@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25784/3665.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 08:58:59 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 01 Jun 2012 06:58:59 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338533939.6.0.779827783959.issue6721@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > conn = MySQLConn() > start_thread1(conn) > start_thread2(conn): > while True: > if os.fork() == 0: # child > raise Exception('doom') # triggers destructor There is no guarantee here that the lock will be held at the time of the fork. So even if we ensure that a lock acquired before the fork stayed lock, we won't necessarily get a deadlock. More importantly, you should never fork without ensuring that you exit with os._exit() or os.exec*(). So your example should be something like conn = MySQLConn() start_thread1(conn) start_thread2(conn): while True: if os.fork() == 0: # child try: raise Exception('doom') # does NOT trigger destructor except: sys.excepthook(*sys.exc_info()) os._exit(1) else: os._exit(0) With this hard exit the destructor never runs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:09:42 2012 From: report at bugs.python.org (alon horev) Date: Fri, 01 Jun 2012 08:09:42 +0000 Subject: [issue14969] Use __suppress_context__ in contextlib.ExitStack.__exit__ In-Reply-To: <1338471704.64.0.423710323237.issue14969@psf.upfronthosting.co.za> Message-ID: <1338538182.43.0.73695962002.issue14969@psf.upfronthosting.co.za> alon horev added the comment: Ok, so turns out this was just a stupid bug: we set the __context__ attr only if an exception is raised, but not when an exception has been previously 'cleared'. so the context is filled (by python) with the last exception raised which is the outer one. deleting the 'if last context is an exception' solved it. This is how I understood it: the exception's __context__ is set when it's raised and not in its except clause, meaning there is no way the outer with is mutating our inner exceptions. using pdb I saw the outer exception being explicitly set. ---------- keywords: +patch Added file: http://bugs.python.org/file25785/14963.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:23:47 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 01 Jun 2012 08:23:47 +0000 Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when called with a str() In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za> Message-ID: <1338539027.01.0.963415593145.issue9544@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:26:11 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 01 Jun 2012 08:26:11 +0000 Subject: [issue12354] packaging.pypi.simple docs use both client and crawler variable, which might be confusing In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za> Message-ID: <1338539171.12.0.524370118219.issue12354@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Can this be closed? ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:28:53 2012 From: report at bugs.python.org (Alexis Metaireau) Date: Fri, 01 Jun 2012 08:28:53 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index In-Reply-To: <1338519679.32.0.432312763449.issue14974@psf.upfronthosting.co.za> Message-ID: <4FC87D43.3040804@notmyidea.org> Alexis Metaireau added the comment: We are all calling these indexes quite everywhere. We are talking about a Python Package Index and even the mirroring infrastructure is talking about indexes. Because that's under the "packaging" namespace, it's kind of obvious that this deals with indexes "like PyPI". Of course, we also have the documentation which is a good starting point to make people realize what this is about; but I really don't think naming this "index" will be a blocker for anyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:34:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jun 2012 08:34:31 +0000 Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6f9bfcc1896f by Eli Bendersky in branch 'default': Issue #14007: implement doctype() method calling in XMLParser of _elementtree. http://hg.python.org/cpython/rev/6f9bfcc1896f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:36:57 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 01 Jun 2012 08:36:57 +0000 Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za> Message-ID: <1338539817.35.0.35539523823.issue14007@psf.upfronthosting.co.za> Eli Bendersky added the comment: The latest commit completes this issue. ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:40:12 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 01 Jun 2012 08:40:12 +0000 Subject: [issue14852] json and ElementTree parsers misbehave on streams containing more than a single object In-Reply-To: <1337362162.37.0.214988903095.issue14852@psf.upfronthosting.co.za> Message-ID: <1338540012.12.0.407187250637.issue14852@psf.upfronthosting.co.za> Eli Bendersky added the comment: I propose to close this issue. If the problem in json is real and someone thinks it has to be fixed, a separate issue specifically for json should be opened. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:42:13 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 01 Jun 2012 08:42:13 +0000 Subject: [issue14128] _elementtree should expose types and factory functions consistently with ElementTree In-Reply-To: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za> Message-ID: <1338540133.97.0.876368990975.issue14128@psf.upfronthosting.co.za> Eli Bendersky added the comment: Done with the recent completion of #14007 ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:43:06 2012 From: report at bugs.python.org (=?utf-8?q?Johan_Aires_Rast=C3=A9n?=) Date: Fri, 01 Jun 2012 08:43:06 +0000 Subject: [issue14976] Queue.PriorityQueue() is not interrupt safe Message-ID: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za> New submission from Johan Aires Rast?n : Python 2.7.3 (default, Apr 20 2012, 22:39:59) [GCC 4.6.3] on linux2 If a signal handler calls Queue.PriorityQueue.put and a second signal is received while one is already being processed, neither of the calls to put will terminate. Highly dependent on timing so it might be difficult to reproduce. ---------- components: Library (Lib) messages: 162062 nosy: JohanAR priority: normal severity: normal status: open title: Queue.PriorityQueue() is not interrupt safe type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 10:59:35 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 01 Jun 2012 08:59:35 +0000 Subject: [issue12354] packaging.pypi.simple docs use both client and crawler variable, which might be confusing In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za> Message-ID: <1338541175.28.0.0253785835046.issue12354@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 11:18:59 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 01 Jun 2012 09:18:59 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338542339.74.0.762294429546.issue6721@psf.upfronthosting.co.za> Vinay Sajip added the comment: >> Re "threading locks cannot be used to protect things outside of a >> single process": > The Python standard library already violates this, in that the > "logging" module uses such a lock to protect the file/socket/whatever, > to which it is writing. logging is not doing anything to protect things *outside* of a single process - the logging docs make that clear, and give specific recommendations for how to use logging in a multi-process scenario. Logging is just using locks to manage contention between multiple threads in a single process. In that sense, it is no different to any other Python code that uses locks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 11:28:53 2012 From: report at bugs.python.org (Emmanuel Beffara) Date: Fri, 01 Jun 2012 09:28:53 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards Message-ID: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> New submission from Emmanuel Beffara : According to RFC 1542, the first matching entry in mailcap files should be used for handling a given type. The mailcap module does not respect this rule when wildcards are used in some rules, because the "lookup" function always checks entries for a specific type (say image/jpeg) before checking the generic ones (image/*). As a consequence, if a user overrides system defaults using a generic type, this choice is not satisfied, and the behaviour is inconsistent with other tools using mailcap (including the standard "run-mailcap"). ---------- components: Library (Lib) messages: 162064 nosy: manu-beffara priority: normal severity: normal status: open title: mailcap does not respect precedence in the presence of wildcards type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 11:39:02 2012 From: report at bugs.python.org (=?utf-8?q?Johan_Aires_Rast=C3=A9n?=) Date: Fri, 01 Jun 2012 09:39:02 +0000 Subject: [issue14976] Queue.PriorityQueue() is not interrupt safe In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za> Message-ID: <1338543542.65.0.985250156226.issue14976@psf.upfronthosting.co.za> Changes by Johan Aires Rast?n : Added file: http://bugs.python.org/file25786/queue_deadlock.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 11:40:02 2012 From: report at bugs.python.org (=?utf-8?q?Johan_Aires_Rast=C3=A9n?=) Date: Fri, 01 Jun 2012 09:40:02 +0000 Subject: [issue14976] Queue.PriorityQueue() is not interrupt safe In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za> Message-ID: <1338543602.14.0.456316340376.issue14976@psf.upfronthosting.co.za> Changes by Johan Aires Rast?n : Added file: http://bugs.python.org/file25787/queue_sendint.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 11:44:20 2012 From: report at bugs.python.org (=?utf-8?q?Johan_Aires_Rast=C3=A9n?=) Date: Fri, 01 Jun 2012 09:44:20 +0000 Subject: [issue14976] Queue.PriorityQueue() is not interrupt safe In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za> Message-ID: <1338543860.02.0.0611285884684.issue14976@psf.upfronthosting.co.za> Johan Aires Rast?n added the comment: Start queue_deadlock.py in one terminal and note the PID it prints. Compile queue_sendint.c in another terminal and execute it with previous PID as only argument. If the bug is triggered, nothing will print in the python terminal window when you press Enter. To terminate the application you can press Ctrl-\ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 11:54:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jun 2012 09:54:13 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0eb63de72e96 by Hynek Schlawack in branch 'default': #14814: Remove 2.x's new-style classes syntax from ipaddress http://hg.python.org/cpython/rev/0eb63de72e96 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 12:09:45 2012 From: report at bugs.python.org (guyomes) Date: Fri, 01 Jun 2012 10:09:45 +0000 Subject: [issue14978] distutils Extension fails to be created with unicode package names Message-ID: <1338545385.38.0.440171490662.issue14978@psf.upfronthosting.co.za> New submission from guyomes : This issue appeared initially in: http://groups.google.com/group/cython-users/browse_thread/thread/f9e7018bb12a66d2 Note that this is also an issue in distutils2/compiler/extension.py, where arguments of Extension are also tested against str only. ---------- assignee: eric.araujo components: Distutils files: patch-distutils-extension_py.diff keywords: patch messages: 162067 nosy: eric.araujo, guyomes, patrick.andrew, tarek priority: normal severity: normal status: open title: distutils Extension fails to be created with unicode package names type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file25788/patch-distutils-extension_py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 13:39:53 2012 From: report at bugs.python.org (Ronan Lamy) Date: Fri, 01 Jun 2012 11:39:53 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <1338550793.84.0.186459660005.issue14938@psf.upfronthosting.co.za> Ronan Lamy added the comment: Here's a preliminary patch, without tests or documentation, implementing my approach (adding an optional is_package=False to FileLoader.__init__()). Next question (quite independent of the chosen implementation): how should this be tested? ---------- keywords: +patch Added file: http://bugs.python.org/file25789/1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 14:02:09 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 01 Jun 2012 12:02:09 +0000 Subject: [issue14976] Queue.PriorityQueue() is not interrupt safe In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za> Message-ID: <1338552129.76.0.733043514943.issue14976@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I don't think there is anything special about PriorityQueue. There is a similar concerning the use of the Python implementation of RLock in signal handlers -- see http://bugs.python.org/issue13697. Maybe the signal handler should temporarily mask or ignore SIGINT while it runs. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 14:24:37 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jun 2012 12:24:37 +0000 Subject: [issue14977] mailcap does not respect precedence in the presence of wildcards In-Reply-To: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za> Message-ID: <1338553477.25.0.453658051247.issue14977@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. It seems to me this is an edge case as far as backward compatibility goes. On the one hand it does seem like an RFC violation (ie: bug), on the other hand there could be user programs depending on the current behavior. I'm inclined toward treating it as a bug, but I can see it being argued the other way. The fact that the file is designed for interoperability and other tools do take the wildcard first argues in favor of treating it as a bug, I think. ---------- components: +email -Library (Lib) keywords: +easy nosy: +barry, r.david.murray versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 14:35:19 2012 From: report at bugs.python.org (YF) Date: Fri, 01 Jun 2012 12:35:19 +0000 Subject: [issue14975] import unicodedata, DLL load failed on Python 2.7.3 In-Reply-To: <1338504145.87.0.920765614951.issue14975@psf.upfronthosting.co.za> Message-ID: <1338554119.23.0.680967230401.issue14975@psf.upfronthosting.co.za> YF added the comment: I compared downloaded python-2.7.3.msi file, it is consistent with the website published "MD5 checksums and sizes", and this time I disabled avast 7 and then reinstall Python 2.7.3, but this error still occurs. After I installed Python 2.7.3 the MD5 signature of the C:\Python27\DLLs\unicodedata.pyd file is: AD7DFE789B1256F039406B640ACD9C0D I have not found that I had any operational errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 14:38:30 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 01 Jun 2012 12:38:30 +0000 Subject: [issue14969] Exception context is not suppressed correctly in contextlib.ExitStack.__exit__ In-Reply-To: <1338471704.64.0.423710323237.issue14969@psf.upfronthosting.co.za> Message-ID: <1338554310.92.0.48318704901.issue14969@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, you're absolutely right. Interestingly though, the old recursive implementation appeared to have the same bug, and I'd deliberately used the recursive approach precisely so that suppressed exceptions *would* get cleared correctly. I must have managed to leave a loophole somewhere :( I also realised simply overwriting the context isn't correct in all cases, and have adjusted the test cases accordingly. ---------- title: Use __suppress_context__ in contextlib.ExitStack.__exit__ -> Exception context is not suppressed correctly in contextlib.ExitStack.__exit__ type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 14:48:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jun 2012 12:48:50 +0000 Subject: [issue14969] Exception context is not suppressed correctly in contextlib.ExitStack.__exit__ In-Reply-To: <1338471704.64.0.423710323237.issue14969@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c108bc96aec6 by Nick Coghlan in branch 'default': Close #14969: Improve the handling of exception chaining in contextlib.ExitStack http://hg.python.org/cpython/rev/c108bc96aec6 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 15:03:26 2012 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 01 Jun 2012 13:03:26 +0000 Subject: [issue14979] pdb: Link to source Message-ID: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za> New submission from anatoly techtonik : http://docs.python.org/library/pdb.html#pdb.Pdb Documentation for pdb says: "The debugger is extensible ? it is actually defined as the class Pdb. This is currently undocumented but easily understood by reading the source." There should a link to the source. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 162074 nosy: docs at python, techtonik priority: normal severity: normal status: open title: pdb: Link to source _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 16:38:28 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 01 Jun 2012 14:38:28 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <1338561508.99.0.169624479311.issue14938@psf.upfronthosting.co.za> Brett Cannon added the comment: I think you misunderstood what I was suggesting as a solution: there is no conversion of module name to file name. It would simply be:: fullname.rpartition('.')[2] == os.path.splitext(os.path.split(self.path)[1])[0] for path comparison. But honestly since __init__ is the only special case here, is_package() could just do its current check and ``fullname.rpartition('.')[2] != '__init__'``. And a problem with your patch is that it is only for FileLoader, which precludes SourceLoader from getting the beneficial fix for the issue and thus leaves out all other loaders which might use an alternative storage mechanism than files (e.g. zip files). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 16:43:02 2012 From: report at bugs.python.org (=?utf-8?q?Johan_Aires_Rast=C3=A9n?=) Date: Fri, 01 Jun 2012 14:43:02 +0000 Subject: [issue14976] Queue.PriorityQueue() is not interrupt safe In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za> Message-ID: <1338561782.48.0.756428667922.issue14976@psf.upfronthosting.co.za> Johan Aires Rast?n added the comment: I did read some more on the subject and it seems like using locks with interrupts is in general a very difficult problem and not limited to Python. Don't know if this is considered common knowledge among programmers or if it would be useful with at least a warning on the signal manual page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 17:39:55 2012 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 01 Jun 2012 15:39:55 +0000 Subject: [issue14972] listcomp with nested classes In-Reply-To: <1338500454.97.0.157911114425.issue14972@psf.upfronthosting.co.za> Message-ID: <1338565195.79.0.978025848198.issue14972@psf.upfronthosting.co.za> Florent Xicluna added the comment: This is a duplicate of issue 11796. See also issue 13557: http://bugs.python.org/issue13557#msg154174 For Python 3, a list comprehension defines a block pretty much like the method definition during the class creation: class x: x = 1 def incx(): return x + 1 print(incx()) ==> raises NameError too ---------- resolution: -> duplicate status: open -> closed superseder: -> Comprehensions in a class definition mostly cannot access class variable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 17:40:56 2012 From: report at bugs.python.org (Samuel John) Date: Fri, 01 Jun 2012 15:40:56 +0000 Subject: [issue14980] ranlib: file: libpython2.7.a(pymath.o) has no symbols Message-ID: <1338565256.1.0.622493856416.issue14980@psf.upfronthosting.co.za> New submission from Samuel John : Building python on the Mac (10.7.4) with latest Xcode shows ``` [...] ranlib: file: libpython2.7.a(pymath.o) has no symbols ``` Is that okay or a bug? ---------- assignee: ronaldoussoren components: Macintosh messages: 162078 nosy: ronaldoussoren, samueljohn priority: normal severity: normal status: open title: ranlib: file: libpython2.7.a(pymath.o) has no symbols type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 17:41:57 2012 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 01 Jun 2012 15:41:57 +0000 Subject: [issue11796] Comprehensions in a class definition mostly cannot access class variable In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za> Message-ID: <1338565317.22.0.362490656425.issue11796@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +anikom15, flox, josmiley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 17:42:37 2012 From: report at bugs.python.org (Samuel John) Date: Fri, 01 Jun 2012 15:42:37 +0000 Subject: [issue14980] OSX: ranlib: file: libpython2.7.a(pymath.o) has no symbols In-Reply-To: <1338565256.1.0.622493856416.issue14980@psf.upfronthosting.co.za> Message-ID: <1338565357.9.0.36969129309.issue14980@psf.upfronthosting.co.za> Changes by Samuel John : ---------- title: ranlib: file: libpython2.7.a(pymath.o) has no symbols -> OSX: ranlib: file: libpython2.7.a(pymath.o) has no symbols _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 17:46:17 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 01 Jun 2012 15:46:17 +0000 Subject: [issue14980] OSX: ranlib: file: libpython2.7.a(pymath.o) has no symbols In-Reply-To: <1338565256.1.0.622493856416.issue14980@psf.upfronthosting.co.za> Message-ID: <1338565577.36.0.15518098557.issue14980@psf.upfronthosting.co.za> Ronald Oussoren added the comment: That's not a bug, the build prices unconditionally builds a file that contains optional definitions. On OSX none of these optional definitions are used, and hence pymath.o is empty. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:11:33 2012 From: report at bugs.python.org (Alexandre Zani) Date: Fri, 01 Jun 2012 17:11:33 +0000 Subject: [issue4849] instantiating and populating xml.dom.minidom.Element is cumbersome In-Reply-To: <1231182515.38.0.572857860756.issue4849@psf.upfronthosting.co.za> Message-ID: <1338570693.8.0.288633968317.issue4849@psf.upfronthosting.co.za> Alexandre Zani added the comment: I would tend to disagree with the use of **kwargs. It means the argument list would be implicit, not documented by the code and not checked at runtime. We could end up with anything in there. I'll try to propose a patch tonight that implements Jean-Paul's solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:20:55 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 01 Jun 2012 17:20:55 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338571255.64.0.789089102375.issue14673@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Looking great, you're almost there! I remviewed issue14673_as_simple_namespace_2.diff and issue14673_full.diff. Reitveld makes it *so* much easier :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:27:31 2012 From: report at bugs.python.org (Andreas Jung) Date: Fri, 01 Jun 2012 17:27:31 +0000 Subject: [issue14981] 3.3.0a4 compilation fails von MacOS Lion /10.7.4 Message-ID: <1338571651.03.0.551687770789.issue14981@psf.upfronthosting.co.za> New submission from Andreas Jung : ranlib: file: libpython3.3m.a(dynamic_annotations.o) has no symbols ranlib: file: libpython3.3m.a(pymath.o) has no symbols gcc -framework CoreFoundation -o python.exe Modules/python.o libpython3.3m.a -ldl -framework CoreFoundation gcc -framework CoreFoundation -o Modules/_testembed Modules/_testembed.o libpython3.3m.a -ldl -framework CoreFoundation ./python.exe -SE -m sysconfig --generate-posix-vars Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] python.exe(41191) malloc: *** mmap(size=7310873954244194304) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Could not import runpy module make: *** [Lib/_sysconfigdata.py] Segmentation fault: 11 ---------- components: Build messages: 162082 nosy: ajung priority: normal severity: normal status: open title: 3.3.0a4 compilation fails von MacOS Lion /10.7.4 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:27:37 2012 From: report at bugs.python.org (Andreas Jung) Date: Fri, 01 Jun 2012 17:27:37 +0000 Subject: [issue14981] 3.3.0a4 compilation fails von MacOS Lion /10.7.4 In-Reply-To: <1338571651.03.0.551687770789.issue14981@psf.upfronthosting.co.za> Message-ID: <1338571657.45.0.479708621673.issue14981@psf.upfronthosting.co.za> Changes by Andreas Jung : ---------- type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:29:50 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jun 2012 17:29:50 +0000 Subject: [issue14981] 3.3.0a4 compilation fails von MacOS Lion /10.7.4 In-Reply-To: <1338571651.03.0.551687770789.issue14981@psf.upfronthosting.co.za> Message-ID: <1338571790.66.0.0777657284464.issue14981@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> ronaldoussoren components: +Macintosh nosy: +ronaldoussoren versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:30:40 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jun 2012 17:30:40 +0000 Subject: [issue14981] 3.3.0a4 compilation fails von MacOS Lion /10.7.4 In-Reply-To: <1338571651.03.0.551687770789.issue14981@psf.upfronthosting.co.za> Message-ID: <1338571840.85.0.169602092144.issue14981@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: ronaldoussoren -> nobody nosy: +ned.deily, nobody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:34:03 2012 From: report at bugs.python.org (Ronan Lamy) Date: Fri, 01 Jun 2012 17:34:03 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <1338572043.69.0.663635036264.issue14938@psf.upfronthosting.co.za> Ronan Lamy added the comment: Your second solution is simple and solves the problem, so I guess that's it, then. Still, I don't really understand the purpose of SourceLoader, which makes me uneasy about the implementation of _LoaderBasics.is_package(). It seems to be meant to load an arbitrary resource yet it assumes that get_filename returns an actual file path, so I don't see how it could be used to import from a URL, for instance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:54:28 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 01 Jun 2012 17:54:28 +0000 Subject: [issue14981] 3.3.0a4 compilation fails von MacOS Lion /10.7.4 In-Reply-To: <1338571651.03.0.551687770789.issue14981@psf.upfronthosting.co.za> Message-ID: <1338573268.16.0.531512171478.issue14981@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Dupe of #13241. Apple's llvm-gcc is broken, please use clang instead (CC=clang ./configure). ---------- nosy: +hynek resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:58:23 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 17:58:23 +0000 Subject: [issue12932] filecmp.dircmp does not allow non-shallow comparisons In-Reply-To: <1315411296.33.0.213336425163.issue12932@psf.upfronthosting.co.za> Message-ID: <1338573503.67.0.578794854879.issue12932@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- stage: test needed -> needs patch title: dircmp does not allow non-shallow comparisons -> filecmp.dircmp does not allow non-shallow comparisons _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 19:59:35 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 17:59:35 +0000 Subject: [issue14918] Incorrect TypeError message for wrong function arguments In-Reply-To: <1337962864.62.0.211953440829.issue14918@psf.upfronthosting.co.za> Message-ID: <1338573575.77.0.340849096741.issue14918@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think this was fixed in 3.3, and maybe backported. Could you test with the latest releases? ---------- nosy: +benjamin.peterson, eric.araujo title: Incorrect explanation of TypeError exception -> Incorrect TypeError message for wrong function arguments versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:01:24 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 18:01:24 +0000 Subject: [issue14919] what disables one from adding self to the "nosy" list In-Reply-To: <1337964276.05.0.327308817778.issue14919@psf.upfronthosting.co.za> Message-ID: <1338573684.54.0.540882361404.issue14919@psf.upfronthosting.co.za> ?ric Araujo added the comment: I suggest just rephrasing to say something like ?if you are logged in, you can add yourself to the nosy list and submit the form (a button fills in your user name if you have JavaScript activated?. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:01:27 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 01 Jun 2012 18:01:27 +0000 Subject: [issue14981] 3.3.0a4 compilation fails von MacOS Lion /10.7.4 In-Reply-To: <1338571651.03.0.551687770789.issue14981@psf.upfronthosting.co.za> Message-ID: <1338573687.41.0.803553450522.issue14981@psf.upfronthosting.co.za> Ned Deily added the comment: This is a known issue with using Apple's llvm-gcc compiler. Make sure you've installed either the latest version of Xcode for OS X 10.7 (currently Xcode 4.3.x) and install the optional Command Line Tools component (Xcode -> Preferences -> Downloads -> Components) or download and install the latest version of the new standalone Command Line Tools package (late March) for 10.7 and then configure the build to use clang as compiler. ./configure CC=clang The defaults ./configure uses will be updated prior to beta releases of 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:02:16 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 18:02:16 +0000 Subject: [issue14926] random.seed docstring needs edit of "*a *is" In-Reply-To: <1338133291.27.0.1725405252.issue14926@psf.upfronthosting.co.za> Message-ID: <1338573736.7.0.588495324721.issue14926@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks. Have you noticed similar typos in the rest of the module, or the reST docs? ---------- nosy: +eric.araujo, sandro.tosi versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:03:51 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 18:03:51 +0000 Subject: [issue14979] pdb doc: Add link to source In-Reply-To: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za> Message-ID: <1338573831.41.0.462117817423.issue14979@psf.upfronthosting.co.za> ?ric Araujo added the comment: Sounds good to me. Raymond, do you concur? ---------- nosy: +eric.araujo, rhettinger title: pdb: Link to source -> pdb doc: Add link to source versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:04:10 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 01 Jun 2012 18:04:10 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1338573850.77.0.66376925952.issue13241@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Ned, any progress/problems? I've closed two dupes already in the last few days and we're still in the alphas. We really should get this fixed before beta1 or the tracker will be flooded. Let me know if you need something. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:04:15 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 18:04:15 +0000 Subject: [issue14973] restore python2 unicode literals in "ur" strings In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za> Message-ID: <1338573855.06.0.863513113407.issue14973@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:05:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 18:05:17 +0000 Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle docstring In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za> Message-ID: <1338573917.63.0.118705101902.issue14927@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo title: add "Do not supply int argument" to random.shuffle docstring -> add "Do not supply 'int' argument" to random.shuffle docstring _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:08:34 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 01 Jun 2012 18:08:34 +0000 Subject: [issue12354] packaging.pypi.simple docs use both client and crawler name, which might be confusing In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za> Message-ID: <1338574114.78.0.374893263632.issue12354@psf.upfronthosting.co.za> ?ric Araujo added the comment: Not yet; the commit was adding missing doc to the Crawler class, but I haven?t reviewed the use of client vs. crawler yet. Alexis, you introduced the client/crawler naming after reading some book; what do you think now? ---------- status: pending -> open title: packaging.pypi.simple docs use both client and crawler variable, which might be confusing -> packaging.pypi.simple docs use both client and crawler name, which might be confusing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:08:59 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jun 2012 18:08:59 +0000 Subject: [issue14918] Incorrect TypeError message for wrong function arguments In-Reply-To: <1337962864.62.0.211953440829.issue14918@psf.upfronthosting.co.za> Message-ID: <1338574139.16.0.000920298135579.issue14918@psf.upfronthosting.co.za> R. David Murray added the comment: It is fixed. It was not backported. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:13:56 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 01 Jun 2012 18:13:56 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1338574436.34.0.335977169722.issue13241@psf.upfronthosting.co.za> Ned Deily added the comment: Hynek: Thanks for the offer; I've got it. I'll have a comprehensive update to support the new multiple dev environments for 10.6 and beyond prior to b1 (and for 2.7.x and 3.2.x). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:21:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jun 2012 18:21:13 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 000cc4e0e1cd by Hynek Schlawack in branch 'default': #14814: Fix errror message creation in ipaddress.collapse_addresses http://hg.python.org/cpython/rev/000cc4e0e1cd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:26:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jun 2012 18:26:32 +0000 Subject: [issue14968] Section "Inplace Operators" of :mod:`operator` should be a subsection In-Reply-To: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset bf6305bce3af by Sandro Tosi in branch '3.2': Issue #14968: set 'Inplace Operators' as subsection; patch by Lars Buitinck http://hg.python.org/cpython/rev/bf6305bce3af New changeset 7c9702b08bfb by Sandro Tosi in branch 'default': Issue #14968: merge with 3.2 http://hg.python.org/cpython/rev/7c9702b08bfb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:27:57 2012 From: report at bugs.python.org (Sandro Tosi) Date: Fri, 01 Jun 2012 18:27:57 +0000 Subject: [issue14968] Section "Inplace Operators" of :mod:`operator` should be a subsection In-Reply-To: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za> Message-ID: <1338575277.3.0.872995460639.issue14968@psf.upfronthosting.co.za> Sandro Tosi added the comment: Thanks Lars for the patch! ?ric, why did you add 2.7 version? AFAISee 2.7 doesn't have the "Inplace Operators" section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:30:16 2012 From: report at bugs.python.org (Christopher Smith) Date: Fri, 01 Jun 2012 18:30:16 +0000 Subject: [issue14926] random.seed docstring needs edit of "*a *is" In-Reply-To: <1338573736.7.0.588495324721.issue14926@psf.upfronthosting.co.za> Message-ID: Christopher Smith added the comment: On Fri, Jun 1, 2012 at 11:47 PM, ?ric Araujo wrote: > > ?ric Araujo added the comment: > > Thanks. ?Have you noticed similar typos in the rest of the module, or the reST docs? I grepped for orphaned asterisks, as I recall, and didn't find any others. /c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:53:29 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Jun 2012 18:53:29 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338576809.11.0.458719947051.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: sorry, I should have been more clear. issue14673_full.diff is not simply a merging of the two previous patches, but rather their merger, plus SimpleNamespace, plus removing the "public" restriction from the repr. I may have a small tweak or two as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:55:27 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 01 Jun 2012 18:55:27 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1338576809.11.0.458719947051.issue14673@psf.upfronthosting.co.za> Message-ID: <20120601145522.686f75ba@limelight.wooz.org> Barry A. Warsaw added the comment: On Jun 01, 2012, at 06:53 PM, Eric Snow wrote: >sorry, I should have been more clear. issue14673_full.diff is not simply a >merging of the two previous patches, but rather their merger, plus >SimpleNamespace, plus removing the "public" restriction from the repr. I may >have a small tweak or two as well. Ah dang. I'd say just double check both of my sets of comments, disregard the ones that are no longer relevant and push an update for the _full.diff. I'll do one final review and/or just commit it for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 20:57:45 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 01 Jun 2012 18:57:45 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338577065.28.0.359469571017.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: I'll get a new patch up tonight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 21:48:02 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jun 2012 19:48:02 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338580082.45.0.730255658808.issue7559@psf.upfronthosting.co.za> R. David Murray added the comment: I updated the tests to Python3, and attempted to replicate the fix using the new importlib qualname support. Even if it had worked, this would not have finished the patch, since Michael wants to generate a failing test instead of raising the import error. However, I'm running into weird problems and am shelving this for the moment. The issue is that if I run the tests like this: ./python -m unittest test.test_unittest (or via regrtest) they fail with the wrong name in the error message. If I run them like this: ./python -m unittest unittest.test.test_loader.TestLoader. the right name is in the message. I suspect the bug is in the tests, but I'm not spotting it. Maybe someone else will see it. ---------- Added file: http://bugs.python.org/file25790/unittest_loader_import_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 21:56:26 2012 From: report at bugs.python.org (Michael Driscoll) Date: Fri, 01 Jun 2012 19:56:26 +0000 Subject: [issue14957] Improve docs for str.splitlines In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za> Message-ID: <1338580586.5.0.15321258184.issue14957@psf.upfronthosting.co.za> Michael Driscoll added the comment: I'm assuming Nick is talking about the stdtypes.rst (in Doc/library) file, correct? If so, I went ahead and created a simple patch that almost uses his verbiage verbatim. ---------- keywords: +patch nosy: +michael.driscoll Added file: http://bugs.python.org/file25791/stdtypes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 22:06:53 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 01 Jun 2012 20:06:53 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <1338581213.92.0.0877521863829.issue14938@psf.upfronthosting.co.za> Brett Cannon added the comment: I have yet to see anyone use a URL loader in serious code beyond people just using it as an example. What I do see is lots of custom zipfile importers and thus for the majority if people this will continue to make sense. And even with a URL loader, get_filename would return a URL who probably has something like http://example.com/pkg/__init__.py which would still work as expected. If someone chooses to break from expectations they can just overload is_package(). ---------- assignee: -> brett.cannon resolution: wont fix -> stage: -> test needed status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 22:21:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 01 Jun 2012 20:21:24 +0000 Subject: [issue14957] Improve docs for str.splitlines In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 24572015e24f by R David Murray in branch '3.2': #14957: clarify splitlines docs. http://hg.python.org/cpython/rev/24572015e24f New changeset 2a43088318ed by R David Murray in branch 'default': #14957: clarify splitlines docs. http://hg.python.org/cpython/rev/2a43088318ed New changeset 0df7594e4ebd by R David Murray in branch '2.7': #14957: clarify splitlines docs. http://hg.python.org/cpython/rev/0df7594e4ebd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 22:22:29 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jun 2012 20:22:29 +0000 Subject: [issue14957] Improve docs for str.splitlines In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za> Message-ID: <1338582149.34.0.120556170629.issue14957@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks. I added an example, too, since split has some. ---------- nosy: +r.david.murray resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 22:33:21 2012 From: report at bugs.python.org (Ronan Lamy) Date: Fri, 01 Jun 2012 20:33:21 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <1338582801.95.0.831873725159.issue14938@psf.upfronthosting.co.za> Ronan Lamy added the comment: OK, that makes sense pragmatically. Here's the patch then. I wasn't sure where to put the test, it doesn't actually have much in common with the rest of Lib/importlib/test/import_/test_packages.py but the name fits, so... ---------- Added file: http://bugs.python.org/file25792/2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 23:01:13 2012 From: report at bugs.python.org (Gavin Burnell) Date: Fri, 01 Jun 2012 21:01:13 +0000 Subject: [issue14975] import unicodedata, DLL load failed on Python 2.7.3 In-Reply-To: <1338504145.87.0.920765614951.issue14975@psf.upfronthosting.co.za> Message-ID: <1338584473.71.0.298354052427.issue14975@psf.upfronthosting.co.za> Gavin Burnell added the comment: I've had the same problem on a Win64 install of EPD 7.3 (Python 2.7.3). This was after installing over the top of a 2.7.2 install. Properly removing and re-installing from clean fixed the problem. ---------- nosy: +Gavin.Burnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 23:12:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Jun 2012 21:12:42 +0000 Subject: [issue14975] import unicodedata, DLL load failed on Python 2.7.3 In-Reply-To: <1338504145.87.0.920765614951.issue14975@psf.upfronthosting.co.za> Message-ID: <1338585162.1.0.276823154403.issue14975@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 23:14:30 2012 From: report at bugs.python.org (Michael Driscoll) Date: Fri, 01 Jun 2012 21:14:30 +0000 Subject: [issue14446] Remove deprecated tkinter functions In-Reply-To: <1333051070.39.0.337099775152.issue14446@psf.upfronthosting.co.za> Message-ID: <1338585270.11.0.752908135262.issue14446@psf.upfronthosting.co.za> Michael Driscoll added the comment: After reading up on both issues, I think I found all the instances that were deprecated and removed them. A patch is attached that includes the edits for tkinter/__init__.py and the _tkinter.c files. ---------- keywords: +patch nosy: +michael.driscoll Added file: http://bugs.python.org/file25793/tkinter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 1 23:18:47 2012 From: report at bugs.python.org (Michael Driscoll) Date: Fri, 01 Jun 2012 21:18:47 +0000 Subject: [issue14446] Remove deprecated tkinter functions In-Reply-To: <1333051070.39.0.337099775152.issue14446@psf.upfronthosting.co.za> Message-ID: <1338585527.45.0.272983441263.issue14446@psf.upfronthosting.co.za> Michael Driscoll added the comment: I just noticed that we'll need to update the Documentation for tkinter too as it mentions the AtEnd etc methods. Do you want me to create a patch for that or a new ticket + patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 01:00:34 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Fri, 01 Jun 2012 23:00:34 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a Message-ID: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> New submission from Marc Abramowitz : I noticed that pip wasn't working properly on Python 3.3a - notably, it wasn't able to load any of its own VCS modules -- it does this by using pkgutil.walk_packages I think the problem is that the behavior of pkgutil.walk_packages changed in some incompatible way in 3.3 -- take a look at the following: [last: 0] marca at scml-marca:~/dev/git-repos/lexicon$ ../lexicon/.tox/py32/bin/python Python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:25:50) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from pkgutil import walk_packages >>> list(walk_packages('/Users/marca/dev/git-repos/lexicon/.tox/py33/lib/python3.3/site-packages/pip-1.1-py3.3.egg/pip/vcs')) [(, 'lexicon', True), (, 'lexicon.alias_dict', False), (, 'lexicon.attribute_dict', False), (, 'reg_settings', False), (, 'setup', False)] >>> ^D [last: 10] marca at scml-marca:~/dev/git-repos/lexicon$ ../lexicon/.tox/py33/bin/python Python 3.3.0a3 (v3.3.0a3:0b53b70a40a0, May 1 2012, 11:39:35) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from pkgutil import walk_packages >>> list(walk_packages('/Users/marca/dev/git-repos/lexicon/.tox/py33/lib/python3.3/site-packages/pip-1.1-py3.3.egg/pip/vcs')) [] ---------- components: Library (Lib) messages: 162110 nosy: Marc.Abramowitz priority: normal severity: normal status: open title: pkgutil.walk_packages seems to not work properly on Python 3.3a versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 01:05:42 2012 From: report at bugs.python.org (Paul Nasrat) Date: Fri, 01 Jun 2012 23:05:42 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338591942.85.0.119532862273.issue14982@psf.upfronthosting.co.za> Paul Nasrat added the comment: I stepped through in pdb (Pdb) p i <_frozen_importlib.FileFinder object at 0x101066090> (Pdb) iter_importer_modules(i, prefix) [] (Pdb) p hasattr(importer, 'iter_modules') False 2.7 uses [] (Pdb) pp dir(myimp) ['__doc__', '__init__', '__module__', 'find_module', 'iter_modules', 'path'] This seems related to http://www.python.org/dev/peps/pep-0420/ ---------- nosy: +pnasrat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 02:03:08 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 00:03:08 +0000 Subject: [issue14446] Remove deprecated tkinter functions In-Reply-To: <1333051070.39.0.337099775152.issue14446@psf.upfronthosting.co.za> Message-ID: <1338595388.85.0.707819873247.issue14446@psf.upfronthosting.co.za> R. David Murray added the comment: The doc changes should be part of the patch. I forget, though, if we completely delete deprecated stuff from the docs or if we keep a deprecation stub in place. Note that it is possible (although in this case probably not too likely) that the code will drift before 3.4 and the patch need to be regenerated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 02:33:13 2012 From: report at bugs.python.org (lesha) Date: Sat, 02 Jun 2012 00:33:13 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338597193.28.0.498292934726.issue6721@psf.upfronthosting.co.za> lesha added the comment: I feel like I'm failing to get my thesis across. I'll write it out fully: == Thesis start == Basic fact: It is an error to use threading locks in _any_ way after a fork. I think we mostly agree on this. The programs we discussing are **inherently buggy**. We disagree on the right action when such a bug happens. I see 3 possibilities: 1) deadlock (the current behavior, if the lock was held in the parent at the time of fork) 2) continue to execute: a) as if nothing happened (the current behavior, if the lock was not held in the parent) b) throw an Exception (equivalent to a, see below) 3) crash hard. I think both 1 and 3 are tolerable, while 2 is **completely unsafe** because the resulting behavior of the program is unexpected and unpredictable (data corruption, deletion, random actions, etc). == Thesis end == I will now address Gregory's, Richard's, and Vinay's comments in view of this thesis: 1) Gregory suggests throwing an exception when the locks are used in a child. He also discusses some cases, in which he believes one could safely continue execution. My responses: a) Throwing an exception is tatamount to continuing execution. Imagine that the parent has a tempfile RAII object that erases the file after the object disappears, or in some exception handler. The destructor / handler will now get called in the child... and the parent's tempfile is gone. Good luck tracking that one down. b) In general, is not safe to continue execution on release(). If you release() and reinitialize, the lock could still later be reused by both parent and child, and there would still be contention leading to data corruption. c) Re: deadlocks are unacceptable... A deadlock is better than data corruption. Whether you prefer a deadlock or a crash depends on whether your system is set up to dump core. You can always debug a deadlock with gdb. A crash without a core dump is impossible to diagnose. However, a crash is harder to ignore, and it lets the process recover. So, in my book, though I'm not 100% certain: hard crash > deadlock > corruption d) However, we can certainly do better than today: i) Right now, we sometimes deadlock, and sometimes continue execution. It would be better to deadlock always (or crash always), no matter how the child uses the lock. ii) We can log before deadlocking (this is hard in general, because it's unclear where to log to), but it would immensely speed up debugging. iii) We can hard-crash with an extra-verbose stack dump (i.e. dump the lock details in addition to the stack) 2) Richard explains how my buggy snippets are buggy, and how to fix them. I respond: Richard, thanks for explaining how to avoid these bugs! Nonetheless, people make bugs all the time, especially in areas like this. I made these bugs. I now know better, mostly, but I wouldn't bet on it. We should choose the safest way to handle these bugs: deadlocking always, or crashing always. Reinitializing the locks is going to cost Python users a lot more in the long run. Deadlocking _sometimes_, as we do now, is equally bad. Also, even your code is potentially unsafe: when you execute the excepthook in the child, you could be running custom exception logic, or even a custom excepthook. Those could well-intentionedly, but stupidly, destroy some of the parent's valuable data. 3) Vinay essentially says "using logging after fork is user error". I respond: Yes, it is. In any other logging library, this error would only result in mangled log lines, but no lasting harm. In Python, you sometimes get a deadlock, and other times, mangled lines. > logging is not doing anything to protect things *outside* of a single process A file is very much outside a single process. If you are logging to a file, the only correct way is to use a file lock. Thus, I stand by my assertion that "logging" is buggy. Windows programs generally have no problems with this. fork() on UNIX gives you both the rope and the gallows to hang yourself. Specifically for logging, I think reasonable options include: a) [The Right Way (TM)] Using a file lock + CLOEXEC when available; this lets multiple processes cooperate safely. b) It's okay to deadlock & log with an explanation of why the deadlock is happening. c) It's okay to crash with a similar explanation. d) It's pretty okay even to reinitialize logs, although mangled log lines do prevent automated parsing. I really hope that my compact thesis can help us get closer to a consensus, instead of arguing about the details of specific bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 02:42:00 2012 From: report at bugs.python.org (lesha) Date: Sat, 02 Jun 2012 00:42:00 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338597720.88.0.000987280153686.issue6721@psf.upfronthosting.co.za> lesha added the comment: A slightly more ambitious solution than crashing / deadlocking always is to have Python automatically spawn a "fork server" whenever you start using threads. Then, you would be able to have "subprocess" work cleanly, and not worry about any of this stuff. I don't know if we want to take the perf hit on "import threading" though... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 02:55:00 2012 From: report at bugs.python.org (lesha) Date: Sat, 02 Jun 2012 00:55:00 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338598500.48.0.72922422319.issue6721@psf.upfronthosting.co.za> lesha added the comment: Actually, we might be able to automatically spawn a safe fork server _only_ when people start mixing threading and subprocess. I'm not totally sure if this would allow us to salvage multiprocessing as well... The tricky bit is that we'd need to proxy into the fork server all the calls having to do with file descriptors / sockets that we would want to pass into the child processes. That suggests to me that it'll be really hard to do this in a backwards-compatible way. Given that subprocess is a pretty broken library, this might be a good time to replace it anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 03:11:48 2012 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 02 Jun 2012 01:11:48 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338599508.63.0.627574225486.issue14982@psf.upfronthosting.co.za> Eric V. Smith added the comment: I don't think this is related to PEP 420. Adding Brett. ---------- nosy: +brett.cannon, eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 03:26:01 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 02 Jun 2012 01:26:01 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338600361.04.0.572419442292.issue14982@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 04:15:43 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 02 Jun 2012 02:15:43 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338603343.33.0.591196332157.issue6721@psf.upfronthosting.co.za> Gregory P. Smith added the comment: subprocess has nothing to do with this bug. subprocess is safe as of Python 3.2 (and the subprocess32 backport for 2.x). Its preexec_fn argument is already documented as an unsafe legacy. If you want to replace subprocess, go ahead, write something new and post it on pypi. That is out of the scope of this issue. Look at the original message I opened this bug with. I *only* want to make the standard library use of locks not be a source of deadlocks as it is unacceptable for a standard library itself to force your code to adopt a threads only or a fork only programming style. How we do that is irrelevant; I merely started the discussion with one suggestion. Third party libraries are always free to hang their users however they see fit. If you want to "log" something before deadlocking, writing directly to the stderr file descriptor is the best that can be done. That is what exceptions that escape __del__ destructors do. logging, http.cookiejar, _strptime - all use locks that could be dealt with in a sane manner to avoid deadlocks after forking. Queue, concurrent.futures & threading.Condition - may not make sense to fix as these are pretty threading specific as is and should just carry the "don't fork" caveats in their documentation. (My *real* preference would be to remove os.fork() from the standard library. Not going to happen.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 04:17:10 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Jun 2012 02:17:10 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338603430.7.0.558518762958.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: Applied all but one of the recommended changes. Thanks, Barry! ---------- Added file: http://bugs.python.org/file25794/issue14673_full_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 04:18:04 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Jun 2012 02:18:04 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338603484.55.0.556663231392.issue14673@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file25794/issue14673_full_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 04:19:10 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Jun 2012 02:19:10 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338603550.77.0.706440784728.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: this time against TIP. ---------- Added file: http://bugs.python.org/file25795/issue14673_full_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 04:57:02 2012 From: report at bugs.python.org (lesha) Date: Sat, 02 Jun 2012 02:57:02 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338605822.86.0.24201327575.issue6721@psf.upfronthosting.co.za> lesha added the comment: 1) I'm totally in favor of making the standard library safe. For that purpose, I think we should do a combination of: a) Use file locks in logging, whenever possible. b) Introduce LockUnsafelyReinitializedAtFork, using a generation counter, or whatever else, which can be used by the few places in the standard library that can safely deal with lock reinitialization. 2) http://docs.python.org/library/subprocess.html#module-subprocess does not actually document that preexec_fn is unsafe and in need of deprecation. New users will continue to shoot themselves in the foot. 3) I think that in addition to making the standard library safe, all other locks need to be made sane (crash or deadlock), so that we at least always avoid the option "2) continue to execute the child despite it relying on an unsafe lock". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 06:34:20 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Sat, 02 Jun 2012 04:34:20 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338611660.37.0.677023724551.issue14982@psf.upfronthosting.co.za> Marc Abramowitz added the comment: Here's the pip issue: https://github.com/pypa/pip/issues/556 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 06:56:41 2012 From: report at bugs.python.org (Paul Nasrat) Date: Sat, 02 Jun 2012 04:56:41 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338613001.03.0.601632768462.issue14982@psf.upfronthosting.co.za> Paul Nasrat added the comment: I was pretty tired when debugging last night and just quickly looked at hg logs, so that may be misattributed. I'll try come up with a clearer reproducer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 07:00:47 2012 From: report at bugs.python.org (Alexandre Zani) Date: Sat, 02 Jun 2012 05:00:47 +0000 Subject: [issue4849] instantiating and populating xml.dom.minidom.Element is cumbersome In-Reply-To: <1231182515.38.0.572857860756.issue4849@psf.upfronthosting.co.za> Message-ID: <1338613247.1.0.0756391151135.issue4849@psf.upfronthosting.co.za> Alexandre Zani added the comment: Here is my patch for it. ---------- keywords: +patch Added file: http://bugs.python.org/file25796/easier_element_init.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 07:04:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 02 Jun 2012 05:04:28 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1338613468.41.0.472386474896.issue14965@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 08:35:49 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Sat, 02 Jun 2012 06:35:49 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338618949.45.0.0757746264987.issue14982@psf.upfronthosting.co.za> Marc Abramowitz added the comment: [last: 0] marca at scml-marca:~/dev/git-repos/pip$ python3.3 Python 3.3.0a4 (v3.3.0a4:7c51388a3aa7, May 30 2012, 16:58:42) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from pip import vcs >>> from pkgutil import walk_packages, iter_modules >>> print(list(iter_modules(path=vcs.__path__, prefix=vcs.__name__+'.'))) [] >>> print(list(iter_modules(path=vcs.__path__))) [] >>> import pip.vcs.git >>> pip.vcs.git >>> import pip.vcs.mercurial >>> pip.vcs.mercurial >>> print(list(iter_modules(path=vcs.__path__, prefix=vcs.__name__+'.'))) [] >>> print(list(iter_modules(path=vcs.__path__))) [] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 08:49:19 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Jun 2012 06:49:19 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338619759.37.0.738916038616.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: I've ironed out all 3 of my new tests that were still failing. ---------- Added file: http://bugs.python.org/file25797/issue14673_full_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 08:52:22 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Sat, 02 Jun 2012 06:52:22 +0000 Subject: [issue14983] [patch] email.generator should always add newlines after closing boundaries Message-ID: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> New submission from Dmitry Shachnev : Trying to write a email-sending script with PGP-signing functionality, I stumbled upon a problem (see [1]): it was impossible to sign mutlipart emails (actually the signing was performed, but the verifying programs thought that the signature is bad). After comparing messages produced by email.generator and popular mail clients (Evolution, KMail), I've found out that the mail clients always add line breaks after ending boundaries. The attached patch makes email.generator behave like all email clients. After applying it, it's possible to sign even complicated mails like "multipart/alternate with attachments". An illustration: --====1== # Part 1 (base message) begin ... --====2== # Part 1.1 begin ... --====2== # Part 1.2 begin ... --====2==-- # Part 1 end # There should be empty line here --====1== # Part 2 (signature) begin ... --====1==-- # End of the message [1]: http://stackoverflow.com/questions/10496902/pgp-signing-multipart-e-mails-with-python ---------- components: email files: always_add_newlines.patch keywords: patch messages: 162126 nosy: barry, mitya57, r.david.murray priority: normal severity: normal status: open title: [patch] email.generator should always add newlines after closing boundaries type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25798/always_add_newlines.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 10:03:30 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 02 Jun 2012 08:03:30 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338624210.3.0.500930407658.issue14673@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Some remarks: - From the docs, I could not understand the difference between sys.implementation.version and sys.version_info. When can they differ? - _PyNamespace_New should be a public API function. From Python code, SimpleNamespace is public. - I agree that _PyNamespace_Type could stay private (it's an implementation detail), in this case PyAPI_DATA is not necessary. - SimpleNamespace should support weak references. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 10:32:53 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 02 Jun 2012 08:32:53 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1338625973.28.0.3126152926.issue14591@psf.upfronthosting.co.za> Mark Dickinson added the comment: Responding to a comment from Serhiy on Rietveld: > Modules/_randommodule.c:442: mt[0] = 0x80000000UL; > mt[0] |= 0x80000000UL (according to the comment)? The = 0x80000000UL was intentional. The low-order 31 bits of mt[0] don't form part of the state of the Mersenne Twister: the resulting random stream isn't affected by their values. So all we have to do is make sure that bit 31 is set. It's the same code that's used in init_by_array earlier in _randommodule.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 10:59:29 2012 From: report at bugs.python.org (alon horev) Date: Sat, 02 Jun 2012 08:59:29 +0000 Subject: [issue14963] Use an iterative implementation for contextlib.ExitStack.__exit__ In-Reply-To: <1338376067.22.0.0825835075506.issue14963@psf.upfronthosting.co.za> Message-ID: <1338627569.9.0.201066194806.issue14963@psf.upfronthosting.co.za> alon horev added the comment: after #14969 has closed, can this be closed? any more action items? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 11:21:27 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 02 Jun 2012 09:21:27 +0000 Subject: [issue14963] Use an iterative implementation for contextlib.ExitStack.__exit__ In-Reply-To: <1338376067.22.0.0825835075506.issue14963@psf.upfronthosting.co.za> Message-ID: <1338628887.04.0.950512937943.issue14963@psf.upfronthosting.co.za> Nick Coghlan added the comment: It *was* closed - I inadvertently reopened it with my comment. Fixed :) ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 12:11:01 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Sat, 02 Jun 2012 10:11:01 +0000 Subject: [issue14380] MIMEText should default to utf8 charset if input text contains non-ASCII In-Reply-To: <1332351288.3.0.0981603454883.issue14380@psf.upfronthosting.co.za> Message-ID: <1338631861.21.0.842007416767.issue14380@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: Maybe it'll be better to use 'latin-1' charset for latin-1 texts? Something like this: if _charset == 'us-ascii': try: _text.encode(_charset) except UnicodeEncodeError: try: _text.encode('latin-1') except UnicodeEncodeError: _charset = 'utf-8' else: _charset = 'latin-1' This will make messages in most latin languages use quoted-printable encoding. ---------- components: +email -Library (Lib) nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 14:53:41 2012 From: report at bugs.python.org (bruno Piguet) Date: Sat, 02 Jun 2012 12:53:41 +0000 Subject: [issue14984] netrc module alows read of non-secured .netrc file Message-ID: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za> New submission from bruno Piguet : Most FTP clients require that the .netrc file be owned by the user and readable/writable by nobody other than the user (ie. permissions set to 0400 or 0600). The netrc module doesn't do this kind of checking, allowing the use a .netrc file written or modified by somebody else. ---------- messages: 162132 nosy: bruno.Piguet priority: normal severity: normal status: open title: netrc module alows read of non-secured .netrc file versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 14:54:19 2012 From: report at bugs.python.org (bruno Piguet) Date: Sat, 02 Jun 2012 12:54:19 +0000 Subject: [issue14984] netrc module allows read of non-secured .netrc file In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za> Message-ID: <1338641659.7.0.647972500972.issue14984@psf.upfronthosting.co.za> Changes by bruno Piguet : ---------- title: netrc module alows read of non-secured .netrc file -> netrc module allows read of non-secured .netrc file _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 15:06:53 2012 From: report at bugs.python.org (Adrian Bastholm) Date: Sat, 02 Jun 2012 13:06:53 +0000 Subject: [issue14985] os.path.isfile and os.path.isdir inconsistent on OSX Lion Message-ID: <1338642413.05.0.366116403314.issue14985@psf.upfronthosting.co.za> New submission from Adrian Bastholm : os.path.isfile doesn't reckognize a .picasa.ini file as a file and os.path.isdir doesn't reckognize a directory as a directory code: def traverse (targetDir): currentDir = targetDir dirs = os.listdir(targetDir) # dirs = [x for x in os.listdir('.') if x.endswith('.JPG')] for entry in dirs: if os.path.isdir(entry): print("Traversing " + entry) traverse(entry) else: print("Not dir: " + entry) if os.path.isfile(entry): print("Processing " + " " + currentDir + " " + entry) else: print("Not file: " + entry) print("\n") return True The test directory contains jpg files and a folder with some other jpgs and a subfolder containing jpgs ---------- assignee: ronaldoussoren components: Macintosh messages: 162133 nosy: javahaxxor, ronaldoussoren priority: normal severity: normal status: open title: os.path.isfile and os.path.isdir inconsistent on OSX Lion type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 15:18:24 2012 From: report at bugs.python.org (Adrian Bastholm) Date: Sat, 02 Jun 2012 13:18:24 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX Message-ID: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> New submission from Adrian Bastholm : print(listentry) fails on folder name with swedish (latin1) characters Error: File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/encodings/mac_roman.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_table)[0] UnicodeEncodeError: 'charmap' codec can't encode character '\u030a' in position 33: character maps to ---------- assignee: ronaldoussoren components: Macintosh messages: 162134 nosy: javahaxxor, ronaldoussoren priority: normal severity: normal status: open title: print() fails on latin1 characters on OSX versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 15:38:42 2012 From: report at bugs.python.org (=?utf-8?b?VG9tYcW+IMWgb2xj?=) Date: Sat, 02 Jun 2012 13:38:42 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338644322.68.0.664619632674.issue6721@psf.upfronthosting.co.za> Changes by Toma? ?olc : ---------- nosy: -avian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 16:12:27 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 14:12:27 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338646347.14.0.734783185495.issue14986@psf.upfronthosting.co.za> R. David Murray added the comment: A mac expert can confirm, but I think that just means that the default mac_roman encoding (which is made the default by the OS, if I understand correctly) can't handle that character. I believe it will work if you use utf-8. And no, I don't know how to do that, not be being a Mac person. ---------- assignee: ronaldoussoren -> nosy: +hynek, ned.deily, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 16:48:24 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 14:48:24 +0000 Subject: [issue14983] [patch] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338648504.27.0.339148012527.issue14983@psf.upfronthosting.co.za> R. David Murray added the comment: Then either the signer or the verifier (or both) are broken per RFC 2046 (unless there has been an update that isn't referenced from the RFC). Section http://tools.ietf.org/html/rfc2046#section-5.1.1 clearly indicates that the ending delimiter ends at the trailing --. In particular, *transports* are allowed to add whitespace before the trailing CRLF, and receivers are to handle this case. You might want to report bugs about that to the appropriate projects. That said, there seems to be little harm in adding a CRLF, and some argument in its favor, since the RFC also says that the CRLF before the next boundary is conceptually part of it, and by that interpretation a CRLF could be considered missing (though I think technically it isn't...the reason for the rule is to disambiguate preceding *body* parts that end or don't end in a CRLF, and here we are dealing with an unambiguous ending boundary delimiter). We'll need some tests for this. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 16:48:38 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 14:48:38 +0000 Subject: [issue14983] [patch] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338648518.18.0.819855265094.issue14983@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 16:49:29 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 02 Jun 2012 14:49:29 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338648569.46.0.739251818663.issue6721@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Use file locks in logging, whenever possible. Logging doesn't just log to files, and moreover, also has locks to serialise access to internal data structures (nothing to do with files). Hence, using file locks in logging is not going to magically solve problems caused in threading+forking scenarios. Apart from logging a commonly used part of the stdlib library which uses locks, I don't think this issue is to do with logging, specifically; logging uses locks in an unexceptional, conventional way, much as any other code might. Whatever solution is come up with for this thorny issue, it needs to be generic, in my view; otherwise we might just be papering over the cracks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 16:55:54 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 14:55:54 +0000 Subject: [issue14983] [patch] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338648954.02.0.365681429445.issue14983@psf.upfronthosting.co.za> R. David Murray added the comment: Looking at your stackoverflow post, you might be able to fix this by doing an rstrip on the string body before signing it. But then if we add a CRLF between the boundaries, the verifiers might start failing again. What do you think? Probably adding the CRLF is the way to go, but I wonder, what are the controlling RFCs for signing/verifying and what do they say? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 16:56:33 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 14:56:33 +0000 Subject: [issue14983] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338648993.88.0.23487315976.issue14983@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: [patch] email.generator should always add newlines after closing boundaries -> email.generator should always add newlines after closing boundaries _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 16:59:49 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 14:59:49 +0000 Subject: [issue14380] MIMEText should default to utf8 charset if input text contains non-ASCII In-Reply-To: <1332351288.3.0.0981603454883.issue14380@psf.upfronthosting.co.za> Message-ID: <1338649189.86.0.647042099199.issue14380@psf.upfronthosting.co.za> R. David Murray added the comment: I do plan to add something like that at some point. You could open a new issue for it if you like, and propose a formal patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 17:17:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jun 2012 15:17:49 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset facdca62aa68 by Sandro Tosi in branch 'default': Issue #14814: minor spelling fixes http://hg.python.org/cpython/rev/facdca62aa68 New changeset 4b4044292d09 by Sandro Tosi in branch 'default': Issue #14814: use print() function http://hg.python.org/cpython/rev/4b4044292d09 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 17:21:25 2012 From: report at bugs.python.org (Michael Driscoll) Date: Sat, 02 Jun 2012 15:21:25 +0000 Subject: [issue14446] Remove deprecated tkinter functions In-Reply-To: <1333051070.39.0.337099775152.issue14446@psf.upfronthosting.co.za> Message-ID: <1338650485.66.0.992346702131.issue14446@psf.upfronthosting.co.za> Michael Driscoll added the comment: Here's the doc patch. The local repo I was using yesterday is on a different computer that I don't have access to today. Hopefully applying two patches is okay. If not, I can redo the other patch and add it to this one. ---------- Added file: http://bugs.python.org/file25799/tkinter_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 17:21:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jun 2012 15:21:49 +0000 Subject: [issue14957] Improve docs for str.splitlines In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4d9b3a58e208 by R David Murray in branch '3.2': #14957: fix doc typo. http://hg.python.org/cpython/rev/4d9b3a58e208 New changeset 3bb35ad5d9da by R David Murray in branch 'default': #14957: fix doc typo. http://hg.python.org/cpython/rev/3bb35ad5d9da New changeset 48564362b687 by R David Murray in branch '2.7': #14957: fix doc typo. http://hg.python.org/cpython/rev/48564362b687 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 17:28:16 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 02 Jun 2012 15:28:16 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338650896.49.0.422725560282.issue14986@psf.upfronthosting.co.za> Hynek Schlawack added the comment: '\u030a' can?t be latin1 as 0x030a = 778 which is waaay beyond 255. :) That's gonna be utf-8 and indeed that maps to " ?". My best guess is that your LC_CTYPE is set to Mac Roman. You can check it using "import os;os.environ.get('LC_CTYPE')". Try running python as "LC_CTYPE=sv_SE.UTF-8 python3" and do a "print('\u030a')" to try if it helps. Otherwise a more complete (but minimal) example demonstrating the problem would be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 17:53:51 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sat, 02 Jun 2012 15:53:51 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1338652431.11.0.877844280501.issue14814@psf.upfronthosting.co.za> Sandro Tosi added the comment: Attached is a draft of the module documentation. I didn't commit yet cause we might want to rework it deeply. Else we can just commit the patch and let the comments coming as additional diffs. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 17:54:11 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sat, 02 Jun 2012 15:54:11 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1338652451.57.0.0474584241588.issue14814@psf.upfronthosting.co.za> Sandro Tosi added the comment: and the patch... ---------- Added file: http://bugs.python.org/file25800/ipaddress_module_doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 18:01:08 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 02 Jun 2012 16:01:08 +0000 Subject: [issue14985] os.path.isfile and os.path.isdir inconsistent on OSX Lion In-Reply-To: <1338642413.05.0.366116403314.issue14985@psf.upfronthosting.co.za> Message-ID: <1338652868.6.0.918352108319.issue14985@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I think your problem is a different one: os.listdir() doesn't return full paths and os.path.isfile()/isdir() return False if the supplied path doesn't exist. For example if you have this directory structure: foo/ foo/bar/ foo/bar/baz Calling os.listdir('foo') will return ["bar"]. Calling os.isdir('bar') will return False because it can't find the file. Have a look at os.walk() which was written with your use case in mind. ---------- nosy: +hynek resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 18:27:16 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 02 Jun 2012 16:27:16 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1338654436.31.0.196380378851.issue14814@psf.upfronthosting.co.za> Hynek Schlawack added the comment: As discussed on IRC, please: - add a link to the tutorial - add some typical use cases to the header of the api - change the name of the tutorial from "Howto" to "HOWTO" or a more descriptive title that doesn't contain the word how to at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 18:33:15 2012 From: report at bugs.python.org (Ronan Lamy) Date: Sat, 02 Jun 2012 16:33:15 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338654795.44.0.833783592705.issue14982@psf.upfronthosting.co.za> Changes by Ronan Lamy : ---------- nosy: +Ronan.Lamy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 18:50:59 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Sat, 02 Jun 2012 16:50:59 +0000 Subject: [issue14983] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338655859.58.0.607801570449.issue14983@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: > Looking at your stackoverflow post, you might be able to fix this by doing an rstrip on the string body before signing it. My body doesn't end with \n, so that doesn't help. If you suggest me any (easy) way to fix this on the level of my script, I will be happy. > Probably adding the CRLF is the way to go, but I wonder, what are the controlling RFCs for signing/verifying and what do they say? The standard is RFC 1847, it doesn't say anything about multipart emails. I've just looked at what other mail clients do, it works, but I can't say anything about its correctness. Also, looking at some multipart signed emails in my inbox, they *all* have the blank line before the signature part. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 18:55:26 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 16:55:26 +0000 Subject: [issue14983] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338656126.36.0.116436982071.issue14983@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I wasn't clear. By 'body' I actually meant the multipart part you are signing. I haven't looked at your script really, but I was thinking of something along the lines of make_sig(str(fullmsg.get_payload(0)).rstrip()). But like I said I didn't actually look at your script, so that may not be applicable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:05:47 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Jun 2012 17:05:47 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338656747.3.0.923744279028.issue14986@psf.upfronthosting.co.za> Ned Deily added the comment: mac_roman is an obsolete encoding from Mac OS 9 days; it is seldom seen on modern OS X systems. But it is often the fallback encoding set in ~/.CFUserTextEncoding if the LANG or a LC_* environment variable is not set (see, for example, http://superuser.com/questions/82123/mac-whats-cfusertextencoding-for). If you run a terminal session using Terminal.app, the LANG environment variable is usually set for you to an appropriate modern value, like 'en_US.UTF-8' in the US locale; this is controlled by a Terminal.app preference; other terminal apps like iTerm2 have something similar. But if you are using xterm with X11, xterm does not inject a LANG env variable. So, something like: python3.2 -c 'print("\u030a")' may fail running under xterm with UnicodeEncodeError but will print the expected character when run under Terminal.app. I avoid those kinds of issues by explicitly setting LANG in my shell profile. Let us know if that helps or, if not, how to reproduce your issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:24:28 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Sat, 02 Jun 2012 17:24:28 +0000 Subject: [issue14983] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338657868.1.0.102059931818.issue14983@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: > By 'body' I actually meant the multipart part you are signing. Yes, I've understood you, and I mean the same :) The signature is created against the not-ending-with-newline string, in any case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:29:01 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 02 Jun 2012 17:29:01 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <1338658141.37.0.66487475613.issue14938@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Ronan! The fix seems fine and I will have a more thorough look at the test later and figure out where it should go (probably only going to worry about testing is_package() directly since that was the semantic disconnect). I will also update the docs when I commit the patch. And as a matter of procedure, Ronan, can you submit a contributor agreement? http://python.org/psf/contrib/ ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:40:12 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 02 Jun 2012 17:40:12 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338658812.91.0.873504271911.issue14982@psf.upfronthosting.co.za> Brett Cannon added the comment: Basically pkgutil kind of handles importers properly, kind of doesn't. So if a module defined a __loader__ it will use it, but all the rest of its code assumes it uses only the loaders defined in pkgutil. The problem here is that pkgutil.walk_packages() ends up calling iter_importer_modules() which only returns anything of consequence if the loader has iter_modules() defined which is a non-standard API requirement that only pkgutil loaders has implemented. Basically the docs for pkgutil were incorrect in not specifying that the walk only works for loaders that define iter_modules(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:40:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jun 2012 17:40:44 +0000 Subject: [issue14926] random.seed docstring needs edit of "*a *is" In-Reply-To: <1338133291.27.0.1725405252.issue14926@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e2739145657d by Sandro Tosi in branch '3.2': Issue #14926: fix docstring highlight http://hg.python.org/cpython/rev/e2739145657d New changeset 29148c027986 by Sandro Tosi in branch 'default': Issue #14926: merge with 3.2 http://hg.python.org/cpython/rev/29148c027986 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:41:08 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sat, 02 Jun 2012 17:41:08 +0000 Subject: [issue14926] random.seed docstring needs edit of "*a *is" In-Reply-To: <1338133291.27.0.1725405252.issue14926@psf.upfronthosting.co.za> Message-ID: <1338658868.88.0.694672844967.issue14926@psf.upfronthosting.co.za> Sandro Tosi added the comment: Thanks Christopher! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:41:43 2012 From: report at bugs.python.org (Adrian Bastholm) Date: Sat, 02 Jun 2012 17:41:43 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338658903.49.0.860147849893.issue14986@psf.upfronthosting.co.za> Adrian Bastholm added the comment: The char in question: '?'. It is a folder with this character in the name. My encoding is UTF-8. Running print("\u030a") gives a blank line U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE General Character Properties In Unicode since: 1.1 Unicode category: Letter, Uppercase Canonical decomposition: U+0041 LATIN CAPITAL LETTER A + U+030A COMBINING RING ABOVE Various Useful Representations UTF-8: 0xC3 0x85 UTF-16: 0x00C5 C octal escaped UTF-8: \303\205 XML decimal entity: Å Annotations and Cross References See also: ? U+212B ANGSTROM SIGN Equivalents: ? U+0041 LATIN CAPITAL LETTER A U+030A COMBINING RING ABOVE The code: def traverse (targetDir): currentDir = targetDir dirs = os.listdir(targetDir) for entry in dirs: if os.path.isdir(entry): print("Traversing " + entry) traverse(entry) else: print("Not dir: " + entry) if os.path.isfile(entry): print("Processing " + " " + currentDir + " " + entry) else: print("Not file: " + entry) print("\n") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:43:59 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 02 Jun 2012 17:43:59 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1338659039.37.0.39909581332.issue1521950@psf.upfronthosting.co.za> Vinay Sajip added the comment: I've updated the patch following comments by RDM - it probably could do with a code review (now that I've addressed RDM's comments on the docs). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:52:16 2012 From: report at bugs.python.org (Adrian Bastholm) Date: Sat, 02 Jun 2012 17:52:16 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338659536.54.0.344543106449.issue14986@psf.upfronthosting.co.za> Adrian Bastholm added the comment: The last post is the CAPITAL ?. The following is the small letter "?" U+00E5 LATIN SMALL LETTER A WITH RING ABOVE General Character Properties In Unicode since: 1.1 Unicode category: Letter, Lowercase Canonical decomposition: U+0061 LATIN SMALL LETTER A + U+030A COMBINING RING ABOVE Various Useful Representations UTF-8: 0xC3 0xA5 UTF-16: 0x00E5 C octal escaped UTF-8: \303\245 XML decimal entity: å Annotations and Cross References Notes: ? Danish, Norwegian, Swedish, Walloon Equivalents: ? U+0061 LATIN SMALL LETTER A U+030A COMBINING RING ABOVE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 19:56:34 2012 From: report at bugs.python.org (Jon Oberheide) Date: Sat, 02 Jun 2012 17:56:34 +0000 Subject: [issue14955] hmac.secure_compare() is not time-independent for unicode strings In-Reply-To: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> Message-ID: <1338659794.6.0.874595067883.issue14955@psf.upfronthosting.co.za> Jon Oberheide added the comment: Thanks for the feedback, haypo. I've updated the patch to use unicode-internal. As long as the encode() of the expected non-attacker-controlled digest is not dependent on the actual contents of the digest, we should be good. ---------- Added file: http://bugs.python.org/file25801/secure-compare-fix-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 20:06:21 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 02 Jun 2012 18:06:21 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1338660381.39.0.957335889921.issue6721@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Lesha, the problems about "magical" __del__ methods you are worried about actually have nothing to do with threading and locks. Even in a single threaded program using fork, exactly the same issues of potential corruption would be present because the object might be finalized at the same in multiple processes. The idea that protecting the object with a thread lock will help you is seriously misguided UNLESS you also make sure you acquire them all before the fork -- and then you need to worry about the order in which you acquire all these locks. There are much easier and more direct ways to deal with the issue than wrapping all objects with locks and trying to acquire them all before forking. You could of course use multiprocessing.Lock() if you want a lock shared between processes. But even then, depending on what the __del__ method does, it is likely that you will not want the object to be finalized in both processes. However, the suggestion that locked-before-fork-locks should by default raise an error is reasonable enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 20:13:29 2012 From: report at bugs.python.org (Adrian Bastholm) Date: Sat, 02 Jun 2012 18:13:29 +0000 Subject: [issue14985] os.path.isfile and os.path.isdir inconsistent on OSX Lion In-Reply-To: <1338642413.05.0.366116403314.issue14985@psf.upfronthosting.co.za> Message-ID: <1338660809.5.0.742630608034.issue14985@psf.upfronthosting.co.za> Adrian Bastholm added the comment: You're right, my code was shite. Strange though it seemed to work on some files. The following updated version does everything as intended with the help of os.path.join: def traverse (targetDir): currentDir = targetDir dirs = os.listdir(targetDir) for entry in dirs: if os.path.isdir(os.path.join(currentDir,entry)): print("Traversing " + os.path.join(targetDir,entry)) traverse(os.path.join(targetDir,entry)) else: if os.path.isfile(os.path.join(targetDir,entry)): print("Processing" + " " + os.path.join(currentDir,entry)) else: print("Not file: " + entry) print("\n") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 20:42:44 2012 From: report at bugs.python.org (Daniel Swanson) Date: Sat, 02 Jun 2012 18:42:44 +0000 Subject: [issue14901] Python Windows FAQ is Very Outdated In-Reply-To: <1337873167.77.0.855144378298.issue14901@psf.upfronthosting.co.za> Message-ID: <1338662564.02.0.558823318101.issue14901@psf.upfronthosting.co.za> Daniel Swanson added the comment: >>> 1a) Update all Windows references to Windows 7 or Vista/7. We can include XP, but I think Microsoft is dropping support next year. According to wikipedia Windows XP is the second most popular operating system, probably better not to drop it all together. http://en.wikipedia.org/wiki/Usage_share_of_operating_systems Of course there are people who have 5 or 6 computers and use the same windows disk on all of them which might skew the data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 20:47:40 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 18:47:40 +0000 Subject: [issue14983] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338662860.62.0.254767252683.issue14983@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. So that means the verifiers are not paying attention to the MIME RFC? That's unfortunate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 20:58:58 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Jun 2012 18:58:58 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338663538.28.0.586523607651.issue14986@psf.upfronthosting.co.za> Ned Deily added the comment: The character in question is not the problem and the code snippet you provide looks fine. The problem is almost certainly that you are running the code in an execution environment where the LANG environment variable is either not set or is set to an encoding that doesn't support higher-order Unicode characters. The fallback 'mac_roman' is such an encoding. The default encodings used by the Python 3 interpreter are influenced by the value of these environment variables. So the questions are: how are you running your code and what are the values of the environment variables that your Python program inherits, and, by any chance, is your program using the 'locale' module, and if so, exactly what functions from it? Please try adding the following in the environment you are seeing the problem: import sys print(sys.stdout) import os print([(k, os.environ[k]) for k in os.environ if k.startswith('LC')]) print([(k, os.environ[k]) for k in os.environ if k.startswith('LANG')]) import locale print(locale.getlocale()) print('\u00e5') print('\u0061\u030a') If I paste the above into a Python3.2 interactive terminal session using the python.org 64-/32-bit Python 3.2.3, I see the following: $ python3.2 Python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:25:50) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print(sys.stdout) <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'> >>> import os >>> print([(k, os.environ[k]) for k in os.environ if k.startswith('LC')]) [] >>> print([(k, os.environ[k]) for k in os.environ if k.startswith('LANG')]) [('LANG', 'en_US.UTF-8')] >>> import locale >>> print(locale.getlocale()) ('en_US', 'UTF-8') >>> print('\u00e5') ? >>> print('\u0061\u030a') ? But, if I explicitly remove the LANG environment variable: $ unset LANG $ python3.2 Python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:25:50) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print(sys.stdout) <_io.TextIOWrapper name='' mode='w' encoding='US-ASCII'> >>> import os >>> print([(k, os.environ[k]) for k in os.environ if k.startswith('LC')]) [] >>> print([(k, os.environ[k]) for k in os.environ if k.startswith('LANG')]) [] >>> import locale >>> print(locale.getlocale()) (None, None) >>> print('\u00e5') Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character '\xe5' in position 0: ordinal not in range(128) >>> print('\u0061\u030a') Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character '\u030a' in position 1: ordinal not in range(128) >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 21:02:09 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 19:02:09 +0000 Subject: [issue14984] netrc module allows read of non-secured .netrc file In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za> Message-ID: <1338663729.62.0.821218080464.issue14984@psf.upfronthosting.co.za> R. David Murray added the comment: This seems like something we should fix for the default file read. There is a backward compatibility concern, but I think the security aspect overrides that. ---------- components: +Library (Lib) nosy: +r.david.murray priority: normal -> high type: -> security versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 21:05:51 2012 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Sat, 02 Jun 2012 19:05:51 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index In-Reply-To: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za> Message-ID: <1338663951.48.0.851216227403.issue14974@psf.upfronthosting.co.za> Westley Mart?nez added the comment: -1 index is too generic to convey any kind of meaning and can be confused--atleast for me--with list.index. Sometimes it is better for a name to be specific. ---------- nosy: +anikom15 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 21:18:40 2012 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Sat, 02 Jun 2012 19:18:40 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1338664720.79.0.323378968803.issue14937@psf.upfronthosting.co.za> Westley Mart?nez added the comment: I think a better technique would be to expand FILENAME_CHARS to include more characters. ---------- nosy: +anikom15 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 21:20:16 2012 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Sat, 02 Jun 2012 19:20:16 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1338664816.46.0.816163041667.issue14937@psf.upfronthosting.co.za> Westley Mart?nez added the comment: Also, shouldn't the space character ' ' be included? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 21:49:43 2012 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Sat, 02 Jun 2012 19:49:43 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1338666583.2.0.676213313735.issue14937@psf.upfronthosting.co.za> Westley Mart?nez added the comment: Ahh okay, sorry for the triple post, I have an idea. On UNIX, the function should accept any character except: \0 /, and on Windows should accept any character except: \0 \ / : * ? " < > | On classic Macintosh, : is invalid. However, I do not know what characters are valid on other systems. (I believe Mac OS X is the same as UNIX, but am not sure.) Included is a patch with FILENAME_CHARS left in in case anything still needs it. ---------- Added file: http://bugs.python.org/file25802/cpython-14937.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 22:01:10 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 20:01:10 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1338667270.86.0.472179829874.issue1521950@psf.upfronthosting.co.za> R. David Murray added the comment: Review, including a code-but-not-algorithm review :), posted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 22:03:52 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 02 Jun 2012 20:03:52 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1338667432.42.0.321977088145.issue14937@psf.upfronthosting.co.za> Roger Serwy added the comment: I agree that chr(32) should be included in FILENAME_CHARS. The algorithm for backward searching checks that each character is contained in FILENAME_CHARS. I'm concerned about running time, as expanding FILENAME_CHARS to include all valid Unicode would be a large set to search. Do you know a better algorithm for determining when to perform a file-system completion when in a string? Also, are there any Unicode code points above 127 that are not valid in a filename? I appreciate that different file systems can have different constraints but I don't know all these subtle points. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 22:22:10 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 02 Jun 2012 20:22:10 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1338668530.89.0.98370118282.issue14937@psf.upfronthosting.co.za> Roger Serwy added the comment: Westley, I was responding to msg162168 and didn't see msg162169 yet. PEP11 mentions MacOS 9 support was removed in 2.4. Is ":" still invalid in OSX? I'll need to think about the approach of using an "INVALID_CHARS" list. It looks like it might be a better way to do this. However, here are some issues with the patch. I received this error: AttributeError: 'str' object has no attribute 'relpace' I fixed this minor mistype, but noticed that file auto-completion no longer works for the following: >>> "/ Pressing tab after the forward slash should show a drop-down with the root filesystem. Changing INVALID_CHARS to be: if os.name == 'posix': INVALID_CHARS = '\0' allows the root filesystem to show. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 22:34:37 2012 From: report at bugs.python.org (Adrian Bastholm) Date: Sat, 02 Jun 2012 20:34:37 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338669277.1.0.146453370085.issue14986@psf.upfronthosting.co.za> Adrian Bastholm added the comment: Output in console: Python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:25:50) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print(sys.stdout) <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'> >>> import os >>> print([(k, os.environ[k]) for k in os.environ if k.startswith('LC')]) [('LC_CTYPE', 'UTF-8')] >>> print([(k, os.environ[k]) for k in os.environ if k.startswith('LANG')]) [] >>> import locale >>> print(locale.getlocale()) Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/locale.py", line 524, in getlocale return _parse_localename(localename) File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/locale.py", line 433, in _parse_localename raise ValueError('unknown locale: %s' % localename) ValueError: unknown locale: UTF-8 >>> print('\u00e5') ? >>> print('\u0061\u030a') ? ********************** Output from Eclipse: <_io.TextIOWrapper name='' mode='w' encoding='MacRoman'> [] [] (None, None) ? Traceback (most recent call last): File "/Users/adyhasch/Documents/PythonWorkspace/PatternRenamer/src/prenamer.py", line 70, in print('\u0061\u030a') File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/encodings/mac_roman.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_table)[0] UnicodeEncodeError: 'charmap' codec can't encode character '\u030a' in position 1: character maps to ************************************ I'm running PyDev .. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 22:42:38 2012 From: report at bugs.python.org (Adrian Bastholm) Date: Sat, 02 Jun 2012 20:42:38 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338669758.65.0.813188730035.issue14986@psf.upfronthosting.co.za> Adrian Bastholm added the comment: my code runs fine in a console window, so it's some kind of configuration error. Sorry for wasting your time guys .. It would be nice to know why PyDev is not setting the right environment vars though .. >>> traverse(".") Processing ./.DS_Store Traversing ./2011-10-03--Sebi_o_costi_ny_frisyr Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/.DS_Store Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/.picasa.ini Traversing ./2011-10-03--Sebi_o_costi_ny_frisyr/2011-10-04--Sebastian_2?r Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/2011-10-04--Sebastian_2?r/.DS_Store Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/2011-10-04--Sebastian_2?r/.picasa.ini Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/2011-10-04--Sebastian_2?r/DSC_5467.JPG Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/2011-10-04--Sebastian_2?r/DSC_5468.JPG Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/2011-10-04--Sebastian_2?r/DSC_5472.JPG Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/DSC_5440.JPG Processing ./2011-10-03--Sebi_o_costi_ny_frisyr/DSC_5441.JPG Processing ./__init__.py Processing ./DSC_5440.JPG Processing ./DSC_5453.JPG Processing ./prenamer.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:02:28 2012 From: report at bugs.python.org (Francisco Gracia) Date: Sat, 02 Jun 2012 21:02:28 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1338670948.72.0.846032057338.issue14937@psf.upfronthosting.co.za> Francisco Gracia added the comment: Is there any necessity at all for the IDLE to test the validity of the filenames? I mean: the file specification is provided by the underlying operating system, so by definition it has to be taken as valid. Testing for its validity is superfluous and, in my opinion, a fault in the general conception of the procedure. IDLE's only role should be to present the data it receives in the best possible form and silently integrate the election made by the user. Excuse me if I speak nonsense, but I got this idea from studying *Autocomplete.py* and its dependencies. It seems to me that the difficulty resides in submitting natural language strings to the judgement of *PyParse* and *Hyperparser*, which are not competent for it because its purpose is to check the validity of Python code and Python *identifiers*. This confussion is what in my opinion causes this bug (and probably others related to the treatment of natural language text files by the IDLE, as it could also happen with issue 14929). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:06:02 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 21:06:02 +0000 Subject: [issue14971] (unittest) loadTestsFromName does not work on method with a decorator In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za> Message-ID: <1338671162.04.0.423731053206.issue14971@psf.upfronthosting.co.za> R. David Murray added the comment: Here's a patch. ---------- components: +Library (Lib) -Documentation keywords: +patch Added file: http://bugs.python.org/file25803/unittest_method_name_difference.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:30:07 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 02 Jun 2012 21:30:07 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338672607.6.0.423694031253.issue14986@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Glad we could help. I suspected it was running under "special circumstances". ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:31:12 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Jun 2012 21:31:12 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338672672.27.0.269749546166.issue14986@psf.upfronthosting.co.za> Ned Deily added the comment: I'm neither a PyDev nor an Eclipse user but there should be some way to set environment variables in it. Undoubtedly, Eclipse is launched as an app so a shell is not involved and shell profile files are not processed. However, the "Environment" section of this tutorial may help: http://pydev.org/manual_101_interpreter.html Try adding a definition for LANG or LC_CTYPE, as you prefer. And you should use a valid localized definition, like LANG=en_US.UTF-8 for US English UTF-8. The list of definitions is in Lib/locale.py. Good luck! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:31:52 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 21:31:52 +0000 Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za> Message-ID: <1338672712.19.0.714036005598.issue14007@psf.upfronthosting.co.za> R. David Murray added the comment: This is causing buildbot failures on some of the buildbots: http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/2529/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/5082/steps/test/logs/stdio ---------- nosy: +r.david.murray status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:55:30 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Jun 2012 21:55:30 +0000 Subject: [issue14959] ttk.Scrollbar in Notebook widget freezes In-Reply-To: <1338340992.23.0.15573788402.issue14959@psf.upfronthosting.co.za> Message-ID: <1338674130.6.0.771354148735.issue14959@psf.upfronthosting.co.za> Ned Deily added the comment: One final data point: I was unable to reproduce the failure when using a Python 3.2.3 when linked with a current ActiveState Tcl/Tk 8.4, which uses an older Aqua Carbon Tk. The python.org 32-bit-only Pythons use Tcl/Tk 8.4 like this; see http://www.python.org/download/mac/tcltk/ for more info. No guarantee that the problem won't show up there for you or that there won't be other issues (for instance, the Aqua Carbon Tcl/Tk is only available in 32-bit mode) but it *might* be worth a try. Given Kevin's response to your enquiry on the Mac Tcl list, the consensus seems to be that the problem here is indeed in the Cocoa port of Tcl/Tk and is unlikely to be addressed there soon. Sorry! http://permalink.gmane.org/gmane.comp.lang.tcl.mac/7029 ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:57:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jun 2012 21:57:12 +0000 Subject: [issue1079] decode_header does not follow RFC 2047 In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8c03fe231877 by R David Murray in branch 'default': #1079: Fix parsing of encoded words. http://hg.python.org/cpython/rev/8c03fe231877 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:57:34 2012 From: report at bugs.python.org (Paul Nasrat) Date: Sat, 02 Jun 2012 21:57:34 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338674254.75.0.631142113164.issue14982@psf.upfronthosting.co.za> Paul Nasrat added the comment: Ok so it seems I can't just use sys.meta_path in pip to work with ImpImporter due to according to the pydoc: Note that ImpImporter does not currently support being used by placement on sys.meta_path. I guess I can write a custom importer in pip for handling the vcs plugins or possibly change how we do that. Another option is to grossly hack around ala: i = ImpImporter(path=vcs.__path__[0]) sys.path_importer_cache.setdefault(vcs.__path__[0], i) Found another bug doing this though which I'll follow up with a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 2 23:59:27 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jun 2012 21:59:27 +0000 Subject: [issue1079] decode_header does not follow RFC 2047 In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za> Message-ID: <1338674367.19.0.693332047858.issue1079@psf.upfronthosting.co.za> R. David Murray added the comment: I've applied this to 3.3. Because the preservation of spaces around the ascii parts is a visible behavior change that could cause working programs to break, I don't think I can backport it. I'm going to leave this open until I can consult with Barry to see if he thinks a backport is justified. Anyone else can feel free to chime in with an opinion as well :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 00:00:07 2012 From: report at bugs.python.org (Paul Nasrat) Date: Sat, 02 Jun 2012 22:00:07 +0000 Subject: [issue14987] inspect missing warnings import Message-ID: <1338674407.28.0.70502641007.issue14987@psf.upfronthosting.co.za> New submission from Paul Nasrat : Whilst looking for workarounds to http://bugs.python.org/issue14982 I came across this, which is due to inspect using warnings without having importing it. Fix is trivial but can upload a patch Traceback (most recent call last): File "t.py", line 7, in print(list(iter_modules(path=vcs.__path__, prefix=vcs.__name__+'.'))) File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/pkgutil.py", line 144, in iter_modules for name, ispkg in iter_importer_modules(i, prefix): File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/pkgutil.py", line 202, in iter_modules modname = inspect.getmodulename(fn) File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/inspect.py", line 448, in getmodulename info = getmoduleinfo(path) File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/inspect.py", line 436, in getmoduleinfo warnings.warn('inspect.getmoduleinfo() is deprecated', DeprecationWarning, NameError: global name 'warnings' is not defined ---------- components: Library (Lib) messages: 162184 nosy: pnasrat priority: normal severity: normal status: open title: inspect missing warnings import versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 00:36:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Jun 2012 22:36:08 +0000 Subject: [issue11954] 3.3 - 'make test' fails In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za> Message-ID: <1338676568.27.0.107561415291.issue11954@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 00:39:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Jun 2012 22:39:08 +0000 Subject: [issue2401] Solaris: ctypes tests being skipped despite following #1516 In-Reply-To: <1205867491.87.0.489555231909.issue2401@psf.upfronthosting.co.za> Message-ID: <1338676748.11.0.90660250383.issue2401@psf.upfronthosting.co.za> Stefan Krah added the comment: This seems really out of date now. Closing. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 00:56:42 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Jun 2012 22:56:42 +0000 Subject: [issue14987] inspect missing warnings import In-Reply-To: <1338674407.28.0.70502641007.issue14987@psf.upfronthosting.co.za> Message-ID: <1338677802.43.0.262030186145.issue14987@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 01:02:29 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Jun 2012 23:02:29 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338678149.33.0.971326800179.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: > - From the docs, I could not understand the difference between > sys.implementation.version and sys.version_info. When can they differ? I'll make an update. As an example, PyPy is at version 1.8 which implements the Python 2.7 language. In that case sys.version_info would be (2, 7, 3, 'final', 0) while sys.implementation.version might be (1, 8, 0, 'final', 0). One confusing part is that for CPython they are exactly the same. I think there's room for improvement with the versioning of the language specification itself, but one thing at a time! :) > - _PyNamespace_New should be a public API function. From Python code, > SimpleNamespace is public. > - I agree that _PyNamespace_Type could stay private (it's an > implementation detail), in this case PyAPI_DATA is not necessary. Agreed, though I'd like to see sys.implementation go in first and take action on the PyNamespace type/API in a separate issue. > - SimpleNamespace should support weak references. I'll admit that I haven't used weakrefs a ton and am not familiar with the use cases. However, the fact that most of the builtin types do not support weak references gives me pause to simply adding it. I'd like more discussion on this, but in a separate issue so that it doesn't hold up sys.implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 01:33:20 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 Jun 2012 23:33:20 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338680000.09.0.217830460492.issue14673@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file25804/issue14673_full_4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 02:25:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 00:25:30 +0000 Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed before other file opened In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5b267381eea0 by Terry Jan Reedy in branch '2.7': Issue 10365: Add and replace comments; condense defaulted attribute access. http://hg.python.org/cpython/rev/5b267381eea0 New changeset 4f3d4ce8ac9f by Terry Jan Reedy in branch '3.2': Issue 10365: Add and replace comments; condense defaulted attribute access. http://hg.python.org/cpython/rev/4f3d4ce8ac9f New changeset d9b7399d9e45 by Terry Jan Reedy in branch 'default': Merge with 3.2 #10365 http://hg.python.org/cpython/rev/d9b7399d9e45 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 02:26:17 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 03 Jun 2012 00:26:17 +0000 Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed before other file opened In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za> Message-ID: <1338683177.1.0.631164792334.issue10365@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 04:28:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 02:28:52 +0000 Subject: [issue14987] inspect missing warnings import In-Reply-To: <1338674407.28.0.70502641007.issue14987@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 3de5b053d924 by Brett Cannon in branch 'default': Issue #14987: Add a missing import statement http://hg.python.org/cpython/rev/3de5b053d924 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 04:29:14 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 03 Jun 2012 02:29:14 +0000 Subject: [issue14987] inspect missing warnings import In-Reply-To: <1338674407.28.0.70502641007.issue14987@psf.upfronthosting.co.za> Message-ID: <1338690554.09.0.0659728025796.issue14987@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 05:12:00 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 03 Jun 2012 03:12:00 +0000 Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za> Message-ID: <1338693120.75.0.893730089622.issue14007@psf.upfronthosting.co.za> Eli Bendersky added the comment: Thanks. Fixed in changeset eb1d633fe307. I'll watch the bots to see no problems remain. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 05:23:50 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 03 Jun 2012 03:23:50 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338693830.59.0.904925627498.issue7559@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Thanks. It looks like the issue with the latest patch is caused by side effects of calling importlib.import_module(). Working from the patch, I got it to the point where inserting the following four lines somewhere in the code-- try: importlib.import_module('foo__doesnotexist') except: pass caused the exception raised by the following line-- module = importlib.import_module('package_foo2.subpackage.no_exist') to change from this-- ... File "", line 1250, in _find_and_load_unlocked ImportError: No module named 'package_foo2.subpackage.no_exist' to this-- ... File "..../Lib/importlib/_bootstrap.py", line 1257, in _find_and_load_unlocked raise ImportError(_ERR_MSG.format(name), name=name) ImportError: No module named 'package_foo2' It looks like this issue is cropping up in the tests because the test code dynamically adds packages to directories that importlib may already have examined. In the reduced test case I was creating to examine the issue, I found that inserting a call to importlib.invalidate_caches() at an appropriate location resolved the issue. Should loadTestsFromName() call importlib.invalidate_caches() in the new patch implementation, or should the test code be aware of that aspect of loadTestsFromName()'s behavior and be adjusted accordingly (e.g. by creating the dynamically-added packages in more isolated directories)? For backwards compatibility reasons, how does loadTestsFromName() currently behave in this regard (i.e. does importlib.import_module() behave the same as __import__ with respect to caching)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 05:48:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 03:48:02 +0000 Subject: [issue14424] document PyType_GenericAlloc In-Reply-To: <1332851611.13.0.643004221435.issue14424@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 3c43be281196 by Eli Bendersky in branch 'default': Issue #14424: Document PyType_GenericAlloc, and fix the documentation of PyType_GenericNew http://hg.python.org/cpython/rev/3c43be281196 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 05:48:32 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 03 Jun 2012 03:48:32 +0000 Subject: [issue14424] document PyType_GenericAlloc In-Reply-To: <1332851611.13.0.643004221435.issue14424@psf.upfronthosting.co.za> Message-ID: <1338695312.75.0.504933008569.issue14424@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 05:48:43 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 03 Jun 2012 03:48:43 +0000 Subject: [issue14424] document PyType_GenericAlloc In-Reply-To: <1332851611.13.0.643004221435.issue14424@psf.upfronthosting.co.za> Message-ID: <1338695323.09.0.574068354423.issue14424@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 07:07:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 05:07:32 +0000 Subject: [issue12510] IDLE get_the_calltip mishandles raw strings In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 477508efe4ab by Terry Jan Reedy in branch '2.7': Issue 12510: Expand 2 bare excepts. Improve comments. Change deceptive name http://hg.python.org/cpython/rev/477508efe4ab New changeset f927a5c6e4be by Terry Jan Reedy in branch '3.2': Issue 12510: Expand 2 bare excepts. Improve comments. Change deceptive name http://hg.python.org/cpython/rev/f927a5c6e4be New changeset a7501ddf74ac by Terry Jan Reedy in branch 'default': Merge with 3.2 #12510 http://hg.python.org/cpython/rev/a7501ddf74ac ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 07:09:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 05:09:49 +0000 Subject: [issue14090] Bus error on test_big_buffer() of test_zlib, buildbot AMD64 debian bigmem 3.x In-Reply-To: <1329944377.36.0.413864839881.issue14090@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 90f0dd118aa4 by Eli Bendersky in branch 'default': Issue #14090: fix some minor C API problems in default branch (3.3) http://hg.python.org/cpython/rev/90f0dd118aa4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 07:12:08 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 03 Jun 2012 05:12:08 +0000 Subject: [issue14190] Minor C API documentation bugs In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za> Message-ID: <1338700328.47.0.647121999611.issue14190@psf.upfronthosting.co.za> Eli Bendersky added the comment: Fixed what was relevant for default (3.3) in 90f0dd118aa4 (the commit message there has a typo in the issue number). Since 3.3 is going to be out soon, I see no real reason to backport to 3.2 If anyone is willing to create a complete patch for 2.7 that fixes the relevant issues, I will review it. Ejaj, are your diffs for 2.7? Can you create a single patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 07:17:15 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 03 Jun 2012 05:17:15 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338700635.54.0.244237111006.issue12510@psf.upfronthosting.co.za> Terry J. Reedy added the comment: CallTips.py has a 'main' test at the end. Currently, test TC fails in 3.x but not 2.7. So either the test became invalid or get_argspec was not completely and correctly converted from get_arg_text. This should be fixed. int.append( does not bring up a tip on either version, but should if possible. The failing examples in previous messages should be added to the tests to ensure that all pass now and continue to pass in the future. So I am not closing this yet, and a new patch is needed. ---------- resolution: fixed -> stage: committed/rejected -> needs patch title: IDLE get_the_calltip mishandles raw strings -> IDLE: calltips mishandle raw strings and other examples _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 07:49:18 2012 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Sun, 03 Jun 2012 05:49:18 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1338702558.63.0.319448720619.issue14937@psf.upfronthosting.co.za> Westley Mart?nez added the comment: You're right. The code shouldn't *have* to check if the name is valid. It should just accept that the name is already valid. This would simplify things. Here's the problem: the code needs to find the index of where the string with the filename starts. The way the code does it now by checking for a quote in a rather obfuscated way (while i and curline[i-1] in FILENAME_CHARS + SEPS:). So, changing that line to say curline[i-1] != "'" or curline[i-1] != '"' would work (in theory) but I'm really hoping there's a better way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 08:23:49 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 03 Jun 2012 06:23:49 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338704629.18.0.973646968944.issue14982@psf.upfronthosting.co.za> Chris Jerdonek added the comment: See also issue 14787 re: walk_packages(), which also affects versions before 3.3. ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 09:21:56 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 Jun 2012 07:21:56 +0000 Subject: [issue14988] _elementtree: Raise ImportError when importing of pyexpat fails Message-ID: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis : If, after building of Python, libexpat.so (library used by pyexpat module) has been broken/removed or pyexpat module has been broken/removed, then attempt of import of _elementtree module, which requires pyexpat module, will raise strange exceptions in Python 3. These exceptions can be simulated by setting sys.modules["pyexpat"] = None. $ python2.6 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree' Traceback (most recent call last): File "", line 1, in ImportError: No module named pyexpat $ python2.7 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree' Traceback (most recent call last): File "", line 1, in ImportError: PyCapsule_Import could not import module "pyexpat" $ python3.1 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree' Traceback (most recent call last): File "", line 1, in SystemError: initialization of _elementtree raised unreported exception $ python3.2 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree' Traceback (most recent call last): File "", line 1, in SystemError: initialization of _elementtree raised unreported exception $ python3.3 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree' Traceback (most recent call last): File "", line 1, in File "", line 1286, in _find_and_load File "", line 1253, in _find_and_load_unlocked File "", line 432, in _check_name_wrapper File "", line 347, in set_package_wrapper File "", line 360, in set_loader_wrapper File "", line 870, in load_module RuntimeError: cannot load dispatch table from pyexpat I suggest to raise ImportError instead of SystemError or RuntimeError. Third-party modules would rather use only 'except ImportError: pass' instead of 'except (ImportError, SystemError, RuntimeError): pass' when trying to optionally use e.g. xml.etree.cElementTree. xml.etree.ElementTree in Python 3.3 also ignores only ImportError when trying to import _elementtree. ---------- messages: 162198 nosy: Arfrever, eli.bendersky, flox priority: normal severity: normal status: open title: _elementtree: Raise ImportError when importing of pyexpat fails versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 09:26:12 2012 From: report at bugs.python.org (Zac Medico) Date: Sun, 03 Jun 2012 07:26:12 +0000 Subject: [issue14988] _elementtree: Raise ImportError when importing of pyexpat fails In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za> Message-ID: <1338708373.0.0.257841539379.issue14988@psf.upfronthosting.co.za> Changes by Zac Medico : ---------- nosy: +zmedico _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 10:03:04 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 03 Jun 2012 08:03:04 +0000 Subject: [issue14989] http.server option to run CGIHTTPRequestHandler Message-ID: <1338710584.57.0.336351054508.issue14989@psf.upfronthosting.co.za> New submission from Senthil Kumaran : python3 -m http.server enables you to serve with SimpleHTTPRequestHandler serving as http server. If the cgi-bin paths are present those are *not treated as cgi paths*. Previously in Python2, python -m CGIHTTPServer enabled the sever to run it as CGI enabled HTTP Server. Since in Python3, both SimpleHTTPServer and CGIHTTPServer are combined into http/server.py, I think having a option to serve cgi server from command like invocation is a good idea. This is not a new feature, just an enabler in command line execution of http.server module and I think, it should be made available in 3.2 as well as it already available in 2.7 ( via CGIHTTPServer). ---------- assignee: orsenthil messages: 162199 nosy: orsenthil priority: normal severity: normal stage: needs patch status: open title: http.server option to run CGIHTTPRequestHandler type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 10:16:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 08:16:50 +0000 Subject: [issue14989] http.server option to run CGIHTTPRequestHandler In-Reply-To: <1338710584.57.0.336351054508.issue14989@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 935a656359ae by Senthil Kumaran in branch 'default': Issue 14989: http.server --cgi option can enable the CGI http server. http://hg.python.org/cpython/rev/935a656359ae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 10:19:48 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 03 Jun 2012 08:19:48 +0000 Subject: [issue14989] http.server option to run CGIHTTPRequestHandler In-Reply-To: <1338710584.57.0.336351054508.issue14989@psf.upfronthosting.co.za> Message-ID: <1338711588.09.0.990455616481.issue14989@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I have added this in 3.3, I am not sure if adding to 3.2 is a good idea. To some, it may look like a feature. ---------- resolution: -> fixed stage: needs patch -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 11:25:27 2012 From: report at bugs.python.org (Adrian Bastholm) Date: Sun, 03 Jun 2012 09:25:27 +0000 Subject: [issue14986] print() fails on latin1 characters on OSX In-Reply-To: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za> Message-ID: <1338715527.2.0.124688856752.issue14986@psf.upfronthosting.co.za> Adrian Bastholm added the comment: Thanks a lot for the help, guys ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 12:00:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 10:00:57 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 41e85ac2ccef by Martin v. L?wis in branch '3.2': Issue #14937: Perform auto-completion of filenames in strings even for non-ASCII filenames. http://hg.python.org/cpython/rev/41e85ac2ccef New changeset 9aa8af0761ef by Martin v. L?wis in branch 'default': Merge 3.2: issue #14937. http://hg.python.org/cpython/rev/9aa8af0761ef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 12:02:58 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 03 Jun 2012 10:02:58 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1338717778.68.0.553069363848.issue14937@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have now fixed it by looking for the beginning of the string, and not checking for file name characters at all. There was a related issue that the auto-complete window would disappear if you type a non-ascii character; I have fixed that as well. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 12:29:02 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 03 Jun 2012 10:29:02 +0000 Subject: [issue14990] detect_encoding should fail with SyntaxError on invalid encoding Message-ID: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za> New submission from Florent Xicluna : I've hit this issue while playing with tokenize for the pep8.py module. The tokenize detect_encoding() should report SyntaxError when the encoding is improperly declared. However it raises a LookupError in some cases. $ ./python -m tokenize Lib/test/bad_coding2.py unexpected error: unknown encoding: utf8-sig Traceback (most recent call last): File "./Lib/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "./Lib/runpy.py", line 75, in _run_code exec(code, run_globals) File "./Lib/tokenize.py", line 686, in main() File "./Lib/tokenize.py", line 656, in main tokens = list(tokenize(f.readline)) File "./Lib/tokenize.py", line 489, in _tokenize line = line.decode(encoding) LookupError: unknown encoding: utf8-sig ---------- components: Library (Lib) messages: 162205 nosy: flox priority: normal severity: normal stage: needs patch status: open title: detect_encoding should fail with SyntaxError on invalid encoding type: behavior versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 12:31:05 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 03 Jun 2012 10:31:05 +0000 Subject: [issue14990] detect_encoding should fail with SyntaxError on invalid encoding In-Reply-To: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za> Message-ID: <1338719465.81.0.506285913695.issue14990@psf.upfronthosting.co.za> Florent Xicluna added the comment: This patch seems to fix the issue. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file25805/issue14990_detect_encoding.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 14:06:45 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 03 Jun 2012 12:06:45 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1338725205.73.0.493488121911.issue13598@psf.upfronthosting.co.za> Ramchandra Apte added the comment: What is the status of the bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 14:07:30 2012 From: report at bugs.python.org (Francisco Gracia) Date: Sun, 03 Jun 2012 12:07:30 +0000 Subject: [issue14929] IDLE crashes on *Edit / Find in files ...* command In-Reply-To: <1338151641.58.0.68836434552.issue14929@psf.upfronthosting.co.za> Message-ID: <1338725250.86.0.316327233725.issue14929@psf.upfronthosting.co.za> Francisco Gracia added the comment: While your are at it, here is another suggestion: what the *Find in files ...* dialog needs most urgently in my opinion is a field for specifying clearly the directory from which the user wants to launch the search. Also in my modest opinion, having an input field for encondings would be good, although detecting the encodings of the handled files is something that any self respecting software should reliably do by itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 15:28:33 2012 From: report at bugs.python.org (David Beck) Date: Sun, 03 Jun 2012 13:28:33 +0000 Subject: [issue14959] ttk.Scrollbar in Notebook widget freezes In-Reply-To: <1338340992.23.0.15573788402.issue14959@psf.upfronthosting.co.za> Message-ID: <1338730113.56.0.0164307343711.issue14959@psf.upfronthosting.co.za> David Beck added the comment: That's a shame, though I guess it means I can stop struggling with the installation of Tix. Since that's another extension of Tk, the same issue will probably be lurking in there as well. Maybe I'll give wxPyton or QT a shot. Thanks for your help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 15:45:54 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Sun, 03 Jun 2012 13:45:54 +0000 Subject: [issue14983] email.generator should always add newlines after closing boundaries In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za> Message-ID: <1338731154.63.0.789322577606.issue14983@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: > Hmm. So that means the verifiers are not paying attention to the MIME > RFC? That's unfortunate. It seems that's true... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 15:49:15 2012 From: report at bugs.python.org (Daniel Urban) Date: Sun, 03 Jun 2012 13:49:15 +0000 Subject: [issue11480] Cannot copy a class with a metaclass other than type In-Reply-To: <1300007060.0.0.461224143225.issue11480@psf.upfronthosting.co.za> Message-ID: <1338731355.96.0.223864700491.issue11480@psf.upfronthosting.co.za> Daniel Urban added the comment: I've updated the patch to the current version. I've also checked, that the tests still pass. ---------- nosy: +ncoghlan Added file: http://bugs.python.org/file25806/copy_metaclass_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 16:36:47 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Jun 2012 14:36:47 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338734207.56.0.510289977067.issue7559@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for figuring that out. And no, it doesn't matter if it is importlib.load_module or __import__, since both are provided by importlib now and both use the cache. It's an interesting question where the cache clear should go. I *think* it should go in the test, based on the idea that the cache is part of the environment, and therefore should be reset by tests that change what's on the path. I'm not sure how we'd write an environment monitor for that, since not all changes to the import cache need to be reset. I wonder if it would be worth putting a reset into DirsOnSysPath. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 16:46:17 2012 From: report at bugs.python.org (Natalia) Date: Sun, 03 Jun 2012 14:46:17 +0000 Subject: [issue14894] distutils.LooseVersion fails to compare number and a word In-Reply-To: <1337805749.61.0.661955519892.issue14894@psf.upfronthosting.co.za> Message-ID: <1338734777.97.0.590568885336.issue14894@psf.upfronthosting.co.za> Natalia added the comment: Hi, I'm attaching a patch that fixes this issue:) ---------- keywords: +patch Added file: http://bugs.python.org/file25807/14894.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 17:39:19 2012 From: report at bugs.python.org (Natalia) Date: Sun, 03 Jun 2012 15:39:19 +0000 Subject: [issue14894] distutils.LooseVersion fails to compare number and a word In-Reply-To: <1337805749.61.0.661955519892.issue14894@psf.upfronthosting.co.za> Message-ID: <1338737959.42.0.609383499477.issue14894@psf.upfronthosting.co.za> Natalia added the comment: I had a wrong return value in one of unit tests, fixed. ---------- Added file: http://bugs.python.org/file25808/14894.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 17:39:31 2012 From: report at bugs.python.org (Natalia) Date: Sun, 03 Jun 2012 15:39:31 +0000 Subject: [issue14894] distutils.LooseVersion fails to compare number and a word In-Reply-To: <1337805749.61.0.661955519892.issue14894@psf.upfronthosting.co.za> Message-ID: <1338737971.13.0.927869839569.issue14894@psf.upfronthosting.co.za> Changes by Natalia : Removed file: http://bugs.python.org/file25807/14894.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 18:05:52 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 03 Jun 2012 16:05:52 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1338680000.67.0.0979634789519.issue14673@psf.upfronthosting.co.za> Message-ID: <20120603120545.19a87ff5@resist.wooz.org> Barry A. Warsaw added the comment: On Jun 02, 2012, at 11:33 PM, Eric Snow wrote: >Added file: http://bugs.python.org/file25804/issue14673_full_4.diff Hi Eric. I'm ready to do a final review and merge this in, but I just want to be sure I'm looking at the right file. Is full_4.diff the most up-to-date patch, and is it complete (i.e. contains all code, docs, and tests)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 18:06:32 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 03 Jun 2012 16:06:32 +0000 Subject: [issue1079] decode_header does not follow RFC 2047 In-Reply-To: <1338674367.19.0.693332047858.issue1079@psf.upfronthosting.co.za> Message-ID: <20120603120628.762a6dc0@resist.wooz.org> Barry A. Warsaw added the comment: On Jun 02, 2012, at 09:59 PM, R. David Murray wrote: >I've applied this to 3.3. Because the preservation of spaces around the >ascii parts is a visible behavior change that could cause working programs to >break, I don't think I can backport it. I'm going to leave this open until I >can consult with Barry to see if he thinks a backport is justified. Anyone >else can feel free to chime in with an opinion as well :) I think a backport is risky. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 18:10:00 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 03 Jun 2012 16:10:00 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1338624210.3.0.500930407658.issue14673@psf.upfronthosting.co.za> Message-ID: <20120603120956.3d396995@resist.wooz.org> Barry A. Warsaw added the comment: On Jun 02, 2012, at 08:03 AM, Amaury Forgeot d'Arc wrote: >- _PyNamespace_New should be a public API function. From Python code, >- SimpleNamespace is public. This is a separate discussion. I'm not opposed, but I don't think this should be addressed in this patch. >- SimpleNamespace should support weak references. Again, this could be addressed separately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 18:10:24 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Jun 2012 16:10:24 +0000 Subject: [issue1079] decode_header does not follow RFC 2047 In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za> Message-ID: <1338739824.71.0.410313511185.issue1079@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I'm closing this, then, and will close the related issues as well. Thanks again for the patch, Ralf. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 18:14:50 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Jun 2012 16:14:50 +0000 Subject: [issue1467619] Header.decode_header eats up spaces Message-ID: <1338740090.95.0.403231392728.issue1467619@psf.upfronthosting.co.za> R. David Murray added the comment: This is fixed by the fix in issue 1079. Ralf found a *relatively* backward compatible way to fix it, but since the point is preserving whitespace that wasn't preserved before, there is an unavoidable behavior change, so it can't be backported. ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> decode_header does not follow RFC 2047 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 18:27:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 16:27:21 +0000 Subject: [issue1079] decode_header does not follow RFC 2047 In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0808cb8c60fd by R David Murray in branch 'default': #2658: Add test for issue fixed by fix for #1079. http://hg.python.org/cpython/rev/0808cb8c60fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 18:27:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 16:27:22 +0000 Subject: [issue2658] decode_header() fails on multiline headers In-Reply-To: <1208608894.4.0.0735061784066.issue2658@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0808cb8c60fd by R David Murray in branch 'default': #2658: Add test for issue fixed by fix for #1079. http://hg.python.org/cpython/rev/0808cb8c60fd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 18:28:42 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Jun 2012 16:28:42 +0000 Subject: [issue2658] decode_header() fails on multiline headers In-Reply-To: <1208608894.4.0.0735061784066.issue2658@psf.upfronthosting.co.za> Message-ID: <1338740922.61.0.460424938559.issue2658@psf.upfronthosting.co.za> R. David Murray added the comment: This is fixed by the fix for issue 1079. I've added the test to the test suite. ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> decode_header does not follow RFC 2047 versions: -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 3 19:01:01 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 03 Jun 2012 17:01:01 +0000 Subject: [issue14991] Option for regex groupdict() to show only matching names Message-ID: <1338742861.24.0.324062376049.issue14991@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Currently, mo.groupdict() always inserts a default value for unmatched named groups. This is helpful in some use cases and awkward in others. I propose adding an option to suppress default entries: >>> # CURRENT WAY >>> pattern = r'(?PMrs |Mr |Dr )?(?P<LASTNAME>\w+)(?P<SUFFIX> Phd| JD)?' >>> print re.match(pattern, 'Dr Who').groupdict() {'LASTNAME': 'Who', 'SUFFIX': None, 'TITLE': 'Dr '} >>> # PROPOSED WAY >>> print re.match(pattern, 'Dr Who').groupdict(nodefault=True) {'LASTNAME': 'Who', 'TITLE': 'Dr '} >>> # UPSTREAM VARIANT >>> print re.match(pattern, 'Dr Who', re.NODEFAULT).groupdict() {'LASTNAME': 'Who', 'TITLE': 'Dr '} There is probably a better name than "nodefault", but I would like to see someway to improve the usability of groupdict(). ---------- messages: 162223 nosy: rhettinger priority: normal severity: normal status: open title: Option for regex groupdict() to show only matching names type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14991> _______________________________________ From report at bugs.python.org Sun Jun 3 19:06:27 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 03 Jun 2012 17:06:27 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1338743187.15.0.534652877699.issue13598@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Could you upload just one patch with fix and test, addressing my previous comments, and remove the old patches? It will make it easier for Eric to review when he gets some time. Please also keep lines under 80 characters. Thanks in advance. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Sun Jun 3 19:50:37 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 03 Jun 2012 17:50:37 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1338745837.49.0.0334092530882.issue1521950@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: Added file: http://bugs.python.org/file25809/388411be9b61.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1521950> _______________________________________ From report at bugs.python.org Sun Jun 3 20:03:25 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 03 Jun 2012 18:03:25 +0000 Subject: [issue14712] Integrate PEP 405 In-Reply-To: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za> Message-ID: <1338746605.21.0.458213780124.issue14712@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: Closing, as the changes are now incorporated in default, and the buildbots seem reasonably happy. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14712> _______________________________________ From report at bugs.python.org Sun Jun 3 20:28:13 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 03 Jun 2012 18:28:13 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1338748093.47.0.201190259018.issue13598@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: It seems like the patch doesn't consider mixing of positional and keyword arguments: if you have the format string "{foo} {} {bar}", then manual will be set to True when "foo" is seen as the field_name, and fail soon after when "" is seen as the field_name the next time around. So, the test should include something which shows that fmt.format("{foo} {} {bar}", 2, foo='fooval', bar='barval') returns "fooval 2 barval", whereas with a format string like "{foo} {0} {} {bar}" or "{foo} {} {0} {bar}" you get a ValueError. Also, why "automatic field numbering" vs. "manual field specification"? Why not "numbering" for both? ---------- nosy: +vinay.sajip _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Sun Jun 3 20:35:55 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 03 Jun 2012 18:35:55 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338748555.65.0.217632113043.issue14673@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: > Is full_4.diff the most up-to-date > patch, and is it complete (i.e. contains all code, docs, and tests)? Yep. :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14673> _______________________________________ From report at bugs.python.org Sun Jun 3 21:16:34 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 03 Jun 2012 19:16:34 +0000 Subject: [issue14992] os.makedirs expect_ok=True test_os failure when directory has S_ISGID bit set Message-ID: <1338750994.84.0.984038556909.issue14992@psf.upfronthosting.co.za> New submission from Gregory P. Smith <greg at krypto.org>: ====================================================================== ERROR: test_exist_ok_existing_directory (__main__.MakedirTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_os.py", line 842, in test_exist_ok_existing_directory os.makedirs(path, mode=mode, exist_ok=True) File "/home/greg/sandbox/python/cpython/default/Lib/os.py", line 161, in makedirs mkdir(name, mode) FileExistsError: [Errno 17] File exists (mode 0o2755 != desired mode 0o755): '@test_4027_tmp/dir1' (I modified os.makedirs to add the info on the mode differences above to highlight the source of the problem) 0o2000 is the S_ISGID bit on a directory which is a "contagious" bit that is automatically copied onto subdirectories. os.makedirs is not expecting to find it so exist_ok does not work as desired. Workaround: Don't run the Python test suite from a directory with that bit set. I think the os.makedirs() behavior should be to ignore bits that can appear regardless of the umask as it makes exist_ok=True useless in that situation. ---------- messages: 162228 nosy: gregory.p.smith priority: normal severity: normal status: open title: os.makedirs expect_ok=True test_os failure when directory has S_ISGID bit set versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14992> _______________________________________ From report at bugs.python.org Sun Jun 3 21:25:23 2012 From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Malo?=) Date: Sun, 03 Jun 2012 19:25:23 +0000 Subject: [issue14993] GCC error when using unicodeobject.h Message-ID: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> New submission from Andr? Malo <nd at perlig.de>: GCC error when using unicodeobject.h This ist my first attempt to test an extension with python 3.3. I've been using the 3.3.0a4 tarball. I'm using very strict compiler settings when compiling my extension modules, especially -Wall -Werror (along with a lot more flags, like -pedantic, -std=c89). Including Python.h includes unicodeobject.h which emits: /usr/include/python3.3/unicodeobject.h:905: error: type of bit-field 'overallocate' is a GCC extension /usr/include/python3.3/unicodeobject.h:908: error: type of bit-field 'readonly' is a GCC extension Maybe these should just be (unsigned) ints or something? ---------- components: Extension Modules, Interpreter Core messages: 162229 nosy: ndparker priority: normal severity: normal status: open title: GCC error when using unicodeobject.h type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Sun Jun 3 21:31:09 2012 From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Malo?=) Date: Sun, 03 Jun 2012 19:31:09 +0000 Subject: [issue14994] GCC error when using pyerrors.h Message-ID: <1338751869.08.0.200680664927.issue14994@psf.upfronthosting.co.za> New submission from Andr? Malo <nd at perlig.de>: GCC error when using pyerrors.h This ist my first attempt to test an extension with python 3.3. I've been using the 3.3.0a4 tarball. I'm using very strict compiler settings when compiling my extension modules, especially -Wall -Werror (along with a lot more flags, like -pedantic, -std=c89). Including Python.h includes pyerrors.h which emits: /usr/include/python3.3/pyerrors.h:91:8: error: "__GNUC_MAJOR__" is not defined /usr/include/python3.3/pyerrors.h:92:8: error: "__GNUC_MAJOR__" is not defined I'm not sure, which of the compiler flags is responsible for dropping those macros. Simple defined() checks should fix that problem though. ---------- components: Extension Modules, Interpreter Core messages: 162230 nosy: ndparker priority: normal severity: normal status: open title: GCC error when using pyerrors.h type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14994> _______________________________________ From report at bugs.python.org Sun Jun 3 22:04:50 2012 From: report at bugs.python.org (Daniel Harding) Date: Sun, 03 Jun 2012 20:04:50 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1338753890.52.0.390594516998.issue9949@psf.upfronthosting.co.za> Daniel Harding <dharding at gmail.com> added the comment: The previous version of this patch did not handle bytes arguments correctly and could fail in conjunction with a non-ASCII compatible encoding. Also, if the result was a UNC path, it was not being handled correctly (the returned value would have started with a single backslash, not two). Version 3 of the patch fixes these issues. I am also attaching a single, condensed patch as requested by the Lifecycle of a Patch devguide. I can also provide a patch series as before if desired. ---------- keywords: +patch Added file: http://bugs.python.org/file25810/issue9949-v3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9949> _______________________________________ From report at bugs.python.org Sun Jun 3 22:50:48 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 03 Jun 2012 20:50:48 +0000 Subject: [issue14989] http.server option to run CGIHTTPRequestHandler In-Reply-To: <1338710584.57.0.336351054508.issue14989@psf.upfronthosting.co.za> Message-ID: <1338756648.9.0.464246447557.issue14989@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I don?t think this can be defended as a bug fix, so let?s keep 3.2 as it is. ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14989> _______________________________________ From report at bugs.python.org Sun Jun 3 22:51:05 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 03 Jun 2012 20:51:05 +0000 Subject: [issue14992] os.makedirs expect_ok=True test_os failure when directory has S_ISGID bit set In-Reply-To: <1338750994.84.0.984038556909.issue14992@psf.upfronthosting.co.za> Message-ID: <1338756665.71.0.310343867831.issue14992@psf.upfronthosting.co.za> Changes by Gregory P. Smith <greg at krypto.org>: ---------- versions: +Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14992> _______________________________________ From report at bugs.python.org Sun Jun 3 22:54:40 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 03 Jun 2012 20:54:40 +0000 Subject: [issue14714] PEP 414 tokenizing hook does not preserve tabs In-Reply-To: <1336059831.47.0.0507292871504.issue14714@psf.upfronthosting.co.za> Message-ID: <1338756880.15.0.952924828736.issue14714@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: ---------- title: PEp 414 tokenizing hook does not preserve tabs -> PEP 414 tokenizing hook does not preserve tabs _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14714> _______________________________________ From report at bugs.python.org Sun Jun 3 23:27:23 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 03 Jun 2012 21:27:23 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338758843.45.0.914888108187.issue12510@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: fix_12510.patch addresses the issue with the test. What do you mean by: "int.append( does not bring up a tip on either version, but should if possible." ? The "int" object does not have "append" as a method. ---------- Added file: http://bugs.python.org/file25811/fix_12510.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Sun Jun 3 23:36:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jun 2012 21:36:53 +0000 Subject: [issue14992] os.makedirs expect_ok=True test_os failure when directory has S_ISGID bit set In-Reply-To: <1338750994.84.0.984038556909.issue14992@psf.upfronthosting.co.za> Message-ID: <E1SbITk-0004fc-3L@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset fef529f3de5b by Gregory P. Smith in branch '3.2': Fixes Issue #14992: os.makedirs(path, exist_ok=True) would raise an OSError http://hg.python.org/cpython/rev/fef529f3de5b New changeset eed26e508b7e by Gregory P. Smith in branch 'default': Fixes Issue #14992: os.makedirs(path, exist_ok=True) would raise an OSError http://hg.python.org/cpython/rev/eed26e508b7e ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14992> _______________________________________ From report at bugs.python.org Sun Jun 3 23:42:29 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 03 Jun 2012 21:42:29 +0000 Subject: [issue14992] os.makedirs expect_ok=True test_os failure when directory has S_ISGID bit set In-Reply-To: <1338750994.84.0.984038556909.issue14992@psf.upfronthosting.co.za> Message-ID: <1338759749.88.0.215174417459.issue14992@psf.upfronthosting.co.za> Changes by Gregory P. Smith <greg at krypto.org>: ---------- assignee: -> gregory.p.smith resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14992> _______________________________________ From report at bugs.python.org Sun Jun 3 23:46:47 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Jun 2012 21:46:47 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1338760007.94.0.670464464165.issue14814@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: With a cross link from the header of the module reference to the howto guide, I think what Sandro posted is good enough for a first draft. Once the basic content is checked in, then I'll tinker a bit to figure out a more logical order (and possibly move some details from the current howto guide into the module reference). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 4 00:08:01 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Jun 2012 22:08:01 +0000 Subject: [issue9967] encoded_word regular expression in email.header.decode_header() In-Reply-To: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za> Message-ID: <1338761281.6.0.550551112155.issue9967@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Instead of doing this we've opted to follow postel and be generous in what we accept and go ahead and decode even if the leading and/or terminating space is missing (see issue 1079). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9967> _______________________________________ From report at bugs.python.org Mon Jun 4 00:11:21 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Jun 2012 22:11:21 +0000 Subject: [issue10574] email.header.decode_header fails if the string contains multiple directives In-Reply-To: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za> Message-ID: <1338761481.64.0.11534318812.issue10574@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: This is fixed by the fix to issue 1079, but we have decided that fix can't be backported because it is a behavior change that might break existing working programs. ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> decode_header does not follow RFC 2047 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10574> _______________________________________ From report at bugs.python.org Mon Jun 4 00:35:01 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 03 Jun 2012 22:35:01 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338762901.79.0.306308445503.issue14982@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: I should mention that Guido and others on python-dev mentioned coming up with an API for finders/loaders that allowed for file-like API and possibly being able to iterate over available modules when importlib's bootstrapping landed (sorry, don't have a link for it). If pip needs some specific introspection support from finders or loaders I would try asking on python-dev about exactly what you need to see if it can get into Python 3.3. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14982> _______________________________________ From report at bugs.python.org Mon Jun 4 01:13:31 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 03 Jun 2012 23:13:31 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338765211.57.0.283673025083.issue7559@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Not sure what DirsOnSysPath is, but I have been only calling importlib.invalidate_caches() as needed in order to not slow down tests needlessly. And as for detecting an environment change as necessary, that's essentially impossible since it's only needed if something changed between imports which would require adding a hook to notice that an import happened *and* a directory already covered by sys.path_importer_cache (not sys.path since that doesn't cover packages) changed w/o calling invalidate_caches(). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7559> _______________________________________ From report at bugs.python.org Mon Jun 4 01:16:38 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 03 Jun 2012 23:16:38 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1338765398.17.0.05439521233.issue13598@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- nosy: +flox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Mon Jun 4 01:31:22 2012 From: report at bugs.python.org (Ronan Lamy) Date: Sun, 03 Jun 2012 23:31:22 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <1338766282.17.0.204526399692.issue14938@psf.upfronthosting.co.za> Ronan Lamy <ronan.lamy at gmail.com> added the comment: I'm not sure that it's enough to test is_package() because that only involves the loader and not the interaction between it and FileFinder. That's the reason why my test works at a higher level. BTW, I sent the contributor agreement. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14938> _______________________________________ From report at bugs.python.org Mon Jun 4 02:32:36 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jun 2012 00:32:36 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338769956.92.0.121869034232.issue7559@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: OK, let's just do it in the individual test, then. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7559> _______________________________________ From report at bugs.python.org Mon Jun 4 02:32:53 2012 From: report at bugs.python.org (Ryan Kelly) Date: Mon, 04 Jun 2012 00:32:53 +0000 Subject: [issue14995] PyLong_FromString documentation should state that the string must be null-terminated Message-ID: <1338769973.67.0.784454345332.issue14995@psf.upfronthosting.co.za> New submission from Ryan Kelly <ryan at rfk.id.au>: PyLong_FromString will raise a ValueError if the given string doesn't contain a null byte after the digits. For example, this will result in a ValueError char *pend; PyLong_FromString("1234 extra", &pend, 10) While this will successfully read the number and set the pointer to the extra data: char *pend; PyLong_FromString("1234\0extra", &pend, 10) The requirement for a null-terminated string of digits is not clear from the docs. Suggested re-wording attached. ---------- assignee: docs at python components: Documentation files: PyLong_FromString-doc.patch keywords: patch messages: 162242 nosy: docs at python, rfk priority: normal severity: normal status: open title: PyLong_FromString documentation should state that the string must be null-terminated Added file: http://bugs.python.org/file25812/PyLong_FromString-doc.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14995> _______________________________________ From report at bugs.python.org Mon Jun 4 03:14:55 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Mon, 04 Jun 2012 01:14:55 +0000 Subject: [issue14996] pthon 3.2.3 freezes when saving a .py program Message-ID: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> New submission from Maureen Cuomo <mcuomo at prestonhs.org>: I have been using ver 3.2.1 without a problem. Downloaded 3.2.3 nd cannot save any file in idle. ---------- components: IDLE messages: 162243 nosy: mcuomo at prestonhs.org priority: normal severity: normal status: open title: pthon 3.2.3 freezes when saving a .py program type: crash versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Mon Jun 4 03:18:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jun 2012 01:18:28 +0000 Subject: [issue14994] GCC error when using pyerrors.h In-Reply-To: <1338751869.08.0.200680664927.issue14994@psf.upfronthosting.co.za> Message-ID: <E1SbLw9-000281-QR@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 696d3631a4a1 by Benjamin Peterson in branch 'default': __GNUC__ does not imply gcc version is present, so just check for version (closes #14994) http://hg.python.org/cpython/rev/696d3631a4a1 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14994> _______________________________________ From report at bugs.python.org Mon Jun 4 03:19:26 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 04 Jun 2012 01:19:26 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> Message-ID: <1338772766.9.0.878744705093.issue14993@psf.upfronthosting.co.za> Benjamin Peterson <benjamin at python.org> added the comment: It might not matter if it's an extension that everyone implements. ---------- nosy: +benjamin.peterson, loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Mon Jun 4 03:30:08 2012 From: report at bugs.python.org (cuulblu) Date: Mon, 04 Jun 2012 01:30:08 +0000 Subject: [issue14997] Syntax Error in Python Version Number Message-ID: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za> New submission from cuulblu <ken at fivefingerdesigns.com>: When using Idle any code I attempt to test I get a syntax error in the version number of the software. Please see the attached image. I have python installed on three machines and get the same error on all three. All three machines are Windows 7, 64 bit. Two have Intel CPU's. One is an AMD. I have tried reinstalling. Same results. ---------- components: IDLE files: python_error.jpg messages: 162246 nosy: cuulblu priority: normal severity: normal status: open title: Syntax Error in Python Version Number type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file25813/python_error.jpg _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14997> _______________________________________ From report at bugs.python.org Mon Jun 4 03:41:46 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 04 Jun 2012 01:41:46 +0000 Subject: [issue14996] pthon 3.2.3 freezes when saving a .py program In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338774106.82.0.998212054654.issue14996@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: We need more information to be able to help. What platform and OS version are you running on? Where did you install Python 3.2.3 from? Exactly what happens when you try to save a file, i.e. are you using a mouse or a keyboard accelerator, what messages do you see, etc? ---------- nosy: +ned.deily _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Mon Jun 4 05:01:54 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Jun 2012 03:01:54 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338778914.21.0.974819979395.issue12510@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: i12510.test.diff (for Python 3 only) does the following: * Turn method CallTips.get_entity into a module function as it does not use the self parameter and is therefore not really an instance method. * Delete the erroneous _find_constructor function. Even if it were fixed, it is unnecessary at least in 3.x. Class attribute lookup already does the superclass search duplicated in this function and should find object.__init__ if nothing else. (I defaulted to None anyway in case of an unforeseen problem, such as a type subclass that somehow disables the lookup.) * In get_argspec, remove the lambda stuff that resulted in all classes getting a spurious '()' line. With the fix to retrieving .__init__, it never gets used and is not needed anyway. * Only delete 'self' from the argument list for classes and bound methods where it is implicit and not to be explicity entered. * Increase tests from 13 to 37. * Modernize and re-organize tests with an eye to becoming part of an idlelib test suite. With the increased number of tests, I am pretty confident in the patch, but I would not mind if you glance at it and try it out on Linux. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file25814/i12510.test.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Mon Jun 4 05:32:16 2012 From: report at bugs.python.org (Shawn Brown) Date: Mon, 04 Jun 2012 03:32:16 +0000 Subject: [issue14998] pprint._safe_key is not always safe enough Message-ID: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za> New submission from Shawn Brown <03sjbrown at gmail.com>: This is related to resolved issue 3976 and, to a lesser extent, issue 10017. I've run across another instance where pprint throws an exception (but works fine in 2.7 and earlier): Python 3.2 (r32:88445, Mar 25 2011, 19:28:28) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from pprint import pprint >>> pprint({(0,): 1, (None,): 2}) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.2/pprint.py", line 55, in pprint printer.pprint(object) File "/usr/lib/python3.2/pprint.py", line 132, in pprint self._format(object, self._stream, 0, 0, {}, 0) File "/usr/lib/python3.2/pprint.py", line 155, in _format rep = self._repr(object, context, level - 1) File "/usr/lib/python3.2/pprint.py", line 245, in _repr self._depth, level) File "/usr/lib/python3.2/pprint.py", line 257, in format return _safe_repr(object, context, maxlevels, level) File "/usr/lib/python3.2/pprint.py", line 299, in _safe_repr items = sorted(object.items(), key=_safe_tuple) File "/usr/lib/python3.2/pprint.py", line 89, in __lt__ rv = self.obj.__lt__(other.obj) TypeError: unorderable types: int() < NoneType() The above example might seem contrived but I stumbled across the issue quite naturally. Honest! In working with multiple lists and computing results using combinations of these lists' values. I _could_ organize the results as a dictionary of dictionaries of dictionaries but that would get confusing very quickly. Instead, I'm using a single dictionary with a composite key ("flat is better than nested"). So I've got code like this... >>> combinations = itertools.product(lst_x, lst_y, lst_z) >>> results = {(x,y,z): compute(x,y,z) for x,y,z in combinations} ... and it is not uncommon for one or more of the values to be None -- resulting in the above exception should anyone (including unittest) attempt to pprint the dictionary. ---------- components: Library (Lib) messages: 162249 nosy: Shawn.Brown priority: normal severity: normal status: open title: pprint._safe_key is not always safe enough versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14998> _______________________________________ From report at bugs.python.org Mon Jun 4 06:59:38 2012 From: report at bugs.python.org (Shawn Brown) Date: Mon, 04 Jun 2012 04:59:38 +0000 Subject: [issue14998] pprint._safe_key is not always safe enough In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za> Message-ID: <1338785978.19.0.656229805184.issue14998@psf.upfronthosting.co.za> Shawn Brown <03sjbrown at gmail.com> added the comment: Currently, I'm monkey patching _safe_key (adding a try/except) as follows: >>> import pprint >>> >>> class _safe_key(pprint._safe_key): >>> def __lt__(self, other): >>> try: >>> rv = self.obj.__lt__(other.obj) >>> except TypeError: # Exception instead of TypeError? >>> rv = NotImplemented >>> >>> if rv is NotImplemented: >>> rv = (str(type(self.obj)), id(self.obj)) < \ >>> (str(type(other.obj)), id(other.obj)) >>> return rv >>> >>> pprint._safe_key = _safe_key >>> >>> pprint.pprint({(0,): 1, (None,): 2}) {(None,): 2, (0,): 1} ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14998> _______________________________________ From report at bugs.python.org Mon Jun 4 07:50:05 2012 From: report at bugs.python.org (Timothy Pederick) Date: Mon, 04 Jun 2012 05:50:05 +0000 Subject: [issue14999] ctypes ArgumentError lists arguments from 1, not 0 Message-ID: <1338789005.54.0.744601187049.issue14999@psf.upfronthosting.co.za> New submission from Timothy Pederick <pederick at gmail.com>: The ctypes ArgumentError exception indicates the location of the problem by argument number. It counts arguments starting from 1, not 0 as is typical in Python. Observed -------- An example (anonymised) traceback: Traceback (most recent call last): ... foreign_function(a, b, c, d) ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type The error here was with the argument "b". Expected -------- Standard, zero-indexed Python counting would suggest that argument 2 should mean "c", and "b" would be argument 1. Rationale --------- This may be as intended, but for me it violates the principle of least surprise. I *think* this is the vicinity of the bug: http://hg.python.org/cpython/file/696d3631a4a1/Modules/_ctypes/callproc.c#l1103 _ctypes_extend_error(PyExc_ArgError, "argument %d: ", i+1); If I'm right and the "i+1" (here and/or in subsequent lines) is the cause, that definitely makes it look intentional. ---------- components: ctypes messages: 162251 nosy: perey priority: normal severity: normal status: open title: ctypes ArgumentError lists arguments from 1, not 0 type: behavior versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14999> _______________________________________ From report at bugs.python.org Mon Jun 4 08:46:20 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jun 2012 06:46:20 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> Message-ID: <1338792380.14.0.818397700618.issue14993@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Mon Jun 4 09:01:19 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 04 Jun 2012 07:01:19 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> Message-ID: <1338793279.76.0.659266612733.issue14993@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Compilation with gcc -std=c89 is not supported. Just drop this option. While Python strives to use C89, we will not distort to meet some abstract language compliance goal. OTOH, I fail to see why they need to be bitfields: a plain unsigned char field should work as well (as would an int bitfield). Victor? ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Mon Jun 4 09:05:38 2012 From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Malo?=) Date: Mon, 04 Jun 2012 07:05:38 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> Message-ID: <1338793538.14.0.42620278429.issue14993@psf.upfronthosting.co.za> Andr? Malo <nd at perlig.de> added the comment: I'm not talking about compiling python but my extension module. I *do* try supporting c89. Also relying on implementation extensions is bad style. I think, there's a huge difference between public header files (standards are good) and linked C code (do whatever you like, although standards are good here as well). OTOH, is there a real difference between char:1 and int:1? That's what we're actually discussing here. If not, I suggest simply using int:1 and be done with it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Mon Jun 4 09:37:50 2012 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 04 Jun 2012 07:37:50 +0000 Subject: [issue14998] pprint._safe_key is not always safe enough In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za> Message-ID: <1338795470.81.0.950929125698.issue14998@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- nosy: +flox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14998> _______________________________________ From report at bugs.python.org Mon Jun 4 10:42:56 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 04 Jun 2012 08:42:56 +0000 Subject: [issue11959] smtpd cannot be used without affecting global state In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za> Message-ID: <1338799376.62.0.688539412121.issue11959@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: ---------- hgrepos: +129 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11959> _______________________________________ From report at bugs.python.org Mon Jun 4 10:43:42 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 04 Jun 2012 08:43:42 +0000 Subject: [issue11959] smtpd cannot be used without affecting global state In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za> Message-ID: <1338799422.66.0.482111439336.issue11959@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: ---------- keywords: +patch Added file: http://bugs.python.org/file25815/fa55dc894947.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11959> _______________________________________ From report at bugs.python.org Mon Jun 4 10:54:05 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 04 Jun 2012 08:54:05 +0000 Subject: [issue11959] smtpd cannot be used without affecting global state In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za> Message-ID: <1338800045.56.0.439946034379.issue11959@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: ---------- assignee: -> vinay.sajip stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11959> _______________________________________ From report at bugs.python.org Mon Jun 4 12:27:37 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jun 2012 10:27:37 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1338805657.87.0.386530300081.issue13598@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Added a new patch which addresses ?ric's comments. ---------- Added file: http://bugs.python.org/file25816/issue13598.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Mon Jun 4 12:28:40 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jun 2012 10:28:40 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1338805720.86.0.608300947627.issue13598@psf.upfronthosting.co.za> Changes by Ramchandra Apte <maniandram01 at gmail.com>: Added file: http://bugs.python.org/file25817/test_string.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Mon Jun 4 13:10:40 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jun 2012 11:10:40 +0000 Subject: [issue14996] IDLE in Python 3.2.3 freezes when saving a .py program In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338808240.65.0.611739768663.issue14996@psf.upfronthosting.co.za> Changes by Ramchandra Apte <maniandram01 at gmail.com>: ---------- title: pthon 3.2.3 freezes when saving a .py program -> IDLE in Python 3.2.3 freezes when saving a .py program _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Mon Jun 4 13:13:11 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jun 2012 11:13:11 +0000 Subject: [issue14996] IDLE in Python 3.2.3 freezes when saving a .py program In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338808391.37.0.93893589592.issue14996@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Can you run IDLE from the cmd line and send the output of the cmd line when it crashes? ---------- nosy: +ramchandra.apte _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Mon Jun 4 13:19:41 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jun 2012 11:19:41 +0000 Subject: [issue14997] Syntax Error in Python Version Number In-Reply-To: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za> Message-ID: <1338808781.81.0.586189152649.issue14997@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Can you please run IDLE from the cmd line and send the output of it in the cmd line. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14997> _______________________________________ From report at bugs.python.org Mon Jun 4 13:32:33 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Mon, 04 Jun 2012 11:32:33 +0000 Subject: [issue14996] pthon 3.2.3 freezes when saving a .py program In-Reply-To: <1338774106.82.0.998212054654.issue14996@psf.upfronthosting.co.za> Message-ID: <CACPbxaMEfc_ffxpojg0jXtJ_h+MT-46j7fpYiN9FMW9UoD8TiQ@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: I am running python in Windows 7, I installed python from python.org. I tried both of the following with the same results Python 3.2.3 Windows x86 MSI Installer<http://www.python.org/ftp/python/3.2.3/python-3.2.3.msi>(Windows binary -- does not include source) Python 3.2.3 Windows X86-64 MSI Installer<http://www.python.org/ftp/python/3.2.3/python-3.2.3.amd64.msi>(Windows AMD64 / Intel 64 / X86-64 binary [1] <http://www.python.org/download/#id10> -- does not include source) Cannot save any file. Maureen Cuomo On Sun, Jun 3, 2012 at 9:41 PM, Ned Deily <report at bugs.python.org> wrote: > > Ned Deily <nad at acm.org> added the comment: > > We need more information to be able to help. What platform and OS version > are you running on? Where did you install Python 3.2.3 from? Exactly what > happens when you try to save a file, i.e. are you using a mouse or a > keyboard accelerator, what messages do you see, etc? > > ---------- > nosy: +ned.deily > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- title: IDLE in Python 3.2.3 freezes when saving a .py program -> pthon 3.2.3 freezes when saving a .py program _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Mon Jun 4 13:52:18 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jun 2012 11:52:18 +0000 Subject: [issue14996] Python 3.2.3 freezes when saving a .py program In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338810738.93.0.635589066181.issue14996@psf.upfronthosting.co.za> Changes by Ramchandra Apte <maniandram01 at gmail.com>: ---------- title: pthon 3.2.3 freezes when saving a .py program -> Python 3.2.3 freezes when saving a .py program _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Mon Jun 4 14:20:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jun 2012 12:20:19 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <E1SbWGf-0005hP-9f@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 6808a72fc9ec by Hynek Schlawack in branch 'default': #14814: Use correct comparison for IP addresses http://hg.python.org/cpython/rev/6808a72fc9ec ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 4 15:46:22 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jun 2012 13:46:22 +0000 Subject: [issue14215] http://www.python.org/dev/peps/ title is python.org In-Reply-To: <1331102600.96.0.801989456091.issue14215@psf.upfronthosting.co.za> Message-ID: <1338817582.21.0.694135281516.issue14215@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: What it the status of this bug? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14215> _______________________________________ From report at bugs.python.org Mon Jun 4 15:50:22 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jun 2012 13:50:22 +0000 Subject: [issue14215] http://www.python.org/dev/peps/ title is python.org In-Reply-To: <1331102600.96.0.801989456091.issue14215@psf.upfronthosting.co.za> Message-ID: <1338817822.52.0.0153801184722.issue14215@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Presumably the PEP 0 generator needs a patch, but that's not something most of us ever touch. I've added Nick to nosy, I think he made changes to it last. ---------- nosy: +ncoghlan, r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14215> _______________________________________ From report at bugs.python.org Mon Jun 4 15:52:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jun 2012 13:52:07 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <E1SbXhQ-0006P7-GG@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 9c445f4695c1 by Barry Warsaw in branch 'default': Eric Snow's implementation of PEP 421. http://hg.python.org/cpython/rev/9c445f4695c1 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14673> _______________________________________ From report at bugs.python.org Mon Jun 4 15:55:21 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 04 Jun 2012 13:55:21 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338818121.48.0.0971072777174.issue14673@psf.upfronthosting.co.za> Barry A. Warsaw <barry at python.org> added the comment: I'm resolving this as Fixed since I've just committed the code to 3.3, but I'm also leaving its status open and assigning it to mvl for verification of the Windows build. Martin, if you'd rather not do that, please unassign it from yourself. I've also added Brian to the nosy list. ---------- assignee: -> loewis nosy: +brian.curtin resolution: -> fixed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14673> _______________________________________ From report at bugs.python.org Mon Jun 4 17:11:32 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 04 Jun 2012 15:11:32 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1338822692.27.0.146815911081.issue14908@psf.upfronthosting.co.za> Changes by Barry A. Warsaw <barry at python.org>: ---------- nosy: +barry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 17:15:05 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 04 Jun 2012 15:15:05 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1338822905.28.0.894328001441.issue14908@psf.upfronthosting.co.za> Barry A. Warsaw <barry at python.org> added the comment: I completely agree. As easy (but obscure) as it is, it seems quite silly to have to go through time.mktime(dt.timetuple()) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 17:20:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 04 Jun 2012 15:20:38 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338823238.93.0.890061818308.issue7559@psf.upfronthosting.co.za> Chris Jerdonek <chris.jerdonek at gmail.com> added the comment: Because we don't know if the rest of the test code will adhere to this, we might want to consider clearing the cache before each test as well. Alternatively, we could avoid having to call importlib.invalidate_caches() at all (and having to think about for which tests it is necessary) if we do each test in a different directory and with a different name for the test package. We could do the former as follows: with support.temp_cwd(support.TESTFN): dir_name = self.id().split('.')[-1] # test method name with support.temp_cwd(dir_name) as cwd: with support.DirsOnSysPath(cwd): # Create package and run test. An approach like this might be less prone to issues that are hard to troubleshoot. I verified that it works. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7559> _______________________________________ From report at bugs.python.org Mon Jun 4 17:32:14 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jun 2012 15:32:14 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338823934.14.0.314039600192.issue7559@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: That would probably be OK, but I don't see why clearing the cache in those same methods (that create directories on the path) would be any harder. (It isn't necessary to clear the cache *afterward*, only before, as far as I can see, since the case of a directory not existing that the cache thinks exists should be handled correctly by importlib). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7559> _______________________________________ From report at bugs.python.org Mon Jun 4 17:45:15 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 04 Jun 2012 15:45:15 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338824715.4.0.896327430839.issue7559@psf.upfronthosting.co.za> Chris Jerdonek <chris.jerdonek at gmail.com> added the comment: That sounds fine. I just got the sense from above that there was a desire to call invalidate_caches() as few times as possible. And yes, I agree only before is necessary. I had just taken what you said above literally (that "[the cache] should be reset by tests that change what's on the path"), thinking that you wanted to maintain the principle that tests should leave things as they were at the beginning. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7559> _______________________________________ From report at bugs.python.org Mon Jun 4 17:45:40 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 04 Jun 2012 15:45:40 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1338824740.64.0.750076471873.issue14908@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Barry, Did you review the long discussion under issue 2736? Specifically, please note the part about mxDateTime, ticks() and gmticks(). I am -0 on adding ticks() and gmticks() and as far as I can tell no one has implemented these methods for datetime without introducing some subtle bugs. I also suspect that those who ask for a timestamp() method expect that it will do more than EPOCH = datetime(1970, 1, 1) def timestamp(t): return (t - EPOCH).total_seconds() For example, account for leap seconds or magically guess the DST offset. If we introduce a method that implements the code above, we have to prepare to explain why it does not do those things. If instead we introduce a shortcut for time.mktime(t.timetuple()), we will have to deal with the fact that mktime() behaves differently on different systems. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 17:57:42 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 04 Jun 2012 15:57:42 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1338824740.64.0.750076471873.issue14908@psf.upfronthosting.co.za> Message-ID: <20120604115734.5d567c58@resist.wooz.org> Barry A. Warsaw <barry at python.org> added the comment: On Jun 04, 2012, at 03:45 PM, Alexander Belopolsky wrote: >Did you review the long discussion under issue 2736? Specifically, please >note the part about mxDateTime, ticks() and gmticks(). I am -0 on adding >ticks() and gmticks() and as far as I can tell no one has implemented these >methods for datetime without introducing some subtle bugs. I skimmed it, but I don't have time to read the whole bug. I'll note that I've recently had to convert a bunch of code from using mxDateTime to datetime+time, for the only reason that we had to support Python 3 and mxDT isn't yet ported. >I also suspect that those who ask for a timestamp() method expect that it >will do more than > >EPOCH = datetime(1970, 1, 1) >def timestamp(t): > return (t - EPOCH).total_seconds() Not really. >For example, account for leap seconds or magically guess the DST offset. If >we introduce a method that implements the code above, we have to prepare to >explain why it does not do those things. That's fine, explain away! >If instead we introduce a shortcut for time.mktime(t.timetuple()), we will >have to deal with the fact that mktime() behaves differently on different >systems. Not really. If developers even care, they will know that the epoch is different for different systems. We don't have to deal with it, we just have to mention it. Let them use more verbose "correct" code if they care. Seriously, we should not over-engineer this. It's purely a more discoverable convenience and I think implementing the moral equivalent to time.mktime(t.timetuple()) is exactly the right thing to do. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 18:03:34 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 04 Jun 2012 16:03:34 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <20120604115734.5d567c58@resist.wooz.org> Message-ID: <CAP7h-xZkz7KSU01J5_kYLYThoSdM9dDDiUzi5efxht=4R9J20w@mail.gmail.com> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: On Mon, Jun 4, 2012 at 11:57 AM, Barry A. Warsaw <report at bugs.python.org> wrote: > I've recently had to convert a bunch of code from using mxDateTime to > datetime+time, That's a valuable experience. How big of a deal was the lack of .ticks() and .gmticks()? How did you work around it? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 18:12:44 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 04 Jun 2012 16:12:44 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <CAP7h-xZkz7KSU01J5_kYLYThoSdM9dDDiUzi5efxht=4R9J20w@mail.gmail.com> Message-ID: <20120604121234.25889a57@limelight.wooz.org> Barry A. Warsaw <barry at python.org> added the comment: On Jun 04, 2012, at 04:03 PM, Alexander Belopolsky wrote: >That's a valuable experience. How big of a deal was the lack of >.ticks() and .gmticks()? How did you work around it? It was *much* less of an issue than all the magic date format parsing that mxDT supports. That's actually something that I think is a more serious deficiency, since .strptime() is pretty limited (e.g. how would you parse ISO 8601 dates both with and without the 'T'?). A Python 3 compatible time format parser would make for a very nice separate library (PyPI) and/or addition to the stdlib (eventually). FWIW, here's the changeset. http://bazaar.launchpad.net/~gwibber-committers/gwibber/trunk/revision/1354 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 18:15:47 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 Jun 2012 16:15:47 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1338826547.72.0.427978392465.issue14626@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Second pass at my patch. Incorporates suggestions from Serhiy's review--thanks, Serhiy! Still not ready for checkin. > 80 col lines, no docs, docstrings are messy. But code is ready for (further) review. Code passes regression test suite without errors. ---------- Added file: http://bugs.python.org/file25818/larry.os.keyword.arguments.collapse.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Mon Jun 4 18:20:26 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jun 2012 16:20:26 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1338826826.13.0.0492484534992.issue7559@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Ah, yes, I wasn't clear. Sorry. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7559> _______________________________________ From report at bugs.python.org Mon Jun 4 18:24:22 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jun 2012 16:24:22 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1338827062.21.0.0956466561316.issue14908@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 18:34:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jun 2012 16:34:58 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <E1SbaF6-0007fT-GR@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset df6d1a4d83fa by Hynek Schlawack in branch 'default': #14814: Remove dead code from ipaddress http://hg.python.org/cpython/rev/df6d1a4d83fa ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 4 18:52:49 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jun 2012 16:52:49 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1338826547.72.0.427978392465.issue14626@psf.upfronthosting.co.za> Message-ID: <201206041952.34716.storchaka@gmail.com> Serhiy Storchaka <storchaka at gmail.com> added the comment: Well, I'm going to ignore the long lines and documentation. The patch is really big and impressive. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Mon Jun 4 18:54:25 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 Jun 2012 16:54:25 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1338828865.08.0.175157591327.issue14626@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I'm not sure that "long" and "impressive" are words that go together when describing a patch ;-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Mon Jun 4 19:13:16 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jun 2012 17:13:16 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1338829996.24.0.67303749212.issue13959@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Need to update the docstrings for imp.find_module() and load_module() to mention the functions are deprecated since there is no specific raised deprecation, only documented deprecation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Mon Jun 4 19:17:59 2012 From: report at bugs.python.org (cuulblu) Date: Mon, 04 Jun 2012 17:17:59 +0000 Subject: [issue14997] Syntax Error in Python Version Number In-Reply-To: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za> Message-ID: <1338830279.39.0.642801288285.issue14997@psf.upfronthosting.co.za> cuulblu <ken at fivefingerdesigns.com> added the comment: "Can you please run IDLE from the cmd line and send the output of it in the cmd line." How do I do that? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14997> _______________________________________ From report at bugs.python.org Mon Jun 4 19:33:09 2012 From: report at bugs.python.org (Alexandre Zani) Date: Mon, 04 Jun 2012 17:33:09 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1338831189.04.0.931111112346.issue14908@psf.upfronthosting.co.za> Alexandre Zani <alexandre.zani at gmail.com> added the comment: I think the easiest and most intuitive approach is to simply define timestamp() as being the reverse of fromtimestamp(). Don't worry about leap seconds and all that stuff. If non-1970 epochs are a concern, this could be renamed to posix_timestamp or some such with perhaps a generic timestamp function that takes both a time and epoch. But let's not let such a useful function not happen just because it won't solve everyone's problem. ---------- nosy: +Alexandre.Zani _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 19:35:03 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 04 Jun 2012 17:35:03 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338831303.26.0.960415235854.issue14673@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: The Windows buildbots were failing compilation. I've added Object/namespaceobject.c and Include/namespaceobject.h to PCbuild/pythoncore.vcxproj in changeset ee7cd7d51ed6. ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14673> _______________________________________ From report at bugs.python.org Mon Jun 4 19:45:52 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 04 Jun 2012 17:45:52 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1338831189.04.0.931111112346.issue14908@psf.upfronthosting.co.za> Message-ID: <CAP7h-xbVbVSNPxdtYd-dxmsTjEwa6bGgqb8cxQKS6MVoUU-g3g@mail.gmail.com> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: On Mon, Jun 4, 2012 at 1:33 PM, Alexandre Zani <report at bugs.python.org> wrote: > I think the easiest and most intuitive approach is to simply define timestamp() > as being the reverse of fromtimestamp(). I would like to invite everyone to review the discussion leading to closing of issue 2736. We cannot implement "the reverse of fromtimestamp()" because fromtimestamp() is not reversible in presence of DST and because float cannot represent all values that datetime supports. Both issues can be resolved, but I did not see any solution that I would call intuitive. Is anyone motivated enough to port mxDT's ticks() method to datetime? I don't think we need to reinvent the wheel. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 20:07:37 2012 From: report at bugs.python.org (Mike Frysinger) Date: Mon, 04 Jun 2012 18:07:37 +0000 Subject: [issue15000] posixsubprocess module broken on x32 Message-ID: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> New submission from Mike Frysinger <vapier at users.sourceforge.net>: the direct call to the getdents syscall is broken on x32. there, the first two args are not unsigned long, but unsigned long long. patch attached to fix the issue. ---------- components: Extension Modules files: python-3.2.3-x32.patch keywords: patch messages: 162281 nosy: vapier priority: normal severity: normal status: open title: posixsubprocess module broken on x32 versions: Python 3.2 Added file: http://bugs.python.org/file25819/python-3.2.3-x32.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Mon Jun 4 21:21:24 2012 From: report at bugs.python.org (Alexandre Zani) Date: Mon, 04 Jun 2012 19:21:24 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1338837684.51.0.0473623533288.issue14908@psf.upfronthosting.co.za> Alexandre Zani <alexandre.zani at gmail.com> added the comment: I'm still reading through the issue you mentioned. (It's a painful read I have to admit) One major obstacle seems to be that during the DST switch over, an hour gets repeated and so the datetime object is ambiguous. (are you on the first or second hour?) I would argue that it isn't a problem that this function needs to solve. The ambiguity isn't tied to the conversion. It's tied to the datetime object itself. Let's add an optional parameter to specify the DST status, doc the pitfall and not worry overmuch about it. Side note: Let me know if I misunderstood Alexander, but if I didn't this should be documented with the datetime object. Based upon my understanding, the datetime object is a bad choice if you care about that ambiguity. That's not really clear. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 21:26:52 2012 From: report at bugs.python.org (Daniel Urban) Date: Mon, 04 Jun 2012 19:26:52 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1338838012.72.0.11388935946.issue14965@psf.upfronthosting.co.za> Daniel Urban <urban.dani+py at gmail.com> added the comment: I'm attaching a patch implementing super.__setattr__ (and __delattr__). The implementation in the patch only works, if super can find a data descriptor in the MRO, otherwise it throws an AttributeError. As it can be seen in the tests, in some cases this may result in counter-intuitive behaviour. But I wasn't able to find another behaviour, that is consistent with both super.__getattr__ and normal __setattr__ semantics. ---------- keywords: +patch nosy: +daniel.urban Added file: http://bugs.python.org/file25820/super_setattr.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14965> _______________________________________ From report at bugs.python.org Mon Jun 4 21:27:15 2012 From: report at bugs.python.org (Daniel Urban) Date: Mon, 04 Jun 2012 19:27:15 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1338838035.71.0.930764832778.issue14965@psf.upfronthosting.co.za> Changes by Daniel Urban <urban.dani+py at gmail.com>: ---------- components: +Extension Modules -Library (Lib) _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14965> _______________________________________ From report at bugs.python.org Mon Jun 4 21:49:25 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 04 Jun 2012 19:49:25 +0000 Subject: [issue15001] segmentation fault with del sys.module['__main__'] Message-ID: <1338839365.76.0.631007627601.issue15001@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>: This simple script segfaults the interpreter (all versions), at least when run with "./python myscript.py" myscript.py:: import sys del sys.module['__main__'] ---------- messages: 162284 nosy: amaury.forgeotdarc priority: normal severity: normal status: open title: segmentation fault with del sys.module['__main__'] type: crash versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15001> _______________________________________ From report at bugs.python.org Mon Jun 4 21:54:12 2012 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 04 Jun 2012 19:54:12 +0000 Subject: [issue15001] segmentation fault with del sys.module['__main__'] In-Reply-To: <1338839365.76.0.631007627601.issue15001@psf.upfronthosting.co.za> Message-ID: <1338839652.07.0.00634013188056.issue15001@psf.upfronthosting.co.za> Changes by Alex Gaynor <alex.gaynor at gmail.com>: ---------- nosy: +alex _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15001> _______________________________________ From report at bugs.python.org Mon Jun 4 21:56:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jun 2012 19:56:31 +0000 Subject: [issue8739] Update to smtpd.py to RFC 5321 In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za> Message-ID: <E1SbdO8-0003Xj-8a@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 079c1942eedf by R David Murray in branch 'default': #8739: fix omission of DEBUGSTREAM reset in new test in test_smtpd. http://hg.python.org/cpython/rev/079c1942eedf ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8739> _______________________________________ From report at bugs.python.org Mon Jun 4 21:59:29 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 04 Jun 2012 19:59:29 +0000 Subject: [issue15001] segmentation fault with del sys.module['__main__'] In-Reply-To: <1338839365.76.0.631007627601.issue15001@psf.upfronthosting.co.za> Message-ID: <1338839969.28.0.372560289882.issue15001@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15001> _______________________________________ From report at bugs.python.org Mon Jun 4 22:06:59 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 04 Jun 2012 20:06:59 +0000 Subject: [issue15001] segmentation fault with del sys.module['__main__'] In-Reply-To: <1338839365.76.0.631007627601.issue15001@psf.upfronthosting.co.za> Message-ID: <1338840419.83.0.686817911081.issue15001@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Many paths in pythonrun.c contains these lines: m = PyImport_AddModule("__main__"); d = PyModule_GetDict(m); both return borrowed references, from sys.modules. in most cases, d is simply passed to PyEval_EvalCode() and not used afterwards, *except* in PyRun_SimpleFileExFlags which calls PyDict_DelItemString(d, "__file__"); this is where the crash occurs. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15001> _______________________________________ From report at bugs.python.org Mon Jun 4 22:14:41 2012 From: report at bugs.python.org (sspapilin) Date: Mon, 04 Jun 2012 20:14:41 +0000 Subject: [issue15002] urllib2 does not download 4 MB file fully using ftp Message-ID: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> New submission from sspapilin <sspapilin at gmail.com>: File test.py is #!/usr/bin/env python import urllib2 print urllib2.urlopen('ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest').read() When I issue python test.py > out.txt , I get file about 100KB in size, the beginning of the actual file. I repeated it a hundred times, and almost every time I get 98305 byte file, and a couple of times a 49153 bytes or 188417 bytes file. When I replace urllib2 with urllib in test.py, I get full (4 MB) file. I have Ubuntu 12.04 64-bit, Python 2.7.3 (from default Ubuntu repository, up-to-date as of 4-june-2012) and slow, 64KB/s, Internet connection. However, I asked my friend with Windows and faster connection to check it, and he got partial download as well, while he had another size of partial file (50109 bytes). I do not know his OS ant Python versions. ---------- components: Library (Lib) files: test.py messages: 162287 nosy: sspapilin priority: normal severity: normal status: open title: urllib2 does not download 4 MB file fully using ftp type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25821/test.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15002> _______________________________________ From report at bugs.python.org Mon Jun 4 22:17:36 2012 From: report at bugs.python.org (sspapilin) Date: Mon, 04 Jun 2012 20:17:36 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1338841056.99.0.950935072019.issue15002@psf.upfronthosting.co.za> Changes by sspapilin <sspapilin at gmail.com>: ---------- title: urllib2 does not download 4 MB file fully using ftp -> urllib2 does not download 4 MB file completely using ftp _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15002> _______________________________________ From report at bugs.python.org Mon Jun 4 22:20:46 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 04 Jun 2012 20:20:46 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1338837684.51.0.0473623533288.issue14908@psf.upfronthosting.co.za> Message-ID: <CAP7h-xb8kRn82zjbSD7JYNJX53KpjTqi-g3dsW0pShqOLjN7Fw@mail.gmail.com> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: On Mon, Jun 4, 2012 at 3:21 PM, Alexandre Zani <report at bugs.python.org> wrote: > Let me know if I misunderstood Alexander, but if I didn't this should be documented with > the datetime object. Based upon my understanding, the datetime object is a bad choice > if you care about that ambiguity. That's not really clear. The datetime object is neither good nor bad if you want to deal with the DST ambiguity. If you want to store times as local time, the best practice is to include the UTC offset. The datetime module now provides the facilities to do so. If you neglect the timezone and deal with naive datetime objects instead, you should probably avoid mixing it with POSIX timestamps in the same application. Here is an example where naive datetime is quite appropriate: a timekeeping application for a small business with a single location. If you need to generate opening hours for a given week, [datetime(y,m,d, 9, 0) + datetime(i) for i in range(5)] is an adequate solution, but if you compare it to [datetime.fromtimestamp(x + 24*3600*i) for i in range(5)], you may be off by one hour if your week spans the DST change. In most applications, however, keeping local time without UTC offset is a bad choice. POSIX's timestamp only advantage is that it does no allow keeping local time at all. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Mon Jun 4 22:23:15 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 04 Jun 2012 20:23:15 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338841395.2.0.374637450046.issue14673@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I think Richard fixed it already, thanks. ---------- assignee: loewis -> status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14673> _______________________________________ From report at bugs.python.org Mon Jun 4 22:39:06 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 04 Jun 2012 20:39:06 +0000 Subject: [issue14996] Python 3.2.3 freezes when saving a .py program In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338842346.88.0.70358081288.issue14996@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: It is still difficult to understand what problem you are seeing as others are using IDLE from the 3.2.3 installers on Windows 7. There is at least one open issue in this area on Windows: http://bugs.python.org/issue12988. Does that describe what you are seeing? If now, a few things to check: if you get to the Save dialog, try choosing another folder to save to, ilke Desktop; also, try a simple file name with ".py" at the end. If that doesn't help, please give a step-by-step procedure to reproduce the problem, including what you see on the screen. ---------- components: +Windows _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Mon Jun 4 22:54:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jun 2012 20:54:12 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> Message-ID: <E1SbeHz-0001AQ-0O@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 09736ae1c314 by Victor Stinner in branch 'default': Issue #14993: Use standard "unsigned char" instead of a unsigned char bitfield http://hg.python.org/cpython/rev/09736ae1c314 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Mon Jun 4 22:58:18 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 20:58:18 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> Message-ID: <1338843498.84.0.868030393233.issue14993@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: > OTOH, I fail to see why they need to be bitfields: a plain > unsigned char field should work as well (as would an int bitfield). Victor? I chose a bitfield to have a more compact structure. I didn't know that a bitfield using unsigned char is a GCC extension: it compiles on Visual Studio 2008, isn't it? The size of _PyUnicodeWriter doesn't really matter, so I replace the two fields with simple types. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Mon Jun 4 22:58:47 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 04 Jun 2012 20:58:47 +0000 Subject: [issue14996] Python 3.2.3 freezes when saving a .py program In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338843527.06.0.479815225275.issue14996@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Also, you could try temporarily renaming the .idlerc folder in your User folder; this is where IDLE stores several configuration files which can be a cause of problems if they have incorrect values. And you could also try to run IDLE from the Python command line. Launch Python 3.2 -> Python (command line), then in the interactive interpreter enter: import idlelib.PyShell idlelib.PyShell.main() Additional error messages may show up in the command line window. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Mon Jun 4 22:58:50 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 20:58:50 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> Message-ID: <1338843530.22.0.160869025392.issue14993@psf.upfronthosting.co.za> Changes by STINNER Victor <victor.stinner at gmail.com>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Mon Jun 4 23:02:26 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 04 Jun 2012 21:02:26 +0000 Subject: [issue14997] Syntax Error in Python Version Number In-Reply-To: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za> Message-ID: <1338843746.84.0.854602674083.issue14997@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Try launching Python 2.7 -> Python (command line), then in the interactive interpreter enter: import idlelib.PyShell idlelib.PyShell.main() Additional error messages may show up in the command line window. But also try renaming or deleting the .idlerc folder in your User folder. You may have an IDLE configuration file with an unexpected value. ---------- nosy: +ned.deily _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14997> _______________________________________ From report at bugs.python.org Mon Jun 4 23:11:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 04 Jun 2012 21:11:05 +0000 Subject: [issue14907] SSL module cannot handle unicode filenames In-Reply-To: <1337928550.27.0.394572153469.issue14907@psf.upfronthosting.co.za> Message-ID: <1338844265.71.0.216990284459.issue14907@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I'm closing it as won't fix. I don't think it needs to be documented, but I won't mind if it is. ---------- nosy: +loewis resolution: -> wont fix status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14907> _______________________________________ From report at bugs.python.org Mon Jun 4 23:11:21 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 04 Jun 2012 21:11:21 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1338844281.96.0.318570258887.issue9998@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: I added an updated patch which uses ld, and added a test (Linux/Unix only). ---------- hgrepos: +130 stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9998> _______________________________________ From report at bugs.python.org Mon Jun 4 23:12:15 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 04 Jun 2012 21:12:15 +0000 Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za> Message-ID: <1338844335.42.0.759104284586.issue9998@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: Added file: http://bugs.python.org/file25822/ce3be1c1091a.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9998> _______________________________________ From report at bugs.python.org Mon Jun 4 23:14:08 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jun 2012 21:14:08 +0000 Subject: [issue14998] pprint._safe_key is not always safe enough In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za> Message-ID: <1338844448.96.0.498631671739.issue14998@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +rhettinger stage: -> needs patch type: -> behavior versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14998> _______________________________________ From report at bugs.python.org Mon Jun 4 23:16:44 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jun 2012 21:16:44 +0000 Subject: [issue14989] http.server option to run CGIHTTPRequestHandler In-Reply-To: <1338710584.57.0.336351054508.issue14989@psf.upfronthosting.co.za> Message-ID: <1338844604.54.0.852240954077.issue14989@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14989> _______________________________________ From report at bugs.python.org Mon Jun 4 23:39:47 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 04 Jun 2012 21:39:47 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1338845987.21.0.413226537952.issue14673@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: presumably PEP 421 can be marked as final now? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14673> _______________________________________ From report at bugs.python.org Mon Jun 4 23:44:52 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 04 Jun 2012 21:44:52 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za> Message-ID: <1338846292.77.0.441185672975.issue14993@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I don't think the change had any effect on memory consumption: because of alignment, padding is inserted either way to fill the flags to four (32-bit) or eight bytes. So with the bit field, there were 7 bytes of padding on 64-bit systems, and now there are only 6 bytes of padding. Yes, Visual C also supports the same extension. See the "Microsoft specific" section in http://msdn.microsoft.com/en-us/library/yszfawxh(v=vs.80).aspx ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Mon Jun 4 23:49:58 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 04 Jun 2012 21:49:58 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1338845987.21.0.413226537952.issue14673@psf.upfronthosting.co.za> Message-ID: <20120604174953.27098ce8@resist.wooz.org> Barry A. Warsaw <barry at python.org> added the comment: On Jun 04, 2012, at 09:39 PM, Eric Snow wrote: >presumably PEP 421 can be marked as final now? Done. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14673> _______________________________________ From report at bugs.python.org Mon Jun 4 23:55:36 2012 From: report at bugs.python.org (Catalin Iacob) Date: Mon, 04 Jun 2012 21:55:36 +0000 Subject: [issue8745] zipimport is a bit slow In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za> Message-ID: <1338846936.98.0.829441125171.issue8745@psf.upfronthosting.co.za> Catalin Iacob <iacobcatalin at gmail.com> added the comment: I updated Goplat's patch to the default branch. It now needs to read 4 dummy bytes instead of 6 since an extra PyMarshal_ReadShortFromFile was added to the default branch in the mean time. I added an explicit dummy buffer instead of reading the dummy bytes into name (for cleanness and because name would overflow on hypothetical platforms where MAXPATHLEN + 5 < 8). Also added tests for the loop that skips the rest of the header by creating some zips with file comments; without the extra test, commenting out the loop didn't fail test_zipimport. Running Goplat's test in msg106191 on Windows I get 0.032 sec before and 0.015 sec after. On Linux I see no significant difference. AFAIK Mercurial (for example) ships with a zipped stdlib on Windows and they care quite a lot about startup time. Can this make it into 3.3? ---------- nosy: +catalin.iacob versions: +Python 3.3 -Python 3.2 Added file: http://bugs.python.org/file25823/zipimport_speedup-v2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8745> _______________________________________ From report at bugs.python.org Tue Jun 5 00:02:35 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jun 2012 22:02:35 +0000 Subject: [issue15000] posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338847355.03.0.172592169229.issue15000@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +gregory.p.smith _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 00:03:34 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 04 Jun 2012 22:03:34 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1338847414.51.0.669551642305.issue14814@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Dear friends of ip addresses, I made something: refactor dup code, minor janitoring, bump coverage - remove duplicate netmask/hostmask code (it was identical in ipv4address & interface) - make two ifs more pythonic - Refactor and fix packed property for ipv6 addresses and networks. Apparently nobody has ever used this. :) - Test coverage is now at 97%, the rest are mostly unreachable safeguards. Please have a look at it if you will. The test suite passes of course. That said, I'm pretty sure the constructor for IPv6Network is broken (particularly constructing from int and packed ? also the the strict tests in these two cases don't make any sense as net mask is always ALL_ONES). I'll be dreaming of ip addresses tonight. ;) ---------- Added file: http://bugs.python.org/file25824/ipaddress-refactor-and-bump-coverage.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Tue Jun 5 00:54:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 22:54:07 +0000 Subject: [issue14993] GCC error when using unicodeobject.h In-Reply-To: <1338846292.77.0.441185672975.issue14993@psf.upfronthosting.co.za> Message-ID: <CAMpsgwZSNO1XazcrumtK=jT8m+hnSSveNakq9OQiSbP3eeQayA@mail.gmail.com> STINNER Victor <victor.stinner at gmail.com> added the comment: > I don't think the change had any effect on memory consumption: because of alignment, padding is inserted either way to fill the flags to four (32-bit) or eight bytes. So with the bit field, there were 7 bytes of padding on 64-bit systems, and now there are only 6 bytes of padding. Oh, interesting information. I forgot the alignment thing. > Yes, Visual C also supports the same extension. See the "Microsoft specific" section in > http://msdn.microsoft.com/en-us/library/yszfawxh(v=vs.80).aspx Oh, what is the "C" language nowadays?... ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14993> _______________________________________ From report at bugs.python.org Tue Jun 5 00:55:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 22:55:25 +0000 Subject: [issue15001] segmentation fault with del sys.module['__main__'] In-Reply-To: <1338839365.76.0.631007627601.issue15001@psf.upfronthosting.co.za> Message-ID: <1338850525.57.0.709549596985.issue15001@psf.upfronthosting.co.za> Changes by STINNER Victor <victor.stinner at gmail.com>: ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15001> _______________________________________ From report at bugs.python.org Tue Jun 5 01:06:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 23:06:02 +0000 Subject: [issue14990] detect_encoding should fail with SyntaxError on invalid encoding In-Reply-To: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za> Message-ID: <1338851162.37.0.105160227229.issue14990@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: The patch is correct according to the PEP 263: If a source file uses both the UTF-8 BOM mark signature and a magic encoding comment, the only allowed encoding for the comment is 'utf-8'. Any other encoding will cause an error. The fix should also be applied to 3.2. (Note: Python 3.1 doesn't accept bugfixes anymore.) ---------- components: +Unicode nosy: +ezio.melotti, haypo versions: -Python 3.1 Added file: http://bugs.python.org/file25825/detect_encoding.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14990> _______________________________________ From report at bugs.python.org Tue Jun 5 01:08:34 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 23:08:34 +0000 Subject: [issue14904] test_unicode_repr_oflw (in test_bigmem) crashes In-Reply-To: <1337903212.58.0.439916347295.issue14904@psf.upfronthosting.co.za> Message-ID: <1338851314.36.0.413520933655.issue14904@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: > Someone needs to debug this (someone with enough RAM). I tried to reproduce the bug, but I got a bug in my filesystem :-p A memory allocation failed in the kernel and btrfs didn't handle it correctly. 12 GB of RAM (and no swap) is maybe not enough. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14904> _______________________________________ From report at bugs.python.org Tue Jun 5 01:09:51 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 23:09:51 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1338851391.47.0.878766695172.issue14428@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: I'm closing again this issue. @neologix: Please open a new issue if you disagree with me on the definition of "seconds" for time.process_time(). ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14428> _______________________________________ From report at bugs.python.org Tue Jun 5 01:20:08 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 04 Jun 2012 23:20:08 +0000 Subject: [issue14805] Support display of both __cause__ and __context__ In-Reply-To: <1336996839.56.0.43377861765.issue14805@psf.upfronthosting.co.za> Message-ID: <1338852008.84.0.431918231378.issue14805@psf.upfronthosting.co.za> Changes by Meador Inge <meadori at gmail.com>: ---------- nosy: +meador.inge _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14805> _______________________________________ From report at bugs.python.org Tue Jun 5 01:24:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 23:24:22 +0000 Subject: [issue14711] Remove os.stat_float_times In-Reply-To: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> Message-ID: <1338852262.69.0.903380545829.issue14711@psf.upfronthosting.co.za> Changes by STINNER Victor <victor.stinner at gmail.com>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14711> _______________________________________ From report at bugs.python.org Tue Jun 5 01:32:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jun 2012 23:32:10 +0000 Subject: [issue14711] Remove os.stat_float_times In-Reply-To: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> Message-ID: <E1Sbgkq-0006mT-Ei@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 7cb15b47c70e by Victor Stinner in branch 'default': Issue #14711: os.stat_float_times() has been deprecated. http://hg.python.org/cpython/rev/7cb15b47c70e ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14711> _______________________________________ From report at bugs.python.org Tue Jun 5 01:37:39 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 23:37:39 +0000 Subject: [issue6745] (curses) addstr() takes str in Python 3 In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za> Message-ID: <1338853059.34.0.937320159164.issue6745@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: The issue #12567 fixed this one: - umlaut3x.py now works in Python 3.3 with an encoding different than UTF-8: Python automatically detects (and uses) the locale encoding - getkey_sample.py can be patched to handle Unicode correctly using get_wch() instead of getkey() ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6745> _______________________________________ From report at bugs.python.org Tue Jun 5 01:38:54 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 04 Jun 2012 23:38:54 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1338853134.26.0.82050979003.issue14814@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Hynek's latest patch mostly looks good to me, but I think the "packed" property on network definitions just needs to go away. The original ipaddr API that is the basis for ipaddress doesn't really have a clear distinction between network definitions and IP addresses, and I think the current network code is still showing some of the legacies of that. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Tue Jun 5 01:42:00 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 04 Jun 2012 23:42:00 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1338853320.25.0.406843080392.issue14814@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Also noting a TODO item here: currently, the address-producing operations on network objects just produce vanilla address objects of the appropriate version. My question is, should we have those operations create interface objects instead? My current thought is that the latter would lose less information, since you can easily strip the network details later if desired. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Tue Jun 5 01:42:33 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 04 Jun 2012 23:42:33 +0000 Subject: [issue15000] posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338853353.98.0.284820140883.issue15000@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: What is x32? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 01:47:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jun 2012 23:47:22 +0000 Subject: [issue11022] locale.getpreferredencoding() must not set temporary LC_CTYPE In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za> Message-ID: <1338853642.87.0.888466622638.issue11022@psf.upfronthosting.co.za> Changes by STINNER Victor <victor.stinner at gmail.com>: ---------- title: locale.setlocale() doesn't change I/O codec, os.environ does -> locale.getpreferredencoding() must not set temporary LC_CTYPE _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11022> _______________________________________ From report at bugs.python.org Tue Jun 5 01:53:53 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Mon, 04 Jun 2012 23:53:53 +0000 Subject: [issue14996] Python 3.2.3 freezes when saving a .py program In-Reply-To: <1338842346.88.0.70358081288.issue14996@psf.upfronthosting.co.za> Message-ID: <CACPbxaN=N8qNjwOktUEuywxjK0SRKBEZxcYkEPK2jArBm7nV0Q@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: Yes it looks like that. I Open a new window in python, type into the new window. I try to save it so I can run the program and I get the twirling circle until the dialog box come up saying pythow.exe has stopped working. Maureen Cuomo On Mon, Jun 4, 2012 at 4:39 PM, Ned Deily <report at bugs.python.org> wrote: > > Ned Deily <nad at acm.org> added the comment: > > It is still difficult to understand what problem you are seeing as others > are using IDLE from the 3.2.3 installers on Windows 7. There is at least > one open issue in this area on Windows: http://bugs.python.org/issue12988. > Does that describe what you are seeing? If now, a few things to check: if > you get to the Save dialog, try choosing another folder to save to, ilke > Desktop; also, try a simple file name with ".py" at the end. If that > doesn't help, please give a step-by-step procedure to reproduce the > problem, including what you see on the screen. > > ---------- > components: +Windows > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 01:54:04 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 04 Jun 2012 23:54:04 +0000 Subject: [issue15000] posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338854044.64.0.297765415297.issue15000@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: Answering my own question I believe x32 is the new ABI being worked on as described in http://lwn.net/Articles/456731/. In that light, your patch makes sense assuming the __ILP32__ define is something gcc's cpp will always be defining when targeting x32. I will apply it. ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 01:58:54 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 04 Jun 2012 23:58:54 +0000 Subject: [issue15000] posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338854334.46.0.122317457615.issue15000@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: for reference - https://sites.google.com/site/x32abi/ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 02:00:22 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Tue, 05 Jun 2012 00:00:22 +0000 Subject: [issue14996] Python 3.2.3 freezes when saving a .py program In-Reply-To: <CACPbxaN=N8qNjwOktUEuywxjK0SRKBEZxcYkEPK2jArBm7nV0Q@mail.gmail.com> Message-ID: <CACPbxaO0AP104R+hhgJqg9i73oq3SKpnpqmRdrocyYXUqtGUUg@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: I can save to the desktop, but nowhere else. Will this be fixed? I teach python at my school and next year all my computers will have windows 7. I also have a program called deep freeze that erases any files saved on a computer including the desktop. This prevents viruses. Mareen Cuomo On Mon, Jun 4, 2012 at 7:53 PM, Maureen Cuomo <report at bugs.python.org>wrote: > > Maureen Cuomo <mcuomo at prestonhs.org> added the comment: > > Yes it looks like that. I Open a new window in python, type into the new > window. I try to save it so I can run the program and I get the twirling > circle until the dialog box come up saying pythow.exe has stopped working. > Maureen Cuomo > > On Mon, Jun 4, 2012 at 4:39 PM, Ned Deily <report at bugs.python.org> wrote: > > > > > Ned Deily <nad at acm.org> added the comment: > > > > It is still difficult to understand what problem you are seeing as others > > are using IDLE from the 3.2.3 installers on Windows 7. There is at least > > one open issue in this area on Windows: > http://bugs.python.org/issue12988. > > Does that describe what you are seeing? If now, a few things to check: > if > > you get to the Save dialog, try choosing another folder to save to, ilke > > Desktop; also, try a simple file name with ".py" at the end. If that > > doesn't help, please give a step-by-step procedure to reproduce the > > problem, including what you see on the screen. > > > > ---------- > > components: +Windows > > > > _______________________________________ > > Python tracker <report at bugs.python.org> > > <http://bugs.python.org/issue14996> > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 02:33:16 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Jun 2012 00:33:16 +0000 Subject: [issue14996] Python 3.2.3 freezes when saving a .py program In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338856396.64.0.580464283141.issue14996@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Windows experts: any suggestions here? ---------- nosy: +brian.curtin, loewis, terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 02:34:18 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Jun 2012 00:34:18 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338856458.71.0.547220741482.issue14996@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: ---------- title: Python 3.2.3 freezes when saving a .py program -> IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 03:28:13 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 05 Jun 2012 01:28:13 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1338859693.45.0.169663010472.issue14908@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Barry, I looked at your changeset at http://bazaar.launchpad.net/~gwibber-committers/gwibber/trunk/revision/1354 and at the specification at http://developers.facebook.com/docs/reference/api/event/. Am I correct that you are parsing "string containing an ISO-8601 formatted date/time or a UNIX timestamp; if it contains a time zone (not recommended), it will be converted to Pacific time before being stored and displayed"? If so, it looks like converting input to POSIX timestamps is the wrong thing to do because users who specify naive time expect it to be displayed without conversion. The way I read the specs, a better implementation would store input in naive datetime objects, converting UNIX timestamps or TZ-aware strings to Pacific timezone. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Tue Jun 5 03:35:58 2012 From: report at bugs.python.org (Mike Frysinger) Date: Tue, 05 Jun 2012 01:35:58 +0000 Subject: [issue15000] posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338860158.97.0.801220129344.issue15000@psf.upfronthosting.co.za> Mike Frysinger <vapier at users.sourceforge.net> added the comment: $ echo | gcc -m32 -E -P -dD - | grep LP <nothing> $ echo | gcc -m64 -E -P -dD - | grep LP #define _LP64 1 #define __LP64__ 1 $ echo | gcc -mx32 -E -P -dD - | grep LP #define _ILP32 1 #define __ILP32__ 1 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 03:57:30 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jun 2012 01:57:30 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338861450.5.0.708824816166.issue14996@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Maureen, I have saved and run a file from the Idle editor perhaps a thousand times over the years with multiple Python versions, including 3.2.3 (retried just now) on both Windows XP and Win7. (Note: on the General tab of the Preferences dialog, one can make saving automatic for named files.) Like many others, I have had no problems, so there is something peculiar about your system or installation. For us to be of any help, please provide the information Ned already requested. 1. Start "Python (command line)" from Start/3.2 menu. 2. Enter "from idlelib import idle" to start Idle. 3. Either open a new or existing file and make a change. 4. Try to save and tell us *exactly* the directory you are in and the filename you enter. 5. If Idle closes, does it just go 'poof' or is there a Windows error message box? 6. If there is a box, what does it say? 7. If there is a traceback, copy *all* of it and paste into a message here. If you have to do anything different than the above to get an error, please be specific. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 04:17:41 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Jun 2012 02:17:41 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1338862661.53.0.404245713302.issue15002@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: The same problem exists in Python3. ---------- nosy: +orsenthil, r.david.murray stage: -> needs patch versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15002> _______________________________________ From report at bugs.python.org Tue Jun 5 04:22:08 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 05 Jun 2012 02:22:08 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1338862928.53.0.373437910778.issue15002@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: That's surprising! I shall test it with http debug mode and see what's happening. ---------- assignee: -> orsenthil _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15002> _______________________________________ From report at bugs.python.org Tue Jun 5 04:30:35 2012 From: report at bugs.python.org (Mike Perry) Date: Tue, 05 Jun 2012 02:30:35 +0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error In-Reply-To: <1338149431.79.0.453915882533.issue1028@psf.upfronthosting.co.za> Message-ID: <CAGZBjRX+7RPXszDCwYB27onqeB6P0yirbeH_Me19MDUwm5_XGg@mail.gmail.com> Mike Perry <mike at cogsmos.com> added the comment: Looking good in 3.2.3! Tested on Debian Wheezy using packages python3-tk 3.2.3-1 and idle3 3.2.3~rc1-2. /* ?* Mike Perry ?* mike at cogs....com ?*/ On Sun, May 27, 2012 at 4:10 PM, Terry J. Reedy <report at bugs.python.org> wrote: > > Terry J. Reedy <tjreedy at udel.edu> added the comment: > > On Win 7, a<cntl-space> brings up the box on all the latest releases: 2.7.3, 3.2.3, and 3.3.0a3. (These all come with recent tk 8.5.x.) > > Mike, please retest with 3.2.3 and specify os and tk version and exactly what you entered if there is still a problem. > > ---------- > nosy: +terry.reedy > versions: ?-Python 3.1 > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue1028> > _______________________________________ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1028> _______________________________________ From report at bugs.python.org Tue Jun 5 04:41:45 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 05 Jun 2012 02:41:45 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338864105.79.0.76502173636.issue14996@psf.upfronthosting.co.za> Changes by Roger Serwy <roger.serwy at gmail.com>: ---------- nosy: +serwy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 04:53:40 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 05 Jun 2012 02:53:40 +0000 Subject: [issue15003] make PyNamespace_New() public Message-ID: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> New submission from Eric Snow <ericsnowcurrently at gmail.com>: The type is available as types.SimpleNamespace, and there's no reason to hold PyNamespace_New() back. ---------- components: Library (Lib) messages: 162322 nosy: amaury.forgeotdarc, eric.snow priority: normal severity: normal stage: needs patch status: open title: make PyNamespace_New() public type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Tue Jun 5 04:58:52 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 05 Jun 2012 02:58:52 +0000 Subject: [issue15004] add weakref support to types.SimpleNamespace Message-ID: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za> New submission from Eric Snow <ericsnowcurrently at gmail.com>: Currently types.SimpleNamespace does not support weak references. Amaury asked for this in #14673, but I'd like to see more discussion. What are the use cases for weak references in this case? The type is a simple wrapper around dict, which does not support weak references. In fact most of the builtin types do not support them. However, I freely admit that I haven't used weak references very much and am not familiar with the use cases. ---------- messages: 162323 nosy: amaury.forgeotdarc, eric.snow priority: normal severity: normal stage: needs patch status: open title: add weakref support to types.SimpleNamespace type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15004> _______________________________________ From report at bugs.python.org Tue Jun 5 05:09:21 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 05 Jun 2012 03:09:21 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338865761.05.0.581057142604.issue12510@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: The reoganization in i12510.test.diff will make back-porting to 2.7 slightly more difficult since old and new style classes exist. I do agree with your reasoning for re-factoring the code. (Also, as an extremely minor point, running reindent.py adjusts "pos = 70".) I applied the patch and it works under 11.04 Ubuntu. All the tests pass and the behavior of the CallTip gives reasonable results when used interactively. I did manage to find a corner-case where a CallTip should arise: >>> class A: def __init__(self, a=None): print('init') def __call__(self, b=None): print('call') >>> c = A( Gives "(a=None)" as the call-tip. However, once the object is created, giving the __call__ argument doesn't work, i.e. >>> c( doesn't give a call-tip. This behavior is also the same without the patch. I'll keep playing with the patch to see what else needs improving with CallTips. We might as well fix it completely. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Tue Jun 5 05:35:22 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 Jun 2012 03:35:22 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1338867322.93.0.907347644979.issue15003@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: SimpleNamespaces also need to be picklable. ---------- nosy: +rhettinger _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Tue Jun 5 06:39:18 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 Jun 2012 04:39:18 +0000 Subject: [issue15004] add weakref support to types.SimpleNamespace In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za> Message-ID: <1338871158.59.0.635564695961.issue15004@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: The only reason some of the builtin types don't support weakrefs is to save space. That reason doesn't apply here. Most types should support weakrefs unless there is a compelling reason not to. ---------- nosy: +rhettinger _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15004> _______________________________________ From report at bugs.python.org Tue Jun 5 06:53:51 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Jun 2012 04:53:51 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338872031.45.0.953383864614.issue14996@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Terry, I believe Maureen was confirming that this appeared to be the same problem as documented in Issue12988. So does anyone have any idea what apparently causes this behavior on some systems and not others? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 07:24:24 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 05 Jun 2012 05:24:24 +0000 Subject: [issue15004] add weakref support to types.SimpleNamespace In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za> Message-ID: <1338873864.65.0.616373262944.issue15004@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: That's good enough for me. :) ---------- keywords: +patch Added file: http://bugs.python.org/file25826/issue15004.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15004> _______________________________________ From report at bugs.python.org Tue Jun 5 07:37:23 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 05 Jun 2012 05:37:23 +0000 Subject: [issue11022] locale.getpreferredencoding() must not set temporary LC_CTYPE In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za> Message-ID: <1338874643.0.0.0361940629538.issue11022@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I think it's absolutely necessary that text files, by default, are opened in the encoding of the user's locale, whether the script has called setlocale or not. There are reasons for C to not automatically call setlocale at startup (mostly backwards compatibility), but they don't apply to Python. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11022> _______________________________________ From report at bugs.python.org Tue Jun 5 07:40:12 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 05 Jun 2012 05:40:12 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1338874812.24.0.375854792689.issue15003@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: Patch to make PyNamespace_New() public. ---------- keywords: +patch Added file: http://bugs.python.org/file25827/issue15003_public.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Tue Jun 5 08:14:10 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 05 Jun 2012 06:14:10 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1338876850.94.0.0999139246129.issue15003@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: I'll get a patch up tomorrow to make the type pickleable. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Tue Jun 5 09:01:33 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 05 Jun 2012 07:01:33 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1338851391.47.0.878766695172.issue14428@psf.upfronthosting.co.za> Message-ID: <CAH_1eM1=9gc7+5hfVXbwgpvDp-x4MGnCtSFWsbztejZDk2dNiA@mail.gmail.com> Charles-Fran?ois Natali <neologix at free.fr> added the comment: > I'm closing again this issue. > > @neologix: Please open a new issue if you disagree with me on the definition of "seconds" for time.process_time(). I won't reopen, but I still disagree with your definition. process_time() returns second, as does the Unix 'time' command return: """ $ time sleep 1 real 0m1.014s user 0m0.000s sys 0m0.000s """ AFAICT, process_time() returns user + sys. Since the unit of those two fields are second, the value returned is in second. I doesn't include time spent in 'S'/'D'/whatever time, but it's still seconds. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14428> _______________________________________ From report at bugs.python.org Tue Jun 5 09:37:36 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jun 2012 07:37:36 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338881856.19.0.514775302728.issue14996@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: #12988 was about saving specifically to a Win7 Explorer window sidebar 'library', and the OP report with 3.2.1. This is different from a normal path as you know it. Maureen said she cannot save 'any file' except to desktop and that the behavior changed from 3.2.1 to 3.2.3. Maureen, if you reply by email, PLEASE trim everything except your reply. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 09:55:00 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Tue, 05 Jun 2012 07:55:00 +0000 Subject: [issue13515] Consistent documentation practices for security concerns and considerations In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za> Message-ID: <1338882900.46.0.652246004215.issue13515@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13515> _______________________________________ From report at bugs.python.org Tue Jun 5 11:21:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jun 2012 09:21:08 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338888068.56.0.372797257527.issue12510@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: By 'Python 3 only', I meant that I am not personally planning to backport to 2.7. I do not want to edit the more complicated get_arg_text and consider other issues higher priority. I meant to include a test case for callable instances, but forgot. When I add to test class TC " def __call__(self, ci): "(self, ci)" tc( gives the inherited TC.__doc__ as the tool tip, which in this case happens to by the artificial "(ai=None, *b)". Adding the following to get_argspec: # after current if is...type: fob = ... elif isinstance(ob.__call__, types.MethodType): fob = ob.__call__ & or isinstance(ob.__call__, types.MethodType) # to self-strip conditional, as instance is already typed & if isinstance(ob.__call__, types.MethodType): doc = ob.__call__.__doc__ else: # before current doc = line, which gets indented makes this new test pass. fdoc = tc.__call__.__doc__ test('tc', fdoc + "\n" + fdoc) Revised patch with above attached. Note 1: Programming is more fun with decent tests. Note 2: These non-visual automatic test do not completely substitute for visual testing with the gui. When I first used a broader conditional than the 'elif' above, one that caught list.append and [].append, the tests passed, but typing list.append( resulting in weird behavior: something flashed and the typed text moved down a line. ---------- Added file: http://bugs.python.org/file25828/i12510b.test.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Tue Jun 5 11:40:57 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jun 2012 09:40:57 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338889257.66.0.361240046247.issue12510@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Stephen D'Aprano just asked on Python list how to get signatures of builtins, noting that calling inspect.getargspec on a Python-coded subclass of a builtin class raises an exception. So we need another testcase, verify the behavior, and probably add try-except around the inspect call. (Perhaps inspect.py should be revised to not leak an exception when given the advertised acceptible input, but that is another issue.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Tue Jun 5 11:55:44 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jun 2012 09:55:44 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338890144.15.0.427886213555.issue12510@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Upon further thought, not a problem. Stephen considered the case: class myint(int): # inherit __init__ def added_func(self): "some new function of an int" In this case, fob = myint.__init__ would not be FunctionType and inspect would not be called. Tool tip would be myint.__doc__ and writer could follow style of builtins. Still an interesting test case to add. A different question is whether the default for callables (as opposed to non-callables) should be nothing or something like 'args unknown' or 'see docs'. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Tue Jun 5 11:57:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Jun 2012 09:57:21 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <E1SbqVs-0007b4-BK@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset cca2a1cc9598 by Hynek Schlawack in branch 'default': #14814: ipaddress: refactor dup code, minor janitoring, bump coverage http://hg.python.org/cpython/rev/cca2a1cc9598 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Tue Jun 5 12:04:27 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 05 Jun 2012 10:04:27 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1338890667.27.0.916186933299.issue14814@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: So one more issue from me: as indicated, the constructor using packed of IPv6Networks is broken (wrong indent). The question is whether we want to be able to construct using packed at all. Also the strict check doesn't make any sense because the net mask is ALL_ONES so if the construction of the IPv6Address succeeds, there's no way the check can fail. ---------- Added file: http://bugs.python.org/file25829/ipaddress-ipv6network-constructor.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Tue Jun 5 13:48:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Jun 2012 11:48:17 +0000 Subject: [issue11022] locale.getpreferredencoding() must not set temporary LC_CTYPE In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za> Message-ID: <E1SbsFE-0000xB-2m@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2587328c7c9c by Victor Stinner in branch 'default': Close #11022: TextIOWrapper doesn't call locale.setlocale() anymore http://hg.python.org/cpython/rev/2587328c7c9c ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11022> _______________________________________ From report at bugs.python.org Tue Jun 5 14:02:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Jun 2012 12:02:58 +0000 Subject: [issue6203] 3.x locale does not default to C, contrary to the documentation and to 2.x behavior In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za> Message-ID: <1338897778.85.0.120887008638.issue6203@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: > Either the code is incorrect in 3.1 > or the documentation should be updated. Leaving LC_CTYPE unchanged (use the "C" locale, which is ASCII in most cases) at Python startup would be a major change in Python 3. I don't want to change this. You would see a lot of mojibake in your GUIs and get a lot of ugly surrogate characters in filenames (because of the PEP 393) if we don't set the LC_CTYPE to the user preferred encoding at startup anymore. Setting the LC_CTYPE to the user preferred encoding is just very convinient and helps Python to speak to the user though the console, to the filesystem, to pass arguments on a command line of a subprocess, etc. For example, you cannot pass non-ASCII characters to a subprocess, characters written by the user in your GUI, if your current LC_CTYPE locale is C (ASCII): you get an Unicode encode error. So it's just a documentation issue: see my attached patch. ---------- keywords: +patch Added file: http://bugs.python.org/file25830/locale_doc.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6203> _______________________________________ From report at bugs.python.org Tue Jun 5 14:03:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Jun 2012 12:03:57 +0000 Subject: [issue6203] locale documentation doesn't mention that LC_CTYPE is changed at startup In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za> Message-ID: <1338897837.06.0.25195194629.issue6203@psf.upfronthosting.co.za> Changes by STINNER Victor <victor.stinner at gmail.com>: ---------- components: +Unicode title: 3.x locale does not default to C, contrary to the documentation and to 2.x behavior -> locale documentation doesn't mention that LC_CTYPE is changed at startup versions: +Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6203> _______________________________________ From report at bugs.python.org Tue Jun 5 15:47:44 2012 From: report at bugs.python.org (Alexander O) Date: Tue, 05 Jun 2012 13:47:44 +0000 Subject: [issue4849] instantiating and populating xml.dom.minidom.Element is cumbersome In-Reply-To: <1338613247.1.0.0756391151135.issue4849@psf.upfronthosting.co.za> Message-ID: <CAJo3jRAtnGt0WF10e3seUO+1ZoHWZmbdtJ80r5k6rx=kcf-qjg@mail.gmail.com> Alexander O <alexander at vonoesterreich.com> added the comment: On Jun 2, 2012 7:00 AM, "Alexandre Zani" <report at bugs.python.org> wrote: > > Alexandre Zani <alexandre.zani at gmail.com> added the comment: > > Here is my patch for it. > > ---------- > keywords: +patch > Added file: http://bugs.python.org/file25796/easier_element_init.patch > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue4849> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4849> _______________________________________ From report at bugs.python.org Tue Jun 5 15:51:40 2012 From: report at bugs.python.org (Moritz Klammler) Date: Tue, 05 Jun 2012 13:51:40 +0000 Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb' In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za> Message-ID: <1338904300.69.0.960023694667.issue14156@psf.upfronthosting.co.za> Moritz Klammler <moritz.klammler at gmail.com> added the comment: I don't know how if this is the perfect solution but it keeps the program from crashing. 1154c1154,1157 < return _sys.stdin --- > if 'b' in self._mode: > return _sys.stdin.buffer > else: > return _sys.stdin 1156c1159,1162 < return _sys.stdout --- > if 'b' in self._mode: > return _sys.stdout.buffer > else: > return _sys.stdout ---------- nosy: +moritz type: behavior -> crash versions: +Python 3.2 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14156> _______________________________________ From report at bugs.python.org Tue Jun 5 16:00:45 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 05 Jun 2012 14:00:45 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338904845.42.0.596901375295.issue14996@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Issue12988 only has this problem on 64-bit Win 7. The 32-bit version works correctly. Maureen tried both versions and had the same problem. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Tue Jun 5 16:01:33 2012 From: report at bugs.python.org (Alexis Metaireau) Date: Tue, 05 Jun 2012 14:01:33 +0000 Subject: [issue12354] packaging.pypi.simple docs use both client and crawler name, which might be confusing In-Reply-To: <1338574114.78.0.374893263632.issue12354@psf.upfronthosting.co.za> Message-ID: <4FCE113C.1000304@notmyidea.org> Alexis Metaireau <alexis at notmyidea.org> added the comment: > Alexis, you introduced the client/crawler naming after reading some book; what do you think now? Making the distinction between a crawler and a client is probably not a good idea since it introduces two concepts instead of one simple one. We have indexes and different ways to access them: What about having an "XMLRPCClient" and a "SimpleClient"? In addition, having a simpler API, something like packaging.indexes.get_client('simple' OR 'xmlrpc') can be useful, but that's a different issue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12354> _______________________________________ From report at bugs.python.org Tue Jun 5 16:03:43 2012 From: report at bugs.python.org (Alexis Metaireau) Date: Tue, 05 Jun 2012 14:03:43 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index In-Reply-To: <1338663951.48.0.851216227403.issue14974@psf.upfronthosting.co.za> Message-ID: <4FCE11BE.1000604@notmyidea.org> Alexis Metaireau <alexis at notmyidea.org> added the comment: The problem is that PyPI isn't a good name since it's the name of ONE index. Westley, do you have any other idea? Otherwise, I think we should stick to "index", which is a good name for something that's named "index" quite everywhere already. Especially because it's living under the "packaging" namespace. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14974> _______________________________________ From report at bugs.python.org Tue Jun 5 16:14:14 2012 From: report at bugs.python.org (Alexis Metaireau) Date: Tue, 05 Jun 2012 14:14:14 +0000 Subject: [issue14950] Make packaging.install API less confusing and more extensible In-Reply-To: <1338288446.67.0.0715913421745.issue14950@psf.upfronthosting.co.za> Message-ID: <1338905654.72.0.587729085394.issue14950@psf.upfronthosting.co.za> Alexis Metaireau <alexis at notmyidea.org> added the comment: Attaching a work in progress file which intend to replace the current install.py file. The implementation isn't finished yet but the overall design is here. It comes with four classes: - Installer which manages the overall installation procedure. It shares a distribution cache with the dependency handler so distributions are not downloaded / extracted multiple times. The installer is able to install / remove single distributions OR distributions with their dependency tree. - DependencyHandler which takes care about getting the dependencies from either the metadata stored in the indexes or inside the distirbutions. - The DistributionCache class is just a store containing the location of the distributions that had been extracted/downloaded. It provides methods to ease the work with them (so any external user don't need to care about the state of the distribution when requesting it). - DirectoryMover provides a way to deal with moving/deleting operations with a commit/rollback API. The goal is to simplify a lot the current API and to provide a reusable tool for other installers. why not putting this in shutil at some point. This file is provided here mostly for feedback, but the work is not finished yet. ---------- Added file: http://bugs.python.org/file25831/install.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14950> _______________________________________ From report at bugs.python.org Tue Jun 5 16:14:17 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 05 Jun 2012 14:14:17 +0000 Subject: [issue12354] packaging.pypi.simple docs use both client and crawler name, which might be confusing In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za> Message-ID: <1338905657.58.0.986395205401.issue12354@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: ---------- nosy: -petri.lehtinen _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12354> _______________________________________ From report at bugs.python.org Tue Jun 5 16:40:11 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 05 Jun 2012 14:40:11 +0000 Subject: [issue15005] trace corrupts return result on chained execution Message-ID: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> New submission from anatoly techtonik <techtonik at gmail.com>: This code dumps a lot of internal source code info when executed with trace as: python -m trace --trace file2.py ---[file2.py] import subprocess def ret(): output = subprocess.check_output(['hg', 'id', '-nib']) print( output ) print( output ) print( output.strip() ) print( output.strip().split() ) ret() --- Normally, the last line of the output is: ['e67793ec2995+', '2162+', 'default'] But during trace call it is: ['subprocess.py(1180):', '_dup2(errwrite,', '2)', '---', 'modulename:', 'subprocess,', 'funcname:', '_dup2', 'subprocess.py(1174):', 'if', 'a', '==', 'b:', 'subprocess.py(1176):', 'elif', 'a', 'is', 'not', 'None:', 'subprocess.py(1184):', 'closed', '=', '{', 'None', '}', ... etc. ---------- files: file2.py messages: 162347 nosy: techtonik priority: normal severity: normal status: open title: trace corrupts return result on chained execution versions: Python 2.7 Added file: http://bugs.python.org/file25832/file2.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Tue Jun 5 16:45:24 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 05 Jun 2012 14:45:24 +0000 Subject: [issue15005] trace corrupts return result on chained execution In-Reply-To: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> Message-ID: <1338907524.46.0.638360782651.issue15005@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: The behavior repeats with PyPy 1.8.0, and doesn't repeat with Python 3. ---------- components: +Library (Lib) _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Tue Jun 5 17:03:46 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 05 Jun 2012 15:03:46 +0000 Subject: [issue14989] http.server option to run CGIHTTPRequestHandler In-Reply-To: <1338710584.57.0.336351054508.issue14989@psf.upfronthosting.co.za> Message-ID: <1338908626.13.0.52396141679.issue14989@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: Thanks for sharing your views, ?ric. I guess, RDM has +1 too ( since he closed it). Let this be only in 3.3+ then. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14989> _______________________________________ From report at bugs.python.org Tue Jun 5 17:06:24 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 05 Jun 2012 15:06:24 +0000 Subject: [issue15005] trace corrupts return result on chained execution In-Reply-To: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> Message-ID: <1338908784.79.0.322964436966.issue15005@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Python2 has a pure python implementation of subprocess, with separate calls to fork() and exec(); so the output of the subprocess contains the trace of the forked Python interpreter, until the exec() system call. Python3 has a C implementation: _posixsubprocess.fork_exec() won't call the Python interpreter between fork() and exec(), and no trace is emitted. Yes, Python3 is better :) ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Tue Jun 5 17:18:02 2012 From: report at bugs.python.org (cuulblu) Date: Tue, 05 Jun 2012 15:18:02 +0000 Subject: [issue14997] Syntax Error in Python Version Number In-Reply-To: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za> Message-ID: <1338909482.44.0.276203507799.issue14997@psf.upfronthosting.co.za> cuulblu <ken at fivefingerdesigns.com> added the comment: Ned I entered the commands you gave in the Python (command line). When Idle then opened I put test code in and am still getting the same error message. I deleted the idlerc folder. I am still getting the same error message. To expand on the problem, I get the error message when hitting the F5 key. If I hit Enter, instead of going to a new line it runs the code, but does not produce an error message. I get the same results on all three machines mentioned in my original post. I have also installed on an older XP machine, which produces the same results. It really makes no sense to me how 4 computers can all have the same issue. (Wanders off looking for the nearest wall) I downloaded the software from this website. I have tried both 32 bit and 64 bit versions. Currently the 64 bit versions are installed on the 64 bit machines. I hope to find a solution for this soon as I am getting behind on homework. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14997> _______________________________________ From report at bugs.python.org Tue Jun 5 17:34:15 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 05 Jun 2012 15:34:15 +0000 Subject: [issue15005] trace corrupts return result on chained execution In-Reply-To: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> Message-ID: <1338910455.5.0.697908645167.issue15005@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: OMG. =) Is it possible to fix it somehow? Postpone output collection until the very exec() call? Or provide a different stream for collecting output? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Tue Jun 5 18:03:35 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 05 Jun 2012 16:03:35 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338912215.29.0.240832535541.issue12510@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Callable instances now return a call tip. Good! I agree with your analysis of the issue raised by Stephen. The get_argspec function will not fail unexpectedly. > but typing list.append( resulting in weird behavior: something flashed and the typed text moved down a line. I get "L.append(object) -> None -- append object to end" as the call tip on Linux. I'm not sure why it didn't work on Win 7. Could an unintentional enter key-press be the culprit? > A different question is whether the default for callables (as opposed to non-callables) should be nothing or something like 'args unknown' or 'see docs'. I agree that if the argspec string has no contents after all the code in get_argspec, then it should have a message added. Perhaps the following would be sufficient: if hasattr(ob, '__call__'): [truncated] if not argspec: argspec += "Arguments unknown. See docs." return argspec ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Tue Jun 5 18:09:09 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 05 Jun 2012 16:09:09 +0000 Subject: [issue15005] trace corrupts return result on chained execution In-Reply-To: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> Message-ID: <1338912549.75.0.0107469940236.issue15005@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: It's not possible to delay output collection: output starts being collected just after the call os.dup2(cp2write, 1) and before exec(), we need to os.close it. The trace module will already have emitted some lines. Process output by definition goes to the C stdout, but you could redirect sys.stdout (the Python one, used by print) to something else, like a StringIO so that trace.py does not pollute the subprocess output. In 3.2, suprocess.py states that the pure Python implementation (the one use in 2.7) is not thread safe. We could add that it's not reentrant or trace-friendly as well... this is not surprising IMO. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Tue Jun 5 18:24:07 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Jun 2012 16:24:07 +0000 Subject: [issue6203] locale documentation doesn't mention that LC_CTYPE is changed at startup In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za> Message-ID: <1338913447.08.0.290480355981.issue6203@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: LGTM ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6203> _______________________________________ From report at bugs.python.org Tue Jun 5 18:30:41 2012 From: report at bugs.python.org (John Ehresman) Date: Tue, 05 Jun 2012 16:30:41 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1338913841.75.0.266894877531.issue13959@psf.upfronthosting.co.za> John Ehresman <jpe at wingware.com> added the comment: This may be a known problem, but imp.load_module fails when trying to load a C extension. This is with the 3.3a4 release on Windows, though I suspect the problem is cross-platform. ---------- nosy: +jpe _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Tue Jun 5 18:32:41 2012 From: report at bugs.python.org (Chris Rebert) Date: Tue, 05 Jun 2012 16:32:41 +0000 Subject: [issue14966] Fully document subprocess.CalledProcessError In-Reply-To: <1338446762.96.0.360332771622.issue14966@psf.upfronthosting.co.za> Message-ID: <1338913961.15.0.204899024983.issue14966@psf.upfronthosting.co.za> Changes by Chris Rebert <pybugs at rebertia.com>: ---------- nosy: +cvrebert _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14966> _______________________________________ From report at bugs.python.org Tue Jun 5 19:08:56 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jun 2012 17:08:56 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1338916136.25.0.844778100561.issue13959@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Does it work in Python 3.2, John? If it does then it's just an oversight thanks to the lack of tests in test_imp and it shouldn't be too difficult to support. But do realize I have deprecated the function. =) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Tue Jun 5 19:13:36 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Jun 2012 17:13:36 +0000 Subject: [issue14997] IDLE tries to run shell window if line is completed with F5 rather than Enter In-Reply-To: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za> Message-ID: <1338916416.0.0.856150382863.issue14997@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Thanks for the additional information; it's now clear what's going on. IDLE has two kinds of windows where code can be entered. When you launch IDLE, by default it opens with its shell window. This window is similar to running the Python interpreter in interactive mode, i.e. you can type in lines of Python code that are immediately executed and whose results are displayed. The other kind of window is an IDLE editor window in which you can edit a file containing Python code (either a new file or by opening an existing file). When you are ready to run the code in the selected editor window (there may be multiple ones open), you either use the Run menu command or its accelerator shortcut, F5. The results of running the file are also displayed in the IDLE shell window. What seems to be happening here is that, if are you in the shell window and enter some text and press F5 rather than return/enter to complete the line, IDLE mistakenly treats the shell window as if it were an editor window and prompts you to save and then tries to run the contents of the shell window. It shouldn't let you do that. Thanks for bringing that error to our attention! ---------- stage: -> needs patch title: Syntax Error in Python Version Number -> IDLE tries to run shell window if line is completed with F5 rather than Enter type: compile error -> behavior versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14997> _______________________________________ From report at bugs.python.org Tue Jun 5 19:28:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Jun 2012 17:28:52 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1338917332.98.0.852708135164.issue14428@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I don't know what you two are arguing about, since the process_time() doc says "Return the value (in fractional seconds) of the sum of the system and user CPU time of the current process". (while I'm not sure what "fractional" seconds are, they are probably seconds in the first place :-)) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14428> _______________________________________ From report at bugs.python.org Tue Jun 5 19:43:32 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 05 Jun 2012 17:43:32 +0000 Subject: [issue14997] IDLE tries to run shell window if line is completed with F5 rather than Enter In-Reply-To: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za> Message-ID: <1338918212.93.0.861125968408.issue14997@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: The ScriptBinding extension is enabled for the shell. If the shell is in a modified state, then pressing F5 will bring up the save dialog (or auto-save), and then perform a syntax check. This is what cuublu experienced. Attached is a patch against 3.3a4 to disable ScriptBinding in the shell window. The patch is identical for 2.7 branch. ---------- keywords: +patch nosy: +serwy Added file: http://bugs.python.org/file25833/issue14997.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14997> _______________________________________ From report at bugs.python.org Tue Jun 5 19:46:01 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 05 Jun 2012 17:46:01 +0000 Subject: [issue15005] trace corrupts return result on chained execution In-Reply-To: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> Message-ID: <1338918361.35.0.162083341204.issue15005@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: Is it possible to pause trace and resume after the exec call? Between some missing instructions from subprocess internals and traceability of the Python programs I'd choose the latter. It can be even more actual for people tracing program execution in the process of porting to Python 3. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Tue Jun 5 20:05:46 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 05 Jun 2012 18:05:46 +0000 Subject: [issue15005] trace corrupts return result on chained execution In-Reply-To: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> Message-ID: <1338919546.32.0.066820383042.issue15005@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Sure, just save/restore the trace function around your calls to subprocess. But I fail to see how a Python2-only issue can affect a Python3 port. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Tue Jun 5 20:49:04 2012 From: report at bugs.python.org (Marc Schlaich) Date: Tue, 05 Jun 2012 18:49:04 +0000 Subject: [issue14907] SSL module cannot handle unicode filenames In-Reply-To: <1337928550.27.0.394572153469.issue14907@psf.upfronthosting.co.za> Message-ID: <1338922144.87.0.745800251474.issue14907@psf.upfronthosting.co.za> Marc Schlaich <marc.schlaich at googlemail.com> added the comment: Well, the Unicode HOWTO states: When opening a file for reading or writing, you can usually just provide the Unicode string as the filename, and it will be automatically converted to the right encoding for you This is really an unexpected behavior which could be easily missed by a test case so I would really vote for making this clear in the documentation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14907> _______________________________________ From report at bugs.python.org Tue Jun 5 20:49:10 2012 From: report at bugs.python.org (John Ehresman) Date: Tue, 05 Jun 2012 18:49:10 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1338916136.25.0.844778100561.issue13959@psf.upfronthosting.co.za> Message-ID: <4FCE549C.8000605@wingware.com> John Ehresman <jpe at wingware.com> added the comment: On 6/5/12 1:08 PM, Brett Cannon wrote: > > Brett Cannon<brett at python.org> added the comment: > > Does it work in Python 3.2, John? If it does then it's just an oversight thanks to the lack of tests in test_imp and it shouldn't be too difficult to support. > > But do realize I have deprecated the function. =) Attached is a short test file to demonstrate this. It assumes the standard win32 layout, but shouldn't be hard to modify. It does work in Python 3.2, but the else: clause in 3.3's imp.load_module function raises an ImportError. I think the fix is to add an elif C_EXTENSION: clause that loads the .so / .pyd. I've already rewritten my code to use importlib when running in Python 3.3. ---------- Added file: http://bugs.python.org/file25834/imptest.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ -------------- next part -------------- import imp import importlib import sys dirname = r'c:\Python33\dlls' name = '_bz2' assert name not in sys.modules use_imp = True if use_imp: fp, pathname, description = imp.find_module(name, [dirname]) mod = imp.load_module(name, fp, pathname, description) else: loader = importlib.machinery.PathFinder.find_module(name, [dirname]) mod = loader.load_module(name) print (mod) From report at bugs.python.org Tue Jun 5 21:08:02 2012 From: report at bugs.python.org (Marc Schlaich) Date: Tue, 05 Jun 2012 19:08:02 +0000 Subject: [issue14907] SSL module cannot handle unicode filenames In-Reply-To: <1337928550.27.0.394572153469.issue14907@psf.upfronthosting.co.za> Message-ID: <1338923282.15.0.675737699058.issue14907@psf.upfronthosting.co.za> Marc Schlaich <marc.schlaich at googlemail.com> added the comment: For example it is broken in the well known requests library: >>> import requests >>> requests.get('x', cert=u'???.pem') Traceback (most recent call last): File "<stdin>", line 1, in <module> ... UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14907> _______________________________________ From report at bugs.python.org Tue Jun 5 21:09:08 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 05 Jun 2012 19:09:08 +0000 Subject: [issue15000] _posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338923348.72.0.609783075478.issue15000@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever stage: -> patch review title: posixsubprocess module broken on x32 -> _posixsubprocess module broken on x32 versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 21:22:57 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 05 Jun 2012 19:22:57 +0000 Subject: [issue15000] _posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338924177.49.0.636387669333.issue15000@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Would a uint64_t be recommended in this case? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 21:24:15 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 05 Jun 2012 19:24:15 +0000 Subject: [issue11694] xdrlib raises ConversionError in inconsistent way In-Reply-To: <1301224336.99.0.411299821684.issue11694@psf.upfronthosting.co.za> Message-ID: <1338924255.89.0.345479552938.issue11694@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: I see one obvious issue with the patch: The ConversionErrors it creates are passed the struct.error or TypeError instance as a parameter. The first argument of these exceptions would be better, i.e. try: ... except struct.error as e: raise ConversionError(e.args[0]) Furthermore, my ear thinks that raises_conversion_error would be a better name for the decorator than raising_conversion_error. Anyway, I think the whole ConversionError is a bit problematic, as either TypeError or ValueError would be the most appropriate exception, depending on the situation. For example: p = Packer() p.pack_int('foo') # should raise a TypeError p.pack_int(2**100) # should raise a ValueError This would be slightly harder to implement, though, as struct.error has exactly the same problem. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11694> _______________________________________ From report at bugs.python.org Tue Jun 5 21:29:50 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 05 Jun 2012 19:29:50 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects Message-ID: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>: Guido: Let's make it so. / python-dev ---------- components: Extension Modules, Library (Lib) messages: 162368 nosy: belopolsky priority: normal severity: normal status: open title: Allow equality comparison between naive and aware datetime objects type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Tue Jun 5 21:30:15 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 05 Jun 2012 19:30:15 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> Message-ID: <1338924615.16.0.107676085617.issue15006@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- assignee: -> belopolsky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Tue Jun 5 21:34:03 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 05 Jun 2012 19:34:03 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1338924843.99.0.689824294572.issue14908@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- assignee: -> belopolsky nosy: -Alexander.Belopolsky stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Tue Jun 5 21:38:08 2012 From: report at bugs.python.org (Mike Frysinger) Date: Tue, 05 Jun 2012 19:38:08 +0000 Subject: [issue15000] _posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338925088.96.0.389230150049.issue15000@psf.upfronthosting.co.za> Mike Frysinger <vapier at users.sourceforge.net> added the comment: a uint64_t would fix it for x86_64, but break it most 32bit systems as sizeof(unsigned long) == 32bit for them ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 21:39:13 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 05 Jun 2012 19:39:13 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1338925153.55.0.695731371379.issue9527@psf.upfronthosting.co.za> Changes by Barry A. Warsaw <barry at python.org>: ---------- nosy: +barry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Tue Jun 5 22:16:43 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 05 Jun 2012 20:16:43 +0000 Subject: [issue15005] trace corrupts return result on chained execution In-Reply-To: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> Message-ID: <1338927403.92.0.999896336225.issue15005@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: The fix for saving/restoring trace function belong to subprocess module. Python2 only issue will be actual when you have to port Python2 only app where it works ok to the Python3 where it doesn't work even if it executes successfully. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Tue Jun 5 22:30:04 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 05 Jun 2012 20:30:04 +0000 Subject: [issue14059] Implement multiprocessing.Barrier In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za> Message-ID: <1338928204.67.0.687050096542.issue14059@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: The attached patch uses memoryview instead of ctypes. If the patch for Issue #14953 (reimplementing RawArray/RawValue in terms of memoryview) is applied, then it could be simplified a bit. ---------- Added file: http://bugs.python.org/file25835/mp_barrier.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14059> _______________________________________ From report at bugs.python.org Tue Jun 5 22:30:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Jun 2012 20:30:57 +0000 Subject: [issue15000] _posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <E1Sc0P1-0007O3-LL@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset aa9cfeea07ad by Gregory P. Smith in branch '3.2': Fixes issue #15000: support the odd x32 abi on posixsubprocess's system call. http://hg.python.org/cpython/rev/aa9cfeea07ad New changeset 5a4d5e714d08 by Gregory P. Smith in branch 'default': Fixes issue #15000: support the odd x32 abi on posixsubprocess's system call. http://hg.python.org/cpython/rev/5a4d5e714d08 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 22:32:09 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 05 Jun 2012 20:32:09 +0000 Subject: [issue15000] _posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338928329.36.0.734415825393.issue15000@psf.upfronthosting.co.za> Changes by Gregory P. Smith <greg at krypto.org>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 22:37:32 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 05 Jun 2012 20:37:32 +0000 Subject: [issue15000] _posixsubprocess module broken on x32 In-Reply-To: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za> Message-ID: <1338928652.7.0.0992717088058.issue15000@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15000> _______________________________________ From report at bugs.python.org Tue Jun 5 23:06:53 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Jun 2012 21:06:53 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1338930413.48.0.498098797672.issue12510@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: The weird behavior was as if the cursor were moved to the beginning of the line and <Enter> pressed. I cannot duplicate it. I had elif not isinstance(ob, (types.FunctionType, types.MethodType)): instead elif isinstance(ob.__call__, types.MethodType): but something else must have been different, as list.append( works now with above changed back. The tests pass because passing fob to inspect is guarded. But the correct conditional is needed anyway elsewhere in the file. So I will forget this until it happens again ;-). Since we (intend to) inspect all Python-coded callables, and since that returns at least '()' for no args (there is already a test for that), empty callable argspec should only happen for builtin and extension callables with no docstring. I added this code: _default_callable_argspec = "No docstring, see docs." # before get_argspec if not argspec: argspec = _default_callable_argspec I added tests for this and for subclasses of builtins and uploaded a new patch. Can you think of anything else to test? Now that the code and test cases seem about settled, the other (big) change I would like to make is to make most of the tests into proper unittests of get_argspec (which means passing an object, not a string) and some (with some overlap) into unittests of get_entity (passing expression string, getting object). Since rpcclt is None when tests call CallTips.fetch_tip, the method reduces to get_argspec(get_entity(expression)), which just mixes tests of the two functions together. ---------- Added file: http://bugs.python.org/file25836/i12510c.test.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Tue Jun 5 23:20:29 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Jun 2012 21:20:29 +0000 Subject: [issue15007] Unittest CLI does not support test packages very well Message-ID: <1338931229.09.0.80724559879.issue15007@psf.upfronthosting.co.za> New submission from R. David Murray <rdmurray at bitdance.com>: Suppose you have a test package: test_pkg __init__.py test_mytest.py If __init__.py is empty and you run python -m unittest test_pk no tests are found. You can get this to work by adding the following boiler plate to __init__.py: def load_tests(loader, standard_tests, pattern): this_dir = os.path.dirname(__file__) if pattern is None: pattern = "test*" package_tests = loader.discover(start_dir=this_dir, pattern=pattern, top_level_dir=this_dir) standard_tests.addTests(package_tests) return standard_tests Note that top_level_dir is required to handle specifying more than one test package at a time on the unittest command line. Otherwise the second package gets a loader that already has _top_level_dir set, and so it fails to default to start_dir. I suspect this is also a bug. This works; it uses discovery to find the tests and returns them using the load test protocol. Other methods could be used to construct the test to add as well. But all have the serious disadvantage that the package name does not appear in the output. Running the above test_pkg command line give results like this with -v: test_something (test_mytest.Test) ... ok test_pkg is not mentioned. This is merely annoying when running a single test package, but if you do something like: python -m unittest -v test_pkg test_pkg2 You can't tell in the verbose output or the test failure output which test package the tests are from. In summary, unittest needs better support for test packages. ---------- messages: 162374 nosy: michael.foord, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Unittest CLI does not support test packages very well type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15007> _______________________________________ From report at bugs.python.org Tue Jun 5 23:36:51 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 05 Jun 2012 21:36:51 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> Message-ID: <1338932211.09.0.519423683832.issue15006@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- keywords: +patch Added file: http://bugs.python.org/file25837/issue15006.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Tue Jun 5 23:38:54 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 05 Jun 2012 21:38:54 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> Message-ID: <1338932334.7.0.592543656374.issue15006@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- keywords: +needs review nosy: +pitrou stage: -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Wed Jun 6 00:04:35 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 05 Jun 2012 22:04:35 +0000 Subject: [issue15005] trace corrupts return result on chained execution In-Reply-To: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za> Message-ID: <1338933875.39.0.965935415203.issue15005@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Sorry, what does not work in Python3? And how can the trace module help you? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15005> _______________________________________ From report at bugs.python.org Wed Jun 6 00:05:43 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 05 Jun 2012 22:05:43 +0000 Subject: [issue10854] Output .pyd name in error message of ImportError when DLL load fails In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za> Message-ID: <1338933943.0.0.232279419426.issue10854@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: repr() or str() of ImportError doesn't include the 'name' or 'path' members. It would be useful to have them added to the repr if present. ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10854> _______________________________________ From report at bugs.python.org Wed Jun 6 00:06:43 2012 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Jun 2012 22:06:43 +0000 Subject: [issue15008] PEP 362 reference implementation for 3.3 Message-ID: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> New submission from Yury Selivanov <yselivanov at gmail.com>: This issue will track implementation of PEP 362 functionality. ---------- components: Library (Lib) files: pep362.1.patch hgrepos: 131 keywords: patch messages: 162377 nosy: Yury.Selivanov, brett.cannon, larry priority: normal severity: normal status: open title: PEP 362 reference implementation for 3.3 type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25838/pep362.1.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Wed Jun 6 00:12:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Jun 2012 22:12:11 +0000 Subject: [issue14953] Reimplement subset of multiprocessing.sharedctypes using memoryview In-Reply-To: <1338303583.56.0.322806581737.issue14953@psf.upfronthosting.co.za> Message-ID: <1338934331.21.0.153411371945.issue14953@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +neologix, pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14953> _______________________________________ From report at bugs.python.org Wed Jun 6 00:28:27 2012 From: report at bugs.python.org (Buck Golemon) Date: Tue, 05 Jun 2012 22:28:27 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. Message-ID: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> New submission from Buck Golemon <buck at yelp.com>: 1) As long as x is valid, I expect that urlunsplit(urlsplit(x)) == x 2) yelp:///foo is a well-formed (albeit odd) url. It it similar to file:///tmp: it specifies the /foo resource, on the "current" host, using the yelp protocol (defined on mobile devices). >>> from urlparse import urlsplit, urlunsplit >>> urlunsplit(urlsplit('yelp:///foo')) 'yelp:/foo' Urlparse / unparse has the same bug: >>> urlunparse(urlparse('yelp:///foo')) 'yelp:/foo' The file: protocol seems to be special-case, in an inappropriate manner: >>> urlunsplit(urlsplit('file:///tmp')) 'file:///tmp' ---------- components: Library (Lib) messages: 162378 nosy: Buck.Golemon priority: normal severity: normal status: open title: urlsplit can't round-trip relative-host urls. versions: Python 2.6, Python 2.7, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15009> _______________________________________ From report at bugs.python.org Wed Jun 6 00:49:16 2012 From: report at bugs.python.org (Michael Foord) Date: Tue, 05 Jun 2012 22:49:16 +0000 Subject: [issue15007] Unittest CLI does not support test packages very well In-Reply-To: <1338931229.09.0.80724559879.issue15007@psf.upfronthosting.co.za> Message-ID: <1338936556.46.0.867654624624.issue15007@psf.upfronthosting.co.za> Michael Foord <michael at voidspace.org.uk> added the comment: Whilst I agree in principle... The trouble is that when you do this: python -m unittest test_pk What you are saying is "run all the tests from the test_pk module". You *aren't* launching discovery. This should work: python -m unittest discover -t . test_pkg This is more verbose than is ideal. Suggestions for improvements welcome. Having unittest revert to discovery when it is passed a package name that turns out to be empty seems a bit magical (and complex in terms of implementation). Yes, calling loader.discover inside a load_tests function will mutate that loader - so having discover restore _top_level_dir on exit would be better. Can you post that as a separate issue? I think there is a separate issue for improving the test failure name (including module) reporting. I'll try and dig out the issue number. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15007> _______________________________________ From report at bugs.python.org Wed Jun 6 01:39:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Jun 2012 23:39:41 +0000 Subject: [issue6203] locale documentation doesn't mention that LC_CTYPE is changed at startup In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za> Message-ID: <E1Sc3Le-0007TO-Eb@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 113cdce4663c by Victor Stinner in branch 'default': Close #6203: Document that Python 3 sets LC_CTYPE at startup to the user's preferred locale encoding http://hg.python.org/cpython/rev/113cdce4663c ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6203> _______________________________________ From report at bugs.python.org Wed Jun 6 01:43:22 2012 From: report at bugs.python.org (Cameron Simpson) Date: Tue, 05 Jun 2012 23:43:22 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1338939802.24.0.0680177829648.issue9527@psf.upfronthosting.co.za> Changes by Cameron Simpson <cs at zip.com.au>: ---------- nosy: +cameron _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Wed Jun 6 01:53:41 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Jun 2012 23:53:41 +0000 Subject: [issue15001] segmentation fault with del sys.module['__main__'] In-Reply-To: <1338839365.76.0.631007627601.issue15001@psf.upfronthosting.co.za> Message-ID: <1338940421.08.0.453441650883.issue15001@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: Attached patch changes PyRun_SimpleFileExFlags() to keep a reference to the module. ---------- keywords: +patch Added file: http://bugs.python.org/file25839/pyrun_simple.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15001> _______________________________________ From report at bugs.python.org Wed Jun 6 02:03:47 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 06 Jun 2012 00:03:47 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <1338941027.91.0.431928620317.issue14769@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I guess the answer was "no". Attached is a new diff as you suggest. It isn't really any shorter--in fact it's about 20% longer. Though I freely admit it is more written-in-Python-y. The test currently passes. If you add support for a new format unit (like add "case '8':" above "case 'H':" in convertsimple()) without adding the corresponding case to simpleitem(), it fails. If you perform the same operation on simpleitem() but not to convertsimple(), it again fails. So I assert the test is working 100% correctly. ---------- Added file: http://bugs.python.org/file25840/larry.test_skipitem_parity.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14769> _______________________________________ From report at bugs.python.org Wed Jun 6 02:11:34 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Wed, 06 Jun 2012 00:11:34 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338904845.42.0.596901375295.issue14996@psf.upfronthosting.co.za> Message-ID: <CACPbxaOG4eF_pnsX9XD3PV_LPHeKU-XTXu746+K6AH3bCwaiiA@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: I have done some experimenting. I can save a file that I created on another computer any place. It seems the only new files cannot be save in my usual folder. I don't save in pyton32 folder. I have another folder to save in. Maybe this will help Maureen On Tue, Jun 5, 2012 at 10:00 AM, Roger Serwy <report at bugs.python.org> wrote: > > Roger Serwy <roger.serwy at gmail.com> added the comment: > > Issue12988 only has this problem on 64-bit Win 7. The 32-bit version works > correctly. Maureen tried both versions and had the same problem. > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Wed Jun 6 02:15:11 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 06 Jun 2012 00:15:11 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1338941711.44.0.00336906381768.issue13959@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: You're right about the solution, John. I (or someone else) just needs to code it up. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Wed Jun 6 03:08:10 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 06 Jun 2012 01:08:10 +0000 Subject: [issue15001] segmentation fault with del sys.module['__main__'] In-Reply-To: <1338839365.76.0.631007627601.issue15001@psf.upfronthosting.co.za> Message-ID: <1338944890.16.0.284959321029.issue15001@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15001> _______________________________________ From report at bugs.python.org Wed Jun 6 03:15:36 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 01:15:36 +0000 Subject: [issue15007] Unittest CLI does not support test packages very well In-Reply-To: <1338931229.09.0.80724559879.issue15007@psf.upfronthosting.co.za> Message-ID: <1338945336.0.0.232822972471.issue15007@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Right, I'm not wanting to run discovery from the command line, I'm wanting to run the tests in the package by package name. In my mind, this is exactly parallel to specifying a module name and having unittest automatically discover the TestCase classes in it. We don't have unittest run 0 tests because discovery wasn't invoked when the module name was specified. Why should it be different for a test package? If boilerplate is required in __init__.py to make that happen that's OK, though to my mind not ideal. Is there some different magic I can put into __init__.py that will result in the tests in the package being run such that the package name shows up in the report? Without that, specifying a package name on the unittest command line seems pretty useless. (I mean, to get it to do anything useful, you'd have to be putting all the TestCases in the __init__.py, and if you are doing that, why have a package?) The issue about improving the name output was about making it copy and pasteable (something I would also very much like). The naming issue here is different, about how to get the package name to show up in the fully qualified test name. I will open another bug for the _top_level_dir issue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15007> _______________________________________ From report at bugs.python.org Wed Jun 6 03:16:12 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Wed, 06 Jun 2012 01:16:12 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <CACPbxaOG4eF_pnsX9XD3PV_LPHeKU-XTXu746+K6AH3bCwaiiA@mail.gmail.com> Message-ID: <CACPbxaPTzU=vfdxOzdbO4iwdvOo5UjamWNQjnm0MAeEj_vY2Sw@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: I was working on a project and by instinct did a save as with a new name. It worked fine. So just to test things. I closed out of all python files, opened idle, opened a new window, tried to save the new window and the swirling circle came and then the message 'python has stopped working'. Then everything closes. Maybe this will help Maureen On Tue, Jun 5, 2012 at 8:11 PM, Maureen Cuomo <report at bugs.python.org>wrote: > > Maureen Cuomo <mcuomo at prestonhs.org> added the comment: > > I have done some experimenting. I can save a file that I created on another > computer any place. It seems the only new files cannot be save in my usual > folder. I don't save in pyton32 folder. I have another folder to save in. > > Maybe this will help > Maureen > > On Tue, Jun 5, 2012 at 10:00 AM, Roger Serwy <report at bugs.python.org> > wrote: > > > > > Roger Serwy <roger.serwy at gmail.com> added the comment: > > > > Issue12988 only has this problem on 64-bit Win 7. The 32-bit version > works > > correctly. Maureen tried both versions and had the same problem. > > > > ---------- > > > > _______________________________________ > > Python tracker <report at bugs.python.org> > > <http://bugs.python.org/issue14996> > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Wed Jun 6 03:20:43 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 01:20:43 +0000 Subject: [issue15010] unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods Message-ID: <1338945643.44.0.808523506511.issue15010@psf.upfronthosting.co.za> New submission from R. David Murray <rdmurray at bitdance.com>: During the execution of the load tests protocol, the loader instance will set its _top_level_dir attribute, and this will persist if the loader is passed on to another load_tests method. If that method does not specify a top_level_dir in a discovery call, the wrong top_level_dir may be used, and loading will fail. You can reproduce this by having two test *packages* with a load_tests method that calls discover in their __init__.py, and specify both package names to the unittest CLI. ---------- components: Library (Lib) keywords: easy messages: 162387 nosy: michael.foord, r.david.murray priority: normal severity: normal stage: needs patch status: open title: unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15010> _______________________________________ From report at bugs.python.org Wed Jun 6 03:57:39 2012 From: report at bugs.python.org (Alexandre Zani) Date: Wed, 06 Jun 2012 01:57:39 +0000 Subject: [issue15008] PEP 362 reference implementation for 3.3 In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1338947859.37.0.535019619573.issue15008@psf.upfronthosting.co.za> Changes by Alexandre Zani <alexandre.zani at gmail.com>: ---------- nosy: +Alexandre.Zani _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Wed Jun 6 05:01:27 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 06 Jun 2012 03:01:27 +0000 Subject: [issue15008] PEP 362 reference implementation for 3.3 In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1338951687.14.0.0975620116176.issue15008@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Signature and signature are two variable names that differ only in case. To avoid confusion, I recommend one of the names should be changed. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Wed Jun 6 05:04:50 2012 From: report at bugs.python.org (Roger Serwy) Date: Wed, 06 Jun 2012 03:04:50 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1338951890.92.0.861028400157.issue14996@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Maureen, can you please start IDLE from a command prompt and report the error message? Launch a command prompt, enter in "cd c:\python32" and then "python -m idlelib.idle". IDLE should appear. Proceed to save something that causes the crash. You should receive some feedback in the command prompt. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Wed Jun 6 05:12:22 2012 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 06 Jun 2012 03:12:22 +0000 Subject: [issue15008] PEP 362 reference implementation for 3.3 In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1338952342.62.0.177377276432.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: Well, 'Signature' class is unlikely to be used very frequently. So I think it's fine. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Wed Jun 6 05:23:16 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jun 2012 03:23:16 +0000 Subject: [issue15011] Change Scripts to bin on Windows Message-ID: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za> New submission from Brian Curtin <brian at python.org>: Attached is a patch, originally written by Van Lindberg*, which changes Python's layout on Windows to more match all of the other operating systems we support. This patch starts by changing the layout of virtual environments, so the venv module creates an environment with the same layout you'd find on Linux. The most visible change is the Scripts folder becoming bin, and there are changes to capitalization of folders to match that of Linux as well. If this is acceptable I can do the Windows installer change to have the installed layout follow what's in this patch. * Van asked me to take this on for him. I will make sure he has a contributor agreement on file. ---------- components: Library (Lib), Windows files: bin_directory.diff keywords: patch messages: 162391 nosy: brian.curtin, carljm, loewis, vinay.sajip priority: normal severity: normal stage: patch review status: open title: Change Scripts to bin on Windows type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25841/bin_directory.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15011> _______________________________________ From report at bugs.python.org Wed Jun 6 05:43:42 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jun 2012 03:43:42 +0000 Subject: [issue15012] test issue Message-ID: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> New submission from Brian Curtin <brian at python.org>: IGNORE THIS ISSUE This is a test of a newer bitbucket mirror setup by Atlassian. I just want to get a feel for how it works before I post about it on the dev blog. ---------- hgrepos: 132 messages: 162392 nosy: brian.curtin priority: normal severity: normal status: open title: test issue _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15012> _______________________________________ From report at bugs.python.org Wed Jun 6 05:44:15 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jun 2012 03:44:15 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1338954255.28.0.927118305316.issue15012@psf.upfronthosting.co.za> Changes by Brian Curtin <brian at python.org>: ---------- keywords: +patch Added file: http://bugs.python.org/file25842/e48c54fa4bfb.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15012> _______________________________________ From report at bugs.python.org Wed Jun 6 05:45:02 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jun 2012 03:45:02 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1338954302.85.0.322193659164.issue15012@psf.upfronthosting.co.za> Changes by Brian Curtin <brian at python.org>: ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15012> _______________________________________ From report at bugs.python.org Wed Jun 6 05:46:31 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 06 Jun 2012 03:46:31 +0000 Subject: [issue15008] PEP 362 reference implementation for 3.3 In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1338954391.93.0.416471583989.issue15008@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Yes, it seems quite common to me to have a class called Thing and instances named thing. Unless it makes the code wrap better, using real names like signature instead of for example sig is recommended by PEP 8. ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Wed Jun 6 05:47:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 06 Jun 2012 03:47:00 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1338954420.67.0.469433844904.issue15008@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- keywords: +needs review stage: -> patch review title: PEP 362 reference implementation for 3.3 -> PEP 362 "Signature Objects" reference implementation _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Wed Jun 6 05:53:31 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jun 2012 03:53:31 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1338954811.66.0.959375813853.issue15012@psf.upfronthosting.co.za> Changes by Brian Curtin <brian at python.org>: ---------- hgrepos: +133 keywords: +needs review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15012> _______________________________________ From report at bugs.python.org Wed Jun 6 05:54:06 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jun 2012 03:54:06 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1338954846.49.0.387391854048.issue15012@psf.upfronthosting.co.za> Changes by Brian Curtin <brian at python.org>: ---------- hgrepos: +134 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15012> _______________________________________ From report at bugs.python.org Wed Jun 6 05:54:29 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jun 2012 03:54:29 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1338954869.82.0.156992025872.issue15012@psf.upfronthosting.co.za> Changes by Brian Curtin <brian at python.org>: Added file: http://bugs.python.org/file25843/e48c54fa4bfb.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15012> _______________________________________ From report at bugs.python.org Wed Jun 6 08:35:22 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 06 Jun 2012 06:35:22 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1338964522.98.0.963018904072.issue15003@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: I'll get to a pickle patch as soon as I can. I also need to add a doc addition for PyNamespace_New() to the existing patch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Wed Jun 6 09:44:23 2012 From: report at bugs.python.org (Sandro Tosi) Date: Wed, 06 Jun 2012 07:44:23 +0000 Subject: [issue15013] smtplib: add low-level APIs to doc? Message-ID: <1338968663.18.0.754320203153.issue15013@psf.upfronthosting.co.za> New submission from Sandro Tosi <sandro.tosi at gmail.com>: In the smtplib doc I read: Low-level methods corresponding to the standard SMTP/ESMTP commands HELP, RSET, NOOP, MAIL, RCPT, and DATA are also supported. Normally these do not need to be called directly, so they are not documented here. For details, consult the module code. Well, I think the documentation should include also those low-level apis (maybe in a separate subsection). >From my POV, smtplib should implement the protocol, and give the programmers the tools to use the protocol as they prefers, and as a plus some companion methods to easy the most common operations. I'm in need to use the low-level apis, and not finding them in the doc is a disservice to me (with my user hat on ;)) and just say "go read the source" is kinda rude and unexpected. What do you think? ---------- assignee: docs at python components: Documentation messages: 162395 nosy: docs at python, sandro.tosi priority: normal severity: normal stage: needs patch status: open title: smtplib: add low-level APIs to doc? versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15013> _______________________________________ From report at bugs.python.org Wed Jun 6 10:11:21 2012 From: report at bugs.python.org (Sandro Tosi) Date: Wed, 06 Jun 2012 08:11:21 +0000 Subject: [issue15014] smtplib: allow to choose auth method on login() Message-ID: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> New submission from Sandro Tosi <sandro.tosi at gmail.com>: Hello, I'm writing some tests from an MTA, and so I'm using smtplib. Sadly the login() method doesn't allow to choose the auth method to use (but it's selected from a static list compared with what's advertized from the MTA) while it would be useful to be able to choose the AUTH method to use. ---------- components: Library (Lib) messages: 162396 nosy: sandro.tosi priority: normal severity: normal status: open title: smtplib: allow to choose auth method on login() versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15014> _______________________________________ From report at bugs.python.org Wed Jun 6 10:24:27 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 06 Jun 2012 08:24:27 +0000 Subject: [issue15011] Change Scripts to bin on Windows In-Reply-To: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za> Message-ID: <1338971067.39.0.0448171277211.issue15011@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: This was proposed a little while ago, and I have the impression that (after a lot of discussion) the proposal didn't achieve consensus on python-dev. Has that changed? The patch itself doesn't touch the venv package, which would still create e.g. 'Scripts' and 'Include' directories. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15011> _______________________________________ From report at bugs.python.org Wed Jun 6 10:33:05 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Wed, 06 Jun 2012 08:33:05 +0000 Subject: [issue7304] email.message.Message.set_payload and as_string given charset 'us-ascii' plus 8bit data produces invalid message In-Reply-To: <1257892368.6.0.221695441401.issue7304@psf.upfronthosting.co.za> Message-ID: <1338971585.39.0.520068438022.issue7304@psf.upfronthosting.co.za> Changes by Dmitry Shachnev <Mitya57 at gmail.com>: ---------- nosy: +mitya57 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7304> _______________________________________ From report at bugs.python.org Wed Jun 6 11:05:29 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Piel?=) Date: Wed, 06 Jun 2012 09:05:29 +0000 Subject: [issue15015] Access to non-existing "future" attribute in error path of futures Message-ID: <1338973529.66.0.217110755385.issue15015@psf.upfronthosting.co.za> New submission from ?ric Piel <e.a.b.piel at tudelft.nl>: concurrent.futures.Future.set_running_or_notify_cancel() has a reference to self.future, although Future has no future attribute. It's probably due to a copy/paste error. As it's in an error handling code path, most of the time the code is never used. Nevertheless it's worthy to fix it so that the right exception happens in case of error. This was detected by pylint. Attaching a patch that fixes the error. ---------- components: Library (Lib) files: future-fix-attribute.patch keywords: patch messages: 162398 nosy: pieleric priority: normal severity: normal status: open title: Access to non-existing "future" attribute in error path of futures versions: Python 3.4 Added file: http://bugs.python.org/file25844/future-fix-attribute.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15015> _______________________________________ From report at bugs.python.org Wed Jun 6 11:13:28 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Wed, 06 Jun 2012 09:13:28 +0000 Subject: [issue15016] [patch] add special case for latin messages in email.mime.text Message-ID: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> New submission from Dmitry Shachnev <Mitya57 at gmail.com>: (Follow-up to issue 14380) The attached patch makes the email.mime.text.MIMEText constructor use the iso-8859-1 (aka latin-1) encoding for messages where all characters are in range(256). This also makes them use quoted-printable transfer encoding instead of base64. So, the current algorithm of guessing encoding is as follows: - all characters are in range(128) -> encoding is us-ascii - all characters are in range(256) -> encoding is iso-8859-1 (aka latin-1) - else -> encoding is utf-8 ---------- components: email messages: 162399 nosy: barry, mitya57, r.david.murray priority: normal severity: normal status: open title: [patch] add special case for latin messages in email.mime.text type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Wed Jun 6 11:14:59 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Wed, 06 Jun 2012 09:14:59 +0000 Subject: [issue15016] [patch] add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1338974099.11.0.000822724566044.issue15016@psf.upfronthosting.co.za> Changes by Dmitry Shachnev <Mitya57 at gmail.com>: ---------- keywords: +patch Added file: http://bugs.python.org/file25845/issue_15016.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Wed Jun 6 11:32:58 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Wed, 06 Jun 2012 09:32:58 +0000 Subject: [issue15016] [patch] add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1338975178.79.0.356475017305.issue15016@psf.upfronthosting.co.za> Dmitry Shachnev <Mitya57 at gmail.com> added the comment: Updated the patch: - Avoid using letter ? in test, it's better to use chr(256) as the test case; - Updated the comment in MIMEText constructor to reflect the new behaviour. ---------- hgrepos: +135 Added file: http://bugs.python.org/file25846/issue_15016_v2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Wed Jun 6 11:33:23 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Wed, 06 Jun 2012 09:33:23 +0000 Subject: [issue15016] [patch] add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1338975203.47.0.0823881362041.issue15016@psf.upfronthosting.co.za> Changes by Dmitry Shachnev <Mitya57 at gmail.com>: ---------- hgrepos: -135 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Wed Jun 6 11:34:15 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Wed, 06 Jun 2012 09:34:15 +0000 Subject: [issue15016] [patch] add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1338975255.32.0.534851920014.issue15016@psf.upfronthosting.co.za> Changes by Dmitry Shachnev <Mitya57 at gmail.com>: Removed file: http://bugs.python.org/file25845/issue_15016.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Wed Jun 6 12:40:13 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 06 Jun 2012 10:40:13 +0000 Subject: [issue15017] threading.Lock documentation conflict Message-ID: <1338979213.38.0.308308399616.issue15017@psf.upfronthosting.co.za> New submission from Petri Lehtinen <petri at digip.org>: In the description of section 16.2.2. Lock objects: If an attempt is made to release an unlocked lock, a RuntimeError will be raised. In the description of Lock.release(): When invoked on an unlocked lock, a ThreadError is raised. Apparently, ThreadError is the correct exception. ---------- assignee: petri.lehtinen components: Documentation, Library (Lib) keywords: easy messages: 162401 nosy: petri.lehtinen priority: normal severity: normal status: open title: threading.Lock documentation conflict versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15017> _______________________________________ From report at bugs.python.org Wed Jun 6 12:40:36 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 06 Jun 2012 10:40:36 +0000 Subject: [issue15017] threading.Lock documentation conflict In-Reply-To: <1338979213.38.0.308308399616.issue15017@psf.upfronthosting.co.za> Message-ID: <1338979236.53.0.708457118969.issue15017@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: ---------- versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15017> _______________________________________ From report at bugs.python.org Wed Jun 6 13:34:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 06 Jun 2012 11:34:05 +0000 Subject: [issue15011] Change Scripts to bin on Windows In-Reply-To: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za> Message-ID: <1338982445.25.0.539060104038.issue15011@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I think there were strong objections to changing the path of python.exe, but this is not proposed in this patch. As for the patch itself, I think it lacks bdist_msi changes. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15011> _______________________________________ From report at bugs.python.org Wed Jun 6 14:09:19 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 06 Jun 2012 12:09:19 +0000 Subject: [issue12774] Warning -- multiprocessing.process._dangling was modified by test_multiprocessing In-Reply-To: <1313626877.54.0.853743115284.issue12774@psf.upfronthosting.co.za> Message-ID: <1338984559.73.0.853996874717.issue12774@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: The warning no longer appears for the 3.x branch. I think it was changeset e54adf13e7a6 which only modified the test suite. I don't think it is worth backporting to 3.2. ---------- nosy: +sbt resolution: -> fixed stage: needs patch -> committed/rejected status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12774> _______________________________________ From report at bugs.python.org Wed Jun 6 14:24:33 2012 From: report at bugs.python.org (Paul Nasrat) Date: Wed, 06 Jun 2012 12:24:33 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1338985473.48.0.506246106789.issue14982@psf.upfronthosting.co.za> Paul Nasrat <pnasrat at gmail.com> added the comment: We've taken a simpler approach avoiding walk_packages in pip which we'll release for 3.3. I'd say if pkgutil doesn't work correctly with importers & loaders outside of it we probably should make that very explicit in the docs, and potentially consider deprecating walk_packages. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14982> _______________________________________ From report at bugs.python.org Wed Jun 6 14:24:48 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 06 Jun 2012 12:24:48 +0000 Subject: [issue13854] multiprocessing: SystemExit from child with non-int, non-str arg causes TypeError In-Reply-To: <1327428526.26.0.964378708084.issue13854@psf.upfronthosting.co.za> Message-ID: <1338985488.58.0.952581536743.issue13854@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13854> _______________________________________ From report at bugs.python.org Wed Jun 6 14:25:09 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 06 Jun 2012 12:25:09 +0000 Subject: [issue12157] join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za> Message-ID: <1338985509.12.0.356852672559.issue12157@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12157> _______________________________________ From report at bugs.python.org Wed Jun 6 14:35:14 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 06 Jun 2012 12:35:14 +0000 Subject: [issue10037] multiprocessing.pool processes started by worker handler stops working In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za> Message-ID: <1338986114.16.0.914697200734.issue10037@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10037> _______________________________________ From report at bugs.python.org Wed Jun 6 14:51:43 2012 From: report at bugs.python.org (Marcus von Appen) Date: Wed, 06 Jun 2012 12:51:43 +0000 Subject: [issue15018] Incomplete Python LDFLAGS and CPPFLAGS used for extension modules on posix Message-ID: <1338987103.32.0.200789346526.issue15018@psf.upfronthosting.co.za> New submission from Marcus von Appen <mva at sysfault.org>: If CPython is built and installed with additional CPPFLAGS and/or LDFLAGS on a posix platform, those flags are not passed to C extension modules, leaving users (in the worst case) lost without the ability to build and install C extension modules, if the flags are important for detecting include files or linking. Example: * Python shall be built with GNU pthreads (--with-pth) * The pth libs are not installed in any default location, CPP and LD know about, but somewhere else (e.g. /usr/local/lib/pth/ and /usr/local/include/pth/) * Appropriate CPPFLAGS="-I/usr/local/include/pth" and LDFLAGS="-L/usr/local/lib/pth" are defined in the environment for the build. Python gets built and installed. Result in /wherever/pythonX.X/config/Makefile: ... OPT= BASECFLAGS= -fno-strict-aliasing CFLAGS= $(BASECFLAGS) -pipe $(OPT) $(EXTRA_CFLAGS) ... CPPFLAGS= -I. -IInclude -I$(srcdir)/Include -I/usr/local/include/pth LDFLAGS= -L/usr/local/lib/pth ... Invocation of python-config --cflags: # python-config --cflags -I/whereever/include/pythonX.X -I/whereever/include/pythonX.X -fno-strict-aliasing -pipe Invocation of python-config --ldflags: # python-config --ldflags -L/whereever/lib/pythonX.X/config -lpth -lutil -lm -lpythonX.X So far, so problematic. Since Python.h incorporates pth.h, compiling something without defining the necessary CPPFLAGS manually will fail. Same for linking. The issue is *not* limited to --with-pth, but to any CPPFLAGS/LDFLAGS settings that are necessary to get CPython to work on the target platform. One might argue that CPPFLAGS should go to CFLAGS, but that contradicts the purpose of CPPFLAGS and CFLAGS. At least for posix-alike platforms (those for which _init_posix() is called in distutils/sysconfig.py), it is necessary that both, python-config as well as the distutils internals add the appropriate CPPFLAGS. It might be argued that one should use CFLAGS instead of CPPFLAGS for such important additional flags, but what shall be done with LDFLAGS then? ---------- assignee: eric.araujo components: Build, Distutils, Extension Modules messages: 162405 nosy: eric.araujo, marcusva, tarek priority: normal severity: normal status: open title: Incomplete Python LDFLAGS and CPPFLAGS used for extension modules on posix type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15018> _______________________________________ From report at bugs.python.org Wed Jun 6 14:54:49 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 12:54:49 +0000 Subject: [issue15013] smtplib: add low-level APIs to doc? In-Reply-To: <1338968663.18.0.754320203153.issue15013@psf.upfronthosting.co.za> Message-ID: <1338987289.8.0.975220451137.issue15013@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Well, personally I just read the code, and didn't think anything of it. I guess Python code is documentation to me :) I don't see why there would be any objection to documenting them if you want to, though. It's not like we're going to want to change that API. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15013> _______________________________________ From report at bugs.python.org Wed Jun 6 14:55:04 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 12:55:04 +0000 Subject: [issue15013] smtplib: add low-level APIs to doc? In-Reply-To: <1338968663.18.0.754320203153.issue15013@psf.upfronthosting.co.za> Message-ID: <1338987304.58.0.236279379612.issue15013@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- components: +email nosy: +barry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15013> _______________________________________ From report at bugs.python.org Wed Jun 6 15:01:57 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 13:01:57 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1338987717.14.0.554096698034.issue15014@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Yes, this is a need I also ran into, but hadn't gotten around to submitting a bug for. If we are going to do this, though, I think we should do it right and add the ability to support arbitrary login methods. An example of one way to do this is the imaplib authobj protocol. As things are, I wound up implementing XYMCOOKIE login using the even-more-primitive-than-SMTP-cmd-level operation 'do_cmd'. ---------- nosy: +r.david.murray title: smtplib: allow to choose auth method on login() -> smtplib: add support for arbitrary auth methods type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15014> _______________________________________ From report at bugs.python.org Wed Jun 6 15:02:19 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 13:02:19 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1338987739.73.0.861108143286.issue15014@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- components: +email nosy: +barry stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15014> _______________________________________ From report at bugs.python.org Wed Jun 6 15:05:15 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 13:05:15 +0000 Subject: [issue15015] Access to non-existing "future" attribute in error path of futures In-Reply-To: <1338973529.66.0.217110755385.issue15015@psf.upfronthosting.co.za> Message-ID: <1338987915.61.0.517190280556.issue15015@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +bquinlan stage: -> patch review type: -> behavior versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15015> _______________________________________ From report at bugs.python.org Wed Jun 6 15:10:45 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 13:10:45 +0000 Subject: [issue15016] Add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1338988245.67.0.326873825421.issue15016@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Thanks for the patch. I may not get to this until after the beta (or I might, you never know). Could you submit a contributor agreement please? http://www.python.org/psf/contrib ---------- stage: -> patch review title: [patch] add special case for latin messages in email.mime.text -> Add special case for latin messages in email.mime.text _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Wed Jun 6 15:14:51 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 13:14:51 +0000 Subject: [issue15017] threading.Lock documentation conflict In-Reply-To: <1338979213.38.0.308308399616.issue15017@psf.upfronthosting.co.za> Message-ID: <1338988491.43.0.23994619397.issue15017@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: There's already an issue for this (issue 14502), which is closed. If the docs are still wrong you should probably reopen that one, since it has discussion of the issues involved. (Note, however, that ThreadError is RuntimeError, so technically the docs are not *in*correct :) ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Document better what happens on releasing an unacquired lock _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15017> _______________________________________ From report at bugs.python.org Wed Jun 6 15:29:47 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Wed, 06 Jun 2012 13:29:47 +0000 Subject: [issue15016] Add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1338989387.82.0.596361768144.issue15016@psf.upfronthosting.co.za> Dmitry Shachnev <Mitya57 at gmail.com> added the comment: Done, sent an e-mail to contributors at python.org. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Wed Jun 6 16:06:26 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 Jun 2012 14:06:26 +0000 Subject: [issue15011] Change Scripts to bin on Windows In-Reply-To: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za> Message-ID: <1338991586.41.0.18232185581.issue15011@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: Ah, sorry, the venv change wasn't included for some reason. New patch attached. I'll look into bdist_msi. I don't remember there being strong thoughts against this, but I guess I'll go look again. ---------- Added file: http://bugs.python.org/file25847/issue15011.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15011> _______________________________________ From report at bugs.python.org Wed Jun 6 16:12:47 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 06 Jun 2012 14:12:47 +0000 Subject: [issue10037] multiprocessing.pool processes started by worker handler stops working In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za> Message-ID: <1338991967.04.0.49417129819.issue10037@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: It is not clear to me how to reproduce the bug. When you say "letting the workers terminate themselves" do mean calling sys.exit() or os._exit() in the submitted task? Are you trying to get the result of a task which caused the worker to exit? I'm not sure how the patch would change the current behaviour. The following seems to work for me: import sys, os import multiprocessing as mp if __name__ == '__main__': p = mp.Pool(4, maxtasksperchild=5) results = [] for i in range(100): if i % 10 == 0: results.append(p.apply_async(sys.exit)) else: results.append(p.apply_async(os.getpid)) for i, res in enumerate(results): if i % 10 != 0: print(res.get()) else: pass # trying res.get() would block forever ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10037> _______________________________________ From report at bugs.python.org Wed Jun 6 16:47:45 2012 From: report at bugs.python.org (=?utf-8?b?SsSBbmlz?=) Date: Wed, 06 Jun 2012 14:47:45 +0000 Subject: [issue15019] Sting termination on Linux Message-ID: <1338994065.34.0.987983176333.issue15019@psf.upfronthosting.co.za> New submission from J?nis <janis.judvaitis at gmail.com>: test = "Hi there :)" print len(test), test // Prints "11 Hi there :)" test = test.replace(" ", "\x00") print len(test), test // Prints "11 On Windows '\x00' is same as ' ', but on linux string is terminated at first occurance of '\x00'. Results on problems with pySerial and binary data, so I can't replace '\x00' with ' '. ---------- components: Interpreter Core messages: 162413 nosy: jjanis priority: normal severity: normal status: open title: Sting termination on Linux type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15019> _______________________________________ From report at bugs.python.org Wed Jun 6 17:11:45 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Jun 2012 15:11:45 +0000 Subject: [issue15019] Sting termination on Linux In-Reply-To: <1338994065.34.0.987983176333.issue15019@psf.upfronthosting.co.za> Message-ID: <1338995505.46.0.433781715334.issue15019@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Windows makes \x00 a space? How odd. This is the result for me on linux: Python 2.7.3+ (2.7:1f5d2642929a, May 25 2012, 12:47:34) [GCC 4.5.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> test = "Hi there :)" >>> print len(test), test 11 Hi there :) >>> test = test.replace(" ", "\x00") >>> print len(test), test 11 Hithere:) Your comment on the last line of your example seems to have been truncated, so I'm not sure what you really saw. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15019> _______________________________________ From report at bugs.python.org Wed Jun 6 18:00:23 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 06 Jun 2012 16:00:23 +0000 Subject: [issue15018] Incomplete Python LDFLAGS and CPPFLAGS used for extension modules on posix In-Reply-To: <1338987103.32.0.200789346526.issue15018@psf.upfronthosting.co.za> Message-ID: <1338998423.34.0.48530779292.issue15018@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15018> _______________________________________ From report at bugs.python.org Wed Jun 6 18:24:37 2012 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 06 Jun 2012 16:24:37 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1338999877.64.0.168170486686.issue14626@psf.upfronthosting.co.za> Changes by Yury Selivanov <yselivanov at gmail.com>: ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Wed Jun 6 18:53:19 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 06 Jun 2012 16:53:19 +0000 Subject: [issue14847] AttributeError: NoneType has no attribute 'utf_8_decode' In-Reply-To: <1337311331.2.0.610588604888.issue14847@psf.upfronthosting.co.za> Message-ID: <1339001599.14.0.552137942368.issue14847@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: I find that on Python 2.7.3 64-bit Windows, the deletion of locale.encodings is also necessary: PS C:\Users\jaraco> python Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> b'x'.decode('utf-8') u'x' >>> del sys.modules['encodings.utf_8'], sys.modules['encodings'] >>> b'x'.decode('utf-8') u'x' >>> ^Z PS C:\Users\jaraco> python Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> b'x'.decode('utf-8') u'x' >>> import locale; del locale.encodings # Not necessary with python2 >>> del sys.modules['encodings.utf_8'], sys.modules['encodings'] >>> b'x'.decode('utf-8') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "c:\python\lib\encodings\utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) AttributeError: 'NoneType' object has no attribute 'utf_8_decode' ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14847> _______________________________________ From report at bugs.python.org Wed Jun 6 19:36:06 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 06 Jun 2012 17:36:06 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1339004166.19.0.188664939232.issue14982@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Yes, the docs should get updated and I will do that before Python 3.3 goes out the door. ---------- assignee: -> brett.cannon _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14982> _______________________________________ From report at bugs.python.org Wed Jun 6 20:00:57 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 06 Jun 2012 18:00:57 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1339005657.14.0.652294196637.issue14502@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: The docs of 2.7 and 3.2 still first say that RuntimeError is raised, and then that a ThreadError is raised: ... If an attempt is made to release an unlocked lock, a RuntimeError will be raised. ... Lock.release() ... When invoked on an unlocked lock, a ThreadError is raised. In 2.7 and 3.2, ThreadError is not a RuntimeError, so this is wrong. ---------- nosy: +petri.lehtinen resolution: fixed -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14502> _______________________________________ From report at bugs.python.org Wed Jun 6 20:03:07 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 06 Jun 2012 18:03:07 +0000 Subject: [issue14847] AttributeError: NoneType has no attribute 'utf_8_decode' In-Reply-To: <1337311331.2.0.610588604888.issue14847@psf.upfronthosting.co.za> Message-ID: <1339005787.21.0.355437419197.issue14847@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: We're encountering this issue in another application of ours. A scan of the code doesn't reveal any places where the encodings.* modules are removed, so I've created a wrapper I intend to apply to our application that might help us detect where the module is being deleted. I'm attaching it as 'wrapper.py'. It appears to work for the nominal case. I'll report back if it works (or doesn't) for a real-world case. ---------- Added file: http://bugs.python.org/file25848/wrapper.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14847> _______________________________________ From report at bugs.python.org Wed Jun 6 20:28:45 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 06 Jun 2012 18:28:45 +0000 Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when called with a str() In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za> Message-ID: <1339007325.11.0.69318292966.issue9544@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Attached a patch against 3.2. It reflects the facts that pack_fstring and pack_fopaque are the same methd, and pack_string, pack_opaque and pack_bytes are the same method. ---------- versions: +Python 3.2, Python 3.3 -Python 3.1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9544> _______________________________________ From report at bugs.python.org Wed Jun 6 20:29:37 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 06 Jun 2012 18:29:37 +0000 Subject: [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when called with a str() In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za> Message-ID: <1339007377.64.0.700548949833.issue9544@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: Added file: http://bugs.python.org/file25849/issue9544.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9544> _______________________________________ From report at bugs.python.org Wed Jun 6 21:25:52 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jun 2012 19:25:52 +0000 Subject: [issue6160] Tkinter.Spinbox: fix for bbox and removed some uninteresting returns In-Reply-To: <1243826530.3.0.945381049334.issue6160@psf.upfronthosting.co.za> Message-ID: <1339010752.91.0.230632769338.issue6160@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: I believe that for 3.x, Lib/lib-tk/Tkinter.py is not Lib/tkinter/__init__.py. I will put this on my list of issues to look at if possible. ---------- nosy: +terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6160> _______________________________________ From report at bugs.python.org Wed Jun 6 22:26:16 2012 From: report at bugs.python.org (Brian Quinlan) Date: Wed, 06 Jun 2012 20:26:16 +0000 Subject: [issue15015] Access to non-existing "future" attribute in error path of futures In-Reply-To: <1338973529.66.0.217110755385.issue15015@psf.upfronthosting.co.za> Message-ID: <1339014377.0.0.971523431289.issue15015@psf.upfronthosting.co.za> Changes by Brian Quinlan <brian at sweetapp.com>: ---------- assignee: -> bquinlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15015> _______________________________________ From report at bugs.python.org Wed Jun 6 23:25:39 2012 From: report at bugs.python.org (Roumen Petrov) Date: Wed, 06 Jun 2012 21:25:39 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1339017939.34.0.00707823452042.issue3754@psf.upfronthosting.co.za> Changes by Roumen Petrov <bugtrack at roumenpetrov.info>: Added file: http://bugs.python.org/file25850/python-py3k-20120607-CROSS.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Wed Jun 6 23:54:49 2012 From: report at bugs.python.org (Roumen Petrov) Date: Wed, 06 Jun 2012 21:54:49 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1339019689.23.0.981533177946.issue3754@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: About Android issue with wchar still is applicable. So issue is not exactly as in 12010. Even with changed size multi-byte functions just return return result like a byte array, i.e. without conversion. Since python try to validate wide character at some point will be raised exception invalid multi-byte. Only for test work around could be implement - "fake" conversion functions that just store char into wchar array and to use ascii codec. Next is that lack of locale support and lack of locale information(structure is without members). Another issue is that loader does not resolve indirect dependencies. Many python modules depend from math library but are not linked with it and math functions are resolved later. This does not work on android and those modules must be explicitly linked to math library. Also posix semaphores must be disabled. As result python 3k regression tests except those that require locale support or ctype will pass. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Thu Jun 7 00:01:14 2012 From: report at bugs.python.org (Alexis Metaireau) Date: Wed, 06 Jun 2012 22:01:14 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1339020074.49.0.779587036481.issue3754@psf.upfronthosting.co.za> Changes by Alexis Metaireau <alexis at notmyidea.org>: ---------- nosy: -alexis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Thu Jun 7 00:04:25 2012 From: report at bugs.python.org (Roumen Petrov) Date: Wed, 06 Jun 2012 22:04:25 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1339020265.71.0.266094739448.issue3871@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: Also include mingw-w64 fixes - check for structure REPARSE_DATA_BUFFER, use lower case names of some headers . set_abort_behavior. I prefer to exclude use of parse_off_t so that functionality to be to same. Use of relict alarm function is not excluded as one of the test will fail as test require SIGALARM support. ---------- Added file: http://bugs.python.org/file25851/python-py3k-20120607-MINGW.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Thu Jun 7 00:08:09 2012 From: report at bugs.python.org (Roumen Petrov) Date: Wed, 06 Jun 2012 22:08:09 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1339020489.88.0.190706114245.issue3871@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: Correction: Use of relict alarm function is not excluded even failure in one of tests - the test is run if exist alarm function but require in addition SIGALARM attribute. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Thu Jun 7 00:24:04 2012 From: report at bugs.python.org (Roumen Petrov) Date: Wed, 06 Jun 2012 22:24:04 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1339021444.68.0.350111655438.issue3871@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: Ray , about python cygwin/mingw compiler classes exists other requests - use cygwin class instead unix compiler, remove relict checks : nocygwin and etc. but without progress. About merge of getpath sources - issue is 9654. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Thu Jun 7 00:37:29 2012 From: report at bugs.python.org (Joshua Cogliati) Date: Wed, 06 Jun 2012 22:37:29 +0000 Subject: [issue15020] Poor default value for progname Message-ID: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za> New submission from Joshua Cogliati <jrincayc at gmail.com>: In Python/pythonrun.c the following definition exists: static wchar_t *progname = L"python"; This is then used by Py_GetProgramName which is used by calculate_path in Modules/getpath.c Since in python 3, the default executable is python3, and not python, when calculate_path searches for "python" it will find where python 2 is installed instead of where python3 is installed. This is the error message that this causes: Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] I recommend that line be changed to: static wchar_t *progname = L"python3"; since that is the default executable name. For my purposes (which is making an executable that embedds python 3), I was able to work around this by calling: Py_SetProgramName(L"python3"); before Py_Initialize(); ---------- messages: 162425 nosy: Joshua.Cogliati priority: normal severity: normal status: open title: Poor default value for progname type: behavior versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15020> _______________________________________ From report at bugs.python.org Thu Jun 7 00:48:26 2012 From: report at bugs.python.org (Joshua Cogliati) Date: Wed, 06 Jun 2012 22:48:26 +0000 Subject: [issue15020] Poor default value for progname In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za> Message-ID: <1339022906.18.0.872119162861.issue15020@psf.upfronthosting.co.za> Joshua Cogliati <jrincayc at gmail.com> added the comment: Here is a part of an strace where Python fails to find python3: (This would work if progname=L"python3" ) ... 23249 stat("/opt/python/3.2.2.3/bin/python", 0x7fff2881cbf0) = -1 ENOENT (No such file or directory) 23249 readlink("/usr/local/bin/python", "/usr/bin/python", 4096) = 15 23249 readlink("/usr/bin/python", "python2.7", 4096) = 9 23249 readlink("/usr/bin/python2.7", 0x7fff2881bb70, 4096) = -1 EINVAL (Invalid argument) 23249 stat("/usr/bin/Modules/Setup", 0x7fff2881cbf0) = -1 ENOENT (No such file or directory) 23249 stat("/usr/bin/lib/python3.2/os.py", 0x7fff2881cbf0) = -1 ENOENT (No such file or directory) 23249 stat("/usr/bin/lib/python3.2/os.pyc", 0x7fff2881cbf0) = -1 ENOENT (No such file or directory) 23249 stat("/usr/lib/python3.2/os.py", 0x7fff2881cbf0) = -1 ENOENT (No such file or directory) 23249 stat("/usr/lib/python3.2/os.pyc", 0x7fff2881cbf0) = -1 ENOENT (No such file or directory) 23249 stat("/lib/python3.2/os.py", 0x7fff2881cbf0) = -1 ENOENT (No such file or directory) 23249 stat("/lib/python3.2/os.pyc", 0x7fff2881cbf0) = -1 ENOENT (No such file or directory) 23249 write(2, "Could not find platform independ"..., 55) = 55 ... $ which python3 /opt/python/3.2.2.3/bin/python3 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15020> _______________________________________ From report at bugs.python.org Thu Jun 7 00:59:26 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jun 2012 22:59:26 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1339023566.27.0.977194482058.issue14627@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: > Hmm, I've managed to produce the error with 3.1: Oh oh, I thought that importlib changed the behaviour, but I'm wrong. importlib doesn't change anything so I'm closing the issue as invalid. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14627> _______________________________________ From report at bugs.python.org Thu Jun 7 01:11:32 2012 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 06 Jun 2012 23:11:32 +0000 Subject: [issue14990] detect_encoding should fail with SyntaxError on invalid encoding In-Reply-To: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za> Message-ID: <1339024292.96.0.455254610546.issue14990@psf.upfronthosting.co.za> Florent Xicluna <florent.xicluna at gmail.com> added the comment: It should raise a SyntaxError, if coding is 'utf8'. I don't agree with the last patch proposed. If the import report a SyntaxError, 'tokenize' should do the same. $ ./python Lib/test/bad_coding2.py File "Lib/test/bad_coding2.py", line 1 SyntaxError: encoding problem: utf-8 and it complies strictly with PEP263. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14990> _______________________________________ From report at bugs.python.org Thu Jun 7 01:13:32 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jun 2012 23:13:32 +0000 Subject: [issue14990] detect_encoding should fail with SyntaxError on invalid encoding In-Reply-To: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za> Message-ID: <1339024412.8.0.0241266374048.issue14990@psf.upfronthosting.co.za> Changes by STINNER Victor <victor.stinner at gmail.com>: Removed file: http://bugs.python.org/file25825/detect_encoding.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14990> _______________________________________ From report at bugs.python.org Thu Jun 7 01:13:55 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jun 2012 23:13:55 +0000 Subject: [issue14990] detect_encoding should fail with SyntaxError on invalid encoding In-Reply-To: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za> Message-ID: <1339024435.68.0.436276866105.issue14990@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: Oops, I didn't want to attach my patch to the issue. Mine is wrong, whereas yours is the right fix :-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14990> _______________________________________ From report at bugs.python.org Thu Jun 7 01:27:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jun 2012 23:27:57 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1339025277.05.0.0713527004486.issue15003@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: It would be nice to have a minimum documentation :-) What is the kwds parameter? What are attributes of the object? ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Thu Jun 7 01:32:34 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jun 2012 23:32:34 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> Message-ID: <1339025554.29.0.269612380922.issue15006@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: Hum, can you please explain your change? If it is explained on python-dev, can you add a link to the email? You should documentation the behaviour change in the documentation of the datetime module. You chose Python 3.4, do you mean that such change is too late for Python 3.3? ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Thu Jun 7 02:01:12 2012 From: report at bugs.python.org (Abhishek Singh) Date: Thu, 07 Jun 2012 00:01:12 +0000 Subject: [issue15021] xmlrpc server hangs Message-ID: <1339027271.75.0.304876559161.issue15021@psf.upfronthosting.co.za> New submission from Abhishek Singh <abhishekrsingh at gmail.com>: Hi Terry, I am running into a xmlrpc server issue where it just hangs. 9.914048 127.0.0.1 -> 127.0.0.1 TCP 52327 > 8012 [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=3131436173 TSER=0 WS=6 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 3c 27 64 40 00 40 06 15 56 7f 00 00 01 7f 00 .<'d at .@..V...... 0020 00 01 cc 67 1f 4c ee eb cb e9 00 00 00 00 a0 02 ...g.L.......... 0030 80 18 41 d1 00 00 02 04 40 0c 04 02 08 0a ba a5 ..A..... at ....... 0040 ec 8d 00 00 00 00 01 03 03 06 .......... 9.914060 127.0.0.1 -> 127.0.0.1 TCP 8012 > 52327 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=3131436173 TSER=3131436173 WS=6 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 3c 00 00 40 00 40 06 3c ba 7f 00 00 01 7f 00 .<.. at .@.<....... 0020 00 01 1f 4c cc 67 0e c1 e9 95 ee eb cb ea a0 12 ...L.g.......... 0030 80 00 a2 4d 00 00 02 04 40 0c 04 02 08 0a ba a5 ...M.... at ....... 0040 ec 8d ba a5 ec 8d 01 03 03 06 .......... 9.914070 127.0.0.1 -> 127.0.0.1 TCP 52327 > 8012 [ACK] Seq=1 Ack=1 Win=32832 Len=0 TSV=3131436173 TSER=3131436173 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 27 65 40 00 40 06 15 5d 7f 00 00 01 7f 00 .4'e at .@..]...... 0020 00 01 cc 67 1f 4c ee eb cb ea 0e c1 e9 96 80 10 ...g.L.......... 0030 02 01 89 70 00 00 01 01 08 0a ba a5 ec 8d ba a5 ...p............ 0040 ec 8d .. 9.914123 127.0.0.1 -> 127.0.0.1 TCP 52327 > 8012 [PSH, ACK] Seq=1 Ack=1 Win=32832 Len=141 TSV=3131436173 TSER=3131436173 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 c1 27 66 40 00 40 06 14 cf 7f 00 00 01 7f 00 ..'f at .@......... 0020 00 01 cc 67 1f 4c ee eb cb ea 0e c1 e9 96 80 18 ...g.L.......... 0030 02 01 fe b5 00 00 01 01 08 0a ba a5 ec 8d ba a5 ................ 0040 ec 8d 50 4f 53 54 20 2f 20 48 54 54 50 2f 31 2e ..POST / HTTP/1. 0050 30 0d 0a 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f 0..Host: localho 0060 73 74 3a 38 30 31 32 0d 0a 55 73 65 72 2d 41 67 st:8012..User-Ag 0070 65 6e 74 3a 20 78 6d 6c 72 70 63 6c 69 62 2e 70 ent: xmlrpclib.p 0080 79 2f 31 2e 30 2e 31 20 28 62 79 20 77 77 77 2e y/1.0.1 (by www. 0090 70 79 74 68 6f 6e 77 61 72 65 2e 63 6f 6d 29 0d pythonware.com). 00a0 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 .Content-Type: t 00b0 65 78 74 2f 78 6d 6c 0d 0a 43 6f 6e 74 65 6e 74 ext/xml..Content 00c0 2d 4c 65 6e 67 74 68 3a 20 39 38 0d 0a 0d 0a -Length: 98.... 9.914130 127.0.0.1 -> 127.0.0.1 TCP 8012 > 52327 [ACK] Seq=1 Ack=142 Win=33856 Len=0 TSV=3131436173 TSER=3131436173 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 05 1b 40 00 40 06 37 a7 7f 00 00 01 7f 00 .4.. at .@.7....... 0020 00 01 1f 4c cc 67 0e c1 e9 96 ee eb cc 77 80 10 ...L.g.......w.. 0030 02 11 88 d3 00 00 01 01 08 0a ba a5 ec 8d ba a5 ................ 0040 ec 8d .. 9.914171 127.0.0.1 -> 127.0.0.1 TCP 52327 > 8012 [PSH, ACK] Seq=142 Ack=1 Win=32832 Len=98 TSV=3131436173 TSER=3131436173 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 96 27 67 40 00 40 06 14 f9 7f 00 00 01 7f 00 ..'g at .@......... 0020 00 01 cc 67 1f 4c ee eb cc 77 0e c1 e9 96 80 18 ...g.L...w...... 0030 02 01 fe 8a 00 00 01 01 08 0a ba a5 ec 8d ba a5 ................ 0040 ec 8d 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d ..<?xml version= 0050 27 31 2e 30 27 3f 3e 0a 3c 6d 65 74 68 6f 64 43 '1.0'?>.<methodC 0060 61 6c 6c 3e 0a 3c 6d 65 74 68 6f 64 4e 61 6d 65 all>.<methodName 0070 3e 69 6e 66 6f 3c 2f 6d 65 74 68 6f 64 4e 61 6d >info</methodNam 0080 65 3e 0a 3c 70 61 72 61 6d 73 3e 0a 3c 2f 70 61 e>.<params>.</pa 0090 72 61 6d 73 3e 0a 3c 2f 6d 65 74 68 6f 64 43 61 rams>.</methodCa 00a0 6c 6c 3e 0a ll>. 9.914177 127.0.0.1 -> 127.0.0.1 TCP 8012 > 52327 [ACK] Seq=1 Ack=240 Win=33856 Len=0 TSV=3131436173 TSER=3131436173 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 05 1c 40 00 40 06 37 a6 7f 00 00 01 7f 00 .4.. at .@.7....... 0020 00 01 1f 4c cc 67 0e c1 e9 96 ee eb cc d9 80 10 ...L.g.......... 0030 02 11 88 71 00 00 01 01 08 0a ba a5 ec 8d ba a5 ...q............ 0040 ec 8d .. <Client sent a request, and server just hangs here> When I look at the server, it is stuck here: (gdb) bt #0 0x00310424 in __kernel_vsyscall () #1 0x003df758 in recv () from /lib/libpthread.so.0 #2 0x00dbbca5 in sock_recv_guts (s=0xb7489890, cbuf=<value optimized out>, len=8192, flags=0) at /home/shankar/python/Python-2.7.3/Modules/socketmodule.c:2361 #3 0x00dbbee6 in sock_recv (s=0xb7489890, args=0xb746780c) at /home/shankar/python/Python-2.7.3/Modules/socketmodule.c:2442 #4 0x080e1071 in call_function (f=0x8db3a3c, throwflag=0) at Python/ceval.c:4021 #5 PyEval_EvalFrameEx (f=0x8db3a3c, throwflag=0) at Python/ceval.c:2666 #6 0x080e2c1b in PyEval_EvalCodeEx (co=0xb77211d0, globals=0xb7706604, locals=0x0, args=0x8db3a14, argcount=2, kws=0x8db3a1c, kwcount=0, defs=0xb74a79b8, defcount=1, closure=0x0) at Python/ceval.c:3253 #7 0x080e12e9 in fast_function (f=0x8db38cc, throwflag=0) at Python/ceval.c:4117 #8 call_function (f=0x8db38cc, throwflag=0) at Python/ceval.c:4042 #9 PyEval_EvalFrameEx (f=0x8db38cc, throwflag=0) at Python/ceval.c:2666 #10 0x080e1b55 in fast_function (f=0x8db3774, throwflag=0) at Python/ceval.c:4107 #11 call_function (f=0x8db3774, throwflag=0) at Python/ceval.c:4042 #12 PyEval_EvalFrameEx (f=0x8db3774, throwflag=0) at Python/ceval.c:2666 #13 0x080e1b55 in fast_function (f=0x8db2f3c, throwflag=0) at Python/ceval.c:4107 #14 call_function (f=0x8db2f3c, throwflag=0) at Python/ceval.c:4042 #15 PyEval_EvalFrameEx (f=0x8db2f3c, throwflag=0) at Python/ceval.c:2666 #16 0x080e2c1b in PyEval_EvalCodeEx (co=0xb747c458, globals=0xb7477714, locals=0x0, args=0xb7469538, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253 #17 0x0813ee2a in function_call (func=0xb748b8b4, arg=0xb746952c, kw=0x0) at Objects/funcobject.c:526 #18 0x0805d90a in PyObject_Call (func=0xb748b8b4, arg=0xb746952c, kw=0x0) at Objects/abstract.c:2529 #19 0x080657f1 in instancemethod_call (func=0xb748b8b4, arg=<value optimized out>, kw=0x0) at Objects/classobject.c:2578 #20 0x0805d90a in PyObject_Call (func=0xb7470054, arg=0xb74896bc, kw=0x0) at Objects/abstract.c:2529 #21 0x080db852 in PyEval_CallObjectWithKeywords (func=0xb7470054, arg=0xb74896bc, kw=0x0) at Python/ceval.c:3890 #22 0x08067900 in PyInstance_New (klass=0xb747ff8c, arg=0xb74896bc, kw=0x0) at Objects/classobject.c:571 #23 0x0805d90a in PyObject_Call (func=0xb747ff8c, arg=0xb74896bc, kw=0x0) at Objects/abstract.c:2529 #24 0x080e04ba in do_call (f=0x8db2dd4, throwflag=0) at Python/ceval.c:4239 #25 call_function (f=0x8db2dd4, throwflag=0) at Python/ceval.c:4044 #26 PyEval_EvalFrameEx (f=0x8db2dd4, throwflag=0) at Python/ceval.c:2666 #27 0x080e1b55 in fast_function (f=0x8db2c6c, throwflag=0) at Python/ceval.c:4107 #28 call_function (f=0x8db2c6c, throwflag=0) at Python/ceval.c:4042 #29 PyEval_EvalFrameEx (f=0x8db2c6c, throwflag=0) at Python/ceval.c:2666 #30 0x080e1b55 in fast_function (f=0x8db26dc, throwflag=0) at Python/ceval.c:4107 #31 call_function (f=0x8db26dc, throwflag=0) at Python/ceval.c:4042 #32 PyEval_EvalFrameEx (f=0x8db26dc, throwflag=0) at Python/ceval.c:2666 #33 0x080e1b55 in fast_function (f=0x8db251c, throwflag=0) at Python/ceval.c:4107 #34 call_function (f=0x8db251c, throwflag=0) at Python/ceval.c:4042 #35 PyEval_EvalFrameEx (f=0x8db251c, throwflag=0) at Python/ceval.c:2666 #36 0x080e1b55 in fast_function (f=0x8d3855c, throwflag=0) at Python/ceval.c:4107 #37 call_function (f=0x8d3855c, throwflag=0) at Python/ceval.c:4042 #38 PyEval_EvalFrameEx (f=0x8d3855c, throwflag=0) at Python/ceval.c:2666 #39 0x080e1b55 in fast_function (f=0x8757eac, throwflag=0) at Python/ceval.c:4107 #40 call_function (f=0x8757eac, throwflag=0) at Python/ceval.c:4042 #41 PyEval_EvalFrameEx (f=0x8757eac, throwflag=0) at Python/ceval.c:2666 #42 0x080e2c1b in PyEval_EvalCodeEx (co=0xb76f99b0, globals=0xb779935c, locals=0x0, args=0x870ec84, argcount=0, kws=0x870ec84, kwcount=0, defs=0xb7467778, defcount=1, closure=0x0) at Python/ceval.c:3253 #43 0x080e12e9 in fast_function (f=0x870eb44, throwflag=0) at Python/ceval.c:4117 #44 call_function (f=0x870eb44, throwflag=0) at Python/ceval.c:4042 #45 PyEval_EvalFrameEx (f=0x870eb44, throwflag=0) at Python/ceval.c:2666 #46 0x080e2c1b in PyEval_EvalCodeEx (co=0xb76f99f8, globals=0xb779935c, locals=0xb779935c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253 #47 0x080e2d47 in PyEval_EvalCode (co=0xb76f99f8, globals=0xb779935c, locals=0xb779935c) at Python/ceval.c:667 #48 0x08100276 in run_mod (fp=0x870eb38, filename=0xbfb0388b "/home/shankar/apsim-6.2/1.1.5/apsim.py", start=257, globals=0xb779935c, locals=0xb779935c, closeit=1, flags=0xbfb0361c) at Python/pythonrun.c:1353 #49 PyRun_FileExFlags (fp=0x870eb38, filename=0xbfb0388b "/home/shankar/apsim-6.2/1.1.5/apsim.py", start=257, globals=0xb779935c, locals=0xb779935c, closeit=1, flags=0xbfb0361c) at Python/pythonrun.c:1339 #50 0x081004d2 in PyRun_SimpleFileExFlags (fp=0x870eb38, filename=0xbfb0388b "/home/shankar/apsim-6.2/1.1.5/apsim.py", closeit=1, flags=0xbfb0361c) at Python/pythonrun.c:943 #51 0x080592f1 in Py_Main (argc=8, argv=0xbfb03704) at Modules/main.c:639 #52 0x0805839b in main (argc=8, argv=0xbfb03704) at ./Modules/python.c:23 (gdb) q Here is good/complete one (another process, serving 8011) 9.911198 127.0.0.1 -> 127.0.0.1 TCP 8011 > 55371 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=3131436170 TSER=3131436170 WS=6 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 3c 00 00 40 00 40 06 3c ba 7f 00 00 01 7f 00 .<.. at .@.<....... 0020 00 01 1f 4b d8 4b 01 ce ef bc 30 38 0b 97 a0 12 ...K.K....08.... 0030 80 00 1c 44 00 00 02 04 40 0c 04 02 08 0a ba a5 ...D.... at ....... 0040 ec 8a ba a5 ec 8a 01 03 03 06 .......... 9.911208 127.0.0.1 -> 127.0.0.1 TCP 55371 > 8011 [ACK] Seq=1 Ack=1 Win=32832 Len=0 TSV=3131436170 TSER=3131436170 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 e7 1d 40 00 40 06 55 a4 7f 00 00 01 7f 00 .4.. at .@.U....... 0020 00 01 d8 4b 1f 4b 30 38 0b 97 01 ce ef bd 80 10 ...K.K08........ 0030 02 01 03 67 00 00 01 01 08 0a ba a5 ec 8a ba a5 ...g............ 0040 ec 8a .. 9.911260 127.0.0.1 -> 127.0.0.1 TCP 55371 > 8011 [PSH, ACK] Seq=1 Ack=1 Win=32832 Len=141 TSV=3131436170 TSER=3131436170 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 c1 e7 1e 40 00 40 06 55 16 7f 00 00 01 7f 00 .... at .@.U....... 0020 00 01 d8 4b 1f 4b 30 38 0b 97 01 ce ef bd 80 18 ...K.K08........ 0030 02 01 fe b5 00 00 01 01 08 0a ba a5 ec 8a ba a5 ................ 0040 ec 8a 50 4f 53 54 20 2f 20 48 54 54 50 2f 31 2e ..POST / HTTP/1. 0050 30 0d 0a 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f 0..Host: localho 0060 73 74 3a 38 30 31 31 0d 0a 55 73 65 72 2d 41 67 st:8011..User-Ag 0070 65 6e 74 3a 20 78 6d 6c 72 70 63 6c 69 62 2e 70 ent: xmlrpclib.p 0080 79 2f 31 2e 30 2e 31 20 28 62 79 20 77 77 77 2e y/1.0.1 (by www. 0090 70 79 74 68 6f 6e 77 61 72 65 2e 63 6f 6d 29 0d pythonware.com). 00a0 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 .Content-Type: t 00b0 65 78 74 2f 78 6d 6c 0d 0a 43 6f 6e 74 65 6e 74 ext/xml..Content 00c0 2d 4c 65 6e 67 74 68 3a 20 39 38 0d 0a 0d 0a -Length: 98.... 9.911267 127.0.0.1 -> 127.0.0.1 TCP 8011 > 55371 [ACK] Seq=1 Ack=142 Win=33856 Len=0 TSV=3131436171 TSER=3131436170 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 03 37 40 00 40 06 39 8b 7f 00 00 01 7f 00 .4.7 at .@.9....... 0020 00 01 1f 4b d8 4b 01 ce ef bd 30 38 0c 24 80 10 ...K.K....08.$.. 0030 02 11 02 c9 00 00 01 01 08 0a ba a5 ec 8b ba a5 ................ 0040 ec 8a .. 9.911307 127.0.0.1 -> 127.0.0.1 TCP 55371 > 8011 [PSH, ACK] Seq=142 Ack=1 Win=32832 Len=98 TSV=3131436171 TSER=3131436171 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 96 e7 1f 40 00 40 06 55 40 7f 00 00 01 7f 00 .... at .@.U at ...... 0020 00 01 d8 4b 1f 4b 30 38 0c 24 01 ce ef bd 80 18 ...K.K08.$...... 0030 02 01 fe 8a 00 00 01 01 08 0a ba a5 ec 8b ba a5 ................ 0040 ec 8b 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d ..<?xml version= 0050 27 31 2e 30 27 3f 3e 0a 3c 6d 65 74 68 6f 64 43 '1.0'?>.<methodC 0060 61 6c 6c 3e 0a 3c 6d 65 74 68 6f 64 4e 61 6d 65 all>.<methodName 0070 3e 69 6e 66 6f 3c 2f 6d 65 74 68 6f 64 4e 61 6d >info</methodNam 0080 65 3e 0a 3c 70 61 72 61 6d 73 3e 0a 3c 2f 70 61 e>.<params>.</pa 0090 72 61 6d 73 3e 0a 3c 2f 6d 65 74 68 6f 64 43 61 rams>.</methodCa 00a0 6c 6c 3e 0a ll>. 9.911313 127.0.0.1 -> 127.0.0.1 TCP 8011 > 55371 [ACK] Seq=1 Ack=240 Win=33856 Len=0 TSV=3131436171 TSER=3131436171 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 03 38 40 00 40 06 39 8a 7f 00 00 01 7f 00 .4.8 at .@.9....... 0020 00 01 1f 4b d8 4b 01 ce ef bd 30 38 0c 86 80 10 ...K.K....08.... 0030 02 11 02 66 00 00 01 01 08 0a ba a5 ec 8b ba a5 ...f............ 0040 ec 8b .. 9.911990 127.0.0.1 -> 127.0.0.1 TCP 8011 > 55371 [PSH, ACK] Seq=1 Ack=240 Win=33856 Len=508 TSV=3131436171 TSER=3131436171 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 02 30 03 39 40 00 40 06 37 8d 7f 00 00 01 7f 00 .0.9 at .@.7....... 0020 00 01 1f 4b d8 4b 01 ce ef bd 30 38 0c 86 80 18 ...K.K....08.... 0030 02 11 00 25 00 00 01 01 08 0a ba a5 ec 8b ba a5 ...%............ 0040 ec 8b 48 54 54 50 2f 31 2e 30 20 32 30 30 20 4f ..HTTP/1.0 200 O 0050 4b 0d 0a 53 65 72 76 65 72 3a 20 42 61 73 65 48 K..Server: BaseH 0060 54 54 50 2f 30 2e 33 20 50 79 74 68 6f 6e 2f 32 TTP/0.3 Python/2 0070 2e 37 2e 33 0d 0a 44 61 74 65 3a 20 57 65 64 2c .7.3..Date: Wed, 0080 20 30 36 20 4a 75 6e 20 32 30 31 32 20 32 33 3a 06 Jun 2012 23: 0090 33 34 3a 32 31 20 47 4d 54 0d 0a 43 6f 6e 74 65 34:21 GMT..Conte 00a0 6e 74 2d 74 79 70 65 3a 20 74 65 78 74 2f 78 6d nt-type: text/xm 00b0 6c 0d 0a 43 6f 6e 74 65 6e 74 2d 6c 65 6e 67 74 l..Content-lengt 00c0 68 3a 20 33 37 32 0d 0a 0d 0a 3c 3f 78 6d 6c 20 h: 372....<?xml 00d0 76 65 72 73 69 6f 6e 3d 27 31 2e 30 27 3f 3e 0a version='1.0'?>. 00e0 3c 6d 65 74 68 6f 64 52 65 73 70 6f 6e 73 65 3e <methodResponse> 00f0 0a 3c 70 61 72 61 6d 73 3e 0a 3c 70 61 72 61 6d .<params>.<param 0100 3e 0a 3c 76 61 6c 75 65 3e 3c 73 74 72 69 6e 67 >.<value><string 0110 3e 70 6f 72 74 20 3d 20 38 30 31 31 0a 73 74 61 >port = 8011.sta 0120 72 74 5f 74 69 6d 65 20 3d 20 32 30 31 32 2d 30 rt_time = 2012-0 0130 36 2d 30 35 20 32 33 3a 32 37 3a 34 39 0a 75 70 6-05 23:27:49.up 0140 74 69 6d 65 20 3d 20 36 31 35 39 32 0a 6e 75 6d time = 61592.num 0150 61 70 73 20 3d 20 35 0a 6e 75 6d 73 74 73 20 3d aps = 5.numsts = 0160 20 39 30 0a 66 69 72 73 74 5f 61 70 5f 69 70 20 90.first_ap_ip 0170 3d 20 31 37 32 2e 33 32 2e 31 2e 35 38 0a 66 69 = 172.32.1.58.fi 0180 72 73 74 5f 73 74 5f 69 70 20 3d 20 30 2e 30 2e rst_st_ip = 0.0. 0190 30 2e 30 0a 66 69 72 73 74 5f 73 74 5f 6d 61 63 0.0.first_st_mac 01a0 20 3d 20 30 30 3a 66 66 3a 30 30 3a 30 30 3a 30 = 00:ff:00:00:0 01b0 33 3a 64 65 0a 65 74 68 30 5f 6d 61 63 20 3d 20 3:de.eth0_mac = 01c0 30 30 3a 30 32 3a 30 34 3a 30 30 3a 30 30 3a 33 00:02:04:00:00:3 01d0 37 0a 66 69 72 73 74 5f 61 70 20 3d 20 73 69 6d 7.first_ap = sim 01e0 5f 61 70 5f 30 35 35 5f 30 30 30 0a 66 69 72 73 _ap_055_000.firs 01f0 74 5f 73 74 20 3d 20 73 69 6d 5f 73 74 61 5f 39 t_st = sim_sta_9 0200 39 30 5f 30 30 30 0a 3c 2f 73 74 72 69 6e 67 3e 90_000.</string> 0210 3c 2f 76 61 6c 75 65 3e 0a 3c 2f 70 61 72 61 6d </value>.</param 0220 3e 0a 3c 2f 70 61 72 61 6d 73 3e 0a 3c 2f 6d 65 >.</params>.</me 0230 74 68 6f 64 52 65 73 70 6f 6e 73 65 3e 0a thodResponse>. 9.912012 127.0.0.1 -> 127.0.0.1 TCP 55371 > 8011 [ACK] Seq=240 Ack=509 Win=33920 Len=0 TSV=3131436171 TSER=3131436171 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 e7 20 40 00 40 06 55 a1 7f 00 00 01 7f 00 .4. @. at .U....... 0020 00 01 d8 4b 1f 4b 30 38 0c 86 01 ce f1 b9 80 10 ...K.K08........ 0030 02 12 00 69 00 00 01 01 08 0a ba a5 ec 8b ba a5 ...i............ 0040 ec 8b .. 9.912038 127.0.0.1 -> 127.0.0.1 TCP 8011 > 55371 [FIN, ACK] Seq=509 Ack=240 Win=33856 Len=0 TSV=3131436171 TSER=3131436171 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 03 3a 40 00 40 06 39 88 7f 00 00 01 7f 00 .4.:@. at .9....... 0020 00 01 1f 4b d8 4b 01 ce f1 b9 30 38 0c 86 80 11 ...K.K....08.... 0030 02 11 00 69 00 00 01 01 08 0a ba a5 ec 8b ba a5 ...i............ 0040 ec 8b .. 9.912779 127.0.0.1 -> 127.0.0.1 TCP 55371 > 8011 [FIN, ACK] Seq=240 Ack=510 Win=33920 Len=0 TSV=3131436172 TSER=3131436171 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 e7 21 40 00 40 06 55 a0 7f 00 00 01 7f 00 .4.!@. at .U....... 0020 00 01 d8 4b 1f 4b 30 38 0c 86 01 ce f1 ba 80 11 ...K.K08........ 0030 02 12 00 66 00 00 01 01 08 0a ba a5 ec 8c ba a5 ...f............ 0040 ec 8b .. 9.912790 127.0.0.1 -> 127.0.0.1 TCP 8011 > 55371 [ACK] Seq=510 Ack=241 Win=33856 Len=0 TSV=3131436172 TSER=3131436172 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 03 3b 40 00 40 06 39 87 7f 00 00 01 7f 00 .4.;@. at .9....... 0020 00 01 1f 4b d8 4b 01 ce f1 ba 30 38 0c 87 80 10 ...K.K....08.... 0030 02 11 00 66 00 00 01 01 08 0a ba a5 ec 8c ba a5 ...f............ 0040 ec 8c .. A good server is always at select: (gdb) bt #0 0x00bb8424 in __kernel_vsyscall () #1 0x0030e921 in select () from /lib/libc.so.6 #2 0x0016baf8 in select_select (self=0x0, args=0xb754052c) at /home/shankar/python/Python-2.7.3/Modules/selectmodule.c:271 #3 0x080e1071 in call_function (f=0xa35fcec, throwflag=0) at Python/ceval.c:4021 #4 PyEval_EvalFrameEx (f=0xa35fcec, throwflag=0) at Python/ceval.c:2666 #5 0x080e1b55 in fast_function (f=0xa2bf7bc, throwflag=0) at Python/ceval.c:4107 #6 call_function (f=0xa2bf7bc, throwflag=0) at Python/ceval.c:4042 #7 PyEval_EvalFrameEx (f=0xa2bf7bc, throwflag=0) at Python/ceval.c:2666 #8 0x080e1b55 in fast_function (f=0x9cd5eac, throwflag=0) at Python/ceval.c:4107 #9 call_function (f=0x9cd5eac, throwflag=0) at Python/ceval.c:4042 #10 PyEval_EvalFrameEx (f=0x9cd5eac, throwflag=0) at Python/ceval.c:2666 #11 0x080e2c1b in PyEval_EvalCodeEx (co=0xb77d09b0, globals=0xb787035c, locals=0x0, args=0x9c8cc84, argcount=0, kws=0x9c8cc84, kwcount=0, defs=0xb753e778, defcount=1, closure=0x0) at Python/ceval.c:3253 #12 0x080e12e9 in fast_function (f=0x9c8cb44, throwflag=0) at Python/ceval.c:4117 #13 call_function (f=0x9c8cb44, throwflag=0) at Python/ceval.c:4042 #14 PyEval_EvalFrameEx (f=0x9c8cb44, throwflag=0) at Python/ceval.c:2666 #15 0x080e2c1b in PyEval_EvalCodeEx (co=0xb77d09f8, globals=0xb787035c, locals=0xb787035c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253 #16 0x080e2d47 in PyEval_EvalCode (co=0xb77d09f8, globals=0xb787035c, locals=0xb787035c) at Python/ceval.c:667 #17 0x08100276 in run_mod (fp=0x9c8cb38, filename=0xbfee888b "/home/shankar/apsim-6.2/1.1.5/apsim.py", start=257, globals=0xb787035c, locals=0xb787035c, closeit=1, flags=0xbfee6b2c) at Python/pythonrun.c:1353 #18 PyRun_FileExFlags (fp=0x9c8cb38, filename=0xbfee888b "/home/shankar/apsim-6.2/1.1.5/apsim.py", start=257, globals=0xb787035c, locals=0xb787035c, closeit=1, flags=0xbfee6b2c) at Python/pythonrun.c:1339 #19 0x081004d2 in PyRun_SimpleFileExFlags (fp=0x9c8cb38, filename=0xbfee888b "/home/shankar/apsim-6.2/1.1.5/apsim.py", closeit=1, flags=0xbfee6b2c) at Python/pythonrun.c:943 #20 0x080592f1 in Py_Main (argc=8, argv=0xbfee6c14) at Modules/main.c:639 #21 0x0805839b in main (argc=8, argv=0xbfee6c14) at ./Modules/python.c:23 ---------- components: XML messages: 162432 nosy: Abhishek.Singh priority: normal severity: normal status: open title: xmlrpc server hangs type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15021> _______________________________________ From report at bugs.python.org Thu Jun 7 02:26:21 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 00:26:21 +0000 Subject: [issue9247] imp.reload() doesn't take import lock In-Reply-To: <1279028337.95.0.00914211475074.issue9247@psf.upfronthosting.co.za> Message-ID: <1339028781.63.0.893660717649.issue9247@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: I just ran Antoine's test against the latest 3.3a4 build and received this: lock held = False lock held = False Is this issue still relevant given Brett's work on re-implementing import in pure Python? ---------- nosy: +serwy status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9247> _______________________________________ From report at bugs.python.org Thu Jun 7 02:38:48 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 00:38:48 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339029528.1.0.167086271203.issue14996@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: You are already in a Python shell. Type in "import idlelib.idle" to launch IDLE. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 02:48:16 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Thu, 07 Jun 2012 00:48:16 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1339029528.1.0.167086271203.issue14996@psf.upfronthosting.co.za> Message-ID: <CACPbxaPqgoLMbCDuQy8ic+r7idSz_gBGrfUcVOQ0LVpERum-mA@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: OK. I did that. The idle window opened. I opened a new window to create a file; save the file in my usual directory and the same thing happened. The swirling circle and the message that python.exe has stopped working. Maureen On Wed, Jun 6, 2012 at 8:38 PM, Roger Serwy <report at bugs.python.org> wrote: > > Roger Serwy <roger.serwy at gmail.com> added the comment: > > You are already in a Python shell. Type in "import idlelib.idle" to > launch IDLE. > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 02:51:41 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 00:51:41 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339030301.52.0.583187721828.issue14996@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Did any messages appear in the Python shell? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 02:54:16 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Thu, 07 Jun 2012 00:54:16 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1339030301.52.0.583187721828.issue14996@psf.upfronthosting.co.za> Message-ID: <CACPbxaN-X5svX_uCrzGUuiFMsxRcBeyMUf4nNWvefhopY5O+iw@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: No. the window becomes 'faded' it is not reponding Maureen On Wed, Jun 6, 2012 at 8:51 PM, Roger Serwy <report at bugs.python.org> wrote: > > Roger Serwy <roger.serwy at gmail.com> added the comment: > > Did any messages appear in the Python shell? > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 03:01:24 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 01:01:24 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339030884.66.0.47899343547.issue14996@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: How are you using the open dialog to navigate to your usual directory? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 03:04:21 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Thu, 07 Jun 2012 01:04:21 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1339030884.66.0.47899343547.issue14996@psf.upfronthosting.co.za> Message-ID: <CACPbxaPMWy=orSSLqw48OhtJh9DBbr8D94T3WUarKuMZrPsHbg@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: File , save as, libraries, documents - then I save the file there. No other folder right now. Maureen On Wed, Jun 6, 2012 at 9:01 PM, Roger Serwy <report at bugs.python.org> wrote: > > Roger Serwy <roger.serwy at gmail.com> added the comment: > > How are you using the open dialog to navigate to your usual directory? > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 03:20:34 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 01:20:34 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1339025554.29.0.269612380922.issue15006@psf.upfronthosting.co.za> Message-ID: <CAP7h-xZDAqHYYkFQeHG7eNBx5KMgnriiAXL-cB63juoF-7Ar9w@mail.gmail.com> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: On Wed, Jun 6, 2012 at 7:32 PM, STINNER Victor <report at bugs.python.org> wrote: > Hum, can you please explain your change? If it is explained on python-dev, can you add a link to the email? Please see http://mail.python.org/pipermail/python-dev/2012-June/119933.html I don't know what to add to the title the issue. I'll see what needs to be done in terms of documentation and will propose a NEWS entry. ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Thu Jun 7 03:21:57 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 07 Jun 2012 01:21:57 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339032117.31.0.76459663779.issue14996@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: > File , save as, libraries, documents - then I save the file there. Ok, I agree now that this seems to be a duplicate of #12988 I will make a note there that another user had the same problem. ---------- resolution: -> duplicate status: open -> closed superseder: -> Tkinter File Dialog crashes on Win7 when saving to Documents Library _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 03:25:32 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Thu, 07 Jun 2012 01:25:32 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1339032117.31.0.76459663779.issue14996@psf.upfronthosting.co.za> Message-ID: <CACPbxaNjG816N7h5vj4s_p5BWLLwN2eDd7FbV_xLaDMtUtc99Q@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: So now what happens? Maureen On Wed, Jun 6, 2012 at 9:21 PM, Terry J. Reedy <report at bugs.python.org>wrote: > > Terry J. Reedy <tjreedy at udel.edu> added the comment: > > > File , save as, libraries, documents - then I save the file there. > > Ok, I agree now that this seems to be a duplicate of #12988 > I will make a note there that another user had the same problem. > > ---------- > resolution: -> duplicate > status: open -> closed > superseder: -> Tkinter File Dialog crashes on Win7 when saving to > Documents Library > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 03:36:50 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 01:36:50 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339033010.62.0.0653632529173.issue14996@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Further discussion of this issue will be under Issue12988. We're working on finding a solution. ---------- resolution: duplicate -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 03:37:48 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jun 2012 01:37:48 +0000 Subject: [issue9247] imp.reload() doesn't take import lock In-Reply-To: <1279028337.95.0.00914211475074.issue9247@psf.upfronthosting.co.za> Message-ID: <1339033068.55.0.0991759534878.issue9247@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: Yeah, imp.reload() is pure Python now (Lib/imp.py), a simple wrapper around module.__loader__.load_module(), which does not make use of any import locks. Having it do so, however, may not be feasible as I'd expect it to mean having load_module() handle the locking. Not sure if it's worth it. The other issue is that the True reported by Antoine turned into False for you under 3.3a4. This is because of issue 9260 ("A finer grained import lock"). The global import lock represented in the imp module is now used only long enough to create a lock specific to the module currently being imported. So it's been released by the time the module is actually imported. (see Lib/importlib/_bootstrap.py) ---------- nosy: +eric.snow status: pending -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9247> _______________________________________ From report at bugs.python.org Thu Jun 7 03:43:14 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 01:43:14 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339033394.71.0.983829345731.issue14996@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Sorry for the re-open. I submitted an old form. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 04:01:38 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 07 Jun 2012 02:01:38 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339034498.71.0.934381152203.issue14996@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Maureen, as I explain on #12988, I believe that this was a tcl/tk problem that was fixed by the recent release of version 8.5.11 (last March). The Windows installer for Python 3.3.0a4 release (a week ago) seems to have solved the problem for me. So give that a try. Martin or anyone else: is the same tcl/tk upgrade going into future 3.2 and 2.7 releases? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 04:04:17 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 07 Jun 2012 02:04:17 +0000 Subject: [issue12988] Tkinter File Dialog crashes on Win7 when saving to Documents Library In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za> Message-ID: <1339034657.55.0.952407697977.issue12988@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: I closed #14996 as a duplicate of this. The OP there claimed that behavior changed between 3.2.1 and 3.2.3 and that she had same problem with 32 bit installation. It is hard to know the exact circumstances of the problem until we find its cause. Looking further, I am sure this is a tk and/or Win7 problem. tkinter.filedialog.asksaveasfile() calls SaveAs(**options).show() SaveAs sets command = "tk_getSaveFile" and inherits _Dialog which inherits commondialog.Dialog. The show method of that calls tk.call(self.command, *w._options(self.options)). Since the test call has no options, self.options is an empty dict and I presume the serialized form w._options() is also. So the call amounts to tk.call("tk_getSaveFile"), which suspends python until the dialog returns. That said, 3.3.0a4 was released a week ago with tcl/tk upgraded, in the Windows installer, from 8.5.9 to 8.5.11. So I retried the previous test and the problem is gone. Can someone else verify? If so, we can close this as fixed. (I believe that the same upgrade will appear in future 3.2 and 2.7 releases, but I am not sure.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12988> _______________________________________ From report at bugs.python.org Thu Jun 7 04:32:19 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 02:32:19 +0000 Subject: [issue12988] Tkinter File Dialog crashes on Win7 when saving to Documents Library In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za> Message-ID: <1339036339.37.0.709697614022.issue12988@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: I installed 3.3.0a4 (64-bit) on Win 7 and the issue did not occur when using asksaveasfile. I repeated with 32-bit 3.3.0a4 without any problems. How can we confirm that 3.2 will receive the Tcl/Tk upgrade? (64-bit 2.7.3 does not have this bug.) ---------- resolution: -> out of date status: open -> closed versions: -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12988> _______________________________________ From report at bugs.python.org Thu Jun 7 04:32:41 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 02:32:41 +0000 Subject: [issue12988] Tkinter File Dialog crashes on Win7 when saving to Documents Library In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za> Message-ID: <1339036361.64.0.426445620328.issue12988@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Re-opened. ---------- resolution: out of date -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12988> _______________________________________ From report at bugs.python.org Thu Jun 7 05:18:32 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jun 2012 03:18:32 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1339039112.45.0.140346969502.issue15003@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: Removed file: http://bugs.python.org/file25827/issue15003_public.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Thu Jun 7 05:20:07 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jun 2012 03:20:07 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1339039207.6.0.348231135725.issue15003@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: Where should the docs go for PyNamespace_New()? I looked at what's in Doc/c-api/concrete.rst (concrete.html#other-objects), and each of them points to its own page. Adding a new page for a single function seems a bit too much. :) Would it be bad to put the doc right at the end of concrete.rst? The attached patch does so. (Also just noticed that PyStructSequence_* is not documented...) ---------- Added file: http://bugs.python.org/file25853/issue15003_public.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Thu Jun 7 05:29:04 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 03:29:04 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1339039744.7.0.258243986694.issue14908@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: I think the attached patch implements what was agreed to on python-dev. We need more tests, particularly around DST change. I tested the patch on OSX, but I am interested to hear feedback from users of other OSes. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file25854/issue14908.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Thu Jun 7 05:37:40 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jun 2012 03:37:40 +0000 Subject: [issue15022] types.SimpleNamespace needs to be picklable Message-ID: <1339040260.61.0.109712226507.issue15022@psf.upfronthosting.co.za> New submission from Eric Snow <ericsnowcurrently at gmail.com>: In issue 15003 Raymond recommended that types.SimpleNamespace be picklable. I'll get a patch up as soon as I can to add this capability. ---------- messages: 162453 nosy: eric.snow priority: normal severity: normal stage: needs patch status: open title: types.SimpleNamespace needs to be picklable type: behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15022> _______________________________________ From report at bugs.python.org Thu Jun 7 05:39:02 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jun 2012 03:39:02 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1339040342.27.0.788404768988.issue15003@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: I've opened issue 15022 for making SimpleNamespace picklable. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Thu Jun 7 05:48:29 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 03:48:29 +0000 Subject: [issue3367] Uninitialized value read in parsetok.c In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za> Message-ID: <1339040909.19.0.785897222026.issue3367@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- assignee: belopolsky -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3367> _______________________________________ From report at bugs.python.org Thu Jun 7 05:52:03 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 03:52:03 +0000 Subject: =?utf-8?q?=5Bissue9256=5D_plistlib_should_create_non-na=C3=AFve_datetime_?= =?utf-8?q?objects?= In-Reply-To: <1279071244.17.0.181964010836.issue9256@psf.upfronthosting.co.za> Message-ID: <1339041123.43.0.841376438748.issue9256@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9256> _______________________________________ From report at bugs.python.org Thu Jun 7 05:59:04 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 03:59:04 +0000 Subject: [issue8902] add datetime.time.now() for consistency In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za> Message-ID: <1339041544.36.0.39125894083.issue8902@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Closing for the lack of interest. Proposed time.now() is already available as datetime.now().time(). No use case justifying any improvement in this area was presented. ---------- resolution: postponed -> wont fix status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8902> _______________________________________ From report at bugs.python.org Thu Jun 7 07:17:01 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 07 Jun 2012 05:17:01 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339046221.74.0.805959851315.issue14996@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: If it really fixes the bug, I can update the Tcl version. However, for that, I would need precise instructions on how to reproduce the bug. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 07:23:12 2012 From: report at bugs.python.org (Julian Berman) Date: Thu, 07 Jun 2012 05:23:12 +0000 Subject: [issue15023] listextend (and therefore list.extend and list.__init__) peek at len before iter Message-ID: <1339046592.67.0.693988189804.issue15023@psf.upfronthosting.co.za> New submission from Julian Berman <Julian+Python.org at GrayVines.com>: The following code raises an unexpected exception: class Foo(object): def __len__(self): raise Exception() def __iter__(self): return iter([]) list(Foo()) In the optimizations being done in listextend, it appears len is getting called first for some reason (sorry, haven't gotten a chance to step through it carefully yet). Tangentially, PyPy (correctly I guess) throws no such exception. ---------- components: Interpreter Core messages: 162457 nosy: Julian priority: normal severity: normal status: open title: listextend (and therefore list.extend and list.__init__) peek at len before iter type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15023> _______________________________________ From report at bugs.python.org Thu Jun 7 07:26:01 2012 From: report at bugs.python.org (Julian Berman) Date: Thu, 07 Jun 2012 05:26:01 +0000 Subject: [issue15023] listextend (and therefore list.extend and list.__init__) peek at len before iter In-Reply-To: <1339046592.67.0.693988189804.issue15023@psf.upfronthosting.co.za> Message-ID: <1339046761.91.0.824650955315.issue15023@psf.upfronthosting.co.za> Julian Berman <Julian+Python.org at GrayVines.com> added the comment: Oh, and, with apologies for the double post, tuple does the same, while set, dict, collections.deque do not. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15023> _______________________________________ From report at bugs.python.org Thu Jun 7 07:36:40 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 07 Jun 2012 05:36:40 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za> Message-ID: <1339047400.15.0.61870976327.issue14996@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Precise instructions can be found in msg144106 and msg161168 from Issue12988. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ From report at bugs.python.org Thu Jun 7 08:13:08 2012 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 07 Jun 2012 06:13:08 +0000 Subject: [issue8902] add datetime.time.now() for consistency In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za> Message-ID: <1339049588.54.0.0837105060523.issue8902@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: I'd say no consensus was reached due to lack of participation. My enthusiasm was killed by the issue8903 resolution. My opinion is that: datetime.time.now() is much better than: datetime.datetime.now().time() ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8902> _______________________________________ From report at bugs.python.org Thu Jun 7 08:15:57 2012 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 07 Jun 2012 06:15:57 +0000 Subject: [issue8902] add datetime.time.now() for consistency In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za> Message-ID: <1339049757.77.0.579712304075.issue8902@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: And I certainly don't agree with you that usability changes in API are not use cases. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8902> _______________________________________ From report at bugs.python.org Thu Jun 7 02:35:42 2012 From: report at bugs.python.org (Maureen Cuomo) Date: Thu, 07 Jun 2012 00:35:42 +0000 Subject: [issue14996] IDLE 3.2.3 crashes saving a .py file to certain folders on Windows 7 In-Reply-To: <1338951890.92.0.861028400157.issue14996@psf.upfronthosting.co.za> Message-ID: <CACPbxaPvFwD2=sbN8AVZsOJEKuJP9Mj2MwgHHB5wbvU-95vP_A@mail.gmail.com> Maureen Cuomo <mcuomo at prestonhs.org> added the comment: I get a syntax error when I type this in. I attached a word doc with the error screen Maureen On Tue, Jun 5, 2012 at 11:04 PM, Roger Serwy <report at bugs.python.org> wrote: > > Roger Serwy <roger.serwy at gmail.com> added the comment: > > Maureen, can you please start IDLE from a command prompt and report the > error message? > > Launch a command prompt, enter in "cd c:\python32" and then "python -m > idlelib.idle". IDLE should appear. Proceed to save something that causes > the crash. You should receive some feedback in the command prompt. > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14996> > _______________________________________ > ---------- Added file: http://bugs.python.org/file25852/python error 6-6-12.docx _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14996> _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python error 6-6-12.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 47474 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20120607/b8be3f8f/attachment-0001.docx> From report at bugs.python.org Thu Jun 7 09:36:27 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jun 2012 07:36:27 +0000 Subject: [issue15022] types.SimpleNamespace needs to be picklable In-Reply-To: <1339040260.61.0.109712226507.issue15022@psf.upfronthosting.co.za> Message-ID: <1339054587.63.0.820760787255.issue15022@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: I've attached a patch that gives types.SimpleNamespace pickle support. To do it I had to change the name of the type from "namespace" to "types.SimpleNamespace". That's fine. I also added __eq__/__ne__ support so I could use it during tests. ---------- keywords: +needs review, patch stage: needs patch -> patch review versions: +Python 3.3 Added file: http://bugs.python.org/file25855/issue15022_pickle.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15022> _______________________________________ From report at bugs.python.org Thu Jun 7 09:36:49 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jun 2012 07:36:49 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1339054609.79.0.930716863453.issue15003@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: ---------- stage: needs patch -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Thu Jun 7 09:37:01 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jun 2012 07:37:01 +0000 Subject: [issue15004] add weakref support to types.SimpleNamespace In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za> Message-ID: <1339054621.69.0.135772038916.issue15004@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: ---------- stage: needs patch -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15004> _______________________________________ From report at bugs.python.org Thu Jun 7 09:40:56 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Jun 2012 07:40:56 +0000 Subject: [issue15024] Split enhanced assertion support out as a unittest.TestCase base class Message-ID: <1339054856.06.0.856824140254.issue15024@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: The unittest module has some lovely enhanced comparison operations, but they're currently hard to access outside a test run. It would be rather convenient if they were split out into a separate base class so they could be used directly without needing to create an actual test case. Possible API: class Assertions: # All the enhanced assertion machinery goes here # Nothing related to actually running test cases class TestCase(Assertions): # This adds support for setUp, tearDown, addCleanup etc, etc My current workaround is to just define a dummy "runTest" method in a subclass and use that: >>> class Assertions(unittest.TestCase): ... def runTest(self): pass ... >>> check = Assertions() >>> check.assertEqual([], ()) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/unittest/case.py", line 511, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib64/python2.7/unittest/case.py", line 504, in _baseAssertEqual raise self.failureException(msg) AssertionError: [] != () >>> check.assertEqual([1], [2]) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/unittest/case.py", line 511, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib64/python2.7/unittest/case.py", line 740, in assertListEqual self.assertSequenceEqual(list1, list2, msg, seq_type=list) File "/usr/lib64/python2.7/unittest/case.py", line 722, in assertSequenceEqual self.fail(msg) File "/usr/lib64/python2.7/unittest/case.py", line 408, in fail raise self.failureException(msg) AssertionError: Lists differ: [1] != [2] First differing element 0: 1 2 - [1] + [2] ---------- messages: 162463 nosy: michael.foord, ncoghlan priority: normal severity: normal status: open title: Split enhanced assertion support out as a unittest.TestCase base class _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15024> _______________________________________ From report at bugs.python.org Thu Jun 7 09:51:15 2012 From: report at bugs.python.org (Ray Donnelly) Date: Thu, 07 Jun 2012 07:51:15 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1339055475.58.0.275387203653.issue3754@psf.upfronthosting.co.za> Ray Donnelly <mingw.android at gmail.com> added the comment: Re Android Ah of course. In that case, there's always the NDK built by Dmitry (his latest is v7 AFAIK): http://www.crystax.net/en/android/ndk ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Thu Jun 7 09:54:35 2012 From: report at bugs.python.org (Ray Donnelly) Date: Thu, 07 Jun 2012 07:54:35 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1339055675.26.0.923041102893.issue3871@psf.upfronthosting.co.za> Ray Donnelly <mingw.android at gmail.com> added the comment: Thanks for the details. I've got more fixes but I want to get the whole thing building (at least) before I post them. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Thu Jun 7 10:40:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Jun 2012 08:40:27 +0000 Subject: [issue15020] Poor default value for progname In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za> Message-ID: <1339058427.4.0.315004344511.issue15020@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +loewis versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15020> _______________________________________ From report at bugs.python.org Thu Jun 7 10:56:44 2012 From: report at bugs.python.org (Michael Foord) Date: Thu, 07 Jun 2012 08:56:44 +0000 Subject: [issue15024] Split enhanced assertion support out as a unittest.TestCase base class In-Reply-To: <1339054856.06.0.856824140254.issue15024@psf.upfronthosting.co.za> Message-ID: <1339059404.28.0.109258013217.issue15024@psf.upfronthosting.co.za> Michael Foord <michael at voidspace.org.uk> added the comment: Why not just instantiate a TestCase instance and use that? >>> from unittest import TestCase >>> t = TestCase() >>> t.assertEqual('foo', 'bar') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/compile/py3k-cpython/Lib/unittest/case.py", line 642, in assertEqual assertion_func(first, second, msg=msg) File "/compile/py3k-cpython/Lib/unittest/case.py", line 1021, in assertMultiLineEqual self.fail(self._formatMessage(msg, standardMsg)) File "/compile/py3k-cpython/Lib/unittest/case.py", line 509, in fail raise self.failureException(msg) AssertionError: 'foo' != 'bar' - foo + bar ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15024> _______________________________________ From report at bugs.python.org Thu Jun 7 11:09:22 2012 From: report at bugs.python.org (Ask Solem) Date: Thu, 07 Jun 2012 09:09:22 +0000 Subject: [issue10037] multiprocessing.pool processes started by worker handler stops working In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za> Message-ID: <1339060162.62.0.969065415856.issue10037@psf.upfronthosting.co.za> Ask Solem <ask at celeryproject.org> added the comment: Well, I still don't know exactly why restarting the socket read made it work, but the patch solved an issue where newly started pool processes would be stuck in socket read forever (happening to maybe 1/500 new processes) This and a dozen other pool related fixes are in my billiard fork of multiprocessing, e.g. what you describe in your comment: # trying res.get() would block forever works in billiard, where res.get() will raise WorkerLostError in that case. https://github.com/celery/billiard/ Earlier commit history for the pool can be found in Celery: https://github.com/ask/celery/commits/2.5/celery/concurrency/processes/pool.py My eventual goal is to merge these fixes back into Python, but except for people using Python 3.x, they would have to use billiard for quite some time anyway, so I don't feel in a hurry. I think this issue can be closed, the worker handler is simply borked and we could open up a new issue deciding how to fix it (merging billiard.Pool or someting else). (btw, Richard, you're sbt? I was trying to find your real name to give you credit for the no_execv patch in billiard) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10037> _______________________________________ From report at bugs.python.org Thu Jun 7 12:58:23 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 07 Jun 2012 10:58:23 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1339066703.73.0.29664972685.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Possibly the patch had a mixup I'm going to rework it a bit and post as a separate issue. ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11618> _______________________________________ From report at bugs.python.org Thu Jun 7 13:14:18 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Jun 2012 11:14:18 +0000 Subject: [issue15024] Split enhanced assertion support out as a unittest.TestCase base class In-Reply-To: <1339054856.06.0.856824140254.issue15024@psf.upfronthosting.co.za> Message-ID: <1339067658.38.0.861082146072.issue15024@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Because that doesn't work in 2.x (it fails with a ValueError due to "runTest" being missing) and I forgot you had already changed that behaviour to make it more convenient in 3.x :) ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15024> _______________________________________ From report at bugs.python.org Thu Jun 7 13:15:42 2012 From: report at bugs.python.org (Craig Loftus) Date: Thu, 07 Jun 2012 11:15:42 +0000 Subject: [issue15025] httplib and http.client are missing response messages for defined WEBDAV responses, e.g., UNPROCESSABLE_ENTITY (422) Message-ID: <1339067742.9.0.619240246861.issue15025@psf.upfronthosting.co.za> New submission from Craig Loftus <craig at wildknowledge.co.uk>: Calling httplib.responses[httplib.UNPROCESSABLE_ENTITY] in 2.7, or http.client.responses[http.client.UNPROCESSABLE_ENTITY] raises "KeyError: 422". The expected behaviour would be to return "Unprocessable Entity". This is the specific issue that I have hit, but the same is true of all the WEBDAV status codes that constants are defined for. ---------- components: Library (Lib) messages: 162470 nosy: craigloftus priority: normal severity: normal status: open title: httplib and http.client are missing response messages for defined WEBDAV responses, e.g., UNPROCESSABLE_ENTITY (422) type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15025> _______________________________________ From report at bugs.python.org Thu Jun 7 14:48:49 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jun 2012 12:48:49 +0000 Subject: =?utf-8?q?=5Bissue9256=5D_plistlib_should_create_non-na=C3=AFve_datetime_?= =?utf-8?q?objects?= In-Reply-To: <1279071244.17.0.181964010836.issue9256@psf.upfronthosting.co.za> Message-ID: <1339073329.35.0.91931658187.issue9256@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: An alternative is to do what the email package in 3.3 does, and treat naive datetimes as exactly "UTC referenced but with no information as to what local timezone they originated in". Either way, a program using the plistlib is going to have to know about this and handle the distinction itself, since as you say datetime doesn't have a way to make this differentiation (other than naive vs aware). So it needs to be documented clearly if it isn't already. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9256> _______________________________________ From report at bugs.python.org Thu Jun 7 15:27:00 2012 From: report at bugs.python.org (Daniel Holth) Date: Thu, 07 Jun 2012 13:27:00 +0000 Subject: [issue8084] pep-0370 on osx duplicates existing functionality In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za> Message-ID: <1339075620.99.0.299949695047.issue8084@psf.upfronthosting.co.za> Daniel Holth <dholth at fastmail.fm> added the comment: Please mention Apple's OS X Python behavior in the PEP. The Python that comes with OS X Lion doesn't seem to follow the PEP regarding ~/.local ; this deserves a mention. ---------- nosy: +dholth _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8084> _______________________________________ From report at bugs.python.org Thu Jun 7 15:56:14 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jun 2012 13:56:14 +0000 Subject: [issue15026] Faster UTF-16 encoding Message-ID: <1339077374.41.0.500256039615.issue15026@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: In pair to issue14624 here is a patch than speed up UTF-16 encoding in several times. In addition, it fixes an unsafe check of an integer overflow. Here are the results of benchmarking. See benchmark tools in https://bitbucket.org/storchaka/cpython-stuff repository. On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz: Py2.7 Py3.2 Py3.3 patched 457 (+575%) 458 (+573%) 1077 (+186%) 3083 encode utf-16le 'A'*10000 457 (+579%) 493 (+529%) 1084 (+186%) 3102 encode utf-16le '\x80'*10000 489 (+534%) 458 (+577%) 1081 (+187%) 3102 encode utf-16le '\x80'+'A'*9999 457 (+1261%) 493 (+1161%) 1116 (+457%) 6219 encode utf-16le '\u0100'*10000 489 (+1266%) 458 (+1358%) 1126 (+493%) 6678 encode utf-16le '\u0100'+'A'*9999 489 (+1263%) 458 (+1355%) 1129 (+490%) 6666 encode utf-16le '\u0100'+'\x80'*9999 457 (+1240%) 493 (+1142%) 1118 (+448%) 6125 encode utf-16le '\u8000'*10000 489 (+1271%) 458 (+1363%) 1127 (+495%) 6702 encode utf-16le '\u8000'+'A'*9999 489 (+1271%) 458 (+1364%) 1129 (+494%) 6705 encode utf-16le '\u8000'+'\x80'*9999 489 (+1135%) 458 (+1218%) 1136 (+432%) 6038 encode utf-16le '\u8000'+'\u0100'*9999 498 (+128%) 505 (+125%) 630 (+80%) 1137 encode utf-16le '\U00010000'*10000 489 (+35%) 458 (+44%) 360 (+83%) 659 encode utf-16le '\U00010000'+'A'*9999 489 (+35%) 458 (+44%) 359 (+84%) 660 encode utf-16le '\U00010000'+'\x80'*9999 489 (+36%) 458 (+45%) 361 (+84%) 663 encode utf-16le '\U00010000'+'\u0100'*9999 489 (+36%) 458 (+45%) 361 (+84%) 663 encode utf-16le '\U00010000'+'\u8000'*9999 447 (+507%) 493 (+450%) 1086 (+150%) 2712 encode utf-16be 'A'*10000 447 (+513%) 493 (+456%) 1080 (+154%) 2739 encode utf-16be '\x80'*10000 489 (+458%) 458 (+496%) 1079 (+153%) 2729 encode utf-16be '\x80'+'A'*9999 447 (+498%) 494 (+441%) 1118 (+139%) 2672 encode utf-16be '\u0100'*10000 489 (+464%) 458 (+502%) 1128 (+144%) 2756 encode utf-16be '\u0100'+'A'*9999 489 (+463%) 458 (+502%) 1131 (+144%) 2755 encode utf-16be '\u0100'+'\x80'*9999 447 (+500%) 493 (+444%) 1119 (+139%) 2680 encode utf-16be '\u8000'*10000 489 (+463%) 458 (+502%) 1126 (+145%) 2755 encode utf-16be '\u8000'+'A'*9999 489 (+464%) 458 (+502%) 1129 (+144%) 2757 encode utf-16be '\u8000'+'\x80'*9999 489 (+479%) 458 (+518%) 1137 (+149%) 2829 encode utf-16be '\u8000'+'\u0100'*9999 499 (+102%) 506 (+99%) 630 (+60%) 1009 encode utf-16be '\U00010000'*10000 489 (+6%) 458 (+13%) 360 (+44%) 519 encode utf-16be '\U00010000'+'A'*9999 489 (+6%) 458 (+13%) 359 (+44%) 518 encode utf-16be '\U00010000'+'\x80'*9999 489 (+6%) 458 (+13%) 361 (+44%) 519 encode utf-16be '\U00010000'+'\u0100'*9999 489 (+6%) 458 (+13%) 361 (+44%) 519 encode utf-16be '\U00010000'+'\u8000'*9999 ---------- components: Interpreter Core, Unicode files: encode-utf16.patch keywords: patch messages: 162473 nosy: Arfrever, asvetlov, ezio.melotti, haypo, pitrou, storchaka priority: normal severity: normal status: open title: Faster UTF-16 encoding type: performance versions: Python 3.3 Added file: http://bugs.python.org/file25856/encode-utf16.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Thu Jun 7 15:57:31 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jun 2012 13:57:31 +0000 Subject: [issue15027] Faster UTF-32 encoding Message-ID: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: In pair to issue14625 here is a patch than speed up UTF-32 encoding in several times. In addition, it fixes an unsafe check of an integer overflow. Here are the results of benchmarking. See benchmark tools in https://bitbucket.org/storchaka/cpython-stuff repository. On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz: Py2.7 Py3.2 Py3.3 patched 541 (+1032%) 541 (+1032%) 844 (+626%) 6125 encode utf-32le 'A'*10000 543 (+1056%) 541 (+1060%) 844 (+643%) 6275 encode utf-32le '\x80'*10000 544 (+1010%) 542 (+1014%) 843 (+616%) 6037 encode utf-32le '\x80'+'A'*9999 541 (+799%) 542 (+797%) 764 (+537%) 4864 encode utf-32le '\u0100'*10000 544 (+781%) 542 (+784%) 767 (+525%) 4793 encode utf-32le '\u0100'+'A'*9999 544 (+789%) 542 (+792%) 766 (+531%) 4834 encode utf-32le '\u0100'+'\x80'*9999 542 (+799%) 541 (+801%) 764 (+538%) 4874 encode utf-32le '\u8000'*10000 544 (+779%) 542 (+782%) 767 (+523%) 4780 encode utf-32le '\u8000'+'A'*9999 544 (+793%) 542 (+796%) 766 (+534%) 4859 encode utf-32le '\u8000'+'\x80'*9999 544 (+819%) 542 (+823%) 766 (+553%) 5001 encode utf-32le '\u8000'+'\u0100'*9999 430 (+867%) 427 (+874%) 860 (+383%) 4157 encode utf-32le '\U00010000'*10000 543 (+655%) 543 (+655%) 861 (+376%) 4101 encode utf-32le '\U00010000'+'A'*9999 543 (+658%) 543 (+658%) 861 (+378%) 4116 encode utf-32le '\U00010000'+'\x80'*9999 543 (+670%) 543 (+670%) 859 (+387%) 4180 encode utf-32le '\U00010000'+'\u0100'*9999 543 (+666%) 543 (+666%) 860 (+383%) 4158 encode utf-32le '\U00010000'+'\u8000'*9999 541 (+880%) 543 (+876%) 844 (+528%) 5300 encode utf-32be 'A'*10000 541 (+872%) 542 (+870%) 844 (+523%) 5256 encode utf-32be '\x80'*10000 544 (+843%) 542 (+846%) 843 (+509%) 5130 encode utf-32be '\x80'+'A'*9999 541 (+363%) 542 (+362%) 764 (+228%) 2505 encode utf-32be '\u0100'*10000 544 (+366%) 542 (+368%) 766 (+231%) 2534 encode utf-32be '\u0100'+'A'*9999 544 (+363%) 542 (+365%) 766 (+229%) 2519 encode utf-32be '\u0100'+'\x80'*9999 542 (+363%) 541 (+364%) 764 (+228%) 2509 encode utf-32be '\u8000'*10000 544 (+366%) 542 (+368%) 766 (+231%) 2534 encode utf-32be '\u8000'+'A'*9999 544 (+363%) 542 (+364%) 766 (+229%) 2517 encode utf-32be '\u8000'+'\x80'*9999 544 (+372%) 542 (+374%) 766 (+235%) 2568 encode utf-32be '\u8000'+'\u0100'*9999 430 (+428%) 427 (+432%) 860 (+164%) 2270 encode utf-32be '\U00010000'*10000 543 (+317%) 541 (+318%) 861 (+163%) 2262 encode utf-32be '\U00010000'+'A'*9999 543 (+320%) 541 (+321%) 861 (+165%) 2279 encode utf-32be '\U00010000'+'\x80'*9999 543 (+322%) 541 (+323%) 859 (+167%) 2290 encode utf-32be '\U00010000'+'\u0100'*9999 543 (+322%) 541 (+324%) 860 (+167%) 2292 encode utf-32be '\U00010000'+'\u8000'*9999 ---------- components: Interpreter Core, Unicode files: encode-utf32.patch keywords: patch messages: 162474 nosy: Arfrever, asvetlov, ezio.melotti, haypo, pitrou, storchaka priority: normal severity: normal status: open title: Faster UTF-32 encoding type: performance versions: Python 3.3 Added file: http://bugs.python.org/file25857/encode-utf32.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15027> _______________________________________ From report at bugs.python.org Thu Jun 7 18:01:57 2012 From: report at bugs.python.org (Alex Frase) Date: Thu, 07 Jun 2012 16:01:57 +0000 Subject: [issue11354] argparse: nargs could accept range of options count In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za> Message-ID: <1339084917.61.0.810889589513.issue11354@psf.upfronthosting.co.za> Alex Frase <frase at cs.wisc.edu> added the comment: I'm new here so I apologize if this is considered poor etiquette, but I'm just commenting to 'bump' this issue. My search for a way to accomplish exactly this functionality led me here, and it seems a patch was offered but no action has been taken on it for over a year now. Alas, it seems I must write a custom Action handler instead. ---------- nosy: +atfrase _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11354> _______________________________________ From report at bugs.python.org Thu Jun 7 18:40:45 2012 From: report at bugs.python.org (su) Date: Thu, 07 Jun 2012 16:40:45 +0000 Subject: [issue14185] Failure to build _dbm with ndbm on Arch Linux In-Reply-To: <1330801255.84.0.367469513946.issue14185@psf.upfronthosting.co.za> Message-ID: <1339087245.79.0.88549149082.issue14185@psf.upfronthosting.co.za> su <purepurple2003 at yahoo.com> added the comment: Same thing happens with pyhton-3.2.3 on fedora 17 *** WARNING: renaming "_dbm" since importing it failed: build/lib.linux-x86_64-3.2/_dbm.cpython-32m.so: undefined symbol: dbm_nextkey Failed to build these modules: _dbm ---------- nosy: +su715 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14185> _______________________________________ From report at bugs.python.org Thu Jun 7 18:59:40 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 07 Jun 2012 16:59:40 +0000 Subject: [issue15023] listextend (and therefore list.extend and list.__init__) peek at len before iter In-Reply-To: <1339046592.67.0.693988189804.issue15023@psf.upfronthosting.co.za> Message-ID: <1339088380.0.0.195064564292.issue15023@psf.upfronthosting.co.za> Benjamin Peterson <benjamin at python.org> added the comment: It's an optimization. No one says we can't call __len__(). ---------- nosy: +benjamin.peterson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15023> _______________________________________ From report at bugs.python.org Thu Jun 7 19:11:48 2012 From: report at bugs.python.org (Mateusz Loskot) Date: Thu, 07 Jun 2012 17:11:48 +0000 Subject: [issue4442] document immutable type subclassing via __new__ In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za> Message-ID: <1339089108.11.0.643894890676.issue4442@psf.upfronthosting.co.za> Changes by Mateusz Loskot <mateusz at loskot.net>: ---------- nosy: +mloskot _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4442> _______________________________________ From report at bugs.python.org Thu Jun 7 19:13:54 2012 From: report at bugs.python.org (R.M.Bianchi) Date: Thu, 07 Jun 2012 17:13:54 +0000 Subject: [issue15028] PySys_SetArgv escapes quotes in argv[] Message-ID: <1339089234.78.0.185097327197.issue15028@psf.upfronthosting.co.za> New submission from R.M.Bianchi <riccardomaria.bianchi at gmail.com>: Embedding Python in C++ I saw that if I pass this string below to the PySys_SetArgv, as one of the command-line arguments passed to an embedded script: "--net-label-name='("DC1","eth1")'" PySys_Argv transforms it escaping the single quotes, and in the Python side I get this value for sys.argv[i]: '--net-label-name=\'("DC1","eth1")\'' It does not seem a problem of converting strings or char in the C++ sides, I checked them. The problem appears just after the PySys_Argv call. === cut === Qt-Debug: python script command-line args: ("/afs/cern.ch/work/r/rbianchi/private/tdaq_4_0_0/dbe/cmt/pm_farm.py", "--safe-hw-tags", "--add='pcatd143'", "--net-label-name='("DC1","eth1")'", "newdb.data.xml") [...] pyout: sys.argv: pyout: pyout: ['/afs/cern.ch/work/r/rbianchi/private/tdaq_4_0_0/dbe/cmt/pm_farm.py', '--safe-hw-tags', "--add='pcatd143'", '--net-label-name=\'("DC1","eth1")\'', 'newdb.data.xml'] === cut === Please notice that the same script works perfectly with the same argument list in stand-alone mode (i.e. not embedded in C++). Please also notice that in the embedded side the problem does not appear if I substitute the string passed as command line parameter from the original one: "--net-label-name='("DC1","eth1")'" to this one below, where I omit a level of quotes and I skip the double quotes: "--net-label-name=('DC1','eth1')" In this last case the embedded script also works fine in the embedded world. It seems to me an issue in PySys_SetArgv, while parsing the strings. But maybe I'm missing something. Best regards, R.M.Bianchi ---------- components: Interpreter Core messages: 162478 nosy: RMBianchi priority: normal severity: normal status: open title: PySys_SetArgv escapes quotes in argv[] type: behavior versions: Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15028> _______________________________________ From report at bugs.python.org Thu Jun 7 19:16:55 2012 From: report at bugs.python.org (Mateusz Loskot) Date: Thu, 07 Jun 2012 17:16:55 +0000 Subject: [issue4442] document immutable type subclassing via __new__ In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za> Message-ID: <1339089415.96.0.0474727789745.issue4442@psf.upfronthosting.co.za> Mateusz Loskot <mateusz at loskot.net> added the comment: Is this report about documenting of the concept of immutable types in Python in general or regarding existing built-in types, like datetime.datetime? Generally, the concept of immutable type with relation to tp_new is mentioned (sneaked) here: 1) http://docs.python.org/release/3.2.2/c-api/typeobj.html "A good rule of thumb is that for immutable types, all initialization should take place in tp_new, while for mutable types, most initialization should be deferred to tp_init." 2) http://www.python.org/dev/peps/pep-0253/ Note that for immutable object types, the initialization cannot be done by the tp_init() slot: this would provide the Python user with a way to change the initialization. Therefore, immutable objects typically have an empty tp_init() implementation and do all their initialization in their tp_new() slot. IMHO, it deserves a dedicated section/chapter in the docs. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4442> _______________________________________ From report at bugs.python.org Thu Jun 7 19:25:09 2012 From: report at bugs.python.org (Mateusz Loskot) Date: Thu, 07 Jun 2012 17:25:09 +0000 Subject: [issue15029] Update Defining New Types chapter according to PEP 253 Message-ID: <1339089909.82.0.778815916296.issue15029@psf.upfronthosting.co.za> New submission from Mateusz Loskot <mateusz at loskot.net>: The chapter '2. Defining New Types" in the Python 3.2 documentation [1] does not cover all important elements, especially in the subsection 2.1.4. Subclassing other types. The accepted PEP 253 [2] provides much more detailed and thorough explanation for Python C API users willing to define and subclass new types, than the official manual. I'd like to suggest update of the manual with information enclosed in the PEP 253. In fact, the PEP's sections like * Preparing a type for subtyping * Creating a subtype of a built-in type in C could be copied with little editing, IMHO. The PEP 253 really seems to be a must-read document for Python C API users. [1] http://docs.python.org/release/3.2.2/extending/newtypes.html [2] http://www.python.org/dev/peps/pep-0253/ ---------- assignee: docs at python components: Documentation messages: 162480 nosy: docs at python, mloskot priority: normal severity: normal status: open title: Update Defining New Types chapter according to PEP 253 type: enhancement versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15029> _______________________________________ From report at bugs.python.org Thu Jun 7 19:27:12 2012 From: report at bugs.python.org (Mateusz Loskot) Date: Thu, 07 Jun 2012 17:27:12 +0000 Subject: [issue15029] Update Defining New Types chapter according to PEP 253 In-Reply-To: <1339089909.82.0.778815916296.issue15029@psf.upfronthosting.co.za> Message-ID: <1339090032.28.0.76700491246.issue15029@psf.upfronthosting.co.za> Mateusz Loskot <mateusz at loskot.net> added the comment: Similar request has been rejected in response to the Issue 621526 [1], but I'm not proposing to include PEP into docs, but to update and improve docs with material discussed in accepted PEPs. [1] http://bugs.python.org/issue621526 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15029> _______________________________________ From report at bugs.python.org Thu Jun 7 19:27:59 2012 From: report at bugs.python.org (Mateusz Loskot) Date: Thu, 07 Jun 2012 17:27:59 +0000 Subject: [issue621526] docs do not include spec info from PEPs Message-ID: <1339090079.71.0.481809744546.issue621526@psf.upfronthosting.co.za> Mateusz Loskot <mateusz at loskot.net> added the comment: I reported issue 15029 [1] which may be related to this one. [1] http://bugs.python.org/issue15029 ---------- nosy: +mloskot _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue621526> _______________________________________ From report at bugs.python.org Thu Jun 7 19:29:39 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 17:29:39 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1339090179.33.0.0778741262699.issue14908@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Updated patch adds a few more tests and improves error handling in C implementation. ---------- nosy: +haypo Added file: http://bugs.python.org/file25858/issue14908.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Thu Jun 7 19:29:51 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 17:29:51 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1339090191.54.0.738301445465.issue14908@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: Removed file: http://bugs.python.org/file25854/issue14908.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Thu Jun 7 20:09:15 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 07 Jun 2012 18:09:15 +0000 Subject: [issue15021] xmlrpc server hangs In-Reply-To: <1339027271.75.0.304876559161.issue15021@psf.upfronthosting.co.za> Message-ID: <1339092555.25.0.938363062173.issue15021@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: What kind of xmlrpc server do you run? And how exactly? Try to set a timeout to all sockets: socket.setdefaulttimeout(10) Does this change something? Which exception (and traceback) do you get? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15021> _______________________________________ From report at bugs.python.org Thu Jun 7 20:14:43 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 18:14:43 +0000 Subject: [issue11823] disassembly needs argument counts on calls with keyword args In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za> Message-ID: <1339092883.54.0.626579909489.issue11823@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Bumping priority as a reminder to get this in. ---------- priority: normal -> high _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11823> _______________________________________ From report at bugs.python.org Thu Jun 7 20:29:05 2012 From: report at bugs.python.org (Ronan Lamy) Date: Thu, 07 Jun 2012 18:29:05 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files Message-ID: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> New submission from Ronan Lamy <ronan.lamy at gmail.com>: PyPycLoader can't read or write .pyc files created by the core import machinery. I'm attaching a failing test case demonstrating the issue: if you import a .py file using standard mechanisms, thus creating a .pyc, and then (in a separate process, say) attempt to make use of that cached file with PyPycLoader, the import fails with 'ValueError: bad marshal data (unknown type code)'. It looks like that there has been a change in the binary format of .pyc files but PyPycLoader wasn't updated. ---------- components: Library (Lib) files: test_PyPyc.diff keywords: patch messages: 162486 nosy: Ronan.Lamy, brett.cannon priority: normal severity: normal status: open title: PyPycLoader can't read cached .pyc files type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25859/test_PyPyc.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Thu Jun 7 20:29:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jun 2012 18:29:37 +0000 Subject: [issue11823] disassembly needs argument counts on calls with keyword args In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za> Message-ID: <E1SchSZ-00080q-If@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 22dc0a433b0e by Alexander Belopolsky in branch 'default': Issue #11823: disassembly now shows argument counts on calls with keyword args http://hg.python.org/cpython/rev/22dc0a433b0e ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11823> _______________________________________ From report at bugs.python.org Thu Jun 7 20:33:03 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 18:33:03 +0000 Subject: [issue11823] disassembly needs argument counts on calls with keyword args In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za> Message-ID: <1339093983.82.0.30164651896.issue11823@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- stage: needs patch -> committed/rejected type: behavior -> enhancement versions: -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11823> _______________________________________ From report at bugs.python.org Thu Jun 7 20:36:25 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 07 Jun 2012 18:36:25 +0000 Subject: [issue11823] disassembly needs argument counts on calls with keyword args In-Reply-To: <1302469900.48.0.983863495872.issue11823@psf.upfronthosting.co.za> Message-ID: <1339094185.92.0.920474084829.issue11823@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11823> _______________________________________ From report at bugs.python.org Thu Jun 7 21:09:36 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 07 Jun 2012 19:09:36 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1339096176.7.0.824698553917.issue15030@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Ronan, can you confirm if 2.7 or 3.2 are affected too? ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Thu Jun 7 21:10:16 2012 From: report at bugs.python.org (Ronan Lamy) Date: Thu, 07 Jun 2012 19:10:16 +0000 Subject: [issue15031] Split .pyc parsing from module loading Message-ID: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> New submission from Ronan Lamy <ronan.lamy at gmail.com>: I think it would be beneficial to extract the handling of the binary format of bytecode files from the rest of the loader/finder code in importlib._bootstrap. That means exposing, internally at least, functions that do nothing more than convert the binary contents of a .pyc file to/from metadata + code object. They would help in testing and implementing alternate loaders and would prevent the kind of code duplication that led to issue 15030. I'm adding a patch implementing extracting a _loads_pyc() function from _bytes_to_bytecode(). Note that: * _loads_pyc() has only one parameter, instead of 5 for _bytes_from_bytecode. * The raising of exceptions is more consistent: _loads_pyc being an IO helper, it never raises ImportError. Thanks to exception chaining, no information is lost, though. Obviously, this should be complemented with a _dumps_pyc(). Then there's the question of whether these functions should be public and what the best interface is - I actually feel that the natural home of both functions is in a lower level module, either imp or marshal. So, should I get on with it, or are there things I overlooked that make this a bad idea? ---------- components: Interpreter Core files: loads_pyc.diff keywords: patch messages: 162489 nosy: Ronan.Lamy, brett.cannon, ncoghlan priority: normal severity: normal status: open title: Split .pyc parsing from module loading type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25860/loads_pyc.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Thu Jun 7 21:23:32 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jun 2012 19:23:32 +0000 Subject: [issue15023] listextend (and therefore list.extend and list.__init__) peek at len before iter In-Reply-To: <1339046592.67.0.693988189804.issue15023@psf.upfronthosting.co.za> Message-ID: <1339097012.5.0.422763620222.issue15023@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15023> _______________________________________ From report at bugs.python.org Thu Jun 7 21:35:16 2012 From: report at bugs.python.org (Akintayo Holder) Date: Thu, 07 Jun 2012 19:35:16 +0000 Subject: [issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za> Message-ID: <1339097716.39.0.817234406876.issue14635@psf.upfronthosting.co.za> Akintayo Holder <akintayo at google.com> added the comment: Is my approach ok or is the plan to follow neologix's suggestion and make one fix that works for all the select.select issues. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14635> _______________________________________ From report at bugs.python.org Thu Jun 7 21:39:26 2012 From: report at bugs.python.org (Ronan Lamy) Date: Thu, 07 Jun 2012 19:39:26 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1339097966.36.0.130697371894.issue15030@psf.upfronthosting.co.za> Ronan Lamy <ronan.lamy at gmail.com> added the comment: 2.7 doesn't have PyPycLoader. For 3.2, it's such a pain to create a working concrete subclass of PyPycLoader that I gave up. But just by reading the code, it doesn't seem affected, as there's no discrepancy with importlib._bootstrap: they both consider that metadata are the first 8 bytes (in default, _bootstrap switched to using 12 bytes). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Thu Jun 7 21:41:53 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jun 2012 19:41:53 +0000 Subject: [issue15028] PySys_SetArgv escapes quotes in argv[] In-Reply-To: <1339089234.78.0.185097327197.issue15028@psf.upfronthosting.co.za> Message-ID: <1339098113.52.0.537144782653.issue15028@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Could you please clarify the inputs and outputs. I can't tell from your description what exact byte string you are passing in from C++ or what exact string you are seeing on the Python side. For example, if: '--net-label-name=\'("DC1","eth1")\'' is the python repr of a string, it is equivalent to the ASCII byte sequence: --net-label-name='("DC1","eth1")' Most likely that is what you are passing in from C++, in which case everything seems to be to be working as expected. So if that is not the case, please clarify. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15028> _______________________________________ From report at bugs.python.org Thu Jun 7 21:42:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jun 2012 19:42:03 +0000 Subject: [issue13854] multiprocessing: SystemExit from child with non-int, non-str arg causes TypeError In-Reply-To: <1327428526.26.0.964378708084.issue13854@psf.upfronthosting.co.za> Message-ID: <E1Scian-0007SR-LY@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 4346cba353b4 by Richard Oudkerk in branch '3.2': Issue #13854: Properly handle non-integer, non-string arg to SystemExit http://hg.python.org/cpython/rev/4346cba353b4 New changeset 3585cb1388f2 by Richard Oudkerk in branch 'default': Merge fixes for #13854 and #12157. http://hg.python.org/cpython/rev/3585cb1388f2 New changeset da5b370f41a1 by Richard Oudkerk in branch '2.7': Issue #13854: Properly handle non-integer, non-string arg to SystemExit http://hg.python.org/cpython/rev/da5b370f41a1 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13854> _______________________________________ From report at bugs.python.org Thu Jun 7 21:42:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jun 2012 19:42:03 +0000 Subject: [issue12157] join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za> Message-ID: <E1Scian-0007SR-LJ@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 1b3d4ffcb4d1 by Richard Oudkerk in branch '3.2': Issue #12157: pool.map() does not handle empty iterable correctly http://hg.python.org/cpython/rev/1b3d4ffcb4d1 New changeset 3585cb1388f2 by Richard Oudkerk in branch 'default': Merge fixes for #13854 and #12157. http://hg.python.org/cpython/rev/3585cb1388f2 New changeset 7ab7836894c4 by Richard Oudkerk in branch '2.7': Issue #12157: pool.map() does not handle empty iterable correctly http://hg.python.org/cpython/rev/7ab7836894c4 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12157> _______________________________________ From report at bugs.python.org Thu Jun 7 22:20:38 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 07 Jun 2012 20:20:38 +0000 Subject: [issue10037] multiprocessing.pool processes started by worker handler stops working In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za> Message-ID: <1339100438.07.0.220290825512.issue10037@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: > I think this issue can be closed, the worker handler is simply borked and > we could open up a new issue deciding how to fix it (merging billiard.Pool > or someting else). OK. I am not sure which option under "Resolution" should be chosen. "Later"? > (btw, Richard, you're sbt? Yes. > I was trying to find your real name to give you credit for the no_execv > patch in billiard) The execv stuff certainly won't go in by Py3.3. There has not been consensus that adding it is a good idea. (I also have the unit tests passing with a "fork server": the server process is forked at the beginning of the program and then forked children of the server process are started on request. It is about 10 times faster then using execv, and almost as fast as simple forking.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10037> _______________________________________ From report at bugs.python.org Thu Jun 7 22:24:06 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Thu, 07 Jun 2012 20:24:06 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1339100646.08.0.847622181305.issue13405@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Hi jcea, Sorry, I've been away from this for a while. I'm getting undefined symbols now while trying to link: ``` (12:47pm) [last: 0] marca at scml-marca:~/src$ hg clone http://hg.python.org/cpython... (12:55pm) [last: 0] marca at scml-marca:~/src$ cd cpython [last: 0] marca at scml-marca:~/src/cpython$ hg tip changeset: 77378:da5b370f41a1 branch: 2.7 tag: tip user: Richard Oudkerk <shibturn at gmail.com> date: Wed Jun 06 19:01:14 2012 +0100 summary: Issue #13854: Properly handle non-integer, non-string arg to SystemExit [last: 0] marca at scml-marca:~/src/cpython$ curl -s http://bugs.python.org/file25203/4a072278b866.diff | patch -p1 patching file .hgignore Hunk #1 succeeded at 81 (offset 8 lines). patching file Doc/library/debug.rst patching file Doc/library/dtrace.rst patching file Include/code.h patching file Include/pydtrace.d patching file Include/pydtrace.h patching file Include/pydtrace_offsets.c patching file Include/pydtrace_offsets.sh patching file Lib/test/dtrace_sample.py patching file Lib/test/test_dtrace.py patching file Makefile.pre.in Hunk #2 succeeded at 462 (offset 1 line). Hunk #3 succeeded at 491 (offset 1 line). Hunk #4 succeeded at 502 (offset 1 line). Hunk #5 succeeded at 607 (offset 17 lines). Hunk #6 succeeded at 733 (offset 19 lines). Hunk #7 succeeded at 1429 (offset 45 lines). Hunk #8 succeeded at 1461 (offset 45 lines). patching file Modules/dtracemodule.c patching file Modules/gcmodule.c Hunk #2 FAILED at 791. Hunk #3 succeeded at 1059 with fuzz 1 (offset 112 lines). 1 out of 3 hunks FAILED -- saving rejects to file Modules/gcmodule.c.rej patching file Objects/codeobject.c patching file Objects/frameobject.c Hunk #1 succeeded at 714 (offset 2 lines). patching file Objects/typeobject.c patching file Python/ceval.c Hunk #9 succeeded at 3149 (offset 7 lines). Hunk #10 succeeded at 3842 (offset 12 lines). Hunk #11 succeeded at 3911 (offset 12 lines). patching file configure patching file configure.ac patching file pyconfig.h.in patching file setup.py Hunk #1 succeeded at 575 (offset 4 lines). [last: 0] marca at scml-marca:~/src/cpython$ ./configure --enable-framework && make ... gcc -o Python.framework/Versions/3.3/Python -dynamiclib \ -all_load libpython3.3m.a -Wl,-single_module \ -install_name /Library/Frameworks/Python.framework/Versions/3.3/Python \ -compatibility_version 3.3 \ -current_version 3.3 \ -framework CoreFoundation -ldl -framework CoreFoundation; Undefined symbols: "_PYTHON_LINE_ENABLED", referenced from: _PyEval_EvalFrameEx in libpython3.3m.a(ceval.o) _PyEval_EvalFrameEx in libpython3.3m.a(ceval.o) _PyEval_EvalFrameEx in libpython3.3m.a(ceval.o) _PyEval_EvalFrameEx in libpython3.3m.a(ceval.o) _PyEval_EvalFrameEx in libpython3.3m.a(ceval.o) ``` ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13405> _______________________________________ From report at bugs.python.org Thu Jun 7 22:38:40 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 07 Jun 2012 20:38:40 +0000 Subject: [issue8865] select.poll is not thread safe In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za> Message-ID: <1339101520.18.0.282666949784.issue8865@psf.upfronthosting.co.za> Changes by Gregory P. Smith <greg at krypto.org>: ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8865> _______________________________________ From report at bugs.python.org Thu Jun 7 22:57:48 2012 From: report at bugs.python.org (Ask Solem) Date: Thu, 07 Jun 2012 20:57:48 +0000 Subject: [issue10037] multiprocessing.pool processes started by worker handler stops working In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za> Message-ID: <1339102668.87.0.500179191549.issue10037@psf.upfronthosting.co.za> Ask Solem <ask at celeryproject.org> added the comment: Later works, or just close it. I can open up a new issue to merge the improvements in billiard later. > The execv stuff certainly won't go in by Py3.3. There has not been > consensus that adding it is a good idea. > (I also have the unit tests passing with a "fork server": the server >process is forked at the beginning of the program and then forked >children of the server process are started on request. It is about 10 >times faster then using execv, and almost as fast as simple forking.) Ah, a working 'fork server' would be just as good. Btw, Billiard now supports running Pool without threads, using epoll/kqueue/select instead. So Celery uses that when it can be nonblocking, and execv when it can't. It performs way better without threads, and in addition shutdown + replacing worker processes is much more responsive. Changing the default Pool is not going to happen, but ncluding a simple select() based Pool would be possible, and then it could also easily work with Twisted, Eventlet, Gevent, etc. (especially now that the Connection is rewritten in pure python). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10037> _______________________________________ From report at bugs.python.org Thu Jun 7 23:00:03 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 07 Jun 2012 21:00:03 +0000 Subject: [issue15032] Provide a select.select implemented using select.poll Message-ID: <1339102803.48.0.0979109123526.issue15032@psf.upfronthosting.co.za> New submission from Gregory P. Smith <greg at krypto.org>: Many random bits of the standard library were originally written using select.select. This is an ancient API that is available everywhere, but these days you'd be hard pressed to find _any_ system that does not implement the superior poll() API which does not suffer from the file descriptor limits problem of select(). A select.select() work-a-like should be possible to write that is implemented using poll.poll(). I am attaching my untested work in progress version of something like that as I don't have time to work on this further at the moment. Someone else can pick it up if desired. (sorry about the code being in Google style rather than PEP-8) ---------- files: poll_select-gps001.txt messages: 162498 nosy: gregory.p.smith priority: normal severity: normal status: open title: Provide a select.select implemented using select.poll type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25861/poll_select-gps001.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15032> _______________________________________ From report at bugs.python.org Thu Jun 7 23:01:26 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 07 Jun 2012 21:01:26 +0000 Subject: [issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za> Message-ID: <1339102886.84.0.0250429967407.issue14635@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: I think your approach is fine. BTW for anyone who wants to chase the larger idea of dealing with all select.select use, take a look at the prototype for a select.select() implemented using poll.poll() that I just put in http://bugs.python.org/issue15032. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14635> _______________________________________ From report at bugs.python.org Thu Jun 7 23:08:11 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Thu, 07 Jun 2012 21:08:11 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1339103291.18.0.0333682604068.issue13405@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: The 2.7 patch doesn't apply cleanly for me against the latest on the 2.7 branch: [last: 0] marca at scml-marca:~/src$ hg clone http://hg.python.org/cpython && cd cpython && hg update 2.7 && hg branch && hg tip && curl -s http://bugs.python.org/file25192/aa2dcffa267f.diff | patch -p1 destination directory: cpython requesting all changes adding changesets adding manifests adding file changes added 77379 changesets with 172430 changes to 9646 files (+1 heads) updating to branch default 3917 files updated, 0 files merged, 0 files removed, 0 files unresolved 3574 files updated, 0 files merged, 945 files removed, 0 files unresolved 2.7 changeset: 77378:da5b370f41a1 branch: 2.7 tag: tip user: Richard Oudkerk <shibturn at gmail.com> date: Wed Jun 06 19:01:14 2012 +0100 summary: Issue #13854: Properly handle non-integer, non-string arg to SystemExit patching file .hgignore patching file Doc/library/debug.rst patching file Doc/library/dtrace.rst patching file Include/code.h patching file Include/pydtrace.d patching file Include/pydtrace.h patching file Include/pydtrace_offsets.c patching file Include/pydtrace_offsets.sh patching file Lib/test/dtrace_sample.py patching file Lib/test/test_dtrace.py patching file Makefile.pre.in patching file Modules/dtracemodule.c patching file Modules/gcmodule.c Hunk #2 succeeded at 873 (offset 51 lines). Hunk #3 succeeded at 1038 (offset 54 lines). patching file Objects/classobject.c Hunk #2 succeeded at 557 (offset 10 lines). Hunk #3 succeeded at 622 (offset 10 lines). Hunk #4 succeeded at 676 (offset 10 lines). Hunk #5 succeeded at 758 (offset 10 lines). patching file Objects/codeobject.c patching file Objects/typeobject.c Hunk #4 succeeded at 931 (offset 5 lines). patching file Python/ceval.c patching file Python/sysmodule.c patching file configure Hunk #1 succeeded at 619 (offset 8 lines). Hunk #2 succeeded at 768 (offset 8 lines). Hunk #3 succeeded at 1444 (offset 8 lines). Hunk #4 FAILED at 2616. Hunk #5 FAILED at 3548. Hunk #6 FAILED at 3663. Hunk #7 FAILED at 3706. Hunk #8 FAILED at 3765. Hunk #9 FAILED at 3817. Hunk #10 FAILED at 4360. Hunk #11 FAILED at 6713. Hunk #12 FAILED at 6746. Hunk #13 FAILED at 6779. Hunk #14 FAILED at 6812. Hunk #15 FAILED at 6845. Hunk #16 FAILED at 6878. Hunk #17 FAILED at 6911. Hunk #18 FAILED at 6944. Hunk #19 FAILED at 6977. Hunk #20 FAILED at 7037. Hunk #21 FAILED at 7098. Hunk #22 FAILED at 7159. Hunk #23 FAILED at 7207. Hunk #24 FAILED at 7248. Hunk #25 FAILED at 7310. Hunk #26 FAILED at 7381. Hunk #27 succeeded at 9464 (offset 8 lines). Hunk #28 FAILED at 12456. Hunk #29 FAILED at 12508. Hunk #30 FAILED at 12627. Hunk #31 FAILED at 12893. Hunk #32 FAILED at 14693. Hunk #33 FAILED at 15008. Hunk #34 FAILED at 15036. Hunk #35 FAILED at 15063. 31 out of 35 hunks FAILED -- saving rejects to file configure.rej can't find file to patch at input line 2128 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r 70274d53c1dd -r aa2dcffa267f configure.in |--- a/configure.in Mon Apr 09 19:04:04 2012 -0400 |+++ b/configure.in Thu Apr 12 12:51:51 2012 +0200 -------------------------- File to patch: ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13405> _______________________________________ From report at bugs.python.org Thu Jun 7 23:13:39 2012 From: report at bugs.python.org (Kamil Kisiel) Date: Thu, 07 Jun 2012 21:13:39 +0000 Subject: [issue15033] Different exit status when using -m Message-ID: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za> New submission from Kamil Kisiel <kamil at kamilkisiel.net>: Python returns a different exit status when an exception is raised and -m is used as opposed to just running a module. A short example, let's call it foo.py: def main(): raise ValueError() if __name__ == '__main__': main() When run with python foo.py the exit status of the process is 1. If run with python -mfoo the exit status of the process is 255. ---------- messages: 162501 nosy: kisielk priority: normal severity: normal status: open title: Different exit status when using -m type: behavior versions: Python 2.6, Python 2.7, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15033> _______________________________________ From report at bugs.python.org Thu Jun 7 23:13:43 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 07 Jun 2012 21:13:43 +0000 Subject: [issue10037] multiprocessing.pool processes started by worker handler stops working In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za> Message-ID: <1339103623.51.0.264462450354.issue10037@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: > Ah, a working 'fork server' would be just as good. Only problem is that it depends on fd passing which is apparently broken on MacOSX. > Btw, Billiard now supports running Pool without threads, using > epoll/kqueue/select instead. So Celery uses that when it can be > nonblocking, and execv when it can't. It performs way better without > threads, and in addition shutdown + replacing worker processes is much > more responsive. If it were not for Windows I would have tried to avoid using threads. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10037> _______________________________________ From report at bugs.python.org Thu Jun 7 23:28:56 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 07 Jun 2012 21:28:56 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1339104536.25.0.171187257783.issue15030@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Could you write a patch for 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Thu Jun 7 23:34:11 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Thu, 07 Jun 2012 21:34:11 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1339104851.69.0.283102835327.issue13405@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: If I do `/configure --with-dtrace --enable-framework && make` then I get: ``` ... gcc -c -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c Modules/gcmodule.c:1088: error: conflicting types for ?collect? Modules/gcmodule.c:849: error: previous definition of ?collect? was here Modules/gcmodule.c: In function ?collect?: Modules/gcmodule.c:1093: warning: implicit declaration of function ?collect2? make: *** [Modules/gcmodule.o] Error 1 ``` ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13405> _______________________________________ From report at bugs.python.org Thu Jun 7 23:34:30 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 07 Jun 2012 21:34:30 +0000 Subject: [issue15032] Provide a select.select implemented using select.poll In-Reply-To: <1339102803.48.0.0979109123526.issue15032@psf.upfronthosting.co.za> Message-ID: <1339104870.15.0.668690886459.issue15032@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15032> _______________________________________ From report at bugs.python.org Thu Jun 7 23:58:03 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Thu, 07 Jun 2012 21:58:03 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1339106283.32.0.679891583546.issue13405@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: I hacked around the previous error (duplicate definitions of `collect`) and then ran into: gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o ./Include/pydtrace_offsets \ ./Include/pydtrace_offsets.c ./Include/pydtrace_offsets.c: In function ?main?: ./Include/pydtrace_offsets.c:26: warning: format ?%d? expects type ?int?, but argument 2 has type ?long int? ./Include/pydtrace_offsets.c:29: warning: format ?%d? expects type ?int?, but argument 2 has type ?long unsigned int? ./Include/pydtrace_offsets.c:31: warning: implicit declaration of function ?offsetof? ./Include/pydtrace_offsets.c:31: error: expected expression before ?PyCompactUnicodeObject? ./Include/pydtrace_offsets.c:33: error: expected expression before ?PyCompactUnicodeObject? make: *** [Include/pydtrace_offsets.h] Error 1 I was able to fix this by adding "#include <stddef.h>". ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13405> _______________________________________ From report at bugs.python.org Fri Jun 8 00:04:30 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 07 Jun 2012 22:04:30 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1339106670.64.0.988322680009.issue13405@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Marc, please, check your GTalk/XMPP window :-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13405> _______________________________________ From report at bugs.python.org Fri Jun 8 00:18:20 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 07 Jun 2012 22:18:20 +0000 Subject: [issue12157] join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za> Message-ID: <1339107500.12.0.273678595857.issue12157@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12157> _______________________________________ From report at bugs.python.org Fri Jun 8 00:18:42 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 07 Jun 2012 22:18:42 +0000 Subject: [issue13854] multiprocessing: SystemExit from child with non-int, non-str arg causes TypeError In-Reply-To: <1327428526.26.0.964378708084.issue13854@psf.upfronthosting.co.za> Message-ID: <1339107522.35.0.832089456247.issue13854@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13854> _______________________________________ From report at bugs.python.org Fri Jun 8 01:18:39 2012 From: report at bugs.python.org (Ankit Toshniwal) Date: Thu, 07 Jun 2012 23:18:39 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> Message-ID: <1339111119.02.0.857676610651.issue15009@psf.upfronthosting.co.za> Ankit Toshniwal <ankitoshniwal at gmail.com> added the comment: Hello, Did some initial investigation, so looks like as per the code in parse.py, under the function urlunsplit, we take the 5-tuple returned by urlsplit . In the case of foo we get: SplitResult(scheme='yelp', netloc='', path='/foo', query='', fragment='') Now this tuple is passed to urlunsplit. We have a if statement under the urlunsplit function if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'): which checks if the netloc exists in the url (in our case it does not) then we check if the scheme in the url is part of the uses_netloc list (predefined list in parse.py with the list of common types of schemes used like http, ftp, file, rsync etc). In our case since yelp is not part of it we fail at the if statement and then we just return the url instead of modifying it. What we need was that if the above statement fails we do an else which does something like this: if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'): if url and url[:1] != '/': url = '/' + url url = '//' + (netloc or '') + url else: if url and url[:1] != '/': url = '/' + url url = '//' + (netloc or '') + url In that case we get the right url back. After changing the code here is what i get on local dev machines: >>> urlunparse(urlparse('yelp:///foo')) 'yelp:///foo' >>> urlunsplit(urlsplit('file:///tmp')) 'file:///tmp' >>> urlunsplit(urlsplit('yelp:///foo')) 'yelp:///foo' Thanks, Ankit. P.S : I am new to python trying to learn it and also work on small projects let me know what you think if this is the right approach. ---------- nosy: +ankitoshniwal Added file: http://bugs.python.org/file25862/parse.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15009> _______________________________________ From report at bugs.python.org Fri Jun 8 01:42:55 2012 From: report at bugs.python.org (Ankit Toshniwal) Date: Thu, 07 Jun 2012 23:42:55 +0000 Subject: [issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups In-Reply-To: <1232404142.93.0.545475464378.issue5004@psf.upfronthosting.co.za> Message-ID: <1339112575.08.0.274027462409.issue5004@psf.upfronthosting.co.za> Ankit Toshniwal <ankitoshniwal at gmail.com> added the comment: I cannot reproduce this issue. I just tested this on my mac. atoshniw at prusev-mn:~/Documents/code/python-dev/bin #hostname -f prusev-mn.helloworld.com atoshniw at prusev-mn:~/Documents/code/python-dev/bin #python Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.getfqdn() 'prusev-mn.helloworld.com' ---------- nosy: +ankitoshniwal _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5004> _______________________________________ From report at bugs.python.org Fri Jun 8 01:55:12 2012 From: report at bugs.python.org (Buck Golemon) Date: Thu, 07 Jun 2012 23:55:12 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> Message-ID: <1339113312.89.0.803896569173.issue15009@psf.upfronthosting.co.za> Buck Golemon <buck at yelp.com> added the comment: Well i think the real issue is that you can't enumerate the protocals that "use netloc". All protocols are allowed to have a netloc. the smb: protocol certainly does, but it's not in the list. The core issue is that smb:/foo and smb:///foo are different urls, and should be represented differently when split. The /// form has a netloc, it's just the empty-string. The single-slash form has no netloc, so I propose that urlsplit('smb:/foo') return SplitResult(scheme='smb', netloc=None, path='/foo', query='', fragment='') ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15009> _______________________________________ From report at bugs.python.org Fri Jun 8 02:05:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jun 2012 00:05:20 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <E1ScmhU-0006St-E9@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 02b4c62ce393 by Terry Jan Reedy in branch '3.2': Issue #12510: Revise and triple # of calltip tests, with an eye to unittest http://hg.python.org/cpython/rev/02b4c62ce393 New changeset 03b5f75ddac7 by Terry Jan Reedy in branch 'default': Merge from 3.2, #12510 http://hg.python.org/cpython/rev/03b5f75ddac7 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Fri Jun 8 02:14:30 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jun 2012 00:14:30 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1339114470.31.0.527073505851.issue12510@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: I decided to commit the current patch (i12510c.test.diff + NEWS changes) as is. Another change is needed to correctly delete the first arg of all methods, not just instance methods with the first arg named 'self'. (In the current new classmethod test, I just allowed non-removal of 'cls'. There should also be a test with a variant of 'self'.) In _self_pat = re.compile('self\,?\s*'), 'self' in the pattern should be replaced by '(xxx', where 'xxx' is the pattern that matches an identifier. (And add '(' to the replacement pattern.) If anyone can quickly tell me what that is, that would be helpful. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Fri Jun 8 03:03:57 2012 From: report at bugs.python.org (Ronan Lamy) Date: Fri, 08 Jun 2012 01:03:57 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1339117437.46.0.0397519198333.issue15030@psf.upfronthosting.co.za> Ronan Lamy <ronan.lamy at gmail.com> added the comment: My preferred solution would be to use to use the functions I describe in issue 15031. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Fri Jun 8 03:22:05 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jun 2012 01:22:05 +0000 Subject: [issue15034] tutorial should use best practices in user defined execeptions section Message-ID: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> New submission from R. David Murray <rdmurray at bitdance.com>: And I wish I knew what those were. ---------- assignee: docs at python components: Documentation messages: 162513 nosy: docs at python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: tutorial should use best practices in user defined execeptions section type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Fri Jun 8 03:30:22 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 08 Jun 2012 01:30:22 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1339119022.9.0.643900888034.issue15031@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Fri Jun 8 03:30:43 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 Jun 2012 01:30:43 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1339119043.35.0.586981284043.issue14626@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Here's a nice fresh minor update. Notes on this third patch: * The docstrings are now done. * I discovered that fchmodat() doesn't actually support AT_SYMLINK_NOFOLLOW! glibc documents using the flag, then comically notes that it doesn't actually work. Specifying it results in ENOTSUP every time. os.chmod() now accomodates this; it throws NotImplementedError if it detects this situation. However it should also Just Work once glibc supports it. * While editing the docstrings, I noticed that several of them had old-style octal constants ;-) I fixed 'em. * I added support for the remove_dir argument to unlink/remove on Windows. I also made it work on non-Windows even when unlinkat() is not available. ---------- Added file: http://bugs.python.org/file25863/larry.os.keyword.arguments.collapse.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Fri Jun 8 03:31:32 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 08 Jun 2012 01:31:32 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1339119092.17.0.713858577775.issue15030@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- dependencies: +Split .pyc parsing from module loading _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Fri Jun 8 03:47:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jun 2012 01:47:10 +0000 Subject: [issue8652] Minor improvements to the "Handling Exceptions" part of the tutorial In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za> Message-ID: <E1ScoI8-0004uC-Ml@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset b873afe640e2 by R David Murray in branch '2.7': #8652: update errors tutorial. http://hg.python.org/cpython/rev/b873afe640e2 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8652> _______________________________________ From report at bugs.python.org Fri Jun 8 03:51:54 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jun 2012 01:51:54 +0000 Subject: [issue8652] Minor improvements to the "Handling Exceptions" part of the tutorial In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za> Message-ID: <1339120314.93.0.0163988748314.issue8652@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: The Python3 tutorial was already fixed, and the explanation of the parens is not needed there since the "old syntax" is not supported. I did not do any reordering since the use of 'as' immediately follows in the text and seems to make fine sense as is. Actually, it now makes more sense than the equivalent exposition in the Python3 docs, where the paragraph is absent. Thanks for the patch, Marien. ---------- nosy: +r.david.murray resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed type: -> behavior versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8652> _______________________________________ From report at bugs.python.org Fri Jun 8 04:49:26 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jun 2012 02:49:26 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1339123766.27.0.656719017084.issue15031@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: So the problem with the function is that had this been implemented in Python 3.2 it already would be outdated thanks to the 3.3 change of storing the file size in the .pyc file, and simply changing the length of the sequence returned would probably break code. I have thought about exposing something like this over the years, and I always come back to the conclusion that it is really touchy and the best you could do is pass in the data and info you have from the source and either raise the proper exception or return the code object/bytes. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Fri Jun 8 04:57:11 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jun 2012 02:57:11 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1339124231.16.0.180208868704.issue15030@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: The format did change and importlib.abc.PyPycLoader was not subsequently updated. Problem is that the ABC has been deprecated and given backwards-compatibility instructions for Python 3.1, so I don't know if it should be considered a priority to fix this to read .pyc files created by other loaders instead of just the .pyc files it creates on its own when it implements write_bytecode(). ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Fri Jun 8 05:27:20 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jun 2012 03:27:20 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> Message-ID: <1339126040.04.0.0709188019173.issue15009@psf.upfronthosting.co.za> Changes by Senthil Kumaran <senthil at uthcode.com>: ---------- assignee: -> orsenthil nosy: +orsenthil _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15009> _______________________________________ From report at bugs.python.org Fri Jun 8 05:36:58 2012 From: report at bugs.python.org (Shawn Brown) Date: Fri, 08 Jun 2012 03:36:58 +0000 Subject: [issue14998] pprint._safe_key is not always safe enough In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za> Message-ID: <1339126618.48.0.412920947298.issue14998@psf.upfronthosting.co.za> Shawn Brown <03sjbrown at gmail.com> added the comment: Here's a patch for 3.3 -- as well as two new assertions in test_pprint.py The added try/catch also fixes the issues mentioned in issue 10017 so I added a test for that case as well. ---------- keywords: +patch Added file: http://bugs.python.org/file25864/pprint_safe_key.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14998> _______________________________________ From report at bugs.python.org Fri Jun 8 08:59:54 2012 From: report at bugs.python.org (Catalin Iacob) Date: Fri, 08 Jun 2012 06:59:54 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1339138794.41.0.752470212998.issue15014@psf.upfronthosting.co.za> Changes by Catalin Iacob <iacobcatalin at gmail.com>: ---------- nosy: +catalin.iacob _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15014> _______________________________________ From report at bugs.python.org Fri Jun 8 10:50:03 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 08 Jun 2012 08:50:03 +0000 Subject: [issue15034] tutorial should use best practices in user defined execeptions section In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1339145403.51.0.717057923533.issue15034@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Fri Jun 8 11:22:51 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 08 Jun 2012 09:22:51 +0000 Subject: [issue15035] array.array of UCS2 values Message-ID: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za> New submission from Ronald Oussoren <ronaldoussoren at mac.com>: I'm sometimes using an array.array with format character "u" as a writable backing store for buffers shared with platform APIs that access buffers of UCS2 values. This works fine in python 3.2 and earlier with a ucs2 build of python, but no longer works with python 3.3 because the "u" character explicitly selects a UCS4 representation in that version. An example of how I use this is using PyObjC on MacOSX, for example: b = array.array('u', "hello world") s = CFStringCreateMutableWithExternalCharactersNoCopy( None, b, len(b), len(b), kCFAllocatorNull) "s" now refers to a mutable Objective-C string that uses "b" as its backing store. It would be nice if there were a format code that would allow me to do this with Python 3.3, for example b = array.array("U", ...) (BTW. I'm sorry if this is a duplicate, searching for "array.array" on the tracker results in a lot of hits, most of which have nothing to do with the array module) ---------- components: Extension Modules messages: 162520 nosy: ronaldoussoren priority: low severity: normal status: open title: array.array of UCS2 values type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15035> _______________________________________ From report at bugs.python.org Fri Jun 8 11:46:30 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 08 Jun 2012 09:46:30 +0000 Subject: [issue15035] array.array of UCS2 values In-Reply-To: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za> Message-ID: <1339148790.83.0.853030903537.issue15035@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: See also #13072 and the discussion starting at: http://mail.python.org/pipermail/python-dev/2012-March/117390.html I think the priority should be "high", since the current behavior doesn't preserve the status quo. Also, PEP-3118 suggests 'u' for UCS2 and 'w' for UCS4. ---------- nosy: +skrah _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15035> _______________________________________ From report at bugs.python.org Fri Jun 8 11:48:02 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 08 Jun 2012 09:48:02 +0000 Subject: [issue15035] array.array of UCS2 values In-Reply-To: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za> Message-ID: <1339148882.35.0.0831179149331.issue15035@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Hmm, obviously the discussion starts here: http://mail.python.org/pipermail/python-dev/2012-March/117376.html ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15035> _______________________________________ From report at bugs.python.org Fri Jun 8 13:59:11 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 08 Jun 2012 11:59:11 +0000 Subject: [issue12897] Support for iterators in multiprocessing map In-Reply-To: <1315224105.15.0.691135308397.issue12897@psf.upfronthosting.co.za> Message-ID: <1339156751.22.0.761549883855.issue12897@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: If you want lazy operation then you should use imap(f, it[, chunksize]) rather than using map_async(f, it). This will return an iterator rather than a list. Also, the iterator's next() method has a timeout argument. (chunksize is the number of items which get sent to a worker in each batch, with 1 being the default.) ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12897> _______________________________________ From report at bugs.python.org Fri Jun 8 14:06:33 2012 From: report at bugs.python.org (Laurent Duchesne) Date: Fri, 08 Jun 2012 12:06:33 +0000 Subject: [issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move In-Reply-To: <1333576900.91.0.0583021085072.issue14499@psf.upfronthosting.co.za> Message-ID: <1339157193.4.0.742282288181.issue14499@psf.upfronthosting.co.za> Changes by Laurent Duchesne <laurent.duchesne at gmail.com>: ---------- nosy: +Laurent.Duchesne _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14499> _______________________________________ From report at bugs.python.org Fri Jun 8 14:21:31 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 08 Jun 2012 12:21:31 +0000 Subject: [issue7474] multiprocessing.managers.SyncManager managed object creation fails when started outside of invoked file In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za> Message-ID: <1339158091.33.0.0893774817829.issue7474@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7474> _______________________________________ From report at bugs.python.org Fri Jun 8 14:31:38 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:31:38 +0000 Subject: [issue14852] json and ElementTree parsers misbehave on streams containing more than a single object In-Reply-To: <1337362162.37.0.214988903095.issue14852@psf.upfronthosting.co.za> Message-ID: <1339158698.43.0.957963212239.issue14852@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14852> _______________________________________ From report at bugs.python.org Fri Jun 8 14:32:06 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:32:06 +0000 Subject: [issue14006] Improve the documentation of xml.etree.ElementTree In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za> Message-ID: <1339158726.94.0.309631014139.issue14006@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14006> _______________________________________ From report at bugs.python.org Fri Jun 8 14:32:29 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:32:29 +0000 Subject: [issue14078] Add 'sourceline' property to xml.etree Elements In-Reply-To: <1329863134.79.0.699697784351.issue14078@psf.upfronthosting.co.za> Message-ID: <1339158749.68.0.198504280238.issue14078@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- resolution: -> wont fix stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14078> _______________________________________ From report at bugs.python.org Fri Jun 8 14:34:07 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:34:07 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1339158847.84.0.742732558586.issue14377@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: Any progress, or can this issue be closed? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14377> _______________________________________ From report at bugs.python.org Fri Jun 8 14:36:44 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:36:44 +0000 Subject: [issue11379] Remove "lightweight" from minidom description In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za> Message-ID: <1339159004.07.0.552900020399.issue11379@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- nosy: -eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11379> _______________________________________ From report at bugs.python.org Fri Jun 8 14:38:10 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:38:10 +0000 Subject: [issue1040439] Missing documentation on how to link with libpython Message-ID: <1339159090.23.0.702795474397.issue1040439@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- nosy: -eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1040439> _______________________________________ From report at bugs.python.org Fri Jun 8 14:38:16 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:38:16 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1339159096.62.0.854745192829.issue14097@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- nosy: -eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14097> _______________________________________ From report at bugs.python.org Fri Jun 8 14:38:34 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:38:34 +0000 Subject: [issue13455] Reorganize tracker docs in the devguide In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za> Message-ID: <1339159114.11.0.780658377455.issue13455@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- nosy: -eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13455> _______________________________________ From report at bugs.python.org Fri Jun 8 14:38:40 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 08 Jun 2012 12:38:40 +0000 Subject: [issue12907] Update test coverage devguide page In-Reply-To: <1315284413.51.0.757189280849.issue12907@psf.upfronthosting.co.za> Message-ID: <1339159120.63.0.988880196706.issue12907@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- nosy: -eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12907> _______________________________________ From report at bugs.python.org Fri Jun 8 14:46:22 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 08 Jun 2012 12:46:22 +0000 Subject: [issue8289] multiprocessing.Process.__init__ pickles all arguments In-Reply-To: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za> Message-ID: <1339159582.81.0.275914203524.issue8289@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: As long as you don't pass the arguments on to Process.__init__() when you call it there should be no problem. The following program works, but will fail with RuntimeError if you uncomment the comment line: from multiprocessing import Process class Unpicklable(object): def __reduce__(self): raise RuntimeError class MyProcess(Process): def __init__(self, foo, unpicklable_bar): Process.__init__(self, #args=(foo, unpicklable_bar) ) self.foo = foo self.baz = str(unpicklable_bar) def run(self): print(self.foo) print(self.baz) if __name__ == '__main__': p = MyProcess([1,2,3], Unpicklable()) p.start() p.join() ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8289> _______________________________________ From report at bugs.python.org Fri Jun 8 15:22:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jun 2012 13:22:04 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <E1Scz8c-00067o-Ob@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 4aeb5b9b62d7 by Hynek Schlawack in branch 'default': #14814: Remove redundant code from ipaddress.IPv6Network http://hg.python.org/cpython/rev/4aeb5b9b62d7 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Fri Jun 8 15:40:27 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 08 Jun 2012 13:40:27 +0000 Subject: [issue13532] In IDLE, sys.stdout.write and sys.stderr can write any pickleable object In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za> Message-ID: <1339162827.17.0.719830127875.issue13532@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: @Roger Serwy >> Does anyone know a good way to make the exception render as: "must be str, not int" instead of "must be str, not <class 'int'>" ? Use s.__name__ rather than type(s) for the type name e.g. -raise TypeError('must be str, not %s' % type(s)) +raise TypeError('must be str, not %s' % s.__name__) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13532> _______________________________________ From report at bugs.python.org Fri Jun 8 16:18:55 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 08 Jun 2012 14:18:55 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between Message-ID: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> New submission from Petri Lehtinen <petri at digip.org>: test_mbox is an mbox mailbox with a few messages in it. >>> import mailbox >>> inbox = mailbox.mbox('test_mbox') >>> inbox.lock() >>> inbox.popitem() (0, <mailbox.mboxMessage instance at 0x7f78016bc680>) >>> inbox.flush() >>> inbox.unlock() >>> inbox.lock() >>> inbox.popitem() (1, <mailbox.mboxMessage instance at 0x7f7801653320>) >>> inbox.flush() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/mailbox.py", line 633, in flush (self._file_length, cur_len)) mailbox.ExternalClashError: Size of mailbox file changed (expected 141289, found 141147) ---------- components: Library (Lib) messages: 162528 nosy: petri.lehtinen priority: normal severity: normal status: open title: mailbox.mbox fails to pop two items in a row, flushing in between versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Fri Jun 8 16:20:08 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 08 Jun 2012 14:20:08 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <1339165208.04.0.737329985276.issue15036@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Actually, you don't even need to unlock() and lock() the mailbox before the second popitem() and flush(). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Fri Jun 8 16:28:01 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 08 Jun 2012 14:28:01 +0000 Subject: [issue8028] self.terminate() from a multiprocessing.Process raises AttributeError exception In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za> Message-ID: <1339165681.59.0.401556356903.issue8028@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: One issue with sys.exit() is that it only makes the current thread exit. Even when called in the main thread, the program will wait for non-daemon threads to finish. A closer equivalent to terminate() would be os.kill(os.getpid(), signal.SIGTERM). The problem with minCrashing.py on Windows is that you are inheriting from Queue which has a __reduce__ method. Your Process class is trying to use Queue.__reduce__ to pickle itself. You should really just do "self._queue = Queue()" instead of inheriting from Queue. ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8028> _______________________________________ From report at bugs.python.org Fri Jun 8 16:44:38 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 08 Jun 2012 14:44:38 +0000 Subject: [issue10133] multiprocessing: conn_recv_string() broken error handling In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za> Message-ID: <1339166678.42.0.680023918851.issue10133@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10133> _______________________________________ From report at bugs.python.org Fri Jun 8 17:04:49 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jun 2012 15:04:49 +0000 Subject: [issue1167300] Error "exec"ing python code Message-ID: <1339167889.41.0.825141034026.issue1167300@psf.upfronthosting.co.za> Changes by Terry J. Reedy <tjreedy at udel.edu>: ---------- superseder: -> An inconsistency with nested scopes _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1167300> _______________________________________ From report at bugs.python.org Fri Jun 8 17:37:01 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 08 Jun 2012 15:37:01 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1339169822.0.0.424975954014.issue14908@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Added ReST documentation. Will commit soon. Merging nosy list from issue 2736. ---------- nosy: +Jay.Taylor, Neil Muller, amaury.forgeotdarc, andersjm, catlee, davidfraser, erik.stephens, guettli, hodgestar, jribbens, mark.dickinson, ping, pitrou, python-dev, steve.roberts, tim_one, tomster, vivanov, werneck stage: patch review -> commit review Added file: http://bugs.python.org/file25865/issue14908.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Fri Jun 8 17:37:16 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 08 Jun 2012 15:37:16 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1339169836.9.0.762724321267.issue14908@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: Removed file: http://bugs.python.org/file25858/issue14908.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Fri Jun 8 18:08:32 2012 From: report at bugs.python.org (John Bollinger) Date: Fri, 08 Jun 2012 16:08:32 +0000 Subject: [issue15037] test_curses fails with OverflowError Message-ID: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> New submission from John Bollinger <John.Bollinger at stJude.org>: I encountered this test failure while attempting to verify a patch for a separate issue, and I found that it occurs with the unmodified source on the default branch: LD_LIBRARY_PATH="$PWD" ./python -bb -Wd -m test -r -w -uall -v test_curses == CPython 3.3.0a4+ (default:4aeb5b9b62d7, Jun 8 2012, 10:23:35) [GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] == Linux-2.6.32-220.4.1.el6.x86_64-x86_64-with-centos-6.2-Final little-endian == /home/jbolling/cpython/build/test_python_26873 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=2, quiet=0, hash_randomization=1) Using random seed 3072318 [1/1] test_curses test test_curses crashed -- Traceback (most recent call last): File "/home/jbolling/cpython/Lib/test/regrtest.py", line 1237, in runtest_inner test_runner() File "/home/jbolling/cpython/Lib/test/test_curses.py", line 338, in test_main main(stdscr) File "/home/jbolling/cpython/Lib/test/test_curses.py", line 324, in main test_unget_wch(stdscr) File "/home/jbolling/cpython/Lib/test/test_curses.py", line 283, in test_unget_wch read = chr(read) OverflowError: signed integer is greater than maximum 1 test failed: test_curses Re-running failed tests in verbose mode Re-running test 'test_curses' in verbose mode test test_curses crashed -- Traceback (most recent call last): File "/home/jbolling/cpython/Lib/test/regrtest.py", line 1237, in runtest_inner test_runner() File "/home/jbolling/cpython/Lib/test/test_curses.py", line 338, in test_main main(stdscr) File "/home/jbolling/cpython/Lib/test/test_curses.py", line 324, in main test_unget_wch(stdscr) File "/home/jbolling/cpython/Lib/test/test_curses.py", line 283, in test_unget_wch read = chr(read) OverflowError: signed integer is greater than maximum [123272 refs] Python was built and the tests run on CentOS 6.2 / x86_64, using the platform's standard tool chain, configured with "--enable-shared --with-threads --with-pydebug". All other tests pass for me, although test_builtin failed when run as part of the whole suite but passed when run by itself. For what it's worth, it looks like that particular message is emitted in exactly one place: Python/getargs.c:661 (function convertsimple()), which in this case I guess is being called indirectly from Python/bltinmodule.c:526 (function builtin_chr()). It's not obvious to me why that would be failing. ---------- components: Tests messages: 162532 nosy: jcbollinger priority: normal severity: normal status: open title: test_curses fails with OverflowError type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15037> _______________________________________ From report at bugs.python.org Fri Jun 8 18:33:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jun 2012 16:33:25 +0000 Subject: [issue2736] datetime needs an "epoch" method In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za> Message-ID: <E1Sd27n-0000cD-Ck@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 6671c5039e15 by Alexander Belopolsky in branch 'default': Issue #2736: Added datetime.timestamp() method. http://hg.python.org/cpython/rev/6671c5039e15 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue2736> _______________________________________ From report at bugs.python.org Fri Jun 8 18:38:21 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 08 Jun 2012 16:38:21 +0000 Subject: [issue14908] datetime.datetime should have a timestamp() method In-Reply-To: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za> Message-ID: <1339173501.78.0.853847504652.issue14908@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: I associated my commit with issue 2736 by mistake, but it is probably a good thing because that issue contains a longer history. Closing this as a duplicate. ---------- resolution: -> duplicate stage: commit review -> committed/rejected status: open -> closed superseder: -> datetime needs an "epoch" method _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ From report at bugs.python.org Fri Jun 8 18:41:09 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 08 Jun 2012 16:41:09 +0000 Subject: [issue2736] datetime needs an "epoch" method In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za> Message-ID: <1339173669.97.0.523633185843.issue2736@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- superseder: Add aware local time support to datetime module -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue2736> _______________________________________ From report at bugs.python.org Fri Jun 8 18:53:22 2012 From: report at bugs.python.org (Ronan Lamy) Date: Fri, 08 Jun 2012 16:53:22 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1339174402.9.0.940165482976.issue15031@psf.upfronthosting.co.za> Ronan Lamy <ronan.lamy at gmail.com> added the comment: I see. However, I think that breaking code noisily is better than breaking it silently, which is what happens when the same protocol is reimplemented many times. And _loads_pyc() could be made more forward-compatible by returning (path_stats, code) instead of (timestamp, size, code). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Fri Jun 8 19:04:46 2012 From: report at bugs.python.org (John Bollinger) Date: Fri, 08 Jun 2012 17:04:46 +0000 Subject: [issue14390] Tkinter single-threaded deadlock In-Reply-To: <1332449311.13.0.974359232681.issue14390@psf.upfronthosting.co.za> Message-ID: <1339175086.96.0.304267078249.issue14390@psf.upfronthosting.co.za> John Bollinger <John.Bollinger at stJude.org> added the comment: I attach a patch fixing the issue and providing a test and docs. The fix is substantially as I described earlier: a thread that holds the Tcl lock is permitted to acquire it logically any number of times, but physically attempts to acquire it only if it doesn't already hold it. A thread-local counter ensures that the lock is logically released the same number of times it has been acquired before it is physically released. The external API is unchanged, and even source changes are minimized to the greatest extent possible. If this fix ultimately is accepted then I hope it can also be back-ported to 2.7. ---------- keywords: +patch Added file: http://bugs.python.org/file25866/reentrant-tkinter.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14390> _______________________________________ From report at bugs.python.org Fri Jun 8 19:14:58 2012 From: report at bugs.python.org (Ronan Lamy) Date: Fri, 08 Jun 2012 17:14:58 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1339175698.51.0.0234817000048.issue15030@psf.upfronthosting.co.za> Ronan Lamy <ronan.lamy at gmail.com> added the comment: Well, working on a deprecated ABC is certainly low-priority, but it seems rather bad to have 2 incompatible implementations of the .pyc format in the stdlib. If this is to stay like this, it should at least come with a strong warning that users of PyPycLoader must invent their own PEP 3147 magic tag, which opens the can of worms of supporting multiple .pyc formats within the same interpreter in the stdlib. It seems easier to just fix it to be compatible with the one blessed .pyc format, as was the case in 3.2. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Fri Jun 8 19:18:01 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jun 2012 17:18:01 +0000 Subject: [issue15019] String termination on Linux In-Reply-To: <1338994065.34.0.987983176333.issue15019@psf.upfronthosting.co.za> Message-ID: <1339175881.21.0.31832538436.issue15019@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: J?nis, please present examples as proper python -- indentation and comment char -- so others can copy/paste to run without editing. In Idle (tkinter -- tk), '\0' is displayed as a wider space than ' '. The console is fixed pitch, so it cannot do that. I suspect that the response of a window to \0 is window system dependent and probably out of our control. If so, this issue should be closed. ---------- nosy: +terry.reedy title: Sting termination on Linux -> String termination on Linux _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15019> _______________________________________ From report at bugs.python.org Fri Jun 8 19:35:37 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jun 2012 17:35:37 +0000 Subject: [issue14390] Tkinter single-threaded deadlock In-Reply-To: <1332449311.13.0.974359232681.issue14390@psf.upfronthosting.co.za> Message-ID: <1339176937.86.0.0861005769341.issue14390@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Thanks for working on this. This is not my area of expertise, but what you describe sounds like an RLock, and there is a C implementation of RLock in Python3. Could you just use that for Python3? Also, very minor comments on the patch format (I'm not in a position to review the patch itself): we prefer not to add additional copyright notices (some files have older ones). My understanding is you have the copyright by virtue of having published the patch here, and your contributor agreement on file allows us to incorporate it into the codebase, and nothing more is needed. I don't believe we generally include bug fixes in What's New, unless they are significant enough behavior changes that they don't get put into the older versions. It's Raymond's call, though. ---------- stage: -> patch review versions: +Python 2.7, Python 3.2 -Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14390> _______________________________________ From report at bugs.python.org Fri Jun 8 19:57:42 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 08 Jun 2012 17:57:42 +0000 Subject: [issue15007] Unittest CLI does not support test packages very well In-Reply-To: <1338931229.09.0.80724559879.issue15007@psf.upfronthosting.co.za> Message-ID: <1339178262.57.0.498737848562.issue15007@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15007> _______________________________________ From report at bugs.python.org Fri Jun 8 19:58:26 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 08 Jun 2012 17:58:26 +0000 Subject: [issue15011] Change Scripts to bin on Windows In-Reply-To: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za> Message-ID: <1339178306.04.0.262716838403.issue15011@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15011> _______________________________________ From report at bugs.python.org Fri Jun 8 20:00:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 08 Jun 2012 18:00:10 +0000 Subject: [issue15020] Poor default value for progname in pythonrun.c In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za> Message-ID: <1339178410.79.0.719888769099.issue15020@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +eric.araujo title: Poor default value for progname -> Poor default value for progname in pythonrun.c _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15020> _______________________________________ From report at bugs.python.org Fri Jun 8 20:02:07 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 08 Jun 2012 18:02:07 +0000 Subject: [issue15033] Different exit status when using -m In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za> Message-ID: <1339178527.01.0.345072299687.issue15033@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +eric.araujo, ncoghlan versions: +Python 3.3 -Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15033> _______________________________________ From report at bugs.python.org Fri Jun 8 20:03:27 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 08 Jun 2012 18:03:27 +0000 Subject: [issue15034] tutorial should use best practices in user defined execeptions section In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1339178607.48.0.694482248093.issue15034@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I don?t understand the request. ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Fri Jun 8 20:08:52 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jun 2012 18:08:52 +0000 Subject: [issue15034] tutorial should use best practices in user defined execeptions section In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1339178932.45.0.993022595611.issue15034@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: The obvious example is that the tutorial makes no mention of calling 'super' in __init__. I'm also aware that there are issues of pickleability that arise if you do things one way, but do not arise if you do things another way. But I don't know the details, and I'd like to see the tutorial show an example of the *best* way to write a user defined exception so that they behave like the built in Python exceptions. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Fri Jun 8 20:12:31 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jun 2012 18:12:31 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <1339179151.32.0.387794734912.issue15036@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- components: +email nosy: +barry, r.david.murray stage: -> needs patch type: -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Fri Jun 8 20:14:06 2012 From: report at bugs.python.org (John Bollinger) Date: Fri, 08 Jun 2012 18:14:06 +0000 Subject: [issue14390] Tkinter single-threaded deadlock In-Reply-To: <1332449311.13.0.974359232681.issue14390@psf.upfronthosting.co.za> Message-ID: <1339179246.76.0.0825739737479.issue14390@psf.upfronthosting.co.za> John Bollinger <John.Bollinger at stJude.org> added the comment: Yes, I have basically made tkinter's Tcl lock into an Rlock. With respect to Python3's Rlock implementation, though, are you talking about what I see in Modules/_threadmodule.c? Even if it would be acceptable to make the tkinter module depend on the thread module (not clear), I don't think I can easily use that because it looks like all the relevant functions are static, in typical extension module fashion. In other words, it provides only a Python API, not a C API. Moreover, the current implementation can easily be backported to Python 2, but that would not be true of an implementation based on the thread module's Rlock. If you would nevertheless prefer that the thread module's Rlock be used then I would appreciate technical suggestions for how to overcome the lack of a C API. I am content to comply with the PSF copyright marking policy. Is it documented somewhere? My understanding is that my copyright does not depend in any way on marking the work -- at least in the US -- but there are other reasons to prefer to mark. Anyway, show me the policy or else just confirm that it is to not mark in cases such as this, and I will remove it. Tkinter threading and re-entrancy issues have been somewhat of a sore spot for a very long time, so I think this change is worth calling out. Nevertheless, if Raymund disagrees then so be it. Thanks ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14390> _______________________________________ From report at bugs.python.org Fri Jun 8 20:16:26 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jun 2012 18:16:26 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1339179386.14.0.0880911635747.issue15031@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: I point is that it shouldn't break at all if possible, although path_stats does potentially provide a way to deal with this (as does using keyword-only arguments for what needs to be verified). I'll have to think about this. One issue I have with this is I don't love exposing bytecode files too much as people should not typically muck with bytecode files, and if they do they should really know what they are doing. I honestly view them as an implementation detail and not something for people to play with. I also don't want people to get to into bytecode files as they are not necessarily the best way to store bytecode. E.g. a sqlite DB storing bytecode really shouldn't store all of that info in a single column but instead in separate columns and exposing a function as proposed kind of pushes against that idea. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Fri Jun 8 20:17:26 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jun 2012 18:17:26 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1339179446.21.0.940392905569.issue15030@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Yes, a fix would be easiest, but someone has to write the fix. =) I will try to get to it before the first beta (unless Antoine, who made the .pyc change, wants to do it =). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Fri Jun 8 20:31:41 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 08 Jun 2012 18:31:41 +0000 Subject: [issue15038] Optimize python Locks on Windows Message-ID: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>: The attached patch does three things: " - Abstract the condition variable used by ceval_gil.h into a separate file, condvar.h. It now defines a PyMUTEX_T, PyCOND_T and associated functions. This file can be used by different parts of the python core. - Implement locking on windows using custom structures based on condition variables, rather than using a semaphore kernel object. This avoids kernel transitions for uncontensted locks and provides a large speedup for windows. - Add a condition variable implementation using native primitives for builds targeted for Vista. Experimental and disabled by default. " Using this locking mechanism on windows results in a 60% speedup of using uncontested locks, due to the removal of the necessary kernel transition that is required by regular semaphore objects. Before: D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l .release()" 1000000 loops, best of 3: 0.731 usec per loop After: D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l .release()" 1000000 loops, best of 3: 0.27 usec per loop ---------- components: Interpreter Core, Windows files: 77369.patch keywords: patch messages: 162545 nosy: kristjan.jonsson, loewis, pitrou priority: normal severity: normal status: open title: Optimize python Locks on Windows type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25867/77369.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Fri Jun 8 20:32:45 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 08 Jun 2012 18:32:45 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1339180365.43.0.0252193338026.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: This defect springs out of issue #11618 ---------- superseder: -> Locks broken wrt timeouts on Windows _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Fri Jun 8 20:40:09 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 08 Jun 2012 18:40:09 +0000 Subject: [issue15034] tutorial should use best practices in user defined exceptions section In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1339180809.44.0.907976589672.issue15034@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- title: tutorial should use best practices in user defined execeptions section -> tutorial should use best practices in user defined exceptions section _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Fri Jun 8 20:40:40 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 08 Jun 2012 18:40:40 +0000 Subject: [issue15034] tutorial should use best practices in user defined exceptions section In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1339180840.58.0.846467738042.issue15034@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- nosy: +belopolsky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Fri Jun 8 21:01:01 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jun 2012 19:01:01 +0000 Subject: [issue14390] Tkinter single-threaded deadlock In-Reply-To: <1332449311.13.0.974359232681.issue14390@psf.upfronthosting.co.za> Message-ID: <1339182061.13.0.869468790972.issue14390@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: That's why I phrased it as a question, I don't know enough about the C stuff. Someone else nosy on this bug will probably have a more informed opinion. I don't think the copyright marking policy is currently written down. It ought to be, but I have a sinking feeling making that happen isn't going to be easy, because it involves lawyerly stuff. ---------- nosy: +jnoller _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14390> _______________________________________ From report at bugs.python.org Fri Jun 8 21:02:42 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 Jun 2012 19:02:42 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1339182162.18.0.577500679722.issue14626@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: BTW: If PEP 362 is accepted, and this patch makes it for 3.3 (both of which I think will happen), I'll hand-code signatures for the functions that may throw NotImplementedError so users can use "is_implemented" to LBYL. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 9 00:02:16 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 08 Jun 2012 22:02:16 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1339192936.5.0.323640263635.issue13598@psf.upfronthosting.co.za> Eric V. Smith <eric at trueblade.com> added the comment: Is there a reason "manual" is None, True, or False? Wouldn't just True or False suffice? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Sat Jun 9 00:16:42 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 08 Jun 2012 22:16:42 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1339193802.89.0.305262285418.issue13598@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: > Is there a reason "manual" is None, True, or False? Wouldn't just True or False suffice? I suppose before we see the first bracketed form ({} or {\d+}) we don't know which it is. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Sat Jun 9 00:49:46 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 08 Jun 2012 22:49:46 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1339195786.25.0.315605738332.issue13598@psf.upfronthosting.co.za> Eric V. Smith <eric at trueblade.com> added the comment: Yes, I guess that's so. I'll have to add a comment, as at first glance it just looks like a bug. Thanks! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Sat Jun 9 01:59:03 2012 From: report at bugs.python.org (Dan Stromberg) Date: Fri, 08 Jun 2012 23:59:03 +0000 Subject: [issue15039] module/ found before module.py when both are in the CWD Message-ID: <1339199943.51.0.731148494988.issue15039@psf.upfronthosting.co.za> New submission from Dan Stromberg <strombrg at gmail.com>: CPython 3.3a4 appears to find treap/ before treap.py in the CWD. If I rename treap to treap-dir, all seems well for the code in question: dstromberg at zareason-limbo6000a /tmp/tt $ mv treap treap-dir dstromberg at zareason-limbo6000a /tmp/tt $ /usr/local/cpython-3.3/bin/python -c 'import sys; print(sys.path); import treap; t = treap.treap()' ['', '/usr/local/cpython-3.3/lib/python33.zip', '/usr/local/cpython-3.3/lib/python3.3', '/usr/local/cpython-3.3/lib/python3.3/plat-linux', '/usr/local/cpython-3.3/lib/python3.3/lib-dynload', '/usr/local/cpython-3.3/lib/python3.3/site-packages'] dstromberg at zareason-limbo6000a /tmp/tt $ mv treap-dir/ treap dstromberg at zareason-limbo6000a /tmp/tt $ /usr/local/cpython-3.3/bin/python -c 'import sys; print(sys.path); import treap; t = treap.treap()' ['', '/usr/local/cpython-3.3/lib/python33.zip', '/usr/local/cpython-3.3/lib/python3.3', '/usr/local/cpython-3.3/lib/python3.3/plat-linux', '/usr/local/cpython-3.3/lib/python3.3/lib-dynload', '/usr/local/cpython-3.3/lib/python3.3/site-packages'] Traceback (most recent call last): File "<string>", line 1, in <module> AttributeError: 'module' object has no attribute 'treap' dstromberg at zareason-limbo6000a /tmp/tt $ ls -l treap/__init__.py ls: cannot access treap/__init__.py: No such file or directory dstromberg at zareason-limbo6000a /tmp/tt $ /usr/local/cpython-3.3/bin/python Python 3.3.0a4 (default, Jun 8 2012, 14:14:41) [GCC 4.6.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> dstromberg at zareason-limbo6000a /tmp/tt $ ---------- components: Library (Lib) messages: 162552 nosy: strombrg priority: normal severity: normal status: open title: module/ found before module.py when both are in the CWD type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15039> _______________________________________ From report at bugs.python.org Sat Jun 9 02:46:23 2012 From: report at bugs.python.org (Chris Rebert) Date: Sat, 09 Jun 2012 00:46:23 +0000 Subject: [issue15039] module/ found before module.py when both are in the CWD In-Reply-To: <1339199943.51.0.731148494988.issue15039@psf.upfronthosting.co.za> Message-ID: <1339202783.62.0.421506984635.issue15039@psf.upfronthosting.co.za> Changes by Chris Rebert <pybugs at rebertia.com>: ---------- nosy: +cvrebert _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15039> _______________________________________ From report at bugs.python.org Sat Jun 9 03:08:33 2012 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 09 Jun 2012 01:08:33 +0000 Subject: [issue15039] module/ found before module.py when both are in the CWD In-Reply-To: <1339199943.51.0.731148494988.issue15039@psf.upfronthosting.co.za> Message-ID: <1339204113.15.0.657561881684.issue15039@psf.upfronthosting.co.za> Changes by Eric V. Smith <eric at trueblade.com>: ---------- assignee: -> eric.smith nosy: +eric.smith _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15039> _______________________________________ From report at bugs.python.org Sat Jun 9 04:46:40 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 Jun 2012 02:46:40 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1339210000.88.0.896258593553.issue14626@psf.upfronthosting.co.za> Guido van Rossum <guido at python.org> added the comment: I haven't read the code, but from Larry's description this looks great to me. It's amazing how many extra functions were added to the os module since 3.2! I also agree that the redundant functions that existed in 3.2 should stay and I don't see it's fair to deprecate them. I do hope that not too many people have written code based on the 3.3 alphas using all those extra functions, but I suppose they will get what they paid for. Everything else Larry wrote also sounds reasonable to me. ---------- nosy: +gvanrossum _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 9 04:52:06 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 09 Jun 2012 02:52:06 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1339210326.79.0.170902268374.issue14626@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment: Previously existing redundant functions could be deprecated in documentation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 9 06:23:42 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 09 Jun 2012 04:23:42 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1339215822.62.0.268398625328.issue14626@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > Previously existing redundant functions could be > deprecated in documentation. As in, don't start a "deprecation cycle" (warning in 3.3, deprecated in 3.4, gone in 3.5), just document "consider using this other function instead"? That's probably worth doing. I wouldn't use the word "deprecated" though, I'd just suggest a "see also". Maybe we could remove the redundant functions in 4.0. I'll put it on my wishlist :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 9 11:55:21 2012 From: report at bugs.python.org (bruno Piguet) Date: Sat, 09 Jun 2012 09:55:21 +0000 Subject: [issue14984] netrc module allows read of non-secured .netrc file In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za> Message-ID: <1339235721.55.0.0110799505776.issue14984@psf.upfronthosting.co.za> bruno Piguet <bruno.piguet at gmail.com> added the comment: Do you agree that the attached patch could be a practical solution ? The patch is for the 2.6 version of the lib. Transposition to other versions should be trivial. If we don't want to break backward compatibility, the solution is to add a optional behavior flag argument, something like def __init__(self, file=None, sec_mode=False): and have the default value be False for old versions and True for 3.3 and further. ---------- Added file: http://bugs.python.org/file25868/patch_netrc_2.6.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14984> _______________________________________ From report at bugs.python.org Sat Jun 9 13:10:53 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 09 Jun 2012 11:10:53 +0000 Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?= =?utf-8?b?dF9fIGZhaWxz?= In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za> Message-ID: <1339240253.95.0.300500875301.issue10053@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Anyone? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10053> _______________________________________ From report at bugs.python.org Sat Jun 9 13:13:42 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 09 Jun 2012 11:13:42 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1339240422.06.0.977375343703.issue4489@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Martin, are you still committed to this? I still think code duplication is bad (especially for security related code) but I?d be willing to write a fwalk-less version so it doesn?t look like I?m just defending my code here. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sat Jun 9 14:26:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 09 Jun 2012 12:26:14 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1339240422.06.0.977375343703.issue4489@psf.upfronthosting.co.za> Message-ID: <4FD340E5.3060900@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Martin, are you still committed to this? Yes, I'll provide a patch RSN. I doubt that there will be that much code duplication. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sat Jun 9 15:21:47 2012 From: report at bugs.python.org (Abhishek Singh) Date: Sat, 09 Jun 2012 13:21:47 +0000 Subject: [issue15021] xmlrpc server hangs In-Reply-To: <1339027271.75.0.304876559161.issue15021@psf.upfronthosting.co.za> Message-ID: <1339248107.86.0.107131220166.issue15021@psf.upfronthosting.co.za> Abhishek Singh <abhishekrsingh at gmail.com> added the comment: I have a pretty complicated setup. 100's of threads, xmlrpc being in the main thread and providing show routines for my program. I have 10's of such processes doing some heavy duty simulation/crunching. The threads and program is in C. I use swig routines to throw in my show framework. There is no traceback - it is just stuck and unresponsive. If I quit my client, the socket gets closed and it recovers. But it is annoying to do so, and it can get stuck again :(. I will try your timeout suggestion, but having a infinite timeout might help given my system is loaded with lots of competing (for CPU) threads. I am running the Simple xmlrpc server. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15021> _______________________________________ From report at bugs.python.org Sat Jun 9 15:58:40 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 09 Jun 2012 13:58:40 +0000 Subject: [issue14984] netrc module allows read of non-secured .netrc file In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za> Message-ID: <1339250320.68.0.650814613184.issue14984@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Thanks for the patch. I think the extra check should be done unconditionally in the case where we've looked up the default .netrc file. Adding a feature to 3.3 to provide an optional check for other files (with default False) would then be an additional enhancement, and I think a good one. That should be a separate patch, probably even a separate issue. I don't think the parse error is the right thing to raise, but I'm not sure what is. An OSError, perhaps? I'm adding the 2.6 release manager to see if he thinks this is of sufficient importance to go into a 2.6 release. ---------- nosy: +barry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14984> _______________________________________ From report at bugs.python.org Sat Jun 9 16:51:03 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 09 Jun 2012 14:51:03 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1339253463.3.0.706900397894.issue13598@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Its not a bug though it has maintenance problems because if you change "manual is False" to not manual it no longer works correctly. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Sat Jun 9 16:56:49 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 09 Jun 2012 14:56:49 +0000 Subject: [issue14971] (unittest) loadTestsFromName does not work on method with a decorator In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za> Message-ID: <1339253809.13.0.40939727142.issue14971@psf.upfronthosting.co.za> Michael Foord <michael at voidspace.org.uk> added the comment: Patch looks great - thanks David. ---------- assignee: docs at python -> michael.foord _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14971> _______________________________________ From report at bugs.python.org Sat Jun 9 21:26:21 2012 From: report at bugs.python.org (mattip) Date: Sat, 09 Jun 2012 19:26:21 +0000 Subject: [issue15040] stdlib compatability with pypy: mailbox.py Message-ID: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> New submission from mattip <matti.picus at gmail.com>: These are changes necessary to mailbox.py and its tests so that tests pass (windows platform) on pypy 1.9.0. Files must be explicitly closed on pypy. I would like to submit these as a "compatability" issue type, but that category does not exist, so I used "behavior". This is the first in a series of a number of such patches, I think there will be about 20. ---------- components: Library (Lib) files: mailbox.patch keywords: patch messages: 162564 nosy: mattip priority: normal severity: normal status: open title: stdlib compatability with pypy: mailbox.py type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25869/mailbox.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Sat Jun 9 23:26:23 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 09 Jun 2012 21:26:23 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1339277183.61.0.00906293884033.issue13598@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: > it has maintenance problems because if you change "manual is False" > to not manual it no longer works correctly. So you should probably comment the initialisation appropriately. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Sun Jun 10 02:10:10 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 00:10:10 +0000 Subject: [issue15040] stdlib compatability with pypy: mailbox.py In-Reply-To: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> Message-ID: <1339287010.57.0.707923999324.issue15040@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I see some code changes, but no added tests for those code changes. msg.fp doesn't exist in Python3. I'd like to understand those changes better, but I don't know when I'll have the time or if it is worth the effort. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Sun Jun 10 02:15:50 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 00:15:50 +0000 Subject: [issue15040] stdlib compatability with pypy: mailbox.py In-Reply-To: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> Message-ID: <1339287349.62.0.214988870395.issue15040@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Oh, and the code changes should presumably be applied to Python3 as well (once there are tests), so I've added those versions. It might be better to have two patches, one for the close of _file, and the other for the msg.fp stuff (since that doesn't exist in Python3). ---------- components: +email nosy: +barry stage: -> patch review versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Sun Jun 10 02:49:33 2012 From: report at bugs.python.org (Daniel Swanson) Date: Sun, 10 Jun 2012 00:49:33 +0000 Subject: [issue15041] tkinter "see also" list is from Python2 Message-ID: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za> New submission from Daniel Swanson <popcorn.tomato.dude at gmail.com>: I was looking for information about menus in tkinter and checked the "see also" list. The second is copyrighted 1999, the third says Python 2.5 and the first is pretty much just links to the second and third. The forth is a book. It is my opinion that these resources should be updated. ---------- assignee: docs at python components: Documentation messages: 162568 nosy: docs at python, weirdink13 priority: normal severity: normal status: open title: tkinter "see also" list is from Python2 versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15041> _______________________________________ From report at bugs.python.org Sun Jun 10 02:53:12 2012 From: report at bugs.python.org (Daniel Swanson) Date: Sun, 10 Jun 2012 00:53:12 +0000 Subject: [issue15041] tkinter documentation "see also" list in Python3 is from Python2 In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za> Message-ID: <1339289592.83.0.292874514346.issue15041@psf.upfronthosting.co.za> Changes by Daniel Swanson <popcorn.tomato.dude at gmail.com>: ---------- title: tkinter "see also" list is from Python2 -> tkinter documentation "see also" list in Python3 is from Python2 type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15041> _______________________________________ From report at bugs.python.org Sun Jun 10 03:20:49 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:20:49 +0000 Subject: [issue14680] pydoc with -w option does not work for a lot of help topics In-Reply-To: <1335478272.08.0.215124599111.issue14680@psf.upfronthosting.co.za> Message-ID: <1339291249.19.0.393823798013.issue14680@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Thanks for the report. Are you interested in making a patch? Also, could you tell if the bug happens in 3.2? ---------- nosy: +eric.araujo stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14680> _______________________________________ From report at bugs.python.org Sun Jun 10 03:21:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:21:00 +0000 Subject: [issue14680] pydoc with -w option does not work for a lot of help topics In-Reply-To: <1335478272.08.0.215124599111.issue14680@psf.upfronthosting.co.za> Message-ID: <1339291260.32.0.9646714985.issue14680@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- assignee: docs at python -> components: +Library (Lib) -Documentation nosy: -docs at python _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14680> _______________________________________ From report at bugs.python.org Sun Jun 10 03:23:02 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:23:02 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1339291382.74.0.230043291639.issue14616@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Text LGTM; I haven?t looked at the position in the doc file though. Sandro, once again I?m adding you to nosy in the hope that you?ll have time to make a review and maybe a commit, with my thanks! ---------- nosy: +sandro.tosi _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14616> _______________________________________ From report at bugs.python.org Sun Jun 10 03:23:46 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:23:46 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1339291426.65.0.392752807446.issue14616@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Please also take my note about pipes.quote in my OP into account. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14616> _______________________________________ From report at bugs.python.org Sun Jun 10 03:30:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:30:33 +0000 Subject: [issue14843] support define_macros / undef_macros in setup.cfg In-Reply-To: <1337287780.12.0.529046490638.issue14843@psf.upfronthosting.co.za> Message-ID: <1339291833.94.0.359292493586.issue14843@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: Added file: http://bugs.python.org/file25870/ac776ef41428.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14843> _______________________________________ From report at bugs.python.org Sun Jun 10 03:31:52 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:31:52 +0000 Subject: [issue14848] Use shutil.move instead of os.rename in packaging In-Reply-To: <1337331032.2.0.780379839017.issue14848@psf.upfronthosting.co.za> Message-ID: <1339291912.35.0.530028271002.issue14848@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: OK. Can you paste the full traceback for the error? ---------- stage: -> needs patch title: os.rename should not be used -> Use shutil.move instead of os.rename in packaging _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14848> _______________________________________ From report at bugs.python.org Sun Jun 10 03:32:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:32:10 +0000 Subject: [issue14843] support define_macros / undef_macros in setup.cfg In-Reply-To: <1337287780.12.0.529046490638.issue14843@psf.upfronthosting.co.za> Message-ID: <1339291930.96.0.608561224134.issue14843@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: Removed file: http://bugs.python.org/file25870/ac776ef41428.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14843> _______________________________________ From report at bugs.python.org Sun Jun 10 03:33:03 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:33:03 +0000 Subject: [issue14843] support define_macros / undef_macros in setup.cfg In-Reply-To: <1337287780.12.0.529046490638.issue14843@psf.upfronthosting.co.za> Message-ID: <1339291983.54.0.822962020846.issue14843@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Looks like the diff generator can?t be used for not up-to-date clones. Could you update a diff? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14843> _______________________________________ From report at bugs.python.org Sun Jun 10 03:34:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:34:05 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1337352396.54.0.468921009595.issue14850@psf.upfronthosting.co.za> Message-ID: <1339292045.07.0.369477598475.issue14850@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: What is the use case for passing a string subclass to charmap_decode? Or in other words, how did you stumble upon the bug? ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ From report at bugs.python.org Sun Jun 10 03:37:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:37:33 +0000 Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle docstring In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za> Message-ID: <1339292253.93.0.908281625755.issue14927@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- keywords: +easy nosy: +sandro.tosi stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14927> _______________________________________ From report at bugs.python.org Sun Jun 10 03:44:16 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:44:16 +0000 Subject: [issue14968] Section "Inplace Operators" of :mod:`operator` should be a subsection In-Reply-To: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za> Message-ID: <1339292656.18.0.884008326445.issue14968@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Sandro: I added 2.7 to indicate it should be checked too. As you said, the bug wasn?t there, because there is no In-place Operators section (which I think there should be, i.e. backporting #9717 (if you do that, please use a full commit message instead of ?backport of skldgjlkg?)). ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14968> _______________________________________ From report at bugs.python.org Sun Jun 10 03:46:23 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 10 Jun 2012 01:46:23 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1339292783.73.0.431175945254.issue15003@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > The type is available as types.SimpleNamespace (sorry for being OT) Is this documented in whatsnew? Also, I remember a discussion about making it public or not, but don?t recall a decision. I personally find it bad that we have structseqs for most things, dicts in PEP 418 get_clock_info return values, and now simplenamespace for sys.implementation. ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Sun Jun 10 04:23:07 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 02:23:07 +0000 Subject: [issue3955] maybe doctest doesn't understand unicode_literals? In-Reply-To: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za> Message-ID: <1339294987.82.0.848436307328.issue3955@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I fail to see the problem here. If the module has 'from __future__ import unicode_literals", then the docstring output clauses would need to be changed to reflect the fact that the input literals are now unicode. What am I missing? ---------- assignee: tim_one -> nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3955> _______________________________________ From report at bugs.python.org Sun Jun 10 04:26:19 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 02:26:19 +0000 Subject: [issue2020] _sha256 module missing if openssl is not in a "normal" directory. In-Reply-To: <1202312744.16.0.269773483749.issue2020@psf.upfronthosting.co.za> Message-ID: <1339295179.57.0.712928951432.issue2020@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Since there's been no response, I'm closing this. ---------- keywords: +buildbot nosy: +r.david.murray resolution: -> out of date stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue2020> _______________________________________ From report at bugs.python.org Sun Jun 10 04:31:10 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 02:31:10 +0000 Subject: [issue6165] strftime incorrectly processes DST flag when passed time touples In-Reply-To: <1243877901.36.0.141304844828.issue6165@psf.upfronthosting.co.za> Message-ID: <1339295470.19.0.818335676081.issue6165@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Closing because of lack of response. ---------- nosy: +r.david.murray status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6165> _______________________________________ From report at bugs.python.org Sun Jun 10 04:32:52 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 02:32:52 +0000 Subject: [issue9722] PyObject_Print with Visual Studio 2010 In-Reply-To: <1283247788.01.0.709012210199.issue9722@psf.upfronthosting.co.za> Message-ID: <1339295572.86.0.631044898764.issue9722@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9722> _______________________________________ From report at bugs.python.org Sun Jun 10 09:59:25 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 10 Jun 2012 07:59:25 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1337352396.54.0.468921009595.issue14850@psf.upfronthosting.co.za> Message-ID: <1339315165.22.0.207163493682.issue14850@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: U+FFFE is documented as representing an undefined mapping, see http://docs.python.org/dev/c-api/unicode.html?highlight=charmap#PyUnicode_DecodeCharmap So the base string case is correct; the derived string implementation also needs to invoke the error handler. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ From report at bugs.python.org Sun Jun 10 11:30:22 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 10 Jun 2012 09:30:22 +0000 Subject: [issue15042] Implemented PyState_AddModule, PyState_RemoveModule Message-ID: <1339320622.0.0.56459406352.issue15042@psf.upfronthosting.co.za> New submission from Robin Schreiber <robin.schreiber at me.com>: PEP 3121 suggests a new way of Module-initialization, where the module state is being wrapped inside a dedicate struct, which can be accessed at runtime via the PyState_FindModule method. For code outside the Init-method, there is no other way to receive the module-state, as it has no reference to the object created by PyModule_Create. PyState_FindModule requires, that the module-state has been attached to the interpreter-state beforehand. Inside an extension module code this is almost everywhere the case except inside the Init-method, because currently _PyState_AddModule is only called by the importer AFTER the extension module has been initialized successfully. As most of the macro definitions inside an extension module, which rely on data stored in the module state, have to receive the state via FindModule, they fail to work inside the modules Init-method. This patch suggests an extension of PyState comprising two publicly available methods (PyState_AddModule, PyState_RemoveModule) that can be called from inside the Init-method, so that the module-state is attached to the interpreter state before further initialization of the module continues. As a result, PyState_FindModule will also work in this region of the extension module and the bespoken expanded macros will also work flawlessly when executed inside the Init code. This patch is especially important for the future application of PEP 3121 together with PEP 384, as the newly created heap-types now reside inside the module-state. As type-objects are frequently used in macro-definitions which are also expanded within the Init-method of a module (or inside a function called from Init), the module state has to be received via FindModule. (The alternative would be nasty redefinitions of the specific macros, shortly before Init) ---------- components: Interpreter Core files: PyState_add-remove_module.patch keywords: patch messages: 162581 nosy: Robin.Schreiber priority: normal severity: normal status: open title: Implemented PyState_AddModule, PyState_RemoveModule type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25871/PyState_add-remove_module.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15042> _______________________________________ From report at bugs.python.org Sun Jun 10 12:51:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jun 2012 10:51:16 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1339292045.07.0.369477598475.issue14850@psf.upfronthosting.co.za> Message-ID: <1339325482.18692.11.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > What is the use case for passing a string subclass to charmap_decode? Or in other words, how did you stumble upon the bug? I stumbled upon it, rewriting the charmap decoder (issue14874). Now charmap decoder processes the two cases -- a more effective case of string table and a general slower case of general mapping. I proposed a more optimized case of 256-character UCS2 string (covers all standard charmap encodings). If processing general strings and maps was consistent, these cases can be merged. A string subclass is just an example that illustrates the inconsistency. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ From report at bugs.python.org Sun Jun 10 13:00:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jun 2012 11:00:13 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1339315165.22.0.207163493682.issue14850@psf.upfronthosting.co.za> Message-ID: <1339326022.18692.20.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > U+FFFE is documented as representing an undefined mapping, Yes, using U+FFFE for representing an undefined mapping in strings is normal, the question was about string subclasses. And if we will correct it for string subclasses, how far we go any further? How about general mapping? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ From report at bugs.python.org Sun Jun 10 13:26:39 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 10 Jun 2012 11:26:39 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1339326022.18692.20.camel@raxxla> Message-ID: <4FD4846D.3010509@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: >> U+FFFE is documented as representing an undefined mapping, > > Yes, using U+FFFE for representing an undefined mapping in strings is > normal, the question was about string subclasses. What is the question? U+FFFE also represents an undefined mapping in string subclasses. > And if we will correct it for string subclasses, how far we go any > further? This is a single issue, a single bug. If the bug is fixed, it is fixed. No need to go further (unless there is another bug somewhere). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ From report at bugs.python.org Sun Jun 10 14:52:23 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:52:23 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332743.76.0.559175464511.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25872/ship1.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:53:00 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:53:00 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332780.65.0.424547126376.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25873/ship2.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:53:07 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:53:07 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332787.87.0.407957231447.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25874/ship3.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:53:18 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:53:18 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332798.46.0.693852488792.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25875/ship4.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:53:25 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:53:25 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332805.6.0.892481952972.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25876/ship5.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:53:34 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:53:34 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332814.24.0.422510284261.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25877/ship6.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:53:45 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:53:45 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332825.86.0.879802054582.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25878/ship7.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:53:54 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:53:54 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332834.02.0.261076214795.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25879/ship8.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:54:03 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:54:03 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332843.31.0.264867239856.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25880/ship9.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:54:13 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:54:13 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332853.65.0.501509637885.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25881/ship10.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:54:23 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:54:23 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332863.03.0.841237545589.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25882/ship11.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:54:32 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:54:32 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332872.94.0.289951462147.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25883/ship12.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:54:42 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:54:42 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332882.93.0.26814080619.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25884/ship13.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:54:53 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:54:53 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332893.13.0.405089077988.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25885/ship14.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:55:02 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:55:02 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332902.04.0.537320856534.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25886/ship15.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:55:11 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:55:11 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332911.64.0.192037767387.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25887/ship16.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:55:21 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:55:21 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332921.65.0.233963484393.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25888/ship17.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:55:30 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:55:30 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332930.4.0.592217315181.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25889/ship18.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:55:45 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:55:45 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332945.42.0.84472729172.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25890/ship19.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:55:55 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:55:55 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332955.44.0.364982869213.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25891/ship20.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:56:04 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:56:04 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332964.53.0.861259866944.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25892/ship21.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:56:16 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:56:16 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332976.62.0.168155330975.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25893/ship22.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:56:24 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:56:24 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332984.88.0.496113082969.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25894/ship23.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:56:36 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:56:36 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339332996.76.0.0228795604048.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25895/ship24.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:56:46 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:56:46 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333006.33.0.0907348736416.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25896/ship25.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:56:54 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:56:54 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333014.15.0.147179821599.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25897/ship26.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:57:02 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:57:02 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333022.33.0.116617644689.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25898/ship27.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:57:15 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:57:15 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333035.11.0.800434036805.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25899/ship28.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:57:22 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:57:22 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333042.85.0.830882297724.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25900/ship29.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:57:31 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:57:31 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333051.61.0.1514726413.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25901/ship30.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:57:44 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:57:44 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333064.4.0.254853761916.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25902/ship31.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:57:52 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:57:52 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333072.46.0.866878759585.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25903/ship32.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:58:02 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:58:02 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333082.13.0.481160603597.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25904/ship33.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:58:11 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:58:11 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333091.89.0.794890542088.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25905/ship34.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:58:20 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:58:20 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333100.14.0.452963083675.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25906/ship35.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:58:27 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:58:27 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333107.99.0.178719042301.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25907/ship36.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:58:35 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:58:35 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333115.57.0.157287006652.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25908/ship37.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:58:44 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:58:44 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333124.81.0.993894784595.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25909/ship38.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:58:54 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:58:54 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333134.48.0.849483819264.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25910/ship39.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:59:02 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:59:02 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333142.85.0.134381231697.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25911/ship40.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:59:10 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:59:10 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333150.88.0.906456393654.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25912/ship41.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:59:18 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:59:18 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333158.84.0.53246545362.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25913/ship42.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:59:26 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:59:26 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333166.56.0.0856733398627.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25914/ship43.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:59:38 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:59:38 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333178.23.0.385121374946.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25915/ship44.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:59:48 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:59:48 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333188.78.0.0713546138159.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25916/ship45.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 14:59:57 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 12:59:57 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333197.63.0.650050781183.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25917/ship46.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:00:09 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:00:09 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333209.15.0.719335345525.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25918/ship47.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:00:18 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:00:18 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333218.07.0.6124667881.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25919/ship48.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:00:26 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:00:26 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333226.01.0.621775887633.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25920/ship49.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:00:34 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:00:34 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333234.52.0.777138646218.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25921/ship50.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:00:45 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:00:45 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333245.45.0.461108516901.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25922/ship51.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:00:53 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:00:53 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333253.6.0.669235679307.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25923/ship52.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:01:07 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:01:07 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333267.61.0.546902106531.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25924/ship53.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:01:16 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:01:16 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333276.19.0.524612189916.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25925/ship54.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:01:24 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:01:24 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333284.62.0.669638552026.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25926/ship55.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:01:38 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:01:38 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333298.0.0.530593545997.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25927/ship56.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:01:45 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:01:45 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333305.56.0.701924066955.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25928/ship57.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:01:53 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:01:53 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333313.16.0.181777130646.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25929/ship58.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:02:00 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:02:00 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333320.59.0.407766541892.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25930/ship59.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:02:08 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:02:08 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333328.52.0.562339739812.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25931/ship60.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 15:02:23 2012 From: report at bugs.python.org (Fyrn Jilot) Date: Sun, 10 Jun 2012 13:02:23 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339333343.63.0.517395824508.issue1009@psf.upfronthosting.co.za> Changes by Fyrn Jilot <fyrn76ji at yahoo.com>: Added file: http://bugs.python.org/file25932/ship61.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 16:01:53 2012 From: report at bugs.python.org (Petr Kubat) Date: Sun, 10 Jun 2012 14:01:53 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1339336913.83.0.564694182258.issue13691@psf.upfronthosting.co.za> Petr Kubat <killme01 at gmail.com> added the comment: Is anyone still working on this? If not I would like to make this work. Although I'm not exactly sure how to tackle this problem since the built-in help function is defined as a wrapper around pydoc.help and so the docstring used for printing help('help') is actually a docstring of the site._Helper() class. I made a patch that adds a documentation-like message to the pydoc.help function when it is called with a 'help' argument, but it doesn't seem clean to me. ---------- nosy: +Cubky Added file: http://bugs.python.org/file25933/i13691.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13691> _______________________________________ From report at bugs.python.org Sun Jun 10 16:05:58 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 14:05:58 +0000 Subject: [issue7699] strptime, strftime documentation In-Reply-To: <1263433562.71.0.126740414986.issue7699@psf.upfronthosting.co.za> Message-ID: <1339337158.26.0.239791719009.issue7699@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: This was applied by Georg in SVN revision r77561 on 2010-01-17. ---------- nosy: +r.david.murray resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7699> _______________________________________ From report at bugs.python.org Sun Jun 10 17:16:25 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 Jun 2012 15:16:25 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1339341385.6.0.0171386457531.issue14532@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: A comment above the length check referring back to this issue and the deliberate decision to allow a timing attack to determine the length of the expected digest would be handy. I was just looking at hmac.secure_compare and my thought when reading the source and the docstring was "No, it's not time-independent, you can still use a timing attack to figure out the expected digest length". ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14532> _______________________________________ From report at bugs.python.org Sun Jun 10 17:59:14 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jun 2012 15:59:14 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <4FD4846D.3010509@v.loewis.de> Message-ID: <1339343965.18692.39.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > What is the question? U+FFFE also represents an undefined mapping in > string subclasses. What about classes that not subclassed string but ducktyped string by implementing all string method? What about list/tuple/array.array of integers or 1-character strings? What about general mapping? Should any of them have 0xFFFE or '\uFFFE' represent an undefined mapping? > This is a single issue, a single bug. If the bug is fixed, it is fixed. > No need to go further (unless there is another bug somewhere). My question, where is the limit of this bug. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ From report at bugs.python.org Sun Jun 10 19:08:00 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 10 Jun 2012 17:08:00 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1339343965.18692.39.camel@raxxla> Message-ID: <4FD4D46E.1000709@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > integers or 1-character strings? What about general mapping? Should > any of them have 0xFFFE or '\uFFFE' represent an undefined mapping? The documentation says that the parameter "can be a dictionary mapping byte or a unicode string, which is treated as a lookup table". So anything that supports GetItem with a small integer index can be passed. It then says '... U+FFFE ?characters? are treated as ?undefined mapping?'. So the answer to your last question is "yes". I hope that the answer to your other questions follows from that (strictly speaking, it's only U+FFFE, not 0xFFFE, that is documented as indicating an undefined mapping; a patch should probably fix that). (I also wonder where the support for LookupError comes from - that appears to be undocumented) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ From report at bugs.python.org Sun Jun 10 19:09:53 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:09:53 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348193.47.0.240629274807.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25872/ship1.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:01 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:01 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348201.97.0.321308429808.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25873/ship2.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:08 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:08 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348208.14.0.221176010948.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25874/ship3.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:14 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:14 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348214.43.0.68047780748.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25875/ship4.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:20 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:20 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348220.77.0.47887346304.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25876/ship5.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:30 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:30 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348230.88.0.497168947779.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25877/ship6.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:39 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:39 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348239.45.0.118938626786.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25878/ship7.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:46 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:46 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348246.88.0.565372129445.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25879/ship8.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:53 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:53 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348253.41.0.198509720078.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25880/ship9.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:10:59 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:10:59 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348259.7.0.934243309878.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25881/ship10.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:11:09 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:11:09 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348269.97.0.960608245002.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25882/ship11.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:11:19 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:11:19 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348279.28.0.0572803697812.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25883/ship12.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:11:25 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:11:25 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348285.67.0.312120797076.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25884/ship13.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:11:32 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:11:32 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348292.12.0.615977378816.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25885/ship14.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:11:38 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:11:38 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348298.65.0.930263749437.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25886/ship15.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:11:45 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:11:45 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348305.99.0.457166638985.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25887/ship16.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:11:51 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:11:51 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348311.89.0.998134551594.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25888/ship17.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:12:00 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:12:00 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348320.13.0.40882043972.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25889/ship18.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:12:14 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:12:14 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348334.28.0.874199587072.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25890/ship19.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:12:20 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:12:20 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348340.92.0.464955031264.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25891/ship20.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:12:26 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:12:26 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348346.93.0.212225221525.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25892/ship21.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:12:40 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 17:12:40 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1339348360.71.0.255851133412.issue13691@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: It doesn't look like anyone is working on it currently. Yes, getting this right is a bit tricky for exactly the reason you say. You have to make sure you don't break the other uses, and glancing at the patch (I haven't looked at the code you are patching) it seems likely that the change to the if statement is going to break *something*. Probably what happens when you type 'help' at the 'help>' prompt, at a guess. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13691> _______________________________________ From report at bugs.python.org Sun Jun 10 19:18:04 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:18:04 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348684.74.0.45800710789.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25893/ship22.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:18:34 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 17:18:34 +0000 Subject: [issue15041] tkinter documentation "see also" list in Python3 is from Python2 In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za> Message-ID: <1339348714.91.0.904458500945.issue15041@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: If you find any resources that we can link to, please post them here. ---------- assignee: docs at python -> nosy: +r.david.murray, terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15041> _______________________________________ From report at bugs.python.org Sun Jun 10 19:20:18 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:20:18 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348818.93.0.88994095918.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25894/ship23.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:20:24 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:20:24 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348824.77.0.0999190193501.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25895/ship24.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:20:30 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:20:30 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348830.53.0.319643183215.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25896/ship25.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:20:39 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:20:39 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348839.47.0.577673111142.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25897/ship26.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:20:46 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:20:46 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348846.07.0.316854132138.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25898/ship27.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:20:53 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:20:53 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348853.09.0.288427757667.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25899/ship28.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:20:58 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:20:58 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348858.53.0.418466137805.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25900/ship29.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:21:05 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:21:05 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348865.19.0.718259565885.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25901/ship30.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:21:20 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:21:20 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348880.7.0.954554985143.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25902/ship31.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:21:27 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:21:27 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348887.88.0.42425181043.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25903/ship32.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:21:33 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:21:33 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348893.6.0.268319546171.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25904/ship33.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:21:38 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:21:38 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348898.35.0.699827399222.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25905/ship34.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:21:48 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:21:48 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348908.87.0.2138646479.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25906/ship35.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:21:56 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:21:56 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348916.01.0.440233243332.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25907/ship36.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:04 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:04 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348924.13.0.792406452187.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25908/ship37.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:08 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:08 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348928.36.0.432459648894.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25909/ship38.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:13 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:13 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348933.37.0.200166303671.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25910/ship39.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:18 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:18 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348938.69.0.568963605334.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25911/ship40.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:28 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:28 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348948.25.0.437305594552.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25912/ship41.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:36 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:36 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348956.46.0.0444368166562.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25913/ship42.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:41 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:41 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348961.68.0.438147180619.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25914/ship43.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:49 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:49 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348969.03.0.286673034459.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25915/ship44.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:52 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 17:22:52 +0000 Subject: [issue15041] tkinter documentation "see also" list in Python3 is from Python2 In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za> Message-ID: <1339348972.83.0.916293159378.issue15041@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +asvetlov _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15041> _______________________________________ From report at bugs.python.org Sun Jun 10 19:22:56 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:22:56 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348976.98.0.520511129064.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25916/ship45.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:05 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:05 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348985.47.0.663573390579.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25917/ship46.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:14 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:14 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339348994.22.0.737409037134.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25918/ship47.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:20 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:20 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349000.99.0.645580010203.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25919/ship48.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:33 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:33 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349013.15.0.357053181174.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25920/ship49.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:36 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:36 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349016.76.0.322547512765.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25921/ship50.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:42 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:42 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349022.57.0.793140760192.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25922/ship51.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:48 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:48 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349028.55.0.977292713892.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25923/ship52.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:53 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:53 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349033.26.0.245313086284.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25924/ship53.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:23:57 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:23:57 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349037.8.0.674174367188.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25925/ship54.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:24:02 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:24:02 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349042.09.0.108398292512.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25926/ship55.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:24:06 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:24:06 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349046.88.0.416318576009.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25927/ship56.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:24:12 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:24:12 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349052.31.0.321289868694.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25928/ship57.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:24:17 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:24:17 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349057.75.0.626434837529.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25929/ship58.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:24:23 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:24:23 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349063.3.0.636694620437.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25930/ship59.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:24:35 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:24:35 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349075.71.0.845575792281.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25931/ship60.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:25:00 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Jun 2012 17:25:00 +0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting In-Reply-To: <1187927510.72.0.527812998999.issue1009@psf.upfronthosting.co.za> Message-ID: <1339349100.1.0.82018530732.issue1009@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Removed file: http://bugs.python.org/file25932/ship61.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1009> _______________________________________ From report at bugs.python.org Sun Jun 10 19:29:36 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 17:29:36 +0000 Subject: [issue3518] multiprocessing: BaseManager.from_address documented but doesn't exist In-Reply-To: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za> Message-ID: <1339349376.44.0.178999333455.issue3518@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- assignee: jnoller -> nosy: +sbt versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6, Python 3.0 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3518> _______________________________________ From report at bugs.python.org Sun Jun 10 20:04:47 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 10 Jun 2012 18:04:47 +0000 Subject: [issue15041] tkinter documentation: update "see also" list In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za> Message-ID: <1339351487.46.0.333908343015.issue15041@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: The 2.7 doc can also be updated. Here is a couple to add or replace. Tcl/Tk 8.5 Manual http://www.tcl.tk/man/tcl8.5/ The the current tcl/tk reference manual. The Tk Commands section is the most relevant for tkinter. TKDocs http://www.tkdocs.com/ Extensive tutorial plus friendlier widget pages for some of the widgets. ---------- assignee: -> docs at python components: +Tkinter nosy: +serwy stage: -> needs patch title: tkinter documentation "see also" list in Python3 is from Python2 -> tkinter documentation: update "see also" list versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15041> _______________________________________ From report at bugs.python.org Sun Jun 10 20:47:21 2012 From: report at bugs.python.org (Petr Kubat) Date: Sun, 10 Jun 2012 18:47:21 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1339354041.44.0.496936237364.issue13691@psf.upfronthosting.co.za> Petr Kubat <killme01 at gmail.com> added the comment: Help at the help> prompt does work, I tested that. But if you (or anyone) thought of a better way to fix this issue I would be glad to change it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13691> _______________________________________ From report at bugs.python.org Sun Jun 10 20:51:29 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jun 2012 18:51:29 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <4FD4D46E.1000709@v.loewis.de> Message-ID: <1339354296.18692.82.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > So the answer to your last question is "yes". I hope that the answer to > your other questions follows from that Thank you, this is the answer to all my questions. I've prepared a patch to treat U+FFFE in general mapping as ?undefined mapping?. > (strictly speaking, it's only > U+FFFE, not 0xFFFE, that is documented as indicating an undefined > mapping; a patch should probably fix that). As both integer 0xXXXX and string '\uXXXX' denote U+XXXX, I do not think it necessary fixes. > (I also wonder where the support for LookupError comes from - that > appears to be undocumented) I believe, this is what is meant by the words "undefined mapping". ---------- keywords: +patch Added file: http://bugs.python.org/file25934/decode_charmap_fffe.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ -------------- next part -------------- diff -r 743cf3319862 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sat Jun 09 22:51:39 2012 -0700 +++ b/Objects/unicodeobject.c Sun Jun 10 21:49:34 2012 +0300 @@ -7512,15 +7512,18 @@ if (PyErr_ExceptionMatches(PyExc_LookupError)) { /* No mapping found means: mapping is undefined. */ PyErr_Clear(); - x = Py_None; - Py_INCREF(x); + goto Undefined; } else goto onError; } /* Apply mapping */ + if (x == Py_None) + goto Undefined; if (PyLong_Check(x)) { long value = PyLong_AS_LONG(x); + if (value == 0xFFFE) + goto Undefined; if (value < 0 || value > 65535) { PyErr_SetString(PyExc_TypeError, "character mapping must be in range(65536)"); @@ -7530,21 +7533,6 @@ if (unicode_putchar(&v, &outpos, value) < 0) goto onError; } - else if (x == Py_None) { - /* undefined mapping */ - startinpos = s-starts; - endinpos = startinpos+1; - if (unicode_decode_call_errorhandler( - errors, &errorHandler, - "charmap", "character maps to <undefined>", - &starts, &e, &startinpos, &endinpos, &exc, &s, - &v, &outpos)) { - Py_DECREF(x); - goto onError; - } - Py_DECREF(x); - continue; - } else if (PyUnicode_Check(x)) { Py_ssize_t targetsize; @@ -7554,8 +7542,10 @@ if (targetsize == 1) { /* 1-1 mapping */ - if (unicode_putchar(&v, &outpos, - PyUnicode_READ_CHAR(x, 0)) < 0) + Py_UCS4 value = PyUnicode_READ_CHAR(x, 0); + if (value == 0xFFFE) + goto Undefined; + if (unicode_putchar(&v, &outpos, value) < 0) goto onError; } else if (targetsize > 1) { @@ -7590,6 +7580,19 @@ } Py_DECREF(x); ++s; + continue; +Undefined: + /* undefined mapping */ + Py_XDECREF(x); + startinpos = s-starts; + endinpos = startinpos+1; + if (unicode_decode_call_errorhandler( + errors, &errorHandler, + "charmap", "character maps to <undefined>", + &starts, &e, &startinpos, &endinpos, &exc, &s, + &v, &outpos)) { + goto onError; + } } } if (unicode_resize(&v, outpos) < 0) From report at bugs.python.org Sun Jun 10 22:38:28 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 20:38:28 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1339360708.45.0.263253706798.issue13691@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: "works" in the sense that it produces output. But it doesn't produce the output it used to, which is the same text as the initial banner when you type help(). I believe the existing behavior in this case is correct. With your patch it produces the same output as "help('help')" at the python prompt does, and what that output describes doesn't work at the 'help>' prompt. Thanks for tackling this. Hmm. How about adding the special case to _Helper.__call__? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13691> _______________________________________ From report at bugs.python.org Sun Jun 10 22:40:04 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 10 Jun 2012 20:40:04 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1339360804.75.0.557121130999.issue4489@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Here is a patch with just the shutil changes. Compared to rmtree-with-fwalk-v3.diff, this changes 90 lines of rmtree, whereas the fwalk version changes only 70 lines. On the plus side, it's much more obvious in this version that the *at variant has the same algorithm as the non-*at version. ---------- Added file: http://bugs.python.org/file25935/direct_rmtree_safe.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 10 22:41:02 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Jun 2012 20:41:02 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1339360862.11.0.20806721042.issue13691@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Oh, that wouldn't fix 'pydoc help', would it. So there are probably two places where the special case has to be added, which means the code itself should go in pydoc and be called from _Helper.__call__ somehow. (Note, I'm just throwing out ideas here, I haven't looked carefully at the code.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13691> _______________________________________ From report at bugs.python.org Sun Jun 10 22:48:12 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 10 Jun 2012 20:48:12 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1339361292.42.0.798468964389.issue14599@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: I think the issue mentioned in eae7cc54d28b just occurred again: http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6807/steps/test/logs/stdio ====================================================================== ERROR: test_module (test.test_reprlib.LongReprTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_reprlib.py", line 257, in test_module from areallylongpackageandmodulenametotestreprtruncation.areallylongpackageandmodulenametotestreprtruncation import areallylongpackageandmodulenametotestreprtruncation File "<frozen importlib._bootstrap>", line 1333, in _handle_fromlist File "<frozen importlib._bootstrap>", line 1286, in _find_and_load File "<frozen importlib._bootstrap>", line 1253, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper File "<frozen importlib._bootstrap>", line 776, in load_module File "<frozen importlib._bootstrap>", line 757, in load_module File "<frozen importlib._bootstrap>", line 408, in module_for_loader_wrapper File "<frozen importlib._bootstrap>", line 633, in _load_module File "<frozen importlib._bootstrap>", line 743, in get_code File "<frozen importlib._bootstrap>", line 819, in set_data File "<frozen importlib._bootstrap>", line 127, in _write_atomic FileNotFoundError: [Errno 2] No such file or directory ---------------------------------------------------------------------- ---------- nosy: +skrah resolution: fixed -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14599> _______________________________________ From report at bugs.python.org Mon Jun 11 02:50:37 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jun 2012 00:50:37 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1339375837.61.0.462886863401.issue14119@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Brian: ping. Since this is an enhancement, if you are going to accept it it would be nice to get it into 3.3, which means committing it before June 23rd. ---------- nosy: +r.david.murray stage: -> patch review versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14119> _______________________________________ From report at bugs.python.org Mon Jun 11 03:26:10 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 11 Jun 2012 01:26:10 +0000 Subject: [issue15041] tkinter documentation: update "see also" list In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za> Message-ID: <1339377970.52.0.877674219876.issue15041@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Kevin Walzer, who uses tk/inter regularly, sent me the following effbot has a more recent work-in-progress update of his Tkinter docs here: http://effbot.org/tkinterbook/ I refer to this a lot. "Programming Python" by Mark Lutz (Amazon link here: http://www.amazon.com/Programming-Python-Mark-Lutz/dp/0596158106/ref=dp_ob_title_bk) has excellent coverage of Tkinter. +1 for the TkDocs site--very nice. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15041> _______________________________________ From report at bugs.python.org Mon Jun 11 04:55:13 2012 From: report at bugs.python.org (Brian Quinlan) Date: Mon, 11 Jun 2012 02:55:13 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1339383313.47.0.711866990635.issue14119@psf.upfronthosting.co.za> Brian Quinlan <brian at sweetapp.com> added the comment: Hey Nam, I'm not sure that I understand. You want ThreadPoolExecutor.submit to block if there are too many work items in the queue? Are you sure that this happens currently with ProcessPoolExecutor? I can't see why it would. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14119> _______________________________________ From report at bugs.python.org Mon Jun 11 05:03:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jun 2012 03:03:53 +0000 Subject: [issue15015] Access to non-existing "future" attribute in error path of futures In-Reply-To: <1338973529.66.0.217110755385.issue15015@psf.upfronthosting.co.za> Message-ID: <E1Sduv0-0004Ed-Cf@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 68d7c0be5890 by Brian Quinlan in branch 'default': #15015: Fix accessing an non-existing attribute. http://hg.python.org/cpython/rev/68d7c0be5890 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15015> _______________________________________ From report at bugs.python.org Mon Jun 11 05:06:31 2012 From: report at bugs.python.org (Brian Quinlan) Date: Mon, 11 Jun 2012 03:06:31 +0000 Subject: [issue15015] Access to non-existing "future" attribute in error path of futures In-Reply-To: <1338973529.66.0.217110755385.issue15015@psf.upfronthosting.co.za> Message-ID: <1339383991.79.0.618756434377.issue15015@psf.upfronthosting.co.za> Brian Quinlan <brian at sweetapp.com> added the comment: Thanks for the patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15015> _______________________________________ From report at bugs.python.org Mon Jun 11 05:56:36 2012 From: report at bugs.python.org (Nam Nguyen) Date: Mon, 11 Jun 2012 03:56:36 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1339386996.52.0.563942456588.issue14119@psf.upfronthosting.co.za> Nam Nguyen <bitsink at gmail.com> added the comment: Currently, ProcessionPoolExecutor has this line in its constructor: self._call_queue = multiprocessing.Queue(self._max_workers + EXTRA_QUEUED_CALLS) where EXTRA_QUEUED_CALLS is 1. And yes, it would be best to export a method so that the app developer can set the queue size for themselves. In my case, I would want to limit the queue so that I dont run out of memory. Others might not want the queue to block, and hence would prefer an unlimited queue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14119> _______________________________________ From report at bugs.python.org Mon Jun 11 06:35:12 2012 From: report at bugs.python.org (Brian Quinlan) Date: Mon, 11 Jun 2012 04:35:12 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1339389312.53.0.285998093302.issue14119@psf.upfronthosting.co.za> Brian Quinlan <brian at sweetapp.com> added the comment: The queue that you identified i.e. self._call_queue = multiprocessing.Queue(self._max_workers + EXTRA_QUEUED_CALLS) does not get considered during submit() - are you sure that it somehow causes submit() to block. Could you explain what your use case is such that you can run out of memory? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14119> _______________________________________ From report at bugs.python.org Mon Jun 11 06:46:08 2012 From: report at bugs.python.org (Nam Nguyen) Date: Mon, 11 Jun 2012 04:46:08 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1339389968.28.0.512523483247.issue14119@psf.upfronthosting.co.za> Nam Nguyen <bitsink at gmail.com> added the comment: I used the ThreadPoolExecutor to process a large number (bounded) of input/output jobs. Because there were too many of them and the worker threads could not process them fast enough to drain them from the queue, the queue kept increasing in size. It was okay for the script, though, to block, waiting for the queue to drain, before submitting new jobs. So I needed to limit the queue size. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14119> _______________________________________ From report at bugs.python.org Mon Jun 11 09:31:56 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 11 Jun 2012 07:31:56 +0000 Subject: [issue15040] stdlib compatability with pypy: mailbox.py In-Reply-To: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> Message-ID: <1339399916.57.0.234035917179.issue15040@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: I'm not sure about the __del__: if pypy's deferred garbage collection is not enough to close self._file, how can a __del__ method help? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Mon Jun 11 11:29:51 2012 From: report at bugs.python.org (Petr Kubat) Date: Mon, 11 Jun 2012 09:29:51 +0000 Subject: [issue13691] pydoc help (or help('help')) should show the doc for help In-Reply-To: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za> Message-ID: <1339406991.34.0.912573485599.issue13691@psf.upfronthosting.co.za> Petr Kubat <killme01 at gmail.com> added the comment: I see. So calling help('help') should produce the documentation on the help() function and typing help at the help> prompt should print the help for the prompt. Tricky indeed. I think I'll look at it during the day after tomorrow and post some results (if any). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13691> _______________________________________ From report at bugs.python.org Mon Jun 11 12:53:37 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 11 Jun 2012 10:53:37 +0000 Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent() In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za> Message-ID: <1339412017.45.0.371064975909.issue13857@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- assignee: -> ncoghlan stage: needs patch -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13857> _______________________________________ From report at bugs.python.org Mon Jun 11 13:40:34 2012 From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=) Date: Mon, 11 Jun 2012 11:40:34 +0000 Subject: [issue7300] Unicode arguments in str.format() In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za> Message-ID: <1339414834.29.0.381834425117.issue7300@psf.upfronthosting.co.za> Changes by G?k?en Eraslan <gokcen at pardus.org.tr>: ---------- nosy: +G?k?en.Eraslan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7300> _______________________________________ From report at bugs.python.org Mon Jun 11 13:47:24 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 11 Jun 2012 11:47:24 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1339415244.93.0.150645210648.issue4489@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Fair enough, I'm not going to question your obviously superior judgement here. :) However, your patch currently breaks the test suite on any platform that uses the fallback rmtree: You forgot the ignore_errors=False in the _rmtree_unsafe signature (and obviously also the argument when calling it as a fallback). You also didn't seem to have touched the tests? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Mon Jun 11 14:48:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 11 Jun 2012 12:48:40 +0000 Subject: [issue15043] test_gdb is disallowed by default security settings in Fedora 17 Message-ID: <1339418920.32.0.804230672204.issue15043@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: Running test_gdb on Fedora 17 produces a litany of the following error: - warning: File "/home/ncoghlan/devel/py3k/python-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "/usr/share/gdb/auto-load:/usr/lib/debug:/usr/bin/mono-gdb.py". Presumably some security features in gdb have either been added, or enabled by default, with the F17 update. The devguide needs to be updated with a reference to the relevant gdb security settings so contributors can get it running again. ---------- components: Devguide messages: 162610 nosy: dmalcolm, ezio.melotti, ncoghlan priority: normal severity: normal status: open title: test_gdb is disallowed by default security settings in Fedora 17 type: enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15043> _______________________________________ From report at bugs.python.org Mon Jun 11 14:51:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 11 Jun 2012 12:51:14 +0000 Subject: [issue15043] test_gdb is disallowed by default security settings in Fedora 17 In-Reply-To: <1339418920.32.0.804230672204.issue15043@psf.upfronthosting.co.za> Message-ID: <1339419074.36.0.691048751374.issue15043@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: In addition, we should probably report this as a test skip rather than as a litany of test failures. ---------- components: +Tests _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15043> _______________________________________ From report at bugs.python.org Mon Jun 11 14:54:36 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 11 Jun 2012 12:54:36 +0000 Subject: [issue15044] _dbm not building on Fedora 17 Message-ID: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: After upgrading from Fedora 16 -> 17, my previously working trunk build is getting the following error: Building '_dbm' extension gcc -pthread -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -DHAVE_NDBM_H -IInclude -I. -I./Include -I/usr/local/include -I/home/ncoghlan/devel/py3k -c /home/ncoghlan/devel/py3k/Modules/_dbmmodule.c -o build/temp.linux-x86_64-3.3-pydebug/home/ncoghlan/devel/py3k/Modules/_dbmmodule.o gcc -pthread -shared build/temp.linux-x86_64-3.3-pydebug/home/ncoghlan/devel/py3k/Modules/_dbmmodule.o -L/usr/local/lib -o build/lib.linux-x86_64-3.3-pydebug/_dbm.cpython-33dm.so *** WARNING: renaming "_dbm" since importing it failed: build/lib.linux-x86_64-3.3-pydebug/_dbm.cpython-33dm.so: undefined symbol: dbm_nextkey Failed to build these modules: _dbm ---------- components: Extension Modules messages: 162612 nosy: dmalcolm, ncoghlan priority: normal severity: normal status: open title: _dbm not building on Fedora 17 type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15044> _______________________________________ From report at bugs.python.org Mon Jun 11 15:08:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jun 2012 13:08:35 +0000 Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent() In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za> Message-ID: <E1Se4MC-0006xG-Ud@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 6f7afe25d681 by Nick Coghlan in branch 'default': Close #13857: Added textwrap.indent() function (initial patch by Ezra http://hg.python.org/cpython/rev/6f7afe25d681 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13857> _______________________________________ From report at bugs.python.org Mon Jun 11 15:15:18 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 11 Jun 2012 13:15:18 +0000 Subject: [issue10469] test_socket fails using Visual Studio 2010 In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za> Message-ID: <1339420518.98.0.614077374357.issue10469@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: This has been fixed with the proper 2010 support ---------- resolution: -> fixed status: open -> closed superseder: -> Support Visual Studio 2010 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10469> _______________________________________ From report at bugs.python.org Mon Jun 11 15:16:45 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 11 Jun 2012 13:16:45 +0000 Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent() In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za> Message-ID: <1339420605.57.0.249887966876.issue13857@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Ezra (and anyone interested) may want to take a look at the checked in version to see some of the changes I made while preparing the patch for commit. - name changes and slight restructure as discussed on the review - splitlines() invocation changed as discussed above - doc examples changed to doctest style - tests reworked to use a parameterised style (taking the easy way out of just failing on the first broken case, since there aren't that many cases and the test is quick to run) - default predicate reworked to round trip with textwrap.dedent ---------- resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13857> _______________________________________ From report at bugs.python.org Mon Jun 11 15:18:53 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 11 Jun 2012 13:18:53 +0000 Subject: [issue10854] Output .pyd name in error message of ImportError when DLL load fails In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za> Message-ID: <1339420733.5.0.71455197823.issue10854@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Brian, reopening this since the original issue isn't addressed: The "path" and "module" attributes aren't part of the error "repr" ---------- status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10854> _______________________________________ From report at bugs.python.org Mon Jun 11 15:29:18 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 11 Jun 2012 13:29:18 +0000 Subject: [issue15045] Make textwrap.dedent() consistent with str.splitlines(True) and str.strip() Message-ID: <1339421358.2.0.611530152115.issue15045@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: In working on #13857, I noticed that the current regex based implementation of textwrap.dedent() is limited specifically to ASCII whitespace (tabs and spaces) with Unix line endings (a line containing solely a Windows "\r\n" line ending will be deemed to contain a non-whitespace character, since "\r" isn't recognised by the regex) The new textwrap.indent() function added in #13857 takes a much simpler approach to whitespace handling: its definition of a "line" is exactly that of "text.splitlines(True)", while its definition of a line that does not consist solely of whitespace is "bool(line.strip())" As a simple example of how that can make a difference, consider: >>> "\N{NO-BREAK SPACE}".strip() '' One way to remedy this would be to replace the regex based implementation of textwrap.dedent with a simpler one written in terms of text.splitlines(True) and line.strip(). ---------- components: Library (Lib) messages: 162617 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Make textwrap.dedent() consistent with str.splitlines(True) and str.strip() type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15045> _______________________________________ From report at bugs.python.org Mon Jun 11 15:31:24 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 11 Jun 2012 13:31:24 +0000 Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent() In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za> Message-ID: <1339421484.7.0.215702201211.issue13857@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13857> _______________________________________ From report at bugs.python.org Mon Jun 11 15:45:03 2012 From: report at bugs.python.org (Samuel John) Date: Mon, 11 Jun 2012 13:45:03 +0000 Subject: [issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library In-Reply-To: <19830.44206.997189.286834@montanaro.dyndns.org> Message-ID: <1339422303.92.0.402292916099.issue11445@psf.upfronthosting.co.za> Changes by Samuel John <python at samueljohn.de>: ---------- nosy: +samueljohn _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11445> _______________________________________ From report at bugs.python.org Mon Jun 11 16:19:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jun 2012 14:19:57 +0000 Subject: [issue10133] multiprocessing: conn_recv_string() broken error handling In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za> Message-ID: <E1Se5TE-00060A-Ll@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 60a7b704de5c by Richard Oudkerk in branch '2.7': Issue #10133: Make multiprocessing deallocate buffer if socket read fails. http://hg.python.org/cpython/rev/60a7b704de5c New changeset 5643697070c0 by Richard Oudkerk in branch '3.2': Issue #10133: Make multiprocessing deallocate buffer if socket read fails. http://hg.python.org/cpython/rev/5643697070c0 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10133> _______________________________________ From report at bugs.python.org Mon Jun 11 16:22:10 2012 From: report at bugs.python.org (Jason Tishler) Date: Mon, 11 Jun 2012 14:22:10 +0000 Subject: [issue13756] Python3.2.2 make fail on cygwin In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za> Message-ID: <1339424530.23.0.281052548729.issue13756@psf.upfronthosting.co.za> Jason Tishler <jason at tishler.net> added the comment: I offer the attached patch for consideration. AFAICT, only the Makefile.pre.in and build_ext.py changes are required. I included the makesetup change for completeness and to be consistent with the other changes. ---------- keywords: +patch nosy: +jlt63, yselkowitz Added file: http://bugs.python.org/file25936/3.2.3-libpython-abi.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13756> _______________________________________ From report at bugs.python.org Mon Jun 11 16:46:11 2012 From: report at bugs.python.org (Marco den Otter) Date: Mon, 11 Jun 2012 14:46:11 +0000 Subject: [issue15046] Missing cast to Py_ssize_t in socket_connection.c Message-ID: <1339425971.4.0.190872780402.issue15046@psf.upfronthosting.co.za> New submission from Marco den Otter <marco.den.otter at nspyre.nl>: In the file socket_connection.c on line 139 a cast to Py_ssize_t is missing for the return value. Is: return res < 0 ? res : ulength; Should be return res < 0 ? (Py_ssize_t)res : (Py_ssize_t)ulength; Now it can be possible that a close of the socket is not detected. Found the bug by creating a server client that only sends the length of a data package and then closing the socket. Without the cast the calling function (connection_recvbytes in connection.h) will try to return an object because of not detecting the result was smaller then 0. ---------- components: Library (Lib) messages: 162620 nosy: MOtter priority: normal severity: normal status: open title: Missing cast to Py_ssize_t in socket_connection.c type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15046> _______________________________________ From report at bugs.python.org Mon Jun 11 17:05:54 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 11 Jun 2012 15:05:54 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1339427154.23.0.763321421748.issue14599@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: If you look at line 127 in importlib/_bootstrap.py you will see that it is an os.open() call to open the bytecode file for exclusive writing. I'm willing to bet the buildbot didn't have the directory writable or something and that triggered the issue. Regardless, this has nothing to do with the finder's cache. Antoine might have a little more insight since he wrote the atomic code initially. If not then this issue should be closed. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14599> _______________________________________ From report at bugs.python.org Mon Jun 11 17:12:46 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 11 Jun 2012 15:12:46 +0000 Subject: [issue10133] multiprocessing: conn_recv_string() broken error handling In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za> Message-ID: <1339427566.21.0.0918953344364.issue10133@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: Thanks for the patch, I have applied it. (I don't think there was a problem with the promotion rules because res was a never converted to UINT32.) ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10133> _______________________________________ From report at bugs.python.org Mon Jun 11 17:20:05 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 11 Jun 2012 15:20:05 +0000 Subject: [issue8028] self.terminate() from a multiprocessing.Process raises AttributeError exception In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za> Message-ID: <1339428005.63.0.103998470325.issue8028@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: The docs were patched in changeset 9fa52478b32b, so I will close. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8028> _______________________________________ From report at bugs.python.org Mon Jun 11 17:28:01 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 11 Jun 2012 15:28:01 +0000 Subject: [issue10037] multiprocessing.pool processes started by worker handler stops working In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za> Message-ID: <1339428481.68.0.979049803359.issue10037@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- resolution: -> later stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10037> _______________________________________ From report at bugs.python.org Mon Jun 11 17:46:10 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 11 Jun 2012 15:46:10 +0000 Subject: [issue8289] multiprocessing.Process.__init__ pickles all arguments In-Reply-To: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za> Message-ID: <1339429570.83.0.131409168944.issue8289@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: I don't think there is any problem here since you have control over which arguments you pass to __init__. Without a reason why that is not a solution I will eventually close the issue as rejected. ---------- resolution: -> rejected stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8289> _______________________________________ From report at bugs.python.org Mon Jun 11 17:46:27 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 11 Jun 2012 15:46:27 +0000 Subject: [issue12897] Support for iterators in multiprocessing map In-Reply-To: <1315224105.15.0.691135308397.issue12897@psf.upfronthosting.co.za> Message-ID: <1339429587.11.0.0967805053837.issue12897@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: Unless you have a reason why imap() does not solve the problem I will eventually close the issue as rejected. ---------- resolution: -> rejected stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12897> _______________________________________ From report at bugs.python.org Mon Jun 11 17:51:04 2012 From: report at bugs.python.org (Samuel John) Date: Mon, 11 Jun 2012 15:51:04 +0000 Subject: [issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move In-Reply-To: <1333576900.91.0.0583021085072.issue14499@psf.upfronthosting.co.za> Message-ID: <1339429864.38.0.240418399559.issue14499@psf.upfronthosting.co.za> Changes by Samuel John <python at samueljohn.de>: ---------- nosy: +samueljohn _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14499> _______________________________________ From report at bugs.python.org Mon Jun 11 18:14:14 2012 From: report at bugs.python.org (andrew cooke) Date: Mon, 11 Jun 2012 16:14:14 +0000 Subject: [issue12897] Support for iterators in multiprocessing map In-Reply-To: <1315224105.15.0.691135308397.issue12897@psf.upfronthosting.co.za> Message-ID: <1339431254.42.0.0108579561446.issue12897@psf.upfronthosting.co.za> andrew cooke <andrew at acooke.org> added the comment: hi - i'm the original author (may be using a different account). as far as i remember, i raised this because it seemed relevant given the link i gave. if you've looked at the issue and think your approach would work, or that this should be closed, or whatever, that's fine by me. i'm not going to check myself - i can't remember anything about this now (nearly a year later) and it's not my place to worry about your code (no offence - just trying to clarify that i have no skin in this game). ---------- status: pending -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12897> _______________________________________ From report at bugs.python.org Mon Jun 11 18:21:37 2012 From: report at bugs.python.org (Ram Rachum) Date: Mon, 11 Jun 2012 16:21:37 +0000 Subject: [issue8289] multiprocessing.Process.__init__ pickles all arguments In-Reply-To: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za> Message-ID: <1339431697.33.0.407619233965.issue8289@psf.upfronthosting.co.za> Ram Rachum <ram at rachum.com> added the comment: I opened this issue 2 years ago, and I don't remember it being easily solvable back then. But I've long forgotten what the problems were, and I've lost personal interest in it, so I guess we'll just let it go. ---------- status: pending -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8289> _______________________________________ From report at bugs.python.org Mon Jun 11 18:57:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jun 2012 16:57:53 +0000 Subject: [issue3518] multiprocessing: BaseManager.from_address documented but doesn't exist In-Reply-To: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za> Message-ID: <E1Se7w4-0005gY-JR@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c2910971eb86 by Richard Oudkerk in branch 'default': Issue #3518: Remove references to non-existent BaseManager.from_address() http://hg.python.org/cpython/rev/c2910971eb86 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3518> _______________________________________ From report at bugs.python.org Mon Jun 11 19:03:52 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 11 Jun 2012 17:03:52 +0000 Subject: [issue12897] Support for iterators in multiprocessing map In-Reply-To: <1315224105.15.0.691135308397.issue12897@psf.upfronthosting.co.za> Message-ID: <1339434232.11.0.652753727286.issue12897@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: I'll close then. ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12897> _______________________________________ From report at bugs.python.org Mon Jun 11 19:04:42 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 11 Jun 2012 17:04:42 +0000 Subject: [issue8289] multiprocessing.Process.__init__ pickles all arguments In-Reply-To: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za> Message-ID: <1339434282.78.0.156626521041.issue8289@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: OK, I'll close. ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8289> _______________________________________ From report at bugs.python.org Mon Jun 11 19:34:35 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 11 Jun 2012 17:34:35 +0000 Subject: [issue3518] multiprocessing: BaseManager.from_address documented but doesn't exist In-Reply-To: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za> Message-ID: <1339436075.27.0.390614155897.issue3518@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3518> _______________________________________ From report at bugs.python.org Mon Jun 11 19:44:49 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 11 Jun 2012 17:44:49 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1339436689.88.0.88277823174.issue9527@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: This was originally posted on python-dev, but I hope reposting it here will make this issue easier to navigate. """ With addition of fixed offset timezone class and the timezone.utc instance [0], it is easy to get UTC time as an aware datetime instance: >>> datetime.now(timezone.utc) datetime.datetime(2010, 8, 3, 14, 16, 10, 670308, tzinfo=datetime.timezone.utc) However, if you want to keep time in your local timezone, getting an aware datetime is almost a catch 22. If you know your timezone UTC offset, you can do >>> EDT = timezone(timedelta(hours=-4)) >>> datetime.now(EDT) datetime.datetime(2010, 8, 3, 10, 20, 23, 769537, tzinfo=datetime.timezone(datetime.timedelta(-1, 72000))) but the problem is that there is no obvious or even correct way to find local timezone UTC offset. [1] In a comment on issue #5094 ("datetime lacks concrete tzinfo implementation for UTC"), I proposed to address this problem in a localtime([t]) function that would return current time (or time corresponding to the optional datetime argument) as an aware datetime object carrying local timezone information in a tzinfo set to an appropriate timezone instance. This solution is attractive by its simplicity, but there are several problems: 1. An aware datetime cannot carry all information that system localtime() supplies in a time tuple. Specifically, the is_dst flag is lost. This is not a problem for most applications as long as timezone UTC offset and timezone name are available, but may be an issue when interoperability with the time module is required. 2. Datetime's tzinfo interface was designed with the idea that <2010-11-06 12:00 EDT> + <1 day> = <2010-11-07 12:00 EST>, not <2010-11-07 12:00 EDT>. It other words, if I have lunch with someone at noon (12:00 EDT) on Saturday the day before first Sunday in November, and want to meet again "at the same time tomorrow", I mean 12:00 EST, not 24 hours later. With localtime() returning datetime with tzinfo set to fixed offset timezone, however, localtime() + timedelta(1) will mean exactly 24 hours later and the result will be expressed in an unusual for the given location timezone. An alternative approach is the one recommended in the python manual. [3] One could implement a LocalTimezone class with utcoffset(), tzname() and dst() extracting information from system mktime and localtime calls. This approach has its own shortcomings: 1. While adding integral number of days to datetimes in business setting, it is natural to expect automatic timezone adjustments, it is not as clearcut when adding hours or minutes. 2. The tzinfo.utcoffset() interface that expects *standard* local time as an argument is confusing to many users. Even the "official" example in the python manual gets it wrong. [4] 3. datetime(..., tzinfo=LocalTimezone()) is ambiguous during the "repeated hour" when local clock is set back in DST to standard time transition. As far as I can tell, the only way to resolve the last problem is to add is_dst flag to the datetime object, which would also be the only way to achieve full interoperability between datetime objects and time tuples. [5] The traditional answer to a call for improvement of timezone support in datetime module has been: "this is up to 3rd parties to implement." Unfortunately, stdlib is asking 3rd parties to implement an impossible interface without giving access to the necessary data. The impossibility comes from the requirement that dst() method should find out whether local time represents DST or standard time while there is an hour each year when the same local time can be either. The missing data is the system UTC offset when it changes historically. The time module only gives access to the current UTC offset. My preference is to implement the first alternative - localtime([t]) returning aware datetime with fixed offset timezone. This will solve the problem of python's lack of access to the universally available system facilities that are necessary to implement any kind of aware local time support. [0] http://docs.python.org/dev/library/datetime.html#timezone-objects [1] http://bugs.python.org/issue1647654 [2] http://bugs.python.org/issue5094#msg106997 [3] http://docs.python.org/library/datetime.html#tzinfo-objects [4] http://bugs.python.org/issue9063 [5] http://bugs.python.org/issue9004 """ -- http://mail.python.org/pipermail/python-dev/2010-August/102842.html ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Mon Jun 11 19:57:29 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 11 Jun 2012 17:57:29 +0000 Subject: [issue15046] Missing cast to Py_ssize_t in socket_connection.c In-Reply-To: <1339425971.4.0.190872780402.issue15046@psf.upfronthosting.co.za> Message-ID: <1339437449.95.0.361088349615.issue15046@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: This was fixed 3 hours ago, with issue10133 :) ---------- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> closed superseder: -> multiprocessing: conn_recv_string() broken error handling _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15046> _______________________________________ From report at bugs.python.org Mon Jun 11 20:04:22 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 11 Jun 2012 18:04:22 +0000 Subject: [issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0 In-Reply-To: <1276659404.06.0.425467293989.issue9004@psf.upfronthosting.co.za> Message-ID: <1339437862.73.0.948843441072.issue9004@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > Just recommend the astimezone use in the docs and recommend creating tz-aware instances in the first time (i.e. calling now(utc) instead of utcnow()), +1. ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9004> _______________________________________ From report at bugs.python.org Mon Jun 11 20:21:46 2012 From: report at bugs.python.org (Jason Tishler) Date: Mon, 11 Jun 2012 18:21:46 +0000 Subject: [issue15047] Cygwin install (regen) problem Message-ID: <1339438906.76.0.557865099456.issue15047@psf.upfronthosting.co.za> New submission from Jason Tishler <jason at tishler.net>: The Cygwin build is failing during make install -- specifically, during the regen step: [snip] mkdir /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin cp /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-generic/regen /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin/regen export PATH; PATH="`pwd`:$PATH"; \ export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \ export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \ export EXE; EXE=".exe"; \ cd /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin; ./regen python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] Fatal Python error: Py_Initialize: Unable to get the locale encoding ImportError: No module named encodings ./regen: line 3: 2976 Aborted (core dumped) python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h [snip] Note that I seem to be running into the same or similar problem as the following: http://bugs.python.org/issue3626#msg72415 I was able to workaround the core dump problem with the following patch: diff -u Python-2.6.5.orig/Makefile.pre.in Python-2.6.5/Makefile.pre.in --- Python-2.6.5.orig/Makefile.pre.in 2009-12-24 09:19:38.000000000 -0500 +++ Python-2.6.5/Makefile.pre.in 2010-04-13 17:05:04.368555900 -0400 @@ -910,7 +910,7 @@ mkdir $(srcdir)/Lib/$(PLATDIR) cp $(srcdir)/Lib/plat-generic/regen $(srcdir)/Lib/$(PLATDIR)/regen export PATH; PATH="`pwd`:$$PATH"; \ - export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \ + export PYTHONPATH; PYTHONPATH="$(srcdir)/Lib"; \ export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \ export EXE; EXE="$(BUILDEXE)"; \ cd $(srcdir)/Lib/$(PLATDIR); $(RUNSHARED) ./regen Note that I'm building outside of the source tree, so when the original version sets PYTHONPATH to the following: "`pwd`/Lib" it was guaranteed to point to a nonexistent directory. Unfortunately, now the build fails as follows: [snip] mkdir /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin cp /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-generic/regen /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin/regen export PATH; PATH="`pwd`:$PATH"; \ export PYTHONPATH; PYTHONPATH="/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib"; \ export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \ export EXE; EXE=".exe"; \ cd /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin; ./regen python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] Traceback (most recent call last): File "/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/sysconfig.py", line 334, in _init_posix _parse_makefile(makefile, vars) File "/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/sysconfig.py", line 220, in _parse_makefile with open(filename, errors="surrogateescape") as f: IOError: [Errno 2] No such file or directory: '/usr/lib/python3.2/config-3.2m/Makefile' [snip] AFAICT, the problem is when regen runs, python thinks it is running out of an installation directory and not a build directory. Does anyone know how to convince python to think it is running out its build directory even though it is being found in the PATH. If not, does anyone have any other suggestions on how to resolve this problem? ---------- components: Build messages: 162634 nosy: jlt63, yselkowitz priority: normal severity: normal status: open title: Cygwin install (regen) problem versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15047> _______________________________________ From report at bugs.python.org Mon Jun 11 20:48:05 2012 From: report at bugs.python.org (mattip) Date: Mon, 11 Jun 2012 18:48:05 +0000 Subject: [issue15040] stdlib compatability with pypy: mailbox.py In-Reply-To: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> Message-ID: <1339440485.3.0.766327523441.issue15040@psf.upfronthosting.co.za> mattip <matti.picus at gmail.com> added the comment: Revised patch: changes to mailbox.py were not needed for pypy. Someone did a good job with mailbox.py in stdlib 2.7.3 Now the patch only changes tests. The tests in 3.3 are very different, it seems to me there is little that can be reused there. ---------- Added file: http://bugs.python.org/file25937/mailbox.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Mon Jun 11 21:09:50 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jun 2012 19:09:50 +0000 Subject: [issue15040] stdlib compatability with pypy: mailbox.py In-Reply-To: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> Message-ID: <1339441790.75.0.0349060216564.issue15040@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Ah, good. I thought we'd fixed the open/close issues, but I could easily believe we had missed something (especially in Python2). Since the fp stuff is gone in 3, I'd be OK with just applying this. ---------- versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Mon Jun 11 21:37:00 2012 From: report at bugs.python.org (Michael Driscoll) Date: Mon, 11 Jun 2012 19:37:00 +0000 Subject: [issue14446] Remove deprecated tkinter functions In-Reply-To: <1333051070.39.0.337099775152.issue14446@psf.upfronthosting.co.za> Message-ID: <1339443420.69.0.0166358906753.issue14446@psf.upfronthosting.co.za> Michael Driscoll <mike at pythonlibrary.org> added the comment: Do I need to do anything else to those patches I submitted? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14446> _______________________________________ From report at bugs.python.org Mon Jun 11 21:49:03 2012 From: report at bugs.python.org (Michael Driscoll) Date: Mon, 11 Jun 2012 19:49:03 +0000 Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle docstring In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za> Message-ID: <1339444143.13.0.772359880462.issue14927@psf.upfronthosting.co.za> Michael Driscoll <mike at pythonlibrary.org> added the comment: I added the extra information to the docstring for the shuffle method and attached a patch. ---------- keywords: +patch nosy: +michael.driscoll Added file: http://bugs.python.org/file25938/shuffle.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14927> _______________________________________ From report at bugs.python.org Mon Jun 11 21:50:13 2012 From: report at bugs.python.org (Christopher Smith) Date: Mon, 11 Jun 2012 19:50:13 +0000 Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle docstring In-Reply-To: <1339444143.13.0.772359880462.issue14927@psf.upfronthosting.co.za> Message-ID: <CAEPTCsM39qyF0xasH21Fjn+A2bcQUaHNrAttk-jRvHRS5YfzQg@mail.gmail.com> Christopher Smith <smichr at users.sourceforge.net> added the comment: On Tue, Jun 12, 2012 at 1:34 AM, Michael Driscoll <report at bugs.python.org> wrote: > > Michael Driscoll <mike at pythonlibrary.org> added the comment: > > I added the extra information to the docstring for the shuffle method and attached a patch. Thanks Michael (and Python team)! Chris ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14927> _______________________________________ From report at bugs.python.org Mon Jun 11 21:50:34 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 11 Jun 2012 19:50:34 +0000 Subject: [issue14906] rotatingHandler WindowsError In-Reply-To: <1337912379.85.0.584273983424.issue14906@psf.upfronthosting.co.za> Message-ID: <1339444234.88.0.132682118644.issue14906@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: It could be a number of things which are keeping the file open, e.g. * Windows indexing the volume for search * Child process keeping files open (e.g. while copying log files - I can't tell what you're actually copying) You may need to use a tool like FileMon or PSMon to see what's happening, but I don't see any evidence that it's a logging bug. Is there a specific logging statement which is being called which leads to the error? There are several in your snippet. ---------- assignee: -> vinay.sajip nosy: +vinay.sajip _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14906> _______________________________________ From report at bugs.python.org Mon Jun 11 21:56:10 2012 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 11 Jun 2012 19:56:10 +0000 Subject: [issue13756] Python3.2.2 make fail on cygwin In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za> Message-ID: <1339444570.51.0.476857162644.issue13756@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: Hi Jason, if you look in default rule you will see the same, so this relict specific "else case" could be removed. Also in Lib/packaging/command/build_ext.py. ---------- nosy: +rpetrov _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13756> _______________________________________ From report at bugs.python.org Mon Jun 11 22:07:06 2012 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 11 Jun 2012 20:07:06 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1339445226.41.0.225336284598.issue14599@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: There is one long standing issue with length of the build path ... ---------- nosy: +rpetrov _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14599> _______________________________________ From report at bugs.python.org Mon Jun 11 22:13:05 2012 From: report at bugs.python.org (Michael Driscoll) Date: Mon, 11 Jun 2012 20:13:05 +0000 Subject: [issue14966] Fully document subprocess.CalledProcessError In-Reply-To: <1338446762.96.0.360332771622.issue14966@psf.upfronthosting.co.za> Message-ID: <1339445585.68.0.277016758116.issue14966@psf.upfronthosting.co.za> Michael Driscoll <mike at pythonlibrary.org> added the comment: I don't see the error, TimeoutExpired, documented either. At least the doc page mentions CalledProcessError a couple times. Do we want to use the docstring for CalledProcessError for the documentation page? Where on the page would it go? I assume we'd want an example showing how to use it? ---------- nosy: +michael.driscoll _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14966> _______________________________________ From report at bugs.python.org Mon Jun 11 22:32:21 2012 From: report at bugs.python.org (Michael Driscoll) Date: Mon, 11 Jun 2012 20:32:21 +0000 Subject: [issue15041] tkinter documentation: update "see also" list In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za> Message-ID: <1339446741.79.0.813454193044.issue15041@psf.upfronthosting.co.za> Michael Driscoll <mike at pythonlibrary.org> added the comment: I thought the ebook, "Modern Tkinter for Busy Python Developers" by Mark Roseman was pretty good too: http://www.amazon.com/Modern-Tkinter-Python-Developers-ebook/dp/B0071QDNLO/ref=sr_1_1?ie=UTF8&qid=1339446684&sr=8-1 ---------- nosy: +michael.driscoll _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15041> _______________________________________ From report at bugs.python.org Mon Jun 11 23:13:22 2012 From: report at bugs.python.org (Roger Serwy) Date: Mon, 11 Jun 2012 21:13:22 +0000 Subject: [issue13532] In IDLE, sys.stdout.write and sys.stderr can write any pickleable object In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za> Message-ID: <1339449202.12.0.940074276304.issue13532@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: @Ramchandra: "__name__" does not exist for many objects. This issue with the sys.stdout.write encompasses a lot of other issues involving the shortcomings of the RPCProxy object. The following code prevents another prompt from appearing: >>> class A: pass >>> import sys >>> sys.stdout.write(A) Even though "A" is pickleable, IDLE gets stuck trying to write to stdout. In run.py, Executive.runcode gets stuck on "exec(code, self.locals)", and is not interruptable. Restarting the shell makes the IDLE shell responsive again to commands. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13532> _______________________________________ From report at bugs.python.org Mon Jun 11 23:51:53 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 11 Jun 2012 21:51:53 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1339451513.07.0.0428458350265.issue14599@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Roumen, what issue is that? Do you have an issue # you can share? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14599> _______________________________________ From report at bugs.python.org Tue Jun 12 00:10:42 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 11 Jun 2012 22:10:42 +0000 Subject: [issue14446] Remove deprecated tkinter functions In-Reply-To: <1333051070.39.0.337099775152.issue14446@psf.upfronthosting.co.za> Message-ID: <1339452642.84.0.167031935532.issue14446@psf.upfronthosting.co.za> Andrew Svetlov <andrew.svetlov at gmail.com> added the comment: Michael Driscoll, thank you for patch. Let's go on after Python 3.3 release ? those patches should be applied for 3.4. For now we need to wait. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14446> _______________________________________ From report at bugs.python.org Tue Jun 12 01:23:02 2012 From: report at bugs.python.org (James Kyle) Date: Mon, 11 Jun 2012 23:23:02 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths Message-ID: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> New submission from James Kyle <bugs at jameskyle.org>: This behavior is present on OS X 10.7 and framework builds. In this case, the /Library/Python/<version> paths are included in every install. I would consider this behavior non-standard as in most manual python installs only that installations library paths are included. This can lead to surprising and inconsistent behavior if multiple installs are present (very common on osx, e.g. macports + system install). This originated as a macports bug ticket: https://trac.macports.org/ticket/34763 ---------- assignee: ronaldoussoren components: Macintosh messages: 162648 nosy: James.Kyle, ronaldoussoren priority: normal severity: normal status: open title: Manually Installed Python Includes System Wide Paths type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 01:25:43 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 11 Jun 2012 23:25:43 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339457143.34.0.145141575601.issue15048@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: This is intentional behavior, you can install packages you want to share between python installations in /Library/Python instead of the regular site-packages directory. Macports could always patch their site.py file to avoid this. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 01:38:26 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 11 Jun 2012 23:38:26 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339457906.43.0.154584780921.issue15048@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: This was added in issue4865. (The same behavior is present in 3.2 and 3.3) ---------- resolution: -> rejected versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 01:38:34 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 11 Jun 2012 23:38:34 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339457914.08.0.313896760452.issue15048@psf.upfronthosting.co.za> Changes by Ronald Oussoren <ronaldoussoren at mac.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 01:50:07 2012 From: report at bugs.python.org (James Kyle) Date: Mon, 11 Jun 2012 23:50:07 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339458607.52.0.58564390554.issue15048@psf.upfronthosting.co.za> James Kyle <bugs at jameskyle.org> added the comment: Am I missing something or were the problems delineated in issue #4865 solvable by simply sys.path.append("/Library/Python/2.7/site-packages")? What would the process be for reopening this issue for discussion? I'm not sure this is the right way to address this. For example, what if other *nix distros started adding their own custom "common" paths, would Python begin implemented these distro specific deviations from standard behavior? In my honest opinion, there's an expectation of package isolation in independent python installs. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 01:59:57 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 11 Jun 2012 23:59:57 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339459197.8.0.432570232598.issue15048@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: Python installation are already not isolated: there is a per-user site-packages directory on all platforms that is shared between all installations of a particular python release. This directory is located in a subdirectory of ~/.local on POSIX systems (including OSX). Anyway, this cannot be changed for a released version of python because that would break backward compatibility. At "best" this could be disabled in python 3.3 and even there I'm far from convinced that disabling this feature would be worthwhile. ---------- nosy: +ned.deily _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 02:06:55 2012 From: report at bugs.python.org (James Kyle) Date: Tue, 12 Jun 2012 00:06:55 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339459614.99.0.00931081162558.issue15048@psf.upfronthosting.co.za> James Kyle <bugs at jameskyle.org> added the comment: Fair enough. Thanks! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 02:47:32 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 12 Jun 2012 00:47:32 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1339462052.88.0.784676344794.issue14599@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Brett, I reopened this because you said earlier that the test_reprlib failure is due to a race condition where an invalidate_caches() call is needed. You're quite right of course that the new occurrence could be caused by something unrelated. I can't reproduce the failure on Windows 7, so it might be limited to XP. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14599> _______________________________________ From report at bugs.python.org Tue Jun 12 02:53:49 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 12 Jun 2012 00:53:49 +0000 Subject: [issue1667546] Time zone-capable variant of time.localtime Message-ID: <1339462429.55.0.0255147688302.issue1667546@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Reopening. given the uncertainty with #9527, this issue may result in getting the TZ-aware local time support in stdlib sooner. ---------- resolution: duplicate -> stage: committed/rejected -> patch review status: closed -> open versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1667546> _______________________________________ From report at bugs.python.org Tue Jun 12 03:12:37 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 Jun 2012 01:12:37 +0000 Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle docstring In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za> Message-ID: <1339463557.72.0.895264487547.issue14927@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- assignee: -> rhettinger _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14927> _______________________________________ From report at bugs.python.org Tue Jun 12 03:13:40 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 Jun 2012 01:13:40 +0000 Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle docstring In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za> Message-ID: <1339463620.97.0.150949729913.issue14927@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- priority: normal -> low _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14927> _______________________________________ From report at bugs.python.org Tue Jun 12 03:15:24 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jun 2012 01:15:24 +0000 Subject: [issue15049] line buffering isn't always Message-ID: <1339463724.73.0.621165878269.issue15049@psf.upfronthosting.co.za> New submission from R. David Murray <rdmurray at bitdance.com>: rdmurray at hey:~/python/p32>cat bad.py This line is just ascii A second line for good measure. This comment contains undecodable stuff: "?" or "\\xe9" in "pass?"" cannot be decoded. The last line above is in latin-1, with an ? inside those quotes. rdmurray at hey:~/python/p32>cat bug.py import sys with open('./bad.py', buffering=int(sys.argv[1])) as f: for line in f: print(line, end='') rdmurray at hey:~/python/p32>python3 bug.py -1 Traceback (most recent call last): File "bug.py", line 3, in <module> for line in f: File "/usr/lib/python3.2/codecs.py", line 300, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 99: invalid continuation byte rdmurray at hey:~/python/p32>python3 bug.py 1 Traceback (most recent call last): File "bug.py", line 3, in <module> for line in f: File "/usr/lib/python3.2/codecs.py", line 300, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 99: invalid continuation byte rdmurray at hey:~/python/p32>python3 bug.py 2 This line is just ascii A second line for good measure. Traceback (most recent call last): File "bug.py", line 3, in <module> for line in f: File "/usr/lib/python3.2/codecs.py", line 300, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 0: invalid continuation byte So, line buffering does not appear to buffer line by line. I ran into this problem because I had a much larger file that I thought was in utf-8. When I got the encoding error, I was annoyed that the error message didn't really tell me which line the error was on, but I figured, OK, I'll just set line buffering and then I'll be able to tell. But that didn't work. Fortunately using '2' did work....but at a minimum the docs need to be updated to indicate when line buffering really is line buffering and when it isn't. ---------- messages: 162656 nosy: pitrou, r.david.murray priority: normal severity: normal stage: needs patch status: open title: line buffering isn't always type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15049> _______________________________________ From report at bugs.python.org Tue Jun 12 03:50:37 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 Jun 2012 01:50:37 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339465837.82.0.402698679029.issue15048@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: I have to admit that I'm not keen on this feature for the reasons James cited. And I think the example of the shared user site directory is not a good analogy. In that case, you, as a user, have more control over the presence and contents of the directory since it is located within your home directory. You would normally need administrator privilege to manipulate /Library/Python. And, in any case, it would be better if there *were* separate user site directories per Python instance, IMO. Yes, you can play with sys.path after the fact but that's not very friendly. It certainly can lead to confusion. An uncontrived example: $ sudo easy_install-2.7 appscript [...] Installed /Library/Python/2.7/site-packages/appscript-1.0.0-py2.7-macosx-10.7-intel.egg $ /usr/bin/python2.7 -c "import appscript" $ /usr/local/bin/python2.7 -c "import appscript" Traceback (most recent call last): File "<string>", line 1, in <module> File "build/bdist.macosx-10.7-intel/egg/appscript/__init__.py", line 8, in <module> File "build/bdist.macosx-10.7-intel/egg/aem/__init__.py", line 5, in <module> File "build/bdist.macosx-10.7-intel/egg/aem/ae.py", line 7, in <module> File "build/bdist.macosx-10.7-intel/egg/aem/ae.py", line 3, in __bootstrap__ ImportError: No module named pkg_resources ... because the non-system Python did not have Distribute or setuptools installed, whereas Apple supplies it with the system Python. It's not the only package to fail in a similar way. I expect there are other cases where differences in extension module builds could cause problems. To me, the feature seems to go against "explicit is better than implicit". As far as I know, the only place where this behavior is documented is in the What's New documents for 2.7. I wouldn't object to removing it in 3.3. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 04:27:40 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 12 Jun 2012 02:27:40 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1339468060.98.0.34357067838.issue9527@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Two objections have been raised to the proposed datetime.localtime() function: 1. It offers the third subtly different way to obtain current time in datetime module. The first two being provided by datetime.now() and datetime.today(). 2. C library localtime function takes POSIX timestamp as an argument, so datetime.localtime() should follow suit. I attach a prototype patch for a different approach: make datetime.astimezone() method supply local timezone information if no argument is given. This patch also demonstrates that extracting all TZ information that platform may have knowledge of is not trivial. ---------- Added file: http://bugs.python.org/file25939/datetime-astimezone-proto.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Tue Jun 12 04:28:35 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 12 Jun 2012 02:28:35 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1339468115.63.0.156292922087.issue9527@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: Added file: http://bugs.python.org/file25940/testtz.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Tue Jun 12 04:41:41 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 Jun 2012 02:41:41 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339468901.2.0.980332630753.issue15048@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: A few more thoughts. The original impetus for this feature was Issue4865. The use case there seem to be from users of Google App Engine back when it was released using Python 2.5. It seems to me that the use of dmg installers for Python packages has diminished; certainly the unofficial packages at pythonmac.org haven't been updated for more recent releases. The issues with installing some packages (like PIL) with 3rd-party C library dependencies notwithstanding, I wonder if part of the original call for this feature was the fact that Apple does provide setuptools easy_install's with system Pythons and there is confusion that a setuptools/Distribute instance, with its own easy_install command, is needed for each Python. Some of that confusion should diminish over time with the availability of "pip -E" and, starting with 3.3, a batteries-included installer command, pysetup. Also, with regard to backward compatibility, I speculate that there hasn't been much notice of this feature since it only affects users of Python 2.7 on OS X 10.7+. For Python 3, the presence or absence of the feature doesn't affect anyone because Apple has yet to ship a system Python 3 so removing it from 3.3 would have no backward compatibility impacts, unless an administrator manually created a /Library/Python/3.x for some reason and manually installed things there. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 05:18:38 2012 From: report at bugs.python.org (James Henstridge) Date: Tue, 12 Jun 2012 03:18:38 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1339471117.87.0.0351583425895.issue9527@psf.upfronthosting.co.za> James Henstridge <james at jamesh.id.au> added the comment: One problem I can see with using a fixed offset tzinfo for localtime is that it might confuse people when doing date arithmetic. For example: >>> d = datetime.localtime() + timedelta(days=7) While it will give a correct answer as a point in time it will have the wrong time zone offset if run just before a daylight saving transition, which could be just as confusing. I'm not sure how you'd solve this without e.g. importing pytz into the standard library though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Tue Jun 12 05:28:29 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Jun 2012 03:28:29 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1339471709.73.0.238320200937.issue15003@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: > Is this documented in whatsnew? I'm not sure what has been (none of my patches have done so). > Also, I remember a discussion about making it public or not, but > don?t recall a decision. Amaury brought it up in msg162127. His point was that the type is public in Python, so why not the C API? That's about the extent of the discussion. :) Do you see any harm in making PyNamespace_New() public? > I personally find it bad that we have structseqs for most things, dicts > in PEP 418 get_clock_info return values, and now simplenamespace for > sys.implementation. The use cases are different for the different types. StructSequence/namedtuple provides fixed data structures for structured records. A dict is essentially the opposite: an un-fixed data structure for dynamic namespaces, making no firm promises as to what the future holds. SimpleNamespace fills a similar role to dicts, but offers a higher appearance of stability by virtue of using attributes vs. keys. The problem is that moving from item-access to attribute-access is not a backward-compatible change. That's the big reason why PEP 421 specified the use of an attr-based object. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Tue Jun 12 10:01:44 2012 From: report at bugs.python.org (Grey_Shao) Date: Tue, 12 Jun 2012 08:01:44 +0000 Subject: [issue15050] Python 3.2.3 fail to make Message-ID: <1339488103.99.0.17701742584.issue15050@psf.upfronthosting.co.za> New submission from Grey_Shao <shojnhv at 163.com>: When I try to compile the Python 3.2.3, I failed to make After I ungzip and untar the source package of the Python 3.2.3, Then run the following commands: 1. ./configure 2. make When step 2, the errors below happens: gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Mod ules/python.o ./Modules/python.c In file included from Include/Python.h:50, from ./Modules/python.c:3: Include/pyport.h:260:13: #error "This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG" *** Error code 1 make: Fatal error: Command failed for target `Modules/python.o' Can you help me My system OS is: uname -a SunOS HPCT01 5.9 Generic_117171-02 sun4u sparc SUNW,Sun-Fire-280R I attached install history file Thanks ---------- components: None files: Python3.2.3_Install_History_20120612.txt messages: 162662 nosy: shojnhv priority: normal severity: normal status: open title: Python 3.2.3 fail to make type: compile error versions: Python 3.2 Added file: http://bugs.python.org/file25941/Python3.2.3_Install_History_20120612.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15050> _______________________________________ From report at bugs.python.org Tue Jun 12 10:35:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 12 Jun 2012 08:35:32 +0000 Subject: [issue15050] Python 3.2.3 fail to make In-Reply-To: <1339488103.99.0.17701742584.issue15050@psf.upfronthosting.co.za> Message-ID: <1339490132.89.0.852507765293.issue15050@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Can you please attach the config.log file also? Also, can you please report what the value of PRId64 in /usr/include/inttypes.h is? ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15050> _______________________________________ From report at bugs.python.org Tue Jun 12 11:00:14 2012 From: report at bugs.python.org (Brian Quinlan) Date: Tue, 12 Jun 2012 09:00:14 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1339491614.89.0.115519452892.issue14119@psf.upfronthosting.co.za> Brian Quinlan <brian at sweetapp.com> added the comment: I've had people request that they be able control the order of processed work submissions. So a more general way to solve your problem might be to make the two executors take an optional Queue argument in their constructors. You'd have to explain in detail in the document how the queues are used. What do you think? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14119> _______________________________________ From report at bugs.python.org Tue Jun 12 12:35:27 2012 From: report at bugs.python.org (Hallvard B Furuseth) Date: Tue, 12 Jun 2012 10:35:27 +0000 Subject: [issue10133] multiprocessing: conn_recv_string() broken error handling In-Reply-To: <1339427566.21.0.0918953344364.issue10133@psf.upfronthosting.co.za> Message-ID: <2cd3c413cf4d8ce79db24836f748e179@ulrik.uio.no> Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment: Richard Oudkerk <report at bugs.python.org> wrote: > Thanks for the patch, I have applied it. (I don't think there was a > problem with the promotion rules because res was a never converted to > UINT32.) True now that res is a Py_ssize_t. It was int when I wrote the patch. Hallvard ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10133> _______________________________________ From report at bugs.python.org Tue Jun 12 13:53:57 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Jun 2012 11:53:57 +0000 Subject: [issue15033] Different exit status when using -m In-Reply-To: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za> Message-ID: <1339502037.89.0.341645362161.issue15033@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Technically, it returns -1 (which later gets coerced to an unsigned value). However, there's no good reason for the inconsistency - the offending line (663) in main.c should be changed to be: sts = (RunModule(module, 1) != 0); It is currently just: sts = RunModule(module, 1); An additional test in test_cmd_line_script is also needed to ensure that both variants give a returncode of 1 in the future. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15033> _______________________________________ From report at bugs.python.org Tue Jun 12 13:57:37 2012 From: report at bugs.python.org (Michael Herrmann) Date: Tue, 12 Jun 2012 11:57:37 +0000 Subject: [issue12982] .pyo file can't be imported unless -O is given In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339502257.26.0.373028531891.issue12982@psf.upfronthosting.co.za> Michael Herrmann <mherrmann.at at gmail.com> added the comment: Hi, I need to use a third-party library that ships as a mixture of .pyc and .pyo files. I found it a little surprising and inconvenient that I have to set the -O flag just to read .pyo files. I don't mind whether .pyc or .pyo files are being created during compilation, I just want to be able to read from both .pyc and .pyo files without having to use the -O flag. Can somebody fix this? I unfortunately have absolutely no clue how. Thanks! ---------- components: +Interpreter Core -Documentation nosy: +mherrmann.at _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 13:57:54 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Jun 2012 11:57:54 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1339502274.57.0.972359207196.issue13598@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: One brief comment on the wording of the error message: the inconsistent naming is actually copied from the str.format code. >>> "{foo} {} {bar}".format(2, foo='fooval', bar='barval') 'fooval 2 barval' >>> "{foo} {0} {} {bar}".format(2, foo='fooval', bar='barval') Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: cannot switch from manual field specification to automatic field numbering ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13598> _______________________________________ From report at bugs.python.org Tue Jun 12 14:00:10 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Jun 2012 12:00:10 +0000 Subject: [issue13578] Add subprocess.iter_output() convenience function In-Reply-To: <1323579954.88.0.437166836576.issue13578@psf.upfronthosting.co.za> Message-ID: <1339502410.8.0.886171348977.issue13578@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13578> _______________________________________ From report at bugs.python.org Tue Jun 12 14:00:33 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Jun 2012 12:00:33 +0000 Subject: [issue14803] Add feature to allow code execution prior to __main__ invocation In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1339502433.56.0.889025316713.issue14803@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14803> _______________________________________ From report at bugs.python.org Tue Jun 12 14:02:59 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Jun 2012 12:02:59 +0000 Subject: [issue13783] Clean up PEP 380 C API additions In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za> Message-ID: <1339502579.13.0.403905604194.issue13783@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- assignee: docs at python -> ncoghlan priority: normal -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13783> _______________________________________ From report at bugs.python.org Tue Jun 12 14:05:35 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Jun 2012 12:05:35 +0000 Subject: [issue13062] Introspection generator and function closure state In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za> Message-ID: <1339502735.86.0.624339459726.issue13062@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- assignee: -> ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13062> _______________________________________ From report at bugs.python.org Tue Jun 12 14:56:11 2012 From: report at bugs.python.org (Paul Moore) Date: Tue, 12 Jun 2012 12:56:11 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1339505771.06.0.282582733593.issue15038@psf.upfronthosting.co.za> Paul Moore <p.f.moore at gmail.com> added the comment: Applies and builds cleanly on Win7 32-bit. The speed difference is visible here too: PS D:\Data\cpython\PCbuild> .\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l.release()" 1000000 loops, best of 3: 0.608 usec per loop PS D:\Data\cpython\PCbuild> hg revert --all reverting pythoncore.vcxproj reverting pythoncore.vcxproj.filters reverting ..\Python\ceval_gil.h forgetting ..\Python\condvar.h reverting ..\Python\thread_nt.h PS D:\Data\cpython\PCbuild> .\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l.release()" 1000000 loops, best of 3: 1.66 usec per loop The test suite had a few Python crashes, but a build of trunk did too. No time to diagnose these now, but I didn't see any failures that weren't also in the unpatched build. Basically, test suite results look the same as for the unpatched build. ---------- nosy: +pmoore _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 12 15:15:57 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 12 Jun 2012 13:15:57 +0000 Subject: [issue12982] .pyo file can't be imported unless -O is given In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339506957.81.0.336240976747.issue12982@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Michael, I don?t think your proposed change would be considered favorably: importing .pyc or .pyo is well defined for CPython and the -O switch is really required for .pyo. However you may be able to import them anyway without any change to Python if you write a custom importer (more info in PEP 302 and the import docs) which reuses the low-level imp module to find and load .pyo files. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 15:16:46 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 12 Jun 2012 13:16:46 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339507006.5.0.716215574692.issue12982@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- title: .pyo file can't be imported unless -O is given -> Document that importing .pyo files needs python -O _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 15:25:00 2012 From: report at bugs.python.org (Meador Inge) Date: Tue, 12 Jun 2012 13:25:00 +0000 Subject: [issue13062] Introspection generator and function closure state In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za> Message-ID: <1339507500.37.0.248873328699.issue13062@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: I didn't get around to updating my patch with Nick's comments yet. Nick, the v3 patch I have attached still applies. I am happy to update it per your comments (promptly this time) or you can take it over. Whichever. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13062> _______________________________________ From report at bugs.python.org Tue Jun 12 15:25:50 2012 From: report at bugs.python.org (Michael Herrmann) Date: Tue, 12 Jun 2012 13:25:50 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339507550.31.0.900829147792.issue12982@psf.upfronthosting.co.za> Michael Herrmann <mherrmann.at at gmail.com> added the comment: Hi Eric, thank you for your quick reply. I'm not the first one who encounters this problem and in my opinion it is simply counter-intuitive that you cannot read a mixture of .pyo and .pyc files. That is why I think that my proposed change is valuable. In the meantime, I will follow your suggestion and try to use the imp-module to load the .pyo-files myself. Thank you! Best regards, Michael ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 15:26:10 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jun 2012 13:26:10 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339507570.11.0.0160915347923.issue12982@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Actually it's a lot easier than that, although it is very much a hack: just rename the .pyo files to .pyc, and python without -O will happily import them. Since the optimization happens when the bytecode is written, this does what you want. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 15:28:37 2012 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Tue, 12 Jun 2012 13:28:37 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1339507550.31.0.900829147792.issue12982@psf.upfronthosting.co.za> Message-ID: <B45075F8-1B00-456F-A4CA-E72876CE167D@normalesup.org> Eric O. LEBIGOT <eric.lebigot at normalesup.org> added the comment: Hi Michael, Thank you for your message. You are mentioning the suggestion of "the other Eric" (Araujo). My suggestion was to rename your .pyo files as .pyc files; it is hackish (according to a previous post from Eric Araujo), but might save you some trouble, on the short term, as .pyc do not need -O. Best wishes, EOL On Jun 12, 2012, at 21:25, Michael Herrmann wrote: > > Michael Herrmann <mherrmann.at at gmail.com> added the comment: > > Hi Eric, > > thank you for your quick reply. I'm not the first one who encounters this problem and in my opinion it is simply counter-intuitive that you cannot read a mixture of .pyo and .pyc files. That is why I think that my proposed change is valuable. In the meantime, I will follow your suggestion and try to use the imp-module to load the .pyo-files myself. Thank you! > > Best regards, > Michael > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue12982> > _______________________________________ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 15:31:53 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 12 Jun 2012 13:31:53 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1339507913.16.0.194469927155.issue15003@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: >> Is this documented in whatsnew? > I'm not sure what has been (none of my patches have done so). Okay; if a committer does not add a note we can open a doc bug to not forget that. >> Also, I remember a discussion about making it public or not, but >> don?t recall a decision. > Amaury brought it up in msg162127. His point was that the type is public in Python, so why not the C API? Actually I was talking about making it public at all, i.e. in Python too. > The use cases are different for the different types. StructSequence/namedtuple provides fixed data structures > for structured records. A dict is essentially the opposite: an un-fixed data structure for dynamic namespaces, > making no firm promises as to what the future holds. Right; I just don?t see why the clock info needs to be a dict instead of a structseq or simplenamespace, but maybe it?s explained in the PEP and I missed it. Also it seems to me that the only advantage of simplenamespace over structseqs is that it has no order and can?t be unpacked; I don?t find that a very strong argument (I do see its value, e.g. ?major, minor, *etc = sys.version_info? makes sense but we really don?t want to assign order to sys.implementation elements), but I guess this ship has sailed when the implementation was approved. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Tue Jun 12 15:39:32 2012 From: report at bugs.python.org (Michael Herrmann) Date: Tue, 12 Jun 2012 13:39:32 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339508372.59.0.252523688505.issue12982@psf.upfronthosting.co.za> Michael Herrmann <mherrmann.at at gmail.com> added the comment: Dear Eric OL, I see - I had read your e-mail but because of the similar names I thought the message here was yours too, and thus only replied once. I apologize! I can of course find a workaround such as renaming .pyo to .pyc. However, I would like to avoid having to modify the distribution of the third party library I am using in any way. The reason is that if a new version of this third party library is released and I have to upgrade to this new version, I will again have to manually do all the changes I had to do for the old version for the new version, and of course some changes won't work any more and there will be problems... I'm finding it tedious to use the imp-module to read in the .pyo-files by hand and might just fall back to your suggestion. Thank you for it. Nevertheless, I am still hoping that this may be resolved in a future release. Best, Michael ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 16:25:43 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Jun 2012 14:25:43 +0000 Subject: [issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za> Message-ID: <1339511143.21.0.0567750354662.issue13475@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: any chance on this for 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13475> _______________________________________ From report at bugs.python.org Tue Jun 12 16:46:25 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 12 Jun 2012 14:46:25 +0000 Subject: [issue15049] line buffering isn't always In-Reply-To: <1339463724.73.0.621165878269.issue15049@psf.upfronthosting.co.za> Message-ID: <1339512385.05.0.863153824483.issue15049@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Without looking at the code, it seems that http://docs.python.org/release/3.1.5/library/io.html?highlight=io#io.TextIOWrapper gives the answer "If line_buffering is True, flush() is implied when a call to write contains a newline character." So, "line buffering" may have a meaning only for writing. I don't think there is a reasonable way to implement it for reading. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15049> _______________________________________ From report at bugs.python.org Tue Jun 12 16:56:13 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 12 Jun 2012 14:56:13 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1339512973.69.0.550331042834.issue14599@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: It's not a problem, Stefan. I just happened to have already added the importlib.invalidate_caches() call to test_reprlib so I know that isn't the issue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14599> _______________________________________ From report at bugs.python.org Tue Jun 12 16:58:05 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 12 Jun 2012 14:58:05 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1339513085.57.0.549071536966.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: I've tested Ubuntu 64 myself using a Virtualbox, confirming that the pythread functionality is untouched. (funny how those vi keystrokes seem to be embedded into your amygdala after decades of disuse) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 12 17:00:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Tue, 12 Jun 2012 15:00:38 +0000 Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent() In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za> Message-ID: <1339513238.81.0.616299528945.issue13857@psf.upfronthosting.co.za> Chris Jerdonek <chris.jerdonek at gmail.com> added the comment: Great. Looks good! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13857> _______________________________________ From report at bugs.python.org Tue Jun 12 17:13:33 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Jun 2012 15:13:33 +0000 Subject: [issue15049] line buffering isn't always In-Reply-To: <1339463724.73.0.621165878269.issue15049@psf.upfronthosting.co.za> Message-ID: <1339514013.77.0.752330357718.issue15049@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: That makes sense. I'll add a mention of this to the 'open' docs that discuss the buffering parameter. ---------- assignee: -> r.david.murray components: +Documentation _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15049> _______________________________________ From report at bugs.python.org Tue Jun 12 17:40:08 2012 From: report at bugs.python.org (Virgil Dupras) Date: Tue, 12 Jun 2012 15:40:08 +0000 Subject: [issue15051] Can't compile Python 3.3a4 on OS X Message-ID: <1339515608.84.0.525003412108.issue15051@psf.upfronthosting.co.za> New submission from Virgil Dupras <hsoft at hardcoded.net>: I try to compile Pyhton 3.3a4 on a OS X 10.7 with XCode 4.3.3 and it fails. I tried a few configuration options, but even with a basic "./configure && make", I get this: ./python.exe -SE -m sysconfig --generate-posix-vars Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] python.exe(11771) malloc: *** mmap(size=7310873954244194304) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Could not import runpy module make: *** [Lib/_sysconfigdata.py] Segmentation fault: 11 I tried setting PYTHONHOME to `pwd`, to no avail. Am I doing something wrong? The same thing happens with v3.3a3. If I go back to v3.2.3, it compiles fine on the same system. I also tried on the repo's tip, same error. ---------- components: Build messages: 162683 nosy: vdupras priority: normal severity: normal status: open title: Can't compile Python 3.3a4 on OS X type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15051> _______________________________________ From report at bugs.python.org Tue Jun 12 17:45:30 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 12 Jun 2012 15:45:30 +0000 Subject: [issue15051] Can't compile Python 3.3a4 on OS X In-Reply-To: <1339515608.84.0.525003412108.issue15051@psf.upfronthosting.co.za> Message-ID: <1339515930.05.0.0304568054747.issue15051@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: There is a bug in the version of GCC that's shipped with Xcode. Try building using clang: configure ... CC=clang CXX=clang++ ---------- nosy: +ronaldoussoren _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15051> _______________________________________ From report at bugs.python.org Tue Jun 12 17:48:16 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 12 Jun 2012 15:48:16 +0000 Subject: [issue15051] Can't compile Python 3.3a4 on OS X In-Reply-To: <1339515608.84.0.525003412108.issue15051@psf.upfronthosting.co.za> Message-ID: <1339516096.54.0.270138715918.issue15051@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: This is a duplicate of #13241 We (and in particular Ned Deily are working on a change to the build process that would fix this, and will make it possible to build extensions on OSX regardless of which Xcode variant you use and which variant was used to build the python binaries. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15051> _______________________________________ From report at bugs.python.org Tue Jun 12 18:17:26 2012 From: report at bugs.python.org (James Kyle) Date: Tue, 12 Jun 2012 16:17:26 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339517846.72.0.428057551171.issue15048@psf.upfronthosting.co.za> James Kyle <bugs at jameskyle.org> added the comment: I think Ned does have some good points regarding the minimal impact a reversion would have. The most poignant point is that /Library/ on OS X is not a user controlled directory whereas ~/.local is. If ~/.local exists and has packages installed, it's because the user has made a conscious choice. If they regret that choice, they can remove ~/.local. Every package installed in ~/.local is the result of direct action by the user impacted. The same cannot be said for /Library. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Tue Jun 12 19:17:05 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 12 Jun 2012 17:17:05 +0000 Subject: [issue15052] Outdated comments in build_ssl.py Message-ID: <1339521425.84.0.884791308596.issue15052@psf.upfronthosting.co.za> New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>: The comment regarding a Perl installation not being required is no longer true with regards to OpenSSL 1.0+ (at least 1.0.0j and 1.0.1c). A Perl script(s) is used to generate source files within the generated Makefiles. I would suggest to remove the outdated and misleading comment. ---------- components: Build messages: 162687 nosy: jkloth priority: normal severity: normal status: open title: Outdated comments in build_ssl.py versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Tue Jun 12 20:19:02 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Tue, 12 Jun 2012 18:19:02 +0000 Subject: [issue15044] _dbm not building on Fedora 17 In-Reply-To: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za> Message-ID: <1339525142.88.0.366741351395.issue15044@psf.upfronthosting.co.za> Ross Lagerwall <rosslagerwall at gmail.com> added the comment: The gdbm provided with Fedora 17 provides /usr/include/ndbm.h. This makes setup.py think that it should try link with -lndbm when it actually requires -lgdbm_compat. A workaround is to specify --with-dbmliborder=gdbm to force gdbm to be used. I'll try and make a patch for this. ---------- nosy: +rosslagerwall _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15044> _______________________________________ From report at bugs.python.org Tue Jun 12 20:21:15 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 12 Jun 2012 18:21:15 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339525275.33.0.69913784865.issue12982@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Michael, you should ask the closed source library distributor to distribute all files as .pyc so you have access to docstrings while programming and to avoid the problem with reading them. He could also distribute an all-.pyo version. A mixture seems accidental. Is the import restriction currently intended? If a change *is* made, should it be regarded as an enhancement rather than a bug fix? I asked both question on pydev for more input. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 20:41:36 2012 From: report at bugs.python.org (Jakub Wilk) Date: Tue, 12 Jun 2012 18:41:36 +0000 Subject: [issue14102] argparse: add ability to create a man page In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za> Message-ID: <1339526496.68.0.0739152711044.issue14102@psf.upfronthosting.co.za> Changes by Jakub Wilk <jwilk at jwilk.net>: ---------- nosy: +jwilk _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14102> _______________________________________ From report at bugs.python.org Tue Jun 12 20:48:07 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 12 Jun 2012 18:48:07 +0000 Subject: [issue1644818] Allow built-in packages and submodules as well as top-level modules Message-ID: <1339526887.08.0.700759504561.issue1644818@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1644818> _______________________________________ From report at bugs.python.org Tue Jun 12 21:05:10 2012 From: report at bugs.python.org (Ronan Lamy) Date: Tue, 12 Jun 2012 19:05:10 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339527910.61.0.737165395803.issue12982@psf.upfronthosting.co.za> Changes by Ronan Lamy <ronan.lamy at gmail.com>: ---------- nosy: +Ronan.Lamy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 12 21:33:53 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 12 Jun 2012 19:33:53 +0000 Subject: [issue12510] IDLE: calltips mishandle raw strings and other examples In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za> Message-ID: <1339529633.72.0.550297031964.issue12510@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: The _self_pat RE needs to be changed to just remove the first argument. Presently, another bug exists with the current implementation: >>> class A: def t(self, self1, self2): pass >>> a = A() >>> a.t( gives "(1,2)" as the calltip, instead of "(self1, self2)" for 3.x. Python 2.7 gives the correct calltip. The attached patch modifies _self_pat to remove only the first argument, modifies the classmethod test, and adds a test for "notself", as Terry requested in msg162511. ---------- Added file: http://bugs.python.org/file25942/issue12510_self_pat.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12510> _______________________________________ From report at bugs.python.org Tue Jun 12 21:33:54 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Tue, 12 Jun 2012 19:33:54 +0000 Subject: [issue15044] _dbm not building on Fedora 17 In-Reply-To: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za> Message-ID: <1339529634.59.0.520266322578.issue15044@psf.upfronthosting.co.za> Ross Lagerwall <rosslagerwall at gmail.com> added the comment: Attached is a patch which fixes the issue on Fedora 17. If this doesn't break other OSes I'll commit it for 2.7, 3.2 and 3.3. ---------- keywords: +patch versions: +Python 2.7, Python 3.2 Added file: http://bugs.python.org/file25943/gdbm.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15044> _______________________________________ From report at bugs.python.org Tue Jun 12 21:48:17 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 12 Jun 2012 19:48:17 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1339530497.08.0.127165398195.issue14937@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: There's a small logic bug with Martin's patch. Opening up a new editor window and pressing Tab causes a traceback. Attached is a new patch to fix the problem. ---------- priority: normal -> high resolution: fixed -> stage: -> patch review status: closed -> open Added file: http://bugs.python.org/file25944/issue14937_logic_fix.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14937> _______________________________________ From report at bugs.python.org Tue Jun 12 22:10:51 2012 From: report at bugs.python.org (Abhishek Singh) Date: Tue, 12 Jun 2012 20:10:51 +0000 Subject: [issue15021] xmlrpc server hangs In-Reply-To: <1339027271.75.0.304876559161.issue15021@psf.upfronthosting.co.za> Message-ID: <1339531851.71.0.502145536961.issue15021@psf.upfronthosting.co.za> Abhishek Singh <abhishekrsingh at gmail.com> added the comment: I found my problem. I was also using pipes to implement my show output (between python and C). The pipe was getting full, and xmlrpc server was locking up because of that. The gdb traceback was confusing though (will re-open if I see this again, and if it is indeed a different issue). ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15021> _______________________________________ From report at bugs.python.org Tue Jun 12 22:20:46 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 12 Jun 2012 20:20:46 +0000 Subject: [issue15053] imp.lock_held() "Changed in Python 3.3" mention accidentally one function up Message-ID: <1339532446.32.0.0402768881162.issue15053@psf.upfronthosting.co.za> New submission from Brett Cannon <brett at python.org>: If you look at http://docs.python.org/dev/py3k/library/imp.html#imp.get_tag you will notice it has the "Changed in Python 3.3" notice for imp.lock_held() in it, the function *below* imp.get_tag(). ---------- assignee: docs at python components: Documentation messages: 162694 nosy: brett.cannon, docs at python, pitrou priority: normal severity: normal stage: needs patch status: open title: imp.lock_held() "Changed in Python 3.3" mention accidentally one function up versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15053> _______________________________________ From report at bugs.python.org Tue Jun 12 22:45:01 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 12 Jun 2012 20:45:01 +0000 Subject: [issue14963] Use an iterative implementation for contextlib.ExitStack.__exit__ In-Reply-To: <1338376067.22.0.0825835075506.issue14963@psf.upfronthosting.co.za> Message-ID: <1339533901.58.0.876381999686.issue14963@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14963> _______________________________________ From report at bugs.python.org Wed Jun 13 00:05:34 2012 From: report at bugs.python.org (Chris Withers) Date: Tue, 12 Jun 2012 22:05:34 +0000 Subject: [issue4442] document immutable type subclassing via __new__ In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za> Message-ID: <1339538734.02.0.736323552313.issue4442@psf.upfronthosting.co.za> Chris Withers <chris at simplistix.co.uk> added the comment: It's the fact that for immutable types, initialization is done in __new__ instead of __init__ that isn't documented anywhere. This should be Python-level rather than C-level documentation. The example I gave in #msg76473 is confusing without docs anywhere that explain why this is. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4442> _______________________________________ From report at bugs.python.org Wed Jun 13 02:26:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Jun 2012 00:26:46 +0000 Subject: [issue15053] imp.lock_held() "Changed in Python 3.3" mention accidentally one function up In-Reply-To: <1339532446.32.0.0402768881162.issue15053@psf.upfronthosting.co.za> Message-ID: <1339547206.9.0.143228160052.issue15053@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Well, if the versionchanged were for get_tag(), it would be indented appropriately. But it is actually for the "The following functions help interact with the import system?s internal locking mechanism" paragraph. Feel free to improve :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15053> _______________________________________ From report at bugs.python.org Wed Jun 13 02:27:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Jun 2012 00:27:13 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <1339521425.84.0.884791308596.issue15052@psf.upfronthosting.co.za> Message-ID: <1339547233.19.0.0771203927619.issue15052@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +gregory.p.smith, loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Wed Jun 13 02:32:26 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jun 2012 00:32:26 +0000 Subject: [issue4442] document immutable type subclassing via __new__ In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za> Message-ID: <1339547546.7.0.648576389917.issue4442@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Actually, it is documented: http://docs.python.org/dev/reference/datamodel.html#basic-customization "__new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation." It could certainly be better documented, but where? The tutorial? ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4442> _______________________________________ From report at bugs.python.org Wed Jun 13 02:52:25 2012 From: report at bugs.python.org (Grey_Shao) Date: Wed, 13 Jun 2012 00:52:25 +0000 Subject: [issue15050] Python 3.2.3 fail to make In-Reply-To: <1339488103.99.0.17701742584.issue15050@psf.upfronthosting.co.za> Message-ID: <1339548745.92.0.434450183846.issue15050@psf.upfronthosting.co.za> Grey_Shao <shojnhv at 163.com> added the comment: Thanks for your kindly help I attach the config.log in the attachment "data.7z" The value of the PRId64 is: #ifdef _LP64 #define PRId64 "ld" #else /* _ILP32 */ #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG) #define PRId64 "lld" #endif #endif I also attach the related inttypes.h files in the attachment "data.7z" Thanks for your help ---------- Added file: http://bugs.python.org/file25945/Data.7z _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15050> _______________________________________ From report at bugs.python.org Wed Jun 13 04:42:26 2012 From: report at bugs.python.org (Ariel Poliak) Date: Wed, 13 Jun 2012 02:42:26 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1339555346.49.0.602311456813.issue14377@psf.upfronthosting.co.za> Ariel Poliak <apoliak at gmail.com> added the comment: Made a new patch. This one contains changes for xml.etree.ElementTree for cpython, jython, and stackless. It also contains changes to Modules/_elementtree.c for cpython and stackless. The changes within this patch do not change the signature for the _serialize_* methods, so it can be used with any third-party library that extends ElementTree. ---------- Added file: http://bugs.python.org/file25946/ElementTree-force_long_tags-v3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14377> _______________________________________ From report at bugs.python.org Wed Jun 13 04:50:40 2012 From: report at bugs.python.org (Nam Nguyen) Date: Wed, 13 Jun 2012 02:50:40 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1339555840.01.0.31064958268.issue14119@psf.upfronthosting.co.za> Nam Nguyen <bitsink at gmail.com> added the comment: +1 That was actually what I did. I replaced the internal queue with another one whose limit was properly set. If you are busy to write one, let me find some time to create another patch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14119> _______________________________________ From report at bugs.python.org Wed Jun 13 10:31:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Jun 2012 08:31:57 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1339576317.05.0.871773930489.issue15038@psf.upfronthosting.co.za> Changes by STINNER Victor <victor.stinner at gmail.com>: ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Wed Jun 13 11:37:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Jun 2012 09:37:50 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339077374.41.0.500256039615.issue15026@psf.upfronthosting.co.za> Message-ID: <1339580270.04.0.117108723999.issue15026@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Here are results under 64-bit Linux on a Core i5-2500K: 3.3 patched 3327 (+360%) 15304 encode utf-16le 'A'*10000 3314 (+335%) 14413 encode utf-16le '\x80'*10000 3315 (+578%) 22472 encode utf-16le '\x80'+'A'*9999 2390 (+668%) 18345 encode utf-16le '\u0100'*10000 2390 (+668%) 18364 encode utf-16le '\u0100'+'A'*9999 2324 (+684%) 18219 encode utf-16le '\u0100'+'\x80'*9999 2385 (+664%) 18227 encode utf-16le '\u8000'*10000 2390 (+669%) 18383 encode utf-16le '\u8000'+'A'*9999 2390 (+663%) 18232 encode utf-16le '\u8000'+'\x80'*9999 2385 (+601%) 16708 encode utf-16le '\u8000'+'\u0100'*9999 1601 (-4%) 1542 encode utf-16le '\U00010000'*10000 1209 (+20%) 1448 encode utf-16le '\U00010000'+'A'*9999 1210 (+20%) 1447 encode utf-16le '\U00010000'+'\x80'*9999 1209 (+20%) 1446 encode utf-16le '\U00010000'+'\u0100'*9999 1209 (+20%) 1446 encode utf-16le '\U00010000'+'\u8000'*9999 3237 (+562%) 21422 encode utf-16be 'A'*10000 3294 (+500%) 19779 encode utf-16be '\x80'*10000 3290 (+357%) 15036 encode utf-16be '\x80'+'A'*9999 2382 (+209%) 7354 encode utf-16be '\u0100'*10000 2381 (+208%) 7342 encode utf-16be '\u0100'+'A'*9999 2377 (+209%) 7347 encode utf-16be '\u0100'+'\x80'*9999 2382 (+207%) 7317 encode utf-16be '\u8000'*10000 2381 (+208%) 7343 encode utf-16be '\u8000'+'A'*9999 2376 (+209%) 7343 encode utf-16be '\u8000'+'\x80'*9999 2377 (+206%) 7281 encode utf-16be '\u8000'+'\u0100'*9999 1598 (-42%) 930 encode utf-16be '\U00010000'*10000 1208 (+19%) 1436 encode utf-16be '\U00010000'+'A'*9999 1208 (+19%) 1436 encode utf-16be '\U00010000'+'\x80'*9999 1205 (+19%) 1434 encode utf-16be '\U00010000'+'\u0100'*9999 1205 (+19%) 1433 encode utf-16be '\U00010000'+'\u8000'*9999 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Wed Jun 13 11:38:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Jun 2012 09:38:48 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1339580328.11.0.586209148668.issue15038@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- superseder: Locks broken wrt timeouts on Windows -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Wed Jun 13 11:38:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Jun 2012 09:38:55 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1339580335.23.0.525392151491.issue15038@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- stage: -> patch review type: enhancement -> performance _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Wed Jun 13 11:44:27 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 13 Jun 2012 09:44:27 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1339580667.06.0.592392257123.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: While I'm confident about the correctness of this implementation (it?s in production use right now) I?d like comments on the architecture. - Are people comfortable with the notion of an include file with an inline implementation of portable condition variables like this? - Martin voiced concerns over having a _future_ compatible implementation in there with Windows 7 support only. I thought it cool to have around, since it strenghtens the "portability" design of the pattern. - Names of types/apis. Am I doing it right? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Wed Jun 13 14:12:20 2012 From: report at bugs.python.org (Mateusz Loskot) Date: Wed, 13 Jun 2012 12:12:20 +0000 Subject: [issue4442] document immutable type subclassing via __new__ In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za> Message-ID: <1339589540.26.0.352408130253.issue4442@psf.upfronthosting.co.za> Mateusz Loskot <mateusz at loskot.net> added the comment: Chris Withers' note clarifies it to me, that this should be Python-level rather than C-level documentation. Then the note under __new__() in 3. Data model seems right. Simply, I expected to have some notes in C API too Side note: as mainly Python C API user, I expected to have it documented at C API level too. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4442> _______________________________________ From report at bugs.python.org Wed Jun 13 14:17:55 2012 From: report at bugs.python.org (Chris Withers) Date: Wed, 13 Jun 2012 12:17:55 +0000 Subject: [issue4442] document immutable type subclassing via __new__ In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za> Message-ID: <1339589875.77.0.451228788691.issue4442@psf.upfronthosting.co.za> Chris Withers <chris at simplistix.co.uk> added the comment: Probably also wouldn't go amiss to put some notes near the docs for common immutable types that people might subclass: datetime, maybe tuple? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4442> _______________________________________ From report at bugs.python.org Wed Jun 13 14:47:54 2012 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 13 Jun 2012 12:47:54 +0000 Subject: [issue15054] bytes literals erroneously tokenized Message-ID: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> New submission from Florent Xicluna <florent.xicluna at gmail.com>: With Python 2.7, both b'hello' and br'hello' are wrong. With Python 3.3, b'hello' is wrong. $ python2.7 -m tokenize <<<"'hello', u'hello', ur'hello', b'hello', br'hello'" 1,0-1,7: STRING "'hello'" 1,7-1,8: OP ',' 1,9-1,17: STRING "u'hello'" 1,17-1,18: OP ',' 1,19-1,28: STRING "ur'hello'" 1,28-1,29: OP ',' 1,30-1,31: NAME 'b' 1,31-1,38: STRING "'hello'" 1,38-1,39: OP ',' 1,40-1,42: NAME 'br' 1,42-1,49: STRING "'hello'" 1,49-1,50: NEWLINE '\n' 2,0-2,0: ENDMARKER '' $ python3.3 -m tokenize <<<"'hello', u'hello', ur'hello', b'hello', br'hello', rb'hello'" 1,0-1,7: STRING "'hello'" 1,7-1,8: OP ',' 1,9-1,17: STRING "u'hello'" 1,17-1,18: OP ',' 1,19-1,28: STRING "ur'hello'" 1,28-1,29: OP ',' 1,30-1,31: NAME 'b' 1,31-1,38: STRING "'hello'" 1,38-1,39: OP ',' 1,40-1,49: STRING "br'hello'" 1,49-1,50: OP ',' 1,51-1,60: STRING "rb'hello'" 1,60-1,61: NEWLINE '\n' 2,0-2,0: ENDMARKER '' ---------- components: Library (Lib) messages: 162705 nosy: flox priority: normal severity: normal status: open title: bytes literals erroneously tokenized type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Wed Jun 13 14:54:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Jun 2012 12:54:19 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339592059.44.0.329280687578.issue15054@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +benjamin.peterson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Wed Jun 13 14:56:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Jun 2012 12:56:28 +0000 Subject: [issue15049] line buffering isn't always In-Reply-To: <1339463724.73.0.621165878269.issue15049@psf.upfronthosting.co.za> Message-ID: <1339592188.66.0.816542800935.issue15049@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Indeed, line buffering on the read size would very slow (since you would have to read and decode one byte at a time from the raw stream to make sure you don't overshoot the line boundaries). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15049> _______________________________________ From report at bugs.python.org Wed Jun 13 15:40:17 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jun 2012 13:40:17 +0000 Subject: [issue13062] Introspection generator and function closure state In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za> Message-ID: <1339594817.93.0.81147756638.issue13062@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Meador: I probably won't get to this until the weekend, so go ahead and update the patch if you have time. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13062> _______________________________________ From report at bugs.python.org Wed Jun 13 15:49:17 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 Jun 2012 13:49:17 +0000 Subject: [issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za> Message-ID: <1339595357.35.0.359257845134.issue13475@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I was tempted to just add this (perhaps as a -X option) but, on reflection, I'm going to go with "No, not for 3.3". I want to take a long hard look at the whole sys.path[0] initialisation process when I update PEP 395 to account for namespace packages, and it doesn't make sense to skip ahead with part of the conclusion. (I may even end up splitting that PEP into two pieces) I'll also look into the embedding API, to see if/how embedding applications can fully control sys.path initialisation. Python has survived without this feature for the last couple of decades, there's no need to be hasty in adding it now. ---------- assignee: -> ncoghlan versions: +Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13475> _______________________________________ From report at bugs.python.org Wed Jun 13 16:51:06 2012 From: report at bugs.python.org (Joshua Cogliati) Date: Wed, 13 Jun 2012 14:51:06 +0000 Subject: [issue15020] default value for progname in pythonrun.c should be python3 for Python 3 In-Reply-To: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za> Message-ID: <1339599066.79.0.89187629113.issue15020@psf.upfronthosting.co.za> Changes by Joshua Cogliati <jrincayc at gmail.com>: ---------- title: Poor default value for progname in pythonrun.c -> default value for progname in pythonrun.c should be python3 for Python 3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15020> _______________________________________ From report at bugs.python.org Wed Jun 13 17:34:14 2012 From: report at bugs.python.org (Mark Shannon) Date: Wed, 13 Jun 2012 15:34:14 +0000 Subject: [issue15055] dictnotes.txt is out of date Message-ID: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za> New submission from Mark Shannon <mark at hotpy.org>: dictnotes.txt is out of date w.r.t. dictobject.c Remove notes from dictnotes.txt that duplicate comments in dictobject.c and ensure comments in dictobject.c cover all aspects of tunable parameters. Patch attached. ---------- assignee: docs at python components: Documentation files: dictnotes.patch keywords: patch messages: 162709 nosy: Mark.Shannon, docs at python priority: normal severity: normal status: open title: dictnotes.txt is out of date type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25947/dictnotes.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15055> _______________________________________ From report at bugs.python.org Wed Jun 13 18:00:08 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Jun 2012 16:00:08 +0000 Subject: [issue15055] dictnotes.txt is out of date In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za> Message-ID: <1339603208.11.0.598519710375.issue15055@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15055> _______________________________________ From report at bugs.python.org Wed Jun 13 18:12:39 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 Jun 2012 16:12:39 +0000 Subject: [issue15055] dictnotes.txt is out of date In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za> Message-ID: <1339603959.14.0.944500875479.issue15055@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: Mark, where was it approved that you could change all the tunable parameters? I remembered that the split dict was approved but not changing all of the tuneables (at one point, I had spent a month validating that the tuneables were correct across a wide variety of applications). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15055> _______________________________________ From report at bugs.python.org Wed Jun 13 18:32:42 2012 From: report at bugs.python.org (Mark Shannon) Date: Wed, 13 Jun 2012 16:32:42 +0000 Subject: [issue15055] dictnotes.txt is out of date In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za> Message-ID: <1339605162.66.0.338638065931.issue15055@psf.upfronthosting.co.za> Mark Shannon <mark at hotpy.org> added the comment: Raymond, I don't think this is the place to discuss the changes to the tunables in dictobject.c. This patch merely ensures that dictnotes.txt and the comments in dictobject.c are in agreement. It doesn't change any code (apart from creating the GROWTH_RATE macro for clarity). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15055> _______________________________________ From report at bugs.python.org Wed Jun 13 19:10:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 13 Jun 2012 17:10:52 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available Message-ID: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> New submission from Brett Cannon <brett at python.org>: Both imp.cache_from_source() and source_from_cache() should throw NotImplementedError when sys.implementation.cache_tag is None. See the thread starting at http://mail.python.org/pipermail/python-dev/2012-June/120145.html for discussion of this decision. ---------- components: Library (Lib) keywords: easy messages: 162712 nosy: brett.cannon priority: deferred blocker severity: normal status: open title: Have imp.cache_from_source() raise NotImplementedError when cache tag not available versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Wed Jun 13 19:10:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 13 Jun 2012 17:10:57 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1339607457.53.0.315761854519.issue15056@psf.upfronthosting.co.za> Changes by Brett Cannon <brett at python.org>: ---------- stage: -> test needed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Wed Jun 13 19:26:24 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 13 Jun 2012 17:26:24 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1339608384.13.0.37126189563.issue15056@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: It seems to me there is overlap between sys.implementation.cache_tag and sys.dont_write_bytecode. I was expecting sys.impl.cache_tag to be purely informational, and not actually controlling some behavior. ?If cache_tag is set to None, it indicates that module caching should be disabled?: isn?t that the job of sys.dont_write_bytecode? (The difference that I see is that sys.impl.cache_tag is defined by the VM and dont_write_bytecode by each interpreter invocation; I was expecting VMs that never want to write bytecode to just always set dont_write_bytecode to False, i.e. make -B redundant.) ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Wed Jun 13 19:33:27 2012 From: report at bugs.python.org (Mark Shannon) Date: Wed, 13 Jun 2012 17:33:27 +0000 Subject: [issue13783] Clean up PEP 380 C API additions In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za> Message-ID: <1339608807.91.0.077927106188.issue13783@psf.upfronthosting.co.za> Mark Shannon <mark at hotpy.org> added the comment: There is one call to PyGen_FetchStopIterationValue in ceval.c. But I don't think it should be public. There is no real reason for the "Gen" in the name. The function is used by generator handling code, but the code itself relates to StopIteration. Perhaps it should be moved to errors.c and renamed _PyErr_FetchStopIterationValue. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13783> _______________________________________ From report at bugs.python.org Wed Jun 13 19:35:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 13 Jun 2012 17:35:32 +0000 Subject: [issue15050] Python 3.2.3 fail to make In-Reply-To: <1339488103.99.0.17701742584.issue15050@psf.upfronthosting.co.za> Message-ID: <1339608932.47.0.211131107574.issue15050@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: This is a misconfiguration of your system. Take a look at line 29538 of config.log. It says configure:13701: ./conftest ld.so.1: ./conftest: ??????: libintl.so.8: ????????: ?????????????? ./configure: line -1756: 8400 Killed ./conftest$ac_exeext configure:13701: $? = 137 configure: program exited with status 137 configure: failed program was: | /* confdefs.h */ | #define _GNU_SOURCE 1 ... So it didn't actually run the test, but immediately failed because libintl.so.8 is broken (or something involving libintl.so.8). The surprising part is that this starts with the test for PTHREAD_SCOPE_SYSTEM. I cannot provide an explanation for that - you will have to research the source of the problem yourself. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15050> _______________________________________ From report at bugs.python.org Wed Jun 13 19:41:05 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 13 Jun 2012 17:41:05 +0000 Subject: [issue13841] multiprocessing should use sys.exit() where possible In-Reply-To: <1327345132.43.0.775594933755.issue13841@psf.upfronthosting.co.za> Message-ID: <1339609265.26.0.288171038033.issue13841@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: The trivial patch of replacing exit() by sys.exit() caused manager processes to be terminated after a short timeout. (It is inconvenient that in Python there is no way for a non-main thread to request immediate shutdown of the process.) This new patch makes the manager process shutdown cleanly. ---------- Added file: http://bugs.python.org/file25948/sys_exit.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13841> _______________________________________ From report at bugs.python.org Wed Jun 13 19:42:39 2012 From: report at bugs.python.org (Ken Cheung) Date: Wed, 13 Jun 2012 17:42:39 +0000 Subject: [issue15057] Potential Bugs in mpd_qdivint and mpd_qrem Message-ID: <1339609359.6.0.237192650193.issue15057@psf.upfronthosting.co.za> New submission from Ken Cheung <msrbugzilla at gmail.com>: I observed a code clone from the following files. function : mpd_qdivint @ (file: "Python-3.3.0a2/Modules/_decimal/libmpdec/mpdecimal.c", line: 3727)~3763 function : mpd_qrem @ (file: "Python-3.3.0a2/Modules/_decimal/libmpdec/mpdecimal.c", line: 6331)~6361 The function mpd_qdivint checks the condition "mpd_isinfinite(a) && mpd_isinfinite(b)" while mpd_qrem does not. I wonder if this is necessary in mpd_qrem. The source code is included in the attachment. Hope it helps. ---------- components: Library (Lib) files: mpdecimal_clone.txt messages: 162717 nosy: Ken.Cheung priority: normal severity: normal status: open title: Potential Bugs in mpd_qdivint and mpd_qrem type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25949/mpdecimal_clone.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15057> _______________________________________ From report at bugs.python.org Wed Jun 13 19:42:55 2012 From: report at bugs.python.org (Ken Cheung) Date: Wed, 13 Jun 2012 17:42:55 +0000 Subject: [issue15057] Potential Bug in mpd_qdivint and mpd_qrem In-Reply-To: <1339609359.6.0.237192650193.issue15057@psf.upfronthosting.co.za> Message-ID: <1339609375.73.0.0313094567763.issue15057@psf.upfronthosting.co.za> Changes by Ken Cheung <msrbugzilla at gmail.com>: ---------- title: Potential Bugs in mpd_qdivint and mpd_qrem -> Potential Bug in mpd_qdivint and mpd_qrem _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15057> _______________________________________ From report at bugs.python.org Wed Jun 13 19:46:47 2012 From: report at bugs.python.org (Ken Cheung) Date: Wed, 13 Jun 2012 17:46:47 +0000 Subject: [issue15058] Potential Bugs in dlpvalloc and dlvalloc Message-ID: <1339609607.12.0.430213667453.issue15058@psf.upfronthosting.co.za> New submission from Ken Cheung <msrbugzilla at gmail.com>: I observed a code clone from the following files. function : dlpvalloc @ (file: "Python-3.3.0a2/Modules/_ctypes/libffi/src/dlmalloc.c", line: 4360)~4362 function : dlvalloc @ (file: "Python-3.3.0a2/Modules/_ctypes/libffi/src/dlmalloc.c", line: 4353)~4355 The function dlpvalloc performs a bitwise operation at return while dlvalloc does not. I wonder if this is necessary in dlvalloc. The source code is included in the attachment. Hope it helps. ---------- components: Library (Lib) files: dlmalloc_clone.txt messages: 162718 nosy: Ken.Cheung priority: normal severity: normal status: open title: Potential Bugs in dlpvalloc and dlvalloc type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25950/dlmalloc_clone.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15058> _______________________________________ From report at bugs.python.org Wed Jun 13 19:47:13 2012 From: report at bugs.python.org (Ken Cheung) Date: Wed, 13 Jun 2012 17:47:13 +0000 Subject: [issue15058] Potential Bug in dlpvalloc and dlvalloc In-Reply-To: <1339609607.12.0.430213667453.issue15058@psf.upfronthosting.co.za> Message-ID: <1339609633.41.0.13838956707.issue15058@psf.upfronthosting.co.za> Changes by Ken Cheung <msrbugzilla at gmail.com>: ---------- title: Potential Bugs in dlpvalloc and dlvalloc -> Potential Bug in dlpvalloc and dlvalloc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15058> _______________________________________ From report at bugs.python.org Wed Jun 13 19:52:37 2012 From: report at bugs.python.org (Ken Cheung) Date: Wed, 13 Jun 2012 17:52:37 +0000 Subject: [issue15059] Potential Bug in mpd_qresize and mpd_qresize_zero Message-ID: <1339609957.89.0.517286245492.issue15059@psf.upfronthosting.co.za> New submission from Ken Cheung <msrbugzilla at gmail.com>: I observed a code clone from the following files. function : mpd_qresize @ (file: "Python-3.3.0a2/Modules/_decimal/libmpdec/mpdecimal.c", line: 481)~493 function : mpd_qresize_zero @ (file: "Python-3.3.0a2/Modules/_decimal/libmpdec/mpdecimal.c", line: 501)~517 The two functions perform different in the else if condition. I wonder this is due to functionality requirement or a bug. The source code is included in the attachment. Hope it helps. ---------- components: Library (Lib) files: mpdecimal_clone 2.txt messages: 162719 nosy: Ken.Cheung priority: normal severity: normal status: open title: Potential Bug in mpd_qresize and mpd_qresize_zero type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25951/mpdecimal_clone 2.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15059> _______________________________________ From report at bugs.python.org Wed Jun 13 20:15:17 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 13 Jun 2012 18:15:17 +0000 Subject: [issue15057] Potential Bug in mpd_qdivint and mpd_qrem In-Reply-To: <1339609359.6.0.237192650193.issue15057@psf.upfronthosting.co.za> Message-ID: <1339611317.21.0.061671582258.issue15057@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: ---------- nosy: +skrah _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15057> _______________________________________ From report at bugs.python.org Wed Jun 13 20:20:34 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 13 Jun 2012 18:20:34 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1339611634.76.0.76879495281.issue15056@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: ---------- nosy: +eric.snow _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Wed Jun 13 20:28:01 2012 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 13 Jun 2012 18:28:01 +0000 Subject: [issue15060] docs: socket typo Message-ID: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za> New submission from anatoly techtonik <techtonik at gmail.com>: http://docs.python.org/library/socket.html s/integral/integer/ ---------- assignee: docs at python components: Documentation messages: 162720 nosy: docs at python, techtonik priority: normal severity: normal status: open title: docs: socket typo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15060> _______________________________________ From report at bugs.python.org Wed Jun 13 20:33:15 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jun 2012 18:33:15 +0000 Subject: [issue15058] Potential Bug in dlpvalloc and dlvalloc In-Reply-To: <1339609607.12.0.430213667453.issue15058@psf.upfronthosting.co.za> Message-ID: <1339612395.95.0.739242827721.issue15058@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +amaury.forgeotdarc, meador.inge _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15058> _______________________________________ From report at bugs.python.org Wed Jun 13 20:34:36 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jun 2012 18:34:36 +0000 Subject: [issue15059] Potential Bug in mpd_qresize and mpd_qresize_zero In-Reply-To: <1339609957.89.0.517286245492.issue15059@psf.upfronthosting.co.za> Message-ID: <1339612476.84.0.50185774862.issue15059@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +skrah _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15059> _______________________________________ From report at bugs.python.org Wed Jun 13 20:44:25 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 13 Jun 2012 18:44:25 +0000 Subject: [issue15058] Potential Bug in dlpvalloc and dlvalloc In-Reply-To: <1339609607.12.0.430213667453.issue15058@psf.upfronthosting.co.za> Message-ID: <1339613065.48.0.611611657934.issue15058@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Well, this bitwise operation is exactly why there are two functions: dlvpalloc rounds up to the nearest page size, and dlvalloc does not. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15058> _______________________________________ From report at bugs.python.org Wed Jun 13 20:51:10 2012 From: report at bugs.python.org (John Nagle) Date: Wed, 13 Jun 2012 18:51:10 +0000 Subject: [issue9679] unicode DNS names in urllib, urlopen In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za> Message-ID: <1339613470.79.0.893960540274.issue9679@psf.upfronthosting.co.za> John Nagle <nagle at users.sourceforge.net> added the comment: A "IRI library" is not needed to fix this problem. It's already fixed in the sockets library and the http library. We just need consistency in urllib2. urllib2 functions which take a "url" parameter should apply "encodings.idna.ToASCII" to each label of the domain name. urllib2 function which return a "url" value (such as "geturl()") should apply "encodings.idna.ToUnicode" to each label of the domain name. Note that in both cases, the conversion function must be applied to each label (field between "."s) of the domain name only. Applying it to the entire domain name or the entire URL will not work. If there are future changes to domain syntax, those should go into "encodings.idna", which is the proper library for domain syntax issues. ---------- nosy: +nagle _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9679> _______________________________________ From report at bugs.python.org Wed Jun 13 21:10:15 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jun 2012 19:10:15 +0000 Subject: [issue9679] unicode DNS names in urllib, urlopen In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za> Message-ID: <1339614615.53.0.91695125775.issue9679@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I doubt that unicode domain support in urllib would be of much use without full IRI support. I would think that a domain that uses unicode is highly likely to have URLs that use unicode. However that doesn't mean a patch along the lines you suggest would be rejected out of hand, especially if someone can provide a real web site where it would be helpful. ---------- versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9679> _______________________________________ From report at bugs.python.org Wed Jun 13 21:19:46 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 13 Jun 2012 19:19:46 +0000 Subject: [issue3955] maybe doctest doesn't understand unicode_literals? In-Reply-To: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za> Message-ID: <1339615186.59.0.348540380206.issue3955@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Yeah, I don't really remember now what my point was. ---------- status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3955> _______________________________________ From report at bugs.python.org Wed Jun 13 21:31:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 13 Jun 2012 19:31:38 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <1339521425.84.0.884791308596.issue15052@psf.upfronthosting.co.za> Message-ID: <1339615898.11.0.574078819362.issue15052@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: The comment is correct. The sources are not. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Wed Jun 13 21:52:41 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:52:41 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617161.65.0.251027346561.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25952/pec1.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:52:55 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:52:55 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617175.79.0.908431105343.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25953/pec2.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:53:05 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:53:05 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617185.71.0.827646516652.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25954/pec3.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:53:16 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:53:16 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617196.55.0.11483115447.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25955/pec4.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:53:28 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:53:28 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617208.38.0.323670302316.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25956/pec5.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:53:43 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:53:43 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617223.18.0.603136243787.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25957/pec6.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:53:54 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:53:54 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617234.13.0.118445033726.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25958/pec7.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:54:04 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:54:04 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617244.76.0.385122430058.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25959/pec8.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:54:14 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:54:14 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617254.76.0.657011642192.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25960/pec9.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:54:25 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:54:25 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617265.71.0.133374709072.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25961/pec10.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:54:36 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:54:36 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617276.83.0.437980639776.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25962/pec11.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:54:49 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:54:49 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617289.3.0.798906648355.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25963/pec12.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:55:04 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:55:04 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617304.28.0.403194912094.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25964/pec13.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:55:14 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:55:14 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617314.11.0.209373762264.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25965/pec14.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:55:32 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:55:32 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617332.21.0.00404277073068.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25966/pec15.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:55:41 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:55:41 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617341.65.0.144156390111.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25967/pec16.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:55:51 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:55:51 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617351.32.0.525872129313.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25968/pec17.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:55:59 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:55:59 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617359.98.0.0156438513841.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25969/pec18.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:56:09 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:56:09 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617369.58.0.622861793688.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25970/pec19.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:56:18 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:56:18 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617378.84.0.892583478523.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25971/pec20.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:56:29 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:56:29 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617389.21.0.00677500654843.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25972/pec21.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:56:39 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:56:39 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617399.41.0.185502223864.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25973/pec22.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:56:52 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:56:52 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617412.47.0.986225000201.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25974/pec23.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:57:03 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:57:03 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617423.61.0.93273899996.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25975/pec24.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:57:12 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:57:12 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617432.63.0.609600284758.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25976/pec25.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:57:22 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:57:22 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617442.24.0.837744182136.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25977/pec26.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:57:33 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:57:33 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617453.04.0.0334243988011.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25978/pec27.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:57:43 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:57:43 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617463.18.0.788416268908.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25979/pec28.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:57:52 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:57:52 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617472.26.0.924030640235.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25980/pec29.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:58:02 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:58:02 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617482.09.0.11557229975.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25981/pec30.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:58:12 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:58:12 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617492.04.0.161756942024.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25982/pec31.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:58:28 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:58:28 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617508.16.0.0291986267381.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25983/pec32.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:58:38 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:58:38 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617518.6.0.944231650813.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25984/pec33.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:58:38 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 13 Jun 2012 19:58:38 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1339617518.7.0.0942197427677.issue14674@psf.upfronthosting.co.za> Changes by Chris Rebert <pybugs at rebertia.com>: Removed file: http://bugs.python.org/file25594/json.rst.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14674> _______________________________________ From report at bugs.python.org Wed Jun 13 21:58:54 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:58:54 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617534.58.0.858650680002.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25985/pec34.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:59:09 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:59:09 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617549.88.0.588143224132.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25986/pec35.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:59:21 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:59:21 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617561.6.0.997110212818.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25987/pec36.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:59:33 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:59:33 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617573.52.0.486595480992.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25988/pec37.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:59:42 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:59:42 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617582.7.0.52993363859.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25989/pec38.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 21:59:51 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 19:59:51 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617591.89.0.397188436114.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25990/pec39.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:00:00 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:00:00 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617600.5.0.112764697541.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25991/pec40.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:00:10 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:00:10 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617610.54.0.39878776428.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25992/pec41.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:00:20 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:00:20 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617620.45.0.305979670772.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25993/pec42.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:00:28 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:00:28 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617628.92.0.174214058738.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25994/pec43.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:00:38 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:00:38 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617638.74.0.547176794064.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25995/pec44.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:00:47 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:00:47 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617647.88.0.523692195937.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25996/pec45.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:00:57 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:00:57 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617657.24.0.808668208349.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25997/pec46.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:01:06 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:01:06 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617666.87.0.511175282004.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file25998/pec47.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:01:11 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 13 Jun 2012 20:01:11 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1339617671.97.0.554487885392.issue14674@psf.upfronthosting.co.za> Chris Rebert <pybugs at rebertia.com> added the comment: Any further comments now that the matter of encodings is covered more thoroughly? ---------- Added file: http://bugs.python.org/file25999/json.rst.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14674> _______________________________________ From report at bugs.python.org Wed Jun 13 22:01:19 2012 From: report at bugs.python.org (Gukas Artunyan) Date: Wed, 13 Jun 2012 20:01:19 +0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> Message-ID: <1339617679.19.0.264175209312.issue1054@psf.upfronthosting.co.za> Changes by Gukas Artunyan <gukaar77 at yahoo.com>: Added file: http://bugs.python.org/file26000/pec48.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1054> _______________________________________ From report at bugs.python.org Wed Jun 13 22:01:51 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 13 Jun 2012 20:01:51 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1339617711.91.0.155574873486.issue14674@psf.upfronthosting.co.za> Changes by Chris Rebert <pybugs at rebertia.com>: Removed file: http://bugs.python.org/file25606/json.rst.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14674> _______________________________________ From report at bugs.python.org Wed Jun 13 22:19:50 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 13 Jun 2012 20:19:50 +0000 Subject: [issue9679] unicode DNS names in urllib, urlopen In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za> Message-ID: <1339618790.37.0.00870456099327.issue9679@psf.upfronthosting.co.za> Changes by Chris Rebert <pybugs at rebertia.com>: ---------- nosy: +cvrebert _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9679> _______________________________________ From report at bugs.python.org Wed Jun 13 22:22:52 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 13 Jun 2012 20:22:52 +0000 Subject: [issue4442] document immutable type subclassing via __new__ In-Reply-To: <1227719282.37.0.890069433685.issue4442@psf.upfronthosting.co.za> Message-ID: <1339618972.26.0.492904850926.issue4442@psf.upfronthosting.co.za> Changes by Chris Rebert <pybugs at rebertia.com>: ---------- nosy: +cvrebert _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4442> _______________________________________ From report at bugs.python.org Wed Jun 13 22:41:27 2012 From: report at bugs.python.org (Roumen Petrov) Date: Wed, 13 Jun 2012 20:41:27 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1339620087.98.0.199877209362.issue14599@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: The issue is related to MAXPATHLEN limit and how is implemented . One part of request are already closed , another part wait . Some people port patches other wrote that would not use very long path. I'm in the second group. This buildbot use path with length 54 and since build tree is detected and to this path code adds 'build'. For installed python code will use TEMP environment variable. The test are run in subdir test_python_${PID} and depending of PID the path is with different length. Note this. So try to reproduce with installed python and TEMP set to path like this C:\12345678\12345678\12345678\12345678\12345678\12345678 and run test. The limit of 260(-1) will be reached and FileNotFoundError will be raised. The default value of TEMP is to short to trigger error. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14599> _______________________________________ From report at bugs.python.org Wed Jun 13 23:23:24 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 13 Jun 2012 21:23:24 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1339622604.39.0.193955817815.issue13241@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: The attached configure.ac is a fragment of a configure script that tries to detect if AC_PROG_CC would pick llvm-gcc when clang is also available and then explicitly picks clang. This would avoid "python3.3 won't build on OSX 10.7" bug reports. This is not yet a patch to the real configure file because I'd like to add support for automatically picking the compiler inside Xcode.app when the user has Xcode 4 installed without the unix tools (e.g. on an new OSX 10.7 where the user has installed Xcode from the appstore without further actions). ---------- Added file: http://bugs.python.org/file26001/configure.ac _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13241> _______________________________________ From report at bugs.python.org Wed Jun 13 23:31:35 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 13 Jun 2012 21:31:35 +0000 Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za> Message-ID: <1339623095.09.0.611782215608.issue7584@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: David, Isn't the requested feature now implemented as email.utils.format_datetime()? Also, what is the difference between RFC 3339 format and the one provided by datetime.isoformat? >>> print(datetime(2000,1,1, tzinfo=timezone.utc).isoformat('T')) 2000-01-01T00:00:00+00:00 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7584> _______________________________________ From report at bugs.python.org Wed Jun 13 23:38:23 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 13 Jun 2012 21:38:23 +0000 Subject: [issue13556] When tzinfo.utcoffset is out-of-bounds, the exception message is misleading In-Reply-To: <1323364991.44.0.541305100354.issue13556@psf.upfronthosting.co.za> Message-ID: <1339623503.58.0.902144334772.issue13556@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Does anyone still care about this issue? I think the error message in 3.2 is good enough and fixing this in 2.x is not worth the trouble. I am inclined to close this as "won't fix". ---------- versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13556> _______________________________________ From report at bugs.python.org Wed Jun 13 23:42:05 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Jun 2012 21:42:05 +0000 Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za> Message-ID: <1339623725.89.0.292668710919.issue7584@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: email.utils.format_datetime implements RFC 5322 date format, which is very different from RFC 3339. I don't remember enough about what I read in RFC 3339 to answer your question about isoformat. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7584> _______________________________________ From report at bugs.python.org Wed Jun 13 23:44:07 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 13 Jun 2012 21:44:07 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1339623847.06.0.868409342791.issue1100942@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Bumping priority to get this in before beta. ---------- priority: normal -> high _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1100942> _______________________________________ From report at bugs.python.org Wed Jun 13 23:51:23 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 13 Jun 2012 21:51:23 +0000 Subject: [issue1667546] Time zone-capable variant of time.localtime Message-ID: <1339624283.65.0.443106106105.issue1667546@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: I've simplified Paul's patch by removing timegm and mktimetz functions. Also, platforms that don't support tm_zone are unaffected. ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file26002/issue1667546.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1667546> _______________________________________ From report at bugs.python.org Wed Jun 13 23:59:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Jun 2012 21:59:37 +0000 Subject: [issue15060] docs: socket typo In-Reply-To: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za> Message-ID: <E1SevbD-0001da-Fo@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 744fb52ffdf0 by Sandro Tosi in branch '2.7': Issue #15060: fix typo in socket doc; Patch by anatoly techtonik http://hg.python.org/cpython/rev/744fb52ffdf0 New changeset 4d755a711823 by Sandro Tosi in branch '3.2': Issue #15060: fix typo in socket doc; Patch by anatoly techtonik http://hg.python.org/cpython/rev/4d755a711823 New changeset 29fb36928433 by Sandro Tosi in branch 'default': Issue #15060: merge with 3.2 http://hg.python.org/cpython/rev/29fb36928433 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15060> _______________________________________ From report at bugs.python.org Thu Jun 14 00:00:39 2012 From: report at bugs.python.org (Sandro Tosi) Date: Wed, 13 Jun 2012 22:00:39 +0000 Subject: [issue15060] docs: socket typo In-Reply-To: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za> Message-ID: <1339624839.86.0.35004996809.issue15060@psf.upfronthosting.co.za> Sandro Tosi <sandro.tosi at gmail.com> added the comment: Thanks! ---------- nosy: +sandro.tosi resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15060> _______________________________________ From report at bugs.python.org Thu Jun 14 00:37:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Jun 2012 22:37:38 +0000 Subject: [issue15060] docs: socket typo In-Reply-To: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za> Message-ID: <E1SewC1-0004qI-Gm@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 412c7daed0db by Sandro Tosi in branch '2.7': Issue #15060: better fix, thanks to review on #python-dev http://hg.python.org/cpython/rev/412c7daed0db New changeset e616985284cd by Sandro Tosi in branch '3.2': Issue #15060: better fix, thanks to review on #python-dev http://hg.python.org/cpython/rev/e616985284cd New changeset d16065304bbd by Sandro Tosi in branch 'default': Issue #15060: merge with 3.2 http://hg.python.org/cpython/rev/d16065304bbd ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15060> _______________________________________ From report at bugs.python.org Thu Jun 14 00:39:30 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 13 Jun 2012 22:39:30 +0000 Subject: [issue14955] hmac.secure_compare() is not time-independent for unicode strings In-Reply-To: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> Message-ID: <1339627170.56.0.489310780625.issue14955@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: The second patch looks fine. ---------- nosy: +christian.heimes _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14955> _______________________________________ From report at bugs.python.org Thu Jun 14 00:52:24 2012 From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=) Date: Wed, 13 Jun 2012 22:52:24 +0000 Subject: [issue8668] Packaging: add a 'develop' command In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za> Message-ID: <1339627944.11.0.535808663296.issue8668@psf.upfronthosting.co.za> Alex Gr?nholm <alex.gronholm+python at nextday.fi> added the comment: Python 3.3 is entering beta soon. The develop command is a must have, especially now that virtualenv is part of the official Python distribution. Can someone summarize what still needs to be done to get this feature merged? ---------- nosy: +agronholm _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8668> _______________________________________ From report at bugs.python.org Thu Jun 14 01:00:24 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 13 Jun 2012 23:00:24 +0000 Subject: [issue15061] hmac.secure_compare() leaks information of length of strings Message-ID: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> New submission from Christian Heimes <lists at cheimes.de>: The secure_compare() function immediately returns False when both strings don't have equal length. With the patch the run time of secure_compare() always depends on the length of the right side. It no longer gives away information about the length of the left side. The patch should be applied in combination with the patch in issue #14955. ---------- components: IO files: secure_compare_length.patch keywords: needs review, patch messages: 162739 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: hmac.secure_compare() leaks information of length of strings type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file26003/secure_compare_length.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 01:08:47 2012 From: report at bugs.python.org (Paul Boddie) Date: Wed, 13 Jun 2012 23:08:47 +0000 Subject: [issue1667546] Time zone-capable variant of time.localtime In-Reply-To: <1339624283.65.0.443106106105.issue1667546@psf.upfronthosting.co.za> Message-ID: <201206140112.40424.paul@boddie.org.uk> Paul Boddie <paul at boddie.org.uk> added the comment: On Wednesday 13 June 2012 23:51:25 Alexander Belopolsky wrote: > Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: > > I've simplified Paul's patch by removing timegm and mktimetz functions. > Also, platforms that don't support tm_zone are unaffected. I think you may have forgotten to remove docstring references to those functions. Nice to see some progress on the issue, though, and it's probably good to solve one problem at a time in this way, too. Paul ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1667546> _______________________________________ From report at bugs.python.org Thu Jun 14 01:15:46 2012 From: report at bugs.python.org (wrobell) Date: Wed, 13 Jun 2012 23:15:46 +0000 Subject: [issue15062] argparse: option for a positional argument Message-ID: <1339629346.54.0.223771927159.issue15062@psf.upfronthosting.co.za> New submission from wrobell <wrobell at pld-linux.org>: it would be great if argparse allowed to specify options for multiple positional arguments, i.e. usage: ascript [-h] [-k value] input [[-k value] input ...] output then $ ascript pos1 pos2 -k 1 pos3 -k 2 pos4 pos5 pos6 out would give Namespace(input=[(None, 'pos1'), (None, 'pos2'), ('1', 'pos3'), ('2', 'pos4'), (None, 'pos5'), ('None', 'pos6')], output=['out']) ---------- components: Library (Lib) messages: 162741 nosy: wrobell priority: normal severity: normal status: open title: argparse: option for a positional argument type: enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15062> _______________________________________ From report at bugs.python.org Thu Jun 14 01:57:58 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 13 Jun 2012 23:57:58 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1339631878.34.0.781273102257.issue13241@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: The attached patch "issue13241-configure-version1.txt" implements a number of changes to configure (although only configure.ac is present in the patch) 1) Autodetect the compiler on OSX, in particular - detect llvm-gcc and use clang instead - use clang when gcc cannot be found - use xcrun to locate clang when it isn't in /usr/bin (no Command Line Tools for Xcode) 2) Detect the most recent working SDK, falls back to the 10.4u SDK when using an old version of Xcode or even '/' when that SDK isn't present This patch needs work though: * I have barely tested the patch, configure seems to generate a valid Makefile on OSX 10.7 with the unix tools installed, I haven't tested yet on older OSX versions of without the unix tools installed * Distutils/packaging also need changes: need to detect that the running system has different compiler tools than the build system. This is needed to be able to use the binary installers on python.org on systems with other compiler versions and installed SDKs ---------- Added file: http://bugs.python.org/file26004/issue13241-configure-version1.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13241> _______________________________________ From report at bugs.python.org Thu Jun 14 02:13:10 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 00:13:10 +0000 Subject: [issue15062] argparse: option for a positional argument In-Reply-To: <1339629346.54.0.223771927159.issue15062@psf.upfronthosting.co.za> Message-ID: <1339632790.26.0.216996931605.issue15062@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: It took me a while to make any sense out of your example, but having done so I don't think it makes any sense in the argparse context. It is certainly not the way argparse handles options or arguments. In argparse, if you have an option 'k', you get 'k' mapped to a value in the Namespace. I don't believe I've ever seen a command line command with syntax like that either. Do you know of one? ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15062> _______________________________________ From report at bugs.python.org Thu Jun 14 02:19:14 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 14 Jun 2012 00:19:14 +0000 Subject: [issue1667546] Time zone-capable variant of time.localtime In-Reply-To: <201206140112.40424.paul@boddie.org.uk> Message-ID: <CAP7h-xbXjTNqGy+TRGE3L9Zf_F5_eOx-fqhHb8WmgmOnF0kkhw@mail.gmail.com> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: On Wed, Jun 13, 2012 at 7:08 PM, Paul Boddie <report at bugs.python.org> wrote: > I think you may have forgotten to remove docstring references to those > functions. Good catch. BTW, did you write the additional tests for strptime? This is the only thing that I want to add before committing. ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1667546> _______________________________________ From report at bugs.python.org Thu Jun 14 03:04:46 2012 From: report at bugs.python.org (wrobell) Date: Thu, 14 Jun 2012 01:04:46 +0000 Subject: [issue15062] argparse: option for a positional argument In-Reply-To: <1339629346.54.0.223771927159.issue15062@psf.upfronthosting.co.za> Message-ID: <1339635886.97.0.749419871691.issue15062@psf.upfronthosting.co.za> wrobell <wrobell at pld-linux.org> added the comment: an example would be a pdf merger accepting multiple files and allowing to specify list of pages for each input. at the moment, you can do the following with argparse pdfmerge [pages] input [[pages] input ...] output of course, above is not perfect as you need a bit of heuristic to determine what is "pages" and what is the "input" itself (easy to do, but still...). on other side, i find the following more straightforward pdfmerge [-p pages] input [[-p pages] input ...] output or to complicate things pdfmerge [-p pages] [-s scale] input [[-p pages] [-s scale] input ...] output btw. i understand the argparse limitations, therefore putting this as feature enhancement... if possible :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15062> _______________________________________ From report at bugs.python.org Thu Jun 14 03:18:12 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 01:18:12 +0000 Subject: [issue15062] argparse: option for a positional argument In-Reply-To: <1339629346.54.0.223771927159.issue15062@psf.upfronthosting.co.za> Message-ID: <1339636692.95.0.356347280866.issue15062@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Well, if you can figure out how to add it, please do suggest a patch :) It occurs to me that 'find' is a sort-of similar example, where options can be repeated but the order in which they appear relative to other options matters. So I can see that there could be utility to such a thing if someone can figure out how to do it. On the other hand, it is quite possible that these kind of commands really need a custom parser. ---------- nosy: +bethard _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15062> _______________________________________ From report at bugs.python.org Thu Jun 14 04:16:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jun 2012 02:16:09 +0000 Subject: [issue1667546] Time zone-capable variant of time.localtime Message-ID: <E1SezbU-0004QA-2o@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 3b5545ba6432 by Alexander Belopolsky in branch 'default': Issue #1667546: On platforms supporting tm_zone and tm_gmtoff fields http://hg.python.org/cpython/rev/3b5545ba6432 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1667546> _______________________________________ From report at bugs.python.org Thu Jun 14 04:18:24 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 14 Jun 2012 02:18:24 +0000 Subject: [issue1667546] Time zone-capable variant of time.localtime Message-ID: <1339640304.57.0.759639640178.issue1667546@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1667546> _______________________________________ From report at bugs.python.org Thu Jun 14 04:29:37 2012 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Jun 2012 02:29:37 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1339640977.66.0.740516740011.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: Attaching a patch that implements the latest version of the PEP. Quick summary: 1. Ditched Signature.name & Signature.qualname 2. Added Signature.__eq__ and __ne__ 3. signature() supports classes, metaclasses, decorated stuff, partials, methods, classmethods, callable objects etc 4. signature() does a deepcopy of __signature__ attribute if there is one 5. No implicit caching anywhere 6. Signature.format(...) and Signature.__str__ 7. Signature.bind_partial ---------- Added file: http://bugs.python.org/file26005/pep362.2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Thu Jun 14 05:19:32 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 Jun 2012 03:19:32 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339643972.3.0.135280616246.issue12982@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: The response from pydev is that running .pyc with -O or running .pyo without is not officially supported. Even if mixing usually works now, it does not always work properly for code with __debug__, assert, or __doc__. The scope of possible malfunctions may increase if ideas for more aggressive optimization are implemented. So mixing the two types of cache files is 'do at your own risk' and 'don't complain if it does not work now or ceases to work in the future'. A principle reason for the above is that __debug__ == <not -O> and that it affects complilation, not just execution. The doc should say the above more clearly. Eric L., where is the doc quote from? ---------- components: +Documentation -Interpreter Core _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Thu Jun 14 06:30:55 2012 From: report at bugs.python.org (Bryce Verdier) Date: Thu, 14 Jun 2012 04:30:55 +0000 Subject: [issue15063] Source code links for JSON documentation Message-ID: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za> New submission from Bryce Verdier <bryceverdier at gmail.com>: In some parts of the documentation there are links to the source code. While looking in the JSON documentation that link isn't there. Not sure if this is wanted or if it's complete. But I'm submitting it anyway in the hopes of feedback. ---------- assignee: docs at python components: Documentation files: json_source_link.patch keywords: patch messages: 162750 nosy: docs at python, louiscipher priority: normal severity: normal status: open title: Source code links for JSON documentation type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file26006/json_source_link.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15063> _______________________________________ From report at bugs.python.org Thu Jun 14 06:50:18 2012 From: report at bugs.python.org (Vetoshkin Nikita) Date: Thu, 14 Jun 2012 04:50:18 +0000 Subject: [issue14848] Use shutil.move instead of os.rename in packaging In-Reply-To: <1337331032.2.0.780379839017.issue14848@psf.upfronthosting.co.za> Message-ID: <1339649418.28.0.417357213434.issue14848@psf.upfronthosting.co.za> Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment: Sorry, no traceback by default, had to augment with "raise" :) Now output looks like this: nekto0n at ya-darkstar /var/tmp/mypackage $ pysetup remove pygraphviz u'workflow': u'1.01' is not a valid version (field 'Version') u'zc-zookeeper-static': u'3.4.3-3' is not a valid version (field 'Version') u'virtkey': u'0.01' is not a valid version (field 'Version') u'SSSDConfig': u'1' is not a valid version (field 'Version') [Errno 18] Invalid cross-device link Traceback (most recent call last): File "/home/nekto0n/.local/lib/python2.7/site-packages/distutils2/run.py", line 651, in main return dispatcher() File "/home/nekto0n/.local/lib/python2.7/site-packages/distutils2/run.py", line 639, in __call__ return func(self, self.args) File "/home/nekto0n/.local/lib/python2.7/site-packages/distutils2/run.py", line 91, in wrapper return f(*args, **kwargs) File "/home/nekto0n/.local/lib/python2.7/site-packages/distutils2/run.py", line 239, in _remove remove(dist, auto_confirm=auto_confirm) File "/home/nekto0n/.local/lib/python2.7/site-packages/distutils2/install.py", line 413, in remove error = _move_file(file_, tmpfile) File "/home/nekto0n/.local/lib/python2.7/site-packages/distutils2/install.py", line 399, in _move_file os.rename(source, target) OSError: [Errno 18] Invalid cross-device link According to strace arguments to rename where: rename("/home/nekto0n/.local/lib/python2.7/site-packages/pygraphviz-1.1-py2.7.egg-info/PKG-INFO", "/tmp/pygraphviz-uninstallIiAQ1I/PKG-INFO") = -1 EXDEV (Invalid cross-device link) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14848> _______________________________________ From report at bugs.python.org Thu Jun 14 07:07:21 2012 From: report at bugs.python.org (John Nagle) Date: Thu, 14 Jun 2012 05:07:21 +0000 Subject: [issue9679] unicode DNS names in urllib, urlopen In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za> Message-ID: <1339650441.77.0.891948575258.issue9679@psf.upfronthosting.co.za> John Nagle <nagle at users.sourceforge.net> added the comment: The current convention is that domains go into DNS lookup as punycode, and the port, query, and fragment fields of the URL are encoded with percent-escapes. See http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0155.html Python needs to get with the program here. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9679> _______________________________________ From report at bugs.python.org Thu Jun 14 07:17:12 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 14 Jun 2012 05:17:12 +0000 Subject: [issue14848] Use shutil.move instead of os.rename in packaging In-Reply-To: <1337331032.2.0.780379839017.issue14848@psf.upfronthosting.co.za> Message-ID: <1339651032.17.0.470571504235.issue14848@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Thanks! As your message shows the problem is in the install module, I propose to close this bug as a duplicate of Alexis? bug about improving d2.install. The new FileMover class should use shutil.move, and we?ll make sure to test install+remove as you did to see if the bug is gone. ---------- assignee: eric.araujo -> alexis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14848> _______________________________________ From report at bugs.python.org Thu Jun 14 07:17:53 2012 From: report at bugs.python.org (mattip) Date: Thu, 14 Jun 2012 05:17:53 +0000 Subject: [issue15040] stdlib compatability with pypy: mailbox.py In-Reply-To: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> Message-ID: <1339651073.62.0.260810353401.issue15040@psf.upfronthosting.co.za> mattip <matti.picus at gmail.com> added the comment: What is the next stage in moving this forward? I am new here... ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Thu Jun 14 07:19:43 2012 From: report at bugs.python.org (Vetoshkin Nikita) Date: Thu, 14 Jun 2012 05:19:43 +0000 Subject: [issue14848] Use shutil.move instead of os.rename in packaging In-Reply-To: <1337331032.2.0.780379839017.issue14848@psf.upfronthosting.co.za> Message-ID: <1339651183.67.0.0632899287361.issue14848@psf.upfronthosting.co.za> Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment: glad to help ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14848> _______________________________________ From report at bugs.python.org Thu Jun 14 09:12:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 14 Jun 2012 07:12:45 +0000 Subject: [issue15059] Potential Bug in mpd_qresize and mpd_qresize_zero In-Reply-To: <1339609957.89.0.517286245492.issue15059@psf.upfronthosting.co.za> Message-ID: <1339657965.91.0.656571974703.issue15059@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: You can't return mpd_realloc_dyn(result, nwords, status) in the second instance: the coefficient must be initialized to zero later on. So this is intentional. ---------- components: +Extension Modules -Library (Lib) resolution: -> invalid stage: -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15059> _______________________________________ From report at bugs.python.org Thu Jun 14 09:13:01 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 14 Jun 2012 07:13:01 +0000 Subject: [issue15059] Potential Bug in mpd_qresize and mpd_qresize_zero In-Reply-To: <1339609957.89.0.517286245492.issue15059@psf.upfronthosting.co.za> Message-ID: <1339657981.65.0.986671204697.issue15059@psf.upfronthosting.co.za> Changes by Stefan Krah <stefan-usenet at bytereef.org>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15059> _______________________________________ From report at bugs.python.org Thu Jun 14 09:50:39 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 14 Jun 2012 07:50:39 +0000 Subject: [issue15057] Potential Bug in mpd_qdivint and mpd_qrem In-Reply-To: <1339609359.6.0.237192650193.issue15057@psf.upfronthosting.co.za> Message-ID: <1339660239.88.0.264332247676.issue15057@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: I can see why it is seems strange that // and % behave differently. If anything, I'd change divint to raise for things like inf // 3. But the official test cases don't: dvix601 divideint -Inf -1000 -> Infinity remx701 remainder -Inf -1000 -> NaN Invalid_operation Since decimal follows the specification (and the test cases), we can't change that. So I'm closing the issue. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15057> _______________________________________ From report at bugs.python.org Thu Jun 14 10:33:03 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Thu, 14 Jun 2012 08:33:03 +0000 Subject: [issue15061] hmac.secure_compare() leaks information of length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339662783.79.0.89743319374.issue15061@psf.upfronthosting.co.za> Maciej Fijalkowski <fijall at gmail.com> added the comment: secure_compare leaks the password always. Note that it takes different time to create a result of ord() depending whether it's <=100 or > 100 due to caching of small numbers. Such functions should be written in C. ---------- nosy: +fijall _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 11:10:11 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 14 Jun 2012 09:10:11 +0000 Subject: [issue15061] hmac.secure_compare() leaks information of length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339665011.94.0.133404378092.issue15061@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: We should. Adding secure functions that aren't really secure is something we should rather avoid. :) Christian, are you willing to do that? ---------- components: +Library (Lib) -IO nosy: +hynek stage: patch review -> needs patch type: behavior -> security versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 11:19:00 2012 From: report at bugs.python.org (Armin Rigo) Date: Thu, 14 Jun 2012 09:19:00 +0000 Subject: [issue15061] hmac.secure_compare() leaks information of length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339665540.96.0.36795135286.issue15061@psf.upfronthosting.co.za> Armin Rigo <arigo at users.sourceforge.net> added the comment: fijal: while I agree with you, the limit for small ints has actually been pushed to 257 in recent CPythons. So it should still theoretically work --- of course, assuming a predictable CPU, which is wrong, and assuming a simple interpreter. (We can probably dig enough to find a timing issue even with CPython, and of course it's clear with any of the other Python interpreters out there.) ---------- nosy: +arigo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 11:19:28 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 14 Jun 2012 09:19:28 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339665568.1.0.630481869134.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: I don't see how the function is going to leak this information when both this patch and the patch in #14955 are applied. With http://bugs.python.org/file25801/secure-compare-fix-v2.patch ord() is no longer used and thus avoid the timing difference for integers > 256 (NSMALLPOSINTS is defined as 257, not 100). ---------- title: hmac.secure_compare() leaks information of length of strings -> hmac.secure_compare() leaks information about length of strings _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 11:22:40 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Thu, 14 Jun 2012 09:22:40 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339665760.93.0.641298301244.issue15061@psf.upfronthosting.co.za> Maciej Fijalkowski <fijall at gmail.com> added the comment: Ah unicodes. is encode('unicode-internal') independent on the string characters? I heavily doubt so. you leak at least some information through that function alone. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 11:31:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 09:31:26 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339666286.01.0.68883136263.issue15061@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: With PEP 393 unicode objects can have several representations, which makes it unlikely that *really* constant-timing functions can be devised. Speaking about this particular patch, I don't understand the point. secure_compare() is obviously meant to be used on inputs of some known length, not arbitrary data. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 11:55:22 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 14 Jun 2012 09:55:22 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339667722.74.0.625096369636.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: IMHO it's not obvious to all users. Better safe than sorry. ;) The invariant 'known and equal length' impresses an artificial limitation. Code may need to compare outside data with internal data without exposing too many details about the structure of the internal data. The other matter should be discussed at #14955. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 12:02:47 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 14 Jun 2012 10:02:47 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339668167.56.0.337598586431.issue15061@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: I don?t want to be the killjoy but I find it highly questionable to add a function that is advertised as "secure" while we can't fully grok the complexities at play. If we can't produce a provable secure one, we should scrub the function for good; or at least rename it somehow. Unjustified perceived security is IMHO the worst possible case. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 12:10:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 10:10:19 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339668167.56.0.337598586431.issue15061@psf.upfronthosting.co.za> Message-ID: <1339668436.3355.2.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > I don?t want to be the killjoy but I find it highly questionable to > add a function that is advertised as "secure" while we can't fully > grok the complexities at play. If we can't produce a provable secure > one, we should scrub the function for good; or at least rename it > somehow. The function is probably secure (modulo unseen bugs) in the bytestrings-of-the-same-size case. To make it "provably" secure, we could write a C version (which would be quite easy). For unicode strings things are a bit trickier though. Again, a C version could provide some guarantees (and could raise an error if the passed unicode strings use a different representation from each other). ---------- title: hmac.secure_compare() leaks information about length of strings -> hmac.secure_compare() leaks information about length of strings _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 12:13:48 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Thu, 14 Jun 2012 10:13:48 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339668828.26.0.333357632819.issue15061@psf.upfronthosting.co.za> Maciej Fijalkowski <fijall at gmail.com> added the comment: Antoine, seriously? You want to explore a function that's called "secure" when the only thing you know about it is "probably secure"? This is extremely tricky business and I think it should be called secure only if you can prove it's secure. Otherwise it's plain insecure and should not be named that. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 12:15:38 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Thu, 14 Jun 2012 10:15:38 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339668938.35.0.0684645970427.issue15061@psf.upfronthosting.co.za> Maciej Fijalkowski <fijall at gmail.com> added the comment: export not explore. Why can't I edit my own post? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 12:18:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 10:18:29 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339668828.26.0.333357632819.issue15061@psf.upfronthosting.co.za> Message-ID: <1339668927.3355.3.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Antoine, seriously? You want to explore a function that's called > "secure" when the only thing you know about it is "probably secure"? > This is extremely tricky business and I think it should be called > secure only if you can prove it's secure. Otherwise it's plain > insecure and should not be named that. What's the methodology to "prove" that it's secure? We could rename "secure" to "safe" to downtone it a bit, but it's still an improvement on the nominal equality comparison. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 12:27:30 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Thu, 14 Jun 2012 10:27:30 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339669650.78.0.39173411674.issue15061@psf.upfronthosting.co.za> Maciej Fijalkowski <fijall at gmail.com> added the comment: For unicode at the very least it's not an improvement at all. With the patch mentioned that does encode it's also not an improvement at all. Prove as in reason about the function in C and make sure it does not do any conditionals depending on the input data. This is much easier than it is in Python. We did this exercise for PyPy once, just for the sake of it. We looked at generated IR and made sure a comparison is not leaking any data. As far as the function goes right now - I don't know. For now following the entire code of long_bitwise is a lot of effort - I genuinely can't say that it'll be the same for all numbers of 0-255. Can you? It's easier with low-level language simply (And yes, this is one of the few cases where I would argue it makes sense to implement something in C :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 13:01:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 11:01:50 +0000 Subject: [issue14955] hmac.secure_compare() is not time-independent for unicode strings In-Reply-To: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> Message-ID: <1339671710.45.0.734011914631.issue14955@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: With PEP 393 unicode objects can have several representations, which makes it unlikely that *really* constant-timing functions can be devised. However, a C version could provide some guarantees, by raising an error if the passed unicode strings use a different representation from each other. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14955> _______________________________________ From report at bugs.python.org Thu Jun 14 13:07:45 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 14 Jun 2012 11:07:45 +0000 Subject: [issue14955] hmac.secure_compare() is not time-independent for unicode strings In-Reply-To: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> Message-ID: <1339672065.81.0.89760332563.issue14955@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14955> _______________________________________ From report at bugs.python.org Thu Jun 14 13:16:10 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 14 Jun 2012 11:16:10 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1339672570.93.0.992531466374.issue14532@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I recommend to revert the addition of this function. It's not possible to implement a time-independent comparison function, as demonstrated in issues 14955 and 15061 ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14532> _______________________________________ From report at bugs.python.org Thu Jun 14 13:17:11 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 14 Jun 2012 11:17:11 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339672631.55.0.0834580598789.issue15061@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I recommend to revert the addition of the function, given that it can't be made secure. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 13:20:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 11:20:40 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1339672840.98.0.785278784526.issue14532@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: How is it "not possible"? The implementation may be buggy, but it's possible to write a C version that does the right thing. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14532> _______________________________________ From report at bugs.python.org Thu Jun 14 13:48:10 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 14 Jun 2012 11:48:10 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1339674490.56.0.866410199895.issue14532@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14532> _______________________________________ From report at bugs.python.org Thu Jun 14 14:01:34 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 14 Jun 2012 12:01:34 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339675294.61.0.362837031043.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: I've two suggestions: * rename the function to 'total_compare'. The name explains what the function actually does in comparison to '=='. It takes the total input values into account instead of using short circuit comparison. * restrict the function to bytes. The implementation works well with bytes but not with unicode. It's not an issue since hash digests are bytes. The docs could explain the issue with unicode and how user code can implement a reasonable safe conversion. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 14:13:45 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 14 Jun 2012 12:13:45 +0000 Subject: [issue15064] multiprocessing should use more context manager Message-ID: <1339676025.91.0.9899325094.issue15064@psf.upfronthosting.co.za> New submission from Richard Oudkerk <shibturn at gmail.com>: There are some types which should support the context manager protocol: - connection objects - listener objects - pool objects ---------- messages: 162776 nosy: sbt priority: normal severity: normal stage: needs patch status: open title: multiprocessing should use more context manager type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15064> _______________________________________ From report at bugs.python.org Thu Jun 14 14:16:48 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Thu, 14 Jun 2012 12:16:48 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339676208.48.0.978931257844.issue15061@psf.upfronthosting.co.za> Maciej Fijalkowski <fijall at gmail.com> added the comment: Hi Christian. It's either secure or it's not. If it's not, there is no point in introducing it at all as I don't think it's a good idea to have a kind-of-secure-but-i-dont-know functions in stdlib. If you restrict input to bytes it looks okish, but I looked at all the code that's invoked on the C side and it's quite a lot of code. Does you or anyone else actually go and review all the C code that's called via various operations to check if it does or does not depend on the value of various characters? I can't tell myself, it's too long. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 14:26:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 12:26:25 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339676785.66.0.148848146387.issue15061@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > It's either secure or it's not. I don't think that's true. By that reasoning, Python is not secure so there's no point in fixing crashes or providing a hashlib module. That said, I think renaming to "total_compare" isn't really helpful. The point of the function is to be secure (as much as possible), not to do a "total" comparison. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 14 14:48:01 2012 From: report at bugs.python.org (Kevin) Date: Thu, 14 Jun 2012 12:48:01 +0000 Subject: [issue15065] strftime format string %F %T consistency problem Message-ID: <1339678081.17.0.304576211597.issue15065@psf.upfronthosting.co.za> New submission from Kevin <kevin.fairbanks at gatech.edu>: When using %F and %T in strftime on Mac and Linux the function works as expected, but it fails on Windows. Although these format strings are not in the Python documentation, the inconsistent behavior should be noted or corrected. If possible, the %F and %T could be expanded in some way on Windows systems or cause a format string error on POSIX systems so that the function behaves the same way across platforms. ---------- messages: 162779 nosy: kfairbanks priority: normal severity: normal status: open title: strftime format string %F %T consistency problem type: behavior versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15065> _______________________________________ From report at bugs.python.org Thu Jun 14 14:49:59 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 12:49:59 +0000 Subject: [issue9679] unicode DNS names in urllib, urlopen In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za> Message-ID: <1339678199.74.0.935054787307.issue9679@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: As I said, patches to improve the situation are welcome, and if they match with current internet practices they will likely be accepted. It is still the case that such URLs are likely to require extra work on the part of the application to deal with the other unicode parts (your linked reference reinforces that). So, IMO it would be *better* if someone would do an IRI module. But the fact that nobody has stepped up for that should not prevent us from improving the situation in other ways. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9679> _______________________________________ From report at bugs.python.org Thu Jun 14 14:54:07 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 12:54:07 +0000 Subject: [issue15040] stdlib compatability with pypy: mailbox.py In-Reply-To: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> Message-ID: <1339678447.23.0.800025450741.issue15040@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: You could get one of the pypy devs that have push rights on cpython to commit it. If that doesn't happen, then at some point (probably not *too* long from now) I or someone else will commit it. We have many more patches than we have people with time to commit them, so it sometimes takes a bit. ---------- stage: patch review -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Thu Jun 14 15:08:03 2012 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Thu, 14 Jun 2012 13:08:03 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339679283.42.0.25601996839.issue12982@psf.upfronthosting.co.za> Eric O. LEBIGOT <eric.lebigot at normalesup.org> added the comment: Terry, it seems that the doc I was quoting is for version 1.5.1 (http://docs.python.org/release/1.5.1p1/tut/node43.html). I can't find it in more recent versions of the doc. I should not have quoted an obsolete version of the documentation?I'm not sure how this happened. :) I am not fully sure why -O is essentially required for running .pyo files: why not have the Python interpreter handle everything automatically based on the extension? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Thu Jun 14 15:09:50 2012 From: report at bugs.python.org (Michael Herrmann) Date: Thu, 14 Jun 2012 13:09:50 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339679390.35.0.625634548803.issue12982@psf.upfronthosting.co.za> Michael Herrmann <mherrmann.at at gmail.com> added the comment: That is *exactly* my point :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Thu Jun 14 15:20:05 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 13:20:05 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339680005.19.0.543112024515.issue12982@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Because: 1) The __debug__ flag is defined to be process-global. If you test it in one module, your code should be able to assume that it has the same value in all other modules 2) python-dev does not support running .pyo code without -O turned on. In the future it might be the case that -O would actually change the behavior of the running python interpreter such that .pyo code would fail of -O was not on. So, you can do the rename or importer trick if you want, and it will work right now as long as your program does not depend on __debug__ being globally consistent (which would be the case for almost all programs), but we do not guarantee it will continue to work in future versions of Python. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Thu Jun 14 15:29:28 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 13:29:28 +0000 Subject: [issue15065] strftime format string %F %T consistency problem In-Reply-To: <1339678081.17.0.304576211597.issue15065@psf.upfronthosting.co.za> Message-ID: <1339680568.31.0.248066938465.issue15065@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: The reason the codes are not documented is that they are not supported. Because we delegate to the system strftime, they happen to work. To change that the most sensible thing would be to have our own strftime implementation, which makes this essentially a duplicate of issue 3173. See also issue 14441. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> external strftime for Python? _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15065> _______________________________________ From report at bugs.python.org Thu Jun 14 15:36:04 2012 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 14 Jun 2012 13:36:04 +0000 Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet In-Reply-To: <1279061543.77.0.750672834209.issue7584@psf.upfronthosting.co.za> Message-ID: <CAPkN8xJKgu11o790WbmDGiTcDXp3J7z0KcLd-Tt=4k_Y6H7xdw@mail.gmail.com> anatoly techtonik <techtonik at gmail.com> added the comment: On Wed, Jul 14, 2010 at 1:52 AM, Alexander Belopolsky <report at bugs.python.org> wrote: > I am still -1 on adding specialized formatting methods to the datetime class. ?I think this should be done in specialized modules. No problem - add "formats" module and I'll be happy. >On the other hand, datetime module should provide facilities to easily implement such methods and there does not seem to be a good solution for implementing locale independent formats. ?I would like to consider the idea of adding datetime.cstrftime() which provides formatting equivalent to datetime.strftime() in "C" locale. ?Another feature that will be needed to implement rfcformat, would be a GNU date style "%:z" code. If there is no best solution then the best out worse solutions is much much better - provided that an appropriate explanation is available for the users. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7584> _______________________________________ From report at bugs.python.org Thu Jun 14 15:37:05 2012 From: report at bugs.python.org (anatoly techtonik) Date: Thu, 14 Jun 2012 13:37:05 +0000 Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet In-Reply-To: <CAPkN8xJKgu11o790WbmDGiTcDXp3J7z0KcLd-Tt=4k_Y6H7xdw@mail.gmail.com> Message-ID: <CAPkN8xL6a0E_QGUWwBjpuna_Yt2wXpgy-x-_PoF1j-E8N5pw1w@mail.gmail.com> anatoly techtonik <techtonik at gmail.com> added the comment: I must add - many times better than no solution at all. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7584> _______________________________________ From report at bugs.python.org Thu Jun 14 15:40:37 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 14 Jun 2012 13:40:37 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339681237.0.0.173138588691.issue12982@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: > I am not fully sure why -O is essentially required for running .pyo > files: why not have the Python interpreter handle everything > automatically based on the extension? In part because it would take work to make it happen and apparently no one feels strongly enough about adding that functionality, or convinced enough that it's appropriate, to do the work. If you're interested a good first step would be to write a PEP 302 metapath hook (finder that gets inserted to sys.metapath) that makes import of .pyo files work even when -O is not used. Maybe you'd also want to have .pyc files work even when -O *is* used. Keep in mind that there may be other reasons why such functionality would not go into the interpreter. However, the beauty of import hooks is that it wouldn't matter once you have yours in hand. ---------- nosy: +eric.snow _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Thu Jun 14 15:49:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jun 2012 13:49:10 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <E1SfAQ7-0002TU-PL@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 62030ebb2b01 by Martin v. L?wis in branch '3.2': Issue #14937: Fix typo. Patch by Roger Serwy. http://hg.python.org/cpython/rev/62030ebb2b01 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14937> _______________________________________ From report at bugs.python.org Thu Jun 14 16:09:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jun 2012 14:09:39 +0000 Subject: [issue14936] PEP 3121, 384 refactoring applied to curses_panel module In-Reply-To: <1338223470.25.0.655210931272.issue14936@psf.upfronthosting.co.za> Message-ID: <E1SfAjx-0005Ai-3l@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 9a6b45a83dec by Martin v. L?wis in branch 'default': Issue #14936: curses_panel was converted to PEP 3121 API. http://hg.python.org/cpython/rev/9a6b45a83dec New changeset 6eb21c1d3099 by Martin v. L?wis in branch 'default': Issue #14936: curses_panel was converted to PEP 3121 and PEP 384 API. http://hg.python.org/cpython/rev/6eb21c1d3099 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14936> _______________________________________ From report at bugs.python.org Thu Jun 14 16:11:01 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 14 Jun 2012 14:11:01 +0000 Subject: [issue14936] PEP 3121, 384 refactoring applied to curses_panel module In-Reply-To: <1338223470.25.0.655210931272.issue14936@psf.upfronthosting.co.za> Message-ID: <1339683061.19.0.695498539727.issue14936@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Thanks for the patches! ---------- nosy: +loewis resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14936> _______________________________________ From report at bugs.python.org Thu Jun 14 16:12:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 14 Jun 2012 14:12:18 +0000 Subject: [issue15042] Implemented PyState_AddModule, PyState_RemoveModule In-Reply-To: <1339320622.0.0.56459406352.issue15042@psf.upfronthosting.co.za> Message-ID: <1339683138.76.0.495330181668.issue15042@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: These functions need to be documented. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15042> _______________________________________ From report at bugs.python.org Thu Jun 14 16:28:48 2012 From: report at bugs.python.org (David Barnett) Date: Thu, 14 Jun 2012 14:28:48 +0000 Subject: [issue11880] add a {dist-info} category to distutils2 In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za> Message-ID: <1339684128.96.0.744408983701.issue11880@psf.upfronthosting.co.za> David Barnett <davidbarnett2 at gmail.com> added the comment: Is this ready and just waiting to be merged now? ---------- nosy: +mu_mind _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11880> _______________________________________ From report at bugs.python.org Thu Jun 14 16:36:22 2012 From: report at bugs.python.org (suzhengchun) Date: Thu, 14 Jun 2012 14:36:22 +0000 Subject: [issue15066] make install error: ImportError: No module named _struct Message-ID: <1339684582.74.0.731857257466.issue15066@psf.upfronthosting.co.za> New submission from suzhengchun <suzhengchun at yahoo.com.cn>: if test -d /WORK/suzc/installed/python/lib/python2.7/distutils/tests; then \ /usr/bin/install -c -m 644 ./Modules/xxmodule.c \ /WORK/suzc/installed/python/lib/python2.7/distutils/tests ; \ fi PYTHONPATH=/WORK/suzc/installed/python/lib/python2.7 \ ./python -Wi -tt /WORK/suzc/installed/python/lib/python2.7/compileall.py \ -d /WORK/suzc/installed/python/lib/python2.7 -f \ -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \ /WORK/suzc/installed/python/lib/python2.7 Traceback (most recent call last): File "/WORK/suzc/installed/python/lib/python2.7/compileall.py", line 16, in <module> import struct File "/WORK/suzc/installed/python/lib/python2.7/struct.py", line 1, in <module> from _struct import * ImportError: No module named _struct make: *** [libinstall] ?? 1 In directory /WORK/suzc/software/Python-2.7.3, I do this: suzc at linux-opensuse:22:33:28:Python-2.7.3$ ./configure --prefix=/WORK/suzc/installed/python --exec-prefix=/WORK/suzc/installed/python --mandir=/WORK/suzc/installed/man | tee -a config_make.20120614.log make make install and then meets the install error!! python's version is 2.7.3, i download the .tgz & .bz2, both the some problem. My system is: suzc at linux-opensuse:22:33:28:Python-2.7.3$ uname -a Linux linux-opensuse 3.1.0-rc7-3-desktop #1 SMP PREEMPT Wed Sep 28 14:41:36 UTC 2011 (50fb02f) x86_64 x86_64 x86_64 GNU/Linux suzc at linux-opensuse:22:35:22:Python-2.7.3$ lsb_release -a LSB Version: n/a Distributor ID: SUSE LINUX Description: openSUSE 12.1 Beta 1 (x86_64) Release: 12.1 Codename: Asparagus any help? Thank you very much. ---------- components: Installation messages: 162794 nosy: suzhengchun priority: normal severity: normal status: open title: make install error: ImportError: No module named _struct type: compile error versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15066> _______________________________________ From report at bugs.python.org Thu Jun 14 16:40:05 2012 From: report at bugs.python.org (Daniel Holth) Date: Thu, 14 Jun 2012 14:40:05 +0000 Subject: [issue11880] add a {dist-info} category to distutils2 In-Reply-To: <1339684128.96.0.744408983701.issue11880@psf.upfronthosting.co.za> Message-ID: <1339684802.16558.140661089208833.1F5BA39C@webmail.messagingengine.com> Daniel Holth <dholth at fastmail.fm> added the comment: Yes, but I had some trouble attaching a good patch to the issue tracker itself. On Thu, Jun 14, 2012, at 02:28 PM, David Barnett wrote: > > David Barnett <davidbarnett2 at gmail.com> added the comment: > > Is this ready and just waiting to be merged now? > > ---------- > nosy: +mu_mind > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue11880> > _______________________________________ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11880> _______________________________________ From report at bugs.python.org Thu Jun 14 16:49:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jun 2012 14:49:09 +0000 Subject: [issue13841] multiprocessing should use sys.exit() where possible In-Reply-To: <1327345132.43.0.775594933755.issue13841@psf.upfronthosting.co.za> Message-ID: <E1SfBMB-0001Nl-Nk@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset d31e83497c5a by Richard Oudkerk in branch 'default': Issue #13841: Make child processes exit using sys.exit() on Windows http://hg.python.org/cpython/rev/d31e83497c5a ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13841> _______________________________________ From report at bugs.python.org Thu Jun 14 17:19:08 2012 From: report at bugs.python.org (Zachary Ware) Date: Thu, 14 Jun 2012 15:19:08 +0000 Subject: [issue15067] sqlite3 docs reference PEP 246, which was rejected Message-ID: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za> New submission from Zachary Ware <zachary.ware at gmail.com>: See: http://hg.python.org/cpython/file/d31e83497c5a/Doc/library/sqlite3.rst#l708 PEP 246 is headed by: """ Rejection Notice I'm rejecting this PEP. Something much better is about to happen; it's too early to say exactly what, but it's not going to resemble the proposal in this PEP too closely so it's better to start a new PEP. GvR. """ I don't know what the "something much better" was/is, so I have no idea how that line in the docs should be replaced, but I don't think the PEP 246 reference is valid. Thanks, Zach ---------- assignee: docs at python components: Documentation messages: 162797 nosy: docs at python, ghaering, zach.ware priority: normal severity: normal status: open title: sqlite3 docs reference PEP 246, which was rejected versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15067> _______________________________________ From report at bugs.python.org Thu Jun 14 17:19:34 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 14 Jun 2012 15:19:34 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin Message-ID: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> New submission from Jason R. Coombs <jaraco at jaraco.com>: I found that fileinput.input() requires two EOF characters to stop reading input on Python 2.7.3 on Windows and Ubuntu: PS C:\Users\jaraco> python Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32 >>> import fileinput >>> lines = list(fileinput.input()) foo bar ^Z ^Z >>> lines ['foo\n', 'bar\n'] I don't see anything in the documentation that suggests that two EOF characters would be required, and I can't think of any reason why that should be the case. ---------- components: Library (Lib) messages: 162798 nosy: jason.coombs priority: normal severity: normal status: open title: fileinput requires two EOF when reading stdin versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 17:23:18 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 14 Jun 2012 15:23:18 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339687398.36.0.48545772407.issue15068@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: I observed if I send EOF as the first character, it honors it immediately and doesn't require a second EOF. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 17:29:07 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Jun 2012 15:29:07 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1339687747.49.0.109847983857.issue14599@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Thanks for the info, Roumen. It looks like there is a single use of MAXPATHLEN still in import.c which I hope to eliminate, so hopefully that will rectify this problem. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14599> _______________________________________ From report at bugs.python.org Thu Jun 14 17:32:15 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Jun 2012 15:32:15 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1339687935.65.0.498183624491.issue15056@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: So sys.dont_write_bytecode is there to prevent bytecode writing but not loading. This is an issue for some systems (e.g. clusters) where there are so many processes running Python that they start to trample each others bytecode files and it leads to malformed data. If you set sys.implementation.cache_tag to None you stop all bytecode usage (reading and writing), and thus is "disabled" entirely, not just for writing. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Thu Jun 14 17:38:50 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 14 Jun 2012 15:38:50 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1339688330.53.0.49091064221.issue15056@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Thu Jun 14 18:07:34 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 16:07:34 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339690054.4.0.585187548431.issue15068@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Frankly I'm surprised it works at all, since fileinput.input() will by default read from stdin, and stdin is in turn being read by the python prompt. I just checked 2.5 on linux, and the same situation exists there (two ^Ds are required to end the input()). I suspect we'll find the explanation in the interaction between the default behavior of fileinput.input() and the interactive prompt. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 18:10:11 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 14 Jun 2012 16:10:11 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1339690211.21.0.482747173597.issue9374@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9374> _______________________________________ From report at bugs.python.org Thu Jun 14 18:10:48 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 14 Jun 2012 16:10:48 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339690248.01.0.629126487298.issue15068@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: FWIW, I encountered the double-EOF behavior when invoking fileinput.input from a script running non-interactively (except of course for the input() call). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 18:22:49 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 14 Jun 2012 16:22:49 +0000 Subject: [issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP) In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za> Message-ID: <1339690969.31.0.904001184405.issue14937@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Thanks, fixed ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14937> _______________________________________ From report at bugs.python.org Thu Jun 14 18:41:07 2012 From: report at bugs.python.org (Pat) Date: Thu, 14 Jun 2012 16:41:07 +0000 Subject: [issue15069] Dictionary Creation Fails with integer key Message-ID: <1339692066.88.0.713985325998.issue15069@psf.upfronthosting.co.za> New submission from Pat <pata at jegcpa.com>: Attempting to import pyserial. In module serialposix.py a dict declaration starting on line 64; baudrate_constants = { 0: 0000000, 50: 0000001, 75: 0000002, 110: 0000003, ...etc Traceback (most recent call last): File "<stdin>", line 1, in <module> File "serialposix.py", line 64 50: 0000001, ^ SyntaxError: invalid token MacOSX 10.6.8 32bit x86 python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:09:56) ---------- assignee: ronaldoussoren components: Macintosh files: serialposix.py messages: 162805 nosy: pata at jegcpa.com, ronaldoussoren priority: normal severity: normal status: open title: Dictionary Creation Fails with integer key type: compile error versions: Python 3.2 Added file: http://bugs.python.org/file26007/serialposix.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15069> _______________________________________ From report at bugs.python.org Thu Jun 14 18:47:49 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 14 Jun 2012 16:47:49 +0000 Subject: [issue15069] Dictionary Creation Fails with integer key In-Reply-To: <1339692066.88.0.713985325998.issue15069@psf.upfronthosting.co.za> Message-ID: <1339692469.21.0.0104094731018.issue15069@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: You are importing with Python3 a module written for Python2. pyserial-2.6 comes with a "setup.py" script that will do the conversion, you should run it and not try to import the source code directly. ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15069> _______________________________________ From report at bugs.python.org Thu Jun 14 18:53:27 2012 From: report at bugs.python.org (Ronan Lamy) Date: Thu, 14 Jun 2012 16:53:27 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339692807.98.0.723832131002.issue12982@psf.upfronthosting.co.za> Ronan Lamy <ronan.lamy at gmail.com> added the comment: Doing it at the interpreter level is trivial (cf. patch), except for an annoying bug I noticed (see below). Doing it from user code might require some care to avoid disrupting existing import hooks, but AFAICT something like sys.path_hooks.append(FileFinder.path_hook(['.pyo', SourcelessFileLoader, True])) is supposed to work. The bug is that -O has currently no effect on sourceless imports: it seems that frozen_importlib actually uses freeze-time __debug__ instead of the current interpreter's. ---------- keywords: +patch Added file: http://bugs.python.org/file26008/issue12982.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Thu Jun 14 19:14:50 2012 From: report at bugs.python.org (Zachary Ware) Date: Thu, 14 Jun 2012 17:14:50 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339694090.52.0.605367217878.issue15068@psf.upfronthosting.co.za> Zachary Ware <zachary.ware at gmail.com> added the comment: I just tested on Python 3.2, and found something interesting; it seems a ^Z character on a line that has other input read in as a character. Also, other input after an EOF on its own means you still have to do two more EOFs to end. Python 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import fileinput >>> lines = list(fileinput.input()) test testing ^Z ^Z >>> lines ['test\n', 'testing\n'] >>> lines = list(fileinput.input()) test testing^Z ^Z ^Z >>> lines ['test\n', 'testing\x1a\n'] >>> lines = list(fileinput.input()) testing^Z test ^Z testing ^Z ^Z >>> lines ['testing\x1a\n', 'test\n', 'testing\n'] Also, the documentation for fileinput doesn't mention EOF at all. ---------- nosy: +zach.ware versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 19:32:58 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 17:32:58 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339695178.0.0.934777416125.issue15068@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I don't know how the EOF character works, but I wouldn't be surprised if it had to be on a line by itself to mean EOF. If the double EOF is required when not at the interactive prompt, then there could be a long standing bug in fileinput's logic where it is doing another read after the last file is closed. Normally this wouldn't even be visible since it would just get EOF again, but when the file is an interactive STDIN, closing it doesn't really close it... ---------- stage: -> needs patch type: -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 19:39:40 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 17:39:40 +0000 Subject: [issue15069] Dictionary Creation Fails with integer key In-Reply-To: <1339692066.88.0.713985325998.issue15069@psf.upfronthosting.co.za> Message-ID: <1339695580.46.0.258110380123.issue15069@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: And yes, a number with leading zeros is an invalid token in Python3, because in Python2 it was an octal number, and now we spell octal as, eg, 0o0001. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15069> _______________________________________ From report at bugs.python.org Thu Jun 14 20:19:05 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 14 Jun 2012 18:19:05 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <1339697945.54.0.942363511274.issue15036@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: The fix seems to be very simple: diff --git a/Lib/mailbox.py b/Lib/mailbox.py index a677729..2be4c83 100644 --- a/Lib/mailbox.py +++ b/Lib/mailbox.py @@ -675,6 +675,7 @@ class _singlefileMailbox(Mailbox): new_file.write(buffer) new_toc[key] = (new_start, new_file.tell()) self._post_message_hook(new_file) + self._file_length = new_file.tell() except: new_file.close() os.remove(new_file.name) I guess all single-file mailboxes have this issue, not only mbox. I'll still need to add tests when I have time. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Thu Jun 14 20:28:29 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 14 Jun 2012 18:28:29 +0000 Subject: [issue15067] sqlite3 docs reference PEP 246, which was rejected In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za> Message-ID: <1339698509.23.0.473699956421.issue15067@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: At the time it referred to generic functions (a la PEP 3124: Overloading, Generic Functions, Interfaces, and Adaptation). However, ultimately it was Abstract Base Classes (PEP 3119) that slid into this space. ---------- nosy: +eric.snow _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15067> _______________________________________ From report at bugs.python.org Thu Jun 14 20:29:39 2012 From: report at bugs.python.org (Jason Tishler) Date: Thu, 14 Jun 2012 18:29:39 +0000 Subject: [issue15047] Cygwin install (regen) problem In-Reply-To: <1339438906.76.0.557865099456.issue15047@psf.upfronthosting.co.za> Message-ID: <1339698579.54.0.172496670459.issue15047@psf.upfronthosting.co.za> Jason Tishler <jason at tishler.net> added the comment: The problem is due to Cygwin's automatic ".exe" extension handling. See the attached patch (i.e., code comment) for the details. Is this patch acceptable? ---------- keywords: +patch stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file26009/3.2.3-extension.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15047> _______________________________________ From report at bugs.python.org Thu Jun 14 20:59:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 Jun 2012 18:59:08 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1339700348.78.0.986876797613.issue12982@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Eric, can you find a place in the current doc where -O and .pyo are mentioned, and where you think a sentence should go. What sentence(s) would you like to see. Other comments: __debug__ is intended to be a process-global compilation value (implemented as a keyword) set on startup >>> __debug__ True >>> __debug__ = False SyntaxError: assignment to keyword The devs are not willing to support having contradictory values in the same process. Indeed, since I posted last night, the pydev discussion has moved to the question of whether -O, __debug__, and .pyo as now defined are worth the nuisance they cause or whether some or all should be deprecated. (Docstring stripping for saving space could then be a separate tool.) --- Python interpreters exist to run Python code. The existence, persistence, and other details of compilation caches are version-dependent implementation details. Being able to execute from such caches without source present is also an implementation detail, and for CPython, it gets secondary support at best. (This is a compromise between full support and no support.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Thu Jun 14 21:05:41 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 14 Jun 2012 19:05:41 +0000 Subject: [issue13841] multiprocessing should use sys.exit() where possible In-Reply-To: <1327345132.43.0.775594933755.issue13841@psf.upfronthosting.co.za> Message-ID: <1339700741.7.0.349892934997.issue13841@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13841> _______________________________________ From report at bugs.python.org Thu Jun 14 21:09:55 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 19:09:55 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339700995.61.0.486892571772.issue15068@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: It is not only the fileinput. The same effect can be achieved by simple idiomatic code: import sys while True: chunk = sys.stdin.read(1000) if not chunk: break # process ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 21:33:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 19:33:50 +0000 Subject: [issue15070] AMD64 debug VS9.0 build doesn't work Message-ID: <1339702430.89.0.525587619926.issue15070@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: When I try to launch the AMD64 debug build: Z:\default>PC\VS9.0\amd64\python_d.exe I get an error box complaining that "python33_d.dll" is missing from my system. Indeed it doesn't seem there: Z:\default>dir PC\VS9.0\amd64\*.dll Volume in drive Z is VBOX_cpython Volume Serial Number is 0000-0805 Directory of Z:\default\PC\VS9.0\amd64 05/16/2012 02:09 PM 3,176,960 python33.dll 05/16/2012 02:08 PM 79,872 python3.dll 2 File(s) 3,256,832 bytes 0 Dir(s) 60,807,380,992 bytes free ---------- components: Build, Windows messages: 162816 nosy: loewis, pitrou, skrah priority: normal severity: normal status: open title: AMD64 debug VS9.0 build doesn't work type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15070> _______________________________________ From report at bugs.python.org Thu Jun 14 21:35:37 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Jun 2012 19:35:37 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339702537.94.0.804791968316.issue15068@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: That makes sense. It is a consequence of (a) buffered input and (b) the fact that EOF on stdin doesn't really close it. (And by interactive here I don't just mean Python's interactive prompt, but also the shell). By default fileinput uses readlines with a buffer size, so it suffers from the same issue. It is only the second time that you close stdin that it gets an empty buffer, and so terminates. Anyone want to try to come up with a doc footnote to explain this? ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 21:40:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 19:40:46 +0000 Subject: [issue15070] VS9.0 build doesn't work In-Reply-To: <1339702430.89.0.525587619926.issue15070@psf.upfronthosting.co.za> Message-ID: <1339702846.9.0.93533779572.issue15070@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Ah, apparently it's a linking error and it doesn't work for release builds either: 1> Creating library Z:\default\PC\VS9.0\\amd64\python33.lib and object Z:\default\PC\VS9.0\\amd64\python33.exp 1>timemodule.obj : error LNK2019: unresolved external symbol _PyNamespace_New referenced in function time_get_clock_info 1>sysmodule.obj : error LNK2001: unresolved external symbol _PyNamespace_New 1>object.obj : error LNK2001: unresolved external symbol _PyNamespace_Type 1>Z:\default\PC\VS9.0\\amd64\\python33.dll : fatal error LNK1120: 2 unresolved externals ---------- priority: normal -> high title: AMD64 debug VS9.0 build doesn't work -> VS9.0 build doesn't work _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15070> _______________________________________ From report at bugs.python.org Thu Jun 14 21:54:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Jun 2012 19:54:23 +0000 Subject: [issue15070] VS9.0 build doesn't work In-Reply-To: <1339702430.89.0.525587619926.issue15070@psf.upfronthosting.co.za> Message-ID: <E1SfG7V-0000l9-OI@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset ccbf6f970943 by Antoine Pitrou in branch 'default': Issue #15070: fix VS9.0 build regression http://hg.python.org/cpython/rev/ccbf6f970943 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15070> _______________________________________ From report at bugs.python.org Thu Jun 14 21:55:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 19:55:07 +0000 Subject: [issue15070] VS9.0 build doesn't work In-Reply-To: <1339702430.89.0.525587619926.issue15070@psf.upfronthosting.co.za> Message-ID: <1339703707.08.0.90896751096.issue15070@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15070> _______________________________________ From report at bugs.python.org Thu Jun 14 22:02:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 20:02:45 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339704165.37.0.0495078898296.issue15068@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Note that in the rare cases, when stdio ends immediately on the limit of the read buffer, just one EOF is sufficient. In particular for read(1) one EOF is sufficient always, and for read(2) it is sufficient in about half of the cases. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 22:18:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 20:18:18 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339705098.34.0.171649011196.issue15068@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: It is unlikely to be solvable at the Python level. Witness the raw stream's behaviour (in Python 3): >>> sys.stdin.buffer.raw.read(1000) If you type a letter followed by ^D (Linux) or ^Z (Windows), this returns immediately: >>> sys.stdin.buffer.raw.read(1000) x^Db'x' But since the result is non-empty, the buffering layer will not detect the EOF and will call read() on the raw stream again (as the 1000 bytes are not satisfied). To signal EOF to the buffered stream, you have to type ^D or ^Z *without preceding it with another character*. Try the following: >>> sys.stdin.buffer.read(1000) You'll see that as long as you type a letter before ^D or ^Z, the read() will not return (until you type more than 1000 characters, that is): - ^D alone: returns! - a letter followed by ^D: doesn't return - a letter followed by ^D followed by ^D: returns! - a letter followed by ^D followed by a letter followed by ^D: doesn't return This is all caused by the fact that a C read() on stdin doesn't return until either the end of line or EOF (or the requested bytes number is satisfied). Just experiment with: >>> os.read(0, 1000) That's why I say this is not solvable at the Python level (except perhaps with bizarre ioctl hackery). ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 22:29:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 20:29:52 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339580270.04.0.117108723999.issue15026@psf.upfronthosting.co.za> Message-ID: <1339705805.6648.25.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: Thank you, Antoine. > 3327 (+360%) 15304 encode utf-16le 'A'*10000 > 3314 (+335%) 14413 encode utf-16le '\x80'*10000 > 3290 (+357%) 15036 encode utf-16be '\x80'+'A'*9999 It must be a fluctuation (-30-40%). For all UCS1 strings the same code is used. > 1598 (-42%) 930 encode utf-16be '\U00010000'*10000 This is most likely the fluctuation too. Code for non-BMP characters is different from the code for other characters in UCS4 string, but unlikely a difference is 1.5x. Reproduced whether this result? On 32-bit Linux, Intel Atom N570 @ 1.66GHz: Py2.7 Py3.2 Py3.3 patched 273 (+229%) 274 (+227%) 333 (+169%) 897 encode utf-16le 'A'*10000 274 (+226%) 275 (+225%) 334 (+168%) 894 encode utf-16le '\x80'*10000 274 (+231%) 275 (+230%) 334 (+172%) 908 encode utf-16le '\x80'+'A'*9999 273 (+752%) 275 (+746%) 276 (+743%) 2326 encode utf-16le '\u0100'*10000 274 (+695%) 275 (+692%) 276 (+689%) 2177 encode utf-16le '\u0100'+'A'*9999 274 (+739%) 275 (+736%) 276 (+733%) 2300 encode utf-16le '\u0100'+'\x80'*9999 274 (+739%) 275 (+736%) 276 (+733%) 2298 encode utf-16le '\u8000'*10000 274 (+697%) 274 (+697%) 276 (+691%) 2184 encode utf-16le '\u8000'+'A'*9999 274 (+741%) 274 (+741%) 277 (+731%) 2303 encode utf-16le '\u8000'+'\x80'*9999 274 (+770%) 275 (+767%) 276 (+764%) 2384 encode utf-16le '\u8000'+'\u0100'*9999 279 (+51%) 279 (+51%) 217 (+94%) 422 encode utf-16le '\U00010000'*10000 274 (+6%) 274 (+6%) 162 (+79%) 290 encode utf-16le '\U00010000'+'A'*9999 274 (+6%) 274 (+6%) 162 (+79%) 290 encode utf-16le '\U00010000'+'\x80'*9999 273 (+5%) 275 (+5%) 162 (+78%) 288 encode utf-16le '\U00010000'+'\u0100'*9999 274 (+5%) 275 (+5%) 162 (+78%) 288 encode utf-16le '\U00010000'+'\u8000'*9999 274 (+152%) 275 (+151%) 334 (+107%) 690 encode utf-16be 'A'*10000 274 (+154%) 275 (+153%) 334 (+109%) 697 encode utf-16be '\x80'*10000 274 (+152%) 275 (+151%) 333 (+108%) 691 encode utf-16be '\x80'+'A'*9999 274 (+146%) 275 (+145%) 276 (+145%) 675 encode utf-16be '\u0100'*10000 274 (+146%) 275 (+145%) 276 (+145%) 675 encode utf-16be '\u0100'+'A'*9999 274 (+145%) 275 (+144%) 276 (+143%) 671 encode utf-16be '\u0100'+'\x80'*9999 274 (+145%) 275 (+144%) 276 (+143%) 672 encode utf-16be '\u8000'*10000 275 (+147%) 275 (+147%) 276 (+146%) 680 encode utf-16be '\u8000'+'A'*9999 274 (+146%) 275 (+145%) 276 (+144%) 674 encode utf-16be '\u8000'+'\x80'*9999 275 (+143%) 275 (+143%) 276 (+142%) 667 encode utf-16be '\u8000'+'\u0100'*9999 279 (+26%) 279 (+26%) 217 (+62%) 351 encode utf-16be '\U00010000'*10000 274 (-2%) 275 (-3%) 162 (+65%) 268 encode utf-16be '\U00010000'+'A'*9999 274 (-2%) 275 (-3%) 162 (+65%) 268 encode utf-16be '\U00010000'+'\x80'*9999 274 (-4%) 275 (-4%) 162 (+63%) 264 encode utf-16be '\U00010000'+'\u0100'*9999 274 (-3%) 275 (-4%) 162 (+64%) 265 encode utf-16be '\U00010000'+'\u8000'*9999 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Thu Jun 14 22:30:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 20:30:12 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1339705823.6648.27.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: On 32-bit Linux, Intel Atom N570 @ 1.66GHz: Py2.7 Py3.2 Py3.3 patched 214 (+718%) 215 (+714%) 363 (+382%) 1750 encode utf-32le 'A'*10000 214 (+704%) 214 (+704%) 362 (+375%) 1720 encode utf-32le '\x80'*10000 214 (+712%) 215 (+708%) 363 (+379%) 1738 encode utf-32le '\x80'+'A'*9999 214 (+698%) 214 (+698%) 342 (+399%) 1707 encode utf-32le '\u0100'*10000 214 (+688%) 215 (+684%) 343 (+392%) 1686 encode utf-32le '\u0100'+'A'*9999 214 (+699%) 215 (+695%) 342 (+400%) 1710 encode utf-32le '\u0100'+'\x80'*9999 214 (+694%) 214 (+694%) 342 (+397%) 1699 encode utf-32le '\u8000'*10000 214 (+688%) 215 (+685%) 343 (+392%) 1687 encode utf-32le '\u8000'+'A'*9999 214 (+700%) 214 (+700%) 342 (+401%) 1713 encode utf-32le '\u8000'+'\x80'*9999 214 (+682%) 215 (+679%) 342 (+389%) 1674 encode utf-32le '\u8000'+'\u0100'*9999 121 (+2237%) 121 (+2237%) 333 (+749%) 2828 encode utf-32le '\U00010000'*10000 214 (+1108%) 214 (+1108%) 333 (+676%) 2585 encode utf-32le '\U00010000'+'A'*9999 214 (+1112%) 214 (+1112%) 333 (+679%) 2594 encode utf-32le '\U00010000'+'\x80'*9999 214 (+1208%) 214 (+1208%) 333 (+741%) 2799 encode utf-32le '\U00010000'+'\u0100'*9999 214 (+1214%) 215 (+1208%) 333 (+745%) 2813 encode utf-32le '\U00010000'+'\u8000'*9999 214 (+556%) 214 (+556%) 363 (+287%) 1404 encode utf-32be 'A'*10000 214 (+558%) 214 (+558%) 363 (+288%) 1408 encode utf-32be '\x80'*10000 214 (+550%) 214 (+550%) 363 (+283%) 1390 encode utf-32be '\x80'+'A'*9999 214 (+224%) 214 (+224%) 342 (+103%) 693 encode utf-32be '\u0100'*10000 214 (+229%) 214 (+229%) 343 (+105%) 703 encode utf-32be '\u0100'+'A'*9999 214 (+221%) 214 (+221%) 342 (+101%) 688 encode utf-32be '\u0100'+'\x80'*9999 214 (+224%) 214 (+224%) 342 (+103%) 694 encode utf-32be '\u8000'*10000 215 (+227%) 214 (+229%) 343 (+105%) 704 encode utf-32be '\u8000'+'A'*9999 214 (+221%) 214 (+221%) 342 (+101%) 686 encode utf-32be '\u8000'+'\x80'*9999 214 (+222%) 214 (+222%) 341 (+102%) 690 encode utf-32be '\u8000'+'\u0100'*9999 121 (+387%) 121 (+387%) 333 (+77%) 589 encode utf-32be '\U00010000'*10000 214 (+174%) 215 (+173%) 333 (+76%) 587 encode utf-32be '\U00010000'+'A'*9999 214 (+183%) 214 (+183%) 333 (+82%) 606 encode utf-32be '\U00010000'+'\x80'*9999 214 (+184%) 214 (+184%) 333 (+82%) 607 encode utf-32be '\U00010000'+'\u0100'*9999 214 (+183%) 214 (+183%) 333 (+82%) 605 encode utf-32be '\U00010000'+'\u8000'*9999 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15027> _______________________________________ From report at bugs.python.org Thu Jun 14 22:34:49 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 14 Jun 2012 20:34:49 +0000 Subject: [issue15070] VS9.0 build doesn't work In-Reply-To: <1339702430.89.0.525587619926.issue15070@psf.upfronthosting.co.za> Message-ID: <1339706089.77.0.850029747243.issue15070@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: The question really remains whether the VS 9 project files should be generated from the VS 2010 ones; this would have resolved this error as well (even though Richard Oudkerk probably wouldn't have run those generators - consequentially, the older project files are still broken). In any case, I still think that breakage of the VS9 build shouldn't have high priority. Instead, contributors really should get a copy of VS 2010 express - they will need it until at least 2015. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15070> _______________________________________ From report at bugs.python.org Thu Jun 14 22:40:12 2012 From: report at bugs.python.org (Daniel C.) Date: Thu, 14 Jun 2012 20:40:12 +0000 Subject: [issue15071] TLS get keys and randoms Message-ID: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za> New submission from Daniel C. <llaniscudani at gmail.com>: I am develop a RADIUS server in 3.2 for WiFi authentication, the EAP-TLS or PEAP auths require a TLS tunnel AND get the master key and the client hello and server hello randoms to generate the MSK, the key to encrypt between WiFi user and WiFi access point. The more necessary is the master key, the randoms is possible extract with "man in the middle" Please, patch ssl. ---------- components: Library (Lib) messages: 162825 nosy: llaniscudani priority: normal severity: normal status: open title: TLS get keys and randoms type: enhancement versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15071> _______________________________________ From report at bugs.python.org Thu Jun 14 22:57:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 20:57:10 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1339707430.72.0.0302203355568.issue14377@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: Added file: http://bugs.python.org/file26010/ElementTree-force_long_tags-v3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14377> _______________________________________ From report at bugs.python.org Thu Jun 14 22:58:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Jun 2012 20:58:26 +0000 Subject: [issue15071] TLS get keys and randoms In-Reply-To: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za> Message-ID: <1339707506.77.0.236916119162.issue15071@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Please elaborate on what you are asking for, and try to make yourself understandable. Also, a good way to see your enhancement request fulfilled is to contribute it yourself; please take a look at the devguide: http://docs.python.org/devguide/ ---------- nosy: +pitrou versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15071> _______________________________________ From report at bugs.python.org Thu Jun 14 22:58:57 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 14 Jun 2012 20:58:57 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339707537.28.0.895673752115.issue15068@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Thu Jun 14 23:00:50 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 14 Jun 2012 21:00:50 +0000 Subject: [issue15071] TLS get keys and randoms In-Reply-To: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za> Message-ID: <1339707650.38.0.75707308588.issue15071@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Daniel: Antoine is absolutely right. About the only way this can happen is if *you* contribute the code. Even if you would make clear what you want (what is a "master key" and the "hello randoms"?), it is likely that still nobody else needs that feature. So without code from you, it will likely not happen. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15071> _______________________________________ From report at bugs.python.org Thu Jun 14 23:13:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 21:13:53 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1339708433.12.0.285677662848.issue14377@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: I don't think that the three new fields in each Element is a suitable price for this very rare used feature. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14377> _______________________________________ From report at bugs.python.org Thu Jun 14 23:20:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 21:20:19 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1338625973.28.0.3126152926.issue14591@psf.upfronthosting.co.za> Message-ID: <1339708833.6648.35.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > The = 0x80000000UL was intentional. The low-order 31 bits of mt[0] don't form part of the state of the Mersenne Twister: the resulting random stream isn't affected by their values. Thanks, I have no more questions. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14591> _______________________________________ From report at bugs.python.org Thu Jun 14 23:24:00 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 21:24:00 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1339709040.03.0.765066194507.issue3665@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Georg, Atsuo, how are you? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3665> _______________________________________ From report at bugs.python.org Thu Jun 14 23:26:35 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Jun 2012 21:26:35 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1339709195.09.0.241391915567.issue10376@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Martin, now the patch is good? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10376> _______________________________________ From report at bugs.python.org Fri Jun 15 00:47:01 2012 From: report at bugs.python.org (William Payne) Date: Thu, 14 Jun 2012 22:47:01 +0000 Subject: [issue15072] Segfault on OSX Message-ID: <1339714020.53.0.331077850595.issue15072@psf.upfronthosting.co.za> New submission from William Payne <wtpayne at gmail.com>: Unfortunately, I cannot provide the source of the script I was running then the crash occurred, so I strongly suspect that this issue will be closed as "cannot reproduce", but I have included the OSX problem report anyway, if it is of any use. :-) The script was running unit-tests & gathering unit-test coverage metrics in a separate process (using subprocess module) when the crash occurred. It was also doing some fairly funky things with dynamic imports which might have had a destabilizing influence. Process: Python [33830] Path: /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86-64 (Native) Parent Process: Python [33825] Date/Time: 2012-06-14 18:31:28.053 -0400 OS Version: Mac OS X 10.7.4 (11E53) Report Version: 9 Interval Since Last Report: 169200 sec Crashes Since Last Report: 1 Per-App Crashes Since Last Report: 1 Anonymous UUID: 81415EC1-2F3C-4A2B-BE73-2AC40EA4A047 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000000000000000d, 0x0000000000000000 VM Regions Near 0: --> __TEXT 0000000109071000-0000000109072000 [ 4K] r-x/rwx SM=COW /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Application Specific Information: objc[33830]: garbage collection is OFF Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.python.python 0x000000010912eeea 0x10907b000 + 737002 1 org.python.python 0x000000010912f61d _PyObject_GC_Malloc + 177 2 org.python.python 0x000000010912f6af _PyObject_GC_New + 21 3 org.python.python 0x00000001090b28b0 PyDict_New + 109 4 org.python.python 0x00000001090b300c PyDict_Copy + 57 5 org.python.python 0x00000001090c9232 0x10907b000 + 320050 6 org.python.python 0x00000001090c7afa 0x10907b000 + 314106 7 org.python.python 0x0000000109082d32 PyObject_Call + 97 8 org.python.python 0x0000000109082eed PyObject_CallFunctionObjArgs + 178 9 org.python.python 0x000000010908dc0e PyClass_New + 462 10 org.python.python 0x000000010908e9f3 0x10907b000 + 80371 11 org.python.python 0x00000001090c7afa 0x10907b000 + 314106 12 org.python.python 0x0000000109082d32 PyObject_Call + 97 13 org.python.python 0x0000000109082eed PyObject_CallFunctionObjArgs + 178 14 org.python.python 0x000000010910076b PyEval_EvalFrameEx + 4121 15 org.python.python 0x0000000109105df7 0x10907b000 + 568823 16 org.python.python 0x0000000109102e0a PyEval_EvalFrameEx + 14008 17 org.python.python 0x0000000109105df7 0x10907b000 + 568823 18 org.python.python 0x0000000109102e0a PyEval_EvalFrameEx + 14008 19 org.python.python 0x0000000109105df7 0x10907b000 + 568823 20 org.python.python 0x0000000109102e0a PyEval_EvalFrameEx + 14008 21 org.python.python 0x0000000109105cd8 PyEval_EvalCodeEx + 1996 22 org.python.python 0x00000001090a3abf 0x10907b000 + 166591 23 org.python.python 0x0000000109082d32 PyObject_Call + 97 24 org.python.python 0x00000001090fec40 PyEval_CallObjectWithKeywords + 180 25 org.python.python 0x00000001090fc552 0x10907b000 + 529746 26 org.python.python 0x0000000109102d77 PyEval_EvalFrameEx + 13861 27 org.python.python 0x0000000109105cd8 PyEval_EvalCodeEx + 1996 28 org.python.python 0x0000000109105e6c 0x10907b000 + 568940 29 org.python.python 0x0000000109102e0a PyEval_EvalFrameEx + 14008 30 org.python.python 0x0000000109105df7 0x10907b000 + 568823 31 org.python.python 0x0000000109102e0a PyEval_EvalFrameEx + 14008 32 org.python.python 0x0000000109105df7 0x10907b000 + 568823 33 org.python.python 0x0000000109102e0a PyEval_EvalFrameEx + 14008 34 org.python.python 0x0000000109105cd8 PyEval_EvalCodeEx + 1996 35 org.python.python 0x0000000109105d4d PyEval_EvalCode + 54 36 org.python.python 0x0000000109113f3a PyImport_ExecCodeModuleEx + 211 37 org.python.python 0x0000000109114482 0x10907b000 + 627842 38 org.python.python 0x0000000109115246 0x10907b000 + 631366 39 org.python.python 0x0000000109115454 0x10907b000 + 631892 40 org.python.python 0x0000000109116201 PyImport_ImportModuleLevel + 1137 41 org.python.python 0x00000001090fa506 0x10907b000 + 521478 42 org.python.python 0x0000000109102d77 PyEval_EvalFrameEx + 13861 43 org.python.python 0x0000000109105cd8 PyEval_EvalCodeEx + 1996 44 org.python.python 0x0000000109105d4d PyEval_EvalCode + 54 45 org.python.python 0x0000000109113f3a PyImport_ExecCodeModuleEx + 211 46 org.python.python 0x0000000109114482 0x10907b000 + 627842 47 org.python.python 0x0000000109114ccd 0x10907b000 + 629965 48 org.python.python 0x0000000109115246 0x10907b000 + 631366 49 org.python.python 0x0000000109115492 0x10907b000 + 631954 50 org.python.python 0x0000000109116201 PyImport_ImportModuleLevel + 1137 51 org.python.python 0x00000001090fa506 0x10907b000 + 521478 52 org.python.python 0x0000000109082d32 PyObject_Call + 97 53 org.python.python 0x00000001090fec40 PyEval_CallObjectWithKeywords + 180 54 org.python.python 0x00000001091048d9 PyEval_EvalFrameEx + 20871 55 org.python.python 0x0000000109105cd8 PyEval_EvalCodeEx + 1996 56 org.python.python 0x0000000109105d4d PyEval_EvalCode + 54 57 org.python.python 0x0000000109113f3a PyImport_ExecCodeModuleEx + 211 58 org.python.python 0x0000000109114482 0x10907b000 + 627842 59 org.python.python 0x0000000109114ccd 0x10907b000 + 629965 60 org.python.python 0x0000000109115246 0x10907b000 + 631366 61 org.python.python 0x0000000109115454 0x10907b000 + 631892 62 org.python.python 0x0000000109116246 PyImport_ImportModuleLevel + 1206 63 org.python.python 0x00000001090fa506 0x10907b000 + 521478 64 org.python.python 0x0000000109082d32 PyObject_Call + 97 65 org.python.python 0x00000001090fec40 PyEval_CallObjectWithKeywords + 180 66 org.python.python 0x00000001091048d9 PyEval_EvalFrameEx + 20871 67 org.python.python 0x0000000109105cd8 PyEval_EvalCodeEx + 1996 68 org.python.python 0x0000000109105d4d PyEval_EvalCode + 54 69 org.python.python 0x0000000109113f3a PyImport_ExecCodeModuleEx + 211 70 org.python.python 0x0000000109114482 0x10907b000 + 627842 71 org.python.python 0x0000000109115246 0x10907b000 + 631366 72 org.python.python 0x00000001091155cc 0x10907b000 + 632268 73 org.python.python 0x000000010911635f PyImport_ImportModuleLevel + 1487 74 org.python.python 0x00000001090fa506 0x10907b000 + 521478 75 org.python.python 0x0000000109082d32 PyObject_Call + 97 76 org.python.python 0x00000001090fec40 PyEval_CallObjectWithKeywords + 180 77 org.python.python 0x00000001091048d9 PyEval_EvalFrameEx + 20871 78 org.python.python 0x0000000109105cd8 PyEval_EvalCodeEx + 1996 79 org.python.python 0x0000000109105d4d PyEval_EvalCode + 54 80 org.python.python 0x000000010911d08f 0x10907b000 + 663695 81 org.python.python 0x000000010911d14f PyRun_FileExFlags + 157 82 org.python.python 0x000000010911e2a2 PyRun_SimpleFileExFlags + 392 83 org.python.python 0x000000010912e2af Py_Main + 2715 84 org.python.python 0x0000000109071e88 0x109071000 + 3720 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x4000000000000000 rbx: 0x00000001091c4ac0 rcx: 0x00000001091c4af0 rdx: 0x00000001091c4ac0 rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x00007fff68c696c0 rsp: 0x00007fff68c69610 r8: 0x0000000000000016 r9: 0x0000000000000dd8 r10: 0x0000000000000000 r11: 0x000000003ae31e7c r12: 0x00000001091b0f30 r13: 0x000000010944bfc8 r14: 0x9000000001093a04 r15: 0x00000001091b0f30 rip: 0x000000010912eeea rfl: 0x0000000000010286 cr2: 0x00007ff4fbcde098 Logical CPU: 2 Binary Images: 0x109071000 - 0x109071fff org.python.python (2.7.1 - 2.7.1) <E2C46621-158F-349B-9131-263E8958B23A> /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python 0x10907b000 - 0x109196ff7 org.python.python (2.7.1 - 2.7.1) <A7E34EB5-24D2-3B8F-A26B-4A5B28CD2C60> /System/Library/Frameworks/Python.framework/Versions/2.7/Python 0x1093c7000 - 0x1093cafff strop.so (??? - ???) <A317730F-EDDF-3998-8A22-0E632B3E67A4> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so 0x10940f000 - 0x109410fff time.so (??? - ???) <DA274462-B33A-33EB-90F7-BB9FB8120A5D> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so 0x109417000 - 0x109419ff7 binascii.so (??? - ???) <9B353DAC-B0E8-3B4B-91A1-50F6F86AA928> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so 0x10941d000 - 0x109428ff7 datetime.so (??? - ???) <9EC1E3BD-3BD3-3B39-AE19-448CCEEA747A> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/datetime.so 0x109431000 - 0x109432fff cStringIO.so (??? - ???) <AE5A2A12-8E57-3FE2-B998-C175083B27F7> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so 0x109477000 - 0x10947dfff pyexpat.so (??? - ???) <0E02E7DD-AC97-38B5-BB3B-856249DEBFF9> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/pyexpat.so 0x7fff68c71000 - 0x7fff68ca5baf dyld (195.6 - ???) <0CD1B35B-A28F-32DA-B72E-452EAD609613> /usr/lib/dyld 0x7fff8bb2e000 - 0x7fff8bba1fff libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib 0x7fff8bc9d000 - 0x7fff8bcdfff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib 0x7fff8c135000 - 0x7fff8c13bff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib 0x7fff8cfef000 - 0x7fff8cffdfff libdispatch.dylib (187.9.0 - compatibility 1.0.0) <1D5BE322-A9B9-3BCE-8FAC-076FB07CF54A> /usr/lib/system/libdispatch.dylib 0x7fff8cffe000 - 0x7fff8d003ff7 libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib 0x7fff8d136000 - 0x7fff8d13bfff libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib 0x7fff8d8c1000 - 0x7fff8d8c2fff libdnsinfo.dylib (395.11.0 - compatibility 1.0.0) <853BAAA5-270F-3FDC-B025-D448DB72E1C3> /usr/lib/system/libdnsinfo.dylib 0x7fff8d921000 - 0x7fff8da05e5f libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <871E688B-CF57-3BC7-80D6-F6476DFF109B> /usr/lib/libobjc.A.dylib 0x7fff8dba7000 - 0x7fff8dba9fff libquarantine.dylib (36.6.0 - compatibility 1.0.0) <0EBF714B-4B69-3E1F-9A7D-6BBC2AACB310> /usr/lib/system/libquarantine.dylib 0x7fff8f4e3000 - 0x7fff8f4e4ff7 libremovefile.dylib (21.1.0 - compatibility 1.0.0) <739E6C83-AA52-3C6C-A680-B37FE2888A04> /usr/lib/system/libremovefile.dylib 0x7fff8f4e5000 - 0x7fff8f6e7fff libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib 0x7fff9017f000 - 0x7fff901acfe7 libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <7BEBB139-50BB-3112-947A-F4AA168F991C> /usr/lib/libSystem.B.dylib 0x7fff902bb000 - 0x7fff90331fff libc++.1.dylib (28.1.0 - compatibility 1.0.0) <DA22E4D6-7F20-3BEA-9B89-2FBA735C2EE1> /usr/lib/libc++.1.dylib 0x7fff90339000 - 0x7fff9050dff7 com.apple.CoreFoundation (6.7.2 - 635.21) <62A3402E-A4E7-391F-AD20-1EF20236CE1B> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff906df000 - 0x7fff906e0fff libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff90b92000 - 0x7fff90b9dff7 libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib 0x7fff90c5b000 - 0x7fff90c65ff7 liblaunch.dylib (392.38.0 - compatibility 1.0.0) <6ECB7F19-B384-32C1-8652-2463C1CF4815> /usr/lib/system/liblaunch.dylib 0x7fff90d26000 - 0x7fff90e03fef libsystem_c.dylib (763.13.0 - compatibility 1.0.0) <41B43515-2806-3FBC-ACF1-A16F35B7E290> /usr/lib/system/libsystem_c.dylib 0x7fff90e04000 - 0x7fff90e0bfff libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib 0x7fff91a32000 - 0x7fff91a36fff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib 0x7fff91f2e000 - 0x7fff91f4efff libsystem_kernel.dylib (1699.26.8 - compatibility 1.0.0) <1DDC0B0F-DB2A-34D6-895D-E5B2B5618946> /usr/lib/system/libsystem_kernel.dylib 0x7fff920d0000 - 0x7fff9211efff libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib 0x7fff93b83000 - 0x7fff93b9efff libexpat.1.dylib (7.2.0 - compatibility 7.0.0) <DDB91E75-A2FA-331F-8069-999127AC6A9D> /usr/lib/libexpat.1.dylib 0x7fff94278000 - 0x7fff9427efff libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib 0x7fff943a9000 - 0x7fff943aafff libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib 0x7fff943b9000 - 0x7fff943f4fff libsystem_info.dylib (??? - ???) <35F90252-2AE1-32C5-8D34-782C614D9639> /usr/lib/system/libsystem_info.dylib 0x7fff9464c000 - 0x7fff9464cfff libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib 0x7fff94a6c000 - 0x7fff94a89fff libxpc.dylib (77.19.0 - compatibility 1.0.0) <9F57891B-D7EF-3050-BEDD-21E7C6668248> /usr/lib/system/libxpc.dylib 0x7fff95187000 - 0x7fff95188ff7 libsystem_sandbox.dylib (??? - ???) <96D38E74-F18F-3CCB-A20B-E8E3ADC4E166> /usr/lib/system/libsystem_sandbox.dylib 0x7fff95189000 - 0x7fff9519bff7 libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib 0x7fff96fe0000 - 0x7fff96fe4fff libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib 0x7fff9705f000 - 0x7fff97068ff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib 0x7fff974cc000 - 0x7fff974cdff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib 0x7fff97edf000 - 0x7fff97ee7fff libsystem_dnssd.dylib (??? - ???) <D9BB1F87-A42B-3CBC-9DC2-FC07FCEF0016> /usr/lib/system/libsystem_dnssd.dylib 0x7fff98489000 - 0x7fff9848efff libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 24138 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=57.8M resident=29.7M(51%) swapped_out_or_unallocated=28.1M(49%) Writable regions: Total=20.6M written=2800K(13%) resident=3796K(18%) swapped_out=0K(0%) unallocated=16.9M(82%) REGION TYPE VIRTUAL =========== ======= MALLOC 12.3M MALLOC guard page 32K STACK GUARD 56.0M Stack 8192K VM_ALLOCATE 4K __DATA 1364K __LINKEDIT 47.9M __TEXT 9.9M __UNICODE 544K shared memory 12K =========== ======= TOTAL 136.0M Model: MacBookPro8,1, BootROM MBP81.0047.B27, 2 processors, Intel Core i7, 2.7 GHz, 8 GB, SMC 1.68f98 Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x029E, 0x434D5341344758334D314131333333433920 Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x029E, 0x434D5341344758334D314131333333433920 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.106.198.4.20) Bluetooth: Version 4.0.5f11, 2 service, 18 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en1 Serial ATA Device: TOSHIBA MK5065GSXF, 500.11 GB Serial ATA Device: HL-DT-ST DVDRW GS31N USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3 USB Device: hub_device, 0x0424 (SMSC), 0x2513, 0xfa100000 / 2 USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfa130000 / 6 USB Device: Natural? Ergonomic Keyboard 4000, 0x045e (Microsoft Corporation), 0x00db, 0xfa133000 / 10 USB Device: Evoluent VerticalMouse 4, 0x1a7c, 0x0191, 0xfa134000 / 9 USB Device: hub_device, 0x0424 (SMSC), 0x2640, 0xfa131000 / 7 USB Device: Ultra Fast Media Reader, 0x0424 (SMSC), 0x4064, 0xfa131100 / 11 USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0252, 0xfa120000 / 5 USB Device: BRCM2070 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000 / 4 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 8 USB Device: hub_device, 0x0424 (SMSC), 0x2513, 0xfd100000 / 2 USB Device: Plugable UGA-2K-A, 0x17e9 (DisplayLink (UK) Ltd.), 0x0378, 0xfd120000 / 4 USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3 ---------- assignee: ronaldoussoren components: Macintosh messages: 162832 nosy: William.Payne, ronaldoussoren priority: normal severity: normal status: open title: Segfault on OSX type: crash versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15072> _______________________________________ From report at bugs.python.org Fri Jun 15 02:01:03 2012 From: report at bugs.python.org (Daniel C.) Date: Fri, 15 Jun 2012 00:01:03 +0000 Subject: [issue15071] TLS get keys and randoms In-Reply-To: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za> Message-ID: <1339718463.86.0.300430892408.issue15071@psf.upfronthosting.co.za> Daniel C. <llaniscudani at gmail.com> added the comment: ok. i try to do the patch! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15071> _______________________________________ From report at bugs.python.org Fri Jun 15 02:02:27 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 15 Jun 2012 00:02:27 +0000 Subject: [issue15072] Segfault on OSX In-Reply-To: <1339714020.53.0.331077850595.issue15072@psf.upfronthosting.co.za> Message-ID: <1339718547.69.0.468182294021.issue15072@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: Sadly enough the crash report is not very helpful for us. Can you reproduce the issue? If so, can you either provide more information by running the programming in a debugger or create a script that reproduces the problem? And as Apple uses a patched version of the official source tree: could you try if the problem also exists if you use the installer on the python.org website? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15072> _______________________________________ From report at bugs.python.org Fri Jun 15 02:05:49 2012 From: report at bugs.python.org (William Payne) Date: Fri, 15 Jun 2012 00:05:49 +0000 Subject: [issue15072] Segfault on OSX In-Reply-To: <1339718547.69.0.468182294021.issue15072@psf.upfronthosting.co.za> Message-ID: <CAMmrq7aO2WOCrn=yCyagpMQcax1QLRnFTH-XYUdxrPVzvsm0vg@mail.gmail.com> William Payne <wtpayne at gmail.com> added the comment: The crash has only occurred once (so far). If it happens a couple more times I will try to reproduce it and send you the script. For now though, I guess the ticket should be closed. I hope I did the right thing in raising a ticket - I thought that it was worth letting people know, even if there is nothing that we can do about it. On 14 June 2012 20:02, Ronald Oussoren <report at bugs.python.org> wrote: > > Ronald Oussoren <ronaldoussoren at mac.com> added the comment: > > Sadly enough the crash report is not very helpful for us. > > Can you reproduce the issue? If so, can you either provide more > information by running the programming in a debugger or create a script > that reproduces the problem? > > And as Apple uses a patched version of the official source tree: could you > try if the problem also exists if you use the installer on the python.orgwebsite? > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue15072> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15072> _______________________________________ From report at bugs.python.org Fri Jun 15 02:08:22 2012 From: report at bugs.python.org (Yaakov (Cygwin Ports)) Date: Fri, 15 Jun 2012 00:08:22 +0000 Subject: [issue15047] Cygwin install (regen) problem In-Reply-To: <1339438906.76.0.557865099456.issue15047@psf.upfronthosting.co.za> Message-ID: <1339718902.15.0.289831868827.issue15047@psf.upfronthosting.co.za> Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment: I use obcaseinsensitive=0, hence I didn't see this. Would that be an option for you? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15047> _______________________________________ From report at bugs.python.org Fri Jun 15 02:14:36 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 15 Jun 2012 00:14:36 +0000 Subject: [issue15072] Segfault on OSX In-Reply-To: <1339714020.53.0.331077850595.issue15072@psf.upfronthosting.co.za> Message-ID: <1339719276.08.0.534649168268.issue15072@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: Letting us know of the problem is fine, in general Python should not crash. But without a way to reproduce the problem it is very hard to do anything about that. There are a number of known issues that can cause crashes, a subset of those can be seen at "Lib/test/crashers/" in the python source tree. (Closing as "works for me" because the issue cannot be reproduced) ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15072> _______________________________________ From report at bugs.python.org Fri Jun 15 03:37:24 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 01:37:24 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339724244.24.0.948516476868.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Maciej, please read http://mjg59.dreamwidth.org/13061.html "Secure" vs "not secure" is not a binary state - it's about making attacks progressively more difficult. Something that is secure against a casual script kiddie scatter gunning attacks on various sites with an automated script won't stand up to a systematic attack from a motivated attacker (also see the reporting on Flame and Stuxnet for what a *really* motivated and well resourced attacker can achieve). The hash randomisation changes didn't make Python completely secure against hashing DoS attacks - it just made them harder, by requiring attackers to figure out the hashing seed for the currently running process first. It's protecting against scatter gun attacks, not targeted ones. Performing a timing attack on Python's default short-circuiting comparison operation is *relatively easy* because the timing variations can be so large (send strings of increasing length until the time stops increasing - now you know the target digest length. Then try various initial characters until the time starts increasing again - now you know the first character. Repeat for the last character, then start with the second character and work through the string. Now you have the target hash, which you can try to crack offline at your leisure. The new comparison function is designed to significantly *reduce* the variance, thus leaking *less* information about the target hash, and making the attack *harder* (albeit, probably still not impossible). I agree with Christian's last two suggestions: change the name to total_compare, and only allow use on byte sequences (where the integer values are certain to be cached). Nothing should ever be called "safe" or "secure" in the standard library, because the immediate question from anyone that knows what they're talking about is "Secure/safe against what level of threat and what kind of threat"? People that *don't* know what they're doing will think "Secure/safe against everything" and that's dangerously misleading. Improving protection against remote timing attacks (e.g. by reducing comparison timing variance to the point where it is small relative to network timing variance) is a *lot* easier than protecting against local timing attacks. Protecting against someone with physical access to the machine hosting the target hash is harder still. Regardless, the target needs to be *improving the status quo*. Being able to tell people "using hmac.total_compare will make you less vulnerable to timing attacks than using ordinary short circuiting comparisons" is a *good thing*. We just need to be careful not to oversell it as making you *immune* to timing attacks. ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 04:38:11 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 15 Jun 2012 02:38:11 +0000 Subject: [issue15066] make install error: ImportError: No module named _struct In-Reply-To: <1339684582.74.0.731857257466.issue15066@psf.upfronthosting.co.za> Message-ID: <1339727891.7.0.383332033076.issue15066@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: I have no experience with opensuse but, from a general unix install install view, the most obvious cause of that message would be a build failure of the _struct extension. Check the log file for messages with _struct in it. You could also try to check the paths and to import it in the build directory: PYTHONPATH=/WORK/suzc/installed/python/lib/python2.7 \ ./python -c 'import sys; print(sys.paths)' PYTHONPATH=/WORK/suzc/installed/python/lib/python2.7 \ ./python -c 'import _struct; print(_struct.__file__)' ---------- nosy: +ned.deily _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15066> _______________________________________ From report at bugs.python.org Fri Jun 15 05:02:52 2012 From: report at bugs.python.org (Sam Whitehead) Date: Fri, 15 Jun 2012 03:02:52 +0000 Subject: [issue232493] UserString can not be used as string in calls to C routines Message-ID: <1339729372.88.0.657576640432.issue232493@psf.upfronthosting.co.za> Sam Whitehead <demon.exh at gmail.com> added the comment: This still seems to be the case in 3.2. Python 3.2.3 (default, Apr 23 2012, 23:35:30) [GCC 4.7.0 20120414 (prerelease)] on linux2 >>> from collections import UserString >>> a = UserString("foooooop") >>> import os.path >>> os.path.exists(a) Traceback (most recent call last): File "<input>", line 1, in <module> File "/usr/lib/python3.2/genericpath.py", line 18, in exists os.stat(path) TypeError: Can't convert 'UserString' object to str implicitly ---------- nosy: +Sam.W _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue232493> _______________________________________ From report at bugs.python.org Fri Jun 15 06:07:51 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Jun 2012 04:07:51 +0000 Subject: [issue14997] IDLE tries to run shell window if line is completed with F5 rather than Enter In-Reply-To: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za> Message-ID: <1339733271.44.0.89480200267.issue14997@psf.upfronthosting.co.za> Changes by Terry J. Reedy <tjreedy at udel.edu>: ---------- nosy: +terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14997> _______________________________________ From report at bugs.python.org Fri Jun 15 06:18:31 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 15 Jun 2012 04:18:31 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1339733911.75.0.611097085468.issue14377@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: Agree with Serhiy. Why are these flags required in Element? Also, I'm moving this to 3.4 since the patch came too late in the 3.3 process - the first beta is very soon, after which we prefer not to add new features. ---------- priority: normal -> low stage: -> patch review versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14377> _______________________________________ From report at bugs.python.org Fri Jun 15 06:48:50 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 15 Jun 2012 04:48:50 +0000 Subject: [issue14035] behavior of test.support.import_fresh_module In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za> Message-ID: <1339735730.85.0.69348125028.issue14035@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: This looks rejected to me. Any opposition to closing the issue? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14035> _______________________________________ From report at bugs.python.org Fri Jun 15 06:49:47 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 15 Jun 2012 04:49:47 +0000 Subject: [issue13988] Expose the C implementation of ElementTree by default when importing ElementTree In-Reply-To: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za> Message-ID: <1339735787.21.0.822590086842.issue13988@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: Note: last traces of Python bootstrap code were removed from _elementtree in changeset 652d148bdc1d ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13988> _______________________________________ From report at bugs.python.org Fri Jun 15 07:53:20 2012 From: report at bugs.python.org (Pavel Fedin) Date: Fri, 15 Jun 2012 05:53:20 +0000 Subject: [issue15073] commands.getoutput() is broken Message-ID: <1339739600.87.0.936564016625.issue15073@psf.upfronthosting.co.za> New submission from Pavel Fedin <p.fedin at samsung.com>: commands.getoutput() is broken on Windows. The issue has been detected in v2.7.2, but still persists in v2.7.3: --- cut --- Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import commands; >>> print commands.getoutput("dir"); '{' is not recognized as an internal or external command, operable program or batch file. >>> --- cut --- The error message comes from cmd.exe. Looks like Python tries to feed native Windows shell with UNIX-style commands sequence in {...}. I believe this is very simple to fix, please take a look at it. Some our internal software croaks because of this. ---------- components: Windows messages: 162844 nosy: p.fedin priority: normal severity: normal status: open title: commands.getoutput() is broken type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15073> _______________________________________ From report at bugs.python.org Fri Jun 15 08:19:45 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 15 Jun 2012 06:19:45 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339724244.24.0.948516476868.issue15061@psf.upfronthosting.co.za> Message-ID: <95A3CDBD-3E66-42F9-B6E4-0790BA20606C@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: > "Secure" vs "not secure" is not a binary state - it's about making attacks progressively more difficult. Something that is secure against a casual script kiddie scatter gunning attacks on various sites with an automated script won't stand up to a systematic attack from a motivated attacker (also see the reporting on Flame and Stuxnet for what a *really* motivated and well resourced attacker can achieve). The problem here is, that _if_ you add a "secure" to the name of a method, it becomes binary. At least in the minds of the users. I know you address that, but that's the main point here. > Regardless, the target needs to be *improving the status quo*. > > Being able to tell people "using hmac.total_compare will make you less vulnerable to timing attacks than using ordinary short circuiting comparisons" is a *good thing*. We just need to be careful not to oversell it as making you *immune* to timing attacks. Why not write a C function which can be more secure than Python code? I would argue that would be an general asset for the stdlib, not just for HMAC (therefore, I'd put it elsewhere). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 08:31:59 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 06:31:59 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339676785.66.0.148848146387.issue15061@psf.upfronthosting.co.za> Message-ID: <4FDAD6DD.7010102@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: On 14.06.2012 14:26, Antoine Pitrou wrote: > > Antoine Pitrou <pitrou at free.fr> added the comment: > >> It's either secure or it's not. > > I don't think that's true. By that reasoning, Python is not secure so > there's no point in fixing crashes or providing a hashlib module. The proper statement is "It's either time-independent or it's not". This *is* a binary state (I agree that being secure is not a binary state). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 08:37:44 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 06:37:44 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339724244.24.0.948516476868.issue15061@psf.upfronthosting.co.za> Message-ID: <4FDAD835.4040003@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Being able to tell people "using hmac.total_compare will make you > less vulnerable to timing attacks than using ordinary short > circuiting comparisons" is a *good thing*. No, it's not. It's a *bad thing*. The two issues that have been opened since the function was first submitted indicate that people will keep inspecting the code and find out that it's not time-independent. If they had been relying on that it is, they will be upset. Since it's inherently impossible to make the function time-independent, people will be constantly annoyed about this function. I can't find anything good in that. If nobody else does, I'll revert the addition before the beta. Note that there is no *actual* issue that is being resolved by this function; it was added only because of its cuteness value. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 08:40:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 06:40:29 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <95A3CDBD-3E66-42F9-B6E4-0790BA20606C@ox.cx> Message-ID: <4FDAD8DC.8020106@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Why not write a C function which can be more secure than Python code? For Unicode strings, it's impossible to write a time-independent comparison function even in C > I would argue that would be an general asset for the stdlib I would argue that it's not. No actual use case for this function has been demonstrated so far. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 08:46:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 06:46:07 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1339742767.73.0.484488026683.issue14377@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: xml.sax.saxutils.XMLGenerator constructor has a parameter short_empty_elements (False by default). For consistency new ElementTree.write parameter must have the same name (True by default for compatibility). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14377> _______________________________________ From report at bugs.python.org Fri Jun 15 09:08:33 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 15 Jun 2012 07:08:33 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <4FDAD8DC.8020106@v.loewis.de> Message-ID: <F432E3FD-4D58-4535-90B9-A3B6C4B978E5@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: >> Why not write a C function which can be more secure than Python code? > For Unicode strings, it's impossible to write a time-independent > comparison function even in C Really? Some comments sounded different. That's too bad but also what I suspected in the first place ? it seems to complex. However, this function seems only useful to bytes anyway so why not strip it down if it _is_ possible with bytes? Am I missing something? >> I would argue that would be an general asset for the stdlib > I would argue that it's not. No actual use case for this function > has been demonstrated so far. Well, one example: https://github.com/mitsuhiko/python-pbkdf2/blob/master/pbkdf2.py and any other place that compares passwords, tokens, ? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:20:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 07:20:50 +0000 Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16) Message-ID: <1339744850.61.0.54515879579.issue1470548@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: The patch updated to reflect Martin's comments. I hope the old behavior now preserved in the most used in practice cases. Tests converted to work with bytes instead of strings. ---------- Added file: http://bugs.python.org/file26011/XMLGenerator-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1470548> _______________________________________ From report at bugs.python.org Fri Jun 15 09:21:34 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 07:21:34 +0000 Subject: [issue14035] behavior of test.support.import_fresh_module In-Reply-To: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za> Message-ID: <1339744894.14.0.671510058538.issue14035@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14035> _______________________________________ From report at bugs.python.org Fri Jun 15 09:28:42 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 07:28:42 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339745322.17.0.324661024268.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Can people please stop raising a false dichotomy and using that as an excuse not to do anything? The decision is not between "leak some information" and "leak no information". It is between "leak more information" and "leak less information". The timing variations with standard comparison are relatively massive and relatively easy to analyse (if the time taken goes up, you got the previous digit correct). With this comparison, they're far more subtle and require much greater analysis to figure out the significance of the timing changes. That reduces the pool of attackers to those capable of performing that analysis (or in possession of tools that will perform that analysis for them). Yes, the docs and name are currently completely unacceptable. But scorched earth is not a good answer, because that just means people will fall back to using "==" which is *even worse* from a security point of view. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:38:49 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 07:38:49 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <F432E3FD-4D58-4535-90B9-A3B6C4B978E5@ox.cx> Message-ID: <4FDAE687.4000104@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Well, one example: > https://github.com/mitsuhiko/python-pbkdf2/blob/master/pbkdf2.py It says that it needs that, but I fail to understand why. pbkdf2 is used to generate encryption keys from passwords, where you don't need to compare strings at all. Instead, you derive a key from the password, and use the key e.g. for AES encryption. If you use pdkdf2 for password hashing, then you do need a comparison function, but it's irrelevant whether that is time-independent. If an attacker was able to determine that his hash brings him close to the actual hash, this is no gain in cracking - since similar hashes do not at all mean that the passwords are similar. > and any other place that compares passwords, tokens, ? No no no. Any sensible place to compare passwords would use some sort of one-way function (password hash) before the comparison, so that someone breaking into the machine will not gain the clear text passwords. As a side effect, timing attacks become futile, since hash functions provide confusion and diffusion, so if a timing attack detects that it found a key that hashes similar to the real key, that doesn't get it any closer to revealing the real key. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:41:32 2012 From: report at bugs.python.org (jsevilleja) Date: Fri, 15 Jun 2012 07:41:32 +0000 Subject: [issue15074] Strange behaviour of python cmd module. (Ignores slash) Message-ID: <1339746092.55.0.309146138832.issue15074@psf.upfronthosting.co.za> New submission from jsevilleja <joel at jsevilleja.org>: I've used the code from here: http://stackoverflow.com/questions/5637124/tab-completion-in-pythons-raw-input/5638688#5638688 and it works. But I've used the same code in a class which inherits from cmd.Cmd, and the code doesn't works. Doing tests, I've noticed that if I do "put /", the argument text from "complete_put" method, skips '/' character. I don't know if this is a bug or my code is wrong, but it works with any other character, and I haven't found anything in the docs. Thanks. ---------- files: shell.py messages: 162854 nosy: jsevilleja priority: normal severity: normal status: open title: Strange behaviour of python cmd module. (Ignores slash) type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26012/shell.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15074> _______________________________________ From report at bugs.python.org Fri Jun 15 09:41:41 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 07:41:41 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339746101.2.0.168012572077.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: To repeat, the specific feature being proposed for retention is: * a function called hmac.total_compare() that is clearly documented as being still vulnerable to timing analysis given a sufficiently sophisticated attacker, while still being more resistant to such analysis than the standard comparison operator * restricting that function to operating on bytes, to eliminate timing variations associated with encoding/decoding of Unicode text and reduce those associated with the calculation of integer values Leaking less information on each comparison is intended to increase the effectiveness of higher level timing attack countermeasures (such as rate limiting and lockouts). Anyone that would use "hmac.total_compare" and call it done is likely using ordinary comparison today (which is even worse). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:45:47 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 07:45:47 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339745322.17.0.324661024268.issue15061@psf.upfronthosting.co.za> Message-ID: <4FDAE828.4090406@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > The timing variations with standard comparison are relatively massive > and relatively easy to analyse (if the time taken goes up, you got > the previous digit correct). If you have an application that is vulnerable to such an attack, you better reconsider your entire approach, rather than using a library function that says it will harden your approach (but may actually not). > Yes, the docs and name are currently completely unacceptable. But > scorched earth is not a good answer, because that just means people > will fall back to using "==" which is *even worse* from a security > point of view. It's not scorched earth. It's the standard procedure for adding features to the standard library. *At a minimum* there needs to be a use case, which has not been demonstrated yet (the OP of the original report thought he had a use case, but then agreed that he was wrong). Then, the use case should be fairly relevant for inclusion in the standard library. I wish there was an AES implementation in the library before we start worrying about stuff like this. Then, ideally, the new library function has been in wide use for some time. This was rushed, and it needs to be reverted. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:47:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 07:47:09 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339746101.2.0.168012572077.issue15061@psf.upfronthosting.co.za> Message-ID: <4FDAE87B.30908@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > To repeat, the specific feature being proposed for retention is: To repeat, no use case has been demonstrated for that function. It has been added because it was fun to write, not because it is useful. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:49:07 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Fri, 15 Jun 2012 07:49:07 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339746101.2.0.168012572077.issue15061@psf.upfronthosting.co.za> Message-ID: <CAK5idxRGQ-aGTWpi78O=OhwFpKpG=UM2+3TrSCDbc70cE=ggVw@mail.gmail.com> Maciej Fijalkowski <fijall at gmail.com> added the comment: On Fri, Jun 15, 2012 at 9:41 AM, Nick Coghlan <report at bugs.python.org>wrote: > > Nick Coghlan <ncoghlan at gmail.com> added the comment: > > To repeat, the specific feature being proposed for retention is: > > * a function called hmac.total_compare() that is clearly documented as > being still vulnerable to timing analysis given a sufficiently > sophisticated attacker, while still being more resistant to such analysis > than the standard comparison operator > > * restricting that function to operating on bytes, to eliminate timing > variations associated with encoding/decoding of Unicode text and reduce > those associated with the calculation of integer values > > Leaking less information on each comparison is intended to increase the > effectiveness of higher level timing attack countermeasures (such as rate > limiting and lockouts). Anyone that would use "hmac.total_compare" and call > it done is likely using ordinary comparison today (which is even worse). > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue15061> > _______________________________________ > Nick, I fail to understand why are you opposing writing such a function in C. Such a function can be provably time-independent (and as MvL says this is a binary state), at least as long as it operates on bytes (I'll refrain from asking about unicode, I think it's possible, but I dunno). For the same function in python it's at the very least much harder to prove (and has bugs as we've seen) Cheers, fijal ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:50:29 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Fri, 15 Jun 2012 07:50:29 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <4FDAE87B.30908@v.loewis.de> Message-ID: <CAK5idxRFPHzdKCx0T+ifYwcwxApHTv35_WGVVK-Ken8AXk17+w@mail.gmail.com> Maciej Fijalkowski <fijall at gmail.com> added the comment: On Fri, Jun 15, 2012 at 9:47 AM, Martin v. L?wis <report at bugs.python.org>wrote: > > Martin v. L?wis <martin at v.loewis.de> added the comment: > > > To repeat, the specific feature being proposed for retention is: > > To repeat, no use case has been demonstrated for that function. It > has been added because it was fun to write, not because it is useful. > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue15061> > _______________________________________ > Is comparing passwords against a secure one not useful? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:55:30 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 15 Jun 2012 07:55:30 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <4FDAE687.4000104@v.loewis.de> Message-ID: <F8C6B640-C4CE-4FDF-8805-D2AD2DA160FF@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: >> and any other place that compares passwords, tokens, ? > > No no no. Any sensible place to compare passwords would use some > sort of one-way function (password hash) before the comparison, > so that someone breaking into the machine will not gain the clear > text passwords. I agree that this is the right way to do. However I disagree that it's also the only sensible way to do in the real world. Sometimes you just _have_ to compare sensitive strings, whether you like it or not. I see your point that adding such a function would leverage bad security behavior and thus may be a bad thing. The usefulness of such a function to some(?) people is IMHO not disputable though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:58:29 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Fri, 15 Jun 2012 07:58:29 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <F8C6B640-C4CE-4FDF-8805-D2AD2DA160FF@ox.cx> Message-ID: <CAK5idxSDwEaEVMPt+3762FHaPaSoFn3=JH2kaDtab16b999qeg@mail.gmail.com> Maciej Fijalkowski <fijall at gmail.com> added the comment: On Fri, Jun 15, 2012 at 9:55 AM, Hynek Schlawack <report at bugs.python.org>wrote: > > Hynek Schlawack <hs at ox.cx> added the comment: > > >> and any other place that compares passwords, tokens, ? > > > > No no no. Any sensible place to compare passwords would use some > > sort of one-way function (password hash) before the comparison, > > so that someone breaking into the machine will not gain the clear > > text passwords. > > I agree that this is the right way to do. However I disagree that it's > also the only sensible way to do in the real world. Sometimes you just > _have_ to compare sensitive strings, whether you like it or not. > > I see your point that adding such a function would leverage bad security > behavior and thus may be a bad thing. The usefulness of such a function to > some(?) people is IMHO not disputable though. > Note that this does not relief you from using a time-independent comparison function. If you call some hash function (which time is known to the attacker), then you compare it against a stored hashed version. If you use a normal compare you're leaking the hash. This is indeed not as bad as leaking the password, but it has been demonstrated that one-direction functions are still vulnerable to some sort of attacks, so it's not ideal either. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 09:59:43 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 07:59:43 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339747183.87.0.718599175898.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: This point was discussed in #14532 when the new API was added. >From http://bugs.python.org/issue14532#msg158045: """Given that this issue has affected a lot of security-sensitive third-party code (keyczar, openid providers, almost every python web service that implements "secure cookies" [1] or other HMAC-based REST API signatures), I do like the idea of adding a warning in the relevant documentation as sbt proposed. The only reason I'd recommend _not_ putting a time_independent_comparison() function in the hmac module is that it's not really HMAC-specific. In practice, any fixed-length secrets should be compared in a time-independent manner. It just happens that HMAC verification is a pretty common case for this vulnerable construct. :-)""" For password hashing, the attacker is unlikely to be able to provide the digest directly, but for signature checking it's far more likely to be the case. The idea is to make it easy for people to reduce the time variance of their digest comparisons as the *default* choice when writing security related code. Deciding whether or not the risk of a timing attack is actually significant requires you to look at the system as a whole and decide "Oh, OK, shortcircuiting comparison doesn't leave us open to timing analysis here, we can use it as a performance enhancement". (Although, in most systems, there are likely to be plenty of other less sensitive places to go after for performance improvements first) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:03:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 08:03:14 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339747394.61.0.682171272685.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I'm not really opposed to writing it in C - I just don't think rewriting it in C should be a requirement for keeping it. Even in pure Python, it still leaks less information than the standard comparison operator. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:03:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 08:03:29 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <CAK5idxRFPHzdKCx0T+ifYwcwxApHTv35_WGVVK-Ken8AXk17+w@mail.gmail.com> Message-ID: <4FDAEC50.9050802@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Is comparing passwords against a secure one not useful? I claim that this use case doesn't occur in practice. Everybody uses hashed passwords. If they do compare against a plain-text password, and they want to change something about it, they should switch to hashed passwords. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:03:36 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 15 Jun 2012 08:03:36 +0000 Subject: [issue14991] Option for regex groupdict() to show only matching names In-Reply-To: <1338742861.24.0.324062376049.issue14991@psf.upfronthosting.co.za> Message-ID: <1339747416.13.0.615201136029.issue14991@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14991> _______________________________________ From report at bugs.python.org Fri Jun 15 10:05:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 15 Jun 2012 08:05:07 +0000 Subject: [issue14998] pprint._safe_key is not always safe enough In-Reply-To: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za> Message-ID: <1339747507.37.0.308190798554.issue14998@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti stage: needs patch -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14998> _______________________________________ From report at bugs.python.org Fri Jun 15 10:06:08 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 08:06:08 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <F8C6B640-C4CE-4FDF-8805-D2AD2DA160FF@ox.cx> Message-ID: <4FDAECEE.5050002@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > I see your point that adding such a function would leverage bad > security behavior and thus may be a bad thing. The usefulness of such > a function to some(?) people is IMHO not disputable though. I think this entire issue is out of scale. There is really bigger fish to fry. The two people who really need this should post a package to PyPI. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:06:10 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 15 Jun 2012 08:06:10 +0000 Subject: [issue15007] Unittest CLI does not support test packages very well In-Reply-To: <1338931229.09.0.80724559879.issue15007@psf.upfronthosting.co.za> Message-ID: <1339747570.62.0.62597424371.issue15007@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15007> _______________________________________ From report at bugs.python.org Fri Jun 15 10:07:34 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 15 Jun 2012 08:07:34 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> Message-ID: <1339747654.99.0.0940996896932.issue15009@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti stage: -> needs patch type: -> behavior versions: +Python 3.3 -Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15009> _______________________________________ From report at bugs.python.org Fri Jun 15 10:08:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 15 Jun 2012 08:08:48 +0000 Subject: [issue15019] String termination on Linux In-Reply-To: <1338994065.34.0.987983176333.issue15019@psf.upfronthosting.co.za> Message-ID: <1339747728.86.0.993301922526.issue15019@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15019> _______________________________________ From report at bugs.python.org Fri Jun 15 10:09:31 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 08:09:31 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <CAK5idxSDwEaEVMPt+3762FHaPaSoFn3=JH2kaDtab16b999qeg@mail.gmail.com> Message-ID: <4FDAEDB9.4090500@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Note that this does not relief you from using a time-independent comparison > function. If you call some hash function (which time is known to the > attacker), then you compare it against a stored hashed version. If you use > a normal compare you're leaking the hash. This is indeed not as bad as > leaking the password, but it has been demonstrated that one-direction > functions are still vulnerable to some sort of attacks, so it's not ideal > either. But you don't leak the hash - you leak the first byte of the hash if you make 256 tries, and the first two bytes if you make 65536 tries. To leak the first four bytes of the hash, you need to make 2**32 tries. So this is equivalent to a brute-force attack, which works just as well against a time-independent function. So using a time-independent function does not add any security. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:09:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 15 Jun 2012 08:09:59 +0000 Subject: [issue15034] tutorial should use best practices in user defined exceptions section In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1339747799.37.0.557833029123.issue15034@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Fri Jun 15 10:12:39 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Fri, 15 Jun 2012 08:12:39 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <4FDAEDB9.4090500@v.loewis.de> Message-ID: <CAK5idxSa8Xw_qDqmBTVhOkQMxoCjuqv=u6eznCVndQkTLnqtfg@mail.gmail.com> Maciej Fijalkowski <fijall at gmail.com> added the comment: On Fri, Jun 15, 2012 at 10:09 AM, Martin v. L?wis <report at bugs.python.org>wrote: > > Martin v. L?wis <martin at v.loewis.de> added the comment: > > > Note that this does not relief you from using a time-independent > comparison > > function. If you call some hash function (which time is known to the > > attacker), then you compare it against a stored hashed version. If you > use > > a normal compare you're leaking the hash. This is indeed not as bad as > > leaking the password, but it has been demonstrated that one-direction > > functions are still vulnerable to some sort of attacks, so it's not ideal > > either. > > But you don't leak the hash - you leak the first byte of the hash if you > make 256 tries, and the first two bytes if you make 65536 tries. To leak > the first four bytes of the hash, you need to make 2**32 tries. > So this is equivalent to a brute-force attack, which works just as well > against a time-independent function. So using a time-independent > function does not add any security. > > ---------- > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue15061> > _______________________________________ > Martin, you fail to understand how this works. You don't do 2**32 tries to leak the 4 charaters, you need 4 * 256, that's why this attack is so bad, because the time needed for the next character is brute force, but then you can move on to the next one. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:13:50 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 08:13:50 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339747183.87.0.718599175898.issue15061@psf.upfronthosting.co.za> Message-ID: <4FDAEEBC.8010207@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > For password hashing, the attacker is unlikely to be able to provide > the digest directly, but for signature checking it's far more likely > to be the case. Can you elaborate? What is the application, where is the digest checking, and what is the threat? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:15:20 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 08:15:20 +0000 Subject: [issue11600] PY_CFLAGS and PY_CPPFLAGS inconsistent In-Reply-To: <1300474039.66.0.607700128709.issue11600@psf.upfronthosting.co.za> Message-ID: <1339748120.46.0.46282142177.issue11600@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: PY_CFLAGS (C compiler flags) always used with PY_CPPFLAGS (C preprocessor flags). The include directories need for #include, so it is logical that PY_CPPFLAGS did contain them. This may be useful if you use C preprocessor without C compiler. I don't think that this is a regression. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11600> _______________________________________ From report at bugs.python.org Fri Jun 15 10:18:05 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 15 Jun 2012 08:18:05 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree Message-ID: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> New submission from Eli Bendersky <eliben at gmail.com>: The XincludeTest test-case in test_xml_etree is now skipped, because it fails in an intermittent manner. I can reproduce the failure when running full regrtest with -j1, but not -j8, and not when run individually. The failure is most likely due to the test itself, in the way it imports the Python ET, leaving _elementtree out. This may be related to http://bugs.python.org/issue14035 ---------- components: Tests messages: 162870 nosy: eli.bendersky, flox priority: normal severity: normal stage: test needed status: open title: XincludeTest failure in test_xml_etree type: crash versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Fri Jun 15 10:18:51 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 08:18:51 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <CAK5idxSa8Xw_qDqmBTVhOkQMxoCjuqv=u6eznCVndQkTLnqtfg@mail.gmail.com> Message-ID: <4FDAEFE7.9090207@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Martin, you fail to understand how this works. You don't do 2**32 tries to > leak the 4 charaters, you need 4 * 256, that's why this attack is so bad, > because the time needed for the next character is brute force, but then you > can move on to the next one. How so? Assume we have a hashed password, and assume we have somehow guessed the first three bytes. How can I then find out the fourth byte in only 256 tries? I would have to generate passwords whose *hash* matches in the first three bytes. This is not feasible, for any hash function that is worth its salt. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:32:49 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 08:32:49 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339749169.68.0.0669673642602.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: That's why the vulnerable cases are far more likely to be related to *signature* checking. In those you can generally provide both the hash input (the message) and the hash target (the purported "signature"). If the signature check uses a time-dependent comparison that exhibits a lot of externally visible variance, then you can use a timing attack to find the signature that corresponds to a particular message (by keeping the message constant and changing the "signature"). Depending on the nature of the message, you're potentially done at that point (since on your final attempt your signed message was accepted), or else you may be after data that you can feed into an analysis aimed at breaking the signing key itself (a much harder prospect, but still possible given a sufficiently large sample, or a signing algorithm that is vulnerable to leaking the key as a result of chosen plaintext attacks). Yes, system level defences are also important (that's why multiprocessing turned out to not, in fact, be vulnerable to an attack based on time dependent signature comparisons), but minimising information leakage is just a good principle of secure design. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:34:31 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 08:34:31 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <1339749271.88.0.542594936884.issue15075@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Fri Jun 15 10:36:30 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 15 Jun 2012 08:36:30 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339749390.16.0.806917032947.issue15061@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: For example, Django uses time independent comparison to compare signatures of signed cookies. A signed cookie consists of a plain-text value followed by a signature. An attacker wants to construct a cookie that has a malformed value and a valid signature for that value. Let's assume that a signature is a string of 16 hex characters. If a short-cut comparison was used, the attacker would require at most 16 tries to find out the first character. He first tries the signature "000...0", then "100...0", and so on until he notices that Django takes a slightly longer time to respond. Now he know what's the first character of the hash, let's assume it's "8". He then tries "8000...0", "810...0", and so on until he finds the second character. He continues this until he has the correct 16 characters. This takes at most 16 * 16 tries. But because Django uses a constant-time comparison function, the attacker cannot guess one character at a time, and he needs 16 ** 16 tries. In real world, 16 * 16 tries is not enough, of course. But repeating the same requests many times, the timing variations can be used to reveal which is the correct character in each step. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:38:48 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 15 Jun 2012 08:38:48 +0000 Subject: [issue15073] commands.getoutput() is broken In-Reply-To: <1339739600.87.0.936564016625.issue15073@psf.upfronthosting.co.za> Message-ID: <1339749528.26.0.667771884439.issue15073@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: The documentation http://docs.python.org/library/commands.html prominently says "Platforms: Unix". This module does not work on Windows. You should really use the subprocess module: >>> import subprocess >>> output = subprocess.check_output("dir", shell=True) ---------- nosy: +amaury.forgeotdarc resolution: -> wont fix status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15073> _______________________________________ From report at bugs.python.org Fri Jun 15 10:42:19 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 08:42:19 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339749739.21.0.659010422263.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: FWIW, Petri's example also explains why leaking the expected length of the string is considered an acceptable optimisation in most reimplementations of this signature check comparison: the attacker is assumed to already know the expected length of the signature, because it's part of a documented protocol or API. However, I think it's more reasonable for a standard library implementation to omit that optimisation by default. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 10:57:38 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 08:57:38 +0000 Subject: [issue12508] Codecs Anomaly In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za> Message-ID: <1339750658.85.0.441307779052.issue12508@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- versions: +Python 2.7, Python 3.3 Added file: http://bugs.python.org/file26013/fffd-2.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12508> _______________________________________ From report at bugs.python.org Fri Jun 15 10:59:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 08:59:19 +0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1339750759.89.0.440970486439.issue1598083@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: It looks like another reason to replace codecs.open on io.open. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1598083> _______________________________________ From report at bugs.python.org Fri Jun 15 11:11:01 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 15 Jun 2012 09:11:01 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339749169.68.0.0669673642602.issue15061@psf.upfronthosting.co.za> Message-ID: <4FDAFC23.3010903@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > That's why the vulnerable cases are far more likely to be related to > *signature* checking. In those you can generally provide both the > hash input (the message) and the hash target (the purported > "signature"). I see. I wonder how feasible this attack is, though, since the signature validation involves a lot of computation (including hashing the original message), of which comparing the signature values is but a tiny step. In addition, for public-key signatures (RSA and DSA), I fail to see the threat. I can verify the signature offline, so I don't need to rely on timing attacks to find out what the correct signature would be. Plus I still need to brute-force the signatures, whether for offline generation, or in the timing attack, because it's *not* the case that the expected signature gets compared with the provided signature. Instead, something derived from the message gets compared with something derived from the purported signature. It's really only HMAC which may be vulnerable. In http://seb.dbzteam.org/crypto/python-oauth-timing-hmac.pdf the author discusses that the real protection against this attack is to fix the actual bugs in the OAuth implementation (when OAuth is designed to prevent replay attacks which would also prevent this attack). In the end, he claims that using time-independent comparison would "add even more security", but in the same hand-waving fashion shown in this issue (i.e. without providing any proof that his proposed attack actually works - which I claim it won't, due to the noise caused by the HMAC generation). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 11:30:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 09:30:48 +0000 Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za> Message-ID: <1339752648.47.0.223479017189.issue5067@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Patch adapted for Python 3.3. Consistently changed messages in C code, docs and docstrings. ---------- components: +Documentation nosy: +storchaka versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 Added file: http://bugs.python.org/file26014/json-messages-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5067> _______________________________________ From report at bugs.python.org Fri Jun 15 11:47:41 2012 From: report at bugs.python.org (Armin Rigo) Date: Fri, 15 Jun 2012 09:47:41 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339753661.45.0.5905270174.issue15061@psf.upfronthosting.co.za> Changes by Armin Rigo <arigo at users.sourceforge.net>: ---------- nosy: -arigo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 11:51:04 2012 From: report at bugs.python.org (Leon Zhang) Date: Fri, 15 Jun 2012 09:51:04 +0000 Subject: [issue15076] Sometimes couldn't import os, shown 'import site' failed, use -v for trackback Message-ID: <1339753863.16.0.615623699476.issue15076@psf.upfronthosting.co.za> New submission from Leon Zhang <leozhang at cisco.com>: Hello Experts, I am using Python 2.6.2 on a Linux machine. I found sometimes I have problem to run my simple python script. ========> Linux version and Python version <======== leonz at fxcsgbu2c1% uname -a SunOS fxcsgbu2c1 5.8 Generic_117350-06 sun4u sparc SUNW,UltraAX-i2 leonz at fxcsgbu2c1% python Python 2.6.2 (r262:71600, Sep 9 2009, 06:36:48) [GCC 3.4.6] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >> ========> Problem description <======== I have one python script file located at "/usr/autoprog/LogUtility/pygen.py", the first 4 lines are: line 1: #!/usr/bin/python line 2: import sys line 3: import os line 4: import traceback If I just run "python /usr/autoprog/LogUtility/pygen.py" from shell, the script always worked fine. We are running another application called "autotest" on this machine, "autotest" will create a new process and launch Python in this new process (/usr/bin/python /usr/autoprog/LogUtility/pygen.py) to run my Python script. Most of the time, the Python script worked fine, but from some time, for some reason, the script suddenty failed, and from this time, if I run autotest to luanch my python script, it always fails, but if I run the python script from shell, it always works fine. If I reboot this machine, both way to run python script works fine. But after some time, run autotest to luanch python script will fail again... Here is the details of the error message of running autotest to luanch python script: 'import site' failed; use -v for traceback Traceback (most recent call last): File "/usr/autoprog/SGBU/LogUtility/pygen.py", line 19, in <module> import os File "/usr/local/lib/python2.6/os.py", line 49, in <module> import posixpath as path File "/usr/local/lib/python2.6/posixpath.py", line 16, in <module> import warnings File "/usr/local/lib/python2.6/warnings.py", line 6, in <module> import linecache ImportError: No module named linecache ========> Some other information may help <======== I had searched "'import site' failed; use -v for traceback" on internet, there are also many other people have this problem, but I didn't see any useful information to fix my problem. Here are some information about the Python on my machine: Install path is /usr/local/lib/python2.6 There is just one "README" file under /usr/local/lib/python2.6/site-packages Attached is the python script file "pygen.py". Could any expert help me on this problem? Appreciate if any experts can reply me. Thanks. ---------- components: Library (Lib) files: pygen.py messages: 162879 nosy: qtld614 priority: normal severity: normal status: open title: Sometimes couldn't import os, shown 'import site' failed, use -v for trackback type: crash versions: Python 2.6 Added file: http://bugs.python.org/file26015/pygen.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15076> _______________________________________ From report at bugs.python.org Fri Jun 15 12:00:22 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 15 Jun 2012 10:00:22 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339754422.02.0.747287512063.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Oh dead god, what have I done ... I threw a small stone and caused a major landslide. :) I'm all with Nick on this topic. A correctly named and documented function provides a tool to users that greatly reduced the change of a side channel attack. It's all about teaching good practice. I also agree that we must neither call it 'secure' nor documented it as 'secure'. I believe the correct term is 'hardened against timing analysis and side channel attacks' I could wrap up a quick C implementation if you like. The operator module is a better place for a total_compare() function. Do you a agree? I recommend that you read/watch Geremy Condra's PyCon talk "Through the Side Channel: Timing and Implementation Attacks in Python". The slides contain timing analysis diagrams. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 12:01:43 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 15 Jun 2012 10:01:43 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <1339754503.73.0.158681141383.issue15075@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: After some tinkering I found which test when run before test_xml_etree causes it to crash: $ ./python -m test.regrtest test___all__ test_xml_etree [1/2] test___all__ [2/2] test_xml_etree Fatal Python error: Segmentation fault Current thread 0x00007f771ecec700: File "/home/eliben/python-src/33/Lib/xml/etree/ElementTree.py", line 895 in _namespaces File "/home/eliben/python-src/33/Lib/xml/etree/ElementTree.py", line 843 in write File "/home/eliben/python-src/33/Lib/test/test_xml_etree.py", line 103 in serialize File "/home/eliben/python-src/33/Lib/test/test_xml_etree.py", line 2020 in test_xinclude_default File "/home/eliben/python-src/33/Lib/unittest/case.py", line 385 in _executeTestPart File "/home/eliben/python-src/33/Lib/unittest/case.py", line 440 in run File "/home/eliben/python-src/33/Lib/unittest/case.py", line 492 in __call__ File "/home/eliben/python-src/33/Lib/unittest/suite.py", line 105 in run File "/home/eliben/python-src/33/Lib/unittest/suite.py", line 67 in __call__ File "/home/eliben/python-src/33/Lib/unittest/suite.py", line 105 in run File "/home/eliben/python-src/33/Lib/unittest/suite.py", line 67 in __call__ File "/home/eliben/python-src/33/Lib/test/support.py", line 1282 in run File "/home/eliben/python-src/33/Lib/test/support.py", line 1383 in _run_suite File "/home/eliben/python-src/33/Lib/test/support.py", line 1417 in run_unittest File "/home/eliben/python-src/33/Lib/test/test_xml_etree.py", line 2311 in test_main File "/home/eliben/python-src/33/Lib/test/regrtest.py", line 1238 in runtest_inner File "/home/eliben/python-src/33/Lib/test/regrtest.py", line 919 in runtest File "/home/eliben/python-src/33/Lib/test/regrtest.py", line 710 in main File "/home/eliben/python-src/33/Lib/test/regrtest.py", line 1829 in <module> File "/home/eliben/python-src/33/Lib/runpy.py", line 75 in _run_code File "/home/eliben/python-src/33/Lib/runpy.py", line 162 in _run_module_as_main Segmentation fault (core dumped) Note that this is the Python test crashing. test_xml_etree_c works fine ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Fri Jun 15 12:31:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 10:31:57 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339754422.02.0.747287512063.issue15061@psf.upfronthosting.co.za> Message-ID: <1339756132.3399.2.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > I could wrap up a quick C implementation if you like. The operator > module is a better place for a total_compare() function. Do you a > agree? I think the function is fine in either hashlib or hmac. Putting it in one of these modules is a hint that it's security-related. On the other hand, linking to it from these modules' documentations is just as fine, if it is put in the operator module. If you make a C implementation, it could also be interesting to cover the pure-ASCII unicode case. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 12:41:10 2012 From: report at bugs.python.org (Moriyoshi Koizumi) Date: Fri, 15 Jun 2012 10:41:10 +0000 Subject: [issue15077] Regexp match goes into infinite loop Message-ID: <1339756870.03.0.464046287951.issue15077@psf.upfronthosting.co.za> New submission from Moriyoshi Koizumi <mozo+python at mozo.jp>: A peculiar pair of a regexp and a target string causes the runtime into an infinite loop. The same expression works with Perl. ---------- components: Regular Expressions files: x.py messages: 162883 nosy: ezio.melotti, moriyoshi, mrabarnett priority: normal severity: normal status: open title: Regexp match goes into infinite loop type: crash versions: Python 2.7 Added file: http://bugs.python.org/file26016/x.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15077> _______________________________________ From report at bugs.python.org Fri Jun 15 12:49:33 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 15 Jun 2012 10:49:33 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <1339757373.55.0.359677850817.issue15075@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: As suspected, the cause is that xinclude_loader manages to somehow import the C version of ET, although test_xml_etree tries to enforce the Python version. This is probably because test___all__ imports all modules and leaves stuff in the import cache. What causes the segfault itself is that C Elements are mixed with Python Elements, and they're incompatible. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Fri Jun 15 12:52:36 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 10:52:36 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339757556.89.0.400384454931.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: As a first step, I'm going to make a change to: 1. Rename the function to "compare_digest" 2. Remove the support for comparing strings 3. Update the documentation to be much clearer about its limitations (including why it's considered OK to leak the expected length of the digest) If a C implemented operator.total_compare is made available, then hmac.compare_digest could be updated to use it (retaining the length shortcircuiting behaviour) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 12:53:38 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 15 Jun 2012 10:53:38 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable Message-ID: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> New submission from Larry Hastings <larry at hastings.org>: As I keep saying on python-dev: I think that the argument list for a function should be stable. If you have a function where some abilities are only available on certain platforms, it's best to always accept default no-op parameters for those parameters, rather than adding and removing parameters based on what functionality is available. os.sendfile() accepts either four or seven parameters, depending on the current platform. However, it's a new function in trunk and therefore has no installed base. So it's not too late to change it. I propose to amend os.sendfile so it always accepts all seven arguments. Its signature would therefore be the following, on all platforms: os.sendfile(out, in, offset, nbytes, headers=None, trailers=None, flags=0) Passing in a non-None value for headers or trailers, or a nonzero value for flags, on a platform where the seven-argument form of sendfile is not available would raise NotImplementedError. ---------- assignee: larry messages: 162886 nosy: larry priority: normal severity: normal status: open title: Change os.sendfile so its arguments are stable type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Fri Jun 15 13:04:50 2012 From: report at bugs.python.org (Erik Cederstrand) Date: Fri, 15 Jun 2012 11:04:50 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1339758290.25.0.22335695846.issue14423@psf.upfronthosting.co.za> Erik Cederstrand <erik at cederstrand.dk> added the comment: I would like to point out that http://bugs.python.org/issue12006 provides a solution (including patches) based on %G%, V and %u directives for use in strptime()/strftime(). These directives are defined in (FreeBSD) libc, and PHP has them, too. I think the strptime approach is a more elegant and standardized way of creating dates from exotic values. ---------- nosy: +Erik Cederstrand _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14423> _______________________________________ From report at bugs.python.org Fri Jun 15 13:14:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 11:14:48 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <E1SfUUJ-0001tU-8d@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset f36af3766a20 by Nick Coghlan in branch 'default': Issue #15061: Don't oversell the capabilities of the new non-shortcircuiting comparison function in hmac http://hg.python.org/cpython/rev/f36af3766a20 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 14:06:35 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 12:06:35 +0000 Subject: [issue14955] hmac.secure_compare() is not time-independent for unicode strings In-Reply-To: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> Message-ID: <1339761995.05.0.517467742615.issue14955@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: As a result of the discussions on #15061, I removed unicode comparison support altogether in f36af3766a20 (updating the warning on the hexdigest() method accordingly). Are folks happy to close this issue on that basis? (I'll raise the question of a separate C implementation on the other issue) ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14955> _______________________________________ From report at bugs.python.org Fri Jun 15 14:12:03 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 15 Jun 2012 12:12:03 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <1339762323.82.0.289108593708.issue15036@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: As I suspected, all single-file mailboxes(mbox, MMDF, Babyl) have this issue. Attached a patch with tests. ---------- keywords: +patch Added file: http://bugs.python.org/file26017/issue15036.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Fri Jun 15 14:16:11 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 12:16:11 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339762571.55.0.30282178743.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: OK, the worst aspects (the misleading name and documentation) have been dealt with, so that leaves the questions of: 1. Avoiding leaking the length information (seems unnecessary, since most digests are part of protocols where they have a known, published length, or you can find out the length by looking at public source code) 2. Providing a C implementation via the operator module (given the restriction to bytes values, and the assumption of caching for all relevant integers, would a C reimplementation really be buying us much additional security?) As far as restoring unicode support (even in a C implementation) goes, I actually don't like the idea. For the general unicode case, as suggested in the updated documentation for hexdigest(), I believe the better approach is to try to stay in the bytes domain as much as possible, and avoid having a Unicode->bytes conversion for the expected value anywhere in the comparison timing path. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 14:21:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 12:21:39 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339762571.55.0.30282178743.issue15061@psf.upfronthosting.co.za> Message-ID: <1339762713.3399.5.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > 2. Providing a C implementation via the operator module (given the > restriction to bytes values, and the assumption of caching for all > relevant integers, would a C reimplementation really be buying us much > additional security?) I like the fact that a C implementation can be audited much more easily. Who knows what kind of effects the Python implementation can trigger, if some optimizations get added in the future. > As far as restoring unicode support (even in a C implementation) goes, > I actually don't like the idea. For the general unicode case, as > suggested in the updated documentation for hexdigest(), I believe the > better approach is to try to stay in the bytes domain as much as > possible, and avoid having a Unicode->bytes conversion for the > expected value anywhere in the comparison timing path. The point of supporting unicode would precisely be to avoid a unicode->bytes conversion when unicode strings are received. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 14:34:17 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 15 Jun 2012 12:34:17 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339762713.3399.5.camel@localhost.localdomain> Message-ID: <4FDB2BC7.20703@cheimes.de> Christian Heimes <lists at cheimes.de> added the comment: Am 15.06.2012 14:21, schrieb Antoine Pitrou: > I like the fact that a C implementation can be audited much more easily. > Who knows what kind of effects the Python implementation can trigger, if > some optimizations get added in the future. Secondly we can predict the function's timing on other implementations of Python. Jython or PyPy might have different settings for small int caching -- or non at all. > The point of supporting unicode would precisely be to avoid a > unicode->bytes conversion when unicode strings are received. A byte-wise comparison of the memory representation would work IFF both sides have the same type and unicode kind. Anything else could give away details of the content. Either: PyBytes_CheckExact(a) && PyBytes_CheckExact(b) or PyUnicode_CheckExact(a) && PyUnicode_CheckExact(b) && PyUnicode_KIND(a) == PyUnicode_KIND(b) I'm not sure about CheckExact, just being paranoid. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 14:38:50 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Jun 2012 12:38:50 +0000 Subject: [issue15073] commands.getoutput() does not work on windows In-Reply-To: <1339739600.87.0.936564016625.issue15073@psf.upfronthosting.co.za> Message-ID: <1339763930.02.0.452499354402.issue15073@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Hmm. Maybe issue 10197 should be reclassified as an enhancement... ---------- nosy: +r.david.murray resolution: wont fix -> duplicate superseder: -> subprocess.getoutput fails on win32 title: commands.getoutput() is broken -> commands.getoutput() does not work on windows _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15073> _______________________________________ From report at bugs.python.org Fri Jun 15 14:53:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 12:53:15 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <4FDB2BC7.20703@cheimes.de> Message-ID: <1339764611.3399.7.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > > The point of supporting unicode would precisely be to avoid a > > unicode->bytes conversion when unicode strings are received. > > A byte-wise comparison of the memory representation would work IFF both > sides have the same type and unicode kind. Anything else could give away > details of the content. My proposal was to only allow them on ASCII strings. Any other unicode kind would raise an error (perhaps NotImplementedError). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 14:55:05 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 12:55:05 +0000 Subject: [issue15077] Regexp match goes into infinite loop In-Reply-To: <1339756870.03.0.464046287951.issue15077@psf.upfronthosting.co.za> Message-ID: <1339764905.78.0.155074062212.issue15077@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: This is not infinite loop. This is O(2**len(prefix_before_first_quote)) computation. Measure times of matching for "INSER(`id`...", "INSERT(`id`...", "INSERT (`id`...", "INSERT I(`id`...", etc. Better use r'''(?:[^`';]+|'(?:''|[^'])*'|`(?:``|[^`])*`)+;''' regexp. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15077> _______________________________________ From report at bugs.python.org Fri Jun 15 14:57:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 12:57:26 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1339765046.17.0.0278204593142.issue15078@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +giampaolo.rodola, neologix _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Fri Jun 15 15:30:42 2012 From: report at bugs.python.org (Pavel Fedin) Date: Fri, 15 Jun 2012 13:30:42 +0000 Subject: [issue15073] commands.getoutput() does not work on windows In-Reply-To: <1339739600.87.0.936564016625.issue15073@psf.upfronthosting.co.za> Message-ID: <1339767042.27.0.95877961383.issue15073@psf.upfronthosting.co.za> Pavel Fedin <p.fedin at samsung.com> added the comment: I see it's deprecated and dropped, but anyway, why not to fix it to work on Windows? From 10197 i see the fix is quite simple, and there is lots of legacy code i believe. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15073> _______________________________________ From report at bugs.python.org Fri Jun 15 15:59:21 2012 From: report at bugs.python.org (Peter Otten) Date: Fri, 15 Jun 2012 13:59:21 +0000 Subject: [issue15074] Strange behaviour of python cmd module. (Ignores slash) In-Reply-To: <1339746092.55.0.309146138832.issue15074@psf.upfronthosting.co.za> Message-ID: <1339768761.56.0.685752852004.issue15074@psf.upfronthosting.co.za> Peter Otten <__peter__ at web.de> added the comment: Not a python bug. You are ommitting an important detail of the stackoverflow example in your code: # we want to treat '/' as part of a word, so override the delimiters readline.set_completer_delims(' \t\n;') Please turn to the Python mailing list if you need more help. ---------- nosy: +peter.otten _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15074> _______________________________________ From report at bugs.python.org Fri Jun 15 16:01:23 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 15 Jun 2012 14:01:23 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339768883.29.0.42666196787.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: (Ah, the dangers of using a real text editor for edit fields. This got rather long, but I think it's all still relevant) I'm persuaded that a C implementation is a good idea in the long run. However, I *don't* think we should rush the design of it. It doesn't seem right to me to be adding a new function to the operator module this close to feature freeze (assuming that's even the right place to add this functionality), so I'd like to close this issue on the basis of my last round of updates, and create a new one aimed at 3.4 to provide a lower level time independent bytes comparison primitive. I have a couple of major reasons for feeling this way: Firstly, the various Python web servers and frameworks have achieved a tolerable level of security through pure Python bytes comparisons that simply avoid short circuiting (sufficent to avoid them getting CVEs raised against them, anyway) Secondly, it seems to me that the proposed lower level feature may make more sense as a bytes method rather than as a function in the operator module. Consider the proposed properties for the lower level security primitive: 1. Handle comparison of bytes objects via C level indexing and xor operations I agree on the value of this part - it makes our implementation easy to audit, and explicitly puts the burden on other implementations to support this as a security primitive. Either approach (bytes method or operator function) would achieve this goal. 2. Only leak length information for one of the supplied arguments under timing analysis. Initially I was thinking a function based implementation of this would be confusing, as it would be quite hard to remember which parameter controlled the perceived length. However, I realised it doesn't actually matter - if controlled by the expected value, then the comparison time appears independent of the input length, and doesn't leak clear timing information on the expected length. If controlled by the input value, then it varies with the input length and still doesn't leak clear information regarding the length of the expected value. However, we can exploit the asymmetry of a method call signature to make it clear that in expected.compare(provided), the time taken for the comparison is dictated by the length of "expected" (or vice-versa - whichever way gets chosen, the asymmetry should help make it easier to remember). In either case, hmac.compare_digest would remain as a simpler "argument order doesn't matter, but the expected length is assumed to be public" API (which, given real world use cases, is actually a reasonable assumption). 3. Handles Unicode objects of the same kind via C level indexing and xor operations I'm still not seeing the point of this. To avoid timing attacks based on encoding your best bet is to do any encoding steps *before* calculating and comparing any signatures (that way the encoding duration is certain to be independent of any secrets involved in the signature verification). The reason the embedded unicode support was problematic was because both the supplied *and* the expected value were being converted to integers during the comparison, and a timing analysis could potentially exploit that to retrieve information about the expected value. The timing vulnerability comes from this sequence: 1. Receive Unicode message, with signature 2. In Unicode, derive expected signature from message 3. Encode expected signature <-- Timing vulnerability here 4. Encode received signature 5. Compare the derived and expected signature The original implementation had this problem, because the repeated calls to ord() were roughly equivalent to encoding the string as UTF-32, only with even bigger timing variations (due to the integer caching behaviour) Compare that with the following sequence, which avoids the problem: 1. Receive Unicode message, with signature 2. Encode the received signature to bytes 3. Encode the message to bytes <-- Cannot expose signature related secrets 4. Derive the expected signature from the encoded message 5. Compare the derived and expected signature Given that crypto primitives are designed to operate on byte sequences *anyway*, the latter approach is likely to be the only one that works regardless of Unicode support (or lack thereof). Really, I think the Unicode support in the initial version of the function was just a mistake, pure and simple - the use of ord() during the iteration is a 2.x backwards compatibility trick for 8-bit strings that isn't applicable in the 3.x standard library. You can see this in the equivalent code in the tornado web server, where the ord() based implementation is invoked to handle Python 2 byte strings, not Unicode text: https://github.com/facebook/tornado/blob/master/tornado/web.py#L2004 4. The operator module is about protocols, this is not a protocol Unlike the other operations in operator, this operation care more about consistency of timing, and the only way of achieving that is through strict type limitations. That's more appropriately handled through a new method on the affected types than it is through a new operator function. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 16:03:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 14:03:11 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1339768992.0.0.492707588514.issue15078@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: I believe, that instead of a integer flags will be better and more portable to use boolean parameters (diskio=True, wait=True, sync=False). All additional parameters should be keyword-only. os.sendfile(out, in, offset, nbytes, *, headers=None, trailers=None, diskio=True, wait=True, sync=False) ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Fri Jun 15 16:04:36 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Fri, 15 Jun 2012 14:04:36 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <1339615898.11.0.574078819362.issue15052@psf.upfronthosting.co.za> Message-ID: <CAGvrs3+SeMAVCc3RM+Z6ns8yphdE7rydo28ZY71ZE8GQejtokg@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: I would suggest trying to build OpenSSL (build_ssl.py) *without* Perl installed. On Windows (7,64-bit at least) a dialog box pops up many times asking which program to use to run XXX.pl. This is using the externals from svn.python.org. ---------- nosy: +jeremy.kloth _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Fri Jun 15 16:17:22 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 15 Jun 2012 14:17:22 +0000 Subject: [issue15019] String termination on Linux In-Reply-To: <1338994065.34.0.987983176333.issue15019@psf.upfronthosting.co.za> Message-ID: <1339769842.12.0.883420342922.issue15019@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: J?nis: > Prints "11 This is not what I get on Linux: I see "11 Hithere:)" because the console chooses to not print the \x00. The character is present in the output stream though. Did you really got a truncated output? How did you run the above script? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15019> _______________________________________ From report at bugs.python.org Fri Jun 15 16:20:34 2012 From: report at bugs.python.org (Joey Geralnik) Date: Fri, 15 Jun 2012 14:20:34 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339770034.92.0.432946035346.issue15068@psf.upfronthosting.co.za> Joey Geralnik <jgeralnik at gmail.com> added the comment: First off, I'm a complete noob looking at the python source code for the first time so forgive me if I've done something wrong. What if the length of the chunk is checked as well? The following code works fine: import sys while True: chunk = sys.stdin.read(1000) if not chunk: break # process if len(chunk) < 1000: break Something similar could be done in the fileinput class. The patch I've attached checks if the number of bytes read from the file is less than the size of the buffer (which means that the file has ended). If so, the next time the file is to be read it skips to the next file instead. joey at j-Laptop:~/cpython$ ./python Python 3.3.0a3+ (default:befd56673c80+, Jun 15 2012, 17:14:12) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import fileinput [73732 refs] >>> lines = list(fileinput.input()) foo bar ^D [73774 refs] >>> lines ['foo\n', 'bar\n'] [73780 refs] ---------- keywords: +patch nosy: +jgeralnik Added file: http://bugs.python.org/file26018/fileinput.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 16:40:49 2012 From: report at bugs.python.org (suzhengchun) Date: Fri, 15 Jun 2012 14:40:49 +0000 Subject: [issue15066] make install error: ImportError: No module named _struct In-Reply-To: <1339684582.74.0.731857257466.issue15066@psf.upfronthosting.co.za> Message-ID: <1339771249.34.0.903010786026.issue15066@psf.upfronthosting.co.za> suzhengchun <suzhengchun at yahoo.com.cn> added the comment: Thank for your attention. I try it: suzc at linux-opensuse:22:02:51:Python-2.7.3$ PYTHONPATH=/WORK/suzc/installed/python/lib/python2.7 ./python -c 'import sys; print(sys.path)' ['', '/WORK/suzc/installed/python/lib/python2.7', '/WORK/suzc/installed/python/lib/python27.zip', '/WORK/suzc/installed/python/lib/python2.7/plat-linux2', '/WORK/suzc/installed/python/lib/python2.7/lib-tk', '/WORK/suzc/installed/python/lib/python2.7/lib-old', '/WORK/suzc/installed/python/lib/python2.7/lib-dynload', '/WORK/suzc/.local/lib/python2.7/site-packages', '/WORK/suzc/installed/python/lib/python2.7/site-packages'] suzc at linux-opensuse:22:03:03:Python-2.7.3$ PYTHONPATH=/WORK/suzc/installed/python/lib/python2.7 \ > ./python -c 'import _struct; print(_struct.__file__)' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named _struct 1 suzc at linux-opensuse:22:03:23:Python-2.7.3$ And I read the log of make, it seems to be compiled OK: ----------------------------------------------------------------- ranlib libpython2.7.a gcc -pthread -Xlinker -export-dynamic -o python \ Modules/python.o \ libpython2.7.a -lpthread -ldl -lutil -lm running build running build_ext building dbm using ndbm building '_struct' extension gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/WORK/suzc/software/Python-2.7.3/Include -I/WORK/suzc/software/Python-2.7.3 -c /WORK/suzc/software/Python-2.7.3/Modules/_struct.c -o build/temp.linux-x86_64-2.7/WORK/suzc/software/Python-2.7.3/Modules/_struct.o gcc -pthread -shared build/temp.linux-x86_64-2.7/WORK/suzc/software/Python-2.7.3/Modules/_struct.o -L/WORK/suzc/installed/python/lib64 -L/usr/local/lib -o build/lib.linux-x86_64-2.7/_struct.so building '_ctypes_test' extension ----------------------------------------------------------------- _struct.o and _struct.so are just there, I truely don't know what's wrong. Newly to Python, I think python should not have such an installation problem. I installed it(2.7.3) on RHEL5, works OK, but I want to install OpenSSL to it, don't know how to do it, so I learn to install it on SUSE in my workplace while RHEL5 is in another place. RHEL5 has python 2.4.2, in my memory. SUSE12 has python 2.7.2. Does system's python affect my installtion? But I think it shouldn't. In fact, long before I downloaded a compressed package named Python-2.7.3.tar.bz2, with this one, I can make && make install, but I can't run it, error is: suzc at linux-opensuse:22:12:31:bin$ ./python2.7 Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] Traceback (most recent call last): File "/WORK/suzc/installed/python/lib/python2.7/site.py", line 564, in <module > main() File "/WORK/suzc/installed/python/lib/python2.7/site.py", line 546, in main known_paths = addusersitepackages(known_paths) File "/WORK/suzc/installed/python/lib/python2.7/site.py", line 279, in adduser sitepackages user_site = getusersitepackages() File "/WORK/suzc/installed/python/lib/python2.7/site.py", line 254, in getuser sitepackages user_base = getuserbase() # this will also set USER_BASE File "/WORK/suzc/installed/python/lib/python2.7/site.py", line 244, in getuser base USER_BASE = get_config_var('userbase') File "/WORK/suzc/installed/python/lib/python2.7/sysconfig.py", line 521, in ge t_config_var return get_config_vars().get(name) File "/WORK/suzc/installed/python/lib/python2.7/sysconfig.py", line 420, in ge t_config_vars _init_posix(_CONFIG_VARS) File "/WORK/suzc/installed/python/lib/python2.7/sysconfig.py", line 288, in _i nit_posix raise IOError(msg) IOError: invalid Python installation: unable to open /WORK/suzc/installed/python /lib/python2.7/config/Makefile (No such file or directory) I'm crazy about this, I search it in google, no satisfatory answers. So I want to download a new one 2.7.3, and install, but i just can not install it. Thanks again. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15066> _______________________________________ From report at bugs.python.org Fri Jun 15 16:41:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 14:41:19 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339770034.92.0.432946035346.issue15068@psf.upfronthosting.co.za> Message-ID: <1339771282.6648.143.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > The patch I've attached checks if the number of bytes read from the file is less than the size of the buffer (which means that the file has ended). >From io.RawIOBase.read docs: """ Read up to n bytes from the object and return them. As a convenience, if n is unspecified or -1, readall() is called. Otherwise, only one system call is ever made. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes. If 0 bytes are returned, and n was not 0, this indicates end of file. """ This is not an arbitrary assumption. In particular, when reading from a terminal with line buffering (you can edit the line until you press Enter) on C level you read only a whole line (if line length is not greater than buffer length) and 0 bytes you will receive only by pressing ^D or ^Z at the beginning of the line. Same for pipes and sockets. On Python level there are many third-party implementations of file-like objects which rely on this behavior, you cannot rewrite all of them. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 16:59:06 2012 From: report at bugs.python.org (Joey Geralnik) Date: Fri, 15 Jun 2012 14:59:06 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339772346.98.0.851965854994.issue15068@psf.upfronthosting.co.za> Joey Geralnik <jgeralnik at gmail.com> added the comment: But this is calling the readlines function, which continually reads from the file until more bytes have been read than the specified argument. >From bz2.readlines: "size can be specified to control the number of lines read: no further lines will be read once the total size of the lines read so far equals or exceeds size." Do other file-like objects interpret this parameter differently? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 17:04:20 2012 From: report at bugs.python.org (Joey Geralnik) Date: Fri, 15 Jun 2012 15:04:20 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339772660.2.0.797575168594.issue15068@psf.upfronthosting.co.za> Joey Geralnik <jgeralnik at gmail.com> added the comment: Forget other filelike objects. The FileInput class only works with actual files, so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 17:23:23 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Jun 2012 15:23:23 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339773803.75.0.437408229764.issue15068@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: fileinput should work (for some definition of work) for anything that can be opened by name using the open syscall on unix. That includes many more things than files. Named pipes are a particularly interesting example in this context. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 17:29:24 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Jun 2012 15:29:24 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339774164.99.0.128917489536.issue15068@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: So the real question is: does readlines block until the byte count is satisified? It might, but the docs for io.IOBase.readlines leave open the possibility that fewer lines will be read, and do not limit that to the EOF case. It's not clear, however, if that is because the non-EOF-short-read case is specifically being allowed for, or if the documenter just didn't consider that case. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 17:32:44 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Jun 2012 15:32:44 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339774364.27.0.293773722729.issue15068@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: The _pyio.py version of readlines does read until the count is equaled or exceeded. This could, however, be an implementation detail and not part of the spec. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 17:40:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 15:40:02 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339771282.6648.143.camel@raxxla> Message-ID: <1339774613.3360.0.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: Le vendredi 15 juin 2012 ? 14:41 +0000, Serhiy Storchaka a ?crit : > >From io.RawIOBase.read docs: > > """ > Read up to n bytes from the object and return them. As a convenience, if > n is unspecified or -1, readall() is called. Otherwise, only one system > call is ever made. Fewer than n bytes may be returned if the operating > system call returns fewer than n bytes. But sys.stdin does not implement RawIOBase, it implements TextIOBase. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 17:44:56 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 15:44:56 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339772660.2.0.797575168594.issue15068@psf.upfronthosting.co.za> Message-ID: <1339775096.6648.163.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Forget other filelike objects. The FileInput class only works with actual files, No. sys.stdin can be reassigned before using FileInput. And FileInput has openhook parameter (for read compressed files or get files from Web, for example). > so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong? qwert 'qwert\n' You type five characters "qwert" end press <Enter>. Python immediately receives these six characters, and returns a result of sys.stdin.readline(1000). Only six characters, and no one symbol more, because more characters you have not entered yet. I believe that for such questions will be more appropriate to use a mailing list (python-list at python.org, or newsgroup gmane.comp.python.general on news://news.gmane.org), and not bugtracker. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 17:46:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 15:46:52 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339775096.6648.163.camel@raxxla> Message-ID: <1339775026.3360.1.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > > so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong? > > qwert > 'qwert\n' > > You type five characters "qwert" end press <Enter>. Python immediately > receives these six characters, and returns a result of > sys.stdin.readline(1000). Well, did you try readline() or readlines()? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 17:48:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 15:48:13 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339768883.29.0.42666196787.issue15061@psf.upfronthosting.co.za> Message-ID: <1339775109.3360.3.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Secondly, it seems to me that the proposed lower level feature may > make more sense as a bytes method rather than as a function in the > operator module. If it's a function, though, it can compare all kinds of buffer-like objects (bytearrays, memoryviews, etc.). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 15 18:12:20 2012 From: report at bugs.python.org (Jon Oberheide) Date: Fri, 15 Jun 2012 16:12:20 +0000 Subject: [issue14955] hmac.secure_compare() is not time-independent for unicode strings In-Reply-To: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> Message-ID: <1339776740.22.0.898992337668.issue14955@psf.upfronthosting.co.za> Jon Oberheide <jon at oberheide.org> added the comment: Sounds good to me, Nick. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14955> _______________________________________ From report at bugs.python.org Fri Jun 15 18:27:03 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 15 Jun 2012 16:27:03 +0000 Subject: [issue15064] multiprocessing should use more context manager In-Reply-To: <1339676025.91.0.9899325094.issue15064@psf.upfronthosting.co.za> Message-ID: <1339777623.24.0.544634614291.issue15064@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15064> _______________________________________ From report at bugs.python.org Fri Jun 15 18:29:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 16:29:44 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339774613.3360.0.camel@localhost.localdomain> Message-ID: <1339775403.6648.166.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > But sys.stdin does not implement RawIOBase, it implements TextIOBase. sys.stdin.buffer.raw implements RawIOBase. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 18:36:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 16:36:13 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339775026.3360.1.camel@localhost.localdomain> Message-ID: <1339778185.2467.2.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > > > > qwert > > 'qwert\n' Oh, it seems that the mail server again ate some lines of my examples. > Well, did you try readline() or readlines()? Yes, it's my mistake, I used readline(). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 18:36:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 16:36:57 +0000 Subject: [issue14904] test_unicode_repr_oflw (in test_bigmem) crashes In-Reply-To: <1337903212.58.0.439916347295.issue14904@psf.upfronthosting.co.za> Message-ID: <E1SfZW3-0001fN-Jz@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 1c9635109079 by Antoine Pitrou in branch '2.7': Skip test_bigmem.test_unicode_repr_oflw, since it crashes (issue #14904). http://hg.python.org/cpython/rev/1c9635109079 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14904> _______________________________________ From report at bugs.python.org Fri Jun 15 18:37:51 2012 From: report at bugs.python.org (Stefan M) Date: Fri, 15 Jun 2012 16:37:51 +0000 Subject: [issue15079] pickle: Possibly misplaced test Message-ID: <1339778270.97.0.949730169084.issue15079@psf.upfronthosting.co.za> New submission from Stefan M <mstefanro at gmail.com>: After issue7455 was fixed, a test was created to reflect the fix (Lib/test/pickletester.py @ AbstractPickleModuleTests.test_bad_input). The test makes sure that an UnpicklingError is raised whenever pickled data attempts to pop on an empty stack. Although tests on AbstractPickleModuleTests normally only run on the C implementation of pickle (on which UnpicklingError is thrown), they may also run on the Python implementation if the C implementation of pickle is not available (which throws IndexError). I'm not sure if it's still reasonable to assume that it's possible for the C implementation of pickle not to exist (the python module does), as I've discovered this by forcefully disabling the C implementation. >>> pickle.Unpickler(io.BytesIO(b'0')).load() _pickle.UnpicklingError: unpickling stack underflow >>> pickle._Unpickler(io.BytesIO(b'0')).load() IndexError: list assignment index out of range The current fix involves adding IndexError to the list of exceptions that may be raised and moving the testcase to AbstractPickleTests (where the tests are ran against both the C and Python impl). As I'm working on improving pickle in protocol v4, it might be worth considering adding more consistency to the exceptions that are being raised by the Python unpickler. ---------- components: Tests files: pickletester.py.patch keywords: patch messages: 162919 nosy: alexandre.vassalotti, collinwinter, mstefanro priority: normal severity: normal status: open title: pickle: Possibly misplaced test type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file26019/pickletester.py.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15079> _______________________________________ From report at bugs.python.org Fri Jun 15 18:38:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 16:38:32 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339778185.2467.2.camel@raxxla> Message-ID: <1339778127.3360.19.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Oh, it seems that the mail server again ate some lines of my examples. This is a bug in the e-mail gateway. You can lobby for a fix at http://psf.upfronthosting.co.za/roundup/meta/issue264 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Fri Jun 15 19:10:29 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Jun 2012 17:10:29 +0000 Subject: [issue15079] pickle: Possibly misplaced test In-Reply-To: <1339778270.97.0.949730169084.issue15079@psf.upfronthosting.co.za> Message-ID: <1339780229.39.0.263489749998.issue15079@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: It would be best to have the pickle tests always run against both the C and python code. We do this for other modules that have C versions of some or all of the Python code. And yes, making the two consistent is also good. Since pickle is generally not used without the C code, making the Python consistent with the C would seem to be a low-impact change. ---------- nosy: +r.david.murray versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15079> _______________________________________ From report at bugs.python.org Fri Jun 15 19:15:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 17:15:58 +0000 Subject: [issue14933] Misleading documentation about weakrefs In-Reply-To: <1338211059.84.0.366871304361.issue14933@psf.upfronthosting.co.za> Message-ID: <E1Sfa7p-0005nR-7h@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 69177ff1a643 by Antoine Pitrou in branch '3.2': Issue #14933: fix misleading doc about weakref support in extension types. http://hg.python.org/cpython/rev/69177ff1a643 New changeset b17c8005e08a by Antoine Pitrou in branch 'default': Issue #14933: fix misleading doc about weakref support in extension types. http://hg.python.org/cpython/rev/b17c8005e08a New changeset 0ac1f90954dc by Antoine Pitrou in branch '2.7': Issue #14933: fix misleading doc about weakref support in extension types. http://hg.python.org/cpython/rev/0ac1f90954dc ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14933> _______________________________________ From report at bugs.python.org Fri Jun 15 19:16:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 17:16:14 +0000 Subject: [issue14933] Misleading documentation about weakrefs In-Reply-To: <1338211059.84.0.366871304361.issue14933@psf.upfronthosting.co.za> Message-ID: <1339780574.05.0.338549138686.issue14933@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14933> _______________________________________ From report at bugs.python.org Fri Jun 15 19:33:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 17:33:08 +0000 Subject: [issue14059] Implement multiprocessing.Barrier In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za> Message-ID: <E1SfaOL-0007XV-IM@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2d2f206d040e by Richard Oudkerk in branch 'default': Issue #14059: Implement multiprocessing.Barrier http://hg.python.org/cpython/rev/2d2f206d040e ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14059> _______________________________________ From report at bugs.python.org Fri Jun 15 19:34:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 17:34:47 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339077374.41.0.500256039615.issue15026@psf.upfronthosting.co.za> Message-ID: <1339781687.69.0.881849198768.issue15026@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Serhiy, the tests crash here in debug mode: $ ./python -m test -v test_unicode == CPython 3.3.0a4+ (default:b17c8005e08a+, Jun 15 2012, 19:28:56) [GCC 4.5.2] == Linux-2.6.38.8-desktop-10.mga-x86_64-with-mandrake-1-Official little-endian == /home/antoine/cpython/default/build/test_python_2567 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_unicode test_formatter_field_name_split (test.test_unicode.StringModuleTest) ... ok test_formatter_parser (test.test_unicode.StringModuleTest) ... ok test___contains__ (test.test_unicode.UnicodeTest) ... ok test_additional_rsplit (test.test_unicode.UnicodeTest) ... ok test_additional_split (test.test_unicode.UnicodeTest) ... ok test_ascii (test.test_unicode.UnicodeTest) ... ok test_aswidechar (test.test_unicode.UnicodeTest) ... ok test_aswidecharstring (test.test_unicode.UnicodeTest) ... ok test_bug1001011 (test.test_unicode.UnicodeTest) ... ok test_bytes_comparison (test.test_unicode.UnicodeTest) ... ok test_capitalize (test.test_unicode.UnicodeTest) ... ok test_casefold (test.test_unicode.UnicodeTest) ... ok test_center (test.test_unicode.UnicodeTest) ... ok test_codecs (test.test_unicode.UnicodeTest) ... python: Objects/unicodeobject.c:5401: _PyUnicode_EncodeUTF16: Assertion `(Py_uintptr_t)(((((((((PyObject*)(v))->ob_type))->tp_flags & ((1L<<27))) != 0)) ? (void) (0) : __assert_fail ("((((((PyObject*)(v))->ob_type))->tp_flags & ((1L<<27))) != 0)", "Objects/unicodeobject.c", 5401, __PRETTY_FUNCTION__)), (((PyBytesObject *)(v))->ob_sval)) & 1 == 0' failed. Fatal Python error: Aborted Current thread 0x00007faa4980e700: File "/home/antoine/cpython/default/Lib/test/test_unicode.py", line 1443 in test_codecs File "/home/antoine/cpython/default/Lib/unittest/case.py", line 385 in _executeTestPart File "/home/antoine/cpython/default/Lib/unittest/case.py", line 440 in run File "/home/antoine/cpython/default/Lib/unittest/case.py", line 492 in __call__ File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 105 in run File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 67 in __call__ File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 105 in run File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 67 in __call__ File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 105 in run File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 67 in __call__ File "/home/antoine/cpython/default/Lib/unittest/runner.py", line 168 in run File "/home/antoine/cpython/default/Lib/test/support.py", line 1383 in _run_suite File "/home/antoine/cpython/default/Lib/test/support.py", line 1417 in run_unittest File "/home/antoine/cpython/default/Lib/test/test_unicode.py", line 1954 in test_main File "/home/antoine/cpython/default/Lib/test/regrtest.py", line 1237 in runtest_inner File "/home/antoine/cpython/default/Lib/test/regrtest.py", line 918 in runtest File "/home/antoine/cpython/default/Lib/test/regrtest.py", line 710 in main File "/home/antoine/cpython/default/Lib/test/__main__.py", line 13 in <module> File "/home/antoine/cpython/default/Lib/runpy.py", line 75 in _run_code File "/home/antoine/cpython/default/Lib/runpy.py", line 162 in _run_module_as_main Abandon ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Fri Jun 15 19:51:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 17:51:10 +0000 Subject: [issue14874] Faster charmap decoding In-Reply-To: <1337638770.26.0.783937266614.issue14874@psf.upfronthosting.co.za> Message-ID: <1339782670.44.0.00733440297016.issue14874@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14874> _______________________________________ From report at bugs.python.org Fri Jun 15 19:57:31 2012 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 15 Jun 2012 17:57:31 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <1339783051.88.0.0225114673056.issue15075@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: Here is a patch that solves the current problem. A longer term solution would be to have a cleaner test plan for ET in general, without monkey-patching at all, and without state that causes test-order dependencies. ---------- keywords: +patch Added file: http://bugs.python.org/file26020/issue15075.1.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Fri Jun 15 20:04:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 18:04:01 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <E1SfasK-0002Vh-D7@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 0add70dd3c43 by Petri Lehtinen in branch '2.7': #15036: Make a repeated changes and flushes work with single-file mailboxes http://hg.python.org/cpython/rev/0add70dd3c43 New changeset 714b8f91f3d4 by Petri Lehtinen in branch '3.2': #15036: Make a repeated changes and flushes work with single-file mailboxes http://hg.python.org/cpython/rev/714b8f91f3d4 New changeset 87d119117560 by Petri Lehtinen in branch 'default': #15036: Make a repeated changes and flushes work with single-file mailboxes http://hg.python.org/cpython/rev/87d119117560 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Fri Jun 15 20:04:36 2012 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Jun 2012 18:04:36 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1339783476.16.0.800934789663.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: Attaching the new version of the patch. Summary: 1. 'is_*' family was replaced with 'Parameter.kind' 2. 'signature()' function was updated to check for '__wrapped__' attribute in all callables 3. 'is_implemented' -> 'implemented' 4. Added support for POSITIONAL_ONLY parameters (in 'bind()') ---------- Added file: http://bugs.python.org/file26021/pep362.3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Fri Jun 15 20:05:30 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 15 Jun 2012 18:05:30 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <1339783530.38.0.210514977531.issue15036@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Fri Jun 15 20:38:55 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Jun 2012 18:38:55 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <1339785535.51.0.170053982828.issue15036@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: The news item isn't completely clear. It sounds like the mailbox is now automatically being flushed between pops, but what you really fixed is popping if the *application* does a flush between them, right? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Fri Jun 15 21:11:40 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 15 Jun 2012 19:11:40 +0000 Subject: [issue15074] Strange behaviour of python cmd module. (Ignores slash) In-Reply-To: <1339746092.55.0.309146138832.issue15074@psf.upfronthosting.co.za> Message-ID: <1339787500.51.0.898774442327.issue15074@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15074> _______________________________________ From report at bugs.python.org Fri Jun 15 21:23:45 2012 From: report at bugs.python.org (Collin Winter) Date: Fri, 15 Jun 2012 19:23:45 +0000 Subject: [issue15079] pickle: Possibly misplaced test In-Reply-To: <1339778270.97.0.949730169084.issue15079@psf.upfronthosting.co.za> Message-ID: <1339788225.79.0.617046497953.issue15079@psf.upfronthosting.co.za> Changes by Collin Winter <collinw at gmail.com>: ---------- nosy: -collinwinter _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15079> _______________________________________ From report at bugs.python.org Fri Jun 15 21:35:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Jun 2012 19:35:13 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339781687.69.0.881849198768.issue15026@psf.upfronthosting.co.za> Message-ID: <1339788915.2467.9.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Serhiy, the tests crash here in debug mode: My fault. It's operator precedence issue in the assert expression. Gcc warns about it: Objects/unicodeobject.c: In function ?_PyUnicode_EncodeUTF16?: Objects/unicodeobject.c:5401: warning: suggest parentheses around comparison in operand of ?&? Here is a fixed patch. ---------- Added file: http://bugs.python.org/file26022/encode-utf16-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ -------------- next part -------------- diff -r 40eeab0f7fc2 Include/unicodeobject.h --- a/Include/unicodeobject.h Fri Jun 15 09:40:44 2012 +0300 +++ b/Include/unicodeobject.h Fri Jun 15 22:27:54 2012 +0300 @@ -188,9 +188,9 @@ (((((Py_UCS4)(high) & 0x03FF) << 10) | \ ((Py_UCS4)(low) & 0x03FF)) + 0x10000) /* high surrogate = top 10 bits added to D800 */ -#define Py_UNICODE_HIGH_SURROGATE(ch) (0xD800 | (((ch) - 0x10000) >> 10)) +#define Py_UNICODE_HIGH_SURROGATE(ch) (0xD800 - (0x10000 >> 10) + ((ch) >> 10)) /* low surrogate = bottom 10 bits added to DC00 */ -#define Py_UNICODE_LOW_SURROGATE(ch) (0xDC00 | (((ch) - 0x10000) & 0x3FF)) +#define Py_UNICODE_LOW_SURROGATE(ch) (0xDC00 + ((ch) & 0x3FF)) /* Check if substring matches at given offset. The offset must be valid, and the substring must not be empty. */ diff -r 40eeab0f7fc2 Objects/stringlib/codecs.h --- a/Objects/stringlib/codecs.h Fri Jun 15 09:40:44 2012 +0300 +++ b/Objects/stringlib/codecs.h Fri Jun 15 22:27:54 2012 +0300 @@ -562,4 +562,68 @@ #undef STRIPPED_MASK #undef SWAB #undef LONG_PTR_MASK + + +Py_LOCAL_INLINE(void) +STRINGLIB(utf16_encode)(unsigned short *out, + const STRINGLIB_CHAR *in, + Py_ssize_t len, + int native_ordering) +{ + const STRINGLIB_CHAR *end = in + len; +#if STRINGLIB_SIZEOF_CHAR == 1 +# define SWAB2(CH) ((CH) << 8) +#else +# define SWAB2(CH) (((CH) << 8) | ((CH) >> 8)) +#endif +#if STRINGLIB_MAX_CHAR < 0x10000 + if (native_ordering) { +# if STRINGLIB_SIZEOF_CHAR == 2 + Py_MEMCPY(out, in, 2 * len); +# else + _PyUnicode_CONVERT_BYTES(STRINGLIB_CHAR, unsigned short, in, end, out); +# endif + } else { + const STRINGLIB_CHAR *unrolled_end = in + (len & ~ (Py_ssize_t) 3); + while (in < unrolled_end) { + out[0] = SWAB2(in[0]); + out[1] = SWAB2(in[1]); + out[2] = SWAB2(in[2]); + out[3] = SWAB2(in[3]); + in += 4; out += 4; + } + while (in < end) { + *out++ = SWAB2(*in); + ++in; + } + } +#else + if (native_ordering) { + while (in < end) { + Py_UCS4 ch = *in++; + if (ch < 0x10000) + *out++ = ch; + else { + out[0] = Py_UNICODE_HIGH_SURROGATE(ch); + out[1] = Py_UNICODE_LOW_SURROGATE(ch); + out += 2; + } + } + } else { + while (in < end) { + Py_UCS4 ch = *in++; + if (ch < 0x10000) + *out++ = SWAB2((Py_UCS2)ch); + else { + Py_UCS2 ch1 = Py_UNICODE_HIGH_SURROGATE(ch); + Py_UCS2 ch2 = Py_UNICODE_LOW_SURROGATE(ch); + out[0] = SWAB2(ch1); + out[1] = SWAB2(ch2); + out += 2; + } + } + } +#endif +#undef SWAB2 +} #endif /* STRINGLIB_IS_UNICODE */ diff -r 40eeab0f7fc2 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jun 15 09:40:44 2012 +0300 +++ b/Objects/unicodeobject.c Fri Jun 15 22:27:54 2012 +0300 @@ -5359,26 +5359,18 @@ const char *errors, int byteorder) { - int kind; - void *data; + enum PyUnicode_Kind kind; + const void *data; Py_ssize_t len; PyObject *v; - unsigned char *p; - Py_ssize_t nsize, bytesize; - Py_ssize_t i, pairs; - /* Offsets from p for storing byte pairs in the right order. */ -#ifdef BYTEORDER_IS_LITTLE_ENDIAN - int ihi = 1, ilo = 0; + unsigned short *out; + Py_ssize_t bytesize; + Py_ssize_t pairs; +#ifdef WORDS_BIGENDIAN + int native_ordering = byteorder >= 0; #else - int ihi = 0, ilo = 1; -#endif - -#define STORECHAR(CH) \ - do { \ - p[ihi] = ((CH) >> 8) & 0xff; \ - p[ilo] = (CH) & 0xff; \ - p += 2; \ - } while(0) + int native_ordering = byteorder <= 0; +#endif if (!PyUnicode_Check(str)) { PyErr_BadArgument(); @@ -5391,53 +5383,47 @@ len = PyUnicode_GET_LENGTH(str); pairs = 0; - if (kind == PyUnicode_4BYTE_KIND) - for (i = 0; i < len; i++) - if (PyUnicode_READ(kind, data, i) >= 0x10000) + if (kind == PyUnicode_4BYTE_KIND) { + const Py_UCS4 *in = (const Py_UCS4 *)data; + const Py_UCS4 *end = in + len; + while (in < end) + if (*in++ >= 0x10000) pairs++; - /* 2 * (len + pairs + (byteorder == 0)) */ - if (len > PY_SSIZE_T_MAX - pairs - (byteorder == 0)) + } + if (len > PY_SSIZE_T_MAX / 2 - pairs - (byteorder == 0)) return PyErr_NoMemory(); - nsize = len + pairs + (byteorder == 0); - bytesize = nsize * 2; - if (bytesize / 2 != nsize) - return PyErr_NoMemory(); + bytesize = (len + pairs + (byteorder == 0)) * 2; v = PyBytes_FromStringAndSize(NULL, bytesize); if (v == NULL) return NULL; - p = (unsigned char *)PyBytes_AS_STRING(v); + /* output buffer is 2-bytes aligned */ + assert(((Py_uintptr_t)PyBytes_AS_STRING(v) & 1) == 0); + out = (unsigned short *)PyBytes_AS_STRING(v); if (byteorder == 0) - STORECHAR(0xFEFF); + *out++ = 0xFEFF; if (len == 0) goto done; - if (byteorder == -1) { - /* force LE */ - ihi = 1; - ilo = 0; - } - else if (byteorder == 1) { - /* force BE */ - ihi = 0; - ilo = 1; - } - - for (i = 0; i < len; i++) { - Py_UCS4 ch = PyUnicode_READ(kind, data, i); - Py_UCS4 ch2 = 0; - if (ch >= 0x10000) { - ch2 = Py_UNICODE_LOW_SURROGATE(ch); - ch = Py_UNICODE_HIGH_SURROGATE(ch); - } - STORECHAR(ch); - if (ch2) - STORECHAR(ch2); + switch (kind) { + case PyUnicode_1BYTE_KIND: { + ucs1lib_utf16_encode(out, (const Py_UCS1 *)data, len, native_ordering); + break; + } + case PyUnicode_2BYTE_KIND: { + ucs2lib_utf16_encode(out, (const Py_UCS2 *)data, len, native_ordering); + break; + } + case PyUnicode_4BYTE_KIND: { + ucs4lib_utf16_encode(out, (const Py_UCS4 *)data, len, native_ordering); + break; + } + default: + assert(0); } done: return v; -#undef STORECHAR } PyObject * From report at bugs.python.org Fri Jun 15 22:18:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 20:18:41 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339077374.41.0.500256039615.issue15026@psf.upfronthosting.co.za> Message-ID: <E1SfcyV-0001sZ-Ex@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset acca141fda80 by Antoine Pitrou in branch 'default': Issue #15026: utf-16 encoding is now significantly faster (up to 10x). http://hg.python.org/cpython/rev/acca141fda80 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Fri Jun 15 22:19:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 20:19:15 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339077374.41.0.500256039615.issue15026@psf.upfronthosting.co.za> Message-ID: <1339791555.4.0.385980132586.issue15026@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Thank you for the quick turnaround! The patch is now pushed in 3.3. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Fri Jun 15 22:20:56 2012 From: report at bugs.python.org (Jeremy Gillick) Date: Fri, 15 Jun 2012 20:20:56 +0000 Subject: [issue15080] Cookie library doesn't parse date properly Message-ID: <1339791656.15.0.174723735856.issue15080@psf.upfronthosting.co.za> New submission from Jeremy Gillick <j_gillick at yahoo.com>: The cookie library doesn't seem to support the standard date format (RFC 822) for the expire property while parsing a cookie. For example, in the Python prompt: >>> import Cookie >>> cookie = Cookie.SimpleCookie('bcookie="123"; Expires=Sat, 14-Jun-2014 23:03:13 GMT;') >>> cookie['bcookie']['expires'] 'Sat,' That is a standard header, but it only processes the date up to the first space. ---------- components: Library (Lib) messages: 162932 nosy: jgillick priority: normal severity: normal status: open title: Cookie library doesn't parse date properly type: behavior versions: Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15080> _______________________________________ From report at bugs.python.org Fri Jun 15 22:21:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Jun 2012 20:21:43 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339077374.41.0.500256039615.issue15026@psf.upfronthosting.co.za> Message-ID: <1339791703.79.0.203453766614.issue15026@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: It would be nice to mention the improvement in the What's New in Python 3.3 doc (Optimizations section). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Fri Jun 15 22:25:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 20:25:26 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339077374.41.0.500256039615.issue15026@psf.upfronthosting.co.za> Message-ID: <E1Sfd5B-0002tE-0I@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 35667fc5f785 by Antoine Pitrou in branch 'default': Mention the UTF-16 encoding speedup in the whatsnew (issue #15026). http://hg.python.org/cpython/rev/35667fc5f785 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Fri Jun 15 22:35:12 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 15 Jun 2012 20:35:12 +0000 Subject: [issue14059] Implement multiprocessing.Barrier In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za> Message-ID: <1339792512.19.0.670047246409.issue14059@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14059> _______________________________________ From report at bugs.python.org Fri Jun 15 22:55:19 2012 From: report at bugs.python.org (Roger Serwy) Date: Fri, 15 Jun 2012 20:55:19 +0000 Subject: [issue15080] Cookie library doesn't parse date properly In-Reply-To: <1339791656.15.0.174723735856.issue15080@psf.upfronthosting.co.za> Message-ID: <1339793719.03.0.336665285002.issue15080@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: 2.6.8 is the latest source-only release of the 2.6 series. Here's what I get: Python 2.6.8 (unknown, Jun 15 2012, 15:51:46) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Cookie >>> cookie = Cookie.SimpleCookie('bcookie="123"; Expires=Sat, 14-Jun-2014 23:03:13 GMT;') >>> cookie['bcookie']['expires'] 'Sat, 14-Jun-2014 23:03:13 GMT' Jeremy, what is the exact version of 2.6 being used? ---------- nosy: +serwy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15080> _______________________________________ From report at bugs.python.org Fri Jun 15 23:09:31 2012 From: report at bugs.python.org (Jeremy Gillick) Date: Fri, 15 Jun 2012 21:09:31 +0000 Subject: [issue15080] Cookie library doesn't parse date properly In-Reply-To: <1339791656.15.0.174723735856.issue15080@psf.upfronthosting.co.za> Message-ID: <1339794571.43.0.24663635008.issue15080@psf.upfronthosting.co.za> Jeremy Gillick <j_gillick at yahoo.com> added the comment: I'm using Python 2.6.1 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15080> _______________________________________ From report at bugs.python.org Fri Jun 15 23:40:43 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 15 Jun 2012 21:40:43 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1339796443.37.0.100194117824.issue15078@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > os.sendfile(out, in, offset, nbytes, *, headers=None, trailers=None, diskio=True, wait=True, sync=False) I probably prefer this. If the original implementers are okay with it then I'd be happy to do it that way. But at the very least I want to get rid of the two function signatures. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Fri Jun 15 23:42:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 Jun 2012 21:42:31 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1339796551.05.0.784344834354.issue15078@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sat Jun 16 01:21:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 23:21:14 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <E1SffpJ-0001F7-7O@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset b92fa1c5a96b by Brett Cannon in branch 'default': Closes issue #14982: Document that pkgutil's walk_packages() and http://hg.python.org/cpython/rev/b92fa1c5a96b ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14982> _______________________________________ From report at bugs.python.org Sat Jun 16 01:22:05 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jun 2012 23:22:05 +0000 Subject: [issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a In-Reply-To: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za> Message-ID: <1339802525.12.0.228131279944.issue14982@psf.upfronthosting.co.za> Changes by Brett Cannon <brett at python.org>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14982> _______________________________________ From report at bugs.python.org Sat Jun 16 01:32:24 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Jun 2012 23:32:24 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1339803144.33.0.322240162725.issue15078@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: > As I keep saying on python-dev: I think that the argument list for a function should be stable. There are some other functions with strange/variable prototype: http://docs.python.org/dev/library/fcntl.html?highlight=ioctl#fcntl.ioctl http://docs.python.org/dev/library/mmap.html?highlight=mmap.mmap#mmap.mmap (and maybe others) These Python functions are thin wrapper of the C function, that's why their prototype can be surprising. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sat Jun 16 01:39:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Jun 2012 23:39:13 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <E1Sfg6i-0002N5-Dz@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 034c814eb187 by Brett Cannon in branch 'default': Issue #13959: Add to imp.find_module() and load_module's docstrings http://hg.python.org/cpython/rev/034c814eb187 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Sat Jun 16 01:41:43 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Jun 2012 23:41:43 +0000 Subject: [issue9247] imp.reload() doesn't take import lock In-Reply-To: <1279028337.95.0.00914211475074.issue9247@psf.upfronthosting.co.za> Message-ID: <1339803703.13.0.867819454325.issue9247@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: We have gone this long without a lock for reload(), I don't see a reason to start caring now. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9247> _______________________________________ From report at bugs.python.org Sat Jun 16 02:01:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jun 2012 00:01:22 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <E1SfgS8-0003yT-ES@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 240b7467e65c by Brett Cannon in branch 'default': Issue #14938: importlib.abc.SourceLoader.is_package() now takes the http://hg.python.org/cpython/rev/240b7467e65c ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14938> _______________________________________ From report at bugs.python.org Sat Jun 16 02:01:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 16 Jun 2012 00:01:40 +0000 Subject: [issue14938] 'import my_pkg.__init__' creates duplicate modules In-Reply-To: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za> Message-ID: <1339804900.9.0.00115953561693.issue14938@psf.upfronthosting.co.za> Changes by Brett Cannon <brett at python.org>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14938> _______________________________________ From report at bugs.python.org Sat Jun 16 02:05:42 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jun 2012 00:05:42 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> Message-ID: <1339805142.32.0.340525698569.issue15006@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Added documentation and simplified changes to python implementation. I think this can go to 3.3. ---------- versions: +Python 3.3 -Python 3.4 Added file: http://bugs.python.org/file26023/issue15006a.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Sat Jun 16 02:07:51 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 16 Jun 2012 00:07:51 +0000 Subject: [issue15081] No documentation for PyState_FindModule() Message-ID: <1339805271.75.0.926484818342.issue15081@psf.upfronthosting.co.za> New submission from Christian Heimes <lists at cheimes.de>: Dear Martin, I can't find any documentation of PyState_FindModule() in the official. According to hg annotate you are the creator of the function. ---------- assignee: loewis components: Documentation messages: 162944 nosy: christian.heimes, loewis priority: low severity: normal status: open title: No documentation for PyState_FindModule() versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15081> _______________________________________ From report at bugs.python.org Sat Jun 16 02:20:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jun 2012 00:20:24 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> Message-ID: <E1SfgkU-00058u-OF@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 8272699973cb by Alexander Belopolsky in branch 'default': Issue #15006: Allow equality comparison between naive and aware time http://hg.python.org/cpython/rev/8272699973cb ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Sat Jun 16 02:21:49 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jun 2012 00:21:49 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> Message-ID: <1339806109.45.0.368528863058.issue15006@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- keywords: -needs review, patch nosy: -Alexander.Belopolsky resolution: -> fixed stage: commit review -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Sat Jun 16 02:22:21 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jun 2012 00:22:21 +0000 Subject: [issue15006] Allow equality comparison between naive and aware datetime objects In-Reply-To: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za> Message-ID: <1339806141.99.0.716975892926.issue15006@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15006> _______________________________________ From report at bugs.python.org Sat Jun 16 02:28:06 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 16 Jun 2012 00:28:06 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1339806486.59.0.930356132675.issue15078@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > There are some other functions with strange/variable prototype: > http://docs.python.org/dev/library/fcntl.html?highlight=ioctl#fcntl.ioctl > http://docs.python.org/dev/library/mmap.html?highlight=mmap.mmap#mmap.mmap It does not follow that this behavior is desirable, or that it should be emulated in new code. There's a lot of legacy code with unexpected API design that would not pass muster were it proposed today. Consider this: what should the Signature (PEP 362) for fcntl.ioctl look like? > These Python functions are thin wrapper of the C function, > that's why their prototype can be surprising. The "thin wrapper" os.sendfile is 130 lines of C. Furthermore I disagree with the idea that os does or should contain "thin wrappers". It strikes me as unbearably provincial thinking among UNIX developers. Anyone who thinks os contains "thin wrappers" should examine the Windows implementation of stat(). But at the heart of the matter, I see no benefit to exposing Python developers to the idiosyncrasies of poor C API design. I feel strongly that one way Python becomes "pythonic" is that it aims for the convenience of the programmer--not the language designer and not the implementer. The Python calling convention is far more flexible than the C calling convention. We should put it to good use here. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sat Jun 16 02:42:45 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 16 Jun 2012 00:42:45 +0000 Subject: [issue13825] Datetime failing while reading active directory time attribute In-Reply-To: <1326982457.08.0.645011585605.issue13825@psf.upfronthosting.co.za> Message-ID: <1339807365.07.0.351630398292.issue13825@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13825> _______________________________________ From report at bugs.python.org Sat Jun 16 03:52:09 2012 From: report at bugs.python.org (George Stephanos) Date: Sat, 16 Jun 2012 01:52:09 +0000 Subject: [issue15082] [httplib] httplib.BadStatusLine on any HTTPS connection in certain unknown cases. Message-ID: <1339811528.79.0.0690651710917.issue15082@psf.upfronthosting.co.za> New submission from George Stephanos <gaf.stephanos at gmail.com>: When trying to POST /anything/ @ https://grooveshark.com/, I get an httplib.BadStatusLine exception (server returns nothing at all. It's a timeout since it waits a while). The many Grooveshark webclients however works perfectly, along with a curl command (run through cygwin, commented out in the script) that does the exact same. Meaning this weird behavior is exclusive to Python. This issue was found to be present on many Windows systems. However, not all (all the systems have Python 2.7.2). I'm not sure what the difference is, and I'm not sure if this is a Python bug, but this is the only place I could think of to discuss the behavior. The only Linux system I've tested this on worked (again, Python 2.7.2). Note: If it fails on one system, it never succeeds no matter how much you try. The code *used* to work yesterday and it's been working for many months. Grooveshark might have changed something but this doesn't make any sense since curl works. Please try to reproduce this. I can provide any testing details needed. A script containing the code to test with is attached, along with the curl line and a BadStatusLine traceback. Excuse my complete ignorance on the inner workings of SSL and my weak English skills (second language). ---------- components: Windows files: ssltest.py messages: 162947 nosy: jtr51 priority: normal severity: normal status: open title: [httplib] httplib.BadStatusLine on any HTTPS connection in certain unknown cases. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26024/ssltest.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15082> _______________________________________ From report at bugs.python.org Sat Jun 16 04:33:07 2012 From: report at bugs.python.org (Ariel Poliak) Date: Sat, 16 Jun 2012 02:33:07 +0000 Subject: [issue14377] Modify serializer for xml.etree.ElementTree to allow forcing the use of long tag closing In-Reply-To: <1332305186.87.0.484792091693.issue14377@psf.upfronthosting.co.za> Message-ID: <1339813987.36.0.260815024318.issue14377@psf.upfronthosting.co.za> Ariel Poliak <apoliak at gmail.com> added the comment: Ideally, this would be taken care by the _serialize_xml() with a parameter specified when called from within write(). However, the signature for the _serialize_xml() function cannot be changed, as it needs to match the signature for the rest of the _serialize_*() functions (since which serializing function is chosen from a dictionary that then calls the specific function using the same parameters. An alternative to this would be to create a single variable within the scope of ElementTree at runtime if the code calls to write out the full tags closing, and have the _serialize_xml() function check for the presence and value of that variable. I initially approached the problem via the flags on Element instead due to the perceived usefulness of giving the programmer full control on how the tree is serialized into XML. However, if I'm the only one that sees that as useful, I can certainly refactor the code to go with the above solution (or some other more elegant solution). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14377> _______________________________________ From report at bugs.python.org Sat Jun 16 05:05:32 2012 From: report at bugs.python.org (Jon Oberheide) Date: Sat, 16 Jun 2012 03:05:32 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339815932.05.0.807427233052.issue15061@psf.upfronthosting.co.za> Jon Oberheide <jon at oberheide.org> added the comment: Wow, that escalated quickly. :-) Nick, thanks for keeping things focused and on track. To recap, the primary motivation here is two-fold. First, folks are using == pretty frequently in an unsafe manner when comparing digests, signatures, and other fixed-length strings. This is not good. Second, as we've seen in this thread and elsewhere, getting this right is not easy. Which is the exact reason it belongs in python's stdlib, so that folks do not try to implement it themselves incorrectly. And again, preventing the leakage of the length of the inputs is not an intended goal here for this use case. It'd be best to keep things as simple as possible while achieving the desired security objective. ---------- nosy: +Jon.Oberheide _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 16 05:16:29 2012 From: report at bugs.python.org (Jon Oberheide) Date: Sat, 16 Jun 2012 03:16:29 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1339816589.81.0.485383642579.issue15061@psf.upfronthosting.co.za> Jon Oberheide <jon at oberheide.org> added the comment: On a side note, it may be useful to follow the conventions that already exist in OpenBSD for their timingsafe_bcmp(3): http://www.rootr.net/man/man/timingsafe_bcmp/3 "timingsafe" may be a more reasonable naming convention that is a bit less strong the "secure" which may be more appropriate. Also, the implementation does leak the length of the string (well, actually you provide the length "n", but in real-world usage "n" is the static length of the expected input): ftp://ftp.fr.openbsd.org/pub/OpenBSD/src/lib/libc/string/timingsafe_bcmp.c ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 16 05:49:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jun 2012 03:49:34 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <E1Sfk0y-0000mV-Ee@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 5782efaa8d68 by Eli Bendersky in branch 'default': Make the test more resilient to test-run order (closes #15075) http://hg.python.org/cpython/rev/5782efaa8d68 ---------- nosy: +python-dev resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Sat Jun 16 05:52:39 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 16 Jun 2012 03:52:39 +0000 Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way Message-ID: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za> New submission from Eli Bendersky <eliben at gmail.com>: As #15075 demonstrated, the ET tests are sensitive to execution order because of the way they operate. Two sets of tests (one for the C module and one for the pure Python module) operate from the same test code, monkey-patching the imported module. This sometimes breaks. A more robust solution is needed that is completely deterministic and does not rely on import artifacts. ---------- assignee: eli.bendersky components: Tests messages: 162952 nosy: eli.bendersky, flox, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Rewrite ElementTree tests in a cleaner and safer way type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15083> _______________________________________ From report at bugs.python.org Sat Jun 16 05:53:17 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 16 Jun 2012 03:53:17 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <1339818797.04.0.702033496649.issue15075@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: Opened #15083 to track the *actual* solution to this problem, which should restructure the tests to be safer. ---------- superseder: -> Rewrite ElementTree tests in a cleaner and safer way _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Sat Jun 16 08:06:58 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 16 Jun 2012 06:06:58 +0000 Subject: [issue15081] No documentation for PyState_FindModule() In-Reply-To: <1339805271.75.0.926484818342.issue15081@psf.upfronthosting.co.za> Message-ID: <1339826818.78.0.893255346357.issue15081@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: It's in PEP 3121, but it never made it to the documentation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15081> _______________________________________ From report at bugs.python.org Sat Jun 16 08:38:07 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 16 Jun 2012 06:38:07 +0000 Subject: [issue15082] [httplib] httplib.BadStatusLine on any HTTPS connection in certain unknown cases. In-Reply-To: <1339811528.79.0.0690651710917.issue15082@psf.upfronthosting.co.za> Message-ID: <1339828687.39.0.189471788057.issue15082@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I can reproduce this, and it seems to stem from the openssl version used (0.9.8l). Running openssl s_client -connect grooveshark.com:443 with 0.9.8l gives CONNECTED(00000003) depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info at valicert.com verify error:num=19:self signed certificate in certificate chain verify return:0 22456:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100: 22456:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:697: 22456:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:s3_clnt.c:1448: With 1.0.1c, it gives CONNECTED(00000003) depth=3 L = ValiCert Validation Network, O = "ValiCert, Inc.", OU = ValiCert Class 2 Policy Validation Authority, CN = http://www.valicert.com/, emailAddress = info at valicert.com verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/ST=FL/L=Gainesville/O=Grooveshark/CN=*.grooveshark.com i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info at valicert.com 3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info at valicert.com i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info at valicert.com --- Server certificate ... i.e. the connection gets established. The next bug fix release of Python 2.7 will include OpenSSL 0.9.8x, which is the latest OpenSSL 0.9.8 bug fix. It still shows the error in connecting, so I wonder whether this is a bug that just doesn't get fixed for 0.9.8, or whether it's a bug in the server (that 1.0.1 somehow avoids). ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15082> _______________________________________ From report at bugs.python.org Sat Jun 16 09:10:50 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Jun 2012 07:10:50 +0000 Subject: [issue15084] Add option to os.makefile to not raise an exception for existing directories Message-ID: <1339830650.07.0.788386004533.issue15084@psf.upfronthosting.co.za> New submission from Raymond Hettinger <raymond.hettinger at gmail.com>: I commonly see the code pattern: try: os.mkdir(dirname) except OSError: pass It would be nice to have this instead: os.mkdir(dirname, ignore_if_existing=True) There's probably a better name for the keyword argument, but it communicates the idea clearly enough. ---------- messages: 162956 nosy: rhettinger priority: normal severity: normal status: open title: Add option to os.makefile to not raise an exception for existing directories type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15084> _______________________________________ From report at bugs.python.org Sat Jun 16 09:35:38 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 16 Jun 2012 07:35:38 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <1339832138.14.0.829100642066.issue15075@psf.upfronthosting.co.za> Florent Xicluna <florent.xicluna at gmail.com> added the comment: > File "/home/eliben/python-src/33/Lib/test/regrtest.py", line 710 in main > File "/home/eliben/python-src/33/Lib/test/regrtest.py", line 1829 in <module> > File "/home/eliben/python-src/33/Lib/runpy.py", line 75 in _run_code > File "/home/eliben/python-src/33/Lib/runpy.py", line 162 in _run_module_as_main > Segmentation fault (core dumped) Even if the ET tests are hacking sys.modules, I assume that the Python interpreter should not crash so badly. It reveals probably a flaw somewhere else. I suggest to re-open this to track the Segmentation fault. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Sat Jun 16 09:47:34 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 07:47:34 +0000 Subject: [issue15084] Add option to os.makefile to not raise an exception for existing directories In-Reply-To: <1339830650.07.0.788386004533.issue15084@psf.upfronthosting.co.za> Message-ID: <1339832854.73.0.909933594648.issue15084@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Agree. First, the use of parameter is shorter (1 line instead of 4). Second, try/except idiom hides possible real OS errors (no rights to create the directory, a non-directory file with the same name already exists, illegal filename, too long patch, etc.). But "ignore_if_existing" is not good name for my taste. ---------- components: +Library (Lib) nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15084> _______________________________________ From report at bugs.python.org Sat Jun 16 10:06:30 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 16 Jun 2012 08:06:30 +0000 Subject: [issue15084] Add option to os.makefile to not raise an exception for existing directories In-Reply-To: <1339830650.07.0.788386004533.issue15084@psf.upfronthosting.co.za> Message-ID: <1339833990.67.0.814739865973.issue15084@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: +1. Raymond, is there a reason you put that for 3.4? I'd try to get it in before beta1 next week, it's trivial enough. Regarding the name: os.makedirs() uses exist_ok, we shouldn't invent new ones. ---------- assignee: -> hynek nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15084> _______________________________________ From report at bugs.python.org Sat Jun 16 10:29:05 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 16 Jun 2012 08:29:05 +0000 Subject: [issue15084] Add option to os.mkdir to not raise an exception for existing directories In-Reply-To: <1339830650.07.0.788386004533.issue15084@psf.upfronthosting.co.za> Message-ID: <1339835345.33.0.114105803336.issue15084@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- title: Add option to os.makefile to not raise an exception for existing directories -> Add option to os.mkdir to not raise an exception for existing directories _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15084> _______________________________________ From report at bugs.python.org Sat Jun 16 10:43:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 08:43:11 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339791555.4.0.385980132586.issue15026@psf.upfronthosting.co.za> Message-ID: <1339836113.2467.12.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: Thank you for pushing. :-) Are you interested in a faster UTF-32 codec? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Sat Jun 16 11:03:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 09:03:31 +0000 Subject: [issue15026] Faster UTF-16 encoding In-Reply-To: <1339836113.2467.12.camel@raxxla> Message-ID: <1339837224.3392.10.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Thank you for pushing. :-) Are you interested in a faster UTF-32 codec? Not much :) I know you posted issues on that, but I think UTF-32 is quite low priority. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15026> _______________________________________ From report at bugs.python.org Sat Jun 16 11:08:48 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 16 Jun 2012 09:08:48 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1339837728.44.0.0736733014601.issue15068@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- nosy: +flox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Sat Jun 16 11:09:09 2012 From: report at bugs.python.org (Stefan Krastanov) Date: Sat, 16 Jun 2012 09:09:09 +0000 Subject: [issue15085] set.union accepts not set iterables for all but the first argument. Message-ID: <1339837749.11.0.973257724486.issue15085@psf.upfronthosting.co.za> New submission from Stefan Krastanov <krastanov.stefan at gmail.com>: >>> set.union(set([1,2]), [3]) set([1, 2, 3]) >>> set.union([1,2], [3]) TypeError: descriptor 'union' requires a 'set' object but received a 'list' It seems a bit inconsistent. Is it justified somehow? ---------- components: None messages: 162962 nosy: krastanov-stefan priority: normal severity: normal status: open title: set.union accepts not set iterables for all but the first argument. versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15085> _______________________________________ From report at bugs.python.org Sat Jun 16 12:03:18 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 16 Jun 2012 10:03:18 +0000 Subject: [issue15084] Add option to os.mkdir to not raise an exception for existing directories In-Reply-To: <1339830650.07.0.788386004533.issue15084@psf.upfronthosting.co.za> Message-ID: <1339840998.68.0.310400583672.issue15084@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: I looked into the code. Assuming it should be added, we're facing the fact that os.mkdir() is C code ATM and the handling of the error would require to implement it for NT and Unix separately. Therefore it would make sense to add a Python os.mkdir() that handles this (basically try: _mkdir(dirname) except FileExistsError: pass) and make the C implementation private. OTOH you could argue that if you just want to ensure that that a directory exists, you could just as well use os.makedirs() with exists_ok so I'm kind of -0 on the whole thing. ---------- assignee: hynek -> nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15084> _______________________________________ From report at bugs.python.org Sat Jun 16 12:33:50 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 16 Jun 2012 10:33:50 +0000 Subject: [issue15084] Add option to os.mkdir to not raise an exception for existing directories In-Reply-To: <1339830650.07.0.788386004533.issue15084@psf.upfronthosting.co.za> Message-ID: <1339842830.51.0.596465416634.issue15084@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I agree that this is already covered by the exist_ok parameter (which is new to 3.2). Existing code just hasn't been ported to this API. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15084> _______________________________________ From report at bugs.python.org Sat Jun 16 12:39:28 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Jun 2012 10:39:28 +0000 Subject: [issue15050] Python 3.2.3 fail to make In-Reply-To: <1339488103.99.0.17701742584.issue15050@psf.upfronthosting.co.za> Message-ID: <1339843168.76.0.0357746410352.issue15050@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Martin, do I understand that you are saying that this is not a Python problem, and should be closed? ---------- nosy: +terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15050> _______________________________________ From report at bugs.python.org Sat Jun 16 12:55:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 16 Jun 2012 10:55:09 +0000 Subject: [issue15050] Python 3.2.3 fail to make In-Reply-To: <1339843168.76.0.0357746410352.issue15050@psf.upfronthosting.co.za> Message-ID: <4FDC660B.5070805@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Martin, do I understand that you are saying that this is not a Python > problem, and should be closed? No. I'm saying that I don't know whether it's a Python problem. It hasn't been fully analyzed. I actually only suspect that it's a misconfiguration. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15050> _______________________________________ From report at bugs.python.org Sat Jun 16 14:08:37 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 16 Jun 2012 12:08:37 +0000 Subject: [issue15075] XincludeTest failure in test_xml_etree In-Reply-To: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za> Message-ID: <1339848517.61.0.572369056508.issue15075@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: No need, the cause for the segfault is known. What happens is that Element objects from the Python module get intermixed with Element objects from the C module, and these are incompatible. The C module traversal functions assume they can cast Elements to a known structure (ElementObject), and when they get the invalid Elements they crash. Adding runtime checks everywhere is too costly. This situation cannot arise in a valid way. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15075> _______________________________________ From report at bugs.python.org Sat Jun 16 14:12:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 16 Jun 2012 12:12:22 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339848742.53.0.37867771197.issue15054@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 15:38:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 13:38:48 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339853928.93.0.648481134981.issue15054@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Here is a patch (for Python 3.3). ---------- keywords: +patch nosy: +storchaka Added file: http://bugs.python.org/file26025/tokenize_bytes.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 15:49:59 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jun 2012 13:49:59 +0000 Subject: [issue14992] os.makedirs expect_ok=True test_os failure when directory has S_ISGID bit set In-Reply-To: <1338750994.84.0.984038556909.issue14992@psf.upfronthosting.co.za> Message-ID: <1339854599.63.0.884320852918.issue14992@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: See also issue 13498. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14992> _______________________________________ From report at bugs.python.org Sat Jun 16 15:50:14 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 13:50:14 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339854614.37.0.225825839806.issue15054@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Here is a patch for Python 2. ---------- Added file: http://bugs.python.org/file26026/tokenize_bytes_py2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 15:51:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 13:51:23 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339854683.95.0.0801998120292.issue15054@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: And here is a better patch for Python 3. ---------- Added file: http://bugs.python.org/file26027/tokenize_bytes_py3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 15:51:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 13:51:44 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339854704.6.0.422883450094.issue15054@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: Removed file: http://bugs.python.org/file26025/tokenize_bytes.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 15:54:07 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jun 2012 13:54:07 +0000 Subject: [issue15084] Add option to os.mkdir to not raise an exception for existing directories In-Reply-To: <1339830650.07.0.788386004533.issue15084@psf.upfronthosting.co.za> Message-ID: <1339854847.85.0.779161686114.issue15084@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Note that the implementation of makedirs exist_ok has a significant bug (issue 13498) which renders it mostly useless in practice. Parties interested in this issue might be interested in figuring out how to fix that bug :) ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15084> _______________________________________ From report at bugs.python.org Sat Jun 16 16:02:47 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jun 2012 14:02:47 +0000 Subject: [issue15085] set.union accepts not set iterables for all but the first argument. In-Reply-To: <1339837749.11.0.973257724486.issue15085@psf.upfronthosting.co.za> Message-ID: <1339855367.95.0.979506812525.issue15085@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: By calling 'set.union' you are calling the method on the class. When you call a method directly on a class object, you have to explicitly pass in 'self'. Thus the first argument when you call it like that must be a set object. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15085> _______________________________________ From report at bugs.python.org Sat Jun 16 16:08:24 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 16 Jun 2012 14:08:24 +0000 Subject: [issue9679] unicode DNS names in urllib, urlopen In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za> Message-ID: <1339855704.03.0.585120466365.issue9679@psf.upfronthosting.co.za> Florent Xicluna <florent.xicluna at gmail.com> added the comment: The werkzeug.urls module has examples of such conversion IRI-to-URI: https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/urls.py#L109,L205 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9679> _______________________________________ From report at bugs.python.org Sat Jun 16 16:13:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 14:13:10 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339855990.69.0.85449100447.issue15054@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: Removed file: http://bugs.python.org/file26027/tokenize_bytes_py3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 16:14:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 14:14:11 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339856051.67.0.340808095111.issue15054@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: And here is an even better patch for Python 3. ---------- Added file: http://bugs.python.org/file26028/tokenize_bytes_py3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 16:15:30 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 16 Jun 2012 14:15:30 +0000 Subject: [issue805255] remove/discard method for dict objects. Message-ID: <1339856130.5.0.0844999856992.issue805255@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- nosy: +flox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue805255> _______________________________________ From report at bugs.python.org Sat Jun 16 16:21:08 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 16 Jun 2012 14:21:08 +0000 Subject: [issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za> Message-ID: <1339856468.32.0.0115869911558.issue13498@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13498> _______________________________________ From report at bugs.python.org Sat Jun 16 17:34:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 15:34:13 +0000 Subject: [issue14055] Implement __sizeof__ for etree Element In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za> Message-ID: <1339860853.57.0.136396776664.issue14055@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14055> _______________________________________ From report at bugs.python.org Sat Jun 16 17:38:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 15:38:13 +0000 Subject: [issue14055] Implement __sizeof__ for etree Element In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za> Message-ID: <1339861093.69.0.942907876998.issue14055@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14055> _______________________________________ From report at bugs.python.org Sat Jun 16 18:25:36 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 16 Jun 2012 16:25:36 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1339863936.73.0.654121252339.issue13241@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13241> _______________________________________ From report at bugs.python.org Sat Jun 16 18:27:01 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 16 Jun 2012 16:27:01 +0000 Subject: [issue15048] Manually Installed Python Includes System Wide Paths In-Reply-To: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za> Message-ID: <1339864021.87.0.357524578175.issue15048@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15048> _______________________________________ From report at bugs.python.org Sat Jun 16 18:31:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 16:31:55 +0000 Subject: [issue14850] The inconsistency of codecs.charmap_decode In-Reply-To: <1337352396.54.0.468921009595.issue14850@psf.upfronthosting.co.za> Message-ID: <1339864315.07.0.102117768292.issue14850@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14850> _______________________________________ From report at bugs.python.org Sat Jun 16 18:41:44 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 16 Jun 2012 16:41:44 +0000 Subject: [issue15063] Source code links for JSON documentation In-Reply-To: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za> Message-ID: <1339864904.86.0.189737847195.issue15063@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: The source links were added by Raymond for selected modules that he judged readable, well-written and useful companions to the documentation. For the json.encoder and decoder modules, I don?t think this is the case: the rst doc should explain well the behavior of the default encoder/decoder and how to subclass to change this behavior. Did you see something interesting in the code? I only had a look through it quickly, and saw the mix of C and Python code (which can be non-trivial to follow) and a dubious idiom (binding globals as locals to optimize access on CPython?doesn?t work on PyPy). My opinion is -1; what do other people think? ---------- nosy: +eric.araujo, rhettinger versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15063> _______________________________________ From report at bugs.python.org Sat Jun 16 18:43:40 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 16 Jun 2012 16:43:40 +0000 Subject: [issue15062] argparse: option for a positional argument In-Reply-To: <1339629346.54.0.223771927159.issue15062@psf.upfronthosting.co.za> Message-ID: <1339865020.8.0.827033501631.issue15062@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I wouldn?t use the syntax used by find, dd or other very old and peculiar commands as an example for anything new :) ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15062> _______________________________________ From report at bugs.python.org Sat Jun 16 18:44:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 16:44:22 +0000 Subject: [issue14874] Faster charmap decoding In-Reply-To: <1337638770.26.0.783937266614.issue14874@psf.upfronthosting.co.za> Message-ID: <1339865062.61.0.924017458813.issue14874@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14874> _______________________________________ From report at bugs.python.org Sat Jun 16 18:47:20 2012 From: report at bugs.python.org (George Stephanos) Date: Sat, 16 Jun 2012 16:47:20 +0000 Subject: [issue15082] [httplib] httplib.BadStatusLine on any HTTPS connection in certain unknown cases. In-Reply-To: <1339811528.79.0.0690651710917.issue15082@psf.upfronthosting.co.za> Message-ID: <1339865240.42.0.441491586079.issue15082@psf.upfronthosting.co.za> George Stephanos <gaf.stephanos at gmail.com> added the comment: I can confirm that. I built a 1.0.1c version of both _ssl.pyd and _ssl.lib and now the problem's solved (they're attached if ever needed). Thanks! Can't the next Python 2.7 release include 1.0.1c instead ? ---------- Added file: http://bugs.python.org/file26029/_ssl.zip _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15082> _______________________________________ From report at bugs.python.org Sat Jun 16 18:50:06 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 16 Jun 2012 16:50:06 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339865406.88.0.334327597679.issue15054@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +meador.inge stage: needs patch -> test needed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 18:52:40 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 16 Jun 2012 16:52:40 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1339865560.92.0.0892469337685.issue15008@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: One small thing: can we find a name for the function that starts with a verb? It?s the recommended naming style for functions, and would help making a difference between the class and the function. I also expect people to use ?signature? and ?sig? for their instances. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Sat Jun 16 19:20:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 16 Jun 2012 17:20:48 +0000 Subject: [issue15063] Source code links for JSON documentation In-Reply-To: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za> Message-ID: <1339867248.76.0.296011268612.issue15063@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti resolution: -> rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15063> _______________________________________ From report at bugs.python.org Sat Jun 16 19:21:24 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 16 Jun 2012 17:21:24 +0000 Subject: [issue14055] Implement __sizeof__ for etree Element In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za> Message-ID: <1339867284.34.0.121110510297.issue14055@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: Out of curiosity, why don't the constituents of Element (i.e. the tag, the attributes dict, etc.) count for its size? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14055> _______________________________________ From report at bugs.python.org Sat Jun 16 20:18:03 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 16 Jun 2012 18:18:03 +0000 Subject: [issue15086] Ubuntu bot: error while loading shared libraries Message-ID: <1339870683.52.0.123357667128.issue15086@psf.upfronthosting.co.za> New submission from Stefan Krah <stefan-usenet at bytereef.org>: The Ubuntu shared buildbot fails to run the tests: using PTY: True ./python: error while loading shared libraries: libpython3.3dm.so.1.0: cannot open shared object file: No such file or directory make: *** [Python/importlib.h] Error 127 034c814eb187 was O.K., as far as the logs are still visible the error first appears in 240b7467e65c . ---------- components: Tests keywords: buildbot messages: 162981 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: Ubuntu bot: error while loading shared libraries type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15086> _______________________________________ From report at bugs.python.org Sat Jun 16 20:18:48 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 16 Jun 2012 18:18:48 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339785535.51.0.170053982828.issue15036@psf.upfronthosting.co.za> Message-ID: <20120616181846.GA22371@chang> Petri Lehtinen <petri at digip.org> added the comment: Yes, this is what I tried to say. It's hard for me to find a good wording, so what would you suggest? I also noticed now that there's a typo in the commit messages. But those cannot be fixed anymore. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Sat Jun 16 20:25:57 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 16 Jun 2012 18:25:57 +0000 Subject: [issue15062] argparse: option for a positional argument In-Reply-To: <1339629346.54.0.223771927159.issue15062@psf.upfronthosting.co.za> Message-ID: <1339871157.73.0.962026245301.issue15062@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: What alternate syntax would you suggest for a "find" type command then (other than replacing "-long" by "--long")? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15062> _______________________________________ From report at bugs.python.org Sat Jun 16 20:33:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 18:33:50 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1339871630.39.0.366825108576.issue14657@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Unless someone plans to do further work on this, I'd like to commit unique_importlib3.patch. A working solution is better than nothing. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14657> _______________________________________ From report at bugs.python.org Sat Jun 16 20:43:46 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 16 Jun 2012 18:43:46 +0000 Subject: [issue14055] Implement __sizeof__ for etree Element In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za> Message-ID: <1339872226.26.0.921805320506.issue14055@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: __sizeof__ is supposed to account for just the object, not for the size of any object it refers to. If you want to compute total memory consumption, you should get a list of all objects, and then sum up __sizeof__. If some object would also include some of its referents, there would be a danger of accounting some memory twice. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14055> _______________________________________ From report at bugs.python.org Sat Jun 16 20:45:44 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 Jun 2012 18:45:44 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <1339872344.37.0.440930216453.issue15036@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: "Mailbox no longer throws an error if a flush is done between operations when removing or changing multiple items in mbox, MMDF, or Babyl mailboxes." ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Sat Jun 16 22:15:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 20:15:49 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za> Message-ID: <1339877749.45.0.457708376386.issue14928@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Here is a patch for the "separate C executable" approach. There are a couple of small complications in order to avoid any circular dependency (either at the Makefile level, or at the _frozen_importlib / Py_Initialize level). The proposed "-X" or BOOTSTRAP_PY approaches would be difficult, since there doesn't appear to be an easy way to generate a given file (the Python interpreter) twice in a Makefile dependency chain: the first time using the stale importlib, the second with the fresh importlib. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file26030/cfreeze.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Sat Jun 16 22:30:43 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 20:30:43 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339865406.93.0.0829061150598.issue15054@psf.upfronthosting.co.za> Message-ID: <1339878651.2467.14.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: Patches updated with tests. ---------- Added file: http://bugs.python.org/file26031/tokenize_bytes_py2-2.patch Added file: http://bugs.python.org/file26032/tokenize_bytes_py3-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ -------------- next part -------------- diff -r 412c7daed0db Lib/test/test_tokenize.py --- a/Lib/test/test_tokenize.py Thu Jun 14 00:36:54 2012 +0200 +++ b/Lib/test/test_tokenize.py Sat Jun 16 23:28:52 2012 +0300 @@ -278,6 +278,31 @@ OP '+' (1, 32) (1, 33) STRING 'UR"ABC"' (1, 34) (1, 41) + >>> dump_tokens("b'abc' + B'abc'") + STRING "b'abc'" (1, 0) (1, 6) + OP '+' (1, 7) (1, 8) + STRING "B'abc'" (1, 9) (1, 15) + >>> dump_tokens('b"abc" + B"abc"') + STRING 'b"abc"' (1, 0) (1, 6) + OP '+' (1, 7) (1, 8) + STRING 'B"abc"' (1, 9) (1, 15) + >>> dump_tokens("br'abc' + bR'abc' + Br'abc' + BR'abc'") + STRING "br'abc'" (1, 0) (1, 7) + OP '+' (1, 8) (1, 9) + STRING "bR'abc'" (1, 10) (1, 17) + OP '+' (1, 18) (1, 19) + STRING "Br'abc'" (1, 20) (1, 27) + OP '+' (1, 28) (1, 29) + STRING "BR'abc'" (1, 30) (1, 37) + >>> dump_tokens('br"abc" + bR"abc" + Br"abc" + BR"abc"') + STRING 'br"abc"' (1, 0) (1, 7) + OP '+' (1, 8) (1, 9) + STRING 'bR"abc"' (1, 10) (1, 17) + OP '+' (1, 18) (1, 19) + STRING 'Br"abc"' (1, 20) (1, 27) + OP '+' (1, 28) (1, 29) + STRING 'BR"abc"' (1, 30) (1, 37) + Operators >>> dump_tokens("def d22(a, b, c=2, d=2, *k): pass") diff -r 412c7daed0db Lib/tokenize.py --- a/Lib/tokenize.py Thu Jun 14 00:36:54 2012 +0200 +++ b/Lib/tokenize.py Sat Jun 16 23:28:52 2012 +0300 @@ -70,10 +70,10 @@ Single3 = r"[^'\\]*(?:(?:\\.|'(?!''))[^'\\]*)*'''" # Tail end of """ string. Double3 = r'[^"\\]*(?:(?:\\.|"(?!""))[^"\\]*)*"""' -Triple = group("[uU]?[rR]?'''", '[uU]?[rR]?"""') +Triple = group("[uUbB]?[rR]?'''", '[uUbB]?[rR]?"""') # Single-line ' or " string. -String = group(r"[uU]?[rR]?'[^\n'\\]*(?:\\.[^\n'\\]*)*'", - r'[uU]?[rR]?"[^\n"\\]*(?:\\.[^\n"\\]*)*"') +String = group(r"[uUbB]?[rR]?'[^\n'\\]*(?:\\.[^\n'\\]*)*'", + r'[uUbB]?[rR]?"[^\n"\\]*(?:\\.[^\n"\\]*)*"') # Because of leftmost-then-longest match semantics, be sure to put the # longest operators first (e.g., if = came before ==, == would get @@ -91,9 +91,9 @@ Token = Ignore + PlainToken # First (or only) line of ' or " string. -ContStr = group(r"[uU]?[rR]?'[^\n'\\]*(?:\\.[^\n'\\]*)*" + +ContStr = group(r"[uUbB]?[rR]?'[^\n'\\]*(?:\\.[^\n'\\]*)*" + group("'", r'\\\r?\n'), - r'[uU]?[rR]?"[^\n"\\]*(?:\\.[^\n"\\]*)*' + + r'[uUbB]?[rR]?"[^\n"\\]*(?:\\.[^\n"\\]*)*' + group('"', r'\\\r?\n')) PseudoExtras = group(r'\\\r?\n', Comment, Triple) PseudoToken = Whitespace + group(PseudoExtras, Number, Funny, ContStr, Name) -------------- next part -------------- diff -r f6463dc5ead6 Lib/test/test_tokenize.py --- a/Lib/test/test_tokenize.py Sat Jun 16 16:38:26 2012 +0200 +++ b/Lib/test/test_tokenize.py Sat Jun 16 23:28:44 2012 +0300 @@ -289,6 +289,82 @@ OP '+' (1, 29) (1, 30) STRING 'R"ABC"' (1, 31) (1, 37) + >>> dump_tokens("u'abc' + U'abc'") + ENCODING 'utf-8' (0, 0) (0, 0) + STRING "u'abc'" (1, 0) (1, 6) + OP '+' (1, 7) (1, 8) + STRING "U'abc'" (1, 9) (1, 15) + >>> dump_tokens('u"abc" + U"abc"') + ENCODING 'utf-8' (0, 0) (0, 0) + STRING 'u"abc"' (1, 0) (1, 6) + OP '+' (1, 7) (1, 8) + STRING 'U"abc"' (1, 9) (1, 15) + >>> dump_tokens("ur'abc' + uR'abc' + Ur'abc' + UR'abc'") + ENCODING 'utf-8' (0, 0) (0, 0) + STRING "ur'abc'" (1, 0) (1, 7) + OP '+' (1, 8) (1, 9) + STRING "uR'abc'" (1, 10) (1, 17) + OP '+' (1, 18) (1, 19) + STRING "Ur'abc'" (1, 20) (1, 27) + OP '+' (1, 28) (1, 29) + STRING "UR'abc'" (1, 30) (1, 37) + >>> dump_tokens('ur"abc" + uR"abc" + Ur"abc" + UR"abc"') + ENCODING 'utf-8' (0, 0) (0, 0) + STRING 'ur"abc"' (1, 0) (1, 7) + OP '+' (1, 8) (1, 9) + STRING 'uR"abc"' (1, 10) (1, 17) + OP '+' (1, 18) (1, 19) + STRING 'Ur"abc"' (1, 20) (1, 27) + OP '+' (1, 28) (1, 29) + STRING 'UR"abc"' (1, 30) (1, 37) + + >>> dump_tokens("b'abc' + B'abc'") + ENCODING 'utf-8' (0, 0) (0, 0) + STRING "b'abc'" (1, 0) (1, 6) + OP '+' (1, 7) (1, 8) + STRING "B'abc'" (1, 9) (1, 15) + >>> dump_tokens('b"abc" + B"abc"') + ENCODING 'utf-8' (0, 0) (0, 0) + STRING 'b"abc"' (1, 0) (1, 6) + OP '+' (1, 7) (1, 8) + STRING 'B"abc"' (1, 9) (1, 15) + >>> dump_tokens("br'abc' + bR'abc' + Br'abc' + BR'abc'") + ENCODING 'utf-8' (0, 0) (0, 0) + STRING "br'abc'" (1, 0) (1, 7) + OP '+' (1, 8) (1, 9) + STRING "bR'abc'" (1, 10) (1, 17) + OP '+' (1, 18) (1, 19) + STRING "Br'abc'" (1, 20) (1, 27) + OP '+' (1, 28) (1, 29) + STRING "BR'abc'" (1, 30) (1, 37) + >>> dump_tokens('br"abc" + bR"abc" + Br"abc" + BR"abc"') + ENCODING 'utf-8' (0, 0) (0, 0) + STRING 'br"abc"' (1, 0) (1, 7) + OP '+' (1, 8) (1, 9) + STRING 'bR"abc"' (1, 10) (1, 17) + OP '+' (1, 18) (1, 19) + STRING 'Br"abc"' (1, 20) (1, 27) + OP '+' (1, 28) (1, 29) + STRING 'BR"abc"' (1, 30) (1, 37) + >>> dump_tokens("rb'abc' + rB'abc' + Rb'abc' + RB'abc'") + ENCODING 'utf-8' (0, 0) (0, 0) + STRING "rb'abc'" (1, 0) (1, 7) + OP '+' (1, 8) (1, 9) + STRING "rB'abc'" (1, 10) (1, 17) + OP '+' (1, 18) (1, 19) + STRING "Rb'abc'" (1, 20) (1, 27) + OP '+' (1, 28) (1, 29) + STRING "RB'abc'" (1, 30) (1, 37) + >>> dump_tokens('rb"abc" + rB"abc" + Rb"abc" + RB"abc"') + ENCODING 'utf-8' (0, 0) (0, 0) + STRING 'rb"abc"' (1, 0) (1, 7) + OP '+' (1, 8) (1, 9) + STRING 'rB"abc"' (1, 10) (1, 17) + OP '+' (1, 18) (1, 19) + STRING 'Rb"abc"' (1, 20) (1, 27) + OP '+' (1, 28) (1, 29) + STRING 'RB"abc"' (1, 30) (1, 37) + Operators >>> dump_tokens("def d22(a, b, c=2, d=2, *k): pass") diff -r f6463dc5ead6 Lib/tokenize.py --- a/Lib/tokenize.py Sat Jun 16 16:38:26 2012 +0200 +++ b/Lib/tokenize.py Sat Jun 16 23:28:44 2012 +0300 @@ -127,7 +127,7 @@ Imagnumber = group(r'[0-9]+[jJ]', Floatnumber + r'[jJ]') Number = group(Imagnumber, Floatnumber, Intnumber) -StringPrefix = r'(?:[uU][rR]?|[bB][rR]|[rR][bB]|[rR]|[uU])?' +StringPrefix = r'(?:[uUbB][rR]?|[rR][bB]?)?' # Tail end of ' string. Single = r"[^'\\]*(?:\\.[^'\\]*)*'" From report at bugs.python.org Sat Jun 16 22:47:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 20:47:47 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339879667.15.0.542730602734.issue15054@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- stage: test needed -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 22:54:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jun 2012 20:54:06 +0000 Subject: [issue14874] Faster charmap decoding In-Reply-To: <1337638770.26.0.783937266614.issue14874@psf.upfronthosting.co.za> Message-ID: <E1Sg00T-0000lV-I3@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 8f3a5308f50b by Antoine Pitrou in branch 'default': Issue #14874: Restore charmap decoding speed to pre-PEP 393 levels. http://hg.python.org/cpython/rev/8f3a5308f50b ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14874> _______________________________________ From report at bugs.python.org Sat Jun 16 22:54:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 20:54:33 +0000 Subject: [issue14874] Faster charmap decoding In-Reply-To: <1337638770.26.0.783937266614.issue14874@psf.upfronthosting.co.za> Message-ID: <1339880073.02.0.564811375038.issue14874@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Thank you for the patch! Now pushed to 3.3. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14874> _______________________________________ From report at bugs.python.org Sat Jun 16 23:10:34 2012 From: report at bugs.python.org (Meador Inge) Date: Sat, 16 Jun 2012 21:10:34 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339881034.39.0.674731091416.issue15054@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: The Python 3 patch looks OK, except that several of the tests are duplicated. I am looking at the Python 2 patch now. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 23:12:00 2012 From: report at bugs.python.org (Meador Inge) Date: Sat, 16 Jun 2012 21:12:00 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339881120.71.0.858777041791.issue15054@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: Nevermind, the tests are OK. I missed the swapped quotes. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 23:17:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 21:17:01 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339881034.39.0.674731091416.issue15054@psf.upfronthosting.co.za> Message-ID: <1339881435.2467.16.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > The Python 3 patch looks OK, except that several of the tests are duplicated. What tests? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sat Jun 16 23:23:44 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Jun 2012 21:23:44 +0000 Subject: [issue1229239] optionally allow mutable builtin types Message-ID: <1339881824.45.0.215436329228.issue1229239@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Greg, I am closing this because you seem to have found an alternate solution and have dropped the issue. If you do want to pursue a change for 3.4, I suggest you refresh your patch and post to python-ideas (new list since you posted this). As a limited resource, flags are not casually added, and I know another request was recently denied on pydev. ---------- nosy: +terry.reedy resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1229239> _______________________________________ From report at bugs.python.org Sat Jun 16 23:24:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Jun 2012 21:24:57 +0000 Subject: [issue14815] random_seed uses only 32-bits of hash on Win64 In-Reply-To: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za> Message-ID: <1339881897.59.0.166147306631.issue14815@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14815> _______________________________________ From report at bugs.python.org Sat Jun 16 23:33:39 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Jun 2012 21:33:39 +0000 Subject: [issue730473] Add Py_AtInit() startup hook for extenders Message-ID: <1339882419.39.0.995282249341.issue730473@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Patrick, its been 5 years since you promised a 2nd patch (which would now have to be against the current 3.3 tip). If you have lost interested, perhaps we should close this. ---------- nosy: +terry.reedy versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue730473> _______________________________________ From report at bugs.python.org Sat Jun 16 23:38:10 2012 From: report at bugs.python.org (Meador Inge) Date: Sat, 16 Jun 2012 21:38:10 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339882690.09.0.428870215565.issue15054@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: Python 2 patch looks OK too. I will commit these later today. Thanks for the patches! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sun Jun 17 00:04:51 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 16 Jun 2012 22:04:51 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339884291.89.0.670000893442.issue15054@psf.upfronthosting.co.za> Florent Xicluna <florent.xicluna at gmail.com> added the comment: LGTM too. Thanks. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sun Jun 17 00:11:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 22:11:17 +0000 Subject: [issue15086] Ubuntu bot: error while loading shared libraries In-Reply-To: <1339870683.52.0.123357667128.issue15086@psf.upfronthosting.co.za> Message-ID: <1339884677.83.0.52241715268.issue15086@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +brett.cannon _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15086> _______________________________________ From report at bugs.python.org Sun Jun 17 00:29:44 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 16 Jun 2012 22:29:44 +0000 Subject: [issue15086] Ubuntu bot: error while loading shared libraries In-Reply-To: <1339870683.52.0.123357667128.issue15086@psf.upfronthosting.co.za> Message-ID: <1339885784.48.0.249566940872.issue15086@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Rebuilding importlib.h fails: ---------------------------------------------------------- Python/importlib.h needs to be rebuilt, but no interpreter is available to do so. Leaving the previous version in place. You may want to run ''make'' a second time after this build is complete. ---------------------------------------------------------- Is there an easy way to change the buildmaster to run 'make' twice on this slave? ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15086> _______________________________________ From report at bugs.python.org Sun Jun 17 00:30:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Jun 2012 22:30:52 +0000 Subject: [issue15086] Ubuntu bot: error while loading shared libraries In-Reply-To: <1339870683.52.0.123357667128.issue15086@psf.upfronthosting.co.za> Message-ID: <E1Sg1W7-0001Au-In@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 3680b3423aa3 by Antoine Pitrou in branch 'default': Try to fix issue #15086: build failure on Ubuntu shared buildbot. http://hg.python.org/cpython/rev/3680b3423aa3 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15086> _______________________________________ From report at bugs.python.org Sun Jun 17 00:37:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Jun 2012 22:37:09 +0000 Subject: [issue15086] Ubuntu bot: error while loading shared libraries In-Reply-To: <1339870683.52.0.123357667128.issue15086@psf.upfronthosting.co.za> Message-ID: <1339886229.84.0.520950957154.issue15086@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Looks fixed. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15086> _______________________________________ From report at bugs.python.org Sun Jun 17 00:53:45 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Jun 2012 22:53:45 +0000 Subject: [issue14815] random_seed uses only 32-bits of hash on Win64 In-Reply-To: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za> Message-ID: <1339887225.41.0.874211541885.issue14815@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- assignee: rhettinger -> loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14815> _______________________________________ From report at bugs.python.org Sun Jun 17 02:11:43 2012 From: report at bugs.python.org (Patrick Miller) Date: Sun, 17 Jun 2012 00:11:43 +0000 Subject: [issue730473] Add Py_AtInit() startup hook for extenders Message-ID: <1339891903.13.0.142273596497.issue730473@psf.upfronthosting.co.za> Patrick Miller <patmiller at users.sourceforge.net> added the comment: Just languishing for lo on these 5 years.... ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue730473> _______________________________________ From report at bugs.python.org Sun Jun 17 02:54:19 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 17 Jun 2012 00:54:19 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1339894459.75.0.268563921874.issue14657@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: It's actually at the top of my list, but may still be a week or two until I can get to it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14657> _______________________________________ From report at bugs.python.org Sun Jun 17 02:56:34 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 17 Jun 2012 00:56:34 +0000 Subject: [issue14815] random_seed uses only 32-bits of hash on Win64 In-Reply-To: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za> Message-ID: <1339894594.4.0.149065908417.issue14815@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14815> _______________________________________ From report at bugs.python.org Sun Jun 17 03:05:06 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 17 Jun 2012 01:05:06 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <1339895106.31.0.677212018446.issue14769@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Ping. Benjamin, should I find another reviewer? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14769> _______________________________________ From report at bugs.python.org Sun Jun 17 03:34:39 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Jun 2012 01:34:39 +0000 Subject: [issue15087] Add gzip function to read gzip'd strings Message-ID: <1339896879.03.0.627255791455.issue15087@psf.upfronthosting.co.za> New submission from Raymond Hettinger <raymond.hettinger at gmail.com>: The API for the gzip module is convenient for reading gzipped file but is rather awkward for reading bytes downloaded from a socket: >>> import gzip, io >>> from urllib.request import urlopen, Request >>> u = urlopen(Request('http://www.nytimes.com', headers={'Accept-Encoding': 'gzip'})) >>> content = gzip.GzipFile(fileobj=io.BytesIO(u.read()), mode='rb').read() It would be better if the last line could be written: >>> content = gzip.decompress_file(u) ---------- components: Library (Lib) messages: 163004 nosy: rhettinger priority: normal severity: normal status: open title: Add gzip function to read gzip'd strings type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15087> _______________________________________ From report at bugs.python.org Sun Jun 17 03:41:52 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 17 Jun 2012 01:41:52 +0000 Subject: [issue15087] Add gzip function to read gzip'd strings In-Reply-To: <1339896879.03.0.627255791455.issue15087@psf.upfronthosting.co.za> Message-ID: <1339897312.5.0.351498497314.issue15087@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: There is already such a function, gzip.decompress() - it was added in 3.2. ---------- nosy: +nadeem.vawda resolution: -> invalid stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15087> _______________________________________ From report at bugs.python.org Sun Jun 17 04:21:58 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 17 Jun 2012 02:21:58 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1339899718.93.0.17128583647.issue15078@psf.upfronthosting.co.za> Giampaolo Rodola' <g.rodola at gmail.com> added the comment: I'm -0 about unifying the function signature and raise NotImplementedError where an arg is not supported. I'm -1 about os.sendfile(..., diskio=True, wait=True, sync=False). In both cases users willing to use these 3 args are already supposed to know what they're doing and that the code they're writing is not portable hence in practical terms I can't see a real gain in making a change. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sun Jun 17 04:50:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 02:50:58 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <E1Sg5Zo-0007gf-Tx@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 35d3a8ed7997 by Meador Inge in branch '2.7': Issue #15054: Fix incorrect tokenization of 'b' and 'br' string literals. http://hg.python.org/cpython/rev/35d3a8ed7997 New changeset 115b0cb52c6c by Meador Inge in branch 'default': Issue #15054: Fix incorrect tokenization of 'b' string literals. http://hg.python.org/cpython/rev/115b0cb52c6c ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sun Jun 17 04:54:46 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 17 Jun 2012 02:54:46 +0000 Subject: [issue15054] bytes literals erroneously tokenized In-Reply-To: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za> Message-ID: <1339901686.7.0.459420313454.issue15054@psf.upfronthosting.co.za> Changes by Meador Inge <meadori at gmail.com>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15054> _______________________________________ From report at bugs.python.org Sun Jun 17 05:04:19 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 17 Jun 2012 03:04:19 +0000 Subject: [issue14055] Implement __sizeof__ for etree Element In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za> Message-ID: <1339902259.29.0.894212451375.issue14055@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: Martin, thanks for the explanation. The patch LGTM, then. Could it be useful to document this a bit more explicitly in the description of sys.getsizeof? The most intuitive thing to expect from it is to compute the *total* size including contained objects. So this is somewhat surprising: >>> import sys >>> sys.getsizeof([1, 2, 3]) 96 >>> sys.getsizeof([1, 2, [10] * 500]) 96 The last sentence in the doc of sys.getsizeof says: "See recursive sizeof recipe for an example of using getsizeof() recursively to find the size of containers and all their contents.", which can be taken as a hint, but maybe it could be just said straightforwardly. I.e before it, add: "Note that getsizeof returns just the memory occupied by the object itself, not any contained objects it holds references to". ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14055> _______________________________________ From report at bugs.python.org Sun Jun 17 05:18:42 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 17 Jun 2012 03:18:42 +0000 Subject: [issue1767933] Badly formed XML using etree and utf-16 Message-ID: <1339903122.39.0.636977858022.issue1767933@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- nosy: +eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1767933> _______________________________________ From report at bugs.python.org Sun Jun 17 05:19:24 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 17 Jun 2012 03:19:24 +0000 Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding handling problems In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za> Message-ID: <1339903164.61.0.904204839389.issue9458@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- nosy: +eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9458> _______________________________________ From report at bugs.python.org Sun Jun 17 05:20:28 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 17 Jun 2012 03:20:28 +0000 Subject: [issue13823] xml.etree.ElementTree.ElementTree.write - argument checking In-Reply-To: <1326963107.43.0.928827185581.issue13823@psf.upfronthosting.co.za> Message-ID: <1339903228.32.0.976488824917.issue13823@psf.upfronthosting.co.za> Changes by Eli Bendersky <eliben at gmail.com>: ---------- nosy: +eli.bendersky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13823> _______________________________________ From report at bugs.python.org Sun Jun 17 05:50:10 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 17 Jun 2012 03:50:10 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za> Message-ID: <1339905010.54.0.729949451828.issue14928@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: Nice patch Antoine! The method of partitioning the object sets into frozen and non-frozen is nice. > The proposed "-X" or BOOTSTRAP_PY approaches would be difficult, since there > doesn't appear to be an easy way to generate a given file (the Python > interpreter) twice in a Makefile dependency chain: the first time using the > stale importlib, the second with the fresh importlib. I experimented with the env var approach and came to the exact same conclusion -- you would have to build the interpreter twice. This patch looks good to me (I did have to rebase it against trunk, though; it doesn't apply cleanly right now). I did some basic regression testing and ran it through the original scenario from issue12370 that got us thinking this problem. I saw no issues. Nice work. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Sun Jun 17 05:56:08 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 03:56:08 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1339905368.65.0.145733483239.issue14657@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: +1 Antoine - your patch is better than the status quo, so it makes sense to apply it. If Eric can make the other way work in time for 3.3, great, but at least we'll have a solid fallback position without it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14657> _______________________________________ From report at bugs.python.org Sun Jun 17 06:02:09 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 04:02:09 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za> Message-ID: <1339905729.77.0.335487436664.issue14928@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Looks like a solid improvement to me. One minor naming quibble is that "FROZENLESS_LIBRARY_OBJS" hurts my brain - would you mind switching it to something like "LIBRARY_OBJS_OMIT_FROZEN"? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Sun Jun 17 06:21:02 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 04:21:02 +0000 Subject: [issue15088] PyGen_NeedsFinalizing is public, but undocumented Message-ID: <1339906861.99.0.42415214654.issue15088@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: Currently undocumented: http://docs.python.org/py3k/c-api/gen.html Public API in a released version of Python: http://hg.python.org/cpython/file/3.2/Include/genobject.h ---------- messages: 163012 nosy: ncoghlan priority: normal severity: normal status: open title: PyGen_NeedsFinalizing is public, but undocumented _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15088> _______________________________________ From report at bugs.python.org Sun Jun 17 06:21:15 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 04:21:15 +0000 Subject: [issue15088] PyGen_NeedsFinalizing is public, but undocumented In-Reply-To: <1339906861.99.0.42415214654.issue15088@psf.upfronthosting.co.za> Message-ID: <1339906875.24.0.562344484404.issue15088@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15088> _______________________________________ From report at bugs.python.org Sun Jun 17 07:16:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 05:16:04 +0000 Subject: [issue13783] Clean up PEP 380 C API additions In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za> Message-ID: <E1Sg7qF-0000iK-6d@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset cfbf6aa5c9e3 by Nick Coghlan in branch 'default': Issue #13783: the PEP 380 implementation no longer expands the public C API http://hg.python.org/cpython/rev/cfbf6aa5c9e3 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13783> _______________________________________ From report at bugs.python.org Sun Jun 17 07:41:19 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 05:41:19 +0000 Subject: [issue14215] http://www.python.org/dev/peps/ title is python.org In-Reply-To: <1331102600.96.0.801989456091.issue14215@psf.upfronthosting.co.za> Message-ID: <1339911679.54.0.328633282158.issue14215@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: This is actually related to the integration between the PEP formatting tools and the python.org build system (that is, pep2pyramid.py, rather than genpepindex.py) I'm inclined to close it as "won't fix" and maybe pass it to the psf-redesign list to look into as part of the python.org RFP. ---------- nosy: +michael.foord _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14215> _______________________________________ From report at bugs.python.org Sun Jun 17 07:41:38 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 17 Jun 2012 05:41:38 +0000 Subject: [issue14991] Option for regex groupdict() to show only matching names In-Reply-To: <1338742861.24.0.324062376049.issue14991@psf.upfronthosting.co.za> Message-ID: <1339911698.27.0.508077668829.issue14991@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Just a thought--how about a new constant in the re module: SUPPRESSED=object() and have the interface be mo.groupdict(default=re.SUPPRESSED) ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14991> _______________________________________ From report at bugs.python.org Sun Jun 17 07:45:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 05:45:33 +0000 Subject: [issue13783] Clean up PEP 380 C API additions In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za> Message-ID: <E1Sg8Il-0002NI-NK@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 438b861e2edb by Nick Coghlan in branch 'default': Issue #13783: PEP 380 cleanup part 2, using the new identifier APIs in the generator implementation http://hg.python.org/cpython/rev/438b861e2edb ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13783> _______________________________________ From report at bugs.python.org Sun Jun 17 07:48:44 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 05:48:44 +0000 Subject: [issue13783] Clean up PEP 380 C API additions In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za> Message-ID: <1339912124.93.0.156927753895.issue13783@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I left the name of the new private API as _PyGen_FetchStopIterationValue. If anyone wants to make it public, they can raise a new issue to give it a more appropriate name (and move the definition accordingly). PyStopIteration_Create is simply gone, replaced by the underlying call. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13783> _______________________________________ From report at bugs.python.org Sun Jun 17 07:49:30 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 05:49:30 +0000 Subject: [issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za> Message-ID: <1339912170.17.0.669372943445.issue13475@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- assignee: ncoghlan -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13475> _______________________________________ From report at bugs.python.org Sun Jun 17 07:53:25 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 05:53:25 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1339912405.18.0.465592074082.issue11816@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Given the imminent 3.3 beta 1 feature freeze and the fact I would like to explore Ron's suggestion of a higher level ByteCode object to encapsulate a sequence of instructions (along with additional information from the code object), postponing this one. ---------- assignee: ncoghlan -> versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11816> _______________________________________ From report at bugs.python.org Sun Jun 17 08:37:09 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 06:37:09 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1339915029.05.0.462447574807.issue14814@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I looked into the idea of treating networks as containers of interface objects rather than addresses - it turns out it gets messy very quickly, because you definitely want your network address and broadcast address to be ordinary addresses, so making the host addresses interfaces instead of ordinary addresses would lead to inconsistent behaviour. 739f5c725958 is the result of that investigation (I forgot to mention this issue in the checkin message) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Sun Jun 17 08:51:13 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Jun 2012 06:51:13 +0000 Subject: [issue15089] Add gzip support to urllib.request.retrieve() Message-ID: <1339915873.52.0.115462585972.issue15089@psf.upfronthosting.co.za> New submission from Raymond Hettinger <raymond.hettinger at gmail.com>: Enable retrieve() to take advantage of data compression in HTTP requests. * In the request, add the header "Accept-Encoding: gzip". * In the response, check the headers for "Content-Encoding: gzip". * Convert the downloaded content using gzip.GzipFile. ---------- components: Library (Lib) keywords: easy messages: 163020 nosy: rhettinger priority: normal severity: normal status: open title: Add gzip support to urllib.request.retrieve() type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15089> _______________________________________ From report at bugs.python.org Sun Jun 17 09:02:37 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Jun 2012 07:02:37 +0000 Subject: [issue15090] Add etag support to urllib.request.urlretrieve() Message-ID: <1339916557.45.0.663415683134.issue15090@psf.upfronthosting.co.za> New submission from Raymond Hettinger <raymond.hettinger at gmail.com>: Add an optional argument to urlretrieve to specify an etag for previously downloaded content: >>> urlretrieve('example.com/data.txt', etag="105800d-4af6-4c29d893d69c0") That optional argument would add the following to the outgoing headers: "If-None-Match: 105800d-4af6-4c29d893d69c0" If the site returns a 304 Not Modified, then the full content download isn't needed. ---------- components: Library (Lib) messages: 163021 nosy: rhettinger priority: normal severity: normal status: open title: Add etag support to urllib.request.urlretrieve() type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15090> _______________________________________ From report at bugs.python.org Sun Jun 17 09:24:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 07:24:26 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <E1Sg9qT-000895-1I@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset cacf3b1e20da by Nick Coghlan in branch 'default': Issue #14814: Add first draft of PEP 3144 ipaddress module documentation (initial patch by Sandro Tosi) http://hg.python.org/cpython/rev/cacf3b1e20da ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Sun Jun 17 09:29:57 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 07:29:57 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1339918197.8.0.894382142259.issue14814@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: OK, dropping to "deferred blocker" status, as I think the docs are now good enough for beta 1. We still want to get the public methods and properties for the various objects documented during the beta period, though. I'm not sure how best to handle that, though - the interfaces of the v4 and v6 variants are deliberately very similar, so documenting everything twice seems like a rather user hostile thing to do. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Sun Jun 17 09:37:25 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 17 Jun 2012 07:37:25 +0000 Subject: [issue14055] Implement __sizeof__ for etree Element In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za> Message-ID: <1339918645.78.0.564031630235.issue14055@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Given how C's sizeof works, it may be debatable whether it's natural to expect that sys.getsizeof should be recursive. If you have a struct with pointers (say, char*) in C, and you do sizeof, the string length isn't considered, either. But I'm certainly fine with making this more clear. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14055> _______________________________________ From report at bugs.python.org Sun Jun 17 09:47:50 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 17 Jun 2012 07:47:50 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za> Message-ID: <1339919270.49.0.938919170554.issue14928@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: IIUC, this patch will cause importlib.h to always be built when building from source, since _freeze_importlib will be built. Is it then the plan to drop importlib.h from version control? If so, the Windows build process would need to be adjusted as well (with a separate project that is a prerequisite for pythoncore). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Sun Jun 17 09:54:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 07:54:30 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <E1SgAJY-0001Xh-Mt@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset afe67ea94bc6 by Jason R. Coombs in branch 'default': Adding test from issue6727 demonstrating that symlink import issue does not occur here in 3.3 http://hg.python.org/cpython/rev/afe67ea94bc6 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6727> _______________________________________ From report at bugs.python.org Sun Jun 17 09:58:03 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 17 Jun 2012 07:58:03 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <1339919883.75.0.343289711593.issue6727@psf.upfronthosting.co.za> Changes by Jason R. Coombs <jaraco at jaraco.com>: ---------- versions: -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6727> _______________________________________ From report at bugs.python.org Sun Jun 17 10:16:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jun 2012 08:16:19 +0000 Subject: [issue15090] Add etag support to urllib.request.urlretrieve() In-Reply-To: <1339916557.45.0.663415683134.issue15090@psf.upfronthosting.co.za> Message-ID: <1339920979.0.0.608446636677.issue15090@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15090> _______________________________________ From report at bugs.python.org Sun Jun 17 10:17:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jun 2012 08:17:59 +0000 Subject: [issue15089] Add gzip support to urllib.request.retrieve() In-Reply-To: <1339915873.52.0.115462585972.issue15089@psf.upfronthosting.co.za> Message-ID: <1339921079.19.0.652075870032.issue15089@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Isn't this a duplicate of issue1508475? ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15089> _______________________________________ From report at bugs.python.org Sun Jun 17 10:21:48 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 08:21:48 +0000 Subject: [issue15044] _dbm not building on Fedora 17 In-Reply-To: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za> Message-ID: <1339921308.47.0.679752328475.issue15044@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Patch works for me, and looks pretty safe for other platforms. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15044> _______________________________________ From report at bugs.python.org Sun Jun 17 10:22:13 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 17 Jun 2012 08:22:13 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <1339921333.89.0.467785126809.issue6727@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: I don't know what changed in 3.3 to address this issue; likely candidates are the VS 2010 upgrade or the rewrite of the import machinery. In either case, best I can tell, 3.3 is no longer implicated. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6727> _______________________________________ From report at bugs.python.org Sun Jun 17 10:24:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jun 2012 08:24:39 +0000 Subject: [issue15087] Add gzip function to read gzip'd strings In-Reply-To: <1339896879.03.0.627255791455.issue15087@psf.upfronthosting.co.za> Message-ID: <1339921479.09.0.169658282537.issue15087@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Why not simple gzip.GzipFile(fileobj=u).read()? ---------- nosy: +storchaka status: pending -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15087> _______________________________________ From report at bugs.python.org Sun Jun 17 10:28:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 08:28:11 +0000 Subject: [issue15044] _dbm not building on Fedora 17 In-Reply-To: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za> Message-ID: <E1SgAq9-0003co-Nf@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset e2be1f43beed by Nick Coghlan in branch '3.2': Issue #15044: Handle Fedora 17's approach to ndbm compatibility http://hg.python.org/cpython/rev/e2be1f43beed New changeset 1f6c23ed8218 by Nick Coghlan in branch 'default': Merge from 3.2. (Issue #15044: Handle Fedora 17's approach to ndbm compatibility) http://hg.python.org/cpython/rev/1f6c23ed8218 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15044> _______________________________________ From report at bugs.python.org Sun Jun 17 10:31:18 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 17 Jun 2012 08:31:18 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <1339921878.25.0.262628992085.issue6727@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: It seems that by adding the test to the default branch, the buildbots are now broken for Unix systems (they're failing the test). I'm going to await the results from the Windows buildbots, and then skip the tests on the failing platforms. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6727> _______________________________________ From report at bugs.python.org Sun Jun 17 10:35:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 08:35:54 +0000 Subject: [issue15044] _dbm not building on Fedora 17 In-Reply-To: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za> Message-ID: <E1SgAxd-00044o-8l@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 4d62f788aa19 by Nick Coghlan in branch '2.7': Issue #15044: Handle Fedora 17's approach to ndbm compatibility (backport from 3.x) http://hg.python.org/cpython/rev/4d62f788aa19 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15044> _______________________________________ From report at bugs.python.org Sun Jun 17 10:37:58 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 08:37:58 +0000 Subject: [issue15044] _dbm not building on Fedora 17 In-Reply-To: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za> Message-ID: <1339922278.65.0.369940525553.issue15044@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I committed the fix to at least get things building again, but this should probably get a NEWS entry (since builds that would have previously used gdbm directly will now use it in ndbm compatibility mode instead) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15044> _______________________________________ From report at bugs.python.org Sun Jun 17 10:42:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 08:42:09 +0000 Subject: [issue14055] Implement __sizeof__ for etree Element In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za> Message-ID: <E1SgB3f-0004P2-8q@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 093dec81ea1f by Martin v. L?wis in branch 'default': Issue #14055: Add __sizeof__ support to _elementtree. http://hg.python.org/cpython/rev/093dec81ea1f ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14055> _______________________________________ From report at bugs.python.org Sun Jun 17 10:43:47 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 17 Jun 2012 08:43:47 +0000 Subject: [issue14055] Implement __sizeof__ for etree Element In-Reply-To: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za> Message-ID: <1339922627.18.0.285657739555.issue14055@psf.upfronthosting.co.za> Changes by Martin v. L?wis <martin at v.loewis.de>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14055> _______________________________________ From report at bugs.python.org Sun Jun 17 10:58:29 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Sun, 17 Jun 2012 08:58:29 +0000 Subject: [issue15044] _dbm not building on Fedora 17 In-Reply-To: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za> Message-ID: <1339923509.23.0.10108501077.issue15044@psf.upfronthosting.co.za> Ross Lagerwall <rosslagerwall at gmail.com> added the comment: Yeah, after I submitted the patch, I was unsure if that was a good idea or if it should try and use gdbm in native mode if possible. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15044> _______________________________________ From report at bugs.python.org Sun Jun 17 11:00:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 09:00:50 +0000 Subject: [issue15043] test_gdb is disallowed by default security settings in Fedora 17 In-Reply-To: <1339418920.32.0.804230672204.issue15043@psf.upfronthosting.co.za> Message-ID: <E1SgBLk-0005Xg-Uq@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2db5010a610c by Nick Coghlan in branch '3.2': Issue #15043: skip test_gdb if the custom hooks can't be loaded http://hg.python.org/cpython/rev/2db5010a610c ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15043> _______________________________________ From report at bugs.python.org Sun Jun 17 11:04:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 09:04:09 +0000 Subject: [issue15043] test_gdb is disallowed by default security settings in Fedora 17 In-Reply-To: <1339418920.32.0.804230672204.issue15043@psf.upfronthosting.co.za> Message-ID: <E1SgBOw-0005fm-BA@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset ac2f5067c220 by Nick Coghlan in branch '2.7': Issue #15043: skip test_gdb if the custom hooks can't be loaded (backport from 3.x) http://hg.python.org/cpython/rev/ac2f5067c220 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15043> _______________________________________ From report at bugs.python.org Sun Jun 17 11:04:15 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 17 Jun 2012 09:04:15 +0000 Subject: [issue15091] ImportError when package is symlinked on Unix Message-ID: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za> New submission from Jason R. Coombs <jaraco at jaraco.com>: In testing issue6727, I added a test (http://hg.python.org/cpython/rev/afe67ea94bc6) to the default branch. The test passes on Windows, but fails on some of the Unix buildbots. Here's a quick breakdown of where it's passing and failing: fail: x86 Gentoo 3.x x86 Gentoo Non-Debug 3.x x86 Ubuntu Shared 3.x AMD64 FreeBSD 9.0 3.x x86 debian parallel 3.x x86 RHEL 6 3.x ARM Ubuntu 3.x x86 Solaris 11 3.x pass: AMD64 Gentoo Wide 3.x AMD64 Ubuntu LTS 3.x AMD64 OpenIndiana 3.x AMD64 Fedora without threads 3.x AMD64 Ubuntu LTS bigmem 3.x x86 Tiger 3.x x86 OpenIndiana 3.x x86 FreeBSD 7.2 3.x x86 FreeBSD 6.4 3.x As far as I can tell, the failures don't seem to have an obvious correlation. I will be disabling this test for non-Windows boxes, but it's probably worth tracking down why the test is failing. I should also note that this test is included in Python 2.7 and does not fail on the Unix. ---------- components: Interpreter Core messages: 163039 nosy: brett.cannon, jason.coombs priority: normal severity: normal status: open title: ImportError when package is symlinked on Unix versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15091> _______________________________________ From report at bugs.python.org Sun Jun 17 11:06:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 09:06:33 +0000 Subject: [issue15091] ImportError when package is symlinked on Unix In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za> Message-ID: <E1SgBRH-0005qZ-SW@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 939a68f5d14c by Jason R. Coombs in branch 'default': Disable test on Unix. Causes buildbots to fail. See Issue #15091 http://hg.python.org/cpython/rev/939a68f5d14c ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15091> _______________________________________ From report at bugs.python.org Sun Jun 17 11:08:04 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 17 Jun 2012 09:08:04 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <1339924084.07.0.380323155326.issue6727@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: I've disabled the test on non-Windows systems and created issue15091 to track the issue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6727> _______________________________________ From report at bugs.python.org Sun Jun 17 11:20:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 09:20:00 +0000 Subject: [issue15043] test_gdb is disallowed by default security settings in Fedora 17 In-Reply-To: <1339418920.32.0.804230672204.issue15043@psf.upfronthosting.co.za> Message-ID: <E1SgBeJ-0006jk-7J@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 9456591d0761 by Nick Coghlan in branch 'default': Merge from 3.2 (Issue #15043: skip test_gdb if the custom hooks can't be loaded) http://hg.python.org/cpython/rev/9456591d0761 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15043> _______________________________________ From report at bugs.python.org Sun Jun 17 11:21:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jun 2012 09:21:08 +0000 Subject: [issue15092] Using enum PyUnicode_Kind Message-ID: <1339924867.59.0.117831113894.issue15092@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: Now a string kind declared in different places of code as `enum PyUnicode_Kind`, `int` or `unsigned int`. Working on the codecs optimization, I noticed that sometimes the use of `enum PyUnicode_Kind` gives a little advantage over the use of int's. Probably this hint allows compiler to better utilize the optimizer. The proposed patch replaces all string kind's declarations of local variables and private functions to `enum PyUnicode_Kind`. If this will not impact significantly on the performance, then at least the unification will enhance the readability and will allow to avoid some of the errors (missing switch cases). ---------- components: Interpreter Core files: enum_PyUnicode_Kind.patch keywords: patch messages: 163043 nosy: storchaka priority: normal severity: normal status: open title: Using enum PyUnicode_Kind type: performance versions: Python 3.3 Added file: http://bugs.python.org/file26033/enum_PyUnicode_Kind.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15092> _______________________________________ From report at bugs.python.org Sun Jun 17 11:28:57 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 17 Jun 2012 09:28:57 +0000 Subject: [issue15093] ntpath.isdir returns False for directory symlinks Message-ID: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za> New submission from Jason R. Coombs <jaraco at jaraco.com>: On Unix: python -c "import os; os.mkdir('bar'); os.symlink('bar', 'foo'); print(os.path.isdir('foo'))" True On Windows: python -c "import os; os.mkdir('bar'); os.symlink('bar', 'foo'); print(os.path.isdir('foo'))" False Windows should correctly discern the directory-ness of a symlink (especially since in Windows, the symlink itself has a directory-ness). ---------- components: Windows messages: 163044 nosy: jason.coombs priority: normal severity: normal status: open title: ntpath.isdir returns False for directory symlinks versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15093> _______________________________________ From report at bugs.python.org Sun Jun 17 11:30:40 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 17 Jun 2012 09:30:40 +0000 Subject: [issue13823] xml.etree.ElementTree.ElementTree.write - argument checking In-Reply-To: <1326963107.43.0.928827185581.issue13823@psf.upfronthosting.co.za> Message-ID: <1339925440.28.0.923071864258.issue13823@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- nosy: +flox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13823> _______________________________________ From report at bugs.python.org Sun Jun 17 11:33:35 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 17 Jun 2012 09:33:35 +0000 Subject: [issue14973] restore python2 unicode literals in "ur" strings In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za> Message-ID: <1339925615.79.0.42068390574.issue14973@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: See also http://mail.python.org/pipermail/python-list/2012-June/625406.html ---------- nosy: +aronacher, vinay.sajip _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14973> _______________________________________ From report at bugs.python.org Sun Jun 17 11:34:55 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 09:34:55 +0000 Subject: [issue15043] test_gdb is disallowed by default security settings in Fedora 17 In-Reply-To: <1339418920.32.0.804230672204.issue15043@psf.upfronthosting.co.za> Message-ID: <1339925695.58.0.354374053009.issue15043@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Added new section to devguide in http://hg.python.org/devguide/rev/9fee8e6c2619 ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15043> _______________________________________ From report at bugs.python.org Sun Jun 17 11:36:29 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 17 Jun 2012 09:36:29 +0000 Subject: [issue15091] ImportError when package is symlinked on Unix In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za> Message-ID: <1339925789.41.0.254265252303.issue15091@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: I should point out that some of those failures (e.g. x86 Solaris 11 3.x) weren't triggered by the change, but many were. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15091> _______________________________________ From report at bugs.python.org Sun Jun 17 11:49:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 09:49:55 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1339919270.49.0.938919170554.issue14928@psf.upfronthosting.co.za> Message-ID: <1339926402.3369.2.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > IIUC, this patch will cause importlib.h to always be built when > building from source, since _freeze_importlib will be built. Yes indeed. That's not deliberate, but because of how Makefile dependencies are specified (importlib.h needs the _freeze_importlib executable to be rebuilt, but it should really depend on the _freeze_importlib.c timestamp). Do you have an idea to avoid that? > Is it then the plan to drop importlib.h from version control? No. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Sun Jun 17 11:55:30 2012 From: report at bugs.python.org (Waldemar Kornewald) Date: Sun, 17 Jun 2012 09:55:30 +0000 Subject: [issue15091] ImportError when package is symlinked on Unix In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za> Message-ID: <1339926930.16.0.0419389005026.issue15091@psf.upfronthosting.co.za> Changes by Waldemar Kornewald <wkornewald at gmail.com>: ---------- nosy: +wkornewald _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15091> _______________________________________ From report at bugs.python.org Sun Jun 17 11:56:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 17 Jun 2012 09:56:38 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1339926402.3369.2.camel@localhost.localdomain> Message-ID: <4FDDA9D2.8070101@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Yes indeed. That's not deliberate, but because of how Makefile > dependencies are specified (importlib.h needs the _freeze_importlib > executable to be rebuilt, but it should really depend on the > _freeze_importlib.c timestamp). Do you have an idea to avoid that? Recursive make invocation may help. Before running _freeze_importlib, add '$(MAKE) _freeze_importlib'. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Sun Jun 17 11:57:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jun 2012 09:57:27 +0000 Subject: [issue15094] Incorrectly placed #endif in _tkinter.c. Message-ID: <1339927047.37.0.67596869478.issue15094@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: #endif is placed incorrectly in _tkinter.c. As a result, braces are unbalanced when TCL_UTF_MAX != 3. This is Python 3.3 only error. There are no tests yet. Just wait a few years until TCL will support non-BMP characters or use a time machine. ---------- components: Extension Modules, Tkinter files: tkinter_endif.patch keywords: patch messages: 163050 nosy: storchaka priority: normal severity: normal status: open title: Incorrectly placed #endif in _tkinter.c. type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file26034/tkinter_endif.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15094> _______________________________________ From report at bugs.python.org Sun Jun 17 12:15:41 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 10:15:41 +0000 Subject: [issue15043] test_gdb is disallowed by default security settings in Fedora 17 In-Reply-To: <1339418920.32.0.804230672204.issue15043@psf.upfronthosting.co.za> Message-ID: <1339928141.95.0.654089320901.issue15043@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Also added an FAQ with the specific ~/.gdbinit entry needed to get it running in http://hg.python.org/devguide/rev/1d81501be702 I did try adding a similar command directly to the gdb invocation, but, as far as I can tell, any commands specified as arguments run too late to allow python-gdb.py to be loaded with the current command line invocation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15043> _______________________________________ From report at bugs.python.org Sun Jun 17 12:22:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 10:22:01 +0000 Subject: [issue15092] Using enum PyUnicode_Kind In-Reply-To: <1339924867.59.0.117831113894.issue15092@psf.upfronthosting.co.za> Message-ID: <1339928521.99.0.63634498885.issue15092@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +haypo stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15092> _______________________________________ From report at bugs.python.org Sun Jun 17 12:28:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 10:28:13 +0000 Subject: [issue15094] Incorrectly placed #endif in _tkinter.c. In-Reply-To: <1339927047.37.0.67596869478.issue15094@psf.upfronthosting.co.za> Message-ID: <1339928893.69.0.407835493924.issue15094@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15094> _______________________________________ From report at bugs.python.org Sun Jun 17 12:29:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 10:29:05 +0000 Subject: [issue15087] Add gzip function to read gzip'd strings In-Reply-To: <1339896879.03.0.627255791455.issue15087@psf.upfronthosting.co.za> Message-ID: <1339928945.44.0.143285952675.issue15087@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- resolution: invalid -> out of date status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15087> _______________________________________ From report at bugs.python.org Sun Jun 17 12:31:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 10:31:26 +0000 Subject: [issue15090] Add etag support to urllib.request.urlretrieve() In-Reply-To: <1339916557.45.0.663415683134.issue15090@psf.upfronthosting.co.za> Message-ID: <1339929086.43.0.619298745544.issue15090@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: urlretrieve() is the old urllib interface. You probably want to improve the urllib2-inherited urlopen() instead. ---------- nosy: +orsenthil, pitrou versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15090> _______________________________________ From report at bugs.python.org Sun Jun 17 12:32:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 10:32:19 +0000 Subject: [issue15089] Add gzip support to urllib.request.retrieve() In-Reply-To: <1339915873.52.0.115462585972.issue15089@psf.upfronthosting.co.za> Message-ID: <1339929139.92.0.781127910784.issue15089@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- resolution: -> duplicate status: open -> closed superseder: -> transparent gzip compression in urllib _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15089> _______________________________________ From report at bugs.python.org Sun Jun 17 12:44:01 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 17 Jun 2012 10:44:01 +0000 Subject: [issue15093] ntpath.isdir returns False for directory symlinks In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za> Message-ID: <1339929841.19.0.639226876332.issue15093@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' <g.rodola at gmail.com>: ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15093> _______________________________________ From report at bugs.python.org Sun Jun 17 13:09:55 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 11:09:55 +0000 Subject: [issue15095] test_imaplib problem - intermittent skips and LOGINDISABLED not reported Message-ID: <1339931394.61.0.931073792835.issue15095@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: When running the test suite on Fedora 17 (and behind a couple of layers of NAT), I see the following problems: Intermittently: skipped "Resource 'cyrus.andrew.cmu.edu' is not available" Consistently (with a couple of tests updated to use the improved assertion methods for containment testing): ====================================================================== FAIL: test_logincapa (test.test_imaplib.RemoteIMAPTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ncoghlan/devel/py32/Lib/test/test_imaplib.py", line 236, in test_logincapa self.assertIn('LOGINDISABLED', self.server.capabilities) AssertionError: 'LOGINDISABLED' not found in ('IMAP4REV1', 'LITERAL+', 'ID', 'ENABLE', 'ACL', 'RIGHTS=KXTE', 'QUOTA', 'MAILBOX-REFERRALS', 'NAMESPACE', 'UIDPLUS', 'NO_ATOMIC_RENAME', 'UNSELECT', 'CHILDREN', 'MULTIAPPEND', 'BINARY', 'CATENATE', 'CONDSTORE', 'ESEARCH', 'SORT', 'SORT=MODSEQ', 'SORT=DISPLAY', 'THREAD=ORDEREDSUBJECT', 'THREAD=REFERENCES', 'ANNOTATEMORE', 'LIST-EXTENDED', 'WITHIN', 'QRESYNC', 'SCAN', 'XLIST', 'URLAUTH', 'URLAUTH=BINARY', 'MUPDATE=MUPDATE://MUPDATE.ANDREW.CMU.EDU/', 'AUTH=GSSAPI', 'AUTH=PLAIN', 'AUTH=ANONYMOUS', 'SASL-IR', 'STARTTLS') ---------- messages: 163053 nosy: ncoghlan priority: normal severity: normal status: open title: test_imaplib problem - intermittent skips and LOGINDISABLED not reported versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15095> _______________________________________ From report at bugs.python.org Sun Jun 17 13:16:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 11:16:46 +0000 Subject: [issue15095] test_imaplib problem - intermittent skips and LOGINDISABLED not reported In-Reply-To: <1339931394.61.0.931073792835.issue15095@psf.upfronthosting.co.za> Message-ID: <E1SgDSx-0005ai-GE@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 4028bb7a5ac2 by Nick Coghlan in branch '3.2': Issue #15095: Use better assertions in test_imaplib http://hg.python.org/cpython/rev/4028bb7a5ac2 New changeset bbe1a2049ca1 by Nick Coghlan in branch 'default': Merge from 3.2 (Issue #15095: Use better assertions in test_imaplib) http://hg.python.org/cpython/rev/bbe1a2049ca1 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15095> _______________________________________ From report at bugs.python.org Sun Jun 17 13:27:15 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 17 Jun 2012 11:27:15 +0000 Subject: [issue13455] Reorganize tracker docs in the devguide In-Reply-To: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za> Message-ID: <1339932435.24.0.736270509361.issue13455@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: The attached patch has been committed in 252e2aabc87a, and the wiki pages have been updated to link to the devguide. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13455> _______________________________________ From report at bugs.python.org Sun Jun 17 13:33:13 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 17 Jun 2012 11:33:13 +0000 Subject: [issue13515] Consistent documentation practices for security concerns and considerations In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za> Message-ID: <1339932793.03.0.512547712739.issue13515@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: The new theme of the docs should solve the issue about the scary red boxes, but the original report is still valid. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13515> _______________________________________ From report at bugs.python.org Sun Jun 17 13:37:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 11:37:19 +0000 Subject: [issue14919] what disables one from adding self to the "nosy" list In-Reply-To: <1337964276.05.0.327308817778.issue14919@psf.upfronthosting.co.za> Message-ID: <E1SgDnA-0006ve-9z@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2171bb071dd6 by Ezio Melotti in branch 'default': #14919: clarify paragraph in the devguide. http://hg.python.org/devguide/rev/2171bb071dd6 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14919> _______________________________________ From report at bugs.python.org Sun Jun 17 13:37:50 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 17 Jun 2012 11:37:50 +0000 Subject: [issue14919] what disables one from adding self to the "nosy" list In-Reply-To: <1337964276.05.0.327308817778.issue14919@psf.upfronthosting.co.za> Message-ID: <1339933070.25.0.883834831455.issue14919@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14919> _______________________________________ From report at bugs.python.org Sun Jun 17 13:42:25 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 17 Jun 2012 11:42:25 +0000 Subject: [issue14469] Python 3 documentation links In-Reply-To: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za> Message-ID: <1339933345.4.0.282225340611.issue14469@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14469> _______________________________________ From report at bugs.python.org Sun Jun 17 13:43:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 11:43:28 +0000 Subject: [issue13797] Allow objects implemented in pure Python to export PEP 3118 buffers In-Reply-To: <1326709751.32.0.965094376059.issue13797@psf.upfronthosting.co.za> Message-ID: <1339933408.82.0.698542226615.issue13797@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I suggest a PEP for 3.4 as the best way forward for this. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13797> _______________________________________ From report at bugs.python.org Sun Jun 17 14:13:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 12:13:57 +0000 Subject: [issue14840] Tutorial: Add a bit on the difference between tuples and lists In-Reply-To: <1337273770.17.0.397614380243.issue14840@psf.upfronthosting.co.za> Message-ID: <E1SgEMb-0001f2-7p@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset bb63919cde6e by Ezio Melotti in branch '2.7': #14840: Add a bit on the difference between tuples and lists. Initial patch by Zachary Ware. http://hg.python.org/cpython/rev/bb63919cde6e New changeset 3550416d83b3 by Ezio Melotti in branch '3.2': #14840: Add a bit on the difference between tuples and lists. Initial patch by Zachary Ware. http://hg.python.org/cpython/rev/3550416d83b3 New changeset 2fad115408e9 by Ezio Melotti in branch 'default': #14840: merge with 3.2. http://hg.python.org/cpython/rev/2fad115408e9 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14840> _______________________________________ From report at bugs.python.org Sun Jun 17 14:15:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 17 Jun 2012 12:15:47 +0000 Subject: [issue14840] Tutorial: Add a bit on the difference between tuples and lists In-Reply-To: <1337273770.17.0.397614380243.issue14840@psf.upfronthosting.co.za> Message-ID: <1339935347.35.0.745026847554.issue14840@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14840> _______________________________________ From report at bugs.python.org Sun Jun 17 14:16:51 2012 From: report at bugs.python.org (Michael Foord) Date: Sun, 17 Jun 2012 12:16:51 +0000 Subject: [issue14215] http://www.python.org/dev/peps/ title is python.org In-Reply-To: <1331102600.96.0.801989456091.issue14215@psf.upfronthosting.co.za> Message-ID: <1339935411.96.0.917084666356.issue14215@psf.upfronthosting.co.za> Michael Foord <michael at voidspace.org.uk> added the comment: As the PEPs are "development docs", like the Python documentation itself, I wouldn't have *expected* it to be covered by the redesign. Does this require anything more than an update to the PEP index template? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14215> _______________________________________ From report at bugs.python.org Sun Jun 17 14:17:39 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 12:17:39 +0000 Subject: [issue15096] Drop support for the "ur" string prefix Message-ID: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: When PEP 414 restored support for explicit Unicode literals in Python 3, the "ur" string prefix was deemed to be a synonym for the "r" prefix. However, "ur" in 2.x was only kinda-sorta-raw, since it still supported Unicode escapes: $ python Python 2.7.3 (default, Apr 30 2012, 21:18:11) [GCC 4.7.0 20120416 (Red Hat 4.7.0-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print(ur'\u03B3') ? By contrast, they really are raw strings in 3.x, because the default UTF-8 source code encoding allows arbitrary Unicode characters to be included directly in the literal: $ ./python Python 3.3.0a4+ (default:cfbf6aa5c9e3+, Jun 17 2012, 15:25:45) [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> r"?" '?' >>> "\U000003B3" '?' >>> r"\U000003B3" '\\U000003B3' >>> ur"\U000003B3" '\\U000003B3' Rather than reintroducing this weird legacy not-really-raw string behaviour, I'd prefer to revert this aspect of the PEP 414 changes completely. ---------- components: Interpreter Core messages: 163062 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Drop support for the "ur" string prefix type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Sun Jun 17 14:18:03 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 12:18:03 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1339935483.13.0.92232189283.issue15096@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- priority: normal -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Sun Jun 17 14:20:29 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 17 Jun 2012 12:20:29 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1339935629.15.0.884995957621.issue15096@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Sun Jun 17 14:30:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jun 2012 12:30:41 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1339936241.84.0.300282849054.issue15096@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Sun Jun 17 14:30:46 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 12:30:46 +0000 Subject: [issue14215] http://www.python.org/dev/peps/ title is python.org In-Reply-To: <1331102600.96.0.801989456091.issue14215@psf.upfronthosting.co.za> Message-ID: <1339936246.51.0.17749590433.issue14215@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I'm expecting the "pep2pyramid.py" part to change at the very least. However, back on topic, I actually hit the limits of my knowledge of the PEP build process reading that script. As near as I can tell, PEP 0 should have the same "title" information as is available for the other PEPs. It does appear the individual PEPs and the index do use differently templates though, so that may be the source of the discrepancy. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14215> _______________________________________ From report at bugs.python.org Sun Jun 17 14:46:31 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 17 Jun 2012 12:46:31 +0000 Subject: [issue14215] http://www.python.org/dev/peps/ title is python.org In-Reply-To: <1331102600.96.0.801989456091.issue14215@psf.upfronthosting.co.za> Message-ID: <1339937191.29.0.626286298189.issue14215@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: The title for the PEPs seem to be set in the fixfile function, at the line 206. Maybe something like: if pep: title = "PEP " + pep + " -- " + title else: title = "PEP index" works, assuming that only title-less page is the index. ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14215> _______________________________________ From report at bugs.python.org Sun Jun 17 14:48:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jun 2012 12:48:06 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1339937286.93.0.0273409979483.issue3665@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Here is updated (in conforming with PEP 393) patch. In additional octal and hexadecimal escaping cleared, illegal error message for hexadecimal escaping fixed. Added new tests for octal and hexadecimal escaping. ---------- Added file: http://bugs.python.org/file26035/re_unicode_escapes-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3665> _______________________________________ From report at bugs.python.org Sun Jun 17 14:50:56 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 17 Jun 2012 12:50:56 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1339937456.97.0.62730932016.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Ok, I take the lack of negative reviews as a general approvement. I'll improve comments a bit, write the appropriate NEWS item and make a commit soon. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Sun Jun 17 14:58:53 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 17 Jun 2012 12:58:53 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1339937933.18.0.0248880332915.issue15096@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: +1 Raw unicode strings are rarely used and it's easy to overcome the limitation. I've created a patch that disabled ur'' syntax, updates the docs and adds some tests for u'' syntax. I couldn't find any tests for the syntax ... shame on you! :) ---------- keywords: +patch nosy: +christian.heimes Added file: http://bugs.python.org/file26036/issue15096-1.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Sun Jun 17 16:14:15 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 Jun 2012 14:14:15 +0000 Subject: [issue15095] test_imaplib problem - intermittent skips and LOGINDISABLED not reported In-Reply-To: <1339931394.61.0.931073792835.issue15095@psf.upfronthosting.co.za> Message-ID: <1339942455.01.0.781754032879.issue15095@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- components: +email nosy: +barry, r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15095> _______________________________________ From report at bugs.python.org Sun Jun 17 16:23:56 2012 From: report at bugs.python.org (Merlijn van Deen) Date: Sun, 17 Jun 2012 14:23:56 +0000 Subject: [issue15097] Improving wording on the thread-safeness of import Message-ID: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za> New submission from Merlijn van Deen <valhallasw at gmail.com>: http://docs.python.org/library/threading.html#importing-in-threaded-code Currently, the documentation states "Firstly, other than in the main module, an import should not have the side effect of spawning a new thread and then waiting for that thread in any way. Failing to abide by this restriction can lead to a deadlock if the spawned thread directly or indirectly attempts to import a module." which, I think, fails to make the main point: a call to import acquires the import lock. A call to import from a second thread will thus block. As such, I would suggest rephrasing it to something like: "Firstly, an import acquires the import lock for that thread. Therefore, the import should not have the side effect of waiting for a different thread in any way, as this can lead to a deadlock if that thread directly or indirectly attempts to import a module." There are two additional points that might be interesting to note: (1) Any module can be imported. If the import causes a deadlock, that is a bad thing. Every module *will* be imported by tools such as nosetests. (1b) so: never, ever, have code that causes locks in a different thread in module level code witout 'if __name__=="__main__" ' blocks? (2) The lock is also acquired if a module has already been imported. For instance, in import sys # (1) def f(): import sys # (2) the import lock is acquired in (1) /and/ (2). Adding example code and/or a flow diagram might be a bit too much, but it does clarify how easy it is to make this mistake. See the attached for an example (both a simple example script, as well as a flow diagram explaining what happens). ---------- assignee: docs at python components: Documentation files: deadlock.py messages: 163068 nosy: docs at python, valhallasw priority: normal severity: normal status: open title: Improving wording on the thread-safeness of import type: enhancement Added file: http://bugs.python.org/file26037/deadlock.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________ From report at bugs.python.org Sun Jun 17 16:25:16 2012 From: report at bugs.python.org (Merlijn van Deen) Date: Sun, 17 Jun 2012 14:25:16 +0000 Subject: [issue15097] Improving wording on the thread-safeness of import In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za> Message-ID: <1339943116.85.0.516982394956.issue15097@psf.upfronthosting.co.za> Changes by Merlijn van Deen <valhallasw at gmail.com>: Removed file: http://bugs.python.org/file26037/deadlock.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________ From report at bugs.python.org Sun Jun 17 16:26:08 2012 From: report at bugs.python.org (Merlijn van Deen) Date: Sun, 17 Jun 2012 14:26:08 +0000 Subject: [issue15097] Improving wording on the thread-safeness of import In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za> Message-ID: <1339943168.04.0.914133941941.issue15097@psf.upfronthosting.co.za> Changes by Merlijn van Deen <valhallasw at gmail.com>: Added file: http://bugs.python.org/file26038/deadlock.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________ From report at bugs.python.org Sun Jun 17 16:29:38 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 17 Jun 2012 14:29:38 +0000 Subject: [issue15089] Add gzip support to urllib.request.retrieve() In-Reply-To: <1339915873.52.0.115462585972.issue15089@psf.upfronthosting.co.za> Message-ID: <1339943378.92.0.444972281437.issue15089@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15089> _______________________________________ From report at bugs.python.org Sun Jun 17 16:30:41 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 17 Jun 2012 14:30:41 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1339943441.97.0.579520749745.issue1508475@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1508475> _______________________________________ From report at bugs.python.org Sun Jun 17 16:31:27 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 17 Jun 2012 14:31:27 +0000 Subject: [issue15090] Add etag support to urllib.request.urlretrieve() In-Reply-To: <1339916557.45.0.663415683134.issue15090@psf.upfronthosting.co.za> Message-ID: <1339943487.62.0.371765727064.issue15090@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15090> _______________________________________ From report at bugs.python.org Sun Jun 17 16:51:24 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 17 Jun 2012 14:51:24 +0000 Subject: [issue15097] Improving wording on the thread-safeness of import In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za> Message-ID: <4FDDEEE9.2050006@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > which, I think, fails to make the main point: I disagree. It currently makes it main point, but stops doing so under your rephrasing. The main point of that section is "While the import machinery is thread-safe, there are two key restrictions on threaded imports due to inherent limitations in the way that thread-safety is provided:" The existence of an import lock is deliberately omitted from the text, and the reader is supposed to abide by the restriction as written regardless of the motivation behind it. > Adding example code and/or a flow diagram might be a bit too much, > but it does clarify how easy it is to make this mistake. See the > attached for an example (both a simple example script, as well as a > flow diagram explaining what happens). The entire notion of an import lock is obsolete. Python 3.3 does not have that anymore. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________ From report at bugs.python.org Sun Jun 17 17:23:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 17 Jun 2012 15:23:00 +0000 Subject: [issue14840] Tutorial: Add a bit on the difference between tuples and lists In-Reply-To: <1337273770.17.0.397614380243.issue14840@psf.upfronthosting.co.za> Message-ID: <1339946580.94.0.24271124771.issue14840@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Great addition, thanks! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14840> _______________________________________ From report at bugs.python.org Sun Jun 17 17:38:47 2012 From: report at bugs.python.org (Merlijn van Deen) Date: Sun, 17 Jun 2012 15:38:47 +0000 Subject: [issue15097] Improving wording on the thread-safeness of import In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za> Message-ID: <1339947527.89.0.899071676959.issue15097@psf.upfronthosting.co.za> Merlijn van Deen <valhallasw at gmail.com> added the comment: First off, thank you for your response. > The existence of an import lock is deliberately omitted from the text, > and the reader is supposed to abide by the restriction as written > regardless of the motivation behind it. > The entire notion of an import lock is obsolete. Python 3.3 does not > have that anymore. " This warning is still valid but for a different reason " or " this warning is no longer valid in 3.3 "? Assuming the first (which is what I guess based on the fact the deadlock still occurs in 3.3), I think the text can still be improved; the current wording suggests to me a) it's OK to wait for a thread as long as you did not create it and b) it's OK to import something that waits for a thread as long as you do it from the main module - while both cases can still lead to a deadlock. so, leaving the implementation details out, this is my suggestion: "Firstly, an import should not have the side effect of waiting for a thread in any way. This can lead to a deadlock if that thread directly or indirectly attempts to import a module." ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________ From report at bugs.python.org Sun Jun 17 17:39:28 2012 From: report at bugs.python.org (Marco Buccini) Date: Sun, 17 Jun 2012 15:39:28 +0000 Subject: [issue15098] "TypeError" can give a misleading message Message-ID: <1339947568.49.0.0833314799207.issue15098@psf.upfronthosting.co.za> New submission from Marco Buccini <marcusbu at gmail.com>: Suppose that you have an instance method that takes 2 arguments: one is required, while the other is a keyword argument. If you call that method without passing the required argument, but instead you only set the keyword argument, then you will get a TypeError exception, claiming this ... -> TypeError: 'method' takes at least 2 arguments (2 given) (I am referring to this particular method: http://www.voidspace.org.uk/python/mock/mock.html#mock.Mock.mock_add_spec) @patch('xyz.subprocess.Popen') def test_xyz(self, mocked_popen): mocked_popen.mock_add_spec(spec_set=True) I think the right error message should be different, in particular should be this: -> TypeError: 'method' takes at least 2 arguments (1 given) ---------- components: Interpreter Core messages: 163072 nosy: markon priority: normal severity: normal status: open title: "TypeError" can give a misleading message type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15098> _______________________________________ From report at bugs.python.org Sun Jun 17 17:43:50 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 Jun 2012 15:43:50 +0000 Subject: [issue15098] "TypeError" can give a misleading message In-Reply-To: <1339947568.49.0.0833314799207.issue15098@psf.upfronthosting.co.za> Message-ID: <1339947830.26.0.331483858601.issue15098@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: This is fixed in Python3: >>> def foo(a, b=None): ... pass ... >>> foo(b=1) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: foo() missing 1 required positional argument: 'a' ---------- nosy: +r.david.murray resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15098> _______________________________________ From report at bugs.python.org Sun Jun 17 17:56:52 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 17 Jun 2012 15:56:52 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1339948612.83.0.362045906303.issue14814@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: A small markup error in the doc: in ?.. exception:: Custom(ValueError)? (as in ?.. class:: SomeThing(BaseThing)?), the parens are supposed to contain the signature for the constructor, not the base classes. (Sorry I?m not replying to the python-checkins email; my diff colorizer extension was disabled due to mailer version update so I delete the -checkins messages and to read changesets on hgweb now.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Sun Jun 17 17:57:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 17 Jun 2012 15:57:17 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1339948637.79.0.78538417534.issue14814@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Forgot the reference: http://sphinx.pocoo.org/domains.html#directive-py:exception ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Sun Jun 17 17:58:33 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 17 Jun 2012 15:58:33 +0000 Subject: [issue15082] [httplib] httplib.BadStatusLine on any HTTPS connection in certain unknown cases. In-Reply-To: <1339811528.79.0.0690651710917.issue15082@psf.upfronthosting.co.za> Message-ID: <1339948713.59.0.349159988989.issue15082@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15082> _______________________________________ From report at bugs.python.org Sun Jun 17 18:07:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 16:07:08 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za> Message-ID: <1339949228.54.0.664040602171.issue14928@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: New patch incorporating Martin's and Nick's suggestions. ---------- Added file: http://bugs.python.org/file26039/cfreeze2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Sun Jun 17 18:16:16 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 17 Jun 2012 16:16:16 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1339949776.22.0.624052584259.issue15096@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- nosy: +aronacher, flox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Sun Jun 17 18:17:36 2012 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 17 Jun 2012 16:17:36 +0000 Subject: [issue14991] Option for regex groupdict() to show only matching names In-Reply-To: <1338742861.24.0.324062376049.issue14991@psf.upfronthosting.co.za> Message-ID: <1339949856.7.0.763599196105.issue14991@psf.upfronthosting.co.za> Matthew Barnett <python at mrabarnett.plus.com> added the comment: @rhettinger: The problem with "nodefault" is that it's negative, so that "nodefault=False" means that you don't not want the default, if you see what I mean. I think that "suppress" would be better: mo.groupdict(suppress=True) @larry: If the parameter was "default", would that mean that you could provide a different default, such as: mo.groupdict(default="") ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14991> _______________________________________ From report at bugs.python.org Sun Jun 17 18:20:34 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 17 Jun 2012 16:20:34 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1339950034.46.0.579586202832.issue15096@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- nosy: +vinay.sajip _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Sun Jun 17 18:36:04 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 Jun 2012 16:36:04 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339937933.18.0.0248880332915.issue15096@psf.upfronthosting.co.za> Message-ID: <1339950975.1668.3.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > I've created a patch that disabled ur'' syntax, updates the docs and adds some tests for u'' syntax. Don't forget tokenize module (see issue15054). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Sun Jun 17 19:56:46 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 Jun 2012 17:56:46 +0000 Subject: [issue15087] Add gzip function to read gzip'd strings In-Reply-To: <1339896879.03.0.627255791455.issue15087@psf.upfronthosting.co.za> Message-ID: <1339955806.9.0.542065878914.issue15087@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: Thanks. I didn't know that this had already been added to 3.2 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15087> _______________________________________ From report at bugs.python.org Sun Jun 17 20:08:52 2012 From: report at bugs.python.org (Ben Wolfson) Date: Sun, 17 Jun 2012 18:08:52 +0000 Subject: [issue12014] str.format parses replacement field incorrectly In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za> Message-ID: <1339956532.06.0.818294995802.issue12014@psf.upfronthosting.co.za> Ben Wolfson <wolfson at gmail.com> added the comment: I can certainly address those issues---I'll hold off on doing so, though, until it's clearer whether more substantive things come up, so I can just do it in a swoop. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12014> _______________________________________ From report at bugs.python.org Sun Jun 17 20:26:35 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 17 Jun 2012 18:26:35 +0000 Subject: [issue14991] Option for regex groupdict() to show only matching names In-Reply-To: <1338742861.24.0.324062376049.issue14991@psf.upfronthosting.co.za> Message-ID: <1339957595.33.0.686687737767.issue14991@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: @mrabarnett: That's right--except your tense is wrong. mo.groupdict() has supported the "default" parameter since the function was first added, way back in 1.5.2. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14991> _______________________________________ From report at bugs.python.org Sun Jun 17 22:13:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 Jun 2012 20:13:29 +0000 Subject: [issue14215] http://www.python.org/dev/peps/ title is python.org In-Reply-To: <1331102600.96.0.801989456091.issue14215@psf.upfronthosting.co.za> Message-ID: <1339964009.46.0.610017238892.issue14215@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: As near as I can tell, pep will hold the string value "0" for the PEP index, thus the title should still be getting set. That's why I suspect a templating difference. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14215> _______________________________________ From report at bugs.python.org Sun Jun 17 22:36:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 Jun 2012 20:36:57 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <E1SgMDP-0002zk-HD@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset e3a984076837 by Antoine Pitrou in branch 'default': Issue #14657: The frozen instance of importlib used for bootstrap is now also the module imported as importlib._bootstrap. http://hg.python.org/cpython/rev/e3a984076837 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14657> _______________________________________ From report at bugs.python.org Sun Jun 17 22:40:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 20:40:03 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1339965603.58.0.330235720422.issue14657@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Ok, I've committed the patch. I'm closing this issue, but of course potential improvements can be posted under a new issue. ---------- dependencies: -test.support.DirsOnSysPath should be replaced by importlib.test.util.import_state resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14657> _______________________________________ From report at bugs.python.org Sun Jun 17 22:40:11 2012 From: report at bugs.python.org (Daniel C.) Date: Sun, 17 Jun 2012 20:40:11 +0000 Subject: [issue15071] TLS get keys and randoms In-Reply-To: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za> Message-ID: <1339965611.25.0.860959290328.issue15071@psf.upfronthosting.co.za> Daniel C. <llaniscudani at gmail.com> added the comment: This function solve the problem "SSL_tls1_key_exporter" http://comments.gmane.org/gmane.comp.encryption.openssl.user/42015 included in the development version of OpenSSL 1.0.1 in the CVS how is the correct way to implement in the python bind? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15071> _______________________________________ From report at bugs.python.org Sun Jun 17 23:04:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 17 Jun 2012 21:04:30 +0000 Subject: [issue15071] TLS get keys and randoms In-Reply-To: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za> Message-ID: <1339967070.76.0.602679058949.issue15071@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Ok, so it seems the functionality is described in http://tools.ietf.org/html/rfc5705. If I understand correctly, it takes an ASCII label string, an optional context bytestring, and the length of the desired derived key. It then returns a bytestring of the given length, shared between client and server. The low-level implementation of the ssl module is in Modules/_ssl.c. We probably want to add a method to PySSLSocket_Type there. Then in Lib/ssl.py there'll have to be a SSLSocket method to call the former method. Tests should go in Lib/test/test_ssl.py. ---------- stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15071> _______________________________________ From report at bugs.python.org Sun Jun 17 23:12:49 2012 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 17 Jun 2012 21:12:49 +0000 Subject: [issue12014] str.format parses replacement field incorrectly In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za> Message-ID: <1339967569.16.0.2564164552.issue12014@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- nosy: +flox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12014> _______________________________________ From report at bugs.python.org Mon Jun 18 08:17:11 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 Jun 2012 06:17:11 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340000231.24.0.582142232915.issue14814@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: > the interfaces of the v4 and v6 variants are deliberately very similar I am hoping that means 'identical, once the obvious translations are made': v4 to v6, xxx.xxx.xxx.xxx to <whatever the v6 notation is>, and anything else? > documenting everything twice seems like a rather user hostile thing to do. Agreed. Please factor out common stuff. I see two choices. 1. Document in parallel after an intro explaining the translations xxxx4yyyy(args) xxxx6yyyy(args) Return ... (either in 4 terms which user translate for 6 or generic terms). # This might be better if you expect people to be doing one type of thing with both v4 and v6. 2. Document serially, first v4 stuff then v6 stuff (at present, though order might be reversed in the future ;-). v4 stuff ------- xxxx4yyyy(args) Return ... v6 stuff ------- The following v6 functions are the same as the v4 functions above, except that ipv4address'es become ipv6address'es etc. xxxx6uuuu(args) # This might be better if you expect people to be doing multiple things with either v4 or v6, but not both. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 18 09:14:59 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 18 Jun 2012 07:14:59 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340003699.85.0.264274034254.issue14814@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: My current thoughts are to avoid the usual approach of embedding the method and property definitions in the class definitions, and instead have separate sections under [1] for IP Addresses IP Interfaces IP Networks Inside each of those sections, document the constructors directly under the section heading, and then separate out these subsections: Common IP <kind> properties and methods IPv4 <kind> properties and methods (if any) IPv6 <kind> properties and methods (if any) [1] http://docs.python.org/dev/library/ipaddress#representing-ip-addresses-and-networks ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 18 09:36:11 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 18 Jun 2012 07:36:11 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340004971.28.0.447819768386.issue4489@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Martin, what exactly is the intended proceeding now? Are you going to fix your patch and tests as soon as you have time or was that just a PoC and expect me/us to bring it into shape? (<- troll-free question, I have no idea what to do next here and would like to see a safe rmtree in 3.3) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Mon Jun 18 09:49:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jun 2012 07:49:30 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <E1SgWiE-0007fl-PR@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 8b38a81ba3bf by Petri Lehtinen in branch '2.7': Fix NEWS entry for #15036 http://hg.python.org/cpython/rev/8b38a81ba3bf New changeset 38e2a87c9051 by Petri Lehtinen in branch '3.2': Fix NEWS entry for #15036 http://hg.python.org/cpython/rev/38e2a87c9051 New changeset 072b08989731 by Petri Lehtinen in branch 'default': Fix NEWS entry for #15036 http://hg.python.org/cpython/rev/072b08989731 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Mon Jun 18 09:50:26 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 18 Jun 2012 07:50:26 +0000 Subject: [issue15036] mailbox.mbox fails to pop two items in a row, flushing in between In-Reply-To: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za> Message-ID: <1340005826.29.0.124338764235.issue15036@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Perfect, fixed. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15036> _______________________________________ From report at bugs.python.org Mon Jun 18 09:53:54 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 18 Jun 2012 07:53:54 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1340004971.28.0.447819768386.issue4489@psf.upfronthosting.co.za> Message-ID: <4FDEDE91.9050301@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Martin, what exactly is the intended proceeding now? Are you going to > fix your patch and tests as soon as you have time or was that just a > PoC and expect me/us to bring it into shape? (<- troll-free question, > I have no idea what to do next here and would like to see a safe > rmtree in 3.3) I still plan to work on this, but I'm also really really short on time. I still favor my own approach (obviously), so if you want to bring it into shape - that would be appreciated. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Mon Jun 18 10:01:09 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 18 Jun 2012 08:01:09 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1340006469.95.0.807351094479.issue9559@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: This is actually not true. When calling add(), mbox (and MMDF and Babyl) append the message to the file without rewriting it. It's the following flush() call that rewrites the whole mailbox contents. I think this could be changed to work correctly by not setting self._pending = True in _singlefileMailbox.add. This way, the file wouldn't be rewritten by flush() if messages are only appended. OTOH, flush() should still fsync the mailbox file (if we want to ensure that the changes are really written to disk). This would probably require a new flag in addition to self._pending, to indicate that there are unsynced changes. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Mon Jun 18 10:02:25 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Jun 2012 08:02:25 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1340006545.52.0.146460046085.issue3665@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: I forgot about byte patterns. Here is an updated patch. ---------- Added file: http://bugs.python.org/file26040/re_unicode_escapes-3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3665> _______________________________________ From report at bugs.python.org Mon Jun 18 10:03:55 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 18 Jun 2012 08:03:55 +0000 Subject: [issue1590744] mail message parsing glitch Message-ID: <1340006635.57.0.784622967442.issue1590744@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: ---------- nosy: +petri.lehtinen _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1590744> _______________________________________ From report at bugs.python.org Mon Jun 18 12:59:59 2012 From: report at bugs.python.org (John Firestone) Date: Mon, 18 Jun 2012 10:59:59 +0000 Subject: [issue15099] exec of function doesn't call __getitem__ or __missing__ on undefined global Message-ID: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za> New submission from John Firestone <johnf at freenet.de>: exec(source, Dict()) doesn't call Dict().__getitem__ or Dict().__missing__ if the source string contains a function and the function references an undefined global. class Dict1(dict): def __getitem__(self, key): print ' __getitem__', repr(key) if key == 's': return None return dict.__getitem__(self, key) class Dict2(dict): def __missing__(self, key): print ' __missing__', repr(key) return None source = """if 1: print ' 1' s def f(): print ' 2' s print ' 3' f()""" print 'Dict1.__getitem__' try: exec(source, Dict1()) except NameError as exc_value: print ' %s: %s' % (exc_value.__class__.__name__, exc_value) print 'Dict2.__missing__' try: exec(source, Dict2()) except NameError as exc_value: print ' %s: %s' % (exc_value.__class__.__name__, exc_value) Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:32:06) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin >>> import curiosity Dict1.__getitem__ 1 __getitem__ 's' __getitem__ 'f' 2 NameError: global name 's' is not defined Dict2.__missing__ 1 __missing__ 's' 2 NameError: global name 's' is not defined >>> ---------- components: Interpreter Core files: curiosity.py messages: 163095 nosy: johnf priority: normal severity: normal status: open title: exec of function doesn't call __getitem__ or __missing__ on undefined global type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26041/curiosity.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15099> _______________________________________ From report at bugs.python.org Mon Jun 18 13:57:49 2012 From: report at bugs.python.org (Radoslaw A. Zarzynski) Date: Mon, 18 Jun 2012 11:57:49 +0000 Subject: [issue15100] Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile Message-ID: <1340020668.92.0.801725909503.issue15100@psf.upfronthosting.co.za> New submission from Radoslaw A. Zarzynski <radoslaw.zarzynski at student.put.poznan.pl>: shutil.copy and shutil.copy2 first copy a file content and afterwards change permissions of a destination file. Unfortunately, the sequence isn't atomical and may lead to disclosure of matter of any file that is being duplicated. Additionally, shutil.copyfile procedure seems to have a problem with symlinks that could result in the corruption of content of any file on filesystem (in favorable conditions). Some functions from shutil module that depend on copy[2] (and thus copyfile) are vulnerable too. For example, shutil.move is using copy2 when os.rename fails because of file transfer between filesystems. I have attached listing from strace(1) system utility below that illustrates the disclosure problem. # ls -l ./shutil_test -r-------- 1 root root 10 06-18 11:42 shutil_test # strace -- python -c "import shutil; shutil.move('./shutil_test', '/tmp')" <many irrelevant lines> open("./shutil_test", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0400, st_size=10, ...}) = 0 open("/tmp/shutil_test", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 fstat(3, {st_mode=S_IFREG|0400, st_size=10, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd82e13e000 read(3, "blablabla\n", 16384) = 10 read(3, "", 12288) = 0 fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd82e13d000 read(3, "", 16384) = 0 write(4, "blablabla\n", 10) = 10 close(4) = 0 munmap(0x7fd82e13d000, 4096) = 0 close(3) = 0 munmap(0x7fd82e13e000, 4096) = 0 stat("./shutil_test", {st_mode=S_IFREG|0400, st_size=10, ...}) = 0 utimes("/tmp/shutil_test", {{1340012952, 0}, {1340012539, 0}}) = 0 chmod("/tmp/shutil_test", 0400) = 0 Quick fix for the first issue could rely on os.umask but much more elegant and composite solution might use combination of os.open, os.fchmod and os.fdopen instead of open(dst, 'wb') in shutil.copyfile procedure which additionally rectifies the problem with symlink attack. However, I am not sure that the last one is portable and won't mess with another code. I have prepared *untested* patches for both propositions. Best regards, Radoslaw A. Zarzynski ---------- components: Library (Lib) files: python_shutil_copyfile.diff keywords: patch messages: 163096 nosy: radoslaw.zarzynski priority: normal severity: normal status: open title: Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile type: security versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file26042/python_shutil_copyfile.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15100> _______________________________________ From report at bugs.python.org Mon Jun 18 14:03:49 2012 From: report at bugs.python.org (Radoslaw A. Zarzynski) Date: Mon, 18 Jun 2012 12:03:49 +0000 Subject: [issue15100] Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile In-Reply-To: <1340020668.92.0.801725909503.issue15100@psf.upfronthosting.co.za> Message-ID: <1340021029.29.0.191101251465.issue15100@psf.upfronthosting.co.za> Changes by Radoslaw A. Zarzynski <radoslaw.zarzynski at student.put.poznan.pl>: Added file: http://bugs.python.org/file26043/python_shutil_copy_with_umask.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15100> _______________________________________ From report at bugs.python.org Mon Jun 18 14:10:47 2012 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 18 Jun 2012 12:10:47 +0000 Subject: [issue15100] Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile In-Reply-To: <1340020668.92.0.801725909503.issue15100@psf.upfronthosting.co.za> Message-ID: <1340021447.95.0.291748796241.issue15100@psf.upfronthosting.co.za> Changes by Florent Xicluna <florent.xicluna at gmail.com>: ---------- components: +IO nosy: +flox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15100> _______________________________________ From report at bugs.python.org Mon Jun 18 14:12:26 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 18 Jun 2012 12:12:26 +0000 Subject: [issue15099] exec of function doesn't call __getitem__ or __missing__ on undefined global In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za> Message-ID: <1340021546.75.0.752321482362.issue15099@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: This looks like a documentation issue: it's well documented that in the exec statement, the globals dictionary must be a dict. What's not so clear from the documentation (AFAICT) is that it must actually have *type* dict, rather than merely being an instance of dict. (Or, from experimentation, it *can* be an instance of a dict subclass, but the underlying C-implemented dict methods are called directly, so overloads for __getitem__ and the like don't have any effect.) ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python, mark.dickinson stage: -> needs patch type: behavior -> versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15099> _______________________________________ From report at bugs.python.org Mon Jun 18 14:34:11 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 18 Jun 2012 12:34:11 +0000 Subject: [issue15100] Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile In-Reply-To: <1340020668.92.0.801725909503.issue15100@psf.upfronthosting.co.za> Message-ID: <1340022851.0.0.490017213175.issue15100@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15100> _______________________________________ From report at bugs.python.org Mon Jun 18 14:34:28 2012 From: report at bugs.python.org (John Firestone) Date: Mon, 18 Jun 2012 12:34:28 +0000 Subject: [issue15099] exec of function doesn't call __getitem__ or __missing__ on undefined global In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za> Message-ID: <1340022868.32.0.436923241001.issue15099@psf.upfronthosting.co.za> John Firestone <johnf at freenet.de> added the comment: I find the behavior inconsistent. As you can see from this example, the exec'uted code *does* call the instance's overloaded __getitem__ and __missing__ methods when outside a function, but doesn't when inside. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15099> _______________________________________ From report at bugs.python.org Mon Jun 18 14:50:14 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 18 Jun 2012 12:50:14 +0000 Subject: [issue15099] exec of function doesn't call __getitem__ or __missing__ on undefined global In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za> Message-ID: <1340023814.34.0.385085789347.issue15099@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > As you can see from this example, the exec'uted code *does* call the > instance's overloaded __getitem__ and __missing__ methods when outside a > function, but doesn't when inside. Yep; that's because the 's' and 'f' lookups at top level are *local* lookups, and the 's' lookup from inside the body of 'f' is done as a *global* lookup (as explained in the docs here: [1]). In the exec statement, the locals can be any mapping-like object. The behaviour's a bit clearer if you pass separate globals and locals dictionaries: >>> source = """\ ... print s ... def f(): ... print s ... f() ... """ >>> locals = {'s': 1729} >>> globals = {'s': 31415} >>> exec source in globals, locals 1729 31415 [1] http://docs.python.org/reference/executionmodel.html#interaction-with-dynamic-features ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15099> _______________________________________ From report at bugs.python.org Mon Jun 18 15:48:26 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 18 Jun 2012 13:48:26 +0000 Subject: [issue15099] exec of function doesn't call __getitem__ or __missing__ on undefined global In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za> Message-ID: <1340027306.05.0.515910728715.issue15099@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: With Python3 though, __getitem__ seems called though. OTOH the 'print' symbol is not found, even though the Dict1 got a '__builtins__' entry added. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15099> _______________________________________ From report at bugs.python.org Mon Jun 18 16:33:41 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 18 Jun 2012 14:33:41 +0000 Subject: [issue15101] multiprocessing pool finalizer can fail if triggered in background pool thread Message-ID: <1340030021.48.0.355749717921.issue15101@psf.upfronthosting.co.za> New submission from Richard Oudkerk <shibturn at gmail.com>: Multiprocessing's process pool originally used a finalizer to shutdown the pool when the pool object is garbage collected. Since the maxtasksperchild feature was added, the worker_handler thread holds a reference to the pool, preventing garbage collection at least until that thread finished. In some cases the last reference to the pool is owned by the worker_handler thread, and as it exits, the finalizer is triggered. Since the finalizer tries to join the worker_handler thread, an error will be raised since a thread cannot join itself. It would have been better if pools had used the context manager protocol rather than using RAII -- see Issue #15064. Unless/until RAII usage is fixed, a quick fix would be to just make the finalizer skip trying to join the current thread. ---------- messages: 163101 nosy: sbt priority: normal severity: normal status: open title: multiprocessing pool finalizer can fail if triggered in background pool thread type: behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15101> _______________________________________ From report at bugs.python.org Mon Jun 18 16:48:16 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 18 Jun 2012 14:48:16 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts Message-ID: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>: The buildbot scripts do not work for the 64-bit targets. Firstly, the "/p:UseEnv=True" parameter to msbuild causes the 32-bit only projects (make_buildinfo and make_versioninfo) to fail due to architecture mismatch. The scripts now unconditionally build those projects using the 32-bit command-line tools. The make_versioninfo project wasn't completely converted to be 32-bit only (issue9981); it would work correctly only from the IDE. This fixes that and removes the Debug configuration as that was already #ifdef'd in the generated .h file. ---------- components: Build, Cross-Build, Windows hgrepos: 136 messages: 163102 nosy: jkloth priority: normal severity: normal status: open title: Fix 64-bit building for buildbot scripts type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Mon Jun 18 16:53:45 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 18 Jun 2012 14:53:45 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <1339521425.84.0.884791308596.issue15052@psf.upfronthosting.co.za> Message-ID: <1340031225.83.0.862441353033.issue15052@psf.upfronthosting.co.za> Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment: In addition to the fixes from issue15102, the only way I could get the ssl project to build successfully was to add the Perl installation (C:\Perl\bin) to my PATH. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Mon Jun 18 16:55:39 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 18 Jun 2012 14:55:39 +0000 Subject: [issue15040] stdlib compatibility with pypy: mailbox module In-Reply-To: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za> Message-ID: <1340031339.19.0.620079374748.issue15040@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- title: stdlib compatability with pypy: mailbox.py -> stdlib compatibility with pypy: mailbox module _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15040> _______________________________________ From report at bugs.python.org Mon Jun 18 16:55:57 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 18 Jun 2012 14:55:57 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <1339521425.84.0.884791308596.issue15052@psf.upfronthosting.co.za> Message-ID: <1340031357.61.0.958747042663.issue15052@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Again: installing Perl should not be necessary. That it is currently necessary is a bug in the sources. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Mon Jun 18 17:02:49 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 18 Jun 2012 15:02:49 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <1340031357.61.0.958747042663.issue15052@psf.upfronthosting.co.za> Message-ID: <CAGvrs3KVq8vxRVkfLstHiQEwMs0qJc7zz1LidPR6OivOijtB1Q@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: Should I then open another issue just to track that bug? Have you even tried using build_ssl.py *without* Perl? The changes required to get that to work seem fairly extensive. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Mon Jun 18 17:08:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jun 2012 15:08:40 +0000 Subject: [issue15101] multiprocessing pool finalizer can fail if triggered in background pool thread In-Reply-To: <1340030021.48.0.355749717921.issue15101@psf.upfronthosting.co.za> Message-ID: <E1SgdZG-0001JR-H1@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 4c07b9c49b75 by Richard Oudkerk in branch '2.7': Issue #15101: Make pool finalizer avoid joining current thread http://hg.python.org/cpython/rev/4c07b9c49b75 New changeset e1cd1f430ff1 by Richard Oudkerk in branch '3.2': Issue #15101: Make pool finalizer avoid joining current thread. http://hg.python.org/cpython/rev/e1cd1f430ff1 New changeset 59e0a51c5fc3 by Richard Oudkerk in branch 'default': Issue #15101: Make pool finalizer avoid joining current thread. http://hg.python.org/cpython/rev/59e0a51c5fc3 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15101> _______________________________________ From report at bugs.python.org Mon Jun 18 18:55:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jun 2012 16:55:40 +0000 Subject: [issue15064] multiprocessing should use more context manager In-Reply-To: <1339676025.91.0.9899325094.issue15064@psf.upfronthosting.co.za> Message-ID: <E1SgfEo-0003jp-Cr@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 6d2a773d8e00 by Richard Oudkerk in branch 'default': Issue #15064: Implement context manager protocol for multiprocessing types http://hg.python.org/cpython/rev/6d2a773d8e00 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15064> _______________________________________ From report at bugs.python.org Mon Jun 18 19:04:23 2012 From: report at bugs.python.org (pmoody) Date: Mon, 18 Jun 2012 17:04:23 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340039063.45.0.420141669885.issue14814@psf.upfronthosting.co.za> pmoody <python at hda3.com> added the comment: I'm not sure if this is still an issue, but returning the address in a packed format was an early issue (http://code.google.com/p/ipaddr-py/issues/detail?id=14). No objections from me for removing it from the network objects or for removing the packed constructor (I'm assuming there isn't any python-ism about being able to copy-construct an object from any valid representation of said object) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 18 19:40:47 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 18 Jun 2012 17:40:47 +0000 Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za> Message-ID: <1340041247.59.0.339369150475.issue7360@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Can this be closed? ---------- nosy: +petri.lehtinen _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7360> _______________________________________ From report at bugs.python.org Mon Jun 18 19:42:37 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 18 Jun 2012 17:42:37 +0000 Subject: [issue5346] mailbox._singlefileMailbox.flush doesn't preserve file rights In-Reply-To: <1235317721.52.0.542523133974.issue5346@psf.upfronthosting.co.za> Message-ID: <1340041357.83.0.487765640421.issue5346@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: ---------- nosy: +petri.lehtinen _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5346> _______________________________________ From report at bugs.python.org Mon Jun 18 19:45:02 2012 From: report at bugs.python.org (John Firestone) Date: Mon, 18 Jun 2012 17:45:02 +0000 Subject: [issue15099] exec of function doesn't call __getitem__ or __missing__ on undefined global In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za> Message-ID: <1340041502.91.0.343406168254.issue15099@psf.upfronthosting.co.za> John Firestone <johnf at freenet.de> added the comment: Thank you all for the quick and interesting responses! Here is another example, this time showing a simple s sometimes behaves like globals()['s'] and sometimes doesn't. class Dict(dict): def __getitem__(self, key): if key == 's': return 'got s' return dict.__getitem__(self, key) dct = Dict() dct['the_dict'] = dct print 0, id(dct) source = """if 1: print '1', id(globals()), globals() is the_dict print ' ', globals()['s'] print ' ', s def f(): print '2', id(globals()), globals() is the_dict print ' ', globals()['s'] print ' ', s print '3' f()""" exec(source, dct) Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:32:06) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin >>> import curiosity2 0 2459928 1 2459928 True got s got s 2 2459928 True got s Traceback (most recent call last): File "<stdin>", line 1, in <module> File "curiosity2.py", line 22, in <module> exec(source, dct) File "<string>", line 10, in <module> File "<string>", line 8, in f NameError: global name 's' is not defined >>> ---------- Added file: http://bugs.python.org/file26044/curiosity2.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15099> _______________________________________ From report at bugs.python.org Mon Jun 18 20:19:32 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Jun 2012 18:19:32 +0000 Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za> Message-ID: <1340043572.48.0.556745165871.issue7360@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Probably. Unless I'm mistaken, the issue with concurrent rewrite (as opposed to append) exists for single-file-mailboxes in the general case, not just in Python. And as far as I know failure is never noisy, the last writer wins. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7360> _______________________________________ From report at bugs.python.org Mon Jun 18 20:35:42 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 18 Jun 2012 18:35:42 +0000 Subject: [issue7359] mailbox cannot modify mailboxes in system mail spool In-Reply-To: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za> Message-ID: <1340044542.39.0.423004859199.issue7359@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Every program that accesses mailboxes in the system-wide mail spool directory needs to have write access to it. This is because dot-locking is achieved by creating additional files to that directory, and it must be used (in addition to fcntl() locking) to avoid messing up the mailboxes because of concurrent access. In Debian, /var/mail is owned by root:mail with mode 2755, and every MUA is setgid mail. See the Debian Policy Manual section 11.6 for more information: http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-mail-transport-agents If you write a MUA or MTA using Python's mailbox module, your program needs to have write access to /var/mail. That's the only way to do it correctly. It also makes the mailbox module's renaming behavior possible. ---------- nosy: +petri.lehtinen resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7359> _______________________________________ From report at bugs.python.org Mon Jun 18 20:42:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 18 Jun 2012 18:42:27 +0000 Subject: [issue15099] exec of function doesn't call __getitem__ or __missing__ on undefined global In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za> Message-ID: <1340044947.61.0.333897684994.issue15099@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Yes, this is definitely a dark corner of Python, and one that it seems worth trying to illuminate a bit in the documentation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15099> _______________________________________ From report at bugs.python.org Mon Jun 18 20:59:19 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 18 Jun 2012 18:59:19 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <1339521425.84.0.884791308596.issue15052@psf.upfronthosting.co.za> Message-ID: <1340045959.05.0.675912348009.issue15052@psf.upfronthosting.co.za> Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment: OK, I have discovered my issue(s) building OpenSSL. When I first downloaded the openssl-1.0.1c external, the timestamps for the .asm files ended up being older than their corresponding .pl sources therefore triggering the rules in the makefile. I then decided to fix those Perl related issues by installing ActivePerl but *without* having it added to my PATH (as build_ssl.py finds it in the default location). This causes build_ssl.py to no longer use the generated .asm files as a Perl executable has been found (line 221). The attached patch ensures that the Perl executable is actually runnable. ---------- keywords: +patch Added file: http://bugs.python.org/file26045/build_ssl.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Mon Jun 18 20:59:52 2012 From: report at bugs.python.org (Robin Schreiber) Date: Mon, 18 Jun 2012 18:59:52 +0000 Subject: [issue15042] Implemented PyState_AddModule, PyState_RemoveModule In-Reply-To: <1339320622.0.0.56459406352.issue15042@psf.upfronthosting.co.za> Message-ID: <1340045992.91.0.857122846446.issue15042@psf.upfronthosting.co.za> Robin Schreiber <robin.schreiber at me.com> added the comment: Added missing documentation. Also added documentation of PyState_FindModule() which still happened to be missing. ---------- Added file: http://bugs.python.org/file26046/PyState_add-remove_module_v2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15042> _______________________________________ From report at bugs.python.org Mon Jun 18 21:01:00 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 18 Jun 2012 19:01:00 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <1339521425.84.0.884791308596.issue15052@psf.upfronthosting.co.za> Message-ID: <1340046060.4.0.55148029951.issue15052@psf.upfronthosting.co.za> Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment: I forgot to add that with the patch the comment wrt Perl is truly correct. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Mon Jun 18 21:24:31 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 18 Jun 2012 19:24:31 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1340047471.0.0.702216560431.issue15096@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Mon Jun 18 21:45:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Jun 2012 19:45:53 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340048753.34.0.961558349023.issue15102@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- keywords: +patch Added file: http://bugs.python.org/file26047/2a20cee18add.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Mon Jun 18 21:58:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Jun 2012 19:58:52 +0000 Subject: [issue13512] ~/.pypirc created insecurely In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za> Message-ID: <1340049532.85.0.630337317947.issue13512@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Eric, do you plan to fix this soon? Linux distributions have started patched their Pythons manually. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13512> _______________________________________ From report at bugs.python.org Mon Jun 18 22:21:37 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 18 Jun 2012 20:21:37 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1340050897.19.0.676752169377.issue14684@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Sam, the window for Python 3.3 integration is almost close. Could you possibly update your patch with Nadeem's feedback?. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Mon Jun 18 22:31:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jun 2012 20:31:54 +0000 Subject: [issue15064] multiprocessing should use more context manager In-Reply-To: <1339676025.91.0.9899325094.issue15064@psf.upfronthosting.co.za> Message-ID: <E1Sgic4-0007kn-CU@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 198382b4bcd0 by Richard Oudkerk in branch 'default': Issue #15064: Make BaseManager.__enter__() start server if necessary. http://hg.python.org/cpython/rev/198382b4bcd0 New changeset 836d712461b3 by Richard Oudkerk in branch 'default': Issue #15064: Use with-blocks for some examples in docs. http://hg.python.org/cpython/rev/836d712461b3 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15064> _______________________________________ From report at bugs.python.org Mon Jun 18 22:33:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jun 2012 20:33:22 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <E1SgidU-0007r0-Iw@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 978326f98316 by Kristj?n Valur J?nsson in branch 'default': Issue #15038: Optimize python Locks on Windows http://hg.python.org/cpython/rev/978326f98316 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Mon Jun 18 22:42:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 18 Jun 2012 20:42:45 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340052165.85.0.606901720962.issue15102@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: There's some unrelated stuff in the patch that reverts commits in mpdecimal.c and multiprocessing. Maybe a Rietveld issue. ---------- nosy: +skrah _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Mon Jun 18 23:20:02 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 18 Jun 2012 21:20:02 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340052165.85.0.606901720962.issue15102@psf.upfronthosting.co.za> Message-ID: <CAGvrs3J8UqzGZauVdQTVX9xEFjT0X=+p-EWLCYCLMfhJL0vrOA@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: The unrelated changes do seem to be an issue with the diff generated by Rietveld ---------- nosy: +jeremy.kloth _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Mon Jun 18 23:27:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Jun 2012 21:27:45 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340054865.84.0.23572710875.issue15102@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: If I understand, the proposed changes are the following: https://bitbucket.org/jkloth/cpython-buildbot-amd64/changeset/2a20cee18add ? I'm not a Windows specialist, but they do seem a bit weird: - the pcbuild.sln changes remove "Debug|x64.Build" and replaces "Debug" with "Release" - build-common.bat doesn't allow to distinguish between x86 and x64 - build.bat does not call build-common.bat ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Mon Jun 18 23:38:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Jun 2012 21:38:01 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h Message-ID: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: The Solaris compiler chokes on the embedded NUL character. Perhaps we can find another way to remove the importlib.h diffs from the notification e-mails (simply hardcode the filename?). http://www.python.org/dev/buildbot/all/builders/x86%20Solaris%2011%203.x/builds/21/steps/compile/logs/stdio /opt/solarisstudio/bin/cc -c -O -I. -I./Include -DPy_BUILD_CORE -o Python/frozen.o Python/frozen.c "Python/importlib.h", line 3847: null character in input cc: acomp failed for Python/frozen.c ---------- components: Interpreter Core messages: 163124 nosy: georg.brandl, pitrou priority: normal severity: normal status: open title: Solaris compiler chokes on importlib.h type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Mon Jun 18 23:42:40 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 18 Jun 2012 21:42:40 +0000 Subject: [issue15052] Outdated comments in build_ssl.py In-Reply-To: <CAGvrs3KVq8vxRVkfLstHiQEwMs0qJc7zz1LidPR6OivOijtB1Q@mail.gmail.com> Message-ID: <4FDFA0CE.8070300@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Should I then open another issue just to track that bug? Have you > even tried using build_ssl.py *without* Perl? The changes required to > get that to work seem fairly extensive. The 3.3 tree works fine for me without Perl, I'm confident that changing the other trees will be trivial. I just haven't found the time to do that. No need to open other bug reports; I'm aware of the issue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15052> _______________________________________ From report at bugs.python.org Mon Jun 18 23:52:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Jun 2012 21:52:08 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340056328.07.0.630283772342.issue15038@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: There's a problem here: Fatal Python error: PyCOND_SIGNAL(gil_cond) failed http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6859/steps/test/logs/stdio ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 00:26:12 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 18 Jun 2012 22:26:12 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340054865.84.0.23572710875.issue15102@psf.upfronthosting.co.za> Message-ID: <CAGvrs3Jcu7x5=2aPDK4MDmYVb0PVzRjZV+z_5Fab_MY2Pun8BQ@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: On Mon, Jun 18, 2012 at 3:27 PM, Antoine Pitrou <report at bugs.python.org> wrote: > If I understand, the proposed changes are the following: > https://bitbucket.org/jkloth/cpython-buildbot-amd64/changeset/2a20cee18add That seems to be correct, yes. > I'm not a Windows specialist, but they do seem a bit weird: > - the pcbuild.sln changes remove "Debug|x64.Build" and replaces "Debug" with "Release" That change is related to the make_versioninfo project which doesn't use the Debug build (like make_buildinfo) > - build-common.bat doesn't allow to distinguish between x86 and x64 Correct as make_buildinfo and make_versioninfo are only ever built as 32-bit (see issue9981) > - build.bat does not call build-common.bat Oops, an oversight on my part. It didn't show up in testing as the solution already is built in 32-bit mode. The call should in the same location as in build-amd64.bat ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Tue Jun 19 01:20:35 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 18 Jun 2012 23:20:35 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340061635.54.0.0801467862062.issue15038@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: Py_LOCAL_INLINE(int) _PyCOND_WAIT_MS(PyCOND_T *cv, PyMUTEX_T *cs, DWORD ms) { DWORD wait; cv->waiting++; PyMUTEX_UNLOCK(cs); /* "lost wakeup bug" would occur if the caller were interrupted here, * but we are safe because we are using a semaphore wich has an internal * count. */ wait = WaitForSingleObject(cv->sem, ms); PyMUTEX_LOCK(cs); if (wait != WAIT_OBJECT_0) --cv->waiting; /* Here we have a benign race condition with PyCOND_SIGNAL. * When failure occurs or timeout, it is possible that * PyCOND_SIGNAL also decrements this value * and signals releases the mutex. This is benign because it * just means an extra spurious wakeup for a waiting thread. */ ... Are you really sure this race is benign? If cv->waiting gets double decremented then it can become negative. PyCOND_SIGNAL() is defined as Py_LOCAL_INLINE(int) PyCOND_SIGNAL(PyCOND_T *cv) { if (cv->waiting) { cv->waiting--; return ReleaseSemaphore(cv->sem, 1, NULL) ? 0 : -1; } return 0; } While cv->waiting is negative, each call of PyCOND_SIGNAL() decrements cv->waiting, and increments the semaphore, while each call of PyCOND_WAIT() will increment cv->waiting and decrement the semaphore. So if calls of PyCOND_SIGNAL() outnumber calls of PyCOND_WAIT() then we can have cv->waiting becoming very negative and the semaphore overflowing. Maybe just changing the test in PyCOND_SIGNAL() to if (cv->waiting > 0) { would be enough, but I am not convinced. ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 01:41:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Jun 2012 23:41:48 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <E1SglZo-00075h-Nw@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 8281233ec648 by Brian Curtin in branch 'default': Fix #14772: Return the destination from some shutil functions. http://hg.python.org/cpython/rev/8281233ec648 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14772> _______________________________________ From report at bugs.python.org Tue Jun 19 01:45:27 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 18 Jun 2012 23:45:27 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1340063127.1.0.540690121136.issue14772@psf.upfronthosting.co.za> Changes by Brian Curtin <brian at python.org>: ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14772> _______________________________________ From report at bugs.python.org Tue Jun 19 02:15:50 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 19 Jun 2012 00:15:50 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h In-Reply-To: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za> Message-ID: <1340064949.87.0.926446906721.issue15103@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Tue Jun 19 03:01:01 2012 From: report at bugs.python.org (Sam Rushing) Date: Tue, 19 Jun 2012 01:01:01 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1340067661.14.0.749379698889.issue14684@psf.upfronthosting.co.za> Sam Rushing <rushing.sam at gmail.com> added the comment: I think other than the disagreement about whether the dictionary constructor arg should be a buffer object, it's good to go. To restate my position: the need is for an immutable string of bytes, and that's exactly what PyBytes_Type is for. I see no advantage to allowing a buffer object, which will require extra code to check that it is both a buffer object and set to be readonly. I believe the argument for aesthetics does not apply, as the constant dictionary constructor argument is a morally different kind of parameter, comparable to (say) the compression level. You folks are of course welcome to change it, though. 8^) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Tue Jun 19 03:51:05 2012 From: report at bugs.python.org (Justin Venus) Date: Tue, 19 Jun 2012 01:51:05 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h In-Reply-To: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za> Message-ID: <1340070665.84.0.222118095848.issue15103@psf.upfronthosting.co.za> Justin Venus <justin.venus at gmail.com> added the comment: What is the purpose of the comment at the end of "Python/importlib.h"? If I remove the comment that states "binary marker for mercurial" (something to that effect anyhow) the code compiles and only the tests fail. ---------- nosy: +Justin.Venus _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Tue Jun 19 04:00:18 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 19 Jun 2012 02:00:18 +0000 Subject: [issue3173] external strftime for Python? In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za> Message-ID: <1340071218.75.0.515581994502.issue3173@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: IANA is now distributing Olson's timezone database software which includes an implementation of strftime(): http://www.iana.org/time-zones/repository/releases/tzcode2012b.tar.gz The code was designated as public domain by Arthur David Olson, but it seems to be based on code copyrighted by UCB and distributed under the BSD license. The code does seem to include some locale support. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3173> _______________________________________ From report at bugs.python.org Tue Jun 19 04:27:43 2012 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Jun 2012 02:27:43 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340072863.46.0.879237530696.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: New version (pep363.4.patch) Summary: 1. Removed 'Signature.implemented' 2. No more patching built-ins - no issues with shared interpreters 3. Removed 'Signature.format()'. If needed we'll reintroduce it in 3.4 (although we still have 'Signature.__str__') 4. Signature now implements just __copy__ - creates a shallow copy (__deepcopy__ has been removed, as it wasn't deep) 5. Signature.__eq__ fixed to ignore order of keyword-only arguments. Thanks and please review! ---------- Added file: http://bugs.python.org/file26048/pep362.4.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Tue Jun 19 04:29:06 2012 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Jun 2012 02:29:06 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340072946.29.0.550791627851.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: Eric, I personally prefer simple 'signature()' more than 'get_signature()'. But I'll ask this question on python-dev on the next PEP update. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Tue Jun 19 04:46:52 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 19 Jun 2012 02:46:52 +0000 Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za> Message-ID: <1340074012.91.0.11904093741.issue7584@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: I have reviewed RFC 3339 and it looks like the following produces a fully compliant timestamp: >>> print(datetime(2000,1,1, tzinfo=timezone.utc).isoformat('T')) 2000-01-01T00:00:00+00:00 I see the following remaining issues: 1. It is often desired to get RFC 3339 timestamp in local timezone instead of UTC. This will be addressed in issue 9527. 2. If UTC timestamp is produced by a computer in non-UTC timezone, the offset should be specified as '-00:00'. If this is important, an application can replace '+' with '-', but most likely specifying the correct local offset is a better option. 3. RFC 3339 requires support for leap seconds. This limitation cannot be solved by adding a method to datetime. Most importantly, given that there are several RFCs describing different date formats, a datetime.rfcformat() method will be ambiguous. (GNU date has --rfc-2822 and --rfc-3339 options and the later allows output of three different precisions.) I am going to reject this RFE. I don't think adding datetime.rfcformat() method will solve any real deficiency and whatever limitations datetime has with respect to producing RFC compliant timestamps should be addressed in future specific proposals. ---------- resolution: -> rejected stage: needs patch -> committed/rejected status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7584> _______________________________________ From report at bugs.python.org Tue Jun 19 05:18:17 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 19 Jun 2012 03:18:17 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1340075897.33.0.914156735945.issue9527@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: On Mon, Jun 11, 2012 at 11:18 PM, James Henstridge <report at bugs.python.org> wrote: > One problem I can see with using a fixed offset > tzinfo for localtime is that it might confuse people > when doing date arithmetic. Yes, this is the issue that I discussed in my first python-ideas/python-dev post. (See msg162631 above.) > ? ?>>> d = datetime.localtime() + timedelta(days=7) > > While it will give a correct answer as a point in time it > will have the wrong time zone offset if run just before a > daylight saving transition, which could be just as confusing. I think my latest proposal will fare slightly better in this scenario. I am now propose implementing local timezone info discovery in datetime.astimezone() method. Obtaining local time will now be a little more verbose: local_time = datetime.now(timezone.utc).astimezone() but (local_time + timedelta(7)).astimezone() will give you correctly adjusted aware datetime seven days later. If we also implement astimezone() for naive instances, we can even support naive local time arithmetics: (datetime.now() + timedelta(7)).astimezone() will produce the same time of day as "now" unless it falls into a non-existing hour. > I'm not sure how you'd solve this without e.g. importing > pytz into the standard library though. Importing pytz will not help. Pytz fudges the issue by extending tzinfo methods to accept isdst flag, but there is no place in datetime to store this flag. Doing time calculations in local time is inherently ambiguous in presence of DST. On the other hand, producing tz aware local time from any unambiguous absolute time specification (UTC, time_t, local time + tz offset, etc.) is a well-defined problem which does not have an adequate solution. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Tue Jun 19 05:22:43 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 19 Jun 2012 03:22:43 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1340076163.08.0.0781505118171.issue9527@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: > ... is a well-defined problem which does not have an adequate solution. I meant to say "does not have an adequate solution *in the current datetime module*". I think the enhanced datetime.astimezone() method will solve this problem. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Tue Jun 19 08:43:27 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 06:43:27 +0000 Subject: [issue14837] Better SSL errors In-Reply-To: <1337208339.28.0.379758124204.issue14837@psf.upfronthosting.co.za> Message-ID: <1340088207.05.0.710740554256.issue14837@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: I'd like to see this in 3.3. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14837> _______________________________________ From report at bugs.python.org Tue Jun 19 08:44:00 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 06:44:00 +0000 Subject: [issue1757118] utilize 2.5 try/except/finally in contextlib Message-ID: <1340088240.62.0.290062532342.issue1757118@psf.upfronthosting.co.za> Changes by Georg Brandl <georg at python.org>: Removed file: http://bugs.python.org/file25625/1.html _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1757118> _______________________________________ From report at bugs.python.org Tue Jun 19 09:04:13 2012 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Tue, 19 Jun 2012 07:04:13 +0000 Subject: [issue12982] Document that importing .pyo files needs python -O In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za> Message-ID: <1340089453.61.0.726967250427.issue12982@psf.upfronthosting.co.za> Eric O. LEBIGOT <eric.lebigot at normalesup.org> added the comment: Thank you for this lucid account of the situation, Terry. As for where in the documentation something additional could be said about .pyo files and the -O option, I must say that it is already mentioned in some relevant places (http://docs.python.org/tutorial/modules.html#compiled-python-files), However, I can see one other place where some additional information would be useful: in the documentation for the -O option itself (http://docs.python.org/using/cmdline.html#miscellaneous-options). The current documentation only mentions the .pyo-producing effect of -O. Mentioning there that -O is *required* for interpreting .pyo files would be useful. Thanks! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________ From report at bugs.python.org Tue Jun 19 10:02:45 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 19 Jun 2012 08:02:45 +0000 Subject: [issue15104] abusive language in __name__ description Message-ID: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> New submission from anatoly techtonik <techtonik at gmail.com>: http://docs.python.org/library/__main__.html "It is this environment in which the idiomatic ?conditional script? stanza causes a script to run" ?!? ---------- assignee: docs at python components: Documentation messages: 163140 nosy: docs at python, techtonik priority: normal severity: normal status: open title: abusive language in __name__ description _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 10:07:39 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 19 Jun 2012 08:07:39 +0000 Subject: [issue15104] abusive language in __name__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340093259.29.0.264314558479.issue15104@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: I?m no native speaker but I fail to see anything abusive here. ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 10:10:01 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 19 Jun 2012 08:10:01 +0000 Subject: [issue15104] abusive language in __name__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340093401.89.0.272253714167.issue15104@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: It is abusive for those who don't get the meaning. Can you translate it to simple english? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 10:13:35 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 19 Jun 2012 08:13:35 +0000 Subject: [issue15104] abusive language in __name__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340093615.31.0.575677339107.issue15104@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: Maybe "abusive language" is not the right translation from Russian. It could be "coarse language" or "foul language". ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 10:23:39 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 19 Jun 2012 08:23:39 +0000 Subject: [issue15104] abusive language in __name__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340094219.1.0.753298521696.issue15104@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Which specific word do you consider "??????" or "?????????????"? This is all polite, courteous wording, in my understanding of English. But maybe a native speaker should really comment here. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 10:50:26 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 19 Jun 2012 08:50:26 +0000 Subject: [issue15104] abusive language in __name__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340095826.9.0.46370318491.issue15104@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: Ok, the "language is not clear enough" is the queasily polite, serious and corteous substitution for "abusive language" in the title of this issue. Can you translate it to simple english? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 10:55:02 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 19 Jun 2012 08:55:02 +0000 Subject: [issue15104] abusive language in __name__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340096102.07.0.630310895095.issue15104@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: "The following fragment can be used to make a Python file both a library and a script". ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 10:57:15 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Tue, 19 Jun 2012 08:57:15 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1340096235.88.0.343437247271.issue14684@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: > To restate my position: the need is for an immutable string of bytes, [...] I disagree that we should require the dictionary to be immutable - if the caller wishes to use a mutable buffer here, it is their responsibility to ensure that it is not modified until the compressor is finished with it ("consenting adults" and all that). The documentation can inform users of this requirement. > I believe the argument for aesthetics does not apply, as the constant > dictionary constructor argument is a morally different kind of > parameter, comparable to (say) the compression level. Even so, the surrounding code sets a precedent for how it accepts binary data buffers, and deviating from this existing convention should not be taken lightly. Nitpicking about the API aside, thanks for the patch :-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Tue Jun 19 10:57:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 19 Jun 2012 08:57:38 +0000 Subject: [issue15104] abusive language in __name__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340096258.12.0.169462663251.issue15104@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Or, actually "When the script executes as this (i.e. "__main__") module, the following conditional statement, which is in wide use and well-known, will cause the script to run". ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 11:10:37 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 19 Jun 2012 09:10:37 +0000 Subject: [issue15104] abusive language in __name__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340097037.02.0.578938698853.issue15104@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: Now I get it. That's much better. Thanks. =) After rereading the description with this new info I spot that __main__ is called a module, which is not true, because it is only a module name. It makes sense to enclose it in quotes in title as well. I'd reword this: {{{ This module represents the (otherwise anonymous) scope in which the interpreter?s main program executes ? commands read either from standard input, from a script file, or from an interactive prompt. It is this environment in which the idiomatic ?conditional script? stanza causes a script to run: }}} to this: {{{ This __name__ value represents (otherwise anonymous) scope of the program?s main module in the interpreter. __name__ becomes equal to '__main__' when commands read either from standard input, from a script file, or from an interactive prompt. For example, a common way to add code to module that will only be executable when run as a script is to place it into the following if block: }}} Not academic, but practical. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 11:13:33 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 09:13:33 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1340097213.04.0.802924647836.issue15068@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Thanks Antoine. I tested this in my virtualbox so something new must have happened... Anyway, the GIL code should not have changed from before, only moved about slightly. I?ll figure out what happened. ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Tue Jun 19 11:14:15 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 09:14:15 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1340097255.38.0.642022975656.issue15068@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>: ---------- Removed message: http://bugs.python.org/msg163150 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________ From report at bugs.python.org Tue Jun 19 11:14:30 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 09:14:30 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340097270.61.0.0205522315627.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Thanks Antoine. I tested this in my virtualbox so something new must have happened... Anyway, the GIL code should not have changed from before, only moved about slightly. I?ll figure out what happened ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 11:44:50 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 09:44:50 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340099090.49.0.339469907711.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: You are right, Richard. Thanks for pointing this out. This is not a new problem, however, because this code has been in the New GIL since it was launched. The purpose of the "n_waiting" member is to make "signal" a no-op when no one is there waiting. Otherwise, we could increase the semaphore's internal count without bound, since the condition variable protocol allows "signal" to be called as often as one desires. It is important that it doesn't fall out of sync with the actual semaphore count. Normally what will happen when the race occurs is this: n_waiting will be double decremented, and semaphore internal count will be increased by one (the wait timed out, yet we called signal). Thus, for example, we could end up with the idle state of semaphore_count == 1 and n_waiting == -1. (the invariant is semaphore_count + n_waiting - waiting_threads == 0) When the next waiter comes along, with semaphore count==1, it will just pass though, having incremented n_waiting to 0. The problem you describe is that if if 'signal' is ever hit with n_waiting<0, it will continue to tip this balance. What this will do is just cause the semaphore count to start growing. And thus, we have defeated the purpose of n_waiting. This oversight is my fault. However rest assured that it is rare, having been in the new GIL implementation since its launch :) There are two fixes: 1) As you describe, make a positive test in the "signal". 2) Make the waiter the only one who updates n_waiting, whenever it wakes up. The side effect of this is a possible slight increase of spurious wakeups in some usage scenarios. But it is simpler. I'll implement number 1), and improve the documentation to that effect. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 11:46:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 09:46:25 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h In-Reply-To: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za> Message-ID: <1340099185.54.0.287696270797.issue15103@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > What is the purpose of the comment at the end of "Python/importlib.h"? The purpose is to include a NUL character in the source file so that Mercurial treats this (generated) file as a binary file, and so that the diffs are omitted in commit notification e-mails. Since this does not seem to ve valid C (or is it?), we will have to find something else, I think. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Tue Jun 19 11:57:06 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 09:57:06 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340099826.78.0.984175846032.issue15038@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: The old version was 243 __inline static void _cond_signal(COND_T *cond) { 244 /* NOTE: This must be called with the mutex held */ 245 if (cond->n_waiting > 0) { 246 if (!ReleaseSemaphore(cond->sem, 1, NULL)) 247 Py_FatalError("ReleaseSemaphore() failed"); 248 --cond->n_waiting; 249 } 250 } So the test should be "if (cv->waiting > 0)" not "if (cv->waiting)". ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 12:07:12 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 10:07:12 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340100432.18.0.414099609205.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Well spotted. This probably fixes the failure we saw in the buildbots as well. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 12:11:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jun 2012 10:11:13 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <E1SgvOx-0000iO-96@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 110b38c36a31 by Kristjan Valur Jonsson in branch 'default': Issue #15038: http://hg.python.org/cpython/rev/110b38c36a31 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 14:48:16 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 Jun 2012 12:48:16 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340110096.11.0.0030469386472.issue15104@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Hmm. I think that chapter could use a more extensive rewrite with some additional information provided. For example, you actually can have a __main__ module in a package, and anything inside it will execute when the package is run via -m. The "otherwise anonymous" is a bit misleading, I think. The real distinction is that when a module is run as a script, __name__ is set to __main__, whereas when it is imported, __name__ is the module name. This distinction allows a module to easily detect when it is being run as a script rather than imported, and the "idiomatic 'conditional script' stanza" is how to implement the behavior of a module conditionally acting as a script depending on how it is accessed. ---------- nosy: +r.david.murray stage: -> needs patch title: abusive language in __name__ description -> Unclear language in __main__ description versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 15:08:56 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 13:08:56 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340111336.87.0.5800885121.issue15038@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: Standard condition variables have the following guarantees: * if there are any waiters then signal()/notify() will awaken at least one of them; * if there are any waiters then broadcast()/notify_all() will awaken all of them. The implementation in condvar.h does not have these guarantees since a future waiter (possibly the signalling thread) may steal the signal intended for a current waiter. In many cases this does not matter, but in some it can cause a deadlock. For instance, consider from threading import Condition, Thread import time def set_to_value(value, cond, state): while 1: with cond: while state.value == value: cond.wait() state.value = value print("set_to_value(%s)" % value) cond.notify_all() class state: value = False c = Condition() for i in (0, 1): t = Thread(target=set_to_value, args=(i, c, state)) t.daemon = True t.start() time.sleep(5) This *should* make state.value bounce back and forth between 0 and 1 continually for five seconds. But using a condition variable implemented like in condvar.h this program is liable to deadlock because the signalling thread steals the signal intended for the other thread. I think a note about this should be added to condvar.h. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 15:10:16 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Jun 2012 13:10:16 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340111416.71.0.996682452107.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: I've increased the priority to "release blocker". Reason: We should come to an agreement how to handle the issue. In particular we must not pronounce something as secure that isn't secure. Options: 1) Remove the function. 2) Rename the function to a more sensible name and provide a bytes only implementation. I like the Jon's proposal and suggest timingsafe_compare(). 2b) optionally create a C implementation as it's much easier to check C code for timing issues. ---------- priority: normal -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 15:17:11 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 19 Jun 2012 13:17:11 +0000 Subject: [issue15100] Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile In-Reply-To: <1340020668.92.0.801725909503.issue15100@psf.upfronthosting.co.za> Message-ID: <1340111831.51.0.707148922755.issue15100@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: It's not that simple as we currently use public functions for copying the files and the metadata. copyfile is explicitly _not_ supposed to copy any metadata so we can't patch it up to do so. Also that won't help for other stat & xattr data so this fix would be rather incomplete. umask is ruled out too, because that isn't (if I'm not mistaken) thread safe thus wouldn't help against stat & xattr disclosures anyway. Therefore we'll have to re-implement the whole metadata "stack" for copy and copy2 using fd-based functions. Taking into account #4489, I guess it's the best way (+ hoping someone implements safe versions for other platforms too). The mode itself can also be copied pretty easily using a custom opener for open (os.open has a mode argument). I doubt I will be able to do that till beta1 though. But I suppose we can commit this while in the betas? ---------- keywords: -patch nosy: +loewis, pitrou stage: -> needs patch versions: +Python 3.3 -Python 2.7, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15100> _______________________________________ From report at bugs.python.org Tue Jun 19 15:19:59 2012 From: report at bugs.python.org (vjp) Date: Tue, 19 Jun 2012 13:19:59 +0000 Subject: [issue15105] curses: wrong indentation Message-ID: <1340111999.91.0.28631303072.issue15105@psf.upfronthosting.co.za> New submission from vjp <volker.pilipp at dectris.com>: Running the program below on Linux (CentOS 5 and 6) two lines are printed, of which the second one is not correctly indented: Output is: 1234567012345670 012345670 rather than 1234567012345670 012345670 import curses import time def display(screen): while 1: screen.erase() screen.addstr("1234567012345670\n") screen.addstr(" 012345670\n") screen.refresh() time.sleep(100) curses.wrapper(display) ---------- messages: 163161 nosy: vjp priority: normal severity: normal status: open title: curses: wrong indentation type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15105> _______________________________________ From report at bugs.python.org Tue Jun 19 15:20:14 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 13:20:14 +0000 Subject: [issue15064] Use context manager protocol for more multiprocessing types In-Reply-To: <1339676025.91.0.9899325094.issue15064@psf.upfronthosting.co.za> Message-ID: <1340112014.24.0.49644367333.issue15064@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed title: multiprocessing should use more context manager -> Use context manager protocol for more multiprocessing types _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15064> _______________________________________ From report at bugs.python.org Tue Jun 19 15:26:31 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 13:26:31 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340112391.22.0.515101190977.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Yes, another correct observation. This can if a thread is interrupted in between releasing the mutex and waiting for the semaphore. I see no way around this apart from manually creating event objects for every thread. Personally I'm not sure it is a wise guarantee to make. The shift has been away from "handover" semantics towards "retry" semantics for locking in general over the last few years, particularly with the rise of multiprocessing. But this distinction should be made clear and I will make sure to document it. Thanks for pointing this out. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 15:27:19 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 19 Jun 2012 13:27:19 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340112439.81.0.452684378947.issue15061@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: I thought this is settled as of f36af3766a20 (option 2)? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 15:35:17 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 13:35:17 +0000 Subject: [issue12774] Warning -- multiprocessing.process._dangling was modified by test_multiprocessing In-Reply-To: <1313626877.54.0.853743115284.issue12774@psf.upfronthosting.co.za> Message-ID: <1340112917.04.0.643768791342.issue12774@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12774> _______________________________________ From report at bugs.python.org Tue Jun 19 15:36:14 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 13:36:14 +0000 Subject: [issue12882] mmap crash on Windows In-Reply-To: <1314940631.31.0.750108382526.issue12882@psf.upfronthosting.co.za> Message-ID: <1340112974.94.0.46000023763.issue12882@psf.upfronthosting.co.za> Changes by Richard Oudkerk <shibturn at gmail.com>: ---------- status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12882> _______________________________________ From report at bugs.python.org Tue Jun 19 15:47:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 13:47:03 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340113623.91.0.103183815147.issue15038@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Personally I'm not sure it is a wise guarantee to make. If you make sure internal users are immune to this issue, then fine (but make sure to document it somewhere). However, if this lost wakeup problem can affect current users of the API, then it sounds unacceptable. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 15:51:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 13:51:42 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340113902.29.0.264454663931.issue15038@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > However, if this lost wakeup problem can affect current users of the API, then it sounds unacceptable. Let me elaborate: the GIL can perhaps suffer lost wakeups from time to time. The Lock API certainly shouldn't. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 16:05:04 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 14:05:04 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340114704.54.0.944923215743.issue15038@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: > Let me elaborate: the GIL can perhaps suffer lost wakeups from time to > time. The Lock API certainly shouldn't. I think with FORCE_SWITCHING defined (the default?) it is not possible for the thread releasing the GIL to immediately reacquire it (unless there is a spurious wakeup when waiting on switch_cond). If all threads which wait on a condition are testing the same predicate then the stolen wakeup issue probably won't cause any misbehaviour. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 16:15:14 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Jun 2012 14:15:14 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h In-Reply-To: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za> Message-ID: <1340115314.69.0.493878601801.issue15103@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: It looks as great disadvantage compared with Subversion. There are several ways to solve this problem: 1. Python/freeze_importlib.py generates a raw binary file Python/importlib.dump (just marshal dump) and this file is placed in the repository. Then a small C program Python/unpack_importlib.c (or something of the sort) is compiled and converts the file Python/importlib.dump in the file Python/importlib.h. 2. Python/freeze_importlib.py generates a header file Python/importlib.h.in with binary marker as now and this binary file is placed in the repository. Then on Posix systems Python/importlib.h.in is converted to Python/importlib.h by deleting binary marker (tr -d '\0') or whole line with binary marker (head/tail/sed/grep/awk). On Windows Python/importlib.h.in is just copied to Python/importlib.h. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Tue Jun 19 16:27:54 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Jun 2012 14:27:54 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340116074.27.0.710419770214.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Oh, I totally missed Nick's checkin. Sorry for the noise. Should we add the encode('unicode-internal') trick from #14955 as the next best way to compare to unicode strings? ---------- stage: needs patch -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 16:28:39 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Jun 2012 14:28:39 +0000 Subject: [issue14955] hmac.secure_compare() is not time-independent for unicode strings In-Reply-To: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> Message-ID: <1340116119.07.0.196131149115.issue14955@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Nick has pushed a patch in rf36af3766a20 that disables the comparison of unicode strings. See #15061 ---------- dependencies: +hmac.secure_compare() leaks information about length of strings _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14955> _______________________________________ From report at bugs.python.org Tue Jun 19 16:33:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 14:33:16 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340116396.38.0.829803779585.issue15061@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Should we add the encode('unicode-internal') trick from #14955 as the next best way to compare to unicode strings? I don't think so. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 16:37:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jun 2012 14:37:03 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h In-Reply-To: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za> Message-ID: <E1SgzYC-0001xD-O1@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 7d86e207598f by Antoine Pitrou in branch 'default': Issue #15103: remove the NUL character (serving as a Mercurial binary marker) from Python/importlib.h. http://hg.python.org/cpython/rev/7d86e207598f ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Tue Jun 19 16:40:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 14:40:00 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h In-Reply-To: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za> Message-ID: <1340116800.33.0.510853558433.issue15103@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: This should be fixed now. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Tue Jun 19 16:41:11 2012 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 19 Jun 2012 14:41:11 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340116871.45.0.87598422275.issue15061@psf.upfronthosting.co.za> Changes by Alex Gaynor <alex.gaynor at gmail.com>: ---------- nosy: +alex _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 16:45:46 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 14:45:46 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340117146.2.0.377246754759.issue15038@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: The implementation in condvar.h is basically the same as one of the attempts mentioned in http://birrell.org/andrew/papers/ImplementingCVs.pdf (Listing 2 fixed to use non-binary semaphores.) The implementation for multiprocessing.Condition is virtually the same as Listing 3 which the author says he thinks is "formally correct" but with "a fundamental performance problem". ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 16:54:20 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 19 Jun 2012 14:54:20 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h In-Reply-To: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za> Message-ID: <1340117660.21.0.304712895654.issue15103@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: As a general rule, generated files should not be included in the repository. Recent mercurial versions include a "--large" parameter for "hg add" that threat files as binary. In particular, precludes "hg diff", that I guess it is the point here. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Tue Jun 19 17:00:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 15:00:35 +0000 Subject: [issue15103] Solaris compiler chokes on importlib.h In-Reply-To: <1340117660.21.0.304712895654.issue15103@psf.upfronthosting.co.za> Message-ID: <1340117809.3361.6.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > As a general rule, generated files should not be included in the > repository. We already include generated files such as configure. This is either for convenience or for bootstrap purposes. > Recent mercurial versions include a "--large" parameter for "hg add" > that threat files as binary. No, it has nothing to do. "--large" is added by the largefiles extension. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15103> _______________________________________ From report at bugs.python.org Tue Jun 19 17:03:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jun 2012 15:03:33 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <E1Sgzxk-0004kk-RD@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset e8ea27ab9fa6 by Brian Curtin in branch 'default': Add versionchanged tags for #14772 changes http://hg.python.org/cpython/rev/e8ea27ab9fa6 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14772> _______________________________________ From report at bugs.python.org Tue Jun 19 17:06:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 15:06:00 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1340117146.2.0.377246754759.issue15038@psf.upfronthosting.co.za> Message-ID: <1340118156.3361.10.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > The implementation for multiprocessing.Condition is virtually the same > as Listing 3 which the author says he thinks is "formally correct" but > with "a fundamental performance problem". To me, it seems similar to the last listing (under "The Sequel?NT and PThreads"): there's a separate semaphore per waiter, used to wake it up when signal() or broadcast() is called. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 17:06:25 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 15:06:25 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340118385.29.0.434001096745.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: The problem Richard describes isn?t a lost wakeup. PyCOND_SIGNAL _will_ wake up _at least_ one thread. It just isn't guaranteed to be one of those who previously called PyCOND_WAIT(): It could be a latecomer to the game, including the one who called Signal himself. If no such thread comes in to steal it, then one of the waiting threads _will_ wake up. None of the internal usages of condition variables makes this assumption about the order of wakeup from PyCOND_WAIT(). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 17:07:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 15:07:05 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1340118156.3361.10.camel@localhost.localdomain> Message-ID: <1340118225.3361.11.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > > The implementation for multiprocessing.Condition is virtually the same > > as Listing 3 which the author says he thinks is "formally correct" but > > with "a fundamental performance problem". > > To me, it seems similar to the last listing (under "The Sequel?NT and > PThreads"): there's a separate semaphore per waiter, used to wake it up > when signal() or broadcast() is called. Ah, you said multiprocessing.Condition. Sorry. I was thinking about threading.Condition. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 17:07:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 15:07:47 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1340118385.29.0.434001096745.issue15038@psf.upfronthosting.co.za> Message-ID: <1340118266.3361.12.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > The problem Richard describes isn?t a lost wakeup. PyCOND_SIGNAL > _will_ wake up _at least_ one thread. It just isn't guaranteed to be > one of those who previously called PyCOND_WAIT(): It could be a > latecomer to the game, including the one who called Signal himself. > If no such thread comes in to steal it, then one of the waiting > threads _will_ wake up. Ok, thanks for clearing up. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 17:42:52 2012 From: report at bugs.python.org (Ken Cheung) Date: Tue, 19 Jun 2012 15:42:52 +0000 Subject: [issue15106] Potential Bug in errors.c Message-ID: <1340120572.84.0.94173614856.issue15106@psf.upfronthosting.co.za> New submission from Ken Cheung <msrbugzilla at gmail.com>: I observed a code clone from the following files. function : PyErr_Restore @ (file: "Python-3.3.0a4/Python/errors.c", line: 27)~49 function : PyErr_SetExcInfo @ (file: "Python-3.3.0a4/Python/errors.c", line: 341)~353 The function PyErr_Restore performs some checking on traceback while PyErr_SetExcInfo does not. I wonder if this is necessary in the function PyErr_SetExcInfo. The source code is included in the attachment. Hope it helps. ---------- components: None files: errors_clone.txt messages: 163181 nosy: Ken.Cheung priority: normal severity: normal status: open title: Potential Bug in errors.c type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26049/errors_clone.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15106> _______________________________________ From report at bugs.python.org Tue Jun 19 17:50:53 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 19 Jun 2012 15:50:53 +0000 Subject: [issue14913] tokenize the source to manage Pdb breakpoints In-Reply-To: <1337946553.88.0.954704249232.issue14913@psf.upfronthosting.co.za> Message-ID: <1340121053.81.0.484890828035.issue14913@psf.upfronthosting.co.za> Xavier de Gaye <xdegaye at gmail.com> added the comment: Uploaded pdb_default_2.patch. This new patch fixes the previous patch that fails to stop at breakpoints set in nested functions, and extends the previous patch in allowing breakpoints outside function and method definitions. > When a breakpoint is set at the line number of a function definition, > the algorithm used to find the first statement of the function (the > actual breakpoint) is not robust, so that when another breakpoint is > also set at this fuction using the function name instead of the line > number, then this last breakpoint hides the first one. This is not correct. One should read instead: When a breakpoint is set at the first statement of a function and another breakpoint is set using the function name, then the first breakpoint hides the other one. This is fixed as well in both patches. ---------- Added file: http://bugs.python.org/file26050/pdb_default_2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14913> _______________________________________ From report at bugs.python.org Tue Jun 19 17:51:36 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 15:51:36 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340121096.7.0.472507931955.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: It's an interesting article Richard, but I don't see how their 2nd attempt solves the probvlem. All it does is block the thread doing the Signal(), not other threads, from stealing the wakeup. I think I know how to fix this correctly, using a separate internal "locking" condition variable. I will make some offline experiments with that, to see if it makes sense, given the added complexity. In the mean time, I will document this issue and add the link to the article you mentioned. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 17:54:56 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 15:54:56 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340121296.9.0.00662109011305.issue15038@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: The notes should also mention that PyCOND_SIGNAL() and PyCOND_BROADCAST() must be called while holding the mutex. (pthreads does not have that restriction.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 17:59:21 2012 From: report at bugs.python.org (Ken Cheung) Date: Tue, 19 Jun 2012 15:59:21 +0000 Subject: [issue15107] Potential Bug in mpdecimal.c Message-ID: <1340121561.65.0.31237517889.issue15107@psf.upfronthosting.co.za> New submission from Ken Cheung <msrbugzilla at gmail.com>: I observed a code clone from the following files. function : mpd_qexp @ (file: "Python-3.3.0a4/Modules/_decimal/libmpdec/mpdecimal.c", line: 4092)~4165 function : mpd_qln @ (file: "Python-3.3.0a4/Modules/_decimal/libmpdec/mpdecimal.c", line: 4525)~4612 In the first few lines of this clone, the function mpd_qexp only calls mpd_setspecial when mpd_isnegative is false while the function mpd_qln calls mpd_setspecial independent of the value of mpd_isnegative. I wonder the checking is necessary in the function mpd_qln. The source code is included in the attachment. Hope it helps. ---------- components: Library (Lib) files: mpdecimal_clone.txt messages: 163185 nosy: Ken.Cheung priority: normal severity: normal status: open title: Potential Bug in mpdecimal.c type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26051/mpdecimal_clone.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15107> _______________________________________ From report at bugs.python.org Tue Jun 19 18:07:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Jun 2012 16:07:36 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340122056.28.0.474248281849.issue15061@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Unicode string timing depends on the string implementation which depends on the maximum character code in the string. Strings 'A'*9999+'$' 'A'*9999+'?' have different timings for almost all operations (inluding encode('unicode-internal')). ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 18:08:11 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 16:08:11 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340122091.94.0.361443633227.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Right. Without holding the mutex, the definition of "already blocked" is of course meaningless, since only the holding the mutex can define any ordering. pthread standard indeed says "however, if predictable scheduling behaviour is required, then that mutex is locked by the thread calling pthread_cond_signal() or pthread_cond_broadcast()." There are a number of implementations that are subjects to serious problems if the mutex isn't held when doing pthread_cond_signal(), including the notorious 'lost wakeup' bug, eg: http://docs.oracle.com/cd/E19963-01/html/821-1601/sync-21067.html, so it is certainly recommended practice to use pthread_cond_signal() with the mutex held regardless. But you are right, the emulation implementation depends on the mutex not only for predicable scheduling but for synchronizing access to the internal state, and this should be documented. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 18:15:19 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Jun 2012 16:15:19 +0000 Subject: [issue15107] Potential Bug in mpdecimal.c In-Reply-To: <1340121561.65.0.31237517889.issue15107@psf.upfronthosting.co.za> Message-ID: <1340122519.15.0.00141273413387.issue15107@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: The code looks fine to me. > In the first few lines of this clone, the function mpd_qexp only calls > mpd_setspecial when mpd_isnegative is false while the function mpd_qln > calls mpd_setspecial independent of the value of mpd_isnegative. That would probably be because exp(-infinity) is 0, which isn't a floating-point special value, and ln(-infinity) is NaN, which is. In general, I don't think this kind of report is terribly helpful unless you've also examined *and understood* the code, and based on that understanding you've established that there's a high likelihood of a real bug. ---------- nosy: +mark.dickinson, skrah resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15107> _______________________________________ From report at bugs.python.org Tue Jun 19 18:17:23 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 19 Jun 2012 16:17:23 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340122643.31.0.296186943371.issue15104@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Tue Jun 19 18:19:25 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 19 Jun 2012 16:19:25 +0000 Subject: [issue14973] restore python2 unicode literals in "ur" strings In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za> Message-ID: <1340122765.96.0.280414121896.issue14973@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: ---------- superseder: -> Drop support for the "ur" string prefix _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14973> _______________________________________ From report at bugs.python.org Tue Jun 19 18:20:08 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 19 Jun 2012 16:20:08 +0000 Subject: [issue15107] Potential Bug in mpdecimal.c In-Reply-To: <1340121561.65.0.31237517889.issue15107@psf.upfronthosting.co.za> Message-ID: <1340122808.17.0.690882916272.issue15107@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > That would probably be because exp(-infinity) is 0, which isn't a > floating-point special value, and ln(-infinity) is NaN, which is. Actually, looking at the code, mpd_setspecial is called under exactly the same circumstances (namely for +inf) in *both* cases; for -inf, the exp code calls _settriple, while the ln code calls mpd_seterror. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15107> _______________________________________ From report at bugs.python.org Tue Jun 19 18:14:38 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Jun 2012 16:14:38 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340122478.88.0.82831335779.issue15061@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Oh, I see, Antoine said the same thing (msg162771). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 18:31:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jun 2012 16:31:18 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <E1Sh1Kk-0005T3-IU@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset d7a72fdcc168 by Kristjan Valur Jonsson in branch 'default': Issue #15038: Document caveats with the emulated condition variables. http://hg.python.org/cpython/rev/d7a72fdcc168 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 18:38:16 2012 From: report at bugs.python.org (Zachary Ware) Date: Tue, 19 Jun 2012 16:38:16 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1340123896.66.0.152669579196.issue14187@psf.upfronthosting.co.za> Changes by Zachary Ware <zachary.ware at gmail.com>: ---------- nosy: +zach.ware _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14187> _______________________________________ From report at bugs.python.org Tue Jun 19 19:01:20 2012 From: report at bugs.python.org (Zachary Ware) Date: Tue, 19 Jun 2012 17:01:20 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340125280.18.0.913350612845.issue15102@psf.upfronthosting.co.za> Changes by Zachary Ware <zachary.ware at gmail.com>: ---------- nosy: +zach.ware _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Tue Jun 19 19:08:28 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Jun 2012 17:08:28 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340125708.07.0.882549651272.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: I'm well aware of the fact that they have different timings. That's why I argued against including a unicode aware variant of the timing safe compare function. I've used Guido's time machine and seen requests for a unicode function in the future. ;) I think (educated guess) that s.encode('unicode-internal') discloses the least amount of information. That way I argued that we suggest it in the documentation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 19:12:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 17:12:58 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340125708.07.0.882549651272.issue15061@psf.upfronthosting.co.za> Message-ID: <1340125776.3361.13.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > I'm well aware of the fact that they have different timings. That's > why I argued against including a unicode aware variant of the timing > safe compare function. I would not want to repeat myself, but the compare function can be made safe if it restricts itself to a given kind of unicode string (say, all-ASCII). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 19:14:59 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 17:14:59 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340126099.49.0.539635321803.issue15038@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: > It's an interesting article Richard, but I don't see how their 2nd attempt > solves the problem. All it does is block the thread doing the Signal(), > not other threads, from stealing the wakeup. Do you mean the listing on page 5? (The earlier attempts were failures.) The signalling thread holds the lock "x" while issuing the signal "s.V()" and waiting for notification of wakeup "h.P()". A new thread cannot steal the wakeup because it needs to acquire the lock "x" before it can start its wait. Of course, if the main mutex is always held when doing signal()/broadcast() then the lock "x" is unnecessary. I don't think trying to do a full emulation is necessary. Better to just document the limitations. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 19:17:14 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 19 Jun 2012 17:17:14 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340126234.76.0.553579176746.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Ah, right, the lock x, I forgot about that. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 19:24:31 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Jun 2012 17:24:31 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340126671.06.0.503498561822.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Alright, Antoine. Shall explore option 2b) "optionally create a C implementation as it's much easier to check C code for timing issues" as I suggested in http://bugs.python.org/issue15061#msg162893 ? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 19:59:05 2012 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Jun 2012 17:59:05 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340128745.39.0.126901744498.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: New patch (pep362.5.patch) Fixed a bug in BoundArguments.args & BoundArguments.kwargs ---------- Added file: http://bugs.python.org/file26052/pep362.5.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Tue Jun 19 20:08:54 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 19 Jun 2012 18:08:54 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340129334.79.0.81958754259.issue15038@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: 1.41 Generic emulations of the pthread_cond_* API using 1.42 earlier Win32 functions can be found on the Web. 1.43 The following read can be edificating (or not): 1.44 http://www.cse.wustl.edu/~schmidt/win32-cv-1.html 1.45 + 1.46 + See also 1.47 */ 1.45 and 1.46 should be removed? Also I would not recommend the win32-cv-1.html page as "edificating" (edifying?). The implementations all either suffer from the same stolen wakeup issue or are broken.* * win32-cv-1.html assumes that SignalObjectAndWait() is atomic and that PulseEvent() is guaranteed to wake a waiting thread if there is one -- but Microsoft's documentation now admits that both these assumptions are false. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Tue Jun 19 20:21:05 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 19 Jun 2012 18:21:05 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1340130065.74.0.655611823601.issue14684@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: So my question is easy: could we apply this patch as is and defer any "improvement" to 3.4?. The risk of not doing so would be to miss 3.3 completely. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Tue Jun 19 20:34:49 2012 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Jun 2012 18:34:49 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340130889.28.0.958840812764.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: New patch (pep362.6.patch) Fixed a bug in BoundArguments.args when positional arguments were partially mapped by functools.partial ---------- Added file: http://bugs.python.org/file26053/pep362.6.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Tue Jun 19 20:38:10 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 19 Jun 2012 18:38:10 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340131090.14.0.280947822888.issue444582@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: Before we miss yet another beta freeze, how does something like this look? It moves `which` into one function which always yields paths. I don't think anyone will approve of adding a dual-function API to solve this problem. I originally tried an approach where the function returned one value and had an option to return an iterator, but nearly everyone I asked found it unacceptable and potentially confusing. This patch removes the custom pathext stuff seen in other patches. It doesn't seem like it would be that useful to have it, and I'm not sure why you would want to. Unless anyone is violently opposed, I think we should just go on with it. If we want to add to it, we can add to it in 3.4, but I think something should go in for 3.3. The issue has been open with various patches for over 10 years... ---------- assignee: tarek -> brian.curtin Added file: http://bugs.python.org/file26054/issue444582.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Tue Jun 19 20:38:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 19 Jun 2012 18:38:35 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340131115.45.0.022923676535.issue15008@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: I left a few comments on rietveld. The '\' is sometimes used where not necessary and the preferred way to write conditions on multiple lines is: (foo == bar and bar == baz and baz == asd) rather than foo == bar \ and bar == baz \ and baz == asd Have you measured the coverage of the tests? ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Tue Jun 19 21:26:33 2012 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Jun 2012 19:26:33 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340133993.97.0.780750991269.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: New patch - pep362.6.patch Ezio, I've eliminated almost all '\'. Test coverage is now almost 100%. ---------- Added file: http://bugs.python.org/file26055/pep362.6.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Tue Jun 19 22:08:49 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:08:49 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340136529.57.0.0653938179772.issue15061@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: So it's not a blocker anymore, right? ---------- nosy: +georg.brandl priority: release blocker -> normal _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Tue Jun 19 22:09:22 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:09:22 +0000 Subject: [issue13463] Fix parsing of package_data In-Reply-To: <1322068433.36.0.783240091616.issue13463@psf.upfronthosting.co.za> Message-ID: <1340136562.84.0.945070941623.issue13463@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: This has "Python 3.3" set as Version. Does it really block the 3.3 release? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13463> _______________________________________ From report at bugs.python.org Tue Jun 19 22:09:51 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:09:51 +0000 Subject: [issue14225] _cursesmodule compile error in OS X 32-bit-only installer build In-Reply-To: <1331161185.98.0.75427514561.issue14225@psf.upfronthosting.co.za> Message-ID: <1340136591.82.0.809115707335.issue14225@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Is this issue still valid? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14225> _______________________________________ From report at bugs.python.org Tue Jun 19 22:10:11 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:10:11 +0000 Subject: [issue5302] Allow package_data specs/globs to match directories In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za> Message-ID: <1340136611.11.0.436595794768.issue5302@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Does this block 3.3b1? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5302> _______________________________________ From report at bugs.python.org Tue Jun 19 22:11:35 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:11:35 +0000 Subject: [issue14340] Update embedded copy of expat - fix security & crash issues In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za> Message-ID: <1340136695.58.0.913896222031.issue14340@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Greg, are you still going to update expat in time for 3.3? Otherwise this doesn't block 3.3 anymore. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14340> _______________________________________ From report at bugs.python.org Tue Jun 19 22:13:03 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:13:03 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1340136783.83.0.832062739905.issue14578@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Brett (and/or Brian?), this sounds like it should be tackled soon, to give Windows users enough time of testing 3.3. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14578> _______________________________________ From report at bugs.python.org Tue Jun 19 22:14:51 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:14:51 +0000 Subject: [issue14790] use packaging in setup.py In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za> Message-ID: <1340136891.72.0.410789614723.issue14790@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: I'm not willing to hold up 3.3 for this. On the other hand, it should not be done in the beta stage. And I don't assume it's a trivial matter (?ric?), so I'm inclined to move it to 3.4. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14790> _______________________________________ From report at bugs.python.org Tue Jun 19 22:15:14 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:15:14 +0000 Subject: [issue12779] Update packaging documentation In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za> Message-ID: <1340136914.68.0.395275847832.issue12779@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Ping. Does this block 3.3? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12779> _______________________________________ From report at bugs.python.org Tue Jun 19 22:15:47 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:15:47 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1340136947.3.0.416766170947.issue13959@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Which parts are still missing here? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Tue Jun 19 22:16:36 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:16:36 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za> Message-ID: <1340136996.79.0.42804976668.issue14928@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Is this ready to go in before beta1? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Tue Jun 19 22:17:15 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:17:15 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1340137035.19.0.55314365276.issue15096@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: If you commit this, please do so before beta1. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Tue Jun 19 22:17:55 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:17:55 +0000 Subject: [issue12046] Windows build identification incomplete In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za> Message-ID: <1340137075.41.0.463654195755.issue12046@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: I guess this is not an issue anymore. ---------- resolution: -> out of date status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12046> _______________________________________ From report at bugs.python.org Tue Jun 19 22:18:13 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:18:13 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340137093.03.0.13754774036.issue13590@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Ping? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Tue Jun 19 22:19:19 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 19 Jun 2012 20:19:19 +0000 Subject: [issue14940] Usage documentation for pysetup In-Reply-To: <1338246677.91.0.429583785939.issue14940@psf.upfronthosting.co.za> Message-ID: <1340137159.92.0.772154569939.issue14940@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Ping. This isn't necessary for beta1, but would be nice to have once the final release draws near. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14940> _______________________________________ From report at bugs.python.org Tue Jun 19 22:30:51 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 19 Jun 2012 20:30:51 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340137851.44.0.316191489893.issue13590@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: In progress; fixes for this and the other Xcode4-related issues will be in for 3.3.0b1. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Tue Jun 19 22:33:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Jun 2012 20:33:00 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za> Message-ID: <E1Sh56g-0004iQ-0c@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c3616595dada by Antoine Pitrou in branch 'default': Issue #14928: Fix importlib bootstrap issues by using a custom executable (Modules/_freeze_importlib) to build Python/importlib.h. http://hg.python.org/cpython/rev/c3616595dada ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Tue Jun 19 22:45:40 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 19 Jun 2012 20:45:40 +0000 Subject: [issue14225] _cursesmodule compile error in OS X 32-bit-only installer build In-Reply-To: <1331161185.98.0.75427514561.issue14225@psf.upfronthosting.co.za> Message-ID: <1340138740.63.0.402886020217.issue14225@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: It was still valid as of 3.3.0a4. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14225> _______________________________________ From report at bugs.python.org Tue Jun 19 22:52:39 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Jun 2012 20:52:39 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1340139159.59.0.468393914995.issue15096@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: I'll submit an updated patch tomorrow. ---------- assignee: -> christian.heimes _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Tue Jun 19 23:19:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Jun 2012 21:19:13 +0000 Subject: [issue14928] Fix importlib bootstrapping issues In-Reply-To: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za> Message-ID: <1340140753.03.0.530770697542.issue14928@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Should be ok now. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14928> _______________________________________ From report at bugs.python.org Tue Jun 19 23:43:43 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Jun 2012 21:43:43 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1340142223.75.0.138853073791.issue15096@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: New patch: * corrected comment in Parser/tokenizer.c * added test for ub"" and bu"" raising SyntaxError * removed handling of ur"" from tokenize module Serhiy, could you please review my changed to the tokenize module? I think I found all relevant places but I'm not absolutely sure. ---------- keywords: +needs review stage: needs patch -> patch review Added file: http://bugs.python.org/file26056/issue15096-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Tue Jun 19 23:52:14 2012 From: report at bugs.python.org (Pankaj D) Date: Tue, 19 Jun 2012 21:52:14 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function Message-ID: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za> New submission from Pankaj D <pxd at comcast.net>: Hi, Sporadically, while running an sqlite3 query, the above error is seen. In order to debug, I modified Objects/tupleobject.c, PyTuple_SetItem() as follows: if (!PyTuple_Check(op) || op->ob_refcnt != 1) { Py_XDECREF(newitem); /* * Temp: Bug XYZ Generate core so that we can debug * * PyErr_BadInternalCall(); * return -1; */ char errmsg[200]; sprintf(errmsg, "Bug XYZ: PyTuple_Check(op) = %d " "op->ob_refcnt = %d; see core\n", PyTuple_Check(op), op->ob_refcnt); Py_FatalError(errmsg); } This generates a core with the following bt. Showing the top few frames only: (gdb) bt #0 0x0000000800acd3fc in thr_kill () at thr_kill.S:3 #1 0x0000000800b5e283 in abort () at /build/mnt/src/lib/libc/stdlib/abort.c:65 #2 0x0000000000494acf in Py_FatalError (msg=Variable "msg" is not available. ) at ./../Python/pythonrun.c:1646 #3 0x000000000044e740 in PyTuple_SetItem (op=0x80c6e6308, i=16, newitem=0x80a80d780) at ./../Objects/tupleobject.c:128 #4 0x0000000807298866 in _pysqlite_fetch_one_row (self=0x80b846e48) at _sqlite/cursor.c:402 #5 0x0000000807298bf5 in pysqlite_cursor_iternext (self=0x80b846e48) at _sqlite/cursor.c:898 #6 0x0000000000476943 in PyEval_EvalFrameEx (f=0x80a94d420, throwflag=Variable "throwflag" is not available. ) at ./../Python/ceval.c:2237 #7 0x000000000047acbf in PyEval_EvalFrameEx (f=0x80a94b820, throwflag=Variable "throwflag" is not available. ) at ./../Python/ceval.c:3765 #8 0x000000000047bf09 in PyEval_EvalCodeEx (co=0x808d2ac60, globals=Variable "globals" is not available. ) at ./../Python/ceval.c:2942 ... (gdb) fr 4 #4 0x0000000807298866 in _pysqlite_fetch_one_row (self=0x80b846e48) at _sqlite/cursor.c:402 402 PyTuple_SetItem(row, i, converted); Current language: auto; currently c (gdb) l 397 converted = buffer; 398 } (gdb) p *(PyTupleObject *)row $11 = {ob_refcnt = 2, ob_type = 0x60fee0, ob_size = 22, ob_item = {0x80a534030}} 'row' was allocated via PyTuple_New() but, somehow its refcount has become 2 while setting the 16th item!!! Is this a known issue? If not, what can I do to debug. Thanks, Pankaj ---------- messages: 163224 nosy: pxd priority: normal severity: normal status: open title: ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function type: behavior versions: Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Tue Jun 19 23:57:25 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 19 Jun 2012 21:57:25 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function In-Reply-To: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za> Message-ID: <1340143045.09.0.235170520672.issue15108@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Could you possibly reproduce this in 2.7, 3.2 and/or "default" (future 3.3)?. Python 2.6 support is over. ---------- components: +Cross-Build nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Tue Jun 19 23:57:55 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 19 Jun 2012 21:57:55 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function In-Reply-To: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za> Message-ID: <1340143075.85.0.888898824199.issue15108@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- components: -Cross-Build _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Wed Jun 20 00:11:03 2012 From: report at bugs.python.org (Pankaj D) Date: Tue, 19 Jun 2012 22:11:03 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function In-Reply-To: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za> Message-ID: <1340143863.54.0.680287095515.issue15108@psf.upfronthosting.co.za> Pankaj D <pxd at comcast.net> added the comment: sorry, 2.7, 3.2 is not an option currently but I am hoping someone can provide enough info to help probe this more efficiently. There seem to be references to this issue on the web but no root-cause. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Wed Jun 20 00:18:48 2012 From: report at bugs.python.org (Ev Kontsevoy) Date: Tue, 19 Jun 2012 22:18:48 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception Message-ID: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> New submission from Ev Kontsevoy <eugueny at gmail.com>: When calling connection.iterdump() on a database with non-ASCII string values, the following exception is raised: ---------------------------------------------------- File "/python-2.7.3/lib/python2.7/sqlite3/dump.py", line 56, in _iterdump yield("{0};".format(row[0])) UnicodeEncodeError: 'ascii' codec can't encode characters in position 48-51: ordinal not in range(128) ---------------------------------------------------- The older versions used the following (safer) version in /python-2.7.3/lib/python2.7/sqlite3/dump.py:56: yield("%s;" % row[0]) ---------- components: Library (Lib) messages: 163227 nosy: ekontsevoy priority: normal severity: normal status: open title: sqlite3.Connection.iterdump() dies with encoding exception versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 00:19:08 2012 From: report at bugs.python.org (Ev Kontsevoy) Date: Tue, 19 Jun 2012 22:19:08 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340144348.19.0.0436738852438.issue15109@psf.upfronthosting.co.za> Changes by Ev Kontsevoy <eugueny at gmail.com>: ---------- type: -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 00:28:20 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Tue, 19 Jun 2012 22:28:20 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1340144900.37.0.56072489785.issue14684@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: I plan to commit it (along with the buffer API changes) tomorrow. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Wed Jun 20 00:32:25 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 19 Jun 2012 22:32:25 +0000 Subject: [issue13463] Fix parsing of package_data In-Reply-To: <1322068433.36.0.783240091616.issue13463@psf.upfronthosting.co.za> Message-ID: <1340145145.76.0.405663503798.issue13463@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I?ve been using the release blocker priority to mark things that need to be solved for the next d2 alpha release, and by extension before the 3.3 release as the plan was to have d2 in 3.3 (see my recent python-dev email about that). If that interferes with CPython release management feel free to demote them to ?high? or tell me if you?d like me to do it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13463> _______________________________________ From report at bugs.python.org Wed Jun 20 00:53:19 2012 From: report at bugs.python.org (Ev Kontsevoy) Date: Tue, 19 Jun 2012 22:53:19 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340146399.75.0.609941473823.issue15109@psf.upfronthosting.co.za> Ev Kontsevoy <eugueny at gmail.com> added the comment: Proposed fix: maybe yield(u"%s;" % row[0]) or simply row[0] + ";"? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 01:09:58 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 19 Jun 2012 23:09:58 +0000 Subject: [issue12046] Windows build identification incomplete In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za> Message-ID: <1340147398.17.0.406724993578.issue12046@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: It's indeed resolved. ---------- resolution: out of date -> duplicate status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12046> _______________________________________ From report at bugs.python.org Wed Jun 20 01:39:23 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 19 Jun 2012 23:39:23 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1340149163.09.0.364423505017.issue13959@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: Here are the things I'm aware of: * implement imp.get_tag() using sys.implementation * *maybe* implement imp.get_magic() in pure Python (patch already attached here) * (low priority) find a way to rip out the bulk of PyImport_ExecCodeModuleObject() from imp.c, if practical >From my discussions with Brett, there was a laundry list he was aiming to get in for 3.3 (for import stuff in general). I know much of it got done, but not all of it. Of the remainder, I'm not sure how much of that he still wants to see get in. Some of it pertains to this issue, though not all. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Wed Jun 20 02:11:48 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 20 Jun 2012 00:11:48 +0000 Subject: [issue15110] strange Tracebacks with importlib Message-ID: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>: Exceptions during import now display huge tracebacks across importlib._bootstrap, this adds a lot of noise to the error: For example, I added some syntax error in distutils/spawn.py, then: ~/python/cpython3.x$ ./python -c "from distutils import ccompiler" Traceback (most recent call last): File "<string>", line 1, in <module> File "<frozen importlib._bootstrap>", line 1335, in _handle_fromlist File "<frozen importlib._bootstrap>", line 1288, in _find_and_load File "<frozen importlib._bootstrap>", line 1255, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper File "<frozen importlib._bootstrap>", line 778, in load_module File "<frozen importlib._bootstrap>", line 759, in load_module File "<frozen importlib._bootstrap>", line 408, in module_for_loader_wrapper File "<frozen importlib._bootstrap>", line 647, in _load_module File "/home/amauryfa/python/cpython3.x/Lib/distutils/ccompiler.py", line 8, in <module> from distutils.spawn import spawn File "<frozen importlib._bootstrap>", line 1288, in _find_and_load File "<frozen importlib._bootstrap>", line 1255, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper File "<frozen importlib._bootstrap>", line 778, in load_module File "<frozen importlib._bootstrap>", line 759, in load_module File "<frozen importlib._bootstrap>", line 408, in module_for_loader_wrapper File "<frozen importlib._bootstrap>", line 635, in _load_module File "<frozen importlib._bootstrap>", line 736, in get_code File "/home/amauryfa/python/cpython3.x/Lib/distutils/spawn.py", line 14 does not compile ^ SyntaxError: invalid syntax ---------- components: Library (Lib) messages: 163233 nosy: amaury.forgeotdarc priority: normal severity: normal status: open title: strange Tracebacks with importlib type: behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Wed Jun 20 02:17:27 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 20 Jun 2012 00:17:27 +0000 Subject: [issue15111] Wrong ImportError message with importlib Message-ID: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>: Up to Python3.2, a nested ImportError was correctly displayed: ./python -c "import distutils.msvc9compiler" Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/amauryfa/python/cpython3.2/Lib/distutils/msvc9compiler.py", line 27, in <module> import winreg ImportError: No module named winreg But with 3.3, the traceback is lost: ~/python/cpython3.x$ ./python -c "from distutils import msvc9compiler" Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: cannot import name msvc9compiler Even though the failure is still on the "import winreg" line. Only ImportError seems affected, other exceptions are correctly displayed. ---------- components: Interpreter Core messages: 163234 nosy: amaury.forgeotdarc priority: normal severity: normal status: open title: Wrong ImportError message with importlib type: behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15111> _______________________________________ From report at bugs.python.org Wed Jun 20 02:49:00 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 00:49:00 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340153340.07.0.509942909081.issue15109@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: It's not clear to me why the behavior differs. Hopefully Eric will explain. For 2.7 we should probably just revert the change to the yield statement to restore the previous behavior, unless format can be fixed. ---------- nosy: +eric.smith, r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 02:52:58 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 00:52:58 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340153578.8.0.885522783163.issue15110@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: importlib is written in python. So you get a python traceback of its execution stack. Yes it is noisy, but I'm not sure that this should be changed, or we'd lose some of the benefit of having importlib written in python. (It also might be really complicated to change...I'm sure Brett will tell us :) ---------- nosy: +brett.cannon, r.david.murray versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Wed Jun 20 02:57:17 2012 From: report at bugs.python.org (Ev Kontsevoy) Date: Wed, 20 Jun 2012 00:57:17 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340153837.52.0.883257556666.issue15109@psf.upfronthosting.co.za> Ev Kontsevoy <eugueny at gmail.com> added the comment: If the behavior of string.format() can be fixed to act identically to u"%s" % "" that would be simply wonderful! Currently at work we have a rule in place: to never use string.format() since it cannot be used for anything but constants due to encoding exceptions. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 03:00:22 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 01:00:22 +0000 Subject: [issue15111] Wrong ImportError message with importlib In-Reply-To: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za> Message-ID: <1340154022.08.0.695245134343.issue15111@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: To clarify Amaury's example: rdmurray at hey:~/python/p33>./python -c "import distutils.msvc9compiler" Traceback (most recent call last): File "<string>", line 1, in <module> File "<frozen importlib._bootstrap>", line 1288, in _find_and_load File "<frozen importlib._bootstrap>", line 1255, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper File "<frozen importlib._bootstrap>", line 778, in load_module File "<frozen importlib._bootstrap>", line 759, in load_module File "<frozen importlib._bootstrap>", line 408, in module_for_loader_wrapper File "<frozen importlib._bootstrap>", line 647, in _load_module File "/home/rdmurray/python/p33/Lib/distutils/msvc9compiler.py", line 27, in <module> import winreg File "<frozen importlib._bootstrap>", line 1288, in _find_and_load File "<frozen importlib._bootstrap>", line 1252, in _find_and_load_unlocked ImportError: No module named 'winreg' rdmurray at hey:~/python/p33>./python -c "from distutils import msvc9compiler" Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: cannot import name msvc9compiler rdmurray at hey:~/python/p32>./python -c "import distutils.msvc9compiler" Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/rdmurray/python/p32/Lib/distutils/msvc9compiler.py", line 27, in <module> import winreg ImportError: No module named winreg So there is definitely some lost information in 3.3 in the 'import from' case. ---------- nosy: +brett.cannon, r.david.murray priority: normal -> high stage: -> needs patch versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15111> _______________________________________ From report at bugs.python.org Wed Jun 20 03:01:04 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 01:01:04 +0000 Subject: [issue15111] Wrong ImportError message with importlib In-Reply-To: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za> Message-ID: <1340154064.08.0.917499068892.issue15111@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- Removed message: http://bugs.python.org/msg163238 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15111> _______________________________________ From report at bugs.python.org Wed Jun 20 03:02:39 2012 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 20 Jun 2012 01:02:39 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340154159.76.0.352747837813.issue15109@psf.upfronthosting.co.za> Eric V. Smith <eric at trueblade.com> added the comment: Could you reproduce this in a short script that doesn't use sqlite? I'm looking for something like: str = 'some-string' "{0}".format(str) Also: is that the entire traceback? I don't see how format could be invoking a codec. Maybe the error occurs when writing it to stdout, or some other operation that's encoding? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 03:03:49 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 01:03:49 +0000 Subject: [issue15111] Wrong ImportError message with importlib In-Reply-To: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za> Message-ID: <1340154229.74.0.123054832096.issue15111@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: To clarify Amaury's example: rdmurray at hey:~/python/p32>./python -c "from distutils import msvc9compiler" Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/rdmurray/python/p32/Lib/distutils/msvc9compiler.py", line 27, in <module> import winreg ImportError: No module named winreg rdmurray at hey:~/python/p33>./python -c "from distutils import msvc9compiler" Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: cannot import name msvc9compiler So there is definitely some lost information in 3.3 compared to 3.2 in the 'import from' case. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15111> _______________________________________ From report at bugs.python.org Wed Jun 20 03:09:39 2012 From: report at bugs.python.org (Ev Kontsevoy) Date: Wed, 20 Jun 2012 01:09:39 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340154579.46.0.886110911048.issue15109@psf.upfronthosting.co.za> Ev Kontsevoy <eugueny at gmail.com> added the comment: I am attaching death.py file which dies on string.format() The stack trace above is at the full depth. Python doesn't print anything from inside of format(). ---------- Added file: http://bugs.python.org/file26057/death.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 03:37:49 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 01:37:49 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340156269.22.0.102067071459.issue444582@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I'm not sure why there isn't a review link for your patch. "which(file..." I don't think file is a good name. 'fn' or 'filename' or 'string' would all be better choices, I think. 'file' implies a Python file object (to me). And "the give *file* command is called" just looks wrong. "Yield the full path to the executables which could be run if the given *filename* were looked up...." Wait, why are we even returning more than one result? I don't see any use cases for that in the issue (though I admit I just skimmed it). The unix which command doesn't. Wanting only the first match is going to be far more common than wanting a list, so it should be the case supported most easily by the API. If getting the complete list is useful, the API can be extended or a new function added later. Then the motivation statement becomes clearer: "Yield the full path to the executables which would be run if the given *filename* were typed at the shell prompt or passed to the os.exec*p* functions." Given that the function works on Windows, its behavior (looking in the current directory and in PATHEXT) should be documented. And if that's not what exec*p* does on windows, that should be noted, I think (or fixed?) I'm also not sure what the 'path' argument is for. Does it have a use case? If not, drop it. You are doing the PATHEXT extraction regardless of platform, which I don't think is a good idea. This line appears to be useless: base = os.path.join(dir, file) Per my suggestion of dropping the list form (at least for now), the yield should become a return, with the default return value of None indicating not found. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Wed Jun 20 03:47:15 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 20 Jun 2012 01:47:15 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1340156835.84.0.151846582894.issue13959@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: Added file: http://bugs.python.org/file26058/issue13959_get_tag.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Wed Jun 20 03:49:14 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 01:49:14 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340156954.66.0.665582360521.issue15109@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: >>> print('{}'.format(u'\u2107')) Traceback (most recent call last): File "<stdin>", line 1, in <module> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2107' in position 0: ordinal not in range(128) >>> print('%s' % u'\u2107') ? (You get the exception without the print as well, just in case that isn't clear.) Ah, and now I see why this is true. The '%s' gets implicitly coerced to unicode. So, it is not a bug in format, and the yield statement change should be reverted. You can use format if you just always make your format input strings unicode strings (which you should be doing anyway, especially now that python3.3 will allow the 'u' prefix...that is, such code will be forward-compatible with Python3). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 03:50:30 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 01:50:30 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340157030.32.0.340248505295.issue15109@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Or use 'from __future__ import unicode_literals'. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 03:56:37 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 01:56:37 +0000 Subject: [issue9750] sqlite3 iterdump fails on column with reserved name In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za> Message-ID: <1340157397.24.0.337279855843.issue9750@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Note that the use of 'format' in the 2.7 patch caused a regression (% causes an implicit promotion to unicode, .format does not). See issue 15109. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9750> _______________________________________ From report at bugs.python.org Wed Jun 20 03:58:45 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 01:58:45 +0000 Subject: [issue15109] sqlite3.Connection.iterdump() dies with encoding exception In-Reply-To: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za> Message-ID: <1340157525.29.0.520486321987.issue15109@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Note that this is a regression in 2.7.3 relative to 2.7.2, which is why I'm marking it as high priority. ---------- nosy: +petri.lehtinen priority: normal -> high stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15109> _______________________________________ From report at bugs.python.org Wed Jun 20 06:04:46 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 20 Jun 2012 04:04:46 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <1340165086.91.0.0445029226891.issue6727@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Would you mind making a small change and use assertEqual instead of an assert statement? The test suite should run the same tests under -O and -OO; there are remaining asserts in old tests but for the last year or two we?ve tried to change them. Thanks in advance. ---------- versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6727> _______________________________________ From report at bugs.python.org Wed Jun 20 06:06:58 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 20 Jun 2012 04:06:58 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <1340165218.86.0.0063409487133.issue6727@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: (Oh BTW I put back 3.3 in versions without seeing you had removed it recently; even though the bug is not present there, the tests from 3.2 are merged into 3.3 so if I understand the use of the versions field correctly it makes sense to keep 3.3. Didn?t want you to think I was reverting your deliberate changes on a whim :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6727> _______________________________________ From report at bugs.python.org Wed Jun 20 06:15:47 2012 From: report at bugs.python.org (Walter Mundt) Date: Wed, 20 Jun 2012 04:15:47 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional Message-ID: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> New submission from Walter Mundt <waltermundt at codethink.info>: Test case: from argparse import * parser = ArgumentParser() parser.add_argument('-x', action='store_true') parser.add_argument('y') parser.add_argument('z', nargs='*') print parser.parse_args('yy -x zz'.split(' ')) The result of this is that the "z" option is unfilled, and the "zz" argument is unrecognized, resulting in an error. Changing the 'nargs' to '+' works in this case, but results in errors if the 'zz' is left off. ---------- messages: 163249 nosy: waltermundt priority: normal severity: normal status: open title: argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15112> _______________________________________ From report at bugs.python.org Wed Jun 20 07:42:44 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 05:42:44 +0000 Subject: [issue415492] Compiler generates relative filenames Message-ID: <1340170964.11.0.033047477304.issue415492@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: What is the status of this bug? This is the oldest open bug. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue415492> _______________________________________ From report at bugs.python.org Wed Jun 20 07:46:55 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 05:46:55 +0000 Subject: [issue3208] function annotation for builtin and C function In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za> Message-ID: <1340171215.62.0.395169724313.issue3208@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: What is the status of this bug? ---------- nosy: +ramchandra.apte _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3208> _______________________________________ From report at bugs.python.org Wed Jun 20 07:49:22 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 20 Jun 2012 05:49:22 +0000 Subject: [issue3208] function annotation for builtin and C function In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za> Message-ID: <1340171362.64.0.660362505598.issue3208@psf.upfronthosting.co.za> Benjamin Peterson <benjamin at python.org> added the comment: Awaiting a patch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3208> _______________________________________ From report at bugs.python.org Wed Jun 20 07:53:22 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 20 Jun 2012 05:53:22 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340171602.89.0.506345849558.issue444582@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: > I don't think file is a good name. Changed to "cmd" for command, and that's what the Unix `which` calls it as well. > Wait, why are we even returning more than one result? I don't see any use cases for that in the issue (though I admit I just skimmed it). The unix which command doesn't. I guess I just stuck with what was always there, or maybe I introduced it back in an earlier patch - can't remember. In any case, thanks for mentioning this because the common case really is just wanting one path. `which -a` prints all instances on the path, but that'd be an additional and less-used case for sure. > Given that the function works on Windows, its behavior (looking in the current directory and in PATHEXT) should be documented. And if that's not what exec*p* does on windows, that should be noted, I think (or fixed?) Documented. > I'm also not sure what the 'path' argument is for. Does it have a use case? If not, drop it. I've needed this myself when maintaining systems that need to start executables via subprocess.Popen using a Path from a configuration file or other inputs. When I'd need to setup a Path which included a lot of dependencies, like for a mini-continous integration system we had, it would be nice to know where the "foo" command was coming from in my temporary build environment. > You are doing the PATHEXT extraction regardless of platform, which I don't think is a good idea. Changed, it's Windows specific now. I will have access to a linux box to test this out tomorrow morning, but I think the patch should work there. > This line appears to be useless: Removed, that must have been from an old iteration. > Per my suggestion of dropping the list form (at least for now), the yield should become a return, with the default return value of None indicating not found. Done. It's all returns now including a default of None. ---------- Added file: http://bugs.python.org/file26059/issue444582_v2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Wed Jun 20 08:03:52 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 06:03:52 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working Message-ID: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> New submission from Ramchandra Apte <maniandram01 at gmail.com>: delattr(__builtins__,"getattr") causes shell to stop working if you type some code in nothing gets printed back if you press enter without typing any code you get a traceback Exception in thread SockThread: Traceback (most recent call last): File "/usr/lib/python3.2/socketserver.py", line 284, in _handle_request_noblock self.process_request(request, client_address) File "/usr/lib/python3.2/socketserver.py", line 310, in process_request self.finish_request(request, client_address) File "/usr/lib/python3.2/socketserver.py", line 323, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib/python3.2/idlelib/rpc.py", line 503, in __init__ socketserver.BaseRequestHandler.__init__(self, sock, addr, svr) File "/usr/lib/python3.2/socketserver.py", line 637, in __init__ self.handle() File "/usr/lib/python3.2/idlelib/run.py", line 264, in handle rpc.RPCHandler.getresponse(self, myseq=None, wait=0.05) File "/usr/lib/python3.2/idlelib/rpc.py", line 280, in getresponse response = self._getresponse(myseq, wait) File "/usr/lib/python3.2/idlelib/rpc.py", line 300, in _getresponse response = self.pollresponse(myseq, wait) File "/usr/lib/python3.2/idlelib/rpc.py", line 438, in pollresponse response = self.localcall(seq, resq) File "/usr/lib/python3.2/idlelib/rpc.py", line 185, in localcall method = getattr(obj, methodname) NameError: global name 'getattr' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.2/threading.py", line 740, in _bootstrap_inner self.run() File "/usr/lib/python3.2/threading.py", line 693, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.2/idlelib/run.py", line 135, in manage_socket server.handle_request() # A single request only File "/usr/lib/python3.2/socketserver.py", line 269, in handle_request self._handle_request_noblock() File "/usr/lib/python3.2/socketserver.py", line 286, in _handle_request_noblock self.handle_error(request, client_address) File "/usr/lib/python3.2/idlelib/run.py", line 240, in handle_error print('Request: ', repr(request), file=erf) File "/usr/lib/python3.2/socket.py", line 111, in __repr__ getattr(self, '_closed', False) and " [closed] " or "", NameError: global name 'getattr' is not defined ---------- messages: 163254 nosy: ramchandra.apte priority: normal severity: normal status: open title: IDLE Shell: delattr(__builtins__,"getattr") causes shell to stop working versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 08:05:22 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 06:05:22 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340172322.5.0.852480121323.issue15113@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Running the delattr(__builtins__,"getattr") in Python from the cmd line doesn't create any problems though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 08:08:31 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 06:08:31 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340172511.8.0.727399550617.issue15113@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Another note: this bug is reproducable in the IDLE Shell with the python subprocess feature enabled (the python process that runs your commands and the python process that manages IDLE's windows are different). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 08:18:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 20 Jun 2012 06:18:06 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340173086.46.0.471866588679.issue15113@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Why do you think this is a bug? It is expected behavior. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 08:41:45 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 20 Jun 2012 06:41:45 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340174505.36.0.832954950835.issue15110@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: I agree that this is not helpful at all in the usual case, i.e. when you *don't* want to debug importlib. The one frame in actual user code (distutils in this case) in the middle is kind of hard to spot, but it is what you want to know. Note that Amaury's example is quite small; in other projects the import chains may go on for 10-20 modules until the ImportError is raised. Good luck finding out where the bad module was imported without cursing. This is different from the normal case in user code calling stdlib code, which raises an exception: the user code frames will be near the top, and the stdlib code near the bottom. I see several options here, in no particular order of preference: 1. special-case importlib._bootstrap when printing tracebacks 2. rewrite the traceback object when raising ImportErrors from importlib 5. (is there more?) ---------- assignee: -> brett.cannon nosy: +georg.brandl priority: normal -> critical _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Wed Jun 20 08:53:03 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 20 Jun 2012 06:53:03 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340175183.49.0.928984118274.issue15110@psf.upfronthosting.co.za> Changes by Georg Brandl <georg at python.org>: ---------- nosy: +gvanrossum _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Wed Jun 20 08:54:17 2012 From: report at bugs.python.org (Leon Zhang) Date: Wed, 20 Jun 2012 06:54:17 +0000 Subject: [issue15076] Sometimes couldn't import os, shown 'import site' failed, use -v for trackback In-Reply-To: <1339753863.16.0.615623699476.issue15076@psf.upfronthosting.co.za> Message-ID: <1340175257.27.0.638332615417.issue15076@psf.upfronthosting.co.za> Changes by Leon Zhang <leozhang at cisco.com>: Removed file: http://bugs.python.org/file26015/pygen.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15076> _______________________________________ From report at bugs.python.org Wed Jun 20 08:55:01 2012 From: report at bugs.python.org (Leon Zhang) Date: Wed, 20 Jun 2012 06:55:01 +0000 Subject: [issue15076] Sometimes couldn't import os, shown 'import site' failed, use -v for trackback In-Reply-To: <1339753863.16.0.615623699476.issue15076@psf.upfronthosting.co.za> Message-ID: <1340175301.86.0.80383720735.issue15076@psf.upfronthosting.co.za> Leon Zhang <leozhang at cisco.com> added the comment: No people help me. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15076> _______________________________________ From report at bugs.python.org Wed Jun 20 08:58:12 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 20 Jun 2012 06:58:12 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <1340175492.43.0.963986314555.issue14769@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Changes incorporated from Benjamin's feedback. Thanks, Benjamin! Is this ready to go? ---------- Added file: http://bugs.python.org/file26060/larry.test_skipitem_parity.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14769> _______________________________________ From report at bugs.python.org Wed Jun 20 09:12:24 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 20 Jun 2012 07:12:24 +0000 Subject: [issue14225] _cursesmodule compile error in OS X 32-bit-only installer build In-Reply-To: <1331161185.98.0.75427514561.issue14225@psf.upfronthosting.co.za> Message-ID: <1340176344.23.0.489258985562.issue14225@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: And will you fix it for beta1, or do you think it can be done later? BTW, what is the syntax error here? I don't really see it... ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14225> _______________________________________ From report at bugs.python.org Wed Jun 20 10:57:19 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 20 Jun 2012 08:57:19 +0000 Subject: [issue15038] Optimize python Locks on Windows In-Reply-To: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za> Message-ID: <1340182639.7.0.90787199305.issue15038@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Thanks. The comments remain as the last bit of the original Condition Variable emulation code that was put in place for the new GIL. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15038> _______________________________________ From report at bugs.python.org Wed Jun 20 11:18:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 Jun 2012 09:18:14 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <E1ShH3F-00063d-2R@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 8e47e9af826e by Christian Heimes in branch 'default': Issue #15096: Drop support for the ur string prefix http://hg.python.org/cpython/rev/8e47e9af826e ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Wed Jun 20 11:24:49 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 20 Jun 2012 09:24:49 +0000 Subject: [issue15096] Drop support for the "ur" string prefix In-Reply-To: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za> Message-ID: <1340184289.13.0.162420636944.issue15096@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Thanks for you review, Serhiy. I removed the last remains from test_tokenize and even found another missing sentence in the docs. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15096> _______________________________________ From report at bugs.python.org Wed Jun 20 11:42:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 20 Jun 2012 09:42:51 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser Message-ID: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> New submission from Ezio Melotti <ezio.melotti at gmail.com>: The deprecation plan for the strict mode of HTMLParser might be as follow: 3.3 (before the beta) strict=False default strict arg deprecated in the doc strict=True deprecated (raises a warning) HTMLParseError deprecated HTMLParser.error deprecated (raises a warning) calls to HTMLParser.error removed/converted to asserts 3.4 strict arg deprecated (raises a warning) 3.5 strict arg removed and strict code removed HTMLParseError removed HTMLParser.error removed Everything that is parsed by strict=True is parsed by strict=False too, so changing the default shouldn't be a problem. The difference is that strict=False won't raise any error and will parse broken markup too. Given that no errors are raised HTMLParseError and HTMLParser.error become useless and can be deprecated (3.3) and removed (3.5) too. Once strict=False is the default (3.3), the instances should be created simply with HTMLParser(), and eventually the strict argument will be deprecated (3.4) and removed (3.5). ---------- assignee: ezio.melotti components: Library (Lib) messages: 163265 nosy: eric.araujo, ezio.melotti, georg.brandl, r.david.murray priority: release blocker severity: normal stage: needs patch status: open title: Deprecate strict mode of HTMLParser type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Wed Jun 20 12:01:34 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Jun 2012 10:01:34 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <1340186494.64.0.442710094107.issue15114@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Wed Jun 20 12:38:31 2012 From: report at bugs.python.org (Sergei Stolyarov) Date: Wed, 20 Jun 2012 10:38:31 +0000 Subject: [issue15115] Duplicated Content-Transfer-Encoding header when applying email.encoders Message-ID: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za> New submission from Sergei Stolyarov <sergei at regolit.com>: Here is the test script: -------------- from email.mime.text import MIMEText from email.mime.multipart import MIMEMultipart from email import encoders msg = MIMEMultipart() msg['Subject'] = 'Bug test' text_part = MIMEText('actual content doesnt matter') text_part.set_charset('utf-8') msg.attach(text_part) xml_part = MIMEText(b'<xml>aaa</xml>') xml_part.set_type('text/xml') xml_part.set_charset('utf-8') encoders.encode_base64(xml_part) msg.attach(xml_part) print(msg.as_string()) -------------------------- It prints the following: -------------------------- Content-Type: multipart/mixed; boundary="===============2584752675366770986==" MIME-Version: 1.0 Subject: Bug test --===============2584752675366770986== MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" actual content doesnt matter --===============2584752675366770986== Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/xml; charset="utf-8" Content-Transfer-Encoding: base64 PHhtbD5hYWE8L3htbD4= --===============2584752675366770986==-- -------------------------- And that's incorrect: the header "Content-Transfer-Encoding" set twice. As workaround you can use: del xml_part['Content-Transfer-Encoding'] ---------- components: email messages: 163266 nosy: barry, cancel, r.david.murray priority: normal severity: normal status: open title: Duplicated Content-Transfer-Encoding header when applying email.encoders versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15115> _______________________________________ From report at bugs.python.org Wed Jun 20 14:03:38 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 12:03:38 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340193818.49.0.00714185846987.issue15113@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: IDLE should try to mimic Python as much as feasible. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 14:04:03 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 12:04:03 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340193843.08.0.502797982513.issue15113@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: s/Python/Python in cmd ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 14:09:17 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 12:09:17 +0000 Subject: [issue15076] Sometimes couldn't import os, shown 'import site' failed, use -v for trackback In-Reply-To: <1339753863.16.0.615623699476.issue15076@psf.upfronthosting.co.za> Message-ID: <1340194157.64.0.182515089635.issue15076@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Well, Python is not able import the linecache module because the file is missing. Check if a file called linecache.py is there in /usr/lib/python2.6 or /usr/local/lib/python2.6 By the way, the python bug tracker doesn't have much experts. :-) ---------- nosy: +ramchandra.apte _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15076> _______________________________________ From report at bugs.python.org Wed Jun 20 14:09:50 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 20 Jun 2012 12:09:50 +0000 Subject: [issue15076] Sometimes couldn't import os, shown 'import site' failed, use -v for trackback In-Reply-To: <1339753863.16.0.615623699476.issue15076@psf.upfronthosting.co.za> Message-ID: <1340194190.08.0.437681819729.issue15076@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Try reinstalling Python and see if it works. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15076> _______________________________________ From report at bugs.python.org Wed Jun 20 14:30:54 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 12:30:54 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1340195454.56.0.608007994503.issue15112@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +bethard _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15112> _______________________________________ From report at bugs.python.org Wed Jun 20 14:33:23 2012 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 20 Jun 2012 12:33:23 +0000 Subject: [issue14803] Add feature to allow code execution prior to __main__ invocation In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1340195603.15.0.179177520816.issue14803@psf.upfronthosting.co.za> Changes by Bohuslav "Slavek" Kabrda <bkabrda at redhat.com>: ---------- nosy: +bkabrda _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14803> _______________________________________ From report at bugs.python.org Wed Jun 20 14:34:20 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 12:34:20 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340195660.5.0.944048267303.issue15113@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Well, I don't think that imitating the command line needs to extend to supporting doing unusual things to builtins, so unless someone like Terry disagrees I think we should close this as won't fix. ---------- nosy: +r.david.murray, terry.reedy resolution: -> wont fix stage: -> committed/rejected status: open -> pending type: -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 14:35:41 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 20 Jun 2012 12:35:41 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340195741.28.0.816638420561.issue15113@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: I'm afraid it's not feasible. Python (or IDLE) is allowed to rely on Python working correctly, and if commonly used functions are modified there will be unexpected errors. Likewise in 3.3, after a "del __builtins__.hasattr", even import statements will fail... ---------- nosy: +amaury.forgeotdarc status: pending -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 14:38:44 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 12:38:44 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <1340195924.89.0.447266313216.issue15114@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Your plan sounds fine to me. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Wed Jun 20 14:39:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Jun 2012 12:39:21 +0000 Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?= =?utf-8?b?dF9fIGZhaWxz?= In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za> Message-ID: <1340195961.89.0.556415562062.issue10053@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: In the test, assertNone is superfluous. Just call os.close(). However, you should probably use assertRaises to check that MyException is raised. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10053> _______________________________________ From report at bugs.python.org Wed Jun 20 15:51:20 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 13:51:20 +0000 Subject: [issue15115] Duplicated Content-Transfer-Encoding header when applying email.encoders In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za> Message-ID: <1340200280.75.0.169898607846.issue15115@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: First of all, I presume you are running this in python2.7, since it doesn't work in python3. In Python3 MIMEText takes a string as input, not a bytes object, unless you pass it a _charset parameter. If you do that, the encoding is done when the object is created, and the explicit call to encodings that you do fails. If, on the other hand, you pass in a string, the explicit call to encodings fails. In 2.7, the encoder call does not fail, but as you report this results in an extra header. This is because MIMEText sets a content type and CTE header using the default values when it is first created. The explicit call to encoders is not needed What you want to do in stead is to pass the charset and type when you make the MIMEText call: MIMEText('<xml>aaa</xml>', 'xml', 'utf-8') This is the correct way to do it, and the portable way. So, you get the right output by using the API the way it was designed. That leaves the question of whether or not we should add some documentation (such as: *never* call the functions from the encoders module directly :). Note that I don't *like* that the current API is that calling set_charset does the body encode if and only if there are no existing headers, but that is the way it has always worked, and there are programs out there that depend on it. In theory we could fix the encoders functions to check for existing headers and do the right thing in that case, but it is not something that would rate very high on my priority list. I'll happily look at a patch if someone wants to propose one, but since the right way to do this exists, I'm going to treat this issue as documentation-only. If someone wants to propose a patch for this, please open a new issue. ---------- assignee: -> docs at python components: +Documentation -email nosy: +docs at python stage: -> needs patch type: -> behavior versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15115> _______________________________________ From report at bugs.python.org Wed Jun 20 15:58:25 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 13:58:25 +0000 Subject: [issue15115] Duplicated Content-Transfer-Encoding header when applying email.encoders In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za> Message-ID: <1340200705.26.0.725933976842.issue15115@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Barry: I think we should documentationally deprecate the encoders module. I can't see any utility in a new program calling those functions explicitly, especially if the program ever wants to port to Python3. Or maybe the Python2 docs would say deprecated in Python3. What do you think? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15115> _______________________________________ From report at bugs.python.org Wed Jun 20 16:03:06 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 14:03:06 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340200986.27.0.324168552952.issue15113@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 16:05:43 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 20 Jun 2012 14:05:43 +0000 Subject: [issue15107] Potential Bug in mpdecimal.c In-Reply-To: <1340121561.65.0.31237517889.issue15107@psf.upfronthosting.co.za> Message-ID: <1340201143.53.0.888579633675.issue15107@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Mark has already said it all. -- Ken, I want to add that in the case of _decimal it's pretty easy to test any suspected misbehavior against decimal.py. This would have shown very quickly that there is no bug. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15107> _______________________________________ From report at bugs.python.org Wed Jun 20 16:12:09 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 20 Jun 2012 14:12:09 +0000 Subject: [issue15115] Duplicated Content-Transfer-Encoding header when applying email.encoders In-Reply-To: <1340200705.26.0.725933976842.issue15115@psf.upfronthosting.co.za> Message-ID: <20120620101209.73714a85@limelight.wooz.org> Barry A. Warsaw <barry at python.org> added the comment: On Jun 20, 2012, at 01:58 PM, R. David Murray wrote: >Barry: I think we should documentationally deprecate the encoders module. I >can't see any utility in a new program calling those functions explicitly, >especially if the program ever wants to port to Python3. Or maybe the >Python2 docs would say deprecated in Python3. I agree that we should document them as deprecated, as long as we include text explaining why, or providing alternatives (e.g. "you think you need this but you don't because...") I think it does make sense to include text in the Py2 docs about this. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15115> _______________________________________ From report at bugs.python.org Wed Jun 20 16:13:43 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 20 Jun 2012 14:13:43 +0000 Subject: [issue15115] Duplicated Content-Transfer-Encoding header when applying email.encoders In-Reply-To: <1340200280.75.0.169898607846.issue15115@psf.upfronthosting.co.za> Message-ID: <20120620101342.4f319a44@limelight.wooz.org> Barry A. Warsaw <barry at python.org> added the comment: On Jun 20, 2012, at 01:51 PM, R. David Murray wrote: >Note that I don't *like* that the current API is that calling set_charset >does the body encode if and only if there are no existing headers, but that >is the way it has always worked, and there are programs out there that depend >on it. Can we nuke that for email6? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15115> _______________________________________ From report at bugs.python.org Wed Jun 20 16:25:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 Jun 2012 14:25:20 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <E1ShLqP-0001no-F9@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 24369f6c4a22 by Jason R. Coombs in branch 'default': Prefer assertEqual to simply assert per recommendation in issue6727. http://hg.python.org/cpython/rev/24369f6c4a22 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6727> _______________________________________ From report at bugs.python.org Wed Jun 20 16:25:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 Jun 2012 14:25:21 +0000 Subject: [issue15093] ntpath.isdir returns False for directory symlinks In-Reply-To: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za> Message-ID: <E1ShLqP-0001no-F1@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 24369f6c4a22 by Jason R. Coombs in branch 'default': Prefer assertEqual to simply assert per recommendation in issue6727. http://hg.python.org/cpython/rev/24369f6c4a22 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15093> _______________________________________ From report at bugs.python.org Wed Jun 20 16:54:13 2012 From: report at bugs.python.org (hhas) Date: Wed, 20 Jun 2012 14:54:13 +0000 Subject: [issue15116] remove out-of-date Mac application scripting documentation Message-ID: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za> New submission from hhas <hhas at users.sourceforge.net>: 1. The entire '4.6. Application Scripting' section should be deleted from the following Python 2 & 3 pages as appscript (and PyOSA) is no longer developed or supported and its use is not recommended for new projects (http://appscript.sourceforge.net/status.html): http://docs.python.org/using/mac.html#application-scripting http://docs.python.org/release/3.2/using/mac.html#application-scripting http://docs.python.org/dev/using/mac.html#application-scripting 2. The sentence 'For more up-to-date implementation of AppleScript support for Python, see the third-party py-appscript project: <http://pypi.python.org/pypi/appscript/>' should be deleted from the following Python 2 page: http://docs.python.org/library/macosa.html ---------- assignee: docs at python components: Documentation messages: 163282 nosy: docs at python, hhas priority: normal severity: normal status: open title: remove out-of-date Mac application scripting documentation versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15116> _______________________________________ From report at bugs.python.org Wed Jun 20 16:56:16 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 20 Jun 2012 14:56:16 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340204176.76.0.775707824218.issue15102@psf.upfronthosting.co.za> Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment: Now that my buildbot is up and building (and failing at that) could these changes be committed? It would get the buildbot to at least start testing changes to Python proper. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Wed Jun 20 16:58:25 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Jun 2012 14:58:25 +0000 Subject: [issue15115] Duplicated Content-Transfer-Encoding header when applying email.encoders In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za> Message-ID: <1340204305.29.0.549659375229.issue15115@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I think so, yes. When we have the mimeregistry equivalent of the headerregistry, the new mime Message classes can have a set_charset with a different implementation. I'll want to talk about the API details on email-sig before I do anything, though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15115> _______________________________________ From report at bugs.python.org Wed Jun 20 16:58:38 2012 From: report at bugs.python.org (Stefan Krah) Date: Wed, 20 Jun 2012 14:58:38 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340204318.31.0.521528938355.issue15102@psf.upfronthosting.co.za> Changes by Stefan Krah <stefan-usenet at bytereef.org>: ---------- nosy: +brian.curtin, loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Wed Jun 20 17:21:25 2012 From: report at bugs.python.org (wchlm) Date: Wed, 20 Jun 2012 15:21:25 +0000 Subject: [issue15117] Please document top-level sqlite3 module variables Message-ID: <1340205684.94.0.46461654189.issue15117@psf.upfronthosting.co.za> New submission from wchlm <shenkin at gmail.com>: sqlite3 top-level variables, such as version, sqlite_version, version_info, and sqlite_version_info are all useful for Python users of the module -- even essential at times. Yet there is no mention of them in the Py 2.7.3 documentation. dir(sqlite3) reveals a longer list. It would be good if someone with a deeper knowledge of the module could assemble a list of useful items and add them to the sqlite3 documentation. ---------- assignee: docs at python components: Documentation messages: 163285 nosy: docs at python, shenkin priority: normal severity: normal status: open title: Please document top-level sqlite3 module variables versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15117> _______________________________________ From report at bugs.python.org Wed Jun 20 17:29:55 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 20 Jun 2012 15:29:55 +0000 Subject: [issue14973] restore python2 unicode literals in "ur" strings In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za> Message-ID: <1340206195.88.0.376075734901.issue14973@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: Given the resolution of #15096, ISTM this will be a "wontfix", though I'll stop short of marking it as such myself. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14973> _______________________________________ From report at bugs.python.org Wed Jun 20 17:30:11 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 20 Jun 2012 15:30:11 +0000 Subject: [issue14973] restore python2 unicode literals in "ur" strings In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za> Message-ID: <1340206211.59.0.573626495812.issue14973@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: Given the resolution of #15096, ISTM this will be a "wontfix", though I'll stop short of marking it as such myself. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14973> _______________________________________ From report at bugs.python.org Wed Jun 20 17:30:37 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 20 Jun 2012 15:30:37 +0000 Subject: [issue14973] restore python2 unicode literals in "ur" strings In-Reply-To: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za> Message-ID: <1340206237.99.0.574998717438.issue14973@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: ---------- Removed message: http://bugs.python.org/msg163288 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14973> _______________________________________ From report at bugs.python.org Wed Jun 20 17:36:29 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 20 Jun 2012 15:36:29 +0000 Subject: [issue14393] Incorporate Guide to Magic Methods? In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za> Message-ID: <1340206589.89.0.712184035025.issue14393@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14393> _______________________________________ From report at bugs.python.org Wed Jun 20 19:12:47 2012 From: report at bugs.python.org (Pranav Ravichandran) Date: Wed, 20 Jun 2012 17:12:47 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1340212367.93.0.596317916265.issue15056@psf.upfronthosting.co.za> Pranav Ravichandran <prp.1111 at gmail.com> added the comment: First-time contributor here, so just to make sure, let me just clarify this - the trunk builds fine, but one of the tests, test_urllib2_localnet, fails, I'm not sure why. Also, the patch is kind of messed up because of changes to Python/importlib.h. I looked this up on google, but wasn't able to find much help. Awaiting feedback :) ---------- keywords: +patch nosy: +Pranav.Ravichandran Added file: http://bugs.python.org/file26061/cachetag.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Wed Jun 20 20:36:40 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 20 Jun 2012 18:36:40 +0000 Subject: [issue15113] IDLE Shell: delattr(__builtins__, "getattr") causes shell to stop working In-Reply-To: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za> Message-ID: <1340217400.56.0.356891692301.issue15113@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: To put it another way, IDLE is written for standard Python. A standard Python interpreter has a getattr builtin that works as documented in the library manual. Deleting that or any other builtin makes the interpreter non-standard. So would replacing or wrapping the builtin with a function that does anything other than innocuously augmenting the behavior with something like counting calls or logging them to a file. Deletion of getattr *does* create problems for CPython (or any interpreter) in that legal Python code using getattr no longer runs. I presume CPython can limp along and execute other code because it directly calls the C function wrapped by the __builtins__.getattr object. ---------- resolution: wont fix -> invalid _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15113> _______________________________________ From report at bugs.python.org Wed Jun 20 21:03:33 2012 From: report at bugs.python.org (Alexey) Date: Wed, 20 Jun 2012 19:03:33 +0000 Subject: [issue13648] xml.sax.saxutils.escape does not escapes \x00 In-Reply-To: <1324565357.61.0.717954397145.issue13648@psf.upfronthosting.co.za> Message-ID: <1340219013.13.0.487005599284.issue13648@psf.upfronthosting.co.za> Alexey <animus at wayround.org> added the comment: >This is correct behavior. \x00 is not supported in XML: > not in raw form, and not in escaped form last sentence in forth paragraph of section 1.3 in XML 1.1 specification says following: ====== Due to potential problems with APIs, #x0 is still forbidden both directly and as a character reference. ====== And, second sentence in paragraph 2 in subsection 'Validity constraint: Notation Declared' of section 4.2.2 says following: ====== The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML), space #x20, the delimiters '<' #x3C, '>' #x3E and '"' #x22, the unwise characters '{' #x7B, '}' #x7D, '|' #x7C, '\' #x5C, '^' #x5E and '`' #x60, as well as all characters above #x7F. ====== (xml 1.1) http://www.w3.org/TR/2006/REC-xml11-20060816/ (xml 1.0) http://www.w3.org/TR/2008/REC-xml-20081126/ ---------- status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13648> _______________________________________ From report at bugs.python.org Wed Jun 20 21:27:39 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 20 Jun 2012 19:27:39 +0000 Subject: [issue8885] markupbase declaration errors aren't recoverable In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za> Message-ID: <1340220459.78.0.882790424292.issue8885@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- resolution: -> out of date stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8885> _______________________________________ From report at bugs.python.org Wed Jun 20 21:32:12 2012 From: report at bugs.python.org (Alexey) Date: Wed, 20 Jun 2012 19:32:12 +0000 Subject: [issue13648] xml.sax.saxutils.escape does not escapes \x00 In-Reply-To: <1324565357.61.0.717954397145.issue13648@psf.upfronthosting.co.za> Message-ID: <1340220732.73.0.543839400656.issue13648@psf.upfronthosting.co.za> Alexey <animus at wayround.org> added the comment: What am I trying to say is: if those characters are forbidden, then maybe they need to be escaped rather than ignored? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13648> _______________________________________ From report at bugs.python.org Wed Jun 20 21:42:43 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 20 Jun 2012 19:42:43 +0000 Subject: [issue15116] remove out-of-date Mac application scripting documentation In-Reply-To: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za> Message-ID: <1340221363.34.0.841061039991.issue15116@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: The entire "Using Macintosh" section of the documentation set is in need of an update. I plan to have that done for 3.3 release and the next releases of 3.2.x and 2.7.x. The 2.6 and 3.1 releases are in security fix mode only, prior to their retirement, and no longer receive doc or bug fix updates. ---------- assignee: docs at python -> ned.deily nosy: +ned.deily versions: -Python 2.6, Python 3.1, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15116> _______________________________________ From report at bugs.python.org Wed Jun 20 21:56:12 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 20 Jun 2012 19:56:12 +0000 Subject: [issue13648] xml.sax.saxutils.escape does not escapes \x00 In-Reply-To: <1324565357.61.0.717954397145.issue13648@psf.upfronthosting.co.za> Message-ID: <1340222172.59.0.778211762715.issue13648@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: The characters are forbidden both in raw form *and* in escaped form. So even if they get escaped, they *still* will lead to errors. So there is no point in escaping them. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13648> _______________________________________ From report at bugs.python.org Wed Jun 20 22:12:41 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 20 Jun 2012 20:12:41 +0000 Subject: [issue15118] uname &c should return a struct sequence instead of a tuple Message-ID: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> New submission from Larry Hastings <larry at hastings.org>: The trend in the standard library is to get rid of awkward Python-1-style tuple return values and switch to struct sequences. (And perhaps, in the fullness of time, to deprecate the iterability of such objects. But that's for the future.) os.stat is a good example; it's much better to say s = os.stat() then refer to s.st_mtime than s[5] (or whatever the offset is). And doing destructuring assignment... ptui! I just noticed that the following functions in Modules/posixmodule.c still use BuildValue to build raw tuples: _getdiskusage _getfileinformation forkpty getloadavg getresgid getresuid openpty os2_error (can't get excited about this one) pipe, pipe2 times uname wait, waitpid wait3, wait4 (but one of the values is a struct sequence) I think it'd be worthwhile to change all of these to struct sequences, sooner or later. I realize we're almost out of time for 3.3, but perhaps we could hit the important ones (uname! times!) and get to the rest for 3.4? ---------- messages: 163295 nosy: larry priority: normal severity: normal status: open title: uname &c should return a struct sequence instead of a tuple _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Wed Jun 20 22:16:27 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 20 Jun 2012 20:16:27 +0000 Subject: [issue15118] uname &c should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340223387.41.0.73877679354.issue15118@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Wed Jun 20 23:19:08 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 20 Jun 2012 21:19:08 +0000 Subject: [issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime In-Reply-To: <1335213212.56.0.724242644314.issue14653@psf.upfronthosting.co.za> Message-ID: <1340227148.75.0.146220585126.issue14653@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: > That said, this might be a worthwhile as a bug fix. I think this is a reasonable bug fix. Note that apart from OS-dependent date range, some mktime implementations reportedly don't support tm_isdst values other than -1. ---------- assignee: -> belopolsky stage: -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14653> _______________________________________ From report at bugs.python.org Wed Jun 20 23:41:41 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 20 Jun 2012 21:41:41 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1340228501.73.0.00563143098275.issue9527@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Attached patch implements astimezone() default in both Python and C. ---------- stage: -> patch review Added file: http://bugs.python.org/file26062/issue9527.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Thu Jun 21 02:20:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Jun 2012 00:20:56 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <E1ShV8g-0006lP-CC@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset dd4f7d5c51c7 by Nadeem Vawda in branch 'default': Issue #14684: Add support for predefined compression dictionaries to the zlib module. http://hg.python.org/cpython/rev/dd4f7d5c51c7 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Thu Jun 21 02:24:30 2012 From: report at bugs.python.org (Leon Zhang) Date: Thu, 21 Jun 2012 00:24:30 +0000 Subject: [issue15076] Sometimes couldn't import os, shown 'import site' failed, use -v for trackback In-Reply-To: <1339753863.16.0.615623699476.issue15076@psf.upfronthosting.co.za> Message-ID: <1340238270.59.0.921615479565.issue15076@psf.upfronthosting.co.za> Leon Zhang <leozhang at cisco.com> added the comment: Thank ramchandra.apte for the help. I checked linecache.py, and the file exists. Unfortunately I don't have root perssion to re-install Python. I also checked another bug "http://bugs.python.org/issue10496", I think that may be the truth. Finally I found another workaround, that is to run my Python from shell. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15076> _______________________________________ From report at bugs.python.org Thu Jun 21 02:27:02 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Thu, 21 Jun 2012 00:27:02 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1340238422.31.0.0581356036056.issue14684@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: Committed. Once again, thanks for the patch! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Thu Jun 21 02:29:47 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 21 Jun 2012 00:29:47 +0000 Subject: [issue15118] uname &c should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340238587.34.0.257160560282.issue15118@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: +1. ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Thu Jun 21 05:09:06 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 21 Jun 2012 03:09:06 +0000 Subject: [issue13463] Fix parsing of package_data In-Reply-To: <1322068433.36.0.783240091616.issue13463@psf.upfronthosting.co.za> Message-ID: <1340248146.51.0.514662052315.issue13463@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13463> _______________________________________ From report at bugs.python.org Thu Jun 21 05:10:19 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 21 Jun 2012 03:10:19 +0000 Subject: [issue12779] Update packaging documentation In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za> Message-ID: <1340248219.13.0.13206838974.issue12779@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12779> _______________________________________ From report at bugs.python.org Thu Jun 21 05:10:51 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 21 Jun 2012 03:10:51 +0000 Subject: [issue14790] use packaging in setup.py In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za> Message-ID: <1340248251.52.0.0205627809539.issue14790@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14790> _______________________________________ From report at bugs.python.org Thu Jun 21 05:11:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 21 Jun 2012 03:11:00 +0000 Subject: [issue5302] Allow package_data specs/globs to match directories In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za> Message-ID: <1340248260.32.0.983519909388.issue5302@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5302> _______________________________________ From report at bugs.python.org Thu Jun 21 05:24:03 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 21 Jun 2012 03:24:03 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340249043.16.0.329904944513.issue15118@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: os._getdiskusage is an internal helper for shutil.getdiskusage on Windows, which does return a named tuple. The private C function can continue returning a tuple IMO. +1 on changing uname for 3.3! No opinion on times; I don?t use it and don?t understand the member names anyway :) ---------- nosy: +eric.araujo title: uname &c should return a struct sequence instead of a tuple -> uname and other os functions should return a struct sequence instead of a tuple versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Thu Jun 21 06:07:52 2012 From: report at bugs.python.org (John Regehr) Date: Thu, 21 Jun 2012 04:07:52 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1340251672.73.0.669036298693.issue9530@psf.upfronthosting.co.za> John Regehr <regehr at cs.utah.edu> added the comment: I the tests for today's cpython using IOC and got only the issues below. The on-purpose divide by zero should be OK but the shift by -2 probably wants to be fixed. ARITHMETIC UNDEFINED at </home/regehr/tmp/cpython/Modules/_ctypes/cfield.c, (589:5)> : Op: <<=, Reason : Signed Left Shift: Right operand is negative or is greater than or equal to the width of the promoted left operand, BINARY OPERATION: left (int32): 0 right (int32): -2 ARITHMETIC UNDEFINED at <./Modules/faulthandler.c, (844:11)> : Op: /, Reason : Signed Division: Divisor is 0 || divident is INT_MIN, divisor is -1, BINARY OPERATION: left (int32): 1 right (int32): 0 version info: regehr at home:~/tmp/cpython$ ./python Python 3.3.0a4+ (default:24369f6c4a22+, Jun 20 2012, 16:41:04) [GCC 4.2.1 Compatible Clang 3.1 ((branches/release_31))] on linux Type "help", "copyright", "credits" or "license" for more information. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9530> _______________________________________ From report at bugs.python.org Thu Jun 21 07:41:31 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Jun 2012 05:41:31 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340257291.49.0.659575815684.issue15118@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Agree for changing times() and uname(). But functions that return a 2- or 3-element tuple, which immediately will be unpacked, no need to change. Keep it simple. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Thu Jun 21 08:48:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Jun 2012 06:48:41 +0000 Subject: [issue12567] curses implementation of Unicode is wrong in Python 3 In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za> Message-ID: <E1ShbC2-0001dq-Pp@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2035c5ad4239 by Ned Deily in branch 'default': Issue #14225: Fix Unicode support for curses (#12567) on OS X: http://hg.python.org/cpython/rev/2035c5ad4239 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12567> _______________________________________ From report at bugs.python.org Thu Jun 21 08:48:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Jun 2012 06:48:41 +0000 Subject: [issue14225] _cursesmodule compile error in OS X 32-bit-only installer build In-Reply-To: <1331161185.98.0.75427514561.issue14225@psf.upfronthosting.co.za> Message-ID: <E1ShbC2-0001dq-PW@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2035c5ad4239 by Ned Deily in branch 'default': Issue #14225: Fix Unicode support for curses (#12567) on OS X: http://hg.python.org/cpython/rev/2035c5ad4239 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14225> _______________________________________ From report at bugs.python.org Thu Jun 21 09:06:32 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Jun 2012 07:06:32 +0000 Subject: [issue14225] _cursesmodule compile error in OS X 32-bit-only installer build In-Reply-To: <1331161185.98.0.75427514561.issue14225@psf.upfronthosting.co.za> Message-ID: <1340262392.86.0.272514942556.issue14225@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: It turns out that the Unicode support for curses did not build correctly on OS X at all. There were two issues: 1. On OS X, unlike many systems, does not supply separate libncurses and libncursesw in /usr/lib; same for libpanel/libpanelw. So the tests in setup.py based on the presence of the "w" libs failed, thus disabling the wide-char support in the extension modules even though the OS X libs supported it. The tests in setup.py are now fixed to handle building on OS X with either the system libs or locally-supplied copies. 2. The 32-bit-only installer has historically built and supplied its own copy of libncursesw so that installer build did find a wide lib. However, the wide code support within ncurses is conditional depending on _XOPEN_SOURCE_EXTENDED which is specifically not defined for OS X (platform=='darwin') builds. That caused the compile errors (things like cchar_t from the ncurses include files were not getting defined). The solution for that is to supply _XOPEN_SOURCE_EXTENDED locally to the _curses* extension module builds. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14225> _______________________________________ From report at bugs.python.org Thu Jun 21 09:10:53 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Jun 2012 07:10:53 +0000 Subject: [issue12567] curses implementation of Unicode is wrong in Python 3 In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za> Message-ID: <1340262653.24.0.27911553608.issue12567@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: It turns out that the Unicode support introduced by this issue didn't build correctly on OS X, either silently failing to build (explaining the problem seen by Nicholas) or causing a compile error (as seen in Issue14225). This should be working OK (as of 3.3.0b1). BTW, a test of the wide char functions would be nice and might have caught this. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12567> _______________________________________ From report at bugs.python.org Thu Jun 21 10:01:07 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 21 Jun 2012 08:01:07 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1340265667.65.0.908510826833.issue9530@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Thanks. It looks like that <<= report has uncovered a bug in the way that ctypes lays out bitfields: in the following, BITS.M should (I believe) look like: <Field type=c_short, ofs=4:0, bits=1>. Instead, ctypes is trying to store a bitfield starting at bit position 17 of a short, which doesn't make much sense. iwasawa:cpython mdickinson$ ./python.exe Python 3.3.0a4+ (default:2035c5ad4239+, Jun 21 2012, 08:30:36) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import Structure, c_int, c_short >>> class BITS(Structure): ... _fields_ = [("A", c_int, 17), ("M", c_short, 1)] ... >>> BITS.M <Field type=c_short, ofs=2:17, bits=1> ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9530> _______________________________________ From report at bugs.python.org Thu Jun 21 10:13:37 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 21 Jun 2012 08:13:37 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1340266417.55.0.520828604143.issue9530@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Meador: I see that you've been working on some ctypes issues; does the ctypes bitfield problem above fall under any of the existing issues, or should I open a new one? ---------- nosy: +meador.inge _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9530> _______________________________________ From report at bugs.python.org Thu Jun 21 10:23:45 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 21 Jun 2012 08:23:45 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1340267025.97.0.959382163663.issue9530@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Issue3547 looks similar. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9530> _______________________________________ From report at bugs.python.org Thu Jun 21 10:24:00 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 21 Jun 2012 08:24:00 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1340267040.79.0.117469379082.issue14626@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: New patch! What's new: * The big change: I removed the "fd=" parameters. Now, functions that accept either a path or a file descriptor simply take either as their "path" argument. I ran it by Guido and he thought it sounded fine, so I tried it--and I think it's a definite improvement. (Thanks to Jim Jewett for suggesting it--tbh I'd considered it before, but looking at it through fresh eyes helped!) * Also new in this patch: you can now LBYL for the fd, dir_fd, and follow_symlinks parameters. Just check to see if the function is in os.supports_<name of parameter>. For example: if os.chown in os.supports_dir_fd: os.chown(path, dir_fd=whatnot) * The third big bit of news: the patch works under Windows! * I attempted to support Mac OS X 10.3, specifically the weak linking to statvfs, fstatvfs, and lchown. However I don't have a Mac (much less one running 10.3) so I can't test this. I *think* the docstrings are all fixed. The only thing I know that needs to be done are the docs (and Misc/NEWS). I really wanna get this in before the feature freeze. I promise to support it through the betas... can I puh-leez check it in? ---------- Added file: http://bugs.python.org/file26063/larry.os.keyword.arguments.collapse.4.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Thu Jun 21 10:47:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Jun 2012 08:47:14 +0000 Subject: [issue14225] _cursesmodule compile error in OS X 32-bit-only installer build In-Reply-To: <1331161185.98.0.75427514561.issue14225@psf.upfronthosting.co.za> Message-ID: <1340268434.92.0.622281515027.issue14225@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: Cool, thanks for the fix! ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14225> _______________________________________ From report at bugs.python.org Thu Jun 21 11:08:08 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 21 Jun 2012 09:08:08 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <1340269688.75.0.414328604331.issue14769@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Incorporates Benjamin's self-admitted pedantic changes ;-) Will it survive? Will it get checked in? Tune in... soon, I hope! ---------- Added file: http://bugs.python.org/file26064/larry.test_skipitem_parity.4.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14769> _______________________________________ From report at bugs.python.org Thu Jun 21 11:13:35 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 21 Jun 2012 09:13:35 +0000 Subject: [issue15119] Bug in ctypes bitfield layout? Message-ID: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za> New submission from Mark Dickinson <dickinsm at gmail.com>: It looks as though there's a bug in the ctypes bitfield layout algorithm. After: >>> from ctypes import Structure, c_int, c_short >>> class BITS(Structure): ... _fields_ = [("A", c_int, 17), ("M", c_short, 1)] ... I get: >>> BITS.M <Field type=c_short, ofs=2:17, bits=1> which doesn't make a lot of sense (17th bit of a short?) This causes a negative shift operation when trying to access the .M field of an instance of this structure (see issue 9530 and in particular msg163303). On this machine (OS X 10.6, 64-bit build of Python using the system gcc (4.2) with no special compiler flags), the corresponding struct in a simple C test program has size 4: #include <stdio.h> struct { int A : 17; short B: 1; } flags; int main(void) { printf("sizeof flags is: %ld\n", sizeof(flags)); return 0; } So it looks like everything gets packed into that first int. At a guess, BITS.M should therefore look like <Field type=c_int, ofs=0:17, bits=1> instead. System info: Python 3.3.0a4+ (default:2035c5ad4239+, Jun 21 2012, 08:30:36) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------- components: ctypes messages: 163315 nosy: mark.dickinson, meador.inge priority: normal severity: normal status: open title: Bug in ctypes bitfield layout? type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15119> _______________________________________ From report at bugs.python.org Thu Jun 21 11:14:46 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 21 Jun 2012 09:14:46 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1340270086.97.0.818231506265.issue9530@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Thanks, Amaury. I see a whole bunch of related issues, but none of them quite seems to capture this exact issue. So I've opened a new bug report: see issue 15119. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9530> _______________________________________ From report at bugs.python.org Thu Jun 21 11:52:05 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 21 Jun 2012 09:52:05 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340272325.63.0.583889697293.issue15118@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Patch implementing struct sequences for os.uname() and os.times(). Those two are a slam dunk, so let's try and get 'em into 3.3. Patch includes docs! Maybe it's ready! Who knows! ---------- keywords: +patch Added file: http://bugs.python.org/file26065/larry.uname.and.times.structseq.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Thu Jun 21 12:00:39 2012 From: report at bugs.python.org (hansokumake) Date: Thu, 21 Jun 2012 10:00:39 +0000 Subject: [issue15120] Different behavior of html.parser.HTMLParser Message-ID: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za> New submission from hansokumake <hansokumake at seznam.cz>: I tried this example from the documentation: from html.parser import HTMLParser class MyHTMLParser(HTMLParser): def handle_starttag(self, tag, attrs): print("Encountered a start tag:", tag) def handle_endtag(self, tag): print("Encountered an end tag :", tag) def handle_data(self, data): print("Encountered some data :", data) parser = MyHTMLParser(strict=False) parser.feed('<html><head><title>Test' '

Parse me!

') According to documentation the output should be like this: Encountered a start tag: html Encountered a start tag: head Encountered a start tag: title Encountered some data : Test Encountered an end tag : title Encountered an end tag : head Encountered a start tag: body Encountered a start tag: h1 Encountered some data : Parse me! Encountered an end tag : h1 Encountered an end tag : body Encountered an end tag : html but Python produced this: Encountered some data : Encountered some data : Encountered some data : Encountered some data : Test Encountered an end tag : title Encountered an end tag : head Encountered some data : <body> Encountered some data : <h1> Encountered some data : Parse me! Encountered an end tag : h1 Encountered an end tag : body Encountered an end tag : html If strict is set to True, it works correctly. ---------- assignee: docs at python components: Documentation messages: 163318 nosy: docs at python, hansokumake priority: normal severity: normal status: open title: Different behavior of html.parser.HTMLParser type: behavior versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15120> _______________________________________ From report at bugs.python.org Thu Jun 21 12:17:35 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 21 Jun 2012 10:17:35 +0000 Subject: [issue15119] Bug in ctypes bitfield layout? In-Reply-To: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za> Message-ID: <1340273855.74.0.921219019929.issue15119@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > At a guess, BITS.M should therefore look like <Field type=c_int, > ofs=0:17, bits=1> instead. Refined guess: it should be <Field type=c_short, ofs=2:1, bits=1>. Tests for this issue should also cover cases like: _fields_ = [("A", c_int, 13), ("M", c_short, 5)] where M should end up being described as <Field type=c_short, ofs=2:0, bits=5>. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15119> _______________________________________ From report at bugs.python.org Thu Jun 21 12:24:00 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jun 2012 10:24:00 +0000 Subject: [issue15120] Different behavior of html.parser.HTMLParser In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za> Message-ID: <1340274240.66.0.344029977647.issue15120@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15120> _______________________________________ From report at bugs.python.org Thu Jun 21 12:33:20 2012 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 21 Jun 2012 10:33:20 +0000 Subject: [issue15120] Different behavior of html.parser.HTMLParser In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za> Message-ID: <1340274800.28.0.860421598628.issue15120@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. <fred at fdrake.net>: ---------- nosy: +fdrake _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15120> _______________________________________ From report at bugs.python.org Thu Jun 21 12:34:30 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Jun 2012 10:34:30 +0000 Subject: [issue15037] test_curses fails with OverflowError In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1340274870.06.0.520721330963.issue15037@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: I just ran into this problem on another platform. I believe the problem is due to a sign-extension bug in the ncurses library unget_wch function (see link below). It was apparently fixed in nurses 5.8; I've tested with the current ncurses 5.9 and test_ncurses now runs without error. Are you using a version of libncurses/libncursew older than 5.8? If so, can you try building with 5.8 or 5.9? Another question is how to handle this for the 3.3.0 release. It looks like not all platforms have the latest ncurses and, if not, the unget_wch function and test_curses are likely to fail. Unfortunately, there doesn't seem to be an attribute available in the curses module that gives the version of the underlying curses/ncurses library. At the least, the problem should probably be documented somewhere. http://invisible-island.net/ncurses/NEWS.html#t20091010 ---------- nosy: +georg.brandl, haypo, ned.deily priority: normal -> high _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15037> _______________________________________ From report at bugs.python.org Thu Jun 21 12:37:22 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 10:37:22 +0000 Subject: [issue15121] devguide doesn't document all bug tracker components Message-ID: <1340275042.61.0.991678411408.issue15121@psf.upfronthosting.co.za> New submission from Petri Lehtinen <petri at digip.org>: http://docs.python.org/devguide/triaging.html#components The undocumented components are: - None - Cross-Build - email ---------- components: Devguide messages: 163321 nosy: ezio.melotti, petri.lehtinen priority: normal severity: normal status: open title: devguide doesn't document all bug tracker components _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15121> _______________________________________ From report at bugs.python.org Thu Jun 21 12:45:51 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 10:45:51 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. Message-ID: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> New submission from Petri Lehtinen <petri at digip.org>: This seems like a common feature request. Many people suffer from the fact that upon flush, the contents of single-file mailboxes are written into a new file which is then renamed over the old file. For example: #1599254, #5346, #7359, #7360, #9559, The original design rationale was probably to prepare for crashes. When changes are made like this, a power loss, other sytem crash, or even a bug in the mailbox.py code in the middle of writing the mailbox, cannot destroy all the data in the mailbox file. We could add a flag to the constructors of all single-file mailboxes that changes this behavior to in-place rewriting. This would of course need accompanying documentation that warns about that the same safety guarantees don't apply with this flag. ---------- messages: 163322 nosy: petri.lehtinen priority: normal severity: normal status: open title: Add an option to always rewrite single-file mailboxes in-place. type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15122> _______________________________________ From report at bugs.python.org Thu Jun 21 12:46:16 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 10:46:16 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1340275576.99.0.474234699843.issue15122@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: ---------- components: +email nosy: +barry, r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15122> _______________________________________ From report at bugs.python.org Thu Jun 21 12:52:14 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Jun 2012 10:52:14 +0000 Subject: [issue14225] _cursesmodule compile error in OS X 32-bit-only installer build In-Reply-To: <1331161185.98.0.75427514561.issue14225@psf.upfronthosting.co.za> Message-ID: <1340275934.14.0.386035018356.issue14225@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: P.S. All is not perfect. I initially missed re-running test_curses with the system ncurses library on OS X where ncurses is at 5.4 or with the 32-bit-installer which builds ncurses 5.5. When I did, test_curses failed as described in Issue15037. test_curses passes when Python is built with a MacPorts ncurses 5.9. The best solution would be to update the installer builds to build and use the latest ncurses 5.9. That may have to wait until after 3.3.0b1. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14225> _______________________________________ From report at bugs.python.org Thu Jun 21 12:52:19 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 10:52:19 +0000 Subject: [issue13698] Mailbox module should support other mbox formats in addition to mboxo In-Reply-To: <1325540787.88.0.149207146949.issue13698@psf.upfronthosting.co.za> Message-ID: <1340275939.93.0.183400906722.issue13698@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: ---------- nosy: +petri.lehtinen versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13698> _______________________________________ From report at bugs.python.org Thu Jun 21 13:00:14 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jun 2012 11:00:14 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1340276414.86.0.0880995102815.issue15122@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: It would be nice to do some research on what MUAs that support mbox format do here. (eg: mutt, pine if it still exists, etc). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15122> _______________________________________ From report at bugs.python.org Thu Jun 21 13:14:52 2012 From: report at bugs.python.org (=?utf-8?q?Lu=C3=ADs_Gomes?=) Date: Thu, 21 Jun 2012 11:14:52 +0000 Subject: [issue15123] float().__format__() disregards given field width Message-ID: <1340277292.24.0.000274542917798.issue15123@psf.upfronthosting.co.za> Changes by Lu?s Gomes <luismsgomes at gmail.com>: ---------- nosy: luismsgomes priority: normal severity: normal status: open title: float().__format__() disregards given field width versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15123> _______________________________________ From report at bugs.python.org Thu Jun 21 13:17:31 2012 From: report at bugs.python.org (=?utf-8?q?Lu=C3=ADs_Gomes?=) Date: Thu, 21 Jun 2012 11:17:31 +0000 Subject: [issue15123] float().__format__() disregards given field width Message-ID: <1340277451.36.0.503595859178.issue15123@psf.upfronthosting.co.za> New submission from Lu?s Gomes <luismsgomes at gmail.com>: Python 3.2.3 (default, May 3 2012, 15:51:42) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 1.2.__format__('2.2') '1.2' I expected: ' 1.2' ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15123> _______________________________________ From report at bugs.python.org Thu Jun 21 13:19:49 2012 From: report at bugs.python.org (=?utf-8?q?Lu=C3=ADs_Gomes?=) Date: Thu, 21 Jun 2012 11:19:49 +0000 Subject: [issue15123] float().__format__() disregards given field width In-Reply-To: <1340277451.36.0.503595859178.issue15123@psf.upfronthosting.co.za> Message-ID: <1340277589.62.0.814699886601.issue15123@psf.upfronthosting.co.za> Changes by Lu?s Gomes <luismsgomes at gmail.com>: ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15123> _______________________________________ From report at bugs.python.org Thu Jun 21 13:29:43 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 11:29:43 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1340278183.86.0.633649000391.issue15122@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: I actually already researched mutt 1.5.21 (on Ubuntu), and it seems to overwrite the file in-place. At least the inode number doesn't change when I append and/or delete files from an mbox file and save it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15122> _______________________________________ From report at bugs.python.org Thu Jun 21 13:39:36 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 11:39:36 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1340278776.35.0.640519624612.issue15122@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Now I also tested rmail (the Emacs email client). It seems to write-and-rename, at least the inode number changes. It seems to even use the mboxo format nowadays (used to use Babyl). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15122> _______________________________________ From report at bugs.python.org Thu Jun 21 13:46:34 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 11:46:34 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1340279194.46.0.000249303063247.issue15122@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Alpine (the successor of pine) also seems to overwrite in-place, just like mutt. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15122> _______________________________________ From report at bugs.python.org Thu Jun 21 14:14:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 21 Jun 2012 12:14:51 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340280891.22.0.2821893881.issue15061@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Shall explore option 2b) "optionally create a C implementation as it's much easier to check C code for timing issues" Definitely. I'm not sure whether that can go in 3.3 post-beta, though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 21 15:02:34 2012 From: report at bugs.python.org (John Bollinger) Date: Thu, 21 Jun 2012 13:02:34 +0000 Subject: [issue15037] test_curses fails with OverflowError In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1340283754.49.0.337849040791.issue15037@psf.upfronthosting.co.za> John Bollinger <John.Bollinger at stJude.org> added the comment: The system on which I encountered the test failure uses ncurses 5.7, so that's consistent with the theory that the test is tickling an ncurses bug. I'll have a look at testing with ncurses 5.8, but it is not available from RedHat or CentOS (and it never will be for the current and past versions of those systems), so that's not a good solution for most users. On the other hand, it's not clear to me how serious is the bug revealed by the test failures, nor whether there is any viable workaround on the Python side. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15037> _______________________________________ From report at bugs.python.org Thu Jun 21 15:41:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 21 Jun 2012 13:41:21 +0000 Subject: [issue15120] Different behavior of html.parser.HTMLParser In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za> Message-ID: <1340286081.77.0.663307189062.issue15120@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: What exact version of python have you used? The example works here with 3.2.3+. ---------- assignee: docs at python -> ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15120> _______________________________________ From report at bugs.python.org Thu Jun 21 16:01:42 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 21 Jun 2012 14:01:42 +0000 Subject: [issue15121] devguide doesn't document all bug tracker components In-Reply-To: <1340275042.61.0.991678411408.issue15121@psf.upfronthosting.co.za> Message-ID: <1340287302.9.0.224927439428.issue15121@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: I wonder why "None" exists, given that there's already "no selection" (maybe to distinguish issues that have been triaged already from the ones who haven't?). "email" refers to issue related to the email package, and I'm not sure what exactly classify as cross-build issues. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15121> _______________________________________ From report at bugs.python.org Thu Jun 21 16:03:10 2012 From: report at bugs.python.org (Maciej Fijalkowski) Date: Thu, 21 Jun 2012 14:03:10 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340287390.17.0.94060509994.issue15061@psf.upfronthosting.co.za> Maciej Fijalkowski <fijall at gmail.com> added the comment: Hi. This is what we did with Armin: http://bpaste.net/show/32123/ It seems there is still *some* information leaking via side-channels, although it's a bit unclear what. Feel free to play with it (try swapping, having different object etc.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 21 16:11:39 2012 From: report at bugs.python.org (John Bollinger) Date: Thu, 21 Jun 2012 14:11:39 +0000 Subject: [issue15037] test_curses fails with OverflowError In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1340287899.07.0.0987050320476.issue15037@psf.upfronthosting.co.za> John Bollinger <John.Bollinger at stJude.org> added the comment: Clarification: "so that's not a good solution for most users" ... of RedHat-family distros, version 6.2 and earlier. In fact, it looks like RedHat is sticking with its current version of ncurses for RHEL 6.3, too, so no help is coming from that direction any time soon. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15037> _______________________________________ From report at bugs.python.org Thu Jun 21 16:11:40 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 21 Jun 2012 14:11:40 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. Message-ID: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>: _thread.LockType contains code for sanity checking when the lock is released, and for unlocking it when it is deleted. Both operations involve actually try-lock operations that are costly. Use a flag on the log to keep track of its locking state instead. Also, acquiring a lock now first tries a try-aqcuire without releasing the GIL, same as _thread.RLock(). This is done by moving logic from RLock.acquire to acquire_timed() so that both locks benefit. Improvement, on a 64 bit windows machine: Before: D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock" "allocate_lock()" 1000000 loops, best of 3: 0.725 usec per loop D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l.release()" 1000000 loops, best of 3: 0.315 usec per loop After: D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock" "allocate_lock()" 1000000 loops, best of 3: 0.691 usec per loop D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l.release()" 1000000 loops, best of 3: 0.294 usec per loop This amounts to 5% and 7% improvement, respectively. ---------- files: lock.patch keywords: patch messages: 163335 nosy: kristjan.jonsson priority: normal severity: normal status: open title: _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. Added file: http://bugs.python.org/file26066/lock.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Thu Jun 21 16:12:01 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 21 Jun 2012 14:12:01 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340287921.48.0.465273518553.issue15124@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>: ---------- components: +Interpreter Core type: -> performance versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Thu Jun 21 16:30:57 2012 From: report at bugs.python.org (John Bollinger) Date: Thu, 21 Jun 2012 14:30:57 +0000 Subject: [issue15037] test_curses fails with OverflowError In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1340289057.47.0.00494656698031.issue15037@psf.upfronthosting.co.za> John Bollinger <John.Bollinger at stJude.org> added the comment: Ok, I confirm that the test passes after the system's ncurses library is upgraded to ncurses 5.8, and fails again when ncurses is downgraded back to version 5.7. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15037> _______________________________________ From report at bugs.python.org Thu Jun 21 16:50:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 21 Jun 2012 14:50:16 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <1340290216.51.0.465139155179.issue15114@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: The attached patch include these changes: * strict=False default * strict arg deprecated in the doc * strict=True deprecated (raises a warning) * HTMLParseError deprecated in the doc * some calls to HTMLParser.error converted to asserts [0] Regarding * HTMLParser.error deprecated (raises a warning) I'm not sure anymore that's a good idea. The method is not documented, so in theory it could be removed without deprecation warnings, but that might break things if someone is using it. [0] I made a mistake in my first message: some of the calls should actually be converted to assert, the others will stay as long as the strict mode exists (i.e. they will be removed in 3.5) ---------- keywords: +patch Added file: http://bugs.python.org/file26067/issue15114.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Thu Jun 21 16:59:05 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 21 Jun 2012 14:59:05 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <4FDEDE91.9050301@v.loewis.de> Message-ID: <4A5B9825-B557-4DF0-B458-CEE13F4583A5@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: I'll try to get it in before beta1 then. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 21 17:24:40 2012 From: report at bugs.python.org (Jim Jewett) Date: Thu, 21 Jun 2012 15:24:40 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1340292280.86.0.0366771541179.issue14684@psf.upfronthosting.co.za> Jim Jewett <jimjjewett at gmail.com> added the comment: Just saw this on the checkins list; where are the other options documented? """ PyDoc_STRVAR(compressobj__doc__, -"compressobj([level]) -- Return a compressor object.\n" +"compressobj([level[, method[, wbits[, memlevel[, strategy[, zdict]]]]]])\n" +" -- Return a compressor object.\n" "\n" -"Optional arg level is the compression level, in 1-9."); +"Optional arg level is the compression level, in 1-9.\n" +"\n" +"Optional arg zdict is the predefined compression dictionary - a sequence of\n" +"bytes containing subsequences that are likely to occur in the input data."); """ I'm honestly not certain what they should be, but the following is my best guess: """ PyDoc_STRVAR(compressobj__doc__, "compressobj([level[, method[, wbits[, memlevel[, strategy[, zdict]]]]]])\n" " -- Return a compressor object.\n" "\n" -"Optional arg level is the compression level, in 1-9.\n" +"Optional arg level (1-9) is the compression level.\n" +"Larger numbers take longer, but produce smaller results.\n" "\n" +"Optional arg method is the compression method.\n" +"The only currently supported method is zlib.DEFLATED.\n" +"\n" +"Optional arg wbits determines the window buffer size.\n" +"Normal values are 8 (least memory) to 15 (best compression).\n" +"\n" +"Optional arg memlevel (1-9) controls working memory size.\n" +"Larger numbers use more memory, but produce smaller results more quickly.\n" +"\n" +"Optional arg strategy tunes the compression algorithm.\n" +"Supported options include zlib.Z_DEFAULT_STRATEGY, zlib.Z_FILTERED, and zlib.Z_HUFFMAN_ONLY.\n" +"\n" +"Optional arg zdict is the predefined compression dictionary - a sequence of\n" +"bytes containing subsequences that are likely to occur in the input data."); """ ---------- nosy: +Jim.Jewett _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Thu Jun 21 17:34:07 2012 From: report at bugs.python.org (Nicu Stiurca) Date: Thu, 21 Jun 2012 15:34:07 +0000 Subject: [issue15125] argparse: positional arguments containing - in name not handled well Message-ID: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za> New submission from Nicu Stiurca <supernic2002 at gmail.com>: To reproduce, try the following code: from argparse import ArgumentParser a = ArgumentParser() a.add_argument("foo-bar") args = a.parse_args(["biz"]) print args, args.foo_bar Expected output: Namespace(foo_bar='biz') biz Actual output: Namespace(foo-bar='biz') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Namespace' object has no attribute 'foo_bar' Other comments: The positional argument 'foo-bar' becomes impossible to retrieve without explicitly passing keyword argument dest='foo_bar'. Hyphens in positional arguments should be automatically replaced with underscores just as with other arguments. I have not tested if this problem occurs in Python versions newer than 2.6. ---------- messages: 163340 nosy: nstiurca priority: normal severity: normal status: open title: argparse: positional arguments containing - in name not handled well type: behavior versions: Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15125> _______________________________________ From report at bugs.python.org Thu Jun 21 17:36:21 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Thu, 21 Jun 2012 15:36:21 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1340292981.39.0.0692388130924.issue14684@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: > Just saw this on the checkins list; where are the other options documented? They aren't, AFAIK. I've been planning on adding them when I've got time (based on the zlib manual at http://zlib.net/manual.html), but with the upcoming feature freeze for 3.3, this issue was higher priority. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Thu Jun 21 17:37:17 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Jun 2012 15:37:17 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1340293037.83.0.0468986327216.issue15122@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Any chance you'd be willing to look in the source code and see if they do any locking mailbox doesn't? The evidence you've already gathered is probably enough to justify adding the option, though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15122> _______________________________________ From report at bugs.python.org Thu Jun 21 18:24:39 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 21 Jun 2012 16:24:39 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340295879.65.0.78638872331.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: I've attached a header for that implements a single C function timingsafe_eq(a, b). The file is targeted for Objects/stringlib/timingsafe.h. Please review the file. Comments -------- - I only handle exact byte or unicode types (no subclasses) since a user may have overwritten __eq__ and I don't want to special case it. - The unicode path works only with compact ASCII strings. I'm not familiar with the new API so please scream if I did it wrong. - length difference is currently optimized, length 0 isn't. I could easily un-optimize the len(a) != len(b) case or optimize the len(a) == len(b) == 0 case. Open questions -------------- Where should I place the function? hashlib would be a nice place but there are multiple backends for hashlib. _hashopenssl.c seems wrong. ---------- Added file: http://bugs.python.org/file26068/timingsafe.h _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 21 18:27:52 2012 From: report at bugs.python.org (Damian) Date: Thu, 21 Jun 2012 16:27:52 +0000 Subject: [issue15126] Theading isAlive() missing version note Message-ID: <1340296072.22.0.188221984901.issue15126@psf.upfronthosting.co.za> New submission from Damian <atagar1 at gmail.com>: The threading module's isAlive() method had an is_alive() alias first created in python 2.6. The documentation page doesn't mention this... http://docs.python.org/library/threading.html#threading.Thread.is_alive However, this is noted for other methods like the Event's is_set()... http://docs.python.org/library/threading.html#threading.Event.is_set Very minor issue, just meant that I needed to do a bit of experimentation to figure it out. ---------- assignee: docs at python components: Documentation messages: 163344 nosy: atagar1, docs at python priority: normal severity: normal status: open title: Theading isAlive() missing version note versions: Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15126> _______________________________________ From report at bugs.python.org Thu Jun 21 18:27:53 2012 From: report at bugs.python.org (hansokumake) Date: Thu, 21 Jun 2012 16:27:53 +0000 Subject: [issue15120] Different behavior of html.parser.HTMLParser In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za> Message-ID: <1340296073.85.0.156787549819.issue15120@psf.upfronthosting.co.za> hansokumake <hansokumake at seznam.cz> added the comment: I'm sorry. It's my fault. I still use Python 3.2.2. ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15120> _______________________________________ From report at bugs.python.org Thu Jun 21 18:33:36 2012 From: report at bugs.python.org (Damian) Date: Thu, 21 Jun 2012 16:33:36 +0000 Subject: [issue15126] Theading isAlive() missing version note In-Reply-To: <1340296072.22.0.188221984901.issue15126@psf.upfronthosting.co.za> Message-ID: <1340296416.86.0.519235017086.issue15126@psf.upfronthosting.co.za> Damian <atagar1 at gmail.com> added the comment: I'm gonna hazard the guess that other methods like currentThread() and current_thread() are the same... http://docs.python.org/library/threading.html#threading.current_thread ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15126> _______________________________________ From report at bugs.python.org Thu Jun 21 18:35:13 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 21 Jun 2012 16:35:13 +0000 Subject: [issue15120] Different behavior of html.parser.HTMLParser In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za> Message-ID: <1340296513.71.0.757837430635.issue15120@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- resolution: -> invalid stage: -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15120> _______________________________________ From report at bugs.python.org Thu Jun 21 18:41:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 21 Jun 2012 16:41:46 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340295879.65.0.78638872331.issue15061@psf.upfronthosting.co.za> Message-ID: <1340296698.3357.20.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > The file is targeted for Objects/stringlib/timingsafe.h. stringlib is for type-generic functions, so I don't think it should be put there. > - I only handle exact byte or unicode types (no subclasses) since a > user may have overwritten __eq__ and I don't want to special case it. We could handle all bytes-compatible objects, using the buffer API. > - The unicode path works only with compact ASCII strings. I'm not > familiar with the new API so please scream if I did it wrong. It looks ok to me. > Where should I place the function? hashlib would be a nice place but > there are multiple backends for hashlib. _hashopenssl.c seems wrong. Well, if it's meant to be a private function called from hmac, where it's defined is an implementation detail. I think practicality beats purity, so _hashopenssl is a good enough place. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 21 18:48:42 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 21 Jun 2012 16:48:42 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340297322.01.0.632945946894.issue15124@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: On 32 bit linux in a VM I get BEFORE allocation 0.125 acquire/release 0.434 AFTER allocation 0.109 (-13%) acquire/release 0.346 (-20%) ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Thu Jun 21 19:02:57 2012 From: report at bugs.python.org (Samuel John) Date: Thu, 21 Jun 2012 17:02:57 +0000 Subject: [issue15127] Supressing warnings with -w "whether gcc supports ParseTuple" Message-ID: <1340298177.77.0.231186835152.issue15127@psf.upfronthosting.co.za> New submission from Samuel John <python at samueljohn.de>: In configrue.in, Python checks if the compiler supports __attribute__((format(PyArg_ParseTuple, 2, 3))) and sets the CFLAGS to "CFLAGS -Werror" to decide this test. When you build Python with "CFLAGS=-w" (homebrew's default), configure reports whether gcc supports ParseTuple ... yes which is not supported for clang (I was told). I know it's hard to remove a certain flag from the CFLAGS, but perhaps there should be better documentation about this issue. ---------- components: Build messages: 163349 nosy: samueljohn priority: normal severity: normal status: open title: Supressing warnings with -w "whether gcc supports ParseTuple" type: compile error versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15127> _______________________________________ From report at bugs.python.org Thu Jun 21 19:10:39 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 21 Jun 2012 17:10:39 +0000 Subject: [issue13483] Use VirtualAlloc to allocate memory arenas In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za> Message-ID: <1340298639.97.0.336922882398.issue13483@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Here is a benchmark. Based on my assumption that this patch may reduce allocation overheads due to minimizing padding+fragmentation, it allocates a lot of memory, and then waits 20s so you can check in the process explorer what the "Commit Size" of the process is. For the current 3.3 tree, in 32-bit mode, on a 64-bit Windows 7 installation, I get 464,756K for the unpatched version, and 450,436K for the patched version. This is a 3% saving, which seems good enough for me. ---------- Added file: http://bugs.python.org/file26069/tuples.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13483> _______________________________________ From report at bugs.python.org Thu Jun 21 19:11:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 21 Jun 2012 17:11:05 +0000 Subject: [issue13483] Use VirtualAlloc to allocate memory arenas In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za> Message-ID: <1340298665.54.0.730749179318.issue13483@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Here is an updated patch. ---------- Added file: http://bugs.python.org/file26070/va.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13483> _______________________________________ From report at bugs.python.org Thu Jun 21 19:15:16 2012 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Jun 2012 17:15:16 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340298916.16.0.117856986088.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: New patch - pep362.7.patch Summary: 1. Signature & Parameter objects are now immutable 2. Signature.replace() and Parameter.replace() 3. Signature has a new default constructor, which accepts parameters list and a return_annotation; and a new 'from_function', which create a Signature object for the passed function. 4. Parameter.__str__ The implementation has 100% test coverage and is stable. Please review. Thanks! ---------- Added file: http://bugs.python.org/file26071/pep362.7.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Thu Jun 21 19:30:04 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 21 Jun 2012 17:30:04 +0000 Subject: [issue15119] ctypes mixed-types bitfield layout nonsensical; doesn't match compiler. In-Reply-To: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za> Message-ID: <1340299804.63.0.65303748456.issue15119@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: There are two separate issues here. The first is that the layout that ctypes chooses for a struct of bitfields fails basic sanity checks, like having each bitfield actually fit in the corresponding type. As a result, the C-level bitshifting code used to get bitfields ends up invoking undefined behaviour. A secondary problem is that the ctypes layout doesn't match what the compiler does, at least for the system supplied gcc (4.2) on OS X 10.6. The attached patch fixes the first issue, but not the second. ---------- keywords: +patch title: Bug in ctypes bitfield layout? -> ctypes mixed-types bitfield layout nonsensical; doesn't match compiler. Added file: http://bugs.python.org/file26072/ctypes_mixed_bitfields.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15119> _______________________________________ From report at bugs.python.org Thu Jun 21 19:40:33 2012 From: report at bugs.python.org (Meador Inge) Date: Thu, 21 Jun 2012 17:40:33 +0000 Subject: [issue15119] ctypes mixed-types bitfield layout nonsensical; doesn't match compiler. In-Reply-To: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za> Message-ID: <1340300433.04.0.0971969840642.issue15119@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: Thanks for digging into this Mark. I will have a look too later in the day. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15119> _______________________________________ From report at bugs.python.org Thu Jun 21 20:01:08 2012 From: report at bugs.python.org (Kevin M. Turner) Date: Thu, 21 Jun 2012 18:01:08 +0000 Subject: [issue15128] inspect raises exception when frames are misleading about source line numbers Message-ID: <1340301668.18.0.785702018205.issue15128@psf.upfronthosting.co.za> New submission from Kevin M. Turner <acapnotic at users.sourceforge.net>: The attached example shows how inspect.findsource fails when given a stack frame that points to a non-existent source line, and how inspect.getframeinfo and getinnerframes do not handle that failure. On the one hand, yes, this code was asking for it by building such a broken frame. On the other hand, having code that examines tracebacks result in tracebacks of its own sucks a whole bunch. The inspect find&get source methods are documented as returning IOError if they cannot find the source, and the calling code handles that case, so that's probably what should happen here. (Actually, that seems straightforward enough, I can make a patch for that shortly.) This may help with issue #1628987 as well. ---------- components: Library (Lib) files: inspectLineNumber.py messages: 163355 nosy: acapnotic priority: normal severity: normal status: open title: inspect raises exception when frames are misleading about source line numbers versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file26073/inspectLineNumber.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15128> _______________________________________ From report at bugs.python.org Thu Jun 21 20:17:49 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 21 Jun 2012 18:17:49 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <1340302669.05.0.823187276563.issue14769@psf.upfronthosting.co.za> Benjamin Peterson <benjamin at python.org> added the comment: Okay ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14769> _______________________________________ From report at bugs.python.org Thu Jun 21 20:23:04 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 21 Jun 2012 18:23:04 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1340302984.16.0.971845586087.issue14776@psf.upfronthosting.co.za> Dave Malcolm <dmalcolm at redhat.com> added the comment: I'm attaching an updated version of the patch; I hope there's still time before Saturday to get it into 3.3 I found a bug in the configure script in the old patch: /usr/bin/dtrace was required, even without requesting systemtap. I've fixed it by adding a new "SYSTEMTAPDEPS" to the configure.a/Makefile.pre.in A minor subtlety: within the configure.ac's --with-systemtap branch it is set up like this: SYSTEMTAPDEPS="\$(srcdir)/Python/pysystemtap.h" where the leading backslash is needed so that $(srcdir) doesn't get interpreted by the shell when running configure as "run the command named 'srcdir'". I also added removal of $(srcdir)/Python/pysystemtap.h to the "clean" target I made a slight change to the static markers themselves: they now pass a 4th argument, the PyFrameObject*, since it's possible to make use of this to inspect locals etc from systemtap, which might be of use to people. This doesn't introduce any further complexity to the ceval.c code. I moved the documentation from the devguide back to the cpython source tree, rewrote it as a HOWTO (Doc/howto/instrumentation.rst), adding some extra material (e.g. about tapsets). I also added a NEWS item. Tested on a Fedora 15 box with these configurations: * --with-pydebug (implicit --without-systemtap) * explicitly --without-systemtap * --with-pydebug --with-systemtap * --with-pydebug --enable-shared --with-systemtap * --enable-shared --with-systemtap (note that because of issue 14774 I had to rebuild _sysconfigdata.py each time, or the tests fail due to being confused about whether we were configured with --enable-shared) How is this looking? ---------- Added file: http://bugs.python.org/file26074/cpython-systemtap-2012-06-21-001.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14776> _______________________________________ From report at bugs.python.org Thu Jun 21 20:31:29 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 18:31:29 +0000 Subject: [issue15122] Add an option to always rewrite single-file mailboxes in-place. In-Reply-To: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za> Message-ID: <1340303489.68.0.256081888836.issue15122@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: I looked at the source code of mutt to see how it rewrites mbox files. It does roughly this: 1. Block some signals. 2. Lock the mbox file (with dotlock, fcntl and flock). 3. Create a temporary file in /tmp. 4. Write messages to the temporary file, from the point where the first change is up to the end of the mbox file. This saves a lot of writing when the first change is near the end of the file. 5. Write changes from the temporary file to the mbox file, modifying the mbox file in-place. 6. Truncate the mbox file to the correct length. 7. Unblock signals. If writing the changes back to the mbox file fails, the temporary file is copied from /tmp to near the mbox file. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15122> _______________________________________ From report at bugs.python.org Thu Jun 21 20:51:48 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 21 Jun 2012 18:51:48 +0000 Subject: [issue13698] Mailbox module should support other mbox formats in addition to mboxo In-Reply-To: <1325540787.88.0.149207146949.issue13698@psf.upfronthosting.co.za> Message-ID: <1340304708.62.0.545593061621.issue13698@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: I'm a little concerned about backwards compatibility. Someone might get upset if extra >'s start appearing in the messages when they read the mailbox contents with an application that uses the mboxo format. A little analysis on the possible corruptions that happen with these formats: - When the mailbox is both read and written using the mboxo format, lines starting with "From " are changed to ">From ". - When the mailbox is both read and written using the mboxrd format, no corruption happens. - If the mailbox is written using the mboxo format and read using the mboxrd format, lines that were meant to start with ">From " are changed to "From ". So we essentially get a sligthly different corruption. - If the mailbox is written using the mboxrd format and read using the mboxo format, lines that were meant to start with ">From " are changed to ">>From ". This is a new type of corruption. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13698> _______________________________________ From report at bugs.python.org Thu Jun 21 21:00:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Jun 2012 19:00:30 +0000 Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?= =?utf-8?b?dF9fIGZhaWxz?= In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za> Message-ID: <E1ShmcA-0002L5-1V@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 981ad5254d07 by Hynek Schlawack in branch '2.7': #10053: Don't close FDs when FileIO.__init__ fails http://hg.python.org/cpython/rev/981ad5254d07 New changeset d042bd8625f3 by Hynek Schlawack in branch '3.2': #10053: Don't close FDs when FileIO.__init__ fails http://hg.python.org/cpython/rev/d042bd8625f3 New changeset 464cf523485e by Hynek Schlawack in branch 'default': #10053: Don't close FDs when FileIO.__init__ fails http://hg.python.org/cpython/rev/464cf523485e ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10053> _______________________________________ From report at bugs.python.org Thu Jun 21 22:09:43 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Jun 2012 20:09:43 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1340309383.4.0.394647589833.issue15037@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Thanks for the testing. Georg, haypo: I think a call should be made on what, if anything, to do about this prior to 3.3.0-final. It seems that there are still OS distributions out there with older versions of ncurses. Is documenting this bug sufficient? If so, where? ---------- priority: high -> deferred blocker title: test_curses fails with OverflowError -> curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15037> _______________________________________ From report at bugs.python.org Thu Jun 21 22:13:10 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Jun 2012 20:13:10 +0000 Subject: [issue12567] curses implementation of Unicode is wrong in Python 3 In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za> Message-ID: <1340309590.07.0.669384732161.issue12567@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: See also Issue15037 which documents a broken curses.unget_wch and, hence, test_curses when Python is built with ncurses 5.7 or earlier. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12567> _______________________________________ From report at bugs.python.org Thu Jun 21 22:36:28 2012 From: report at bugs.python.org (Tony Malykh) Date: Thu, 21 Jun 2012 20:36:28 +0000 Subject: [issue15129] file.readline() cannot read weird ascii character in file Message-ID: <1340310988.11.0.765927148859.issue15129@psf.upfronthosting.co.za> New submission from Tony Malykh <anton.malykh at gmail.com>: readline() or readlines() method can read the file up to the line where weird character ascii code 26 appears. I would like to read the entire file though. A simple example attached. ---------- components: IO files: testpy.zip messages: 163363 nosy: Tony.Malykh priority: normal severity: normal status: open title: file.readline() cannot read weird ascii character in file type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26075/testpy.zip _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15129> _______________________________________ From report at bugs.python.org Thu Jun 21 22:49:12 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Thu, 21 Jun 2012 20:49:12 +0000 Subject: [issue15130] remove redundant paragraph in socket howto Message-ID: <1340311752.3.0.940656841103.issue15130@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>: same text used on Abstract is used in the beginning of the main text ---------- assignee: docs at python components: Documentation files: redundancy.diff keywords: patch messages: 163364 nosy: docs at python, tshepang priority: normal severity: normal status: open title: remove redundant paragraph in socket howto versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26076/redundancy.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15130> _______________________________________ From report at bugs.python.org Thu Jun 21 22:55:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Jun 2012 20:55:44 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340296698.3357.20.camel@localhost.localdomain> Message-ID: <1340312157.2703.17.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > > - I only handle exact byte or unicode types (no subclasses) since a > > user may have overwritten __eq__ and I don't want to special case it. > We could handle all bytes-compatible objects, using the buffer API. It is timing unsafe. > > - The unicode path works only with compact ASCII strings. I'm not > > familiar with the new API so please scream if I did it wrong. > It looks ok to me. The user can just do timingsafe_eq(a.decode('ascii'), b.decode('ascii')). I do not see a necessity in support of unicode strings. Support ASCII strings will create the false impression that all strings are supported. About code. Instead (PyBytes_CheckExact(a) && PyBytes_CheckExact(b)) you should use ((PyBytes_CheckExact(a) != 0) & (PyBytes_CheckExact(b) != 0)). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 21 23:00:42 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 21 Jun 2012 21:00:42 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340312157.2703.17.camel@raxxla> Message-ID: <4FE38B78.3080403@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > The user can just do timingsafe_eq(a.decode('ascii'), > b.decode('ascii')). You mean .encode()? > I do not see a necessity in support of unicode > strings. Support ASCII strings will create the false impression that all > strings are supported. I agree. > About code. Instead (PyBytes_CheckExact(a) && PyBytes_CheckExact(b)) you > should use ((PyBytes_CheckExact(a) != 0) & (PyBytes_CheckExact(b) != > 0)). What's the difference? They are the same. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 21 23:05:06 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 21 Jun 2012 21:05:06 +0000 Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?= =?utf-8?b?dF9fIGZhaWxz?= In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za> Message-ID: <1340312706.77.0.680018091298.issue10053@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Should be fixed now. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10053> _______________________________________ From report at bugs.python.org Thu Jun 21 23:09:35 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Jun 2012 21:09:35 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <4FE38B78.3080403@v.loewis.de> Message-ID: <1340312987.2703.25.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > You mean .encode()? Yes, of cause. timingsafe_eq(a.encode('ascii'), b.encode('ascii')). > > About code. Instead (PyBytes_CheckExact(a) && PyBytes_CheckExact(b)) you > > should use ((PyBytes_CheckExact(a) != 0) & (PyBytes_CheckExact(b) != > > 0)). > > What's the difference? They are the same. Laziness. If "a" (a secret key) is not bytes then PyBytes_CheckExact(b) ("b" is a user input) is not called. It exposes secret key type. I'm not sure if it is real secret however. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 21 23:21:06 2012 From: report at bugs.python.org (Uoti Urpala) Date: Thu, 21 Jun 2012 21:21:06 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1340313666.64.0.563392428103.issue3982@psf.upfronthosting.co.za> Uoti Urpala <uoti.urpala at pp1.inet.fi> added the comment: I've hit this limitation a couple more times, and none of the proposed workarounds are adequate. Working with protocols and file formats that use human-readable markup is significantly clumsier than it was with Python 2 (using either the % operator, which also lost its support for byte strings in Python 3, or .format()). This bug report was closed by its original creator, after early posts where IMO nobody made as good a case for the feature as they could have. Is it possible to reopen this bug or is it necessary to file a new one? Is there any clear argument AGAINST having .format() for bytes, other than work needed to implement it? Some posts mention "mixing characters and bytes", but I see no reason why this would be much of a real practical concern if it's a method on bytes objects producing bytes output. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3982> _______________________________________ From report at bugs.python.org Thu Jun 21 23:38:42 2012 From: report at bugs.python.org (Kevin M. Turner) Date: Thu, 21 Jun 2012 21:38:42 +0000 Subject: [issue15128] inspect raises exception when frames are misleading about source line numbers In-Reply-To: <1340301668.18.0.785702018205.issue15128@psf.upfronthosting.co.za> Message-ID: <1340314722.32.0.949394729707.issue15128@psf.upfronthosting.co.za> Kevin M. Turner <acapnotic at users.sourceforge.net> added the comment: patch attached (against python 2.7 tip) ---------- keywords: +patch Added file: http://bugs.python.org/file26077/15128-inspect-source-linenum.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15128> _______________________________________ From report at bugs.python.org Thu Jun 21 23:45:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 21 Jun 2012 21:45:30 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340312157.2703.17.camel@raxxla> Message-ID: <1340314923.3400.0.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > > > - I only handle exact byte or unicode types (no subclasses) since a > > > user may have overwritten __eq__ and I don't want to special case it. > > We could handle all bytes-compatible objects, using the buffer API. > > It is timing unsafe. How so? > > > - The unicode path works only with compact ASCII strings. I'm not > > > familiar with the new API so please scream if I did it wrong. > > It looks ok to me. > > The user can just do timingsafe_eq(a.decode('ascii'), > b.decode('ascii')). I don't think that's the right answer, because people will instead e.g. encode('utf-8'), and suddently the encodingly will not be timing-safe. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Thu Jun 21 23:59:01 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 21 Jun 2012 21:59:01 +0000 Subject: [issue15126] Theading isAlive() missing version note In-Reply-To: <1340296072.22.0.188221984901.issue15126@psf.upfronthosting.co.za> Message-ID: <1340315941.55.0.158847496845.issue15126@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Since the news aliases are all over the module, the version change notice is at the top of the page: """ Note Starting with Python 2.6, this module provides PEP 8 compliant aliases and properties to replace the camelCase names that were inspired by Java?s threading API. This updated API is compatible with that of the multiprocessing module. However, no schedule has been set for the deprecation of the camelCase names and they remain fully supported in both Python 2.x and 3.x. """ ---------- nosy: +georg.brandl resolution: -> works for me status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15126> _______________________________________ From report at bugs.python.org Fri Jun 22 00:05:47 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 21 Jun 2012 22:05:47 +0000 Subject: [issue15129] file.readline() cannot read weird ascii character in file In-Reply-To: <1340310988.11.0.765927148859.issue15129@psf.upfronthosting.co.za> Message-ID: <1340316347.11.0.948094172018.issue15129@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Your problem is similar to this discussion: http://stackoverflow.com/questions/405058/line-reading-chokes-on-0x1a On Python2, files are based on the fopen() C function, and on Windows files opened in text mode stop reading on the first character 26 (^Z, or EOF) The best solution here is probably to open the file in "universal" mode: f = open("test.txt", "rU") ...Or use Python3, which has a completely new implementation of the open() function. ---------- nosy: +amaury.forgeotdarc resolution: -> wont fix status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15129> _______________________________________ From report at bugs.python.org Fri Jun 22 00:16:22 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 21 Jun 2012 22:16:22 +0000 Subject: [issue15131] Document py/pyw launchers Message-ID: <1340316982.35.0.0939341708.issue15131@psf.upfronthosting.co.za> New submission from Brian Curtin <brian at python.org>: As of http://hg.python.org/cpython/rev/a7ecbb2ad967, the PEP 397 launchers are included. Their functionality should be documented. ---------- assignee: docs at python components: Documentation, Windows messages: 163374 nosy: brian.curtin, docs at python priority: critical severity: normal stage: needs patch status: open title: Document py/pyw launchers type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15131> _______________________________________ From report at bugs.python.org Fri Jun 22 00:16:46 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 21 Jun 2012 22:16:46 +0000 Subject: [issue15131] Document py/pyw launchers In-Reply-To: <1340316982.35.0.0939341708.issue15131@psf.upfronthosting.co.za> Message-ID: <1340317006.05.0.435277503602.issue15131@psf.upfronthosting.co.za> Changes by Brian Curtin <brian at python.org>: ---------- assignee: docs at python -> brian.curtin _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15131> _______________________________________ From report at bugs.python.org Fri Jun 22 00:16:49 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 21 Jun 2012 22:16:49 +0000 Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?= =?utf-8?b?dF9fIGZhaWxz?= In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za> Message-ID: <1340317009.88.0.4543373337.issue10053@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Shouldn?t the fix be ported to _pyio? ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10053> _______________________________________ From report at bugs.python.org Fri Jun 22 00:30:03 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 21 Jun 2012 22:30:03 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340317803.73.0.478443788618.issue444582@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: Here's a patch that also works on linux. A pathext specific test is now skipped since that only matters on Windows, and I forgot a chmod that was making two tests fail on linux. ---------- Added file: http://bugs.python.org/file26078/issue444582_v3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 00:40:34 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 21 Jun 2012 22:40:34 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340318434.96.0.298431922884.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: I'm a bit rusty and I hope I got it right. The ASCII unicode case is a good idea and IMO timing safe. The buffer path is also timing safe once I have both views. The function leaks some timing information when an error occurs. Since the timing just reveals minimal information about the involved types and none about the bytes it's IMO safe. The acquiring of the buffer views may leak an unknown amount of timing data which may be an issue. The comparison is still safe. I've introduced a new module _hashlibfb (fb = fallback) for systems without openssl. I'm also open for a completely new module for future implementation of other digest, key derivation (PBKDF2) and password related C code. ---------- Added file: http://bugs.python.org/file26079/timingsafe_cmp.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 22 01:26:18 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 21 Jun 2012 23:26:18 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340321178.97.0.93843340546.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: The patch has another flaw. The compiler may choose to fold and optimize code in _tscmp(). I'm going to declare the length of the right side and both char* as volatile. That should stop any compiler. I could also add some pragmas: MSVC: #pragma optimize("", off) code #pragma optimize("", on) GCC 4.4+: #pragma GCC push_options #pragma GCC optimize ("O0") code #pragma GCC pop_options ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 22 01:41:28 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 Jun 2012 23:41:28 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1340322088.87.0.817712715064.issue3982@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: If you want to discuss this issue further, I think you post to python-ideas list with concrete examples. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3982> _______________________________________ From report at bugs.python.org Fri Jun 22 01:51:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Jun 2012 23:51:42 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <E1ShrA3-0006eD-GF@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 1cfa44cb5af0 by Nadeem Vawda in branch 'default': Document the rest of zlib.compressobj()'s arguments. http://hg.python.org/cpython/rev/1cfa44cb5af0 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14684> _______________________________________ From report at bugs.python.org Fri Jun 22 02:49:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 00:49:15 +0000 Subject: [issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime In-Reply-To: <1335213212.56.0.724242644314.issue14653@psf.upfronthosting.co.za> Message-ID: <E1Shs3k-00040n-IN@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset ffc048f43a70 by Alexander Belopolsky in branch '3.2': Issue #14653: email.utils.mktime_tz() no longer relies on system http://hg.python.org/cpython/rev/ffc048f43a70 New changeset 9f88c38318ac by Alexander Belopolsky in branch 'default': Issue #14653: email.utils.mktime_tz() no longer relies on system http://hg.python.org/cpython/rev/9f88c38318ac ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14653> _______________________________________ From report at bugs.python.org Fri Jun 22 02:57:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 00:57:52 +0000 Subject: [issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime In-Reply-To: <1335213212.56.0.724242644314.issue14653@psf.upfronthosting.co.za> Message-ID: <E1ShsC6-0004ui-Rs@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset a283563c8cc4 by Alexander Belopolsky in branch '2.7': Issue #14653: email.utils.mktime_tz() no longer relies on system http://hg.python.org/cpython/rev/a283563c8cc4 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14653> _______________________________________ From report at bugs.python.org Fri Jun 22 02:59:25 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 00:59:25 +0000 Subject: [issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime In-Reply-To: <1335213212.56.0.724242644314.issue14653@psf.upfronthosting.co.za> Message-ID: <1340326765.48.0.151173956958.issue14653@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14653> _______________________________________ From report at bugs.python.org Fri Jun 22 03:01:13 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 01:01:13 +0000 Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za> Message-ID: <1340326873.36.0.502916216918.issue7584@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7584> _______________________________________ From report at bugs.python.org Fri Jun 22 03:06:08 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 01:06:08 +0000 Subject: [issue15125] argparse: positional arguments containing - in name not handled well In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za> Message-ID: <1340327168.33.0.207482792541.issue15125@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: It does. ---------- keywords: +easy nosy: +bethard, r.david.murray stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15125> _______________________________________ From report at bugs.python.org Fri Jun 22 07:53:17 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 22 Jun 2012 05:53:17 +0000 Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?= =?utf-8?b?dF9fIGZhaWxz?= In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za> Message-ID: <1340344397.02.0.813327385816.issue10053@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Hmmm, I thought Lib/_pyio.py actually uses Lib/_io/_fileio.c? At least I can't find the logic inside. There's no error handling at all. It just uses the FileIO object in Lib/_pyio.py:189 which it seems to get from Lib/_pyio.py:585 which I presumed was from Lib/_io/_fileio.c. What am I missing and how would I be supposed to port that? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10053> _______________________________________ From report at bugs.python.org Fri Jun 22 08:08:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jun 2012 06:08:53 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340314923.3400.0.camel@localhost.localdomain> Message-ID: <1340345342.2703.43.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > > > We could handle all bytes-compatible objects, using the buffer API. > > It is timing unsafe. > How so? I checked myself, and I see that most likely I was wrong. At least for bytes and bytearrays it is timing safe. > I don't think that's the right answer, because people will instead e.g. > encode('utf-8'), and suddently the encodingly will not be timing-safe. And what of that? It is outside of the timingsafe_eq function. People can also do other timing unsafe operations with the secret key (for example reading it from file or from DB) or not to use timingsafe_eq at all. The secret key should be pre-encoded. The error will be if code works for developer from ASCII word, and then on the other side of ocean it will no longer work with non-ASCII strings. You are expected to be familiar with such issues. In any case, the obvious (and simplest, and fastest) way to check that a string is ASCII-only is try to encoded it to ASCII. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 22 10:25:30 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 22 Jun 2012 08:25:30 +0000 Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a list Message-ID: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za> New submission from Chris Jerdonek <chris.jerdonek at gmail.com>: It would be nice if unittest.TestProgram(), aka unittest.main(), allowed one to set self.testNames by programmatically passing in a list of test names. Currently, unittest.main() almost allows this: the constructor sets self.testNames to a 1-tuple containing the value of the defaultTest argument. But defaultTest can only be a string, not a list of test names. A way around this is to pass the test names explicitly via the argv argument, but this seems less elegant as a programmatic API. Moreover, this approach isn't equivalent because test names passed via argv first get passed to a _convert_names() function. It seems like it would be a natural and simple change to enhance unittest.TestProgram() to accept not just a name but also a list of names for the defaultTest argument. Thanks. ---------- components: Library (Lib) keywords: easy messages: 163386 nosy: cjerdonek priority: normal severity: normal status: open title: Let unittest.TestProgram()'s defaultTest argument be a list type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15132> _______________________________________ From report at bugs.python.org Fri Jun 22 11:27:46 2012 From: report at bugs.python.org (Mark Summerfield) Date: Fri, 22 Jun 2012 09:27:46 +0000 Subject: [issue15133] tkinter.BooleanVar.get() docstring is wrong Message-ID: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> New submission from Mark Summerfield <mark at qtrac.eu>: Python 3.2.2 (default, Jun 4 2012, 11:15:16) [GCC 4.4.5] on linux2 Type "copyright", "credits" or "license()" for more information. >>> from tkinter import * >>> help(BooleanVar.get) Help on function get in module tkinter: get(self) Return the value of the variable as a bool. On my system it actually returns an int. (I wish it did return a bool though.) ---------- components: Tkinter messages: 163387 nosy: mark priority: normal severity: normal status: open title: tkinter.BooleanVar.get() docstring is wrong versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Fri Jun 22 11:31:15 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 09:31:15 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340357475.31.0.218791120705.issue15124@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Interesting, I need to see what is the reason for that. Possibly, sem_* primitives used there are so cheap that they don't matter. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Fri Jun 22 11:34:45 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 22 Jun 2012 09:34:45 +0000 Subject: [issue15134] urllib.request.thishost() fails on OSX 10.7 Message-ID: <1340357685.54.0.913486027358.issue15134@psf.upfronthosting.co.za> New submission from Ronald Oussoren <ronaldoussoren at mac.com>: I just noticed that test_urllib fails for me because urllib.request.thishost() fails: ====================================================================== ERROR: test_thishost (test.test_urllib.Utility_Tests) Test the urllib.request.thishost utility function returns a tuple ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/ronald/Projects/python/rw/default/Lib/test/test_urllib.py", line 1155, in test_thishost self.assertIsInstance(urllib.request.thishost(), tuple) File "/Users/ronald/Projects/python/rw/default/Lib/urllib/request.py", line 2236, in thishost _thishost = tuple(socket.gethostbyname_ex(socket.gethostname())[2]) socket.gaierror: [Errno 8] nodename nor servname provided, or not known ---------------------------------------------------------------------- This is because this host's hostname (Gondolin.local) is not in DNS because my mDNSReponder detected a conflict and picked a different name to advertise in the .local zone without updating the hostname. The reason I report this anyway is that URLopener.open_local_file seems to assume that thishost() cannot fail, and the error condition on my machine could easily happen on other systems as well. BTW. The use of this host() in URLopener.open_local_file is wrong for other reasons as well: it assumes that the local machine has exactly 1 IP address, and won't correctly detect that a file is local when the IP address is one of the other IP addresses on a multi homed system. ---------- components: Library (Lib) messages: 163389 nosy: ronaldoussoren priority: normal severity: normal status: open title: urllib.request.thishost() fails on OSX 10.7 versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15134> _______________________________________ From report at bugs.python.org Fri Jun 22 12:09:09 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 22 Jun 2012 10:09:09 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340359749.6.0.855359121667.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: > The error will be if code works for developer from ASCII word, and then > on the other side of ocean it will no longer work with non-ASCII > strings. You are expected to be familiar with such issues. In any case, > the obvious (and simplest, and fastest) way to check that a string is > ASCII-only is try to encoded it to ASCII. No, the fastest way is to check the kind attribute of the unicode object in C code. That doesn't involve any additional conversion or Python function call. The function is deliberately limited. The ASCII fallback is very useful as most people will store hex encoded bytes of their passphrases in their databases. With ASCII support you can do timingsafe_compare(hex_from_db, hmac.hexdigest()). Maciej: http://pastebin.com/ZAAjSkJh The C function is one order of magnitude faster and the spread is one order smaller. 1e-07 is within the noise level on my idle computer. A busy server will have a higher noise level. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 22 12:21:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 10:21:27 +0000 Subject: [issue15042] Implemented PyState_AddModule, PyState_RemoveModule In-Reply-To: <1339320622.0.0.56459406352.issue15042@psf.upfronthosting.co.za> Message-ID: <E1Si0zU-0004yX-VA@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 55e8cba34b11 by Martin v. L?wis in branch 'default': Issue #15042: Add PyState_AddModule and PyState_RemoveModule. http://hg.python.org/cpython/rev/55e8cba34b11 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15042> _______________________________________ From report at bugs.python.org Fri Jun 22 12:21:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 10:21:27 +0000 Subject: [issue15081] No documentation for PyState_FindModule() In-Reply-To: <1339805271.75.0.926484818342.issue15081@psf.upfronthosting.co.za> Message-ID: <E1Si0zV-0004yX-0K@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 55e8cba34b11 by Martin v. L?wis in branch 'default': Issue #15042: Add PyState_AddModule and PyState_RemoveModule. http://hg.python.org/cpython/rev/55e8cba34b11 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15081> _______________________________________ From report at bugs.python.org Fri Jun 22 12:48:21 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 22 Jun 2012 10:48:21 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1340362101.66.0.657474904109.issue14626@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Fifth iteration of my patch. Everything is done, and I really think it's ready to be checked in. * The documentation is done, including Misc/NEWS. * All the code is now < 80 columns. * The docstrings have been double- and triple-checked. * It passes all regression tests on Linux 64-bit; it processes the regression test suite identically to trunk on Windows 32-bit. ---------- Added file: http://bugs.python.org/file26080/larry.os.keyword.arguments.collapse.5.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Fri Jun 22 12:57:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 10:57:13 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <E1Si1Y7-0001wk-Q3@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset ace45d23628a by Larry Hastings in branch 'default': Issue #14769: test_capi now has SkipitemTest, which cleverly checks http://hg.python.org/cpython/rev/ace45d23628a ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14769> _______________________________________ From report at bugs.python.org Fri Jun 22 12:58:00 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 22 Jun 2012 10:58:00 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <1340362680.14.0.877730700956.issue14769@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14769> _______________________________________ From report at bugs.python.org Fri Jun 22 13:08:53 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 22 Jun 2012 11:08:53 +0000 Subject: [issue15081] No documentation for PyState_FindModule() In-Reply-To: <1339805271.75.0.926484818342.issue15081@psf.upfronthosting.co.za> Message-ID: <1340363333.94.0.444375544384.issue15081@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Thanks! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15081> _______________________________________ From report at bugs.python.org Fri Jun 22 13:13:12 2012 From: report at bugs.python.org (Pan Yongzhi) Date: Fri, 22 Jun 2012 11:13:12 +0000 Subject: [issue15135] HOWTOs doesn't link to "Idioms and Anti-Idioms" article Message-ID: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za> New submission from Pan Yongzhi <fossilet at users.sourceforge.net>: In the py3k docs howtos table of contents, http://docs.python.org/py3k/howto/index.html, the link to the article "Idioms and Anti-Idioms in Python" is gone, but the article is still in the doc. It is at http://docs.python.org/py3k/howto/doanddont.html. Should it have a link at the howtos section? ---------- assignee: docs at python components: Documentation messages: 163396 nosy: docs at python, fossilet priority: normal severity: normal status: open title: HOWTOs doesn't link to "Idioms and Anti-Idioms" article type: enhancement versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15135> _______________________________________ From report at bugs.python.org Fri Jun 22 13:18:09 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 22 Jun 2012 11:18:09 +0000 Subject: [issue15135] HOWTOs doesn't link to "Idioms and Anti-Idioms" article In-Reply-To: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za> Message-ID: <1340363889.11.0.126540716148.issue15135@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15135> _______________________________________ From report at bugs.python.org Fri Jun 22 13:51:52 2012 From: report at bugs.python.org (Jon Clements) Date: Fri, 22 Jun 2012 11:51:52 +0000 Subject: [issue15136] Decimal accepting Fraction Message-ID: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> New submission from Jon Clements <joncle at googlemail.com>: I'm not a numeric expert but I was looking at a post on S/O which related to converting a Fraction to a certain amount of decimal places. I've had a hunt on the tracker but couldn't find anything relevant, but if I've missed it, I apologise. # F=Fraction, D=Decimal classes If I try num = D( F(5, 7) ) I get: TypeError: Cannot convert Fraction(5, 7) to Decimal So I do: >>> D(f.numerator) / D(f.denominator) Decimal('0.7142857142857142857142857143') Which I think is the correct result? I guess my question is - should Decimal do this implicitly for Fraction? ---------- components: Library (Lib) messages: 163397 nosy: joncle priority: normal severity: normal status: open title: Decimal accepting Fraction type: enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 14:14:39 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 22 Jun 2012 12:14:39 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340367279.05.0.0791566867539.issue15136@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: +1 ---------- nosy: +ramchandra.apte _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 14:32:01 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 22 Jun 2012 12:32:01 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340368321.3.0.214244043775.issue15136@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > I guess my question is - should Decimal do this implicitly for Fraction? I'd prefer not. All other cases of Decimal construction (from float, from string, etc.) are lossless with results that don't depend on the current context; construction from a Fraction will usually involve rounding, with results depending on the current rounding-mode and precision. Having the division operation explicit (making it obvious that there's rounding involved) looks better to me. ---------- nosy: +mark.dickinson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 14:40:18 2012 From: report at bugs.python.org (Jon Clements) Date: Fri, 22 Jun 2012 12:40:18 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340368818.06.0.159773569303.issue15136@psf.upfronthosting.co.za> Jon Clements <joncle at googlemail.com> added the comment: Mark - I bow to your superiour knowledge here. However, would not a classmethod of .from_fraction be welcome? ie, I could write: d = D.from_fraction(5, 7) Then the documents labour the point about what you've mentioned? Just an idea, but fully realise you're the man best suited to decide, so I'll be happy with whatever you say. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 14:45:31 2012 From: report at bugs.python.org (Jon Clements) Date: Fri, 22 Jun 2012 12:45:31 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340369131.92.0.329402419654.issue15136@psf.upfronthosting.co.za> Jon Clements <joncle at googlemail.com> added the comment: Not sure what's going on with my machine today: keep sending things to early. I meant: D.from_fraction(F) where if F is not of type Fraction, then the args are used to construct a Fraction - so can use an existing or create one. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 14:48:33 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 22 Jun 2012 12:48:33 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340369313.06.0.307588108415.issue15136@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > would not a classmethod of .from_fraction be welcome? That depends. :-) Certainly a new classmethod seems better to me than extending the constructor to allow Fractions. I'm not convinced that there's a real need for this feature, though, especially given how easy it is do directly. So I'm -1 on extending the constructor, -0 on adding a .from_fraction method. I'm adding other decimally people to the nosy for their opinions. ---------- versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 14:49:14 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 22 Jun 2012 12:49:14 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340369354.51.0.460754393115.issue15136@psf.upfronthosting.co.za> Changes by Mark Dickinson <dickinsm at gmail.com>: ---------- nosy: +rhettinger, skrah _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 14:57:48 2012 From: report at bugs.python.org (Thom Nichols) Date: Fri, 22 Jun 2012 12:57:48 +0000 Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za> Message-ID: <1340369868.43.0.456854431403.issue4749@psf.upfronthosting.co.za> Thom Nichols <tmnichols at gmail.com> added the comment: I just ran into this issue, clearly it is old and Python 2.6, but I just experienced it in a single-process linux app running on a production embedded system. root at at91sam9g20ek:~# python Python 2.6.5 (r265:79063, Sep 28 2011, 11:52:59) [GCC 4.3.3] on linux2 The symptom is the original "ValueError: I/O operation on closed file." I see one log file that has reached its max size and never rolls over and as a result, the app is unable to log anything. Has anyone since experienced related issues that could exhibit this behavior? ---------- nosy: +Thom.Nichols _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4749> _______________________________________ From report at bugs.python.org Fri Jun 22 15:30:12 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 13:30:12 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340371812.31.0.491068700312.issue15124@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: I cannot repro. On my ubuntu virtualbox I get: before: kristjan at kristjan-VirtualBox:~/cpython$ ./python -m timeit -s "from _thread import allocate_lock" "allocate_lock()" 10000000 loops, best of 3: 0.0768 usec per loop kristjan at kristjan-VirtualBox:~/cpython$ ./python -m timeit -s "from _thread import allocate_lock;l=allocate_lock()" "l.acquire();l.release()" 1000000 loops, best of 3: 0.209 usec per loop after: kristjan at kristjan-VirtualBox:~/cpython$ ./python -m timeit -s "from _thread import allocate_lock" "allocate_lock()" 10000000 loops, best of 3: 0.069 usec per loop kristjan at kristjan-VirtualBox:~/cpython$ ./python -m timeit -s "from _thread import allocate_lock;l=allocate_lock()" "l.acquire();l.release()" 10000000 loops, best of 3: 0.182 usec per loop I did this a few times with consistent results. But virtual machines aren't the most stable of beasts. Perhaps someone with a proper unix box can test it? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Fri Jun 22 15:34:29 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 22 Jun 2012 13:34:29 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340372069.17.0.556206091565.issue15136@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: BTW, the StackOverflow question helped me understand the use-case here: http://stackoverflow.com/q/11154954/270986 The perspective is that of a *Fraction* user who wants to be able to easily see the Decimal expansion of a Fraction to an arbitrary number of decimal places. (I was trying to understand why a *Decimal* user would care about converting from Fraction instances, but that's the wrong way around.) That desire to have an easy way to see the digits of a Fraction seems reasonable to me, but I'm not sure that having a Decimal method is the right way to go about it. Another possible solution would be to implement a decent __format__ method for Fraction, so that somebody could do: >>> format(Fraction(1, 7), '.17g') >>> '0.14285714285714286' ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 15:35:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 13:35:41 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340372141.68.0.0122402655159.issue15124@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: 64-bit Linux: ./python -m timeit -s "from _thread import allocate_lock" "allocate_lock()" -> before: 0.0712 usec per loop -> after: 0.0556 usec per loop ./python -m timeit -s "from _thread import allocate_lock;l=allocate_lock()" "l.acquire();l.release()" -> before: 0.177 usec per loop -> after: 0.168 usec per loop So there's a small improvement on artificial benchmarks. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Fri Jun 22 15:38:13 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 22 Jun 2012 13:38:13 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340372293.98.0.839778949797.issue13590@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: The attached patch (issue1390-version1.txt) is not tested very well at the moment because I'm running into another problem when building on OSX 10.5, but should improve the build situation With this patch: * Configure will automatically pick clang when gcc is llvm-gcc (which miscompiles python3.3) * Configure will use the compiler embedded in Xcode.app when there is no compiler in /usr/bin (e.g. when using a clean install of Xcode 4.3) * Configure picks the most recent available SDK when using --with-universalsdk (cannot use '/' as the -isysroot because Xcode4.3 won't install headers in /usr/include unless you install the unix tools) * Distutils uses the configured compiler when available, and uses the same algorithm as configure when the configured compiler cannot be found * Distutils will remove '-arch ppc' from the compiler flags when that architecture is not supported (such as with recent Xcode 4 releases) I have build the tree on 10.7 and 10.6 with working tests. I'm now trying to build on 10.5 to generate the 32-bit installer, but ran into problems on my 10.5 machine: python.exe claims it cannot find the std. library. This is likely the known issue of Apple's GCC miscompiling python, but I haven't excluded other possibilities yet. ---------- Added file: http://bugs.python.org/file26081/issue1390-version1.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Fri Jun 22 15:56:57 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 13:56:57 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340373417.12.0.856957491986.issue15124@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: well, I'm thinking for example about threading.Condition, where Lock objects are being created and erased willy nilly. Also, locks are normally uncontested. The unconstested case is the one to optimize for. As such, the test cases are not artificial at all. The implementers of RLock in _threadingmodule obviously thought this was important, I'm merely bringing that same benefit to the Lock object. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Fri Jun 22 16:02:28 2012 From: report at bugs.python.org (Zearin) Date: Fri, 22 Jun 2012 14:02:28 +0000 Subject: [issue15137] Cleaned source of `cmd` module Message-ID: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> New submission from Zearin <zearin at users.sourceforge.net>: Cleaned up the source of the Standard Library?s `cmd` module. Attempted to focus on readability by changing things like using booleans instead of 0/1, newer syntax for string formatting, lining up variable declarations (judgement call), and adding comments between groups of methods. Used ace45d23628a to start my work. ---------- components: Library (Lib) files: cmd.py messages: 163409 nosy: zearin priority: normal severity: normal status: open title: Cleaned source of `cmd` module type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26082/cmd.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Fri Jun 22 16:13:24 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 22 Jun 2012 14:13:24 +0000 Subject: [issue15137] Cleaned source of `cmd` module In-Reply-To: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> Message-ID: <1340374404.84.0.443350100602.issue15137@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: The output of "hg diff" would be much appreciated, it's the only way for reviewers to realize the changes you made. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Fri Jun 22 16:16:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 14:16:46 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340373417.12.0.856957491986.issue15124@psf.upfronthosting.co.za> Message-ID: <1340374393.3366.19.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Also, locks are normally uncontested. The unconstested case is the > one to optimize for. As such, the test cases are not artificial at > all. Ok. I don't have any problem with the patch in principle (I didn't read it in detail). I was just a bit surprised that you cared so much about performance of lock allocation. If you want the patch to go in 3.3, you will have to commit it before the beta release, which is very soon (this week-end I think). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Fri Jun 22 16:22:38 2012 From: report at bugs.python.org (Zearin) Date: Fri, 22 Jun 2012 14:22:38 +0000 Subject: [issue15137] Cleaned source of `cmd` module In-Reply-To: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> Message-ID: <1340374958.5.0.715147970138.issue15137@psf.upfronthosting.co.za> Zearin <zearin at users.sourceforge.net> added the comment: Does `hg diff` produce different output than regular `diff`? If so, the patch created by regular `diff` is attached. (I basically did my work without using a local repo, and I have very little experience with patching. I basically just looked up how to create a patch with vanilla `diff`.) ---------- Added file: http://bugs.python.org/file26083/patch-cmd.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Fri Jun 22 16:31:16 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 14:31:16 +0000 Subject: [issue15137] Cleaned source of `cmd` module In-Reply-To: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> Message-ID: <1340375476.16.0.258620830607.issue15137@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I appreciate the work and thought that went into this, but this is not normally the kind of change that we apply. Any change has a chance of introducing bugs (see, for example, issue 15109, where a seemingly innocuous change from % formatting to .format formatting caused a regression in 2.7.3 compared to 2.7.2). The other option, applying it just to default, is also not normally done, because then the code base between versions is gratuitously different, making merging more difficult. So, our general policy is that we do cleanups only when we are changing that area of code in order to fix a bug or add an enhancement. And as you can see from issue 15109, even then we sometimes get in trouble. Now, if you are interested in the maintenance of the cmd module, and can suggest one or more fix/enhancement + cleanup patches like Lucasz Lagna did for configparser, that would be wonderful. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Fri Jun 22 16:36:51 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 14:36:51 +0000 Subject: [issue15137] Cleaned source of `cmd` module In-Reply-To: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> Message-ID: <1340375811.65.0.538638352099.issue15137@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Also as an FYI, triple double quote marks are our standard for docstrings. I don't believe we normally align assignments, but I don't know if that is specifically called out in PEP8. I haven't looked at the patch in detail, but in scanning it quickly, while some of your whitespace changes (spaces around operators) agree with our standards, others (extra spaces after a comma in a function call, for example) do not. Again, I appreciate your putting in this effort, and regret that it isn't something we can use. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Fri Jun 22 16:38:18 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 22 Jun 2012 14:38:18 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340375898.97.0.367367280772.issue13590@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: _binary_on_path looks unnecessary: distutils.util has a function to do that. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Fri Jun 22 16:39:22 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 22 Jun 2012 14:39:22 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340375962.08.0.958974227761.issue13590@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: distutils.spawn.find_executable* ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Fri Jun 22 16:46:17 2012 From: report at bugs.python.org (Meador Inge) Date: Fri, 22 Jun 2012 14:46:17 +0000 Subject: [issue15119] ctypes mixed-types bitfield layout nonsensical; doesn't match compiler. In-Reply-To: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za> Message-ID: <1340376377.14.0.34848671774.issue15119@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: >> At a guess, BITS.M should therefore look like <Field type=c_int, >> ofs=0:17, bits=1> instead. > > Refined guess: it should be <Field type=c_short, ofs=2:1, bits=1>. This refined guess seems reasonable. Although, bitfield allocation order for GCC is dependent on the target ABI. What you have above is at least consistent with the System V i386 [1] and x86-64 [2] psABIs. Not sure about others (other targets and MSVC++ related ones). I tested the original test case plus the cases listed in the i386 psABI, all which seem to work. I did notice that this doesn't seem to be right for big-endian machines: >>> from ctypes import * >>> class S(BigEndianStructure): ... _fields_ = [("A", c_int, 17), ("B", c_short, 1)] ... >>> class T(LittleEndianStructure): ... _fields_ = [("A", c_int, 17), ("B", c_short, 1)] ... >>> s = S() >>> s.B = 1 >>> s.B -1 >>> t = T() >>> t.B = 1 >>> t.B 0 The current implementation got the expected answer of -1 for 't.B' (although that is actually incorrect anyway because bitfields should never be treated as signed). So some big-endian tests and some tests that check the values stored in the fields will be useful. Finally, I think proposed allocation seems correct, but I must admit I am not clever enough to follow why the following part works :-) + /* Adjust current bit offset if necessary so that the next field + doesn't straddle a multiple of 8*dict->size. */ + if (*pbitofs && ( + (*pbitofs + bitsize - 1) % (8*dict->size) != + bitsize + (*pbitofs - 1) % (8*dict->size))) + *pbitofs += (8*dict->size) - 1 - (*pbitofs - 1) % (8*dict->size); [1] http://www.uclibc.org/docs/psABI-i386.pdf [2] http://www.x86-64.org/documentation/abi.pdf ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15119> _______________________________________ From report at bugs.python.org Fri Jun 22 16:46:28 2012 From: report at bugs.python.org (Meador Inge) Date: Fri, 22 Jun 2012 14:46:28 +0000 Subject: [issue15119] ctypes mixed-types bitfield layout nonsensical; doesn't match compiler. In-Reply-To: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za> Message-ID: <1340376388.97.0.580473523204.issue15119@psf.upfronthosting.co.za> Changes by Meador Inge <meadori at gmail.com>: ---------- stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15119> _______________________________________ From report at bugs.python.org Fri Jun 22 16:55:21 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 22 Jun 2012 14:55:21 +0000 Subject: [issue15119] ctypes mixed-types bitfield layout nonsensical; doesn't match compiler. In-Reply-To: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za> Message-ID: <1340376921.69.0.991269883073.issue15119@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > Finally, I think proposed allocation seems correct, but I must admit I > am not clever enough to follow why the following part works :-) Nor am I, any more, though it made sense when I wrote it. I'll see if I can make that a bit more readable. I see two goals here: (1) make the allocation sane and self-consistent, and also ideally document the algorithm ctypes uses (I know there's another issue already open for this), and (2) make the allocation match common compilers. (2) may not be easy / possible... I did some random testing on my machine (x64, OS X, gcc 4.2), which seems to show that the bitfield allocation algorithm for gcc works roughly like this: def simulated_layout(flags): bitpos = 0 for ctype, width in flags: if width is None: # Plain old integer field (not a bitfield) width = 8 * sizeof(ctype) space = -bitpos % (8 * sizeof(ctype)) if width > space: bitpos += space offset, start = divmod(bitpos, 8 * sizeof(ctype)) yield offset * sizeof(ctype), start, width bitpos += width At least, my simple and limited random tests have yet to discover a case where this differs from what gcc actually does on my machine, while they're pretty quick to find differences between what gcc does and what ctypes does. I've attached the script in case it's of interest (please don't judge too harshly---it was written quickly and the style leaves something to be desired). In particular, I didn't include signed integers in the tests; sounds like that's a potential complicating factor. ---------- Added file: http://bugs.python.org/file26084/ctypes_bitfields.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15119> _______________________________________ From report at bugs.python.org Fri Jun 22 16:59:23 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 22 Jun 2012 14:59:23 +0000 Subject: [issue15119] ctypes mixed-types bitfield layout nonsensical; doesn't match compiler. In-Reply-To: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za> Message-ID: <1340377163.13.0.907871905561.issue15119@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > this doesn't seem to be right for big-endian machines Right; I didn't pay too much attention to the big-endian case; definitely there should be lots of tests there, so that at least the buildbots have a chance of picking up problems. (Do we currently *have* any big-endian buildbots? I see one Sparc and one PPC machine, but it looks like they're both currently offline.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15119> _______________________________________ From report at bugs.python.org Fri Jun 22 17:00:00 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Jun 2012 15:00:00 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow Message-ID: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> New submission from Guido van Rossum <guido at python.org>: This bug is still present in Python 3.3. Some people use urlsafe strings *a lot*. And they find that the (obvious) implementation in base64.py is way too slow. In fact, I found myself writing the following a few times in App Engine libraries: # This is 3-4x faster than urlsafe_b64decode() urlsafe = base64.b64encode(<arg>) return urlsafe.rstrip('=').replace('+', '-').replace('/', '_') Someone from YouTube told me they patch the stdlib for the same reason (they claim their solution is 10x faster). IIUC the cause of the slowness is the (mostly irrelevant) generality in b64encode and the _translate() function. ---------- components: Library (Lib) keywords: easy messages: 163420 nosy: gvanrossum priority: normal severity: normal stage: needs patch status: open title: base64.urlsafe_b64**code are too slow type: performance versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 17:03:17 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 22 Jun 2012 15:03:17 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340377397.88.0.415001910791.issue13590@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: Thanks, I'll add it to the patch when I have a working build again. Looks like I get a failure because "pybuilddir.txt" is not created, and that's because "./python.exe setup.py build" crashes when distutils.sysconfig tries to import subprocess (which tries to import time, which cannot be found because it is not build yet. I'm switching to os.popen in my patch, that should be good enough for that code. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Fri Jun 22 17:32:07 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 22 Jun 2012 15:32:07 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340379127.15.0.25524363142.issue15138@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: This is a feature request, not a bug. Marking for 3.3. ---------- nosy: +jcea versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 17:38:33 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 15:38:33 +0000 Subject: [issue15139] Speed up threading.Condition wakeup Message-ID: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>: This patch is based on work previously done locally in python 2.7, see http://blog.ccpgames.com/kristjan/2012/05/25/optimizing-python-condition-variables-with-telemetry/ The idea is to acquire the signaling Lock() of the threading.Condition object _and_ the outer lock, without releasing and re-aquiring the GIL in between that is, as an atomic operation from the program's point of view. _thread.LockType objects, used by the Condition object, now have an _acquire_condition method which knows how to do it for LockType and RLock objects. Both lock types grow _release_save and _acquire_restore methods, the latter of which is a no-op. _acquire_coindition() will ignore any other kinds of locks, including subclasses (if such things exist). The result of this is a very marked improvement in signaling time on a contested machine. A file, queuetest.py is provided which measures the wakeup delay. Typical before the change: best: totaltime: 0.167006, avg delay: 0.004766, delay_stddev: 0.002058 typical: totaltime: 0.154271, avg delay: 0.027621, delay_stddev: 0.007479 after the change typical: totaltime: 0.169217, avg delay: 0.001410, delay_stddev: 0.000722 ---------- components: Interpreter Core, Library (Lib) files: condition.patch keywords: patch messages: 163423 nosy: kristjan.jonsson priority: normal severity: normal status: open title: Speed up threading.Condition wakeup type: performance versions: Python 3.3 Added file: http://bugs.python.org/file26085/condition.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Fri Jun 22 17:38:57 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 15:38:57 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340379537.07.0.723368617888.issue15139@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>: Added file: http://bugs.python.org/file26086/queuetest.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Fri Jun 22 17:42:02 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 22 Jun 2012 15:42:02 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340379722.34.0.147227186027.issue15138@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Guido, would your patch be enough?. Is a 3x improvement enough?. What improvement could be acceptable?. Implemented in C in "binascii" module? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 17:48:23 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 22 Jun 2012 15:48:23 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340380103.55.0.958085307095.issue15139@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n <jcea at jcea.es>: ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Fri Jun 22 17:58:12 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 15:58:12 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340380692.5.0.910288563839.issue15124@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Lock release (the silly saninty check) and acquisition of an uncontested lock. I was waiting for that other windows lock stuff to go in before doing this, because I thought they might actually overlap in implementation, which they didn't. I'll check this in later. Meanwhile look at the other, slightly more contentious patch, issue #15139. (condition variables are the whole reason I've been messing around with locks of late, since I had to make sure my threadpool-related HTTP requests on the PS3 performed adequately) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Fri Jun 22 17:58:33 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 15:58:33 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1340380713.46.0.142291281692.issue9527@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- stage: patch review -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Fri Jun 22 18:02:12 2012 From: report at bugs.python.org (Matt Barr) Date: Fri, 22 Jun 2012 16:02:12 +0000 Subject: [issue10592] pprint module doesn't work well with OrderedDicts In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za> Message-ID: <1340380932.05.0.655650706712.issue10592@psf.upfronthosting.co.za> Changes by Matt Barr <marr75 at gmail.com>: ---------- nosy: +Matt.Barr _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10592> _______________________________________ From report at bugs.python.org Fri Jun 22 18:03:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 16:03:19 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340380999.31.0.672820268985.issue15139@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I think this should wait for 3.4. It's a bit too late now. ---------- nosy: +pitrou, sbt stage: -> patch review versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Fri Jun 22 18:09:46 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 22 Jun 2012 16:09:46 +0000 Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za> Message-ID: <1340381386.34.0.405397589629.issue15083@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15083> _______________________________________ From report at bugs.python.org Fri Jun 22 18:09:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 22 Jun 2012 16:09:59 +0000 Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a list In-Reply-To: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za> Message-ID: <1340381399.57.0.198188536101.issue15132@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti, michael.foord _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15132> _______________________________________ From report at bugs.python.org Fri Jun 22 18:13:14 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Jun 2012 16:13:14 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340381594.48.0.8347927146.issue15136@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- assignee: -> rhettinger _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 18:13:42 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 16:13:42 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340381622.5.0.952018137171.issue15139@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: aw, that's too bad. Since this is not a feature implementat, we have the entire beta cycle to shake out any possible bugs. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Fri Jun 22 18:14:47 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Jun 2012 16:14:47 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340381687.58.0.0764530388177.issue15136@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 18:21:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 16:21:04 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340381622.5.0.952018137171.issue15139@psf.upfronthosting.co.za> Message-ID: <1340381853.3366.44.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > aw, that's too bad. Since this is not a feature implementat, we have > the entire beta cycle to shake out any possible bugs. We treat performance improvements as new features, though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Fri Jun 22 18:26:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 16:26:18 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <E1Si6gZ-0005Cy-SQ@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 88a5f2730579 by Alexander Belopolsky in branch 'default': Issue #9527: datetime.astimezone() method will now supply a class http://hg.python.org/cpython/rev/88a5f2730579 New changeset 336c53c1f547 by Alexander Belopolsky in branch 'default': Issue #9527: datetime.astimezone() method will now supply a class http://hg.python.org/cpython/rev/336c53c1f547 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Fri Jun 22 18:28:26 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Jun 2012 16:28:26 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340382506.47.0.238943683155.issue15138@psf.upfronthosting.co.za> Guido van Rossum <guido at python.org> added the comment: Why would it be a feature? There is no change in semantics, only in speed. Do we have a policy that forbids performance enhancements in bugfix releases? (It doesn't really matter, I'm just curious. Also, if it really was a feature request, it couldn't be introduced once the 3.3 beta has started, which would strike me as silly.) Anyway, I don't think my hack should be applied literally; I was more thinking of memoizing the translation table and inlining the _translate call. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 18:33:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 16:33:13 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <E1Si6nG-0005sl-CE@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset de2a0cb6ba52 by Jesus Cea in branch 'default': Closes #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/de2a0cb6ba52 ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Fri Jun 22 18:38:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 16:38:01 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340383081.65.0.30508471919.issue15138@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Do we have a policy that forbids performance enhancements in bugfix > releases? Yes, except when it fixes a regression. I don't know where that policy is codified, but it seems quite ingrained. It also means the window for getting it in 3.3 is getting narrow, the beta being so soon :) ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 18:45:34 2012 From: report at bugs.python.org (Jon Clements) Date: Fri, 22 Jun 2012 16:45:34 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340383534.42.0.023447626891.issue15136@psf.upfronthosting.co.za> Jon Clements <joncle at googlemail.com> added the comment: The more I think about this - the shades of grey kick in. D.from_fraction(F or creatable F) Then it would be 'reasonable to assume' for a F.to_decimal() to exist. Possibly with an optional context argument. Then, what happens if I do D('2.45') * F(24 / 19)... I'll leave it to the experts, but have noticed Raymond has ideas for this, but not yet commented? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Fri Jun 22 18:48:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 16:48:31 +0000 Subject: [issue7582] Use ISO timestamp in diff.py In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za> Message-ID: <E1Si721-0007bS-R5@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset ec95b94ea831 by Alexander Belopolsky in branch 'default': Issue #7582: Use ISO timestamp in diff.py http://hg.python.org/cpython/rev/ec95b94ea831 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7582> _______________________________________ From report at bugs.python.org Fri Jun 22 18:55:24 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Jun 2012 16:55:24 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340384124.4.0.741475483433.issue15138@psf.upfronthosting.co.za> Guido van Rossum <guido at python.org> added the comment: Here's a patch. It makes urlsafe_b64{en,de}code about 4x faster on my machine. The tests in base64_test.py still pass. ---------- keywords: +patch Added file: http://bugs.python.org/file26087/base64.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 18:58:21 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 16:58:21 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340384301.78.0.234111528975.issue15139@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: hm, still one more day. It will be a pity to wait two more years, perhaps Georg is feeling lucky :) ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Fri Jun 22 19:03:57 2012 From: report at bugs.python.org (hhas) Date: Fri, 22 Jun 2012 17:03:57 +0000 Subject: [issue15116] remove out-of-date Mac application scripting documentation In-Reply-To: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za> Message-ID: <1340384637.34.0.379457759527.issue15116@psf.upfronthosting.co.za> hhas <hhas at users.sourceforge.net> added the comment: @Ned: The whole page has been needing updated for years, but no-one's ever quite managed to complete it. In that light, might I suggest a two-step approach? 1. Edit the existing text now to remove all the obsolete info (e.g. section 4.1.2. is also defunct) and check in those changes before end of this month. 2. Develop whatever shiny new content you think is needed at your leisure. That way, if step 2 takes longer than expected (and creating new material always does), at least the current errors won't appear in the next release. The update to the OSA page can also be done immediately, as that's just a straight text deletion. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15116> _______________________________________ From report at bugs.python.org Fri Jun 22 19:04:55 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 22 Jun 2012 17:04:55 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1340384695.42.0.325414563765.issue14591@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Raymond, can this patch be applied? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14591> _______________________________________ From report at bugs.python.org Fri Jun 22 19:11:05 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jun 2012 17:11:05 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340385065.62.0.578825089619.issue15138@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: $ ./python -m timeit -s "from base64 import urlsafe_b64encode; url=bytes(range(256))" "urlsafe_b64encode(url)" 10000 loops, best of 3: 73.5 usec per loop $ ./python -m timeit -s "from base64 import b64encode; url=bytes(range(256))" "b64encode(url).replace(b'+', b'-').replace(b'/', b'_')" 100000 loops, best of 3: 18.9 usec per loop $ ./python -m timeit -s "from base64 import b64encode; url=bytes(range(256)); tr=bytes.maketrans(b'+/', b'-_')" "b64encode(url).translate(tr)" 100000 loops, best of 3: 15.6 usec per loop ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 19:19:43 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Jun 2012 17:19:43 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340385583.79.0.893146731785.issue15138@psf.upfronthosting.co.za> Guido van Rossum <guido at python.org> added the comment: Heh. I'd forgotten about maketrans. Here's a patch that kills the _translate() helper function completely. ---------- Added file: http://bugs.python.org/file26088/base64.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 19:26:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jun 2012 17:26:02 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340385962.53.0.231207340965.issue15138@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: You're faster than me. I think that asserts should be replaced by if/raise. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 19:27:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 17:27:51 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <E1Si7e5-0006DU-6p@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset a7237f157625 by Alexander Belopolsky in branch 'default': Issue #9527: Fixes for platforms without tm_zone http://hg.python.org/cpython/rev/a7237f157625 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Fri Jun 22 19:28:38 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Jun 2012 17:28:38 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340385962.53.0.231207340965.issue15138@psf.upfronthosting.co.za> Message-ID: <CAP7+vJJm-Bf-O47iMjuvKke_pk9gxODcCJFjO08p3h3AXCVpgQ@mail.gmail.com> Guido van Rossum <guido at python.org> added the comment: I didn't touch that assert. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 19:28:53 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 22 Jun 2012 17:28:53 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340386133.45.0.171565483216.issue4489@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Here is my revised patch with Martin's code integrated. Differences: - fixed docs - added some tests, test_on_errors could still use some refactorings though - renamed _rmtree_safe to _rmtree_safe_fd so we can implement more of them - _rmtree_safe_fd & _rmtree_unsafe don't need default arguments and the unsafe version also doesn't need argument normalization as both get onerror filled out by rmtree. If nobody objects, I'd commit it soonish (definitely before Sunday). ---------- Added file: http://bugs.python.org/file26089/mvl-revisited-plus-docs.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Fri Jun 22 19:37:08 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 22 Jun 2012 17:37:08 +0000 Subject: [issue15121] devguide doesn't document all bug tracker components In-Reply-To: <1340275042.61.0.991678411408.issue15121@psf.upfronthosting.co.za> Message-ID: <1340386628.86.0.883528506594.issue15121@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15121> _______________________________________ From report at bugs.python.org Fri Jun 22 19:37:39 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 17:37:39 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1340386659.68.0.914967028611.issue9527@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Fri Jun 22 19:37:53 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 17:37:53 +0000 Subject: [issue7582] Use ISO timestamp in diff.py In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za> Message-ID: <1340386673.64.0.432898359675.issue7582@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7582> _______________________________________ From report at bugs.python.org Fri Jun 22 19:39:45 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 17:39:45 +0000 Subject: [issue13556] When tzinfo.utcoffset is out-of-bounds, the exception message is misleading In-Reply-To: <1323364991.44.0.541305100354.issue13556@psf.upfronthosting.co.za> Message-ID: <1340386785.04.0.889274633071.issue13556@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Fixed in changeset a7237f157625. ---------- resolution: -> fixed status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13556> _______________________________________ From report at bugs.python.org Fri Jun 22 19:48:20 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 22 Jun 2012 17:48:20 +0000 Subject: [issue15125] argparse: positional arguments containing - in name not handled well In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za> Message-ID: <1340387300.68.0.824884414278.issue15125@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15125> _______________________________________ From report at bugs.python.org Fri Jun 22 19:50:05 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 17:50:05 +0000 Subject: [issue5023] Segfault in datetime.time.strftime("%z") In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za> Message-ID: <1340387405.74.0.8151485711.issue5023@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Since no one is able to reproduce this crash, I am going to close this issue. ---------- status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5023> _______________________________________ From report at bugs.python.org Fri Jun 22 19:58:13 2012 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 22 Jun 2012 17:58:13 +0000 Subject: [issue8355] diff.py produce unified format by default In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za> Message-ID: <1340387893.59.0.235828599078.issue8355@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: Reopening for Python 3. Does anybody still use context diffs nowadays? ---------- status: closed -> open versions: +Python 3.3 -Python 2.7, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8355> _______________________________________ From report at bugs.python.org Fri Jun 22 20:00:30 2012 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 22 Jun 2012 18:00:30 +0000 Subject: [issue7582] Use ISO timestamp in diff.py In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za> Message-ID: <1340388030.82.0.949597856782.issue7582@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: Thanks. I am glad OS TZ support finally issue took off. =) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7582> _______________________________________ From report at bugs.python.org Fri Jun 22 20:11:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 18:11:27 +0000 Subject: [issue15140] PEP 384 inconsistent with implementation Message-ID: <1340388687.85.0.64744522039.issue15140@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: In PEP 384, the PyType_Spec struct has a "const char *doc" that is not present in the implementation (Include/object.h). ---------- assignee: docs at python components: Documentation messages: 163449 nosy: docs at python, loewis, pitrou priority: normal severity: normal stage: needs patch status: open title: PEP 384 inconsistent with implementation type: behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15140> _______________________________________ From report at bugs.python.org Fri Jun 22 20:19:07 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 22 Jun 2012 18:19:07 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1340389147.91.0.57207195705.issue15112@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15112> _______________________________________ From report at bugs.python.org Fri Jun 22 20:20:01 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 22 Jun 2012 18:20:01 +0000 Subject: [issue8355] diff.py produce unified format by default In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za> Message-ID: <1340389201.47.0.465961025406.issue8355@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: The reasons for rejecting this still apply. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8355> _______________________________________ From report at bugs.python.org Fri Jun 22 20:27:25 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 22 Jun 2012 18:27:25 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <1340389645.9.0.0323898925464.issue15114@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- stage: needs patch -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Fri Jun 22 20:28:12 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 22 Jun 2012 18:28:12 +0000 Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za> Message-ID: <1340389692.93.0.262920737001.issue15083@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15083> _______________________________________ From report at bugs.python.org Fri Jun 22 20:28:38 2012 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 22 Jun 2012 18:28:38 +0000 Subject: [issue8355] diff.py produce unified format by default In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za> Message-ID: <1340389718.54.0.468660050085.issue8355@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: > The reasons for rejecting this still apply. Which specifically are valid for 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8355> _______________________________________ From report at bugs.python.org Fri Jun 22 20:31:28 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 18:31:28 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1340389888.22.0.0130007485963.issue10941@psf.upfronthosting.co.za> Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>: ---------- assignee: -> belopolsky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10941> _______________________________________ From report at bugs.python.org Fri Jun 22 20:36:55 2012 From: report at bugs.python.org (Pat) Date: Fri, 22 Jun 2012 18:36:55 +0000 Subject: [issue15141] IDLE horizontal scroll bar missing (Win-XPsp3) Message-ID: <1340390215.85.0.455282030507.issue15141@psf.upfronthosting.co.za> New submission from Pat <pasqualejr at ymail.com>: There is no horizontal scroll bar at the bottom of the IDLE editor window. When a program line exceeds the window area, the window has to be widened, or text has to be manually selected beyond the window to see or edit that portion of the line. No major problem, just a minor inconvenience. Even with this bug, IDLE is still a great editor. Thank you. Pat ---------- components: IDLE messages: 163452 nosy: NyteHawk priority: normal severity: normal status: open title: IDLE horizontal scroll bar missing (Win-XPsp3) versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15141> _______________________________________ From report at bugs.python.org Fri Jun 22 20:40:34 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 22 Jun 2012 18:40:34 +0000 Subject: [issue1644987] ./configure --prefix=/ breaks, won't build C modules Message-ID: <1340390434.79.0.856787384371.issue1644987@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Closing, since this is ancient. Please, open a new bug if still relevant (for 2.7, 3.2 or 3.3). ---------- assignee: tarek -> serwy nosy: +serwy resolution: -> out of date status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1644987> _______________________________________ From report at bugs.python.org Fri Jun 22 20:40:43 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 18:40:43 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340390443.65.0.652653305474.issue444582@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Added some review comments on latest patch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 20:44:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 18:44:56 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <E1Si8qk-0000Bs-U7@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset dfc7fd24983a by Kristjan Valur Jonsson in branch 'default': Issue #15124: Optimize _thread.LockType deletion and acquisition when http://hg.python.org/cpython/rev/dfc7fd24983a ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Fri Jun 22 20:45:45 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 22 Jun 2012 18:45:45 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340390745.15.0.54637559362.issue15124@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>: ---------- stage: -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Fri Jun 22 20:45:58 2012 From: report at bugs.python.org (Nicu Stiurca) Date: Fri, 22 Jun 2012 18:45:58 +0000 Subject: [issue15125] argparse: positional arguments containing - in name not handled well In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za> Message-ID: <1340390758.12.0.304985675613.issue15125@psf.upfronthosting.co.za> Nicu Stiurca <supernic2002 at gmail.com> added the comment: Re-selecting Python 2.6 under version (I think it was accidentally unselected). Here as another related error: if I try to add dest="baz" to the a.add_argument() call, it throws ValueError: dest supplied twice for positional argument ---------- versions: +Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15125> _______________________________________ From report at bugs.python.org Fri Jun 22 20:49:11 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 18:49:11 +0000 Subject: [issue15125] argparse: positional arguments containing - in name not handled well In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za> Message-ID: <1340390951.86.0.165469329506.issue15125@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Nope, it was intentionally unselected. We use versions for the versions in which we will fix the bug, and 2.6 gets only security patches at this point. In any case, argparse isn't part of the stdlib in 2.6. ---------- versions: -Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15125> _______________________________________ From report at bugs.python.org Fri Jun 22 20:51:56 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 18:51:56 +0000 Subject: [issue1644987] ./configure --prefix=/ breaks, won't build C modules Message-ID: <1340391116.56.0.161187960564.issue1644987@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I took the five minutes to test this. It does not fail in 2.7. I remember we fixed some other issues with '-prefix=/', so I presume this got fixed at that time as a byproduct. Either that, or it was a Fedora bug of some sort. ---------- assignee: serwy -> nosy: +r.david.murray resolution: out of date -> fixed stage: test needed -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1644987> _______________________________________ From report at bugs.python.org Fri Jun 22 20:56:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 18:56:57 +0000 Subject: [issue14785] Add sys._debugmallocstats() In-Reply-To: <1336776030.63.0.471450530302.issue14785@psf.upfronthosting.co.za> Message-ID: <E1Si92O-0001Nj-6m@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset d63a80abfbec by David Malcolm in branch 'default': Issue #14785: Add sys._debugmallocstats() to help debug low-level memory allocation issues http://hg.python.org/cpython/rev/d63a80abfbec ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14785> _______________________________________ From report at bugs.python.org Fri Jun 22 20:58:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 22 Jun 2012 18:58:03 +0000 Subject: [issue15140] PEP 384 inconsistent with implementation In-Reply-To: <1340388687.85.0.64744522039.issue15140@psf.upfronthosting.co.za> Message-ID: <1340391483.86.0.232411626457.issue15140@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: It's a bug in the PEP: users need to provide the module documentation through Py_tp_doc (which actually is mentioned in the PEP). I'll fix it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15140> _______________________________________ From report at bugs.python.org Fri Jun 22 21:00:17 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 19:00:17 +0000 Subject: [issue15125] argparse: positional arguments containing - in name not handled well In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za> Message-ID: <1340391617.67.0.148859762138.issue15125@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Oh, and to make sure your second report doesn't get lost, could you open another issue for the other bug, and give a complete example? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15125> _______________________________________ From report at bugs.python.org Fri Jun 22 21:17:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 19:17:15 +0000 Subject: [issue14837] Better SSL errors In-Reply-To: <1337208339.28.0.379758124204.issue14837@psf.upfronthosting.co.za> Message-ID: <E1Si9Lw-0003GG-EM@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 96513d71e650 by Antoine Pitrou in branch 'default': Issue #14837: SSL errors now have `library` and `reason` attributes describing precisely what happened and in which OpenSSL submodule. http://hg.python.org/cpython/rev/96513d71e650 New changeset e193fe3d017e by Antoine Pitrou in branch 'default': Add forgotten files for #14837. http://hg.python.org/cpython/rev/e193fe3d017e ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14837> _______________________________________ From report at bugs.python.org Fri Jun 22 21:21:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 19:21:54 +0000 Subject: [issue14837] Better SSL errors In-Reply-To: <1337208339.28.0.379758124204.issue14837@psf.upfronthosting.co.za> Message-ID: <1340392914.4.0.891327311651.issue14837@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: There it is, Georg :) As mentioned in the commit message, this unfortunately creates a reference leak, which is apparently related to the use of the stable ABI. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14837> _______________________________________ From report at bugs.python.org Fri Jun 22 21:22:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jun 2012 19:22:53 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1340392973.52.0.894129608243.issue14626@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: > > http://bugs.python.org/review/14626/diff/5182/Doc/library/os.rst#newcode1210 > Doc/library/os.rst:1210: using it will raise a > :exc:`NotImplementedError`. > Same as above: would it make sense to ignore the arg if follow_symlinks > is not supported, but the fact is irrelevant because the system doesn't > support symlinks at all? And what if the system supports symlink and doesn't support at-functions, follow_symlinks=False and file is not symlink. Should it be NotImplementedError? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Fri Jun 22 21:36:09 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 22 Jun 2012 19:36:09 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1340393769.13.0.256711082104.issue9527@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: This patch breaks OpenIndiana buildbots. For instance http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/3810/steps/test/logs/stdio """ FAIL: test_astimezone_default_eastern (test.datetimetester.TestDateTimeTZ_Pure) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/support.py", line 1139, in inner return func(*args, **kwds) File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/datetimetester.py", line 3286, in test_astimezone_default_eastern self.assertEqual(local.strftime("%z %Z"), "+0500 EST") AssertionError: '-0500 EST' != '+0500 EST' - -0500 EST ? ^ + +0500 EST ? ^ """ ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Fri Jun 22 21:38:55 2012 From: report at bugs.python.org (Brian Curtin) Date: Fri, 22 Jun 2012 19:38:55 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340393935.53.0.557025009326.issue444582@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: Attached is a patch which fixes your review comments in Lib/shutil.py, and it makes an adjustment in the wording of the documentation. The documentation is a bit more strong in wording that the current directory is always prepended to the path whether its a provided path or the default value. I don't know that the PATHEXT mentions should go much further than saying that it's checked, and then showing what it does by example. We always need to check the PATHEXT variable because it tells us what the accepted executable extensions are that the system will recognize. On my system, it's ".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.RB;.RBW", so the command prompt allows me to type "python" and it'll search that list, search the path, and find "python.exe" at C:\Python33. It's something we need to check no matter what the `path` situation is, default or passed in. ---------- Added file: http://bugs.python.org/file26090/issue444582_v4.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 21:39:25 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 19:39:25 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1340393769.13.0.256711082104.issue9527@psf.upfronthosting.co.za> Message-ID: <CAP7h-xYxHFGfugfNA3KAevqqmC3bFd=Sgzi+6EEx1ZitMHv-yw@mail.gmail.com> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Working on this. It turns out tm_gmtoff uses the opposite sign to that of timezone in time.h. For more confusion, consider this: $ TZ=EST+5 date +%z -0500 I am rechecking all UTC offset signs. On Fri, Jun 22, 2012 at 3:36 PM, Jes?s Cea Avi?n <report at bugs.python.org> wrote: > > Jes?s Cea Avi?n <jcea at jcea.es> added the comment: > > This patch breaks OpenIndiana buildbots. For instance > > http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/3810/steps/test/logs/stdio > > """ > FAIL: test_astimezone_default_eastern (test.datetimetester.TestDateTimeTZ_Pure) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/support.py", line 1139, in inner > ? ?return func(*args, **kwds) > ?File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/datetimetester.py", line 3286, in test_astimezone_default_eastern > ? ?self.assertEqual(local.strftime("%z %Z"), "+0500 EST") > AssertionError: '-0500 EST' != '+0500 EST' > - -0500 EST > ? ^ > + +0500 EST > ? ^ > """ > > ---------- > nosy: +jcea > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue9527> > _______________________________________ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Fri Jun 22 21:42:24 2012 From: report at bugs.python.org (Christian Heimes) Date: Fri, 22 Jun 2012 19:42:24 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340394144.93.0.511357659182.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: In order to get the patch in before the beta release I'm willing to drop the promise and document that the function may leak some information if the arguments differ in length or the arguments' types are incompatible. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 22 21:50:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 19:50:54 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340394144.93.0.511357659182.issue15061@psf.upfronthosting.co.za> Message-ID: <1340394443.3366.79.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > In order to get the patch in before the beta release I'm willing to > drop the promise and document that the function may leak some > information if the arguments differ in length or the arguments' types > are incompatible. That's not a problem to me. Programming errors are not the nominal case. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Fri Jun 22 21:56:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 19:56:07 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec Message-ID: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: The following patch seems to fix the issue explained in http://mail.python.org/pipermail/python-dev/2012-June/120659.html : diff --git a/Objects/typeobject.c b/Objects/typeobject.c --- a/Objects/typeobject.c +++ b/Objects/typeobject.c @@ -2417,6 +2417,10 @@ PyType_FromSpec(PyType_Spec *spec) if (res->ht_type.tp_dictoffset) { res->ht_cached_keys = _PyDict_NewKeysForClass(); } + if (res->ht_type.tp_dealloc == NULL) { + /* It's a heap type, so needs the heap types' dealloc */ + res->ht_type.tp_dealloc = subtype_dealloc; + } if (PyType_Ready(&res->ht_type) < 0) goto fail; ---------- components: Interpreter Core messages: 163470 nosy: loewis, pitrou priority: normal severity: normal stage: patch review status: open title: Fix reference leak with types created using PyType_FromSpec type: resource usage versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Fri Jun 22 21:58:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 19:58:21 +0000 Subject: [issue15143] Windows compile errors Message-ID: <1340395101.67.0.466421051649.issue15143@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: The Windows buildbot are broken, they don't compile anymore. The errors seem to be: [...] ResourceCompile: C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /l"0x0409" /I..\PC /I..\Include /nologo /fo"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\Win32-temp-Debug\pylauncher\pylauncher.res" ..\PC\pylauncher.rc ..\PC\pylauncher.rc(9): fatal error RC1015: cannot open include file 'pythonnt_rc.h'. [d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\pylauncher.vcxproj] [...] ResourceCompile: C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /D _UNICODE /D UNICODE /l"0x0409" /I..\PC /I..\Include /nologo /fo"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\Win32-temp-Debug\pywlauncher\pylauncher.res" ..\PC\pylauncher.rc ..\PC\pylauncher.rc(9): fatal error RC1015: cannot open include file 'pythonnt_rc.h'. [d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\pywlauncher.vcxproj] (see e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6892/steps/compile/logs/stdio ) ---------- components: Windows messages: 163471 nosy: georg.brandl, loewis, pitrou priority: release blocker severity: normal status: open title: Windows compile errors type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15143> _______________________________________ From report at bugs.python.org Fri Jun 22 21:59:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 19:59:15 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <E1SiA0g-0007Fs-0q@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 40d7869501a2 by Larry Hastings in branch 'default': Issue #14769: Incorporated mildly pedantic feedback from python-dev. http://hg.python.org/cpython/rev/40d7869501a2 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14769> _______________________________________ From report at bugs.python.org Fri Jun 22 22:02:49 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jun 2012 20:02:49 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. Message-ID: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: In unicodeobject.c and stringlib aligned addresses and sizes are used for optimization. pointer->integer and implicit integer->integer conversions may overflow or underflow on platforms with sizeof(size_t) != sizeof(void *) or sizeof(size_t) != sizeof(int). The proposed patch fixes such unsafe things in unicodeobject.c, stringlib and some other files. There are still a few unsafe places in libffi, but in this library Py_uintptr_t nor uintptr_t are not available. ---------- components: Interpreter Core files: align_operations.patch keywords: patch messages: 163473 nosy: storchaka priority: normal severity: normal status: open title: Possible integer overflow in operations with addresses and sizes. type: security versions: Python 3.3 Added file: http://bugs.python.org/file26091/align_operations.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15144> _______________________________________ From report at bugs.python.org Fri Jun 22 22:03:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 20:03:19 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340395399.77.0.711424505434.issue15102@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Now that my buildbot is up and building (and failing at that) could > these changes be committed? Well, it would be nice if you could post an updated patch after the comments above. (I'm not saying I'm gonna commit, since I'm not a Windows expert, but it will certainly help other core developers review it) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Fri Jun 22 22:03:22 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 22 Jun 2012 20:03:22 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1340395402.72.0.869518362942.issue15144@psf.upfronthosting.co.za> Changes by Mark Dickinson <dickinsm at gmail.com>: ---------- nosy: +mark.dickinson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15144> _______________________________________ From report at bugs.python.org Fri Jun 22 22:07:26 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 22 Jun 2012 20:07:26 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340395646.97.0.405839643992.issue15138@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Antoine thinks so: http://bugs.python.org/issue15139 :-) I think we should have an official policy, though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 22:09:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 20:09:58 +0000 Subject: [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <E1SiAB3-0008E3-24@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 0f0e3ec22fce by Alexander Belopolsky in branch 'default': Issue #9527: tm_gmtoff has 'correct' sign. http://hg.python.org/cpython/rev/0f0e3ec22fce ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9527> _______________________________________ From report at bugs.python.org Fri Jun 22 22:11:40 2012 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 22 Jun 2012 20:11:40 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340395900.98.0.972838550721.issue15008@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: New patch - pep362.8.patch One big change (Guido's request) - No more AttributeErrors on missing Parameter.default of Signature.return_annotation. They now will be set to Parameter.empty & Signature.empty correspondingly. ---------- Added file: http://bugs.python.org/file26092/pep362.8.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Fri Jun 22 22:20:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 20:20:20 +0000 Subject: [issue15143] Windows compile errors In-Reply-To: <1340395101.67.0.466421051649.issue15143@psf.upfronthosting.co.za> Message-ID: <E1SiAL3-0000rJ-VV@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset f59e6cc3d5eb by Martin v. L?wis in branch 'default': Issue #15143: Define _DEBUG when compiling resources. http://hg.python.org/cpython/rev/f59e6cc3d5eb ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15143> _______________________________________ From report at bugs.python.org Fri Jun 22 22:47:06 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 20:47:06 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340398026.58.0.348142340651.issue444582@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I'm fine with this version going in, but I don't understand what you are saying about PATHEXT. You are getting it from the environment, but you say the shell always looks at the extension. So if someone has changed PATHEXT in their environment, Windows ignores it and does the associations it knows about anyway? That is, PATHEXT is purely informational and changing it has no effect (other than to confuse things)? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 22:51:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jun 2012 20:51:58 +0000 Subject: [issue15145] Faster *_find_max_char Message-ID: <1340398318.47.0.89388206382.issue15145@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: Here is patch that speed up *_find_max_char stringlib functions. Microbenchmarks: ./python -m timeit -s "s='A'*20+'\x80'" "s[:-1]" ./python -m timeit -s "s='A'*20+'\U00010000'" "s[:-1]" Results on Intel Atom N570 @ 1.66GHz: vanilla patched 0.819 0.73 0.788 0.755 ---------- components: Interpreter Core files: find_max_char.patch keywords: patch messages: 163480 nosy: storchaka priority: normal severity: normal status: open title: Faster *_find_max_char type: performance versions: Python 3.3 Added file: http://bugs.python.org/file26093/find_max_char.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15145> _______________________________________ From report at bugs.python.org Fri Jun 22 22:57:38 2012 From: report at bugs.python.org (Brian Curtin) Date: Fri, 22 Jun 2012 20:57:38 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340398658.99.0.162669627447.issue444582@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: I don't know. It makes sense to me. I'll try to find someone else to look at it and adjust it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:01:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 21:01:04 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340398864.55.0.459972121596.issue444582@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I don't really understand why you call abspath(). If the caller wants an absolute path, they can call abspath() themselves. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:02:57 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 22 Jun 2012 21:02:57 +0000 Subject: [issue14785] Add sys._debugmallocstats() In-Reply-To: <1336776030.63.0.471450530302.issue14785@psf.upfronthosting.co.za> Message-ID: <1340398977.77.0.816090877613.issue14785@psf.upfronthosting.co.za> Changes by Dave Malcolm <dmalcolm at redhat.com>: ---------- keywords: -needs review resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14785> _______________________________________ From report at bugs.python.org Fri Jun 22 23:03:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 21:03:41 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <E1SiB11-0004ja-AF@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 0fe7439e470c by Brian Curtin in branch 'default': Fix #444582. Add shutil.which function for finding programs on the system path. http://hg.python.org/cpython/rev/0fe7439e470c ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:06:00 2012 From: report at bugs.python.org (Brian Curtin) Date: Fri, 22 Jun 2012 21:06:00 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340399160.17.0.99088607093.issue444582@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: > I don't really understand why you call abspath(). If the caller wants an absolute path, they can call abspath() themselves. Because that is what `which` does. I just pushed the change before I saw this message, so it went in as the patch shows. Do you want this changed? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:09:31 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 21:09:31 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340399371.15.0.912354411906.issue444582@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I think it would be more surprising if by default it did something different than what the 'which' command does. It also seems like the most useful result to return by default. If there's demand for a non-abspath version we could add that as a feature later. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:10:43 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 21:10:43 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1340399443.04.0.227551024831.issue665194@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Most of the localtime() logic is now implemented (correctly) in datetime.astimezone(). Attached patch fixes email.utils.localtime() implementation. ---------- status: closed -> open Added file: http://bugs.python.org/file26094/issue665194.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue665194> _______________________________________ From report at bugs.python.org Fri Jun 22 23:11:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 21:11:24 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which In-Reply-To: <1340399160.17.0.99088607093.issue444582@psf.upfronthosting.co.za> Message-ID: <1340399275.3366.80.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > I just pushed the change before I saw this message, so it went in as > the patch shows. Do you want this changed? Well, I think it would be better indeed. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:14:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 21:14:25 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which In-Reply-To: <1340399371.15.0.912354411906.issue444582@psf.upfronthosting.co.za> Message-ID: <1340399455.3366.83.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > I think it would be more surprising if by default it did something > different than what the 'which' command does. You know, I've never noticed that Unix `which` automatically abspathified the results (does it always? is it system-dependent? how about Windows?). > It also seems like the If there's demand for a non-abspath version we > could add that as a feature later. That sounds overkill. If which() calls abspath, then there's no way to get a non-absolute result. While if which() doesn't call abspath, the caller is free to call abspath() if they want to ensure the result is absolute. Sounds like a no-brainer to me :-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:18:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 21:18:18 +0000 Subject: [issue15145] Faster *_find_max_char In-Reply-To: <1340398318.47.0.89388206382.issue15145@psf.upfronthosting.co.za> Message-ID: <1340399898.77.0.127425297597.issue15145@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > 0.819 0.73 > 0.788 0.755 Are there any circumstances where this produces a larger speedup? I don't think a 10% improvement on a micro-benchmark is interesting at all (it's basically 0% on any real-world program). ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15145> _______________________________________ From report at bugs.python.org Fri Jun 22 23:19:39 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 21:19:39 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1340399979.55.0.359660475105.issue665194@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- components: +email nosy: +barry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue665194> _______________________________________ From report at bugs.python.org Fri Jun 22 23:25:43 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Fri, 22 Jun 2012 21:25:43 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340400343.66.0.234773838236.issue15102@psf.upfronthosting.co.za> Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>: Added file: http://bugs.python.org/file26095/5924b376d15f.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Fri Jun 22 23:26:31 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Jun 2012 21:26:31 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340400391.79.0.924935957923.issue444582@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I'm fine with it changing. Hopefully it won't introduce subtle bugs in anyone's programs :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:28:21 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 22 Jun 2012 21:28:21 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340400501.22.0.536843184719.issue13590@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: With version 2 of the patch I can bootstrap on OSX 10.5 as well (removes the dependency on subprocess, falls back on os.system instead) This also removes _binary_on_path as suggested by ?ric. The patch needs more testing: I haven't tried using the binary installers on systems with a different compiler configuration that (that is, 32-bit installer on a 10.7 system, 64-bit installer on a system without "/Developer"). It's currently about 23:30 local time, and I won't be able to continue working on this patch until tomorrow (Saterday) night (19:00 or later CEST) ---------- Added file: http://bugs.python.org/file26096/issue1390-version2.txt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Fri Jun 22 23:36:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 21:36:38 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <E1SiBWv-0007j0-2H@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 9d2fe615a400 by Antoine Pitrou in branch 'default': Issue #444582: shutil.which() respects relative paths. http://hg.python.org/cpython/rev/9d2fe615a400 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:37:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 21:37:34 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340401054.6.0.396392186631.issue444582@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: There is another small issue: it returns the normcase'd dir, which means that the case is lost under Windows. Not very serious, but cosmetically imperfect I suppose. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Fri Jun 22 23:38:39 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Jun 2012 21:38:39 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340401119.33.0.643097002419.issue15138@psf.upfronthosting.co.za> Guido van Rossum <guido at python.org> added the comment: So, can I check this into 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 23:39:43 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Jun 2012 21:39:43 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340401183.18.0.742765074361.issue15138@psf.upfronthosting.co.za> Changes by Guido van Rossum <guido at python.org>: ---------- assignee: -> gvanrossum stage: needs patch -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 23:41:24 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 22 Jun 2012 21:41:24 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340401284.85.0.493135938652.issue10142@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Looks like the FreeBSD bot fails in test_posix: ====================================================================== ERROR: test_fs_holes (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_posix.py", line 1033, in test_fs_holes self.assertEqual(i, os.lseek(fno, i, os.SEEK_DATA)) OSError: [Errno 25] Inappropriate ioctl for device ---------------------------------------------------------------------- Ran 81 tests in 1.878s ---------- nosy: +skrah _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Fri Jun 22 23:52:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 21:52:23 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340401943.81.0.957338032713.issue15138@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I haven't tested the patch, but it looks fine to me. ---------- versions: -Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Fri Jun 22 23:54:43 2012 From: report at bugs.python.org (Walter Mundt) Date: Fri, 22 Jun 2012 21:54:43 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1340402083.64.0.773456971525.issue15112@psf.upfronthosting.co.za> Walter Mundt <waltermundt at codethink.info> added the comment: Attached is a patch to fix this bug by deferring matching of nargs='*' argument against a zero-length pattern until the end of the arguments list. I believe that it ought to be maximally conservative in that it should not change the behavior of any existing parsers except in cases where it allows them to accept arguments they would previously have left unrecognized in cases like the test in the initial report. ---------- keywords: +patch Added file: http://bugs.python.org/file26097/argparse_fix_empty_nargs_star.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15112> _______________________________________ From report at bugs.python.org Fri Jun 22 23:59:38 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jun 2012 21:59:38 +0000 Subject: [issue15145] Faster *_find_max_char In-Reply-To: <1340399898.77.0.127425297597.issue15145@psf.upfronthosting.co.za> Message-ID: <1340402390.2747.34.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Are there any circumstances where this produces a larger speedup? I don't know. *_find_max_char in any case only a part of expensive functions. Even if it is optimized to zero time, this will most likely not produce a larger speedup. > I don't think a 10% improvement on a micro-benchmark is interesting at all (it's basically 0% on any real-world program). I agree. It is rather a question of purity. In my opinion the function has become easier (for developer and for compiler). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15145> _______________________________________ From report at bugs.python.org Sat Jun 23 00:03:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 22:03:06 +0000 Subject: [issue15145] Faster *_find_max_char In-Reply-To: <1340398318.47.0.89388206382.issue15145@psf.upfronthosting.co.za> Message-ID: <1340402586.17.0.571899669675.issue15145@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- priority: normal -> low stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15145> _______________________________________ From report at bugs.python.org Sat Jun 23 00:19:48 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 22 Jun 2012 22:19:48 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1340403588.15.0.0725455191299.issue15138@psf.upfronthosting.co.za> Guido van Rossum <guido at python.org> added the comment: Submitted. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15138> _______________________________________ From report at bugs.python.org Sat Jun 23 00:20:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 22:20:14 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <E1SiCD6-0002yF-F3@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset d892bf410478 by Larry Hastings in branch 'default': Issue #15008: Implement PEP 362 "Signature Objects". http://hg.python.org/cpython/rev/d892bf410478 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Sat Jun 23 00:24:52 2012 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 22 Jun 2012 22:24:52 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340403892.51.0.240138025689.issue15008@psf.upfronthosting.co.za> Changes by Yury Selivanov <yselivanov at gmail.com>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Sat Jun 23 00:26:05 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 22 Jun 2012 22:26:05 +0000 Subject: [issue15008] PEP 362 "Signature Objects" reference implementation In-Reply-To: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za> Message-ID: <1340403965.25.0.730044741438.issue15008@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15008> _______________________________________ From report at bugs.python.org Sat Jun 23 00:31:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Jun 2012 22:31:57 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za> Message-ID: <1340404317.94.0.873236371585.issue14923@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Here is a patch that uses some sort of autodetection. ---------- Added file: http://bugs.python.org/file26098/decode_utf8_signed_byte-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 00:34:41 2012 From: report at bugs.python.org (Robin Schreiber) Date: Fri, 22 Jun 2012 22:34:41 +0000 Subject: [issue15146] Implemented PyType_FromSpecWithBases Message-ID: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za> New submission from Robin Schreiber <robin.schreiber at me.com>: Enhancement to the currently existing PyType_FromSpec() which creates and returns a heap type from a given spec. PyType_FromSpecWithBases() works similar to PyType_FromSpec(), however it sets the bases of the newly created heap type to the types contained inside the passed bases-tuple. This allows the programmer to reference other heap-types as base types of a new heap type. This is necessary as the slot-API, which is used for static declarations of the type-spec, currently relies on statically declared type objects as tp_base or tp_bases entries. ---------- components: Interpreter Core files: PyType_FromSpecWithBases.patch keywords: patch messages: 163502 nosy: Robin.Schreiber priority: normal severity: normal status: open title: Implemented PyType_FromSpecWithBases type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file26099/PyType_FromSpecWithBases.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15146> _______________________________________ From report at bugs.python.org Sat Jun 23 00:35:17 2012 From: report at bugs.python.org (Robin Schreiber) Date: Fri, 22 Jun 2012 22:35:17 +0000 Subject: [issue15146] Implemented PyType_FromSpecWithBases In-Reply-To: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za> Message-ID: <1340404517.13.0.721966222751.issue15146@psf.upfronthosting.co.za> Changes by Robin Schreiber <robin.schreiber at me.com>: ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15146> _______________________________________ From report at bugs.python.org Sat Jun 23 01:30:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Jun 2012 23:30:51 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <E1SiDJS-0007xg-0j@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 27f9c26fdd8b by Larry Hastings in branch 'default': Issue #14626: Large refactoring of functions / parameters in the os module. http://hg.python.org/cpython/rev/27f9c26fdd8b ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 23 01:58:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 22 Jun 2012 23:58:10 +0000 Subject: [issue15147] Remove packaging from the stdlib Message-ID: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: Eric, this is for you. If you do only one thing before the 3.3 beta, please do this. ---------- assignee: eric.araujo components: Library (Lib) messages: 163504 nosy: eric.araujo, georg.brandl, pitrou priority: release blocker severity: normal stage: needs patch status: open title: Remove packaging from the stdlib type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sat Jun 23 01:59:01 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jun 2012 23:59:01 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1340409541.02.0.556313982216.issue10941@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: I updated the fix to take advantage of resolved issue 9527. I also noticed and fixed another bug: Internaldate2tuple was using locale-dependent %b directive for strftime. ---------- Added file: http://bugs.python.org/file26100/issue10941.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10941> _______________________________________ From report at bugs.python.org Sat Jun 23 02:02:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 00:02:14 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <E1SiDno-0001T1-Qi@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 04fd8f77a58e by Larry Hastings in branch 'default': Issue #14626: Fix buildbot issues on FreeBSD (AMD64). (Fingers crossed.) http://hg.python.org/cpython/rev/04fd8f77a58e ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 23 02:07:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 00:07:37 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <E1SiDsz-0001lx-4v@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset e1e0eeb07398 by Larry Hastings in branch 'default': Issue #14626: Fix buildbot issue on x86 Tiger 3.x. http://hg.python.org/cpython/rev/e1e0eeb07398 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 23 02:56:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 00:56:09 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <E1SiEdx-0004oH-VX@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 13f5a329d5ea by Jesus Cea in branch 'default': Kernel bug in freebsd9 - #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/13f5a329d5ea ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Sat Jun 23 02:56:53 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 23 Jun 2012 00:56:53 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340413013.05.0.0913845609407.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: This looks like a bug in freebsd: http://lists.freebsd.org/pipermail/freebsd-amd64/2012-January/014332.html Since looks like a kernel bug, skipping test in that case. Committed patch. Thanks for the head-up. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Sat Jun 23 02:56:59 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 23 Jun 2012 00:56:59 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1340413019.25.0.414533141491.issue10941@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: The latest patch belongs to issue 11024. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10941> _______________________________________ From report at bugs.python.org Sat Jun 23 02:58:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 00:58:50 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <E1SiEga-0004vu-NH@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 8acaa341df53 by Jesus Cea in branch 'default': Skip the test only if neccesary - Kernel bug in freebsd9 - #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/8acaa341df53 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Sat Jun 23 03:03:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 23 Jun 2012 01:03:17 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340413397.53.0.550784194731.issue15147@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Yep, that was on my planning for tonight or tomorrow afternoon. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sat Jun 23 03:04:07 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 23 Jun 2012 01:04:07 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340413447.34.0.578596253843.issue15147@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- components: +Distutils2, Documentation nosy: +alexis, tarek stage: needs patch -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sat Jun 23 03:11:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 01:11:02 +0000 Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za> Message-ID: <E1SiEsP-0005fa-99@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 42b9d9d795f7 by Alexander Belopolsky in branch 'default': Issues #11024: Fixes and additional tests for Time2Internaldate. http://hg.python.org/cpython/rev/42b9d9d795f7 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11024> _______________________________________ From report at bugs.python.org Sat Jun 23 03:12:42 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 23 Jun 2012 01:12:42 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340413962.19.0.752395429442.issue4473@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: 3.3 beta will be published next Sunday. Any hope? Lorenzo, is your patch applicable to 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sat Jun 23 03:16:29 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 23 Jun 2012 01:16:29 +0000 Subject: [issue15148] shutul.which() docstring could be clearer Message-ID: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>: I find this a little hard to parse (ignoring the obvious typo and the grammar error): """ Given a file, mode, and a path string, return the path whichs conform to the given mode on the path. """ One other suggestion: wouldn't 'file' read better as 'command'? ---------- assignee: docs at python components: Documentation messages: 163515 nosy: docs at python, hynek, tarek, tshepang priority: normal severity: normal status: open title: shutul.which() docstring could be clearer _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 03:16:38 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 23 Jun 2012 01:16:38 +0000 Subject: [issue15148] shutul.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340414198.99.0.637572743765.issue15148@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 03:17:18 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 23 Jun 2012 01:17:18 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340414238.36.0.772138663997.issue15148@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- title: shutul.which() docstring could be clearer -> shutil.which() docstring could be clearer _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 03:27:11 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 23 Jun 2012 01:27:11 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1340414831.1.0.554642050792.issue665194@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: David, issue665194.diff patch is a bug fix for localtime(). If you decide to keep localtime(), there is not much of a rush because bug fixes can go in after beta. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue665194> _______________________________________ From report at bugs.python.org Sat Jun 23 03:56:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 01:56:48 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <E1SiFah-0008Hb-20@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 5975292ddf82 by Alexander Belopolsky in branch 'default': Issue #15148: Fixed typos in shutil.which() docstring http://hg.python.org/cpython/rev/5975292ddf82 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 04:09:47 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 23 Jun 2012 02:09:47 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340417387.28.0.761814311688.issue15148@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: *file* is correct because shutil.which() is more general than shell which command. (It can be used to find source files on PYTHONPATH, for example.) I think the confusing part is "return the path ... on the path." This can be fixed in reST by marking the second "path" as the argument, but the docstring should be rephrased. Note that reST documentation for shutil.which() is missing in Doc/library/shutil.rst. ---------- nosy: +belopolsky, brian.curtin _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 04:17:02 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 23 Jun 2012 02:17:02 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340417822.69.0.512504992354.issue15148@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: I updated file to command in 973b4806f760. It needs to be command so it matches the implementation's argument name, and because it doesn't exactly take a file. Alexander, can you explain the part about finding a file on PYTHONPATH? I don't think this has anything to do with shutil.which, or at least I have no idea how it would. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 04:25:42 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 23 Jun 2012 02:25:42 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340418342.24.0.622326963272.issue15148@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: > Alexander, can you explain the part about finding a file on PYTHONPATH? I thought about something like this: >>> shutil.which('shutil.py', os.F_OK, ':'.join(sys.path)) '/Users/sasha/Work/python-hg/py3k/Lib/shutil.py' but win32 code seems to assume a search for a command. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 04:30:13 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 23 Jun 2012 02:30:13 +0000 Subject: [issue15149] Release Schedule needs updating Message-ID: <1340418613.19.0.188267492101.issue15149@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>: I see some stuff marked 'planned' has been rejected for 3.3, while some has already been implemented. ---------- assignee: docs at python components: Documentation messages: 163521 nosy: anthonybaxter, barry, benjamin.peterson, docs at python, eric.araujo, georg.brandl, gvanrossum, lemburg, loewis, ned.deily, tarek, tshepang priority: normal severity: normal status: open title: Release Schedule needs updating versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15149> _______________________________________ From report at bugs.python.org Sat Jun 23 04:33:29 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 23 Jun 2012 02:33:29 +0000 Subject: [issue15150] Windows build does not link Message-ID: <1340418809.0.0.92215340871.issue15150@psf.upfronthosting.co.za> New submission from Brian Curtin <brian at python.org>: 6>python3.def : error LNK2001: unresolved external symbol PyState_AddModule 6>python3.def : error LNK2001: unresolved external symbol PyState_RemoveModule 6>C:\python-dev\cpython\PCbuild\python3.lib : fatal error LNK1120: 2 unresolved externals ---------- components: Build, Windows messages: 163522 nosy: brian.curtin priority: release blocker severity: normal stage: needs patch status: open title: Windows build does not link type: compile error versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15150> _______________________________________ From report at bugs.python.org Sat Jun 23 04:34:45 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 23 Jun 2012 02:34:45 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340418885.41.0.228502966136.issue15148@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Brian, Did you intend to commit Tools/msi/msi.py in changeset 973b4806f760? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 04:36:43 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 23 Jun 2012 02:36:43 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340419003.02.0.692336452913.issue15148@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: No, reverting. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 04:51:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 02:51:05 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <E1SiGRE-0002lq-Hc@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 66f7377547d5 by Larry Hastings in branch 'default': Issue #14626: Fix buildbot issue on OpenIndiana 3.x machines. (Hopefully.) http://hg.python.org/cpython/rev/66f7377547d5 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 23 05:00:23 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 23 Jun 2012 03:00:23 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1340420423.16.0.40836797982.issue14127@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Closing this, as I have now removed os.utimensat and os.futimesat. As well as os.futimens, os.futimes, and os.lutimes. And in fact retooled os.utime in a pretty major way. (See #14626.) ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14127> _______________________________________ From report at bugs.python.org Sat Jun 23 05:12:54 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 23 Jun 2012 03:12:54 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340421174.37.0.116871859627.issue4473@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- components: +email nosy: +barry, r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sat Jun 23 05:27:46 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 23 Jun 2012 03:27:46 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340422066.96.0.162093899527.issue15148@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Yeah, Brian had it as 'file' before, and I asked him to change it because it is confusing. 'file' sounds like a Python file object, which this is not. 'filename' would be OK, but 'cmd', as you note, is what it is really about. One possibility for the path confusion is to capitalize the references to the system path, since both posix and windows capitalize it.: "Given a name, mode, and PATH, return the path to the first file which conforms to the given mode found on the PATH, or None if there is no such file. mode defaults to os.F_OK|os.X_OK. PATH can be specified via the path argument, if not specified it defaults to the PATH set in the environment." ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 05:49:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 03:49:28 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <E1SiHLg-0006p5-R0@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 5f18d9d34f73 by Brian Curtin in branch 'default': Fix #15148. Make the shutil.which docstring more thorough http://hg.python.org/cpython/rev/5f18d9d34f73 New changeset aa153b827d17 by Brian Curtin in branch 'default': Fix #15148. Capitalize PATH, hopefully leading to less confusion http://hg.python.org/cpython/rev/aa153b827d17 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Sat Jun 23 05:55:16 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 23 Jun 2012 03:55:16 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1340423716.6.0.746829857651.issue3561@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: So I have a patch that does most of what my previous message shows, but I can't seem to complete it. I don't know if I'm misunderstanding something or this just can't be done, but I could use the help of someone who understands MSI things much better than I can. Attached is the patch which makes this (http://i.imgur.com/415Y1.png) screen possible. The problem is that I can't seem to hook up the Yes and No buttons to set the path feature to install or not on the next screen, the Feature selection page. http://ubuntuone.com/1GfW3hasOIDydQEAweOoKr is a link to an installer built with that patch if anyone wants to click through and it and see if it's worth adding in that form. ---------- status: closed -> open Added file: http://bugs.python.org/file26101/path_option.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3561> _______________________________________ From report at bugs.python.org Sat Jun 23 05:58:39 2012 From: report at bugs.python.org (Walter Mundt) Date: Sat, 23 Jun 2012 03:58:39 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1340423919.02.0.830569161986.issue15112@psf.upfronthosting.co.za> Changes by Walter Mundt <waltermundt at codethink.info>: ---------- components: +Library (Lib) type: -> behavior versions: +Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15112> _______________________________________ From report at bugs.python.org Sat Jun 23 06:47:54 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 04:47:54 +0000 Subject: [issue15079] pickle: Possibly misplaced test In-Reply-To: <1339778270.97.0.949730169084.issue15079@psf.upfronthosting.co.za> Message-ID: <1340426874.16.0.507737152535.issue15079@psf.upfronthosting.co.za> Changes by Terry J. Reedy <tjreedy at udel.edu>: ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15079> _______________________________________ From report at bugs.python.org Sat Jun 23 07:01:02 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 05:01:02 +0000 Subject: [issue15080] Cookie library doesn't parse date properly In-Reply-To: <1339791656.15.0.174723735856.issue15080@psf.upfronthosting.co.za> Message-ID: <1340427662.57.0.834584058175.issue15080@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Jeremy, when reporting bugs, please first check the latest release. This works in current 2.7.3 (as well as latest 2.6.8 and 3.3.0). >>> import Cookie >>> cookie = Cookie.SimpleCookie('bcookie="123"; Expires=Sat, 14-Jun-2014 23:03:13 GMT;') >>> cookie['bcookie']['expires'] 'Sat, 14-Jun-2014 23:03:13 GMT' 2.6 only gets security patches. There have been as least a thousand patches since 2.6.1 and this is one of them. ---------- nosy: +terry.reedy resolution: -> out of date status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15080> _______________________________________ From report at bugs.python.org Sat Jun 23 07:08:27 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 05:08:27 +0000 Subject: [issue15091] ImportError when package is symlinked on Unix In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za> Message-ID: <1340428107.74.0.680212361237.issue15091@psf.upfronthosting.co.za> Changes by Terry J. Reedy <tjreedy at udel.edu>: ---------- components: +Tests stage: -> test needed type: -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15091> _______________________________________ From report at bugs.python.org Sat Jun 23 07:46:14 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 05:46:14 +0000 Subject: [issue15092] Using enum PyUnicode_Kind In-Reply-To: <1339924867.59.0.117831113894.issue15092@psf.upfronthosting.co.za> Message-ID: <1340430374.33.0.0138737283291.issue15092@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Since we have defined an enum, I think we should use it consistently. (Am I correct in thinking it was added after the initial patches.) So I did a sanity check of -/+ lines for perhaps unintended changes. The only things I found to comment on, mostly somewhat picky, would *not* trigger test failures. === - int kind = PyUnicode_KIND(output); + kind = PyUnicode_KIND(output); extra space added misaligns text (for humans) === + default: assert(0); I presume this is standard elsewhere for switches and just got omitted here. - } - assert(0); - return -1; + default: + assert(0); + return -1; + } (two places) Since assert(0) always fails, return can never happen (and was not added above. So I would think remove it. And I agree with putting it consistently under default: (which is a form of else) even if not required as it improves human readability. === - int kind_self; - int kind_sub; + enum PyUnicode_Kind kind_self; + enum PyUnicode_Kind kind_sub; void *data_self; void *data_sub; Several places elsewhere, multiple enum vars are defined on one line, so you *could* do the same here (and with void *vars?). ==== - int kind1, kind2, kind; + enum PyUnicode_Kind kind1, kind2, kind; <four places> being really picky, I would put 'kind' first, not last, unless there is a good reason in the omitted context. It is mentally jarring for me as is without context. Elsewhere, things like src_/dest_/kind and x/y/z/kind are in the 'expected' order. ---------- nosy: +terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15092> _______________________________________ From report at bugs.python.org Sat Jun 23 08:00:15 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 06:00:15 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> Message-ID: <1340431215.31.0.910582474537.issue15142@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: That does look like it will fix the leak, but now I'm actually thinking there's more code from type_new that should also be executed in the PyType_FromSpec case. I mean things like: - ensuring __new__ is a static method - ensuring the standard attribute lookup machinery is configured - hooking up tp_as_number, tp_as_mapping, etc - ensuring GC support is configured correctly If that's all happening somehow, it could use a comment, because I certainly can't see it. If not, we probably need to factor out some helper functions that type_new and PyType_FromSpec can both call to make sure everything is fully configured. ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 08:01:49 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 06:01:49 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> Message-ID: <1340431309.54.0.972280838187.issue15142@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- nosy: +daniel.urban _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 08:12:56 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 23 Jun 2012 06:12:56 +0000 Subject: [issue15141] IDLE horizontal scroll bar missing (Win-XPsp3) In-Reply-To: <1340390215.85.0.455282030507.issue15141@psf.upfronthosting.co.za> Message-ID: <1340431976.87.0.399406267066.issue15141@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: Adding a horizontal scroll bar is relatively easy. This has already been done with the Horizontal.py extension as part of a separate project called IdleX. See http://idlex.sourceforge.net/extensions.html @Terry, perhaps this should be added as an enhancement to IDLE? ---------- keywords: +easy nosy: +serwy, terry.reedy type: -> enhancement versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15141> _______________________________________ From report at bugs.python.org Sat Jun 23 08:13:50 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 06:13:50 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module Message-ID: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: The PEP 362 implementation has been committed, but the inspect module documentation still needs to be updated. ---------- assignee: docs at python components: Documentation messages: 163534 nosy: docs at python, ncoghlan priority: deferred blocker severity: normal status: open title: Documentation for Signature, Parameter and signature in inspect module versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15151> _______________________________________ From report at bugs.python.org Sat Jun 23 08:48:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 06:48:08 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1340434088.79.0.936099493953.issue15104@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: As a native speaker, I agree that the sentence, in isolation, is hardly comprehensible. The previous one is also a bit flakey. The situation is that top-level code executes in a module named __main__, which has one joint global/local namespace that is the global namespace for all subsidiary contexts. '__main__':<__main__ module> is added to sys.modules before user code is executed. The name __main__ is not normally in the __main__ (global) namespace, hence the comment about 'anonymous' in the first sentence. (It is not anonymous in sys.modules.) However (1) __main__ or any other module/namespace can 'import __main__' and get the reference to __main__ from sys.modules and (2) __main__ does have name __name__ bound to the *string* '__main__'. Hence a module can discover whether or not it *is* the __main__ module. Part of the quoting confusion is that unquoted names in code become strings in namespace dicts, and hence quoted literals when referring to them as keys. What I did not realize until just now is that the __name__ attribute of a module *is* its name (key) in the module namespace (sys.modules dict). For instance, after 'import x.y' or 'from x import y', x.y.__name__ or y.__name is 'x.y' and that is its name (key) in sys.modules. So it appears that the __name__ of a package (sub)module is never just the filename (which I expected), and "__name__ is the module name" only if one considers the package name as part of the module name (which I did not). The only non-capi reference to module.__name__ in the index is 3.2. The standard type hierarchy Modules "__name__ is the module?s name" But what is the modules name? Its name in sys.modules, which is either __main__ or the full dotted name for modules in packages (as I just learned). Perhaps this could be explained better here. ---------- nosy: +terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________ From report at bugs.python.org Sat Jun 23 08:53:04 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 06:53:04 +0000 Subject: [issue15149] Release Schedule needs updating In-Reply-To: <1340418613.19.0.188267492101.issue15149@psf.upfronthosting.co.za> Message-ID: <1340434384.41.0.0946464274354.issue15149@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Updated. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15149> _______________________________________ From report at bugs.python.org Sat Jun 23 09:00:11 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 07:00:11 +0000 Subject: [issue15117] Please document top-level sqlite3 module variables In-Reply-To: <1340205684.94.0.46461654189.issue15117@psf.upfronthosting.co.za> Message-ID: <1340434811.76.0.53635221218.issue15117@psf.upfronthosting.co.za> Changes by Terry J. Reedy <tjreedy at udel.edu>: ---------- nosy: +ghaering _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15117> _______________________________________ From report at bugs.python.org Sat Jun 23 09:10:15 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 07:10:15 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340435415.7.0.702548231246.issue15118@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: (OT, but since you brought it up: In my opinion, deprecating the iterability of any builtin class is a horrible idea. It is a Python feature, especially in 3.x, that all *are* iterable. However, I would agree that named tuples should be iterable by name-object pairs, just like dicts. Position is not the real key.) ---------- nosy: +terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sat Jun 23 09:15:54 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 07:15:54 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1340435754.49.0.80643782048.issue11205@psf.upfronthosting.co.za> Changes by Terry J. Reedy <tjreedy at udel.edu>: ---------- components: +Interpreter Core -None _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11205> _______________________________________ From report at bugs.python.org Sat Jun 23 09:24:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 07:24:38 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1340436278.6.0.879914830944.issue3561@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: These things are best studied with msiexec ... /l*v python.log, then inspecting python.log. Without looking at the trace, I'd expect that the actual installation run doesn't inherit ModifyPath from the UI run. The installer runs actually twice - once in the user account, performing the UI sequence and collecting all information. Then in the context of the installer service, running the execute sequence to modify the system. Information is passed in properties. However, not all properties are passed, only secure properties (which I believe must be UPPERCASE, in addition to being listed as a secure property). However, I really recommend to not introduce another secure property, but instead use a custom action, see http://www.advancedinstaller.com/user-guide/qa-conditional-feature.html Write a VB script, and call Session.FeatureRequestState. As yet an alternative, and possibly the best one, there is an AddLocal ControlEvent, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa367537(v=vs.85).aspx Associating this event with the "Yes" button should make the feature selected. Note that you can have multiple control events for a button, so you can proceed to the next dialog after having this control event. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3561> _______________________________________ From report at bugs.python.org Sat Jun 23 09:26:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 07:26:08 +0000 Subject: [issue15121] devguide doesn't document all bug tracker components In-Reply-To: <1340275042.61.0.991678411408.issue15121@psf.upfronthosting.co.za> Message-ID: <1340436368.97.0.161245092092.issue15121@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: None has over 1300 issues, mostly old (historical). It could be removed from current use, I think (if it is possible to hide such a thing). Cross-build has just 6 issues collected together in last three months. I do not think that is really enough to justify adding it, but someone did. Mathias, can you define it? ---------- nosy: +doko, terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15121> _______________________________________ From report at bugs.python.org Sat Jun 23 09:30:18 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Jun 2012 07:30:18 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340436618.18.0.164804923404.issue15136@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: Something like Fraction.as_decimal(prec=28) would be reasonable. ---------- priority: normal -> low _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Sat Jun 23 09:32:35 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 07:32:35 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340431215.31.0.910582474537.issue15142@psf.upfronthosting.co.za> Message-ID: <20120623093223.Horde.2m5GGVNNcXdP5XEH3w-21KA@webmail.df.eu> Martin v. L?wis <martin at v.loewis.de> added the comment: > - ensuring __new__ is a static method This shouldn't be necessary. __new__ won't be a method at all, and not even exist. Instead, a type may or may not fill the tp_new slot. > - ensuring the standard attribute lookup machinery is configured This is what PyType_Ready does, no? > - hooking up tp_as_number, tp_as_mapping, etc This is indeed missing. Robin Schreiber is working on a patch. > - ensuring GC support is configured correctly This is the responsibility of the caller, as always with C types. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 09:33:04 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 07:33:04 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> Message-ID: <1340436784.8.0.528402059831.issue15142@psf.upfronthosting.co.za> Changes by Martin v. L?wis <martin at v.loewis.de>: ---------- nosy: +Robin.Schreiber _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 09:33:57 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 07:33:57 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> Message-ID: <1340436837.13.0.516990106964.issue15142@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: In any case, one issue at a time, please. This issues is about a reference leak. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 09:36:49 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 07:36:49 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340437009.21.0.221040531065.issue15136@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > Something like Fraction.as_decimal(prec=28) would be reasonable. I'd prefer an implementation of Fraction.__format__. That solves the SO user's need exactly. Note that he/she didn't care about the Decimal type, but only wanted to be able to *print* digits of a Fraction; the __format__ method is the OOWTDI. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Sat Jun 23 09:40:47 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 07:40:47 +0000 Subject: [issue15135] HOWTOs doesn't link to "Idioms and Anti-Idioms" article In-Reply-To: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za> Message-ID: <1340437247.1.0.711342551334.issue15135@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: The file is 'controversial'. The link was intentionally removed (and the file deleted and restored but not relinked, pending update) in #7391 (which was closed and re-opened). Your links do not work because the comma/period that follow are considered part of the urls. To be safe, always follow with whitespace. ---------- nosy: +terry.reedy resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15135> _______________________________________ From report at bugs.python.org Sat Jun 23 10:03:40 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 23 Jun 2012 08:03:40 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1340438620.56.0.199968059324.issue15078@psf.upfronthosting.co.za> Charles-Fran?ois Natali <neologix at free.fr> added the comment: > But at the heart of the matter, I see no benefit to exposing Python > developers to the idiosyncrasies of poor C API design. I feel strongly that > one way Python becomes "pythonic" is that it aims for the convenience of the > programmer--not the language designer and not the implementer. The Python > calling convention is far more flexible than the C calling convention. We > should put it to good use here. I agree. However, I think Martin is a proponent of the "thin wrapper" approach, so it'd be nice to have his input on this. I personally like the change, except for `flags` argument collapsing. Imagine what mmap's prototype would look like if we used list of optional arguments instead of a flag... ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sat Jun 23 10:04:45 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 23 Jun 2012 08:04:45 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1340438685.81.0.738253071933.issue15078@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali <neologix at free.fr>: ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sat Jun 23 10:11:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 08:11:08 +0000 Subject: [issue15136] Decimal accepting Fraction In-Reply-To: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za> Message-ID: <1340439068.09.0.720536176153.issue15136@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: I think *both* proposals are sensible. Fraction already has .from_decimal (using Decimal), so .to_decimal (also using Decimal) is sensible. It also has .from_float, with 'f.to_float' spelled f.__float__, normally called as float(f). On the other hand, part of the point of the new format system was/is to allow 'other' classes to tie into format specs with custom .__format__. Currently, Fraction inherits .__format__ from object, which only recognizes 's' specifications. (Anything else gives a misleading 'str' error message that is the subject of another issue.) I think it should get a custom .__format__, which could use f.to_decimal(prec), where prec is calculated from the format spec. ---------- nosy: +eric.smith, terry.reedy _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15136> _______________________________________ From report at bugs.python.org Sat Jun 23 10:13:43 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 08:13:43 +0000 Subject: [issue15092] Using enum PyUnicode_Kind In-Reply-To: <1340430374.33.0.0138737283291.issue15092@psf.upfronthosting.co.za> Message-ID: <1340439177.2747.106.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Since assert(0) always fails, return can never happen (and was not added above. So I would think remove it. This will cause a compiler warning in non-debug mode. Here is updated patch with all other comments taken into account. ---------- Added file: http://bugs.python.org/file26102/enum_PyUnicode_Kind-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15092> _______________________________________ -------------- next part -------------- diff -r aa153b827d17 Include/unicodeobject.h --- a/Include/unicodeobject.h Fri Jun 22 22:49:12 2012 -0500 +++ b/Include/unicodeobject.h Sat Jun 23 11:04:31 2012 +0300 @@ -1013,7 +1013,7 @@ ); #ifndef Py_LIMITED_API -PyAPI_FUNC(void*) _PyUnicode_AsKind(PyObject *s, unsigned int kind); +PyAPI_FUNC(void*) _PyUnicode_AsKind(PyObject *s, enum PyUnicode_Kind kind); #endif #endif diff -r aa153b827d17 Modules/_csv.c --- a/Modules/_csv.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/_csv.c Sat Jun 23 11:04:31 2012 +0300 @@ -774,7 +774,7 @@ PyObject *fields = NULL; Py_UCS4 c; Py_ssize_t pos, linelen; - unsigned int kind; + enum PyUnicode_Kind kind; void *data; PyObject *lineobj; @@ -973,7 +973,8 @@ * record length. */ static Py_ssize_t -join_append_data(WriterObj *self, unsigned int field_kind, void *field_data, +join_append_data(WriterObj *self, + enum PyUnicode_Kind field_kind, void *field_data, Py_ssize_t field_len, int quote_empty, int *quoted, int copy_phase) { @@ -1093,7 +1094,7 @@ static int join_append(WriterObj *self, PyObject *field, int *quoted, int quote_empty) { - unsigned int field_kind = -1; + enum PyUnicode_Kind field_kind = -1; void *field_data = NULL; Py_ssize_t field_len = 0; Py_ssize_t rec_len; @@ -1123,7 +1124,7 @@ join_append_lineterminator(WriterObj *self) { Py_ssize_t terminator_len, i; - unsigned int term_kind; + enum PyUnicode_Kind term_kind; void *term_data; terminator_len = PyUnicode_GET_LENGTH(self->dialect->lineterminator); diff -r aa153b827d17 Modules/_elementtree.c --- a/Modules/_elementtree.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/_elementtree.c Sat Jun 23 11:04:31 2012 +0300 @@ -869,7 +869,7 @@ if (PyUnicode_Check(tag)) { const Py_ssize_t len = PyUnicode_GET_LENGTH(tag); void *data = PyUnicode_DATA(tag); - unsigned int kind = PyUnicode_KIND(tag); + enum PyUnicode_Kind kind = PyUnicode_KIND(tag); for (i = 0; i < len; i++) { Py_UCS4 ch = PyUnicode_READ(kind, data, i); if (ch == '{') @@ -2947,7 +2947,7 @@ unsigned char s[256]; int i; void *data; - unsigned int kind; + enum PyUnicode_Kind kind; memset(info, 0, sizeof(XML_Encoding)); diff -r aa153b827d17 Modules/_io/_iomodule.h --- a/Modules/_io/_iomodule.h Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/_io/_iomodule.h Sat Jun 23 11:04:31 2012 +0300 @@ -55,7 +55,7 @@ Otherwise, the function will scan further and return garbage. */ extern Py_ssize_t _PyIO_find_line_ending( int translated, int universal, PyObject *readnl, - int kind, char *start, char *end, Py_ssize_t *consumed); + enum PyUnicode_Kind kind, char *start, char *end, Py_ssize_t *consumed); #define DEFAULT_BUFFER_SIZE (8 * 1024) /* bytes */ diff -r aa153b827d17 Modules/_io/textio.c --- a/Modules/_io/textio.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/_io/textio.c Sat Jun 23 11:04:31 2012 +0300 @@ -301,7 +301,7 @@ output_len = PyUnicode_GET_LENGTH(output); if (self->pendingcr && (final || output_len > 0)) { /* Prefix output with CR */ - int kind; + enum PyUnicode_Kind kind; PyObject *modified; char *out; @@ -311,7 +311,7 @@ goto error; kind = PyUnicode_KIND(modified); out = PyUnicode_DATA(modified); - PyUnicode_WRITE(kind, PyUnicode_DATA(modified), 0, '\r'); + PyUnicode_WRITE(kind, out, 0, '\r'); memcpy(out + kind, PyUnicode_DATA(output), kind * output_len); Py_DECREF(output); output = modified; /* output remains ready */ @@ -342,7 +342,7 @@ Py_ssize_t len; int seennl = self->seennl; int only_lf = 0; - int kind; + enum PyUnicode_Kind kind; in_str = PyUnicode_DATA(output); len = PyUnicode_GET_LENGTH(output); @@ -417,7 +417,7 @@ } else { void *translated; - int kind = PyUnicode_KIND(output); + kind = PyUnicode_KIND(output); void *in_str = PyUnicode_DATA(output); Py_ssize_t in, out; /* XXX: Previous in-place translation here is disabled as @@ -1600,7 +1600,7 @@ that is to the NUL character. Otherwise the function will produce incorrect results. */ static char * -find_control_char(int kind, char *s, char *end, Py_UCS4 ch) +find_control_char(enum PyUnicode_Kind kind, char *s, char *end, Py_UCS4 ch) { if (kind == PyUnicode_1BYTE_KIND) { assert(ch < 256); @@ -1620,7 +1620,7 @@ Py_ssize_t _PyIO_find_line_ending( int translated, int universal, PyObject *readnl, - int kind, char *start, char *end, Py_ssize_t *consumed) + enum PyUnicode_Kind kind, char *start, char *end, Py_ssize_t *consumed) { Py_ssize_t len = ((char*)end - (char*)start)/kind; @@ -1720,7 +1720,7 @@ while (1) { char *ptr; Py_ssize_t line_len; - int kind; + enum PyUnicode_Kind kind; Py_ssize_t consumed = 0; /* First, get some data if necessary */ diff -r aa153b827d17 Modules/_json.c --- a/Modules/_json.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/_json.c Sat Jun 23 11:04:31 2012 +0300 @@ -204,7 +204,7 @@ PyObject *rval; void *input; unsigned char *output; - int kind; + enum PyUnicode_Kind kind; if (PyUnicode_READY(pystr) == -1) return NULL; @@ -331,7 +331,7 @@ Py_ssize_t begin = end - 1; Py_ssize_t next /* = begin */; const void *buf; - int kind; + enum PyUnicode_Kind kind; PyObject *chunks = NULL; PyObject *chunk = NULL; @@ -613,7 +613,7 @@ Returns a new PyObject (usually a dict, but object_hook can change that) */ void *str; - int kind; + enum PyUnicode_Kind kind; Py_ssize_t end_idx; PyObject *val = NULL; PyObject *rval = NULL; @@ -755,7 +755,7 @@ Returns a new PyList */ void *str; - int kind; + enum PyUnicode_Kind kind; Py_ssize_t end_idx; PyObject *val = NULL; PyObject *rval = PyList_New(0); @@ -858,7 +858,7 @@ May return other types if parse_int or parse_float are set */ void *str; - int kind; + enum PyUnicode_Kind kind; Py_ssize_t end_idx; Py_ssize_t idx = start; int is_float = 0; @@ -975,7 +975,7 @@ */ PyObject *res; void *str; - int kind; + enum PyUnicode_Kind kind; Py_ssize_t length; if (PyUnicode_READY(pystr) == -1) diff -r aa153b827d17 Modules/_pickle.c --- a/Modules/_pickle.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/_pickle.c Sat Jun 23 11:04:31 2012 +0300 @@ -1814,7 +1814,7 @@ char *p; Py_ssize_t i, size, expandsize; void *data; - unsigned int kind; + enum PyUnicode_Kind kind; if (PyUnicode_READY(obj)) return NULL; diff -r aa153b827d17 Modules/_sqlite/connection.c --- a/Modules/_sqlite/connection.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/_sqlite/connection.c Sat Jun 23 11:04:31 2012 +0300 @@ -1440,7 +1440,7 @@ _Py_IDENTIFIER(upper); char *uppercase_name_str; int rc; - unsigned int kind; + enum PyUnicode_Kind kind; void *data; if (!pysqlite_check_thread(self) || !pysqlite_check_connection(self)) { diff -r aa153b827d17 Modules/_tkinter.c --- a/Modules/_tkinter.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/_tkinter.c Sat Jun 23 11:04:31 2012 +0300 @@ -965,7 +965,7 @@ else if (PyUnicode_Check(value)) { void *inbuf; Py_ssize_t size; - int kind; + enum PyUnicode_Kind kind; Tcl_UniChar *outbuf = NULL; Py_ssize_t i; size_t allocsize; diff -r aa153b827d17 Modules/operator.c --- a/Modules/operator.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/operator.c Sat Jun 23 11:04:31 2012 +0300 @@ -403,7 +403,7 @@ PyObject *item = PyTuple_GET_ITEM(args, idx); Py_ssize_t item_len; void *data; - unsigned int kind; + enum PyUnicode_Kind kind; int dot_count; if (!PyUnicode_Check(item)) { diff -r aa153b827d17 Modules/pyexpat.c --- a/Modules/pyexpat.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/pyexpat.c Sat Jun 23 11:04:31 2012 +0300 @@ -1102,7 +1102,7 @@ PyUnicodeObject *_u_string = NULL; int result = 0; int i; - int kind; + enum PyUnicode_Kind kind; void *data; /* Yes, supports only 8bit encodings */ diff -r aa153b827d17 Modules/unicodedata.c --- a/Modules/unicodedata.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Modules/unicodedata.c Sat Jun 23 11:04:31 2012 +0300 @@ -497,7 +497,7 @@ PyObject *result; Py_UCS4 *output; Py_ssize_t i, o, osize; - int kind; + enum PyUnicode_Kind kind; void *data; /* Longest decomposition in Unicode 3.2: U+FDFA */ Py_UCS4 stack[20]; @@ -637,7 +637,7 @@ nfc_nfkc(PyObject *self, PyObject *input, int k) { PyObject *result; - int kind; + enum PyUnicode_Kind kind; void *data; Py_UCS4 *output; Py_ssize_t i, i1, o, len; @@ -773,7 +773,7 @@ is_normalized(PyObject *self, PyObject *input, int nfc, int k) { Py_ssize_t i, len; - int kind; + enum PyUnicode_Kind kind; void *data; unsigned char prev_combining = 0, quickcheck_mask; diff -r aa153b827d17 Objects/bytearrayobject.c --- a/Objects/bytearrayobject.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Objects/bytearrayobject.c Sat Jun 23 11:04:31 2012 +0300 @@ -2692,7 +2692,7 @@ Py_ssize_t hexlen, byteslen, i, j; int top, bot; void *data; - unsigned int kind; + enum PyUnicode_Kind kind; if (!PyArg_ParseTuple(args, "U:fromhex", &hexobj)) return NULL; diff -r aa153b827d17 Objects/bytesobject.c --- a/Objects/bytesobject.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Objects/bytesobject.c Sat Jun 23 11:04:31 2012 +0300 @@ -2372,7 +2372,7 @@ Py_ssize_t hexlen, byteslen, i, j; int top, bot; void *data; - unsigned int kind; + enum PyUnicode_Kind kind; if (!PyArg_ParseTuple(args, "U:fromhex", &hexobj)) return NULL; diff -r aa153b827d17 Objects/exceptions.c --- a/Objects/exceptions.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Objects/exceptions.c Sat Jun 23 11:04:31 2012 +0300 @@ -1274,7 +1274,7 @@ my_basename(PyObject *name) { Py_ssize_t i, size, offset; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicode_READY(name)) diff -r aa153b827d17 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Objects/unicodeobject.c Sat Jun 23 11:04:31 2012 +0300 @@ -295,7 +295,7 @@ _PyUnicode_CheckConsistency(PyObject *op, int check_content) { PyASCIIObject *ascii; - unsigned int kind; + enum PyUnicode_Kind kind; assert(PyUnicode_Check(op)); @@ -538,7 +538,7 @@ (BLOOM(bloom_linebreak, (ch)) && Py_UNICODE_ISLINEBREAK(ch))) Py_LOCAL_INLINE(BLOOM_MASK) -make_bloom_mask(int kind, void* ptr, Py_ssize_t len) +make_bloom_mask(enum PyUnicode_Kind kind, void* ptr, Py_ssize_t len) { /* calculate simple bloom-style bitmask for a given unicode string */ @@ -609,7 +609,7 @@ static PyObject * fixup(PyObject *self, Py_UCS4 (*fixfct)(PyObject *s)); -Py_LOCAL_INLINE(Py_ssize_t) findchar(void *s, int kind, +Py_LOCAL_INLINE(Py_ssize_t) findchar(void *s, enum PyUnicode_Kind kind, Py_ssize_t size, Py_UCS4 ch, int direction) { @@ -1126,7 +1126,7 @@ PyObject *from, Py_ssize_t from_start, Py_ssize_t how_many, int check_maxchar) { - unsigned int from_kind, to_kind; + enum PyUnicode_Kind from_kind, to_kind; void *from_data, *to_data; assert(0 <= how_many); @@ -1856,7 +1856,7 @@ } static Py_UCS4 -kind_maxchar_limit(unsigned int kind) +kind_maxchar_limit(enum PyUnicode_Kind kind) { switch (kind) { case PyUnicode_1BYTE_KIND: @@ -2051,7 +2051,7 @@ PyObject *unicode, *copy; Py_UCS4 max_char; Py_ssize_t len; - unsigned int kind; + enum PyUnicode_Kind kind; assert(p_unicode != NULL); unicode = *p_unicode; @@ -2117,11 +2117,11 @@ character. Return NULL on error. */ void* -_PyUnicode_AsKind(PyObject *s, unsigned int kind) +_PyUnicode_AsKind(PyObject *s, enum PyUnicode_Kind kind) { Py_ssize_t len; void *result; - unsigned int skind; + enum PyUnicode_Kind skind; if (PyUnicode_READY(s) == -1) return NULL; @@ -2175,7 +2175,7 @@ as_ucs4(PyObject *string, Py_UCS4 *target, Py_ssize_t targetsize, int copy_null) { - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t len, targetlen; if (PyUnicode_READY(string) == -1) @@ -2393,7 +2393,7 @@ char *numberresults = NULL; char *numberresult = NULL; Py_ssize_t i; - int kind; + enum PyUnicode_Kind kind; void *data; Py_VA_COPY(count, vargs); @@ -4486,7 +4486,7 @@ int base64WhiteSpace, const char *errors) { - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t len; PyObject *v; @@ -4740,7 +4740,7 @@ s += outpos; while (s < end) { Py_UCS4 ch; - int kind = PyUnicode_KIND(unicode); + enum PyUnicode_Kind kind = PyUnicode_KIND(unicode); if (kind == PyUnicode_1BYTE_KIND) { if (PyUnicode_IS_ASCII(unicode)) ch = asciilib_utf8_decode(&s, end, @@ -5088,7 +5088,7 @@ const char *errors, int byteorder) { - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t len; PyObject *v; @@ -5255,7 +5255,7 @@ while (1) { Py_UCS4 ch = 0; if (e - q >= 2) { - int kind = PyUnicode_KIND(unicode); + enum PyUnicode_Kind kind = PyUnicode_KIND(unicode); if (kind == PyUnicode_1BYTE_KIND) { if (PyUnicode_IS_ASCII(unicode)) ch = asciilib_utf16_decode(&q, e, @@ -5769,7 +5769,7 @@ Py_ssize_t i, len; PyObject *repr; char *p; - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t expandsize = 0; @@ -5800,6 +5800,7 @@ case PyUnicode_1BYTE_KIND: expandsize = 4; break; case PyUnicode_2BYTE_KIND: expandsize = 6; break; case PyUnicode_4BYTE_KIND: expandsize = 10; break; + default: assert(0); } if (len == 0) @@ -6016,7 +6017,7 @@ char *p; char *q; Py_ssize_t expandsize, pos; - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t len; @@ -6317,7 +6318,7 @@ { /* input state */ Py_ssize_t pos=0, size; - int kind; + enum PyUnicode_Kind kind; void *data; /* output object */ PyObject *res; @@ -6554,7 +6555,7 @@ { const char *starts = s; PyObject *unicode; - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t startinpos; Py_ssize_t endinpos; @@ -7694,7 +7695,7 @@ unsigned char level2[512]; unsigned char *mlevel1, *mlevel2, *mlevel3; int count2 = 0, count3 = 0; - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t length; Py_UCS4 ch; @@ -8424,7 +8425,7 @@ /* input object */ char *idata; Py_ssize_t size, i; - int kind; + enum PyUnicode_Kind kind; /* output buffer */ Py_UCS4 *output = NULL; Py_ssize_t osize; @@ -8614,7 +8615,7 @@ /* No need to call PyUnicode_READY(self) because this function is only called as a callback from fixup() which does it already. */ const Py_ssize_t len = PyUnicode_GET_LENGTH(self); - const int kind = PyUnicode_KIND(self); + const enum PyUnicode_Kind kind = PyUnicode_KIND(self); void *data = PyUnicode_DATA(self); Py_UCS4 maxchar = 127, ch, fixed; int modified = 0; @@ -8776,7 +8777,7 @@ Py_ssize_t start, Py_ssize_t end) { - int kind1, kind2, kind; + enum PyUnicode_Kind kind, kind1, kind2; void *buf1, *buf2; Py_ssize_t len1, len2, result; @@ -8852,7 +8853,7 @@ const char *grouping, PyObject *thousands_sep, Py_UCS4 *maxchar) { - unsigned int kind, thousands_sep_kind; + enum PyUnicode_Kind kind, thousands_sep_kind; char *data, *thousands_sep_data; Py_ssize_t thousands_sep_len; Py_ssize_t len; @@ -8951,7 +8952,7 @@ Py_ssize_t result; PyObject* str_obj; PyObject* sub_obj; - int kind1, kind2, kind; + enum PyUnicode_Kind kind, kind1, kind2; void *buf1 = NULL, *buf2 = NULL; Py_ssize_t len1, len2; @@ -9070,7 +9071,7 @@ Py_ssize_t start, Py_ssize_t end, int direction) { - int kind; + enum PyUnicode_Kind kind; Py_ssize_t result; if (PyUnicode_READY(str) == -1) return -2; @@ -9096,13 +9097,9 @@ Py_ssize_t end, int direction) { - int kind_self; - int kind_sub; - void *data_self; - void *data_sub; - Py_ssize_t offset; - Py_ssize_t i; - Py_ssize_t end_sub; + enum PyUnicode_Kind kind_self, kind_sub; + void *data_self, *data_sub; + Py_ssize_t offset, i, end_sub; if (PyUnicode_READY(self) == -1 || PyUnicode_READY(substring) == -1) @@ -9264,7 +9261,8 @@ } static Py_UCS4 -handle_capital_sigma(int kind, void *data, Py_ssize_t length, Py_ssize_t i) +handle_capital_sigma(enum PyUnicode_Kind kind, void *data, + Py_ssize_t length, Py_ssize_t i) { Py_ssize_t j; int final_sigma; @@ -9293,8 +9291,8 @@ } static int -lower_ucs4(int kind, void *data, Py_ssize_t length, Py_ssize_t i, - Py_UCS4 c, Py_UCS4 *mapped) +lower_ucs4(enum PyUnicode_Kind kind, void *data, Py_ssize_t length, + Py_ssize_t i, Py_UCS4 c, Py_UCS4 *mapped) { /* Obscure special case. */ if (c == 0x3A3) { @@ -9305,7 +9303,8 @@ } static Py_ssize_t -do_capitalize(int kind, void *data, Py_ssize_t length, Py_UCS4 *res, Py_UCS4 *maxchar) +do_capitalize(enum PyUnicode_Kind kind, void *data, Py_ssize_t length, + Py_UCS4 *res, Py_UCS4 *maxchar) { Py_ssize_t i, k = 0; int n_res, j; @@ -9329,7 +9328,8 @@ } static Py_ssize_t -do_swapcase(int kind, void *data, Py_ssize_t length, Py_UCS4 *res, Py_UCS4 *maxchar) { +do_swapcase(enum PyUnicode_Kind kind, void *data, Py_ssize_t length, + Py_UCS4 *res, Py_UCS4 *maxchar) { Py_ssize_t i, k = 0; for (i = 0; i < length; i++) { @@ -9354,8 +9354,8 @@ } static Py_ssize_t -do_upper_or_lower(int kind, void *data, Py_ssize_t length, Py_UCS4 *res, - Py_UCS4 *maxchar, int lower) +do_upper_or_lower(enum PyUnicode_Kind kind, void *data, Py_ssize_t length, + Py_UCS4 *res, Py_UCS4 *maxchar, int lower) { Py_ssize_t i, k = 0; @@ -9375,19 +9375,22 @@ } static Py_ssize_t -do_upper(int kind, void *data, Py_ssize_t length, Py_UCS4 *res, Py_UCS4 *maxchar) +do_upper(enum PyUnicode_Kind kind, void *data, Py_ssize_t length, + Py_UCS4 *res, Py_UCS4 *maxchar) { return do_upper_or_lower(kind, data, length, res, maxchar, 0); } static Py_ssize_t -do_lower(int kind, void *data, Py_ssize_t length, Py_UCS4 *res, Py_UCS4 *maxchar) +do_lower(enum PyUnicode_Kind kind, void *data, Py_ssize_t length, + Py_UCS4 *res, Py_UCS4 *maxchar) { return do_upper_or_lower(kind, data, length, res, maxchar, 1); } static Py_ssize_t -do_casefold(int kind, void *data, Py_ssize_t length, Py_UCS4 *res, Py_UCS4 *maxchar) +do_casefold(enum PyUnicode_Kind kind, void *data, Py_ssize_t length, + Py_UCS4 *res, Py_UCS4 *maxchar) { Py_ssize_t i, k = 0; @@ -9404,7 +9407,8 @@ } static Py_ssize_t -do_title(int kind, void *data, Py_ssize_t length, Py_UCS4 *res, Py_UCS4 *maxchar) +do_title(enum PyUnicode_Kind kind, void *data, Py_ssize_t length, + Py_UCS4 *res, Py_UCS4 *maxchar) { Py_ssize_t i, k = 0; int previous_is_cased; @@ -9432,11 +9436,12 @@ static PyObject * case_operation(PyObject *self, - Py_ssize_t (*perform)(int, void *, Py_ssize_t, Py_UCS4 *, Py_UCS4 *)) + Py_ssize_t (*perform)(enum PyUnicode_Kind, void *, Py_ssize_t, + Py_UCS4 *, Py_UCS4 *)) { PyObject *res = NULL; Py_ssize_t length, newlength = 0; - int kind, outkind; + enum PyUnicode_Kind kind, outkind; void *data, *outdata; Py_UCS4 maxchar = 0, *tmp, *tmpend; @@ -9490,7 +9495,7 @@ int use_memcpy; unsigned char *res_data = NULL, *sep_data = NULL; PyObject *last_obj; - unsigned int kind = 0; + enum PyUnicode_Kind kind = 0; fseq = PySequence_Fast(seq, ""); if (fseq == NULL) { @@ -9737,7 +9742,7 @@ { PyObject *u; Py_UCS4 maxchar; - int kind; + enum PyUnicode_Kind kind; void *data; if (left < 0) @@ -9817,7 +9822,7 @@ PyObject *substring, Py_ssize_t maxcount) { - int kind1, kind2, kind; + enum PyUnicode_Kind kind, kind1, kind2; void *buf1, *buf2; Py_ssize_t len1, len2; PyObject* out; @@ -9909,7 +9914,7 @@ PyObject *substring, Py_ssize_t maxcount) { - int kind1, kind2, kind; + enum PyUnicode_Kind kind, kind1, kind2; void *buf1, *buf2; Py_ssize_t len1, len2; PyObject* out; @@ -9997,7 +10002,7 @@ } static Py_ssize_t -anylib_find(int kind, PyObject *str1, void *buf1, Py_ssize_t len1, +anylib_find(enum PyUnicode_Kind kind, PyObject *str1, void *buf1, Py_ssize_t len1, PyObject *str2, void *buf2, Py_ssize_t len2, Py_ssize_t offset) { switch (kind) { @@ -10010,13 +10015,14 @@ return ucs2lib_find(buf1, len1, buf2, len2, offset); case PyUnicode_4BYTE_KIND: return ucs4lib_find(buf1, len1, buf2, len2, offset); - } - assert(0); - return -1; + default: + assert(0); + return -1; + } } static Py_ssize_t -anylib_count(int kind, PyObject *sstr, void* sbuf, Py_ssize_t slen, +anylib_count(enum PyUnicode_Kind kind, PyObject *sstr, void* sbuf, Py_ssize_t slen, PyObject *str1, void *buf1, Py_ssize_t len1, Py_ssize_t maxcount) { switch (kind) { @@ -10029,9 +10035,10 @@ return ucs2lib_count(sbuf, slen, buf1, len1, maxcount); case PyUnicode_4BYTE_KIND: return ucs4lib_count(sbuf, slen, buf1, len1, maxcount); - } - assert(0); - return 0; + default: + assert(0); + return -1; + } } static PyObject * @@ -10043,9 +10050,9 @@ char *buf1 = PyUnicode_DATA(str1); char *buf2 = PyUnicode_DATA(str2); int srelease = 0, release1 = 0, release2 = 0; - int skind = PyUnicode_KIND(self); - int kind1 = PyUnicode_KIND(str1); - int kind2 = PyUnicode_KIND(str2); + enum PyUnicode_Kind skind = PyUnicode_KIND(self); + enum PyUnicode_Kind kind1 = PyUnicode_KIND(str1); + enum PyUnicode_Kind kind2 = PyUnicode_KIND(str2); Py_ssize_t slen = PyUnicode_GET_LENGTH(self); Py_ssize_t len1 = PyUnicode_GET_LENGTH(str1); Py_ssize_t len2 = PyUnicode_GET_LENGTH(str2); @@ -10077,7 +10084,7 @@ if (len1 == 1) { /* replace characters */ Py_UCS4 u1, u2; - int rkind; + enum PyUnicode_Kind rkind; Py_ssize_t index, pos; char *src; @@ -10108,7 +10115,7 @@ } } else { - int rkind = skind; + enum PyUnicode_Kind rkind = skind; char *res; Py_ssize_t i; @@ -10167,7 +10174,7 @@ else { Py_ssize_t n, i, j, ires; Py_ssize_t product, new_size; - int rkind = skind; + enum PyUnicode_Kind rkind = skind; char *res; if (kind1 < rkind) { @@ -10414,7 +10421,7 @@ static int unicode_compare(PyObject *str1, PyObject *str2) { - int kind1, kind2; + enum PyUnicode_Kind kind1, kind2; void *data1, *data2; Py_ssize_t len1, len2, i; @@ -10457,7 +10464,7 @@ PyUnicode_CompareWithASCIIString(PyObject* uni, const char* str) { Py_ssize_t i; - int kind; + enum PyUnicode_Kind kind; void *data; Py_UCS4 chr; @@ -10544,7 +10551,7 @@ PyUnicode_Contains(PyObject *container, PyObject *element) { PyObject *str, *sub; - int kind1, kind2, kind; + enum PyUnicode_Kind kind, kind1, kind2; void *buf1, *buf2; Py_ssize_t len1, len2; int result; @@ -10777,7 +10784,7 @@ Py_ssize_t start = 0; Py_ssize_t end = PY_SSIZE_T_MAX; PyObject *result; - int kind1, kind2, kind; + enum PyUnicode_Kind kind, kind1, kind2; void *buf1, *buf2; Py_ssize_t len1, len2, iresult; @@ -10872,7 +10879,7 @@ PyObject *u; void *src_data, *dest_data; int tabsize = 8; - int kind; + enum PyUnicode_Kind kind; int found; if (!PyArg_ParseTuple(args, "|i:expandtabs", &tabsize)) @@ -11122,7 +11129,7 @@ unicode_islower(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; int cased; @@ -11163,7 +11170,7 @@ unicode_isupper(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; int cased; @@ -11206,7 +11213,7 @@ unicode_istitle(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; int cased, previous_is_cased; @@ -11260,7 +11267,7 @@ unicode_isspace(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicode_READY(self) == -1) @@ -11296,7 +11303,7 @@ unicode_isalpha(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicode_READY(self) == -1) @@ -11330,7 +11337,7 @@ static PyObject* unicode_isalnum(PyObject *self) { - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t len, i; @@ -11369,7 +11376,7 @@ unicode_isdecimal(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicode_READY(self) == -1) @@ -11404,7 +11411,7 @@ unicode_isdigit(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicode_READY(self) == -1) @@ -11440,7 +11447,7 @@ unicode_isnumeric(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicode_READY(self) == -1) @@ -11468,7 +11475,7 @@ int PyUnicode_IsIdentifier(PyObject *self) { - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t i; Py_UCS4 first; @@ -11524,7 +11531,7 @@ unicode_isprintable(PyObject *self) { Py_ssize_t i, length; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicode_READY(self) == -1) @@ -11619,7 +11626,7 @@ _PyUnicode_XStrip(PyObject *self, int striptype, PyObject *sepobj) { void *data; - int kind; + enum PyUnicode_Kind kind; Py_ssize_t i, j, len; BLOOM_MASK sepmask; @@ -11657,7 +11664,7 @@ PyUnicode_Substring(PyObject *self, Py_ssize_t start, Py_ssize_t end) { unsigned char *data; - int kind; + enum PyUnicode_Kind kind; Py_ssize_t length; if (PyUnicode_READY(self) == -1) @@ -11695,7 +11702,7 @@ static PyObject * do_strip(PyObject *self, int striptype) { - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t len, i, j; @@ -11828,7 +11835,7 @@ assert(PyUnicode_KIND(u) == PyUnicode_KIND(str)); if (PyUnicode_GET_LENGTH(str) == 1) { - const int kind = PyUnicode_KIND(str); + const enum PyUnicode_Kind kind = PyUnicode_KIND(str); const Py_UCS4 fill_char = PyUnicode_READ(kind, PyUnicode_DATA(str), 0); if (kind == PyUnicode_1BYTE_KIND) { void *to = PyUnicode_DATA(u); @@ -11944,7 +11951,7 @@ Py_ssize_t isize; Py_ssize_t osize, squote, dquote, i, o; Py_UCS4 max, quote; - int ikind, okind; + enum PyUnicode_Kind ikind, okind; void *idata, *odata; if (PyUnicode_READY(unicode) == -1) @@ -12240,7 +12247,7 @@ PyObject* str_obj; PyObject* sep_obj; PyObject* out; - int kind1, kind2, kind; + enum PyUnicode_Kind kind, kind1, kind2; void *buf1 = NULL, *buf2 = NULL; Py_ssize_t len1, len2; @@ -12317,7 +12324,7 @@ PyObject* str_obj; PyObject* sep_obj; PyObject* out; - int kind1, kind2, kind; + enum PyUnicode_Kind kind, kind1, kind2; void *buf1 = NULL, *buf2 = NULL; Py_ssize_t len1, len2; @@ -12525,7 +12532,7 @@ if (!new) return NULL; if (y != NULL) { - int x_kind, y_kind, z_kind; + enum PyUnicode_Kind x_kind, y_kind, z_kind; void *x_data, *y_data, *z_data; /* x must be a string too, of equal length */ @@ -12574,7 +12581,7 @@ } } } else { - int kind; + enum PyUnicode_Kind kind; void *data; /* x must be a dict */ @@ -12661,7 +12668,7 @@ Py_ssize_t fill; PyObject *u; Py_ssize_t width; - int kind; + enum PyUnicode_Kind kind; void *data; Py_UCS4 chr; @@ -13135,7 +13142,7 @@ Py_ssize_t start, stop, step, slicelength, cur, i; PyObject *result; void *src_data, *dest_data; - int src_kind, dest_kind; + enum PyUnicode_Kind src_kind, dest_kind; Py_UCS4 ch, max_char, kind_limit; if (PySlice_GetIndicesEx(item, PyUnicode_GET_LENGTH(self), @@ -13988,7 +13995,7 @@ PyObject *unicode, *self; Py_ssize_t length, char_size; int share_wstr, share_utf8; - unsigned int kind; + enum PyUnicode_Kind kind; void *data; assert(PyType_IsSubtype(type, &PyUnicode_Type)); @@ -14371,7 +14378,7 @@ assert(_PyUnicode_CHECK(seq)); if (it->it_index < PyUnicode_GET_LENGTH(seq)) { - int kind = PyUnicode_KIND(seq); + enum PyUnicode_Kind kind = PyUnicode_KIND(seq); void *data = PyUnicode_DATA(seq); Py_UCS4 chr = PyUnicode_READ(kind, data, it->it_index); item = PyUnicode_FromOrdinal(chr); diff -r aa153b827d17 Python/_warnings.c --- a/Python/_warnings.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Python/_warnings.c Sat Jun 23 11:04:31 2012 +0300 @@ -500,7 +500,7 @@ *filename = PyDict_GetItemString(globals, "__file__"); if (*filename != NULL && PyUnicode_Check(*filename)) { Py_ssize_t len; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicode_READY(*filename)) diff -r aa153b827d17 Python/ast.c --- a/Python/ast.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Python/ast.c Sat Jun 23 11:04:31 2012 +0300 @@ -3738,7 +3738,7 @@ } if (*s & 0x80) { /* XXX inefficient */ PyObject *w; - int kind; + enum PyUnicode_Kind kind; void *data; Py_ssize_t len, i; w = decode_utf8(c, &s, end); diff -r aa153b827d17 Python/codecs.c --- a/Python/codecs.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Python/codecs.c Sat Jun 23 11:04:31 2012 +0300 @@ -520,7 +520,7 @@ if (PyObject_IsInstance(exc, PyExc_UnicodeEncodeError)) { PyObject *res; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicodeEncodeError_GetStart(exc, &start)) return NULL; @@ -546,7 +546,7 @@ } else if (PyObject_IsInstance(exc, PyExc_UnicodeTranslateError)) { PyObject *res; - int kind; + enum PyUnicode_Kind kind; void *data; if (PyUnicodeTranslateError_GetStart(exc, &start)) return NULL; diff -r aa153b827d17 Python/getargs.c --- a/Python/getargs.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Python/getargs.c Sat Jun 23 11:04:31 2012 +0300 @@ -796,7 +796,7 @@ case 'C': {/* unicode char */ int *p = va_arg(*p_va, int *); - int kind; + enum PyUnicode_Kind kind; void *data; if (!PyUnicode_Check(arg)) diff -r aa153b827d17 Python/import.c --- a/Python/import.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Python/import.c Sat Jun 23 11:04:31 2012 +0300 @@ -877,7 +877,7 @@ Py_ssize_t left, right, dot0, dot1, len; Py_ssize_t i, j; PyObject *result; - int kind; + enum PyUnicode_Kind kind; void *data; len = PyUnicode_GET_LENGTH(path); @@ -1012,7 +1012,7 @@ struct stat statbuf; int err; void *data; - unsigned int kind; + enum PyUnicode_Kind kind; len = PyUnicode_GET_LENGTH(filename); if (len == 0) diff -r aa153b827d17 Python/traceback.c --- a/Python/traceback.c Fri Jun 22 22:49:12 2012 -0500 +++ b/Python/traceback.c Sat Jun 23 11:04:31 2012 +0300 @@ -230,7 +230,7 @@ PyObject *lineobj = NULL; PyObject *res; char buf[MAXPATHLEN+1]; - int kind; + enum PyUnicode_Kind kind; void *data; _Py_IDENTIFIER(close); _Py_IDENTIFIER(open); @@ -485,7 +485,7 @@ PyASCIIObject *ascii = (PyASCIIObject *)text; Py_ssize_t i, size; int truncated; - int kind; + enum PyUnicode_Kind kind; void *data = NULL; wchar_t *wstr = NULL; Py_UCS4 ch; From report at bugs.python.org Sat Jun 23 10:24:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 08:24:11 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1340438620.56.0.199968059324.issue15078@psf.upfronthosting.co.za> Message-ID: <1340439848.2747.111.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > I personally like the change, except for `flags` argument collapsing. Imagine what mmap's prototype would look like if we used list of optional arguments instead of a flag... What's wrong with mmap? It uses list of optional arguments (`flags`, `prot`, `access`) and not only one `flags` argument. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sat Jun 23 10:28:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 08:28:50 +0000 Subject: [issue14742] test_tools very slow In-Reply-To: <1336419915.88.0.52212163456.issue14742@psf.upfronthosting.co.za> Message-ID: <E1SiLhW-0007PY-RT@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 0e5a698d3c4c by Mark Dickinson in branch 'default': Issue #14742: test_unparse now only checks a limited number of files unless the 'cpu' resource is specified. http://hg.python.org/cpython/rev/0e5a698d3c4c ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14742> _______________________________________ From report at bugs.python.org Sat Jun 23 10:30:53 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 08:30:53 +0000 Subject: [issue14742] test_tools very slow In-Reply-To: <1336419915.88.0.52212163456.issue14742@psf.upfronthosting.co.za> Message-ID: <1340440253.05.0.427856979316.issue14742@psf.upfronthosting.co.za> Changes by Mark Dickinson <dickinsm at gmail.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14742> _______________________________________ From report at bugs.python.org Sat Jun 23 10:31:07 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 08:31:07 +0000 Subject: [issue14742] test_tools very slow In-Reply-To: <1336419915.88.0.52212163456.issue14742@psf.upfronthosting.co.za> Message-ID: <1340440267.35.0.158591436908.issue14742@psf.upfronthosting.co.za> Changes by Mark Dickinson <dickinsm at gmail.com>: ---------- resolution: -> fixed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14742> _______________________________________ From report at bugs.python.org Sat Jun 23 10:38:57 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 08:38:57 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1340440737.23.0.496009598502.issue15078@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I indeed think that the code is fine as it stands, and no change is needed, and that the proposed changes make matters worse. The point of the thin wrappers approach is that you can read the manpage of your system, and immediately can trust that this is what the Python function will do. It is unfortunate that BSD and Linux have chosen to give the function the same name despite the signature differences, but there is no value in hiding this fact from the Python user. The whole point of this function is performance and zero copy. Anybody using it will need to understand well what they are doing, and that their code is highly system-dependent. If you want cross-platform code, use shutil.copyfileobj. I could agree to a higher-level function that tries to avoid system differences, but that function shouldn't be called sendfile. For example, the socket object could have a sendfd or sendstream method which would use the proper variant of sendfile if available, else uses a regular read/send loop. I always found the name "sendfile" confusing, anyway, since it's not the file that is being sent, but the all (or some) of the contents of the file. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sat Jun 23 10:40:48 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 08:40:48 +0000 Subject: [issue15137] Cleaned source of `cmd` module In-Reply-To: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> Message-ID: <1340440848.55.0.565698008176.issue15137@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Do read PEP 8 Python style guide. http://python.org/dev/peps/pep-0008/ You violated the following: (Peeves) More than one space around an assignment (or other) operator to align it with another. Yes: x = 1 y = 2 long_variable = 3 No: x = 1 y = 2 long_variable = 3 I used to do that, but it only works with fixed-pitch fonts, which is not really possible for full-unicode fonts. Anyway, that is about half the changes, and they would have to go. Sorry. Some of your other changes make it more compliant. Some I am not sure of others without re-reading. For the other reasons David gave, I am closing this so you are not mislead into doing more work that will not be accepted. I would note that improving test coverage *is* accepted and good test-coverage is really needed before extensive re-writes. Another document to read is the developer guide http://docs.python.org/devguide/index.html Last point. Please use .diff or .patch for diff/patch files as that extension works better for people and, I believe, hg. Since you are interested in readability, you might consider contributing doc suggestions. You do not have to know .rst formatting. A good suggestion given as plain ascii in a message like this will be copied and formatted by someone who does know .rst. And in simple cases, one can even patch the source .rst withouth knowing much. ---------- nosy: +terry.reedy resolution: -> rejected stage: -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Sat Jun 23 10:42:37 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 08:42:37 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> Message-ID: <1340440957.09.0.552325699632.issue15142@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: You're right, I was confusing what happens automatically for classes defined in Python (i.e. the full treatment in type_new) vs those defined statically (i.e. just the parts in PyType_Ready). Given that PyType_FromSpec doesn't currently support inheritance, providing a default tp_dealloc before the inherit_slots() call in PyType_Ready would work OK in the near term. However, once inheritance support is added by #15146 then it would be wrong - the default slot entry would override an inherited one. So, I think this adjustment actually needs to be handled in PyType_Ready, at some point after the inherit_slots() call. Something like: /* Sanity check for tp_dealloc. */ if ((type->tp_flags & Py_TPFLAGS_HEAPTYPE) && (type->tp_dealloc == type_dealloc)) { /* Type has been declared as a heap type, but has inherited the default allocator. This can happen when using the limited API to dynamically create types. */ type->tp_dealloc = subtype_dealloc; } ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 10:51:53 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 08:51:53 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340441513.99.0.833920746163.issue15133@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: The bug is the mismatch between doc and behavior. Unless someone can explain why the seemingly reasonable docstring is wrong, I would consider changing the behavior a possible fix. Can you add minimal test code that gives you an int? I should check windows and someone should check 2.7, doc and behavior. ---------- nosy: +gpolo, serwy, terry.reedy title: tkinter.BooleanVar.get() docstring is wrong -> tkinter.BooleanVar.get() behavior and docstring disagree type: -> behavior versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Sat Jun 23 10:58:35 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 Jun 2012 08:58:35 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340441915.82.0.719535169566.issue10142@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: > This looks like a bug in freebsd: > > http://lists.freebsd.org/pipermail/freebsd-amd64/2012-January/014332.html I tested that one already yesterday (it was late, so I forgot to mention it) and the test case attached to the bug report runs fine on the buildbot: #include <unistd.h> #include <fcntl.h> #include <errno.h> int main(void) { int fd = open("ccc.c", O_RDONLY); off_t offset=lseek(fd,0,SEEK_HOLE); if (offset==-1) { if (errno==ENXIO) { // No more data printf("no more data\n"); close(fd); exit(-1); } } return 0; } The skip looks good to me though, I wouldn't be surprised if there is a kernel bug. This bug is still present on my machine: http://www.freebsd.org/cgi/query-pr.cgi?pr=94729 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Sat Jun 23 10:59:33 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 23 Jun 2012 08:59:33 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1340441973.36.0.804701089333.issue15078@psf.upfronthosting.co.za> Charles-Fran?ois Natali <neologix at free.fr> added the comment: > What's wrong with mmap? It uses list of optional arguments (`flags`, > `prot`, `access`) and not only one `flags` argument. Of course it does, as the mmap syscall(), since this arguments have nothing to do with one another. I was refering to your proposal of splitting sendfile's `flags` argument, which is currently a bitmask, into distinct arguments (diskio=True, wait=True, sync=False). If we did this for, let's say, mmap() `flags`, this would end up in a bazillion optional arguments, because there a re so many possible values for `flags` (MAP_SHARED, MAP_PRIVATE, MAP_ANONYMOUS, MAP_DENYWRITE...). Bitmasks are a clear and compact way to pass optional arguments, and should be kept. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sat Jun 23 10:59:52 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 08:59:52 +0000 Subject: [issue14340] Update embedded copy of expat - fix security & crash issues In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za> Message-ID: <1340441992.2.0.0498157204424.issue14340@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Deferring for beta1 at least. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14340> _______________________________________ From report at bugs.python.org Sat Jun 23 11:00:48 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 09:00:48 +0000 Subject: [issue15146] Implemented PyType_FromSpecWithBases In-Reply-To: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za> Message-ID: <1340442048.66.0.649878065295.issue15146@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15146> _______________________________________ From report at bugs.python.org Sat Jun 23 11:07:22 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 23 Jun 2012 09:07:22 +0000 Subject: [issue15152] test_subprocess fqailures on awfully slow builtbots Message-ID: <1340442442.66.0.972780604979.issue15152@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali <neologix at free.fr>: Some test_subprocess tests are failing on really slow buildbots, such as the Ubtuntu ARM one: """ ====================================================================== ERROR: test_wait_timeout (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_subprocess.py", line 718, in test_wait_timeout self.assertEqual(p.wait(timeout=3), 0) File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/subprocess.py", line 1494, in wait raise TimeoutExpired(self.args, timeout) subprocess.TimeoutExpired: Command '['/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/python', '-c', 'import time; time.sleep(0.1)']' timed out after 3 seconds ====================================================================== FAIL: test_check_output_timeout (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_subprocess.py", line 140, in test_check_output_timeout self.assertEqual(c.exception.output, b'BDFL') AssertionError: b'' != b'BDFL' ====================================================================== FAIL: test_check_output_timeout (test.test_subprocess.ProcessTestCaseNoPoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_subprocess.py", line 140, in test_check_output_timeout self.assertEqual(c.exception.output, b'BDFL') AssertionError: b'' != b'BDFL' """ The timeouts for those tests are already at 3 seconds. We could double them to 6 seconds and see if things get better: that would increase the running time on all the buildbots, though. Any other idea? ---------- components: Tests keywords: buildbot messages: 163557 nosy: neologix, pitrou priority: normal severity: normal stage: needs patch status: open title: test_subprocess fqailures on awfully slow builtbots type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15152> _______________________________________ From report at bugs.python.org Sat Jun 23 11:14:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 09:14:40 +0000 Subject: [issue13062] Introspection generator and function closure state In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za> Message-ID: <1340442880.19.0.802369796795.issue13062@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Attached patch implements both new functions, but I'm going to drop getgeneratorlocals for now and move that idea to a new issue. ---------- Added file: http://bugs.python.org/file26103/issue13062-combined.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13062> _______________________________________ From report at bugs.python.org Sat Jun 23 11:19:30 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 Jun 2012 09:19:30 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1340441915.82.0.719535169566.issue10142@psf.upfronthosting.co.za> Message-ID: <20120623091927.GA20288@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: > int main(void) > { > int fd = open("ccc.c", O_RDONLY); > off_t offset=lseek(fd,0,SEEK_HOLE); > if (offset==-1) { > if (errno==ENXIO) { Darn, the errno in test_posix should be ENOTTY. Indeed, with ENOTTY the test case for the bug is positive. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Sat Jun 23 11:19:50 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 09:19:50 +0000 Subject: [issue15153] Add inspect.getgeneratorlocals Message-ID: <1340443190.33.0.807153251972.issue15153@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: Extracted from #13062, the proposal is add a simple API to inspect the local variables of a generator with an associated frame. ---------- components: Library (Lib) messages: 163560 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Add inspect.getgeneratorlocals type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15153> _______________________________________ From report at bugs.python.org Sat Jun 23 11:22:21 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 09:22:21 +0000 Subject: [issue15153] Add inspect.getgeneratorlocals In-Reply-To: <1340443190.33.0.807153251972.issue15153@psf.upfronthosting.co.za> Message-ID: <1340443341.85.0.181490825124.issue15153@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: The intended use case is for whitebox testing of generator behaviour. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15153> _______________________________________ From report at bugs.python.org Sat Jun 23 11:24:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 09:24:40 +0000 Subject: [issue13062] Introspection generator and function closure state In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za> Message-ID: <1340443480.72.0.245686293274.issue13062@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I created #15153 to cover getgeneratorlocals. Attached patch is just for record keeping purposes - I'll be committing this change shortly. ---------- Added file: http://bugs.python.org/file26104/issue13062-getclosurevars.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13062> _______________________________________ From report at bugs.python.org Sat Jun 23 11:40:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 09:40:12 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340440957.09.0.552325699632.issue15142@psf.upfronthosting.co.za> Message-ID: <1340444197.3326.2.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > However, once inheritance support is added by #15146 then it would be > wrong - the default slot entry would override an inherited one. It would not be wrong. subtype_dealloc will properly call a base class' tp_dealloc, if necessary. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 11:40:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 09:40:23 +0000 Subject: [issue13062] Introspection generator and function closure state In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za> Message-ID: <E1SiMpI-0003hT-Ox@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 487fe648de56 by Nick Coghlan in branch 'default': Close #13062: Add inspect.getclosurevars to simplify testing stateful closures http://hg.python.org/cpython/rev/487fe648de56 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13062> _______________________________________ From report at bugs.python.org Sat Jun 23 11:41:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 09:41:11 +0000 Subject: [issue15152] test_subprocess fqailures on awfully slow builtbots In-Reply-To: <1340442442.66.0.972780604979.issue15152@psf.upfronthosting.co.za> Message-ID: <1340444471.74.0.26779122625.issue15152@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Barry (the buildbot owner) could take a look. ---------- nosy: +barry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15152> _______________________________________ From report at bugs.python.org Sat Jun 23 11:50:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 09:50:09 +0000 Subject: [issue12965] longobject: documentation improvements In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za> Message-ID: <E1SiMyi-0004FW-BH@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 5ca9a51f3d85 by Mark Dickinson in branch '3.2': Issue #12965: Clean up C-API docs for PyLong_AsLong(AndOverflow); clarify that __int__ will be called for non-PyLongs http://hg.python.org/cpython/rev/5ca9a51f3d85 New changeset 63fc1552cd36 by Mark Dickinson in branch 'default': Issue #12965: Merge from 3.2 http://hg.python.org/cpython/rev/63fc1552cd36 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12965> _______________________________________ From report at bugs.python.org Sat Jun 23 11:52:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 09:52:26 +0000 Subject: [issue15153] Add inspect.getgeneratorlocals In-Reply-To: <1340443190.33.0.807153251972.issue15153@psf.upfronthosting.co.za> Message-ID: <E1SiN0s-0004Pi-H8@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset dd82a910eb07 by Nick Coghlan in branch 'default': Close #15153: Added inspect.getgeneratorlocals to simplify whitebox testing of generator state updates http://hg.python.org/cpython/rev/dd82a910eb07 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15153> _______________________________________ From report at bugs.python.org Sat Jun 23 12:12:53 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 10:12:53 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1340446373.92.0.396883325084.issue14578@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: OTOH, I don't want it to block beta1. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14578> _______________________________________ From report at bugs.python.org Sat Jun 23 12:13:44 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 10:13:44 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1340446424.42.0.809615422462.issue13959@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: OK, sounds like none of it would block beta1. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Sat Jun 23 12:14:53 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 10:14:53 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <1340446493.31.0.895431996256.issue15114@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Why not deprecate .error()? Removing it immediately as undocumented is certainly not better. Otherwise sounds good, please commit. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Sat Jun 23 12:15:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 10:15:14 +0000 Subject: [issue12965] longobject: documentation improvements In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za> Message-ID: <E1SiNN0-0005ke-Fh@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 3ace8e17074a by Mark Dickinson in branch '3.2': Issue #12965: Clean up C-API docs for PyLong_AsLongLong(AndOverflow); clarify that __int__ will be called for non-PyLongs http://hg.python.org/cpython/rev/3ace8e17074a New changeset 85683f005fc8 by Mark Dickinson in branch 'default': Issue #12965: Merge from 3.2. http://hg.python.org/cpython/rev/85683f005fc8 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12965> _______________________________________ From report at bugs.python.org Sat Jun 23 12:15:39 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 10:15:39 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> Message-ID: <1340446539.07.0.707119687377.issue15142@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: True, I didn't follow the bouncing ball far enough. In that, case I think all that is needed is a comment like: "subtype_dealloc walks the MRO to call the base dealloc function, so it is OK to block inheritance of the slot" ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 12:15:39 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 10:15:39 +0000 Subject: [issue15143] Windows compile errors In-Reply-To: <1340395101.67.0.466421051649.issue15143@psf.upfronthosting.co.za> Message-ID: <1340446539.07.0.589317398028.issue15143@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Seems to be fixed; at least compilation now works. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15143> _______________________________________ From report at bugs.python.org Sat Jun 23 12:15:49 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 10:15:49 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340446549.55.0.202792732722.issue15147@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Very good, thanks. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sat Jun 23 12:16:34 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 10:16:34 +0000 Subject: [issue15150] Windows build does not link In-Reply-To: <1340418809.0.0.92215340871.issue15150@psf.upfronthosting.co.za> Message-ID: <1340446594.46.0.994483933569.issue15150@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Doesn't occur on the buildbots; is it fixed already? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15150> _______________________________________ From report at bugs.python.org Sat Jun 23 12:37:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 10:37:55 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1340447875.14.0.907773998088.issue14626@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: 27f9c26fdd8b broke test_shutil on the Windows buildbots: ====================================================================== FAIL: test_basic (test.test_shutil.TestWhich) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_shutil.py", line 1146, in test_basic self.assertEqual(rv, self.temp_file.name) AssertionError: None != 'c:\\users\\db3l\\appdata\\local\\temp\\tmpxqw4gu\\tmp7ugfmm.exe' ====================================================================== FAIL: test_full_path_short_circuit (test.test_shutil.TestWhich) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_shutil.py", line 1152, in test_full_path_short_circuit self.assertEqual(self.temp_file.name, rv) AssertionError: 'c:\\users\\db3l\\appdata\\local\\temp\\tmpmwer14\\tmpeacfbz.exe' != None ====================================================================== FAIL: test_non_matching_mode (test.test_shutil.TestWhich) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_shutil.py", line 1158, in test_non_matching_mode self.assertIsNone(rv) AssertionError: 'c:\\users\\db3l\\appdata\\local\\temp\\tmp7n6ojp\\tmp5tt9pa.exe' is not None ====================================================================== FAIL: test_pathext_checking (test.test_shutil.TestWhich) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_shutil.py", line 1181, in test_pathext_checking self.assertEqual(self.temp_file.name, rv) AssertionError: 'c:\\users\\db3l\\appdata\\local\\temp\\tmpipmbe3\\tmpx43hex.exe' != None ====================================================================== FAIL: test_relative (test.test_shutil.TestWhich) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_shutil.py", line 1166, in test_relative self.assertEqual(rv, os.path.join(tail_dir, self.file)) AssertionError: None != 'tmpcluw7l\\tmp6sy_py.exe' ---------- nosy: +pitrou priority: normal -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 23 13:00:33 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 23 Jun 2012 11:00:33 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340449233.35.0.993298085086.issue13590@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Thanks, Ronald. Version 3 addresses various issues, including adding a search of $PATH for clang since xcrun is not useful in the case where the user has installed a standalone Command Line Tools package or has installed a Command Line Tools component from within Xcode but hasn't run xcode-select. Another problem: the SDK path is likely going to be incorrect in the common case of an installer build on 10.5 or 10.6 but run on 10.7 or later. It's tricky to get all the edge cases correct for that. For now, the solution is to delete -sdkroot parameters from the default CFLAGS and friends if the SDK path is invalid; that assumes the Command Line Tools component/package has been installed. If necessary, the user can override via env variables. Also, the compiler validity checks are now bypassed if the user has overridden CC. I'll plan to commit later today for 3.3.0b1 along with some README updates. ---------- stage: needs patch -> commit review Added file: http://bugs.python.org/file26105/issue13950-version3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Sat Jun 23 13:13:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 11:13:45 +0000 Subject: [issue12965] longobject: documentation improvements In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za> Message-ID: <E1SiOHP-0000mp-S2@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset e1416a4d728a by Mark Dickinson in branch '3.2': Issue #12965: More PyLong_As* clarifications. Thanks Stefan Krah. http://hg.python.org/cpython/rev/e1416a4d728a New changeset 349bc58e8c66 by Mark Dickinson in branch 'default': Issue #12965: Merge from 3.2. http://hg.python.org/cpython/rev/349bc58e8c66 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12965> _______________________________________ From report at bugs.python.org Sat Jun 23 13:18:56 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 11:18:56 +0000 Subject: [issue12965] longobject: documentation improvements In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za> Message-ID: <1340450336.16.0.0159623839342.issue12965@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Docs mostly fixed now for Python 3.2 and Python 3.3. That leaves 2.7, where there are some additional complications (e.g., __long__ in addition to __int__, when / whether short ints are accepted, etc.). While it would be good to fix the 2.7 docs as well, I don't see myself having time for this in the near future, so I'm unassigning for now; Stefan, I think should feel free to take this issue and check in clarifications for 2.7, if you want to. ---------- assignee: mark.dickinson -> versions: -Python 3.1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12965> _______________________________________ From report at bugs.python.org Sat Jun 23 13:23:05 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 11:23:05 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1340450585.5.0.939714360798.issue3665@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Any chance to commit the patch today and to get this feature in Python 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3665> _______________________________________ From report at bugs.python.org Sat Jun 23 13:25:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 11:25:58 +0000 Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za> Message-ID: <1340450758.37.0.943481850768.issue5067@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Any chance to commit the patch today and to get this feature in Python 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5067> _______________________________________ From report at bugs.python.org Sat Jun 23 13:28:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 11:28:37 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1340450917.68.0.849937470111.issue10376@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Any chance to commit the patch before final feature freeze? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10376> _______________________________________ From report at bugs.python.org Sat Jun 23 13:28:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 11:28:36 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1340450916.34.0.12087917322.issue3665@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- assignee: -> pitrou stage: patch review -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3665> _______________________________________ From report at bugs.python.org Sat Jun 23 13:30:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 11:30:39 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za> Message-ID: <1340451039.01.0.581714653244.issue14923@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Any chance to commit the patch before final feature freeze? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 13:32:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 11:32:54 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <E1SiOaA-0001zm-Lo@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset b1dbd8827e79 by Antoine Pitrou in branch 'default': Issue #3665: \u and \U escapes are now supported in unicode regular expressions. http://hg.python.org/cpython/rev/b1dbd8827e79 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3665> _______________________________________ From report at bugs.python.org Sat Jun 23 13:33:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 11:33:41 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za> Message-ID: <1340451221.72.0.512356771286.issue3665@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Any chance to commit the patch today and to get this feature in Python > 3.3? Thanks for reminding us! It's now in 3.3. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3665> _______________________________________ From report at bugs.python.org Sat Jun 23 13:34:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 11:34:20 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1340451260.47.0.463513733852.issue10376@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- assignee: docs at python -> nosy: +nadeem.vawda stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10376> _______________________________________ From report at bugs.python.org Sat Jun 23 13:35:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 11:35:52 +0000 Subject: [issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za> Message-ID: <1340451352.35.0.494490589809.issue8271@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: Removed file: http://bugs.python.org/file25720/issue8271-3.3-fast.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8271> _______________________________________ From report at bugs.python.org Sat Jun 23 13:36:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 11:36:12 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za> Message-ID: <1340451372.1.0.0681391920617.issue14923@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Any chance to commit the patch before final feature freeze? I'll defer to Mark :-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 13:38:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 11:38:42 +0000 Subject: [issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za> Message-ID: <1340451522.76.0.416600926989.issue8271@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Why is this marked "fixed"? Is it fixed or not? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8271> _______________________________________ From report at bugs.python.org Sat Jun 23 13:42:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 11:42:27 +0000 Subject: [issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za> Message-ID: <1340451747.4.0.249936375292.issue8271@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: I deleted a fast patch, since it unsafe. Issue14923 should safer compensate a small slowdown. I think this change is not a bugfix (this is not a bug, the standard allows such behavior), but a new feature, so I doubt the need to fix 2.7 and 3.2. Any chance to commit the patch today and to get this feature in Python 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8271> _______________________________________ From report at bugs.python.org Sat Jun 23 13:43:32 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 11:43:32 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za> Message-ID: <1340451812.6.0.687003268422.issue14923@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Okay, will look at this this afternoon. ---------- assignee: -> mark.dickinson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 13:48:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 11:48:13 +0000 Subject: [issue3665] Support \u and \U escapes in regexes In-Reply-To: <1340451221.72.0.512356771286.issue3665@psf.upfronthosting.co.za> Message-ID: <1340452097.2747.112.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: Thank you for the quick response. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3665> _______________________________________ From report at bugs.python.org Sat Jun 23 13:55:49 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 11:55:49 +0000 Subject: [issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 In-Reply-To: <1340451522.76.0.416600926989.issue8271@psf.upfronthosting.co.za> Message-ID: <1340452552.2747.119.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: No, it is not fully fixed. Only one bug was fixed, but the current behavior is still not conformed with the Unicode Standard *recommendations*. Non-conforming with recommendations is not a bug, conforming is a feature. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8271> _______________________________________ From report at bugs.python.org Sat Jun 23 14:00:10 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 12:00:10 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340452810.65.0.62713537216.issue15139@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Antoine is much more of an expert here, and I defer to his judgment that it is better to wait. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Sat Jun 23 14:05:25 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 12:05:25 +0000 Subject: [issue15144] Possible integer overflow in operations with addresses and sizes. In-Reply-To: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za> Message-ID: <1340453125.35.0.894558936634.issue15144@psf.upfronthosting.co.za> Changes by Mark Dickinson <dickinsm at gmail.com>: ---------- assignee: -> mark.dickinson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15144> _______________________________________ From report at bugs.python.org Sat Jun 23 14:08:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 12:08:48 +0000 Subject: [issue15150] Windows build does not link In-Reply-To: <1340418809.0.0.92215340871.issue15150@psf.upfronthosting.co.za> Message-ID: <1340453328.09.0.241713282674.issue15150@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15150> _______________________________________ From report at bugs.python.org Sat Jun 23 14:18:31 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 12:18:31 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340453911.08.0.607234750922.issue10142@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: The test case is till failing for the freebsd7 buildbot: http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/3155/steps/test/logs/stdio ---------- nosy: +georg.brandl status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Sat Jun 23 14:20:29 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 12:20:29 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340454029.64.0.76622238318.issue10142@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: And the Ubuntu ARM buildbot. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Sat Jun 23 14:21:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 12:21:06 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1340454066.33.0.707729093397.issue14596@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Reduction of memory consumption of struct is a new feature. Any chance to commit struct_repeat.patch+struct_sizeof.patch today and to get this feature in Python 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14596> _______________________________________ From report at bugs.python.org Sat Jun 23 14:24:14 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 12:24:14 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1340454254.78.0.553704382944.issue14596@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: I'm still not convinced that something like struct_repeat.patch is necessary. So unless someone else wants to own this issue and review the struct_repeat, I'd say that it's too late for 3.3. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14596> _______________________________________ From report at bugs.python.org Sat Jun 23 14:29:15 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 12:29:15 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340454555.27.0.105662537292.issue15139@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I believe the patch is incorrect. It changes self._acquire_restore into a no-op, claiming that lock_acquire_condition will correctly restore the lock's state. However, lock_acquire_condition may fail (e.g. if the timeout is not strictly positive), in which case the lock's case isn't properly restored. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Sat Jun 23 14:32:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 12:32:20 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340454740.51.0.4092738252.issue15102@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 14:46:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 12:46:16 +0000 Subject: [issue15135] HOWTOs doesn't link to "Idioms and Anti-Idioms" article In-Reply-To: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za> Message-ID: <1340455576.64.0.629780912806.issue15135@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: > Your links do not work because the comma/period that follow are > considered part of the urls. To be safe, always follow with whitespace. FWIW this will be fixed soon and the fix will work on older messages too: http://psf.upfronthosting.co.za/roundup/meta/issue437 http://issues.roundup-tracker.org/issue2550759 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15135> _______________________________________ From report at bugs.python.org Sat Jun 23 14:47:05 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 12:47:05 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1340454254.78.0.553704382944.issue14596@psf.upfronthosting.co.za> Message-ID: <1340455638.2747.132.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: Now internal representation of Struct with small format string may consume unexpectedly large memory and this representation may be invisible cached. With patch you can get large internal representation only for large format strings. It is expected. And how about struct_sizeof.patch? Now sys.getsizeof() returns wrong result for Struct: 28 >>> sys.getsizeof(struct.Struct('100B')) 28 The patch (it compatible with both Struct representations) fixes it: 52 >>> sys.getsizeof(struct.Struct('100B')) 1240 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14596> _______________________________________ From report at bugs.python.org Sat Jun 23 14:48:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 12:48:55 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> Message-ID: <E1SiPlm-0007J6-9d@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 1794308c1ea7 by Antoine Pitrou in branch '3.2': Issue #15142: Fix reference leak when deallocating instances of types created using PyType_FromSpec(). http://hg.python.org/cpython/rev/1794308c1ea7 New changeset 9945d7dfa72c by Antoine Pitrou in branch 'default': Issue #15142: Fix reference leak when deallocating instances of types created using PyType_FromSpec(). http://hg.python.org/cpython/rev/9945d7dfa72c ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 14:49:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 12:49:42 +0000 Subject: [issue15142] Fix reference leak with types created using PyType_FromSpec In-Reply-To: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za> Message-ID: <1340455782.95.0.135522762244.issue15142@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Ok, fixed, thanks. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15142> _______________________________________ From report at bugs.python.org Sat Jun 23 14:50:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 12:50:41 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1340455841.76.0.88998369113.issue14478@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: The C version of decimal may not always be available. In particular, it is not compatible with C89. Therefore, efficiency of the pure Python version of decimal is important. Any chance to get it in Python 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14478> _______________________________________ From report at bugs.python.org Sat Jun 23 15:02:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 13:02:48 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1340456568.17.0.726360157038.issue14478@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +mark.dickinson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14478> _______________________________________ From report at bugs.python.org Sat Jun 23 15:15:59 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sat, 23 Jun 2012 13:15:59 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1340457359.58.0.116333840039.issue10376@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: Patch looks fine to me. Antoine, can you commit this? I'm currently away from the computer that has my SSH key on it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10376> _______________________________________ From report at bugs.python.org Sat Jun 23 15:21:43 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 13:21:43 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <1340457703.79.0.13030953266.issue15114@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Regarding .error() I think the best thing to do is wait till 3.4 and then deprecate it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Sat Jun 23 15:28:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 13:28:01 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <E1SiQNc-0001AO-Bb@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 8dd2f5754b2f by Ezio Melotti in branch 'default': #15114: the strict mode of HTMLParser and the HTMLParseError exception are deprecated now that the parser is able to parse invalid markup. http://hg.python.org/cpython/rev/8dd2f5754b2f ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Sat Jun 23 15:31:52 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 23 Jun 2012 13:31:52 +0000 Subject: [issue15091] ImportError when package is symlinked on Unix In-Reply-To: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za> Message-ID: <1340458312.23.0.177968609457.issue15091@psf.upfronthosting.co.za> Jason R. Coombs <jaraco at jaraco.com> added the comment: The test is already present in test_import but is disabled because it is currently failing. I should mention that I believe this is a regression with 3.3 over 3.2. It is certainly a regression over 2.7. ---------- stage: test needed -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15091> _______________________________________ From report at bugs.python.org Sat Jun 23 15:33:25 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 13:33:25 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za> Message-ID: <1340458405.49.0.215232533119.issue14923@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: I'm happy to apply the 'decode_utf8_range_check.patch'; I'll do that unless there are objections. The code is clearer than the original, and if we get a speedup into the bargain then I don't see a reason not to apply this. I'm less comfortable with either the original patch, or the most recent one (decode_utf8_signed_byte-2.patch). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 15:34:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 13:34:27 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <1340458467.92.0.0840343106874.issue15114@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: 3.3 is done. 3.4 strict arg deprecated (raises a warning) HTMLParser.error deprecated (raises a warning) 3.5 strict arg removed and strict code removed HTMLParseError removed HTMLParser.error and calls to HTMLParser.error removed ---------- keywords: -patch priority: release blocker -> normal stage: commit review -> needs patch versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Sat Jun 23 15:45:01 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 23 Jun 2012 13:45:01 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340459101.86.0.295071450624.issue15118@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > OT, but since you brought it up: In my opinion, deprecating the > iterability of any builtin class is a horrible idea. It is a > Python feature, especially in 3.x, that all *are* iterable. As you say, OT. But I don't see how it's a feature. Destructuring assignment is opaque (what was the order of fields again?), and with named attributes almost always unnecessary. And I find it hard to believe that there's a good use case for iterating over the values in a loop. I don't propose deprecating the iterability of these structures simply because I think it's inappropriate in a point release. But I hope to remove that misfeature in Python 4. (If you wish to continue the discussion, perhaps we should take it somewhere else?) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sat Jun 23 15:48:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 13:48:27 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1340459307.76.0.639089815518.issue14478@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: I agree with Raymond: I don't see a real need to patch the Python version here. If we do want to patch the Python version, I'd go with Raymond's simple patch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14478> _______________________________________ From report at bugs.python.org Sat Jun 23 15:51:00 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 13:51:00 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za> Message-ID: <1340459460.95.0.43373551622.issue14923@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Serhiy, does this patch also fix #8271? If so, can you also include the tests I wrote for it? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 15:57:25 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 13:57:25 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1340459845.04.0.875860868347.issue14596@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: The struct_sizeof patch looks fine, but lacks tests. I think it might be reasonable to call this a bugfix. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14596> _______________________________________ From report at bugs.python.org Sat Jun 23 16:20:30 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 23 Jun 2012 14:20:30 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340461230.18.0.719754308624.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Updated patch with volatile, better error report for non-ASCII strings and updated comments ---------- Added file: http://bugs.python.org/file26106/timingsafe_cmp-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 16:25:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 14:25:16 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340461516.46.0.0598604158341.issue15061@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I'm not really happy with the addition of a separate extension module for a single private function. You could just put it in the operator module, for instance. Also, the idea was not to expose timingsafe_cmp but to use it in compare_digest(). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 16:41:01 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 23 Jun 2012 14:41:01 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340462461.3.0.510636604706.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Me neither but you didn't want it in the operator module in the first place (msg162882). :) Please make a decision. I'm happy to follow it. My idea is to drop the pure Python implementation of compare_digest() and just use the C implementation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 16:48:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 14:48:25 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <E1SiRdP-0006bd-B9@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 0e8285321659 by Antoine Pitrou in branch 'default': On behalf of Nadeem Vawda: issue #10376: micro-optimize reading from a Zipfile. http://hg.python.org/cpython/rev/0e8285321659 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10376> _______________________________________ From report at bugs.python.org Sat Jun 23 16:50:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 14:50:55 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340463055.47.0.953155558512.issue15061@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Me neither but you didn't want it in the operator module in the first > place (msg162882). :) Please make a decision. I'm happy to follow it. Oh, sorry. I've changed my mind about it, but I think the operator module should only export a private function (and hmac or hashlib export it publicly). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 16:51:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 14:51:22 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1340463082.3.0.991594163202.issue10376@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Antoine, can you commit this? Ok, done. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10376> _______________________________________ From report at bugs.python.org Sat Jun 23 16:54:54 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 14:54:54 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340463294.92.0.262019562426.issue15061@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Doesn't belong into operator IMO. We used to have a "strop" module where it would have fitted... ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 17:00:06 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 23 Jun 2012 15:00:06 +0000 Subject: [issue665194] datetime-RFC2822 roundtripping Message-ID: <1340463606.12.0.175701196356.issue665194@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Well, I guess I'd like to keep it since it does satisfy a need in the email package: to manipulate dates in the local timezone when composing messages. It isn't a critical need, though; the critical need is just to be able to have a datetime that has the correct timezone as its tzinfo for 'now', and your astimezone change supplies that. On the third hand, 'util.localtime()' is a lot more intuitive then 'datetime.now().astimezone()', so I'd probably still have a util.localtime() helper even if I restricted it to only generating 'now'. So, on balance, since the method is in and tested with the extra functionality, and that functionality will probably prove useful to programs manipulating emails, I'm coming down in favor of keeping it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue665194> _______________________________________ From report at bugs.python.org Sat Jun 23 17:01:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 15:01:12 +0000 Subject: [issue15145] Faster *_find_max_char In-Reply-To: <1340398318.47.0.89388206382.issue15145@psf.upfronthosting.co.za> Message-ID: <1340463672.74.0.546379881214.issue15145@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15145> _______________________________________ From report at bugs.python.org Sat Jun 23 17:01:20 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 15:01:20 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340463680.79.0.824819602526.issue15102@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: I'd like Martin to have a look at this. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 17:08:20 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 23 Jun 2012 15:08:20 +0000 Subject: [issue14340] Update embedded copy of expat - fix security & crash issues In-Reply-To: <1340441992.2.0.0498157204424.issue14340@psf.upfronthosting.co.za> Message-ID: <CAGE7PN+kMX+UWmybjK-LYE9YgbPMrWqhiBxNkKR7OP5FonD0og@mail.gmail.com> Gregory P. Smith <greg at krypto.org> added the comment: Thanks. I still intend to get to this. On Jun 23, 2012 1:59 AM, "Georg Brandl" <report at bugs.python.org> wrote: > > Georg Brandl <georg at python.org> added the comment: > > Deferring for beta1 at least. > > ---------- > priority: release blocker -> deferred blocker > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue14340> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14340> _______________________________________ From report at bugs.python.org Sat Jun 23 17:08:58 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 Jun 2012 15:08:58 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340464138.35.0.479623648128.issue15061@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: This is why I wanted to close the issue with the pure Python implementation, and punt on the question of a C accelerator for the moment. compare_digest is effectively the same as what all the Python web servers and frameworks do now for signature checking. Yes, it's more vulnerable to timing attacks than a C implementation, but it's going to to take a sophisticated attacker to attack that through the noise of network jitter. It's sufficiently hardened that's it's unlikely to be the weakest link in the security chain. For 3.4, I hope to see a discussion open up regarding the idea of something like a "securitytools" module that aims to provide some basic primitives for operations where Python's standard assumptions (such as flexibility and short circuiting behaviour) are a bad fit for security reasons. That would include exposing a C level full_compare option, as well as the core pbkdf2 algorithm. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 17:09:40 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 15:09:40 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340464180.86.0.998104038456.issue15102@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I think this really needs to be broken further down than "the AMD64 buildbot doesn't work". For each presumed failure, there should be one issue, and perhaps a proposed patch. The patch, as it stands, is clearly incorrect (as has been reviewed and acknowledged). So unless Jeremy can provide an updated patch quickly, I rather suggest to close this issue, and ask for new issues to be created for the individual problems. As for the changes to project files and the solution file: none of these changes should be necessary at all, unless it's actually the case that the AMD64-Debug build doesn't work (i.e. neither in the buildbot, nor from the solution file). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 17:19:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 15:19:01 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340463294.92.0.262019562426.issue15061@psf.upfronthosting.co.za> Message-ID: <1340464528.3326.24.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Doesn't belong into operator IMO. We used to have a "strop" module > where it would have fitted... Again, it can be a private function in the operator module that happens to be wrapped or exposed in the hmac module. Practicality beats purity. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 17:22:02 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 15:22:02 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340464922.71.0.0754473073676.issue15061@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Yes. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 17:24:20 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 23 Jun 2012 15:24:20 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340464528.3326.24.camel@localhost.localdomain> Message-ID: <4FE5DFA2.5050603@cheimes.de> Christian Heimes <lists at cheimes.de> added the comment: > Again, it can be a private function in the operator module that happens > to be wrapped or exposed in the hmac module. Practicality beats purity. Yes, we just need a place for the function. The operator module is a good place if we don't want to introduce a new module. Nick: I'll target pbkdf2 and other password hashing / security related for 3.4. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 17:27:58 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 23 Jun 2012 15:27:58 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340464180.86.0.998104038456.issue15102@psf.upfronthosting.co.za> Message-ID: <CAGvrs3L9-vv5Pta83BcEfMj40S85z__qcmkdU44DPLCfBNmhmw@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: > The patch, as it stands, is clearly incorrect (as has been reviewed and acknowledged). The most recent patch is correct. > As for the changes to project files and the solution file: none of these changes should be necessary at all, unless it's actually the case that the AMD64-Debug build doesn't work (i.e. neither in the buildbot, nor from the solution file). The debug build doesn't even *build*! That's the issue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 17:32:01 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 23 Jun 2012 15:32:01 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340464180.86.0.998104038456.issue15102@psf.upfronthosting.co.za> Message-ID: <CAGvrs3L724+iTKJ+Q=jh7qdPh3+PzY0+oSWutfE4s+zL8H2zvQ@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: > As for the changes to project files and the solution file: none of these changes should be necessary at all, unless it's actually the case that the AMD64-Debug build doesn't work (i.e. neither in the buildbot, nor from the solution file). As to the debug build not working, has anyone even looked at the 64-bit Windows buildbot? As the following link demonstrates, building is clearly failing: http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows7%20SP1%203.x/builds/74/steps/compile/logs/stdio ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 17:35:10 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 23 Jun 2012 15:35:10 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340464138.35.0.479623648128.issue15061@psf.upfronthosting.co.za> Message-ID: <73651495-417A-4F18-8A2E-F969904D0390@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: > For 3.4, I hope to see a discussion open up regarding the idea of something like a "securitytools" module that aims to provide some basic primitives for operations where Python's standard assumptions (such as flexibility and short circuiting behaviour) are a bad fit for security reasons. That would include exposing a C level full_compare option, as well as the core pbkdf2 algorithm. Strong +1 on that one. We could even consider adding bcrypt and scrypt as C isn't really an issue for us. Ideally we'd add a module with docs which both promote and leverage secure behavior. Basically how to realize http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html in Python. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 17:56:16 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 15:56:16 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <CAGvrs3L9-vv5Pta83BcEfMj40S85z__qcmkdU44DPLCfBNmhmw@mail.gmail.com> Message-ID: <20120623175615.Horde.sbtVB1NNcXdP5ecfr_TyuWA@webmail.df.eu> Martin v. L?wis <martin at v.loewis.de> added the comment: > The most recent patch is correct. See my review then; I think it has issues. > The debug build doesn't even *build*! That's the issue. It builds fine for me - I just tried. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 18:05:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 Jun 2012 16:05:41 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <20120623175615.Horde.sbtVB1NNcXdP5ecfr_TyuWA@webmail.df.eu> Message-ID: <20120623160539.GA23487@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Martin v. L??wis <report at bugs.python.org> wrote: > > The debug build doesn't even *build*! That's the issue. > > It builds fine for me - I just tried. What command line do you use? I tried: C:\Users\stefan\pydev\cpython>.\Tools\buildbot\build-amd64.bat Error: project file 'pcbuild.sln' was not found or not a valid project file. Microsoft (R) Visual C++ Project Builder - Command Line Version 9.00.21022 Copyright (C) Microsoft Corporation. All rights reserved. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 18:10:11 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 16:10:11 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <20120623160539.GA23487@sleipnir.bytereef.org> Message-ID: <20120623181010.Horde.8YbzfVNNcXdP5epiHMXC1GA@webmail.df.eu> Martin v. L?wis <martin at v.loewis.de> added the comment: >> > The debug build doesn't even *build*! That's the issue. >> >> It builds fine for me - I just tried. > > What command line do you use? Not the command line - I built from the IDE. My claim is if that works, no changes to the solution and project files should be necessary. > C:\Users\stefan\pydev\cpython>.\Tools\buildbot\build-amd64.bat > > Error: project file 'pcbuild.sln' was not found or not a valid project file. I can believe that there are issues with the batch files. That's why I propose to look at one issue at a time (but it's not my priority at the moment). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 18:13:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 16:13:59 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340468039.1.0.143409938404.issue11113@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Attached another file with a dict that contains the 2231 HTML5 entities listed at http://www.w3.org/TR/html5/named-character-references.html The dict is like: html5namedcharref = { 'Aacute;': '\xc1', 'Aacute': '\xc1', 'aacute;': '\xe1', 'aacute': '\xe1', 'Abreve;': '\u0102', 'abreve;': '\u0103', ... } A better name could be found for the dict if you have better ideas (maybe html.entities.html5 only?). The dict will be added to html.entities. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file26107/entities.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sat Jun 23 18:15:48 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 23 Jun 2012 16:15:48 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <20120623181010.Horde.8YbzfVNNcXdP5epiHMXC1GA@webmail.df.eu> Message-ID: <CAGvrs3KUuQ8gb+amymXtn9zXgDd-BjJVu_FyDoVa8R2kygRENQ@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: > I can believe that there are issues with the batch files. That's why I propose > to look at one issue at a time (but it's not my priority at the moment). That would mean that you do not care that the buildbots are failing. That is exactly the reason that this bug report has been opened. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 18:18:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 16:18:12 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <E1SiT2I-00041C-Sm@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c910af2e3c98 by Hynek Schlawack in branch 'default': #4489: Add a shutil.rmtree that isn't suspectible to symlink attacks http://hg.python.org/cpython/rev/c910af2e3c98 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sat Jun 23 18:28:17 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 16:28:17 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340468897.77.0.978148703533.issue15102@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Of course these failures have to be fixed. But what Martin is saying is that for him (and probably other devs working on Windows) the build works, so the change must be done in the scripts only running on the buildbots. As for priority, we're two days away from 3.3b1 and feature freeze, so you can imagine that there are quite a lot of things on Martin's table. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 18:31:18 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 Jun 2012 16:31:18 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340469078.21.0.579336704827.issue15102@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: I seem to be getting a functioning amd64 debug build by applying the small useenv.diff and then running: Tools\buildbot\build-amd64.bat ---------- Added file: http://bugs.python.org/file26108/useenv.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 18:35:53 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 16:35:53 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <CAGvrs3LpX1TY__e9W6_hD_07Mq0L4YwR4+MTsz4f27e_fBaOOQ@mail.gmail.com> Message-ID: <20120623183552.Horde.S-PsSVNNcXdP5fBoIygy-_A@webmail.df.eu> Martin v. L?wis <martin at v.loewis.de> added the comment: > This change eliminates the need for HOST_PYTHON. Why is it required > in the first place? It is not documented as being required to build > Python. It helps to build 64-bit binaries on a 32-bit Windows installation. Normally, Python uses the python.exe it just built, but this fails if the binary is a 64-bit binary, but the host is 32-bits. It would be best if HOST_PYTHON was used if set, but it otherwise falls back to using the Python just built. I'm fine with dropping HOST_PYTHON for 3.4, but not for 3.3. > When building in the VS IDE, the proper compilers are chosen. > However, when building via the buildbot scripts, the compilers are > forced to the 64-bit only versions and thus cause link errors. See > the buildbot status for the exact error messages. I see the errors, but I believe the solution is incorrect. It must be possible to build from the command line exactly in the same way as from the IDE, and it *was* possible to do so with VS 2008. We just need to find out how to do it with VS 2010. > This file is a redundant with python_nt.h. It was removed for simplicity. That is out of scope for this issue, then. If the file annoys you much, create a separate issue. > I do not know what you reviewed, but the diff I generated does not > have those changes. Interesting. Now Rietveld doesn't show them anymore, either, in the place where I left the comment. ---------- title: Fix 64-bit building for buildbot scripts -> Fix 64-bit building for buildbot scripts (issue 15102) _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 18:37:55 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 16:37:55 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340469475.85.0.613065781383.issue15102@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Stefan: your patch looks good, please apply. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 18:39:25 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 16:39:25 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340469565.01.0.298518257734.issue11113@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Here is a proper patch, still using the html5namedcharref name. HTMLParser should also be updated to use this dict. ---------- keywords: +patch stage: patch review -> commit review Added file: http://bugs.python.org/file26109/issue11113.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sat Jun 23 18:40:15 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 Jun 2012 16:40:15 +0000 Subject: [issue12965] longobject: documentation improvements In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za> Message-ID: <1340469615.21.0.383807635523.issue12965@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: OK, I'll see if I find some time for the 2.7 docs. ---------- assignee: -> skrah _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12965> _______________________________________ From report at bugs.python.org Sat Jun 23 18:49:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 16:49:18 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1340470158.01.0.238129832632.issue14626@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: The `rmdir` argument to unlink() looks completely crazy to me. Instead rmdir() should be called when one wants to rmdir() a fd. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 23 18:52:54 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 16:52:54 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340470374.14.0.791301846517.issue11113@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: Removed file: http://bugs.python.org/file26109/issue11113.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sat Jun 23 18:53:06 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 16:53:06 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340470386.86.0.951783600798.issue11113@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: Added file: http://bugs.python.org/file26110/issue11113.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sat Jun 23 18:55:20 2012 From: report at bugs.python.org (Mark Summerfield) Date: Sat, 23 Jun 2012 16:55:20 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340470520.51.0.448365510878.issue15133@psf.upfronthosting.co.za> Mark Summerfield <mark at qtrac.eu> added the comment: Did you mean formal test code? Or just an example like this: from tkinter import * tk = Tk() bv = BooleanVar() print(bv.get(), type(bv.get())) bv.set(True) print(bv.get(), type(bv.get())) bv.set(False) print(bv.get(), type(bv.get())) ### output ### 0 <class 'int'> 1 <class 'int'> 0 <class 'int'> ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Sat Jun 23 18:59:13 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 16:59:13 +0000 Subject: [issue13263] Group some os functions in submodules In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za> Message-ID: <1340470753.3.0.728780400436.issue13263@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: FWIW we have 12 functions less since 3.3.0a0 (probably after #14626): Python 3.3.0a4+ (default:8dd2f5754b2f, Jun 23 2012, 16:50:40) >>> import os; len(dir(os)) 320 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13263> _______________________________________ From report at bugs.python.org Sat Jun 23 18:59:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 16:59:18 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <E1SiTg2-0006jC-UX@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 979567d33376 by Stefan Krah in branch 'default': Issue #15102: Allow platform-specific settings for the current project http://hg.python.org/cpython/rev/979567d33376 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 19:15:11 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 17:15:11 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir Message-ID: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> New submission from Georg Brandl <georg at python.org>: As Antoine noted in #14626, the "rmdir" argument to os.unlink doesn't really make sense since we already deviate from just mapping posix functionality one-on-one. Attached is a patch removing "rmdir" from os.unlink, and instead adding "dir_fd" to os.rmdir. ---------- assignee: larry files: move-dirfd-to-rmdir.patch keywords: patch messages: 163647 nosy: georg.brandl, larry, pitrou priority: critical severity: normal stage: patch review status: open title: remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26111/move-dirfd-to-rmdir.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sat Jun 23 19:15:20 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 17:15:20 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1340471720.89.0.115649448871.issue14626@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: I agree with Antoine. I've opened #15154 to track this. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 23 19:16:57 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 23 Jun 2012 17:16:57 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir In-Reply-To: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> Message-ID: <1340471817.58.0.219766830341.issue15154@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sat Jun 23 19:18:26 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 23 Jun 2012 17:18:26 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340471906.2.0.993610911573.issue15147@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Just a note: a this time I am cleaning the apartment that I?m leaving, so when I say ?Saturday afternoon? it?s in Montreal time, so you may see it as early Sunday from Europe. So don?t worry if your Saturday night comes and I did not commit. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sat Jun 23 19:18:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 17:18:58 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir In-Reply-To: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> Message-ID: <1340471938.27.0.384090582936.issue15154@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Looks fine to me. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sat Jun 23 19:22:53 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 23 Jun 2012 17:22:53 +0000 Subject: [issue13263] Group some os functions in submodules In-Reply-To: <1319544377.25.0.706220454632.issue13263@psf.upfronthosting.co.za> Message-ID: <1340472173.57.0.357298945298.issue13263@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13263> _______________________________________ From report at bugs.python.org Sat Jun 23 19:24:12 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 23 Jun 2012 17:24:12 +0000 Subject: [issue15114] Deprecate strict mode of HTMLParser In-Reply-To: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za> Message-ID: <1340472252.23.0.103487650774.issue15114@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15114> _______________________________________ From report at bugs.python.org Sat Jun 23 19:57:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 17:57:20 +0000 Subject: [issue15150] Windows build does not link In-Reply-To: <1340418809.0.0.92215340871.issue15150@psf.upfronthosting.co.za> Message-ID: <E1SiUaF-0002Jn-HA@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset f3d28feef2ea by Martin v. L?wis in branch 'default': Issue #15150: regenerate python3stub.def. http://hg.python.org/cpython/rev/f3d28feef2ea ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15150> _______________________________________ From report at bugs.python.org Sat Jun 23 19:57:50 2012 From: report at bugs.python.org (Christian Heimes) Date: Sat, 23 Jun 2012 17:57:50 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340474270.59.0.280072612151.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: New patch. The compare_digest method now lives in the operator module as operator._compare_digest ---------- Added file: http://bugs.python.org/file26112/compare_digest_c.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 19:58:43 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 17:58:43 +0000 Subject: [issue15150] Windows build does not link In-Reply-To: <1340418809.0.0.92215340871.issue15150@psf.upfronthosting.co.za> Message-ID: <1340474323.27.0.372140240187.issue15150@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: This should be fixed with the patch above. As python3.mak was using the wrong target names, the failing command probably wasn't executed. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15150> _______________________________________ From report at bugs.python.org Sat Jun 23 19:58:55 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 17:58:55 +0000 Subject: [issue15150] Windows build does not link In-Reply-To: <1340418809.0.0.92215340871.issue15150@psf.upfronthosting.co.za> Message-ID: <1340474335.72.0.921916832507.issue15150@psf.upfronthosting.co.za> Changes by Martin v. L?wis <martin at v.loewis.de>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15150> _______________________________________ From report at bugs.python.org Sat Jun 23 20:04:32 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 23 Jun 2012 18:04:32 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir In-Reply-To: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> Message-ID: <1340474672.12.0.68410291244.issue15154@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sat Jun 23 20:26:26 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 18:26:26 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340475986.43.0.370449194753.issue11113@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: How about calling it just "html5", or "HTML5"? That it is about entities already follows from the module name. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sat Jun 23 20:30:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 18:30:12 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <E1SiV62-0004Qt-U3@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 53fc7f59c7bb by Hynek Schlawack in branch 'default': #4489: Fix usage of fd-based functions to new api introduced earlier today http://hg.python.org/cpython/rev/53fc7f59c7bb ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sat Jun 23 20:32:00 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 23 Jun 2012 18:32:00 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340476320.36.0.239627177689.issue11113@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Here's a new patch that uses the "html5" name for the dict, if there aren't other comments I'll commit it. ---------- Added file: http://bugs.python.org/file26113/issue11113-2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sat Jun 23 21:08:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 19:08:13 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <E1SiVgq-0006tQ-GG@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset a9d4cf7d15b9 by Martin v. L?wis in branch 'default': Issue #15102: Use HOST_PYTHON only if it is set. http://hg.python.org/cpython/rev/a9d4cf7d15b9 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 21:18:47 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 Jun 2012 19:18:47 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340479127.33.0.171164929478.issue15102@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: I've fixed some paths in external-amd64.bat. Uploading a diff instead of committing right away so as not to interfere with the steadily incoming commits. ---------- Added file: http://bugs.python.org/file26114/external-amd64.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 21:19:46 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 23 Jun 2012 19:19:46 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340479186.07.0.701850159056.issue15139@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: _acquire_condition() should _always_ re-aquire the outer lock, even for a timeout or an interrupt. I see however that it doesn't do so if there is an argument error, but that should not be a problem for an internal method, since it would mean that threading.Condition() were incorrectly implemented. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Sat Jun 23 21:21:44 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 23 Jun 2012 19:21:44 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340479304.48.0.227874523204.issue15139@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: I'll fix the patch so that the lock is _always_ re-aqcuired. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Sat Jun 23 21:37:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 19:37:21 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340480241.64.0.22774460033.issue15102@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Stefan, don't fear interfering. Merging is easy. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 22:19:16 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 23 Jun 2012 20:19:16 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir In-Reply-To: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> Message-ID: <1340482756.1.0.159121061303.issue15154@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I think it's a good idea, and I didn't spot anything on my first pass at reviewing the patch. But I'm on my way out the door and won't be back for a few hours. Tell you what: once I'm back, if I don't spot anything out of place, I'll just check it in. If I have feedback I'll file a second patch. Work for you, Georg? (p.s. Antoine, Georg, anybody, if you have any more bright ideas like this, I'd love to hear 'em. But... now's the time.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sat Jun 23 22:19:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 20:19:55 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <E1SiWoD-00035B-Oi@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c56783fe2e3b by Stefan Krah in branch 'default': Issue #15102: Fix paths in external-amd64.bat. http://hg.python.org/cpython/rev/c56783fe2e3b ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 22:21:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 20:21:29 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340482889.46.0.820985126148.issue15139@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: If the claim is that the _acquire_restore call becomes unnecessary, the entire try-finally should go. If that causes _acquire_restore to become unused, it should also go. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Sat Jun 23 22:22:10 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 Jun 2012 20:22:10 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340480241.64.0.22774460033.issue15102@psf.upfronthosting.co.za> Message-ID: <20120623202208.GA25189@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Antoine Pitrou <report at bugs.python.org> wrote: > Stefan, don't fear interfering. Merging is easy. Good to know, I loathe merging. :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 22:33:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 20:33:06 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340483586.02.0.860957779424.issue15102@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: There's still a problem when building ssl: Project "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pcbuild.sln" (1) is building "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj" (18) on node 1 (default targets). Project "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj" (18) is building "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj" (19) on node 1 (default targets). Build: cd "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\" "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\python_d.exe" build_ssl.py Release x64 -a '"C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\python_d.exe"' is not recognized as an internal or external command, operable program or batch file. (from http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows7%20SP1%203.x/builds/90/steps/compile/logs/stdio ) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sat Jun 23 22:34:59 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 20:34:59 +0000 Subject: [issue15042] Implemented PyState_AddModule, PyState_RemoveModule In-Reply-To: <1339320622.0.0.56459406352.issue15042@psf.upfronthosting.co.za> Message-ID: <1340483699.92.0.846319303585.issue15042@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Thanks for the patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15042> _______________________________________ From report at bugs.python.org Sat Jun 23 22:37:05 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 20:37:05 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir In-Reply-To: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> Message-ID: <1340483825.83.0.547675401099.issue15154@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Works for me. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sat Jun 23 22:41:18 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 23 Jun 2012 20:41:18 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1340484078.65.0.161397477363.issue14626@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: The Windows buildbots are now content; closing. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14626> _______________________________________ From report at bugs.python.org Sat Jun 23 22:41:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 20:41:44 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1340459845.04.0.875860868347.issue14596@psf.upfronthosting.co.za> Message-ID: <1340484115.2747.134.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: Here is Struct.__sizeof__ patch with tests. ---------- Added file: http://bugs.python.org/file26115/struct_sizeof-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14596> _______________________________________ -------------- next part -------------- diff -r 53fc7f59c7bb Lib/test/test_struct.py --- a/Lib/test/test_struct.py Sat Jun 23 20:28:32 2012 +0200 +++ b/Lib/test/test_struct.py Sat Jun 23 23:39:25 2012 +0300 @@ -572,6 +572,16 @@ s = struct.Struct('i') s.__init__('ii') + def test_sizeof(self): + self.assertGreater(sys.getsizeof(struct.Struct('BHILfdspP')), + sys.getsizeof(struct.Struct('B'))) + self.assertGreaterEqual(sys.getsizeof(struct.Struct('123B')), + sys.getsizeof(struct.Struct('B'))) + self.assertGreaterEqual(sys.getsizeof(struct.Struct('B' * 123)), + sys.getsizeof(struct.Struct('123B'))) + self.assertGreaterEqual(sys.getsizeof(struct.Struct('123xB')), + sys.getsizeof(struct.Struct('B'))) + def test_main(): run_unittest(StructTest) diff -r 53fc7f59c7bb Modules/_struct.c --- a/Modules/_struct.c Sat Jun 23 20:28:32 2012 +0200 +++ b/Modules/_struct.c Sat Jun 23 23:39:25 2012 +0300 @@ -1752,6 +1752,19 @@ return PyLong_FromSsize_t(self->s_size); } +static PyObject * +s_sizeof(PyStructObject *self, void *unused) +{ + Py_ssize_t res; + formatcode *code; + + res = sizeof(PyStructObject) + sizeof(formatcode); + for (code = self->s_codes; code->fmtdef != NULL; code++) { + res += sizeof(formatcode); + } + return PyLong_FromSsize_t(res); +} + /* List of functions */ static struct PyMethodDef s_methods[] = { @@ -1760,6 +1773,8 @@ {"unpack", s_unpack, METH_O, s_unpack__doc__}, {"unpack_from", (PyCFunction)s_unpack_from, METH_VARARGS|METH_KEYWORDS, s_unpack_from__doc__}, + {"__sizeof__", (PyCFunction)s_sizeof, METH_NOARGS, + "Returns size in memory, in bytes"}, {NULL, NULL} /* sentinel */ }; From report at bugs.python.org Sat Jun 23 22:42:39 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 20:42:39 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1340312987.2703.25.camel@raxxla> Message-ID: <4FE62A3A.4050307@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: >>> About code. Instead (PyBytes_CheckExact(a) && PyBytes_CheckExact(b)) you >>> should use ((PyBytes_CheckExact(a) != 0) & (PyBytes_CheckExact(b) != >>> 0)). >> >> What's the difference? They are the same. > > Laziness. If "a" (a secret key) is not bytes then PyBytes_CheckExact(b) > ("b" is a user input) is not called. It exposes secret key type. I'm not > sure if it is real secret however. I see; I missed that your version was using &. In any case, I don't think this is a threat: you couldn't use it to get the secret key faster. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sat Jun 23 22:45:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 20:45:27 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za> Message-ID: <E1SiXCv-0004kX-IZ@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 3214c9ebcf5e by Mark Dickinson in branch 'default': Issue #14923: Optimize continuation-byte check in UTF-8 decoding. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/3214c9ebcf5e ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 22:47:20 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 23 Jun 2012 20:47:20 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za> Message-ID: <1340484440.58.0.232968639929.issue14923@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Patch applied. Closing. Ezio: the patch is pure optimization, with no change in semantics; I don't see how it could fix #8271. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 23:03:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 21:03:48 +0000 Subject: [issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za> Message-ID: <1340485428.17.0.582372501834.issue8271@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Here is updated, a little faster, patch. It merged with decode_utf8_range_check.patch from issue14923. Patch contains non-modified Ezio Melotti's tests which all successfully passed. ---------- Added file: http://bugs.python.org/file26116/issue8271-3.3-fast-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8271> _______________________________________ From report at bugs.python.org Sat Jun 23 23:10:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 21:10:44 +0000 Subject: [issue14923] Even faster UTF-8 decoding In-Reply-To: <1340459460.95.0.43373551622.issue14923@psf.upfronthosting.co.za> Message-ID: <1340485859.2747.141.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Serhiy, does this patch also fix #8271? No, this patch not change behavior. But updated patch for issue 8271 now contains this patch (I hope this will help merge). > If so, can you also include the tests I wrote for it? Your tests included in patch for issue 8271. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14923> _______________________________________ From report at bugs.python.org Sat Jun 23 23:19:17 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 23 Jun 2012 21:19:17 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340486357.33.0.616878940181.issue15139@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Made lock_acquire_condition() more robust, always acquiring the outer lock if possible. For Lock objects (not RLocks), set the "locked" variable that was recently added. ---------- Added file: http://bugs.python.org/file26117/condition.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Sat Jun 23 23:21:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jun 2012 21:21:02 +0000 Subject: [issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 In-Reply-To: <1340485428.17.0.582372501834.issue8271@psf.upfronthosting.co.za> Message-ID: <1340486468.2747.145.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: Here is updated patch with resolved merge conflict with 3214c9ebcf5e. ---------- Added file: http://bugs.python.org/file26118/issue8271-3.3-fast-3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8271> _______________________________________ -------------- next part -------------- diff -r ec656d79b8ac Lib/test/test_unicode.py --- a/Lib/test/test_unicode.py Sat Jun 23 22:55:58 2012 +0200 +++ b/Lib/test/test_unicode.py Sun Jun 24 00:20:16 2012 +0300 @@ -1321,7 +1321,7 @@ # with start byte of a 2-byte sequence (b'\xc2', FFFD), # only the start byte (b'\xc2\xc2', FFFD*2), # 2 start bytes - (b'\xc2\xc2\xc2', FFFD*3), # 2 start bytes + (b'\xc2\xc2\xc2', FFFD*3), # 3 start bytes (b'\xc2\x41', FFFD+'A'), # invalid continuation byte # with start byte of a 3-byte sequence (b'\xe1', FFFD), # only the start byte @@ -1391,6 +1391,233 @@ self.assertEqual(seq.decode('utf-8', 'ignore'), res.replace('\uFFFD', '')) + def to_bytestring(self, seq): + return bytes(int(c, 16) for c in seq.split()) + + def assertCorrectUTF8Decoding(self, seq, res, err): + """ + Check that an invalid UTF-8 sequence raises an UnicodeDecodeError when + 'strict' is used, returns res when 'replace' is used, and that doesn't + return anything when 'ignore' is used. + """ + #with self.assertRaises(UnicodeDecodeError) as cm: + #seq.decode('utf-8') + #exc = cm.exception + try: + seq.decode('utf-8') + except UnicodeDecodeError as e: + exc = str(e) + else: + self.fail( + "%r.decode('utf-8') didn't raise UnicodeDecodeError." % seq) + + self.assertIn(err, str(exc)) + self.assertEqual(seq.decode('utf-8', 'replace'), res) + self.assertEqual((b'aaaa' + seq + b'bbbb').decode('utf-8', 'replace'), + 'aaaa' + res + 'bbbb') + res = res.replace('\ufffd', '') + self.assertEqual(seq.decode('utf-8', 'ignore'), res) + self.assertEqual((b'aaaa' + seq + b'bbbb').decode('utf-8', 'ignore'), + 'aaaa' + res + 'bbbb') + + def test_invalid_start_byte(self): + """ + Test that an 'invalid start byte' error is raised when the first byte + is not in the ASCII range or is not a valid start byte of a 2-, 3-, or + 4-bytes sequence. The invalid start byte is replaced with a single + U+FFFD when errors='replace'. + E.g. <80> is a continuation byte and can appear only after a start byte. + """ + FFFD = '\ufffd' + for byte in b'\x80\xA0\x9F\xBF\xC0\xC1\xF5\xFF': + self.assertCorrectUTF8Decoding(bytes([byte]), '\ufffd', + 'invalid start byte') + + def test_unexpected_end_of_data(self): + """ + Test that an 'unexpected end of data' error is raised when the string + ends after a start byte of a 2-, 3-, or 4-bytes sequence without having + enough continuation bytes. The incomplete sequence is replaced with a + single U+FFFD when errors='replace'. + E.g. in the sequence <F3 80 80>, F3 is the start byte of a 4-bytes + sequence, but it's followed by only 2 valid continuation bytes and the + last continuation bytes is missing. + Note: the continuation bytes must be all valid, if one of them is + invalid another error will be raised. + """ + sequences = [ + 'C2', 'DF', + 'E0 A0', 'E0 BF', 'E1 80', 'E1 BF', 'EC 80', 'EC BF', + 'ED 80', 'ED 9F', 'EE 80', 'EE BF', 'EF 80', 'EF BF', + 'F0 90', 'F0 BF', 'F0 90 80', 'F0 90 BF', 'F0 BF 80', 'F0 BF BF', + 'F1 80', 'F1 BF', 'F1 80 80', 'F1 80 BF', 'F1 BF 80', 'F1 BF BF', + 'F3 80', 'F3 BF', 'F3 80 80', 'F3 80 BF', 'F3 BF 80', 'F3 BF BF', + 'F4 80', 'F4 8F', 'F4 80 80', 'F4 80 BF', 'F4 8F 80', 'F4 8F BF' + ] + FFFD = '\ufffd' + for seq in sequences: + self.assertCorrectUTF8Decoding(self.to_bytestring(seq), '\ufffd', + 'unexpected end of data') + + def test_invalid_cb_for_2bytes_seq(self): + """ + Test that an 'invalid continuation byte' error is raised when the + continuation byte of a 2-bytes sequence is invalid. The start byte + is replaced by a single U+FFFD and the second byte is handled + separately when errors='replace'. + E.g. in the sequence <C2 41>, C2 is the start byte of a 2-bytes + sequence, but 41 is not a valid continuation byte because it's the + ASCII letter 'A'. + """ + FFFD = '\ufffd' + FFFDx2 = FFFD * 2 + sequences = [ + ('C2 00', FFFD+'\x00'), ('C2 7F', FFFD+'\x7f'), + ('C2 C0', FFFDx2), ('C2 FF', FFFDx2), + ('DF 00', FFFD+'\x00'), ('DF 7F', FFFD+'\x7f'), + ('DF C0', FFFDx2), ('DF FF', FFFDx2), + ] + for seq, res in sequences: + self.assertCorrectUTF8Decoding(self.to_bytestring(seq), res, + 'invalid continuation byte') + + def test_invalid_cb_for_3bytes_seq(self): + """ + Test that an 'invalid continuation byte' error is raised when the + continuation byte(s) of a 3-bytes sequence are invalid. When + errors='replace', if the first continuation byte is valid, the first + two bytes (start byte + 1st cb) are replaced by a single U+FFFD and the + third byte is handled separately, otherwise only the start byte is + replaced with a U+FFFD and the other continuation bytes are handled + separately. + E.g. in the sequence <E1 80 41>, E1 is the start byte of a 3-bytes + sequence, 80 is a valid continuation byte, but 41 is not a valid cb + because it's the ASCII letter 'A'. + Note: when the start byte is E0 or ED, the valid ranges for the first + continuation byte are limited to A0..BF and 80..9F respectively. + However, when the start byte is ED, Python 2 considers all the bytes + in range 80..BF valid. This is fixed in Python 3. + """ + FFFD = '\ufffd' + FFFDx2 = FFFD * 2 + sequences = [ + ('E0 00', FFFD+'\x00'), ('E0 7F', FFFD+'\x7f'), ('E0 80', FFFDx2), + ('E0 9F', FFFDx2), ('E0 C0', FFFDx2), ('E0 FF', FFFDx2), + ('E0 A0 00', FFFD+'\x00'), ('E0 A0 7F', FFFD+'\x7f'), + ('E0 A0 C0', FFFDx2), ('E0 A0 FF', FFFDx2), + ('E0 BF 00', FFFD+'\x00'), ('E0 BF 7F', FFFD+'\x7f'), + ('E0 BF C0', FFFDx2), ('E0 BF FF', FFFDx2), ('E1 00', FFFD+'\x00'), + ('E1 7F', FFFD+'\x7f'), ('E1 C0', FFFDx2), ('E1 FF', FFFDx2), + ('E1 80 00', FFFD+'\x00'), ('E1 80 7F', FFFD+'\x7f'), + ('E1 80 C0', FFFDx2), ('E1 80 FF', FFFDx2), + ('E1 BF 00', FFFD+'\x00'), ('E1 BF 7F', FFFD+'\x7f'), + ('E1 BF C0', FFFDx2), ('E1 BF FF', FFFDx2), ('EC 00', FFFD+'\x00'), + ('EC 7F', FFFD+'\x7f'), ('EC C0', FFFDx2), ('EC FF', FFFDx2), + ('EC 80 00', FFFD+'\x00'), ('EC 80 7F', FFFD+'\x7f'), + ('EC 80 C0', FFFDx2), ('EC 80 FF', FFFDx2), + ('EC BF 00', FFFD+'\x00'), ('EC BF 7F', FFFD+'\x7f'), + ('EC BF C0', FFFDx2), ('EC BF FF', FFFDx2), ('ED 00', FFFD+'\x00'), + ('ED 7F', FFFD+'\x7f'), + # ('ED A0', FFFDx2), ('ED BF', FFFDx2), # see note ^ + ('ED C0', FFFDx2), ('ED FF', FFFDx2), ('ED 80 00', FFFD+'\x00'), + ('ED 80 7F', FFFD+'\x7f'), ('ED 80 C0', FFFDx2), + ('ED 80 FF', FFFDx2), ('ED 9F 00', FFFD+'\x00'), + ('ED 9F 7F', FFFD+'\x7f'), ('ED 9F C0', FFFDx2), + ('ED 9F FF', FFFDx2), ('EE 00', FFFD+'\x00'), + ('EE 7F', FFFD+'\x7f'), ('EE C0', FFFDx2), ('EE FF', FFFDx2), + ('EE 80 00', FFFD+'\x00'), ('EE 80 7F', FFFD+'\x7f'), + ('EE 80 C0', FFFDx2), ('EE 80 FF', FFFDx2), + ('EE BF 00', FFFD+'\x00'), ('EE BF 7F', FFFD+'\x7f'), + ('EE BF C0', FFFDx2), ('EE BF FF', FFFDx2), ('EF 00', FFFD+'\x00'), + ('EF 7F', FFFD+'\x7f'), ('EF C0', FFFDx2), ('EF FF', FFFDx2), + ('EF 80 00', FFFD+'\x00'), ('EF 80 7F', FFFD+'\x7f'), + ('EF 80 C0', FFFDx2), ('EF 80 FF', FFFDx2), + ('EF BF 00', FFFD+'\x00'), ('EF BF 7F', FFFD+'\x7f'), + ('EF BF C0', FFFDx2), ('EF BF FF', FFFDx2), + ] + for seq, res in sequences: + self.assertCorrectUTF8Decoding(self.to_bytestring(seq), res, + 'invalid continuation byte') + + def test_invalid_cb_for_4bytes_seq(self): + """ + Test that an 'invalid continuation byte' error is raised when the + continuation byte(s) of a 4-bytes sequence are invalid. When + errors='replace',the start byte and all the following valid + continuation bytes are replaced with a single U+FFFD, and all the bytes + starting from the first invalid continuation bytes (included) are + handled separately. + E.g. in the sequence <E1 80 41>, E1 is the start byte of a 3-bytes + sequence, 80 is a valid continuation byte, but 41 is not a valid cb + because it's the ASCII letter 'A'. + Note: when the start byte is E0 or ED, the valid ranges for the first + continuation byte are limited to A0..BF and 80..9F respectively. + However, when the start byte is ED, Python 2 considers all the bytes + in range 80..BF valid. This is fixed in Python 3. + """ + FFFD = '\ufffd' + FFFDx2 = FFFD * 2 + sequences = [ + ('F0 00', FFFD+'\x00'), ('F0 7F', FFFD+'\x7f'), ('F0 80', FFFDx2), + ('F0 8F', FFFDx2), ('F0 C0', FFFDx2), ('F0 FF', FFFDx2), + ('F0 90 00', FFFD+'\x00'), ('F0 90 7F', FFFD+'\x7f'), + ('F0 90 C0', FFFDx2), ('F0 90 FF', FFFDx2), + ('F0 BF 00', FFFD+'\x00'), ('F0 BF 7F', FFFD+'\x7f'), + ('F0 BF C0', FFFDx2), ('F0 BF FF', FFFDx2), + ('F0 90 80 00', FFFD+'\x00'), ('F0 90 80 7F', FFFD+'\x7f'), + ('F0 90 80 C0', FFFDx2), ('F0 90 80 FF', FFFDx2), + ('F0 90 BF 00', FFFD+'\x00'), ('F0 90 BF 7F', FFFD+'\x7f'), + ('F0 90 BF C0', FFFDx2), ('F0 90 BF FF', FFFDx2), + ('F0 BF 80 00', FFFD+'\x00'), ('F0 BF 80 7F', FFFD+'\x7f'), + ('F0 BF 80 C0', FFFDx2), ('F0 BF 80 FF', FFFDx2), + ('F0 BF BF 00', FFFD+'\x00'), ('F0 BF BF 7F', FFFD+'\x7f'), + ('F0 BF BF C0', FFFDx2), ('F0 BF BF FF', FFFDx2), + ('F1 00', FFFD+'\x00'), ('F1 7F', FFFD+'\x7f'), ('F1 C0', FFFDx2), + ('F1 FF', FFFDx2), ('F1 80 00', FFFD+'\x00'), + ('F1 80 7F', FFFD+'\x7f'), ('F1 80 C0', FFFDx2), + ('F1 80 FF', FFFDx2), ('F1 BF 00', FFFD+'\x00'), + ('F1 BF 7F', FFFD+'\x7f'), ('F1 BF C0', FFFDx2), + ('F1 BF FF', FFFDx2), ('F1 80 80 00', FFFD+'\x00'), + ('F1 80 80 7F', FFFD+'\x7f'), ('F1 80 80 C0', FFFDx2), + ('F1 80 80 FF', FFFDx2), ('F1 80 BF 00', FFFD+'\x00'), + ('F1 80 BF 7F', FFFD+'\x7f'), ('F1 80 BF C0', FFFDx2), + ('F1 80 BF FF', FFFDx2), ('F1 BF 80 00', FFFD+'\x00'), + ('F1 BF 80 7F', FFFD+'\x7f'), ('F1 BF 80 C0', FFFDx2), + ('F1 BF 80 FF', FFFDx2), ('F1 BF BF 00', FFFD+'\x00'), + ('F1 BF BF 7F', FFFD+'\x7f'), ('F1 BF BF C0', FFFDx2), + ('F1 BF BF FF', FFFDx2), ('F3 00', FFFD+'\x00'), + ('F3 7F', FFFD+'\x7f'), ('F3 C0', FFFDx2), ('F3 FF', FFFDx2), + ('F3 80 00', FFFD+'\x00'), ('F3 80 7F', FFFD+'\x7f'), + ('F3 80 C0', FFFDx2), ('F3 80 FF', FFFDx2), + ('F3 BF 00', FFFD+'\x00'), ('F3 BF 7F', FFFD+'\x7f'), + ('F3 BF C0', FFFDx2), ('F3 BF FF', FFFDx2), + ('F3 80 80 00', FFFD+'\x00'), ('F3 80 80 7F', FFFD+'\x7f'), + ('F3 80 80 C0', FFFDx2), ('F3 80 80 FF', FFFDx2), + ('F3 80 BF 00', FFFD+'\x00'), ('F3 80 BF 7F', FFFD+'\x7f'), + ('F3 80 BF C0', FFFDx2), ('F3 80 BF FF', FFFDx2), + ('F3 BF 80 00', FFFD+'\x00'), ('F3 BF 80 7F', FFFD+'\x7f'), + ('F3 BF 80 C0', FFFDx2), ('F3 BF 80 FF', FFFDx2), + ('F3 BF BF 00', FFFD+'\x00'), ('F3 BF BF 7F', FFFD+'\x7f'), + ('F3 BF BF C0', FFFDx2), ('F3 BF BF FF', FFFDx2), + ('F4 00', FFFD+'\x00'), ('F4 7F', FFFD+'\x7f'), ('F4 90', FFFDx2), + ('F4 BF', FFFDx2), ('F4 C0', FFFDx2), ('F4 FF', FFFDx2), + ('F4 80 00', FFFD+'\x00'), ('F4 80 7F', FFFD+'\x7f'), + ('F4 80 C0', FFFDx2), ('F4 80 FF', FFFDx2), + ('F4 8F 00', FFFD+'\x00'), ('F4 8F 7F', FFFD+'\x7f'), + ('F4 8F C0', FFFDx2), ('F4 8F FF', FFFDx2), + ('F4 80 80 00', FFFD+'\x00'), ('F4 80 80 7F', FFFD+'\x7f'), + ('F4 80 80 C0', FFFDx2), ('F4 80 80 FF', FFFDx2), + ('F4 80 BF 00', FFFD+'\x00'), ('F4 80 BF 7F', FFFD+'\x7f'), + ('F4 80 BF C0', FFFDx2), ('F4 80 BF FF', FFFDx2), + ('F4 8F 80 00', FFFD+'\x00'), ('F4 8F 80 7F', FFFD+'\x7f'), + ('F4 8F 80 C0', FFFDx2), ('F4 8F 80 FF', FFFDx2), + ('F4 8F BF 00', FFFD+'\x00'), ('F4 8F BF 7F', FFFD+'\x7f'), + ('F4 8F BF C0', FFFDx2), ('F4 8F BF FF', FFFDx2) + ] + for seq, res in sequences: + self.assertCorrectUTF8Decoding(self.to_bytestring(seq), res, + 'invalid continuation byte') + def test_codecs_idna(self): # Test whether trailing dot is preserved self.assertEqual("www.python.org.".encode("idna"), b"www.python.org.") diff -r ec656d79b8ac Objects/stringlib/codecs.h --- a/Objects/stringlib/codecs.h Sat Jun 23 22:55:58 2012 +0200 +++ b/Objects/stringlib/codecs.h Sun Jun 24 00:20:16 2012 +0300 @@ -94,15 +94,14 @@ } } - if (ch < 0xC2) { - /* invalid sequence - \x80-\xBF -- continuation byte - \xC0-\xC1 -- fake 0000-007F */ - goto InvalidStart; - } - if (ch < 0xE0) { /* \xC2\x80-\xDF\xBF -- 0080-07FF */ + if (ch < 0xC2) { + /* invalid sequence + \x80-\xBF -- continuation byte + \xC0-\xC1 -- fake 0000-007F */ + goto InvalidStart; + } Py_UCS4 ch2; if (end - s < 2) { /* unexpected end of data: the caller will decide whether @@ -112,14 +111,15 @@ ch2 = (unsigned char)s[1]; if (!IS_CONTINUATION_BYTE(ch2)) /* invalid continuation byte */ - goto InvalidContinuation; + goto InvalidContinuation1; ch = (ch << 6) + ch2 - ((0xC0 << 6) + 0x80); assert ((ch > 0x007F) && (ch <= 0x07FF)); s += 2; if (STRINGLIB_MAX_CHAR <= 0x007F || (STRINGLIB_MAX_CHAR < 0x07FF && ch > STRINGLIB_MAX_CHAR)) - goto Overflow; + /* Out-of-range */ + goto Return; *p++ = ch; continue; } @@ -130,28 +130,37 @@ if (end - s < 3) { /* unexpected end of data: the caller will decide whether it's an error or not */ + if (end - s < 2) + break; + ch2 = (unsigned char)s[1]; + if (!IS_CONTINUATION_BYTE(ch2) || + (ch2 < 0xA0 ? ch == 0xE0 : ch == 0xED)) + /* for clarification see comments below */ + goto InvalidContinuation1; break; } ch2 = (unsigned char)s[1]; ch3 = (unsigned char)s[2]; - if (!IS_CONTINUATION_BYTE(ch2) || - !IS_CONTINUATION_BYTE(ch3)) { + if (!IS_CONTINUATION_BYTE(ch2)) { /* invalid continuation byte */ - goto InvalidContinuation; + goto InvalidContinuation1; } if (ch == 0xE0) { if (ch2 < 0xA0) /* invalid sequence \xE0\x80\x80-\xE0\x9F\xBF -- fake 0000-0800 */ - goto InvalidContinuation; - } - else if (ch == 0xED && ch2 > 0x9F) { + goto InvalidContinuation1; + } else if (ch == 0xED && ch2 >= 0xA0) { /* Decoding UTF-8 sequences in range \xED\xA0\x80-\xED\xBF\xBF will result in surrogates in range D800-DFFF. Surrogates are not valid UTF-8 so they are rejected. See http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf (table 3-7) and http://www.rfc-editor.org/rfc/rfc3629.txt */ - goto InvalidContinuation; + goto InvalidContinuation1; + } + if (!IS_CONTINUATION_BYTE(ch3)) { + /* invalid continuation byte */ + goto InvalidContinuation2; } ch = (ch << 12) + (ch2 << 6) + ch3 - ((0xE0 << 12) + (0x80 << 6) + 0x80); @@ -159,7 +168,8 @@ s += 3; if (STRINGLIB_MAX_CHAR <= 0x07FF || (STRINGLIB_MAX_CHAR < 0xFFFF && ch > STRINGLIB_MAX_CHAR)) - goto Overflow; + /* Out-of-range */ + goto Return; *p++ = ch; continue; } @@ -170,27 +180,44 @@ if (end - s < 4) { /* unexpected end of data: the caller will decide whether it's an error or not */ + if (end - s < 2) + break; + ch2 = (unsigned char)s[1]; + if (!IS_CONTINUATION_BYTE(ch2) || + (ch2 < 0x90 ? ch == 0xF0 : ch == 0xF4)) + /* for clarification see comments below */ + goto InvalidContinuation1; + if (end - s < 3) + break; + ch3 = (unsigned char)s[2]; + if (!IS_CONTINUATION_BYTE(ch3)) + goto InvalidContinuation2; break; } ch2 = (unsigned char)s[1]; ch3 = (unsigned char)s[2]; ch4 = (unsigned char)s[3]; - if (!IS_CONTINUATION_BYTE(ch2) || - !IS_CONTINUATION_BYTE(ch3) || - !IS_CONTINUATION_BYTE(ch4)) { + if (!IS_CONTINUATION_BYTE(ch2)) { /* invalid continuation byte */ - goto InvalidContinuation; + goto InvalidContinuation1; } if (ch == 0xF0) { if (ch2 < 0x90) /* invalid sequence - \xF0\x80\x80\x80-\xF0\x80\xBF\xBF -- fake 0000-FFFF */ - goto InvalidContinuation; - } - else if (ch == 0xF4 && ch2 > 0x8F) { + \xF0\x80\x80\x80-\xF0\x8F\xBF\xBF -- fake 0000-FFFF */ + goto InvalidContinuation1; + } else if (ch == 0xF4 && ch2 >= 0x90) { /* invalid sequence \xF4\x90\x80\80- -- 110000- overflow */ - goto InvalidContinuation; + goto InvalidContinuation1; + } + if (!IS_CONTINUATION_BYTE(ch3)) { + /* invalid continuation byte */ + goto InvalidContinuation2; + } + if (!IS_CONTINUATION_BYTE(ch4)) { + /* invalid continuation byte */ + goto InvalidContinuation3; } ch = (ch << 18) + (ch2 << 12) + (ch3 << 6) + ch4 - ((0xF0 << 18) + (0x80 << 12) + (0x80 << 6) + 0x80); @@ -198,14 +225,14 @@ s += 4; if (STRINGLIB_MAX_CHAR <= 0xFFFF || (STRINGLIB_MAX_CHAR < 0x10FFFF && ch > STRINGLIB_MAX_CHAR)) - goto Overflow; + /* Out-of-range */ + goto Return; *p++ = ch; continue; } goto InvalidStart; } ch = 0; -Overflow: Return: *inptr = s; *outpos = p - dest; @@ -213,13 +240,18 @@ InvalidStart: ch = 1; goto Return; -InvalidContinuation: +InvalidContinuation1: ch = 2; goto Return; +InvalidContinuation2: + ch = 3; + goto Return; +InvalidContinuation3: + ch = 4; + goto Return; } #undef ASCII_CHAR_MASK -#undef IS_CONTINUATION_BYTE /* UTF-8 encoder specialized for a Unicode kind to avoid the slow diff -r ec656d79b8ac Objects/unicodeobject.c --- a/Objects/unicodeobject.c Sat Jun 23 22:55:58 2012 +0200 +++ b/Objects/unicodeobject.c Sun Jun 24 00:20:16 2012 +0300 @@ -4763,9 +4763,7 @@ goto End; errmsg = "unexpected end of data"; startinpos = s - starts; - endinpos = startinpos + 1; - while (endinpos < size && (starts[endinpos] & 0xC0) == 0x80) - endinpos++; + endinpos = end - starts; break; case 1: errmsg = "invalid start byte"; @@ -4773,11 +4771,11 @@ endinpos = startinpos + 1; break; case 2: + case 3: + case 4: errmsg = "invalid continuation byte"; startinpos = s - starts; - endinpos = startinpos + 1; - while (endinpos < size && (starts[endinpos] & 0xC0) == 0x80) - endinpos++; + endinpos = startinpos + ch - 1; break; default: if (unicode_putchar(&unicode, &outpos, ch) < 0) From report at bugs.python.org Sat Jun 23 23:21:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 21:21:57 +0000 Subject: [issue15146] Implemented PyType_FromSpecWithBases In-Reply-To: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za> Message-ID: <E1SiXmE-00077U-H4@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset bb6df3781edb by Martin v. L?wis in branch 'default': Issue #15146: Add PyType_FromSpecWithBases. Patch by Robin Schreiber. http://hg.python.org/cpython/rev/bb6df3781edb ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15146> _______________________________________ From report at bugs.python.org Sat Jun 23 23:23:08 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 21:23:08 +0000 Subject: [issue15146] Implemented PyType_FromSpecWithBases In-Reply-To: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za> Message-ID: <1340486588.74.0.869049857059.issue15146@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Thanks for the patch. Committed with slight modifications: if the spec contained a tp_base/tp_bases pointer, that needed to be considered. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15146> _______________________________________ From report at bugs.python.org Sat Jun 23 23:33:23 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 21:33:23 +0000 Subject: [issue13115] tp_as_{number, sequence, mapping} can't be set using PyType_FromSpec In-Reply-To: <1317910226.56.0.365091018544.issue13115@psf.upfronthosting.co.za> Message-ID: <1340487203.69.0.902772178486.issue13115@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: For 3.3, this is fixed in bb6df3781edb. However, this needs to be backported to 3.2. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13115> _______________________________________ From report at bugs.python.org Sat Jun 23 23:37:26 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 23 Jun 2012 21:37:26 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340487446.76.0.875723899767.issue15139@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Well, the rationale for keeping the try_finally is that the Condition should continue to work with other Locks, as long as they provide _release_save and _acquire_restore methods. Lock._acquire_condtion onnly knows Lock and RLock intimately enough to automatically reaquire them with teh GIL released. If I remove the _acuire_restore, we have prohibited the Condition class from using customized locks, or subclasses of locks. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Sat Jun 23 23:47:26 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 23 Jun 2012 21:47:26 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340488046.38.0.262807503621.issue15139@psf.upfronthosting.co.za> Changes by Gregory P. Smith <greg at krypto.org>: ---------- nosy: +gregory.p.smith _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Sat Jun 23 23:47:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 21:47:53 +0000 Subject: [issue15146] Implemented PyType_FromSpecWithBases In-Reply-To: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za> Message-ID: <1340488073.94.0.45911894693.issue15146@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: There was a crash here: http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/4014/steps/test/logs/stdio ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15146> _______________________________________ From report at bugs.python.org Sat Jun 23 23:48:10 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Jun 2012 21:48:10 +0000 Subject: [issue14226] Expose dict_proxy type from descrobject.c In-Reply-To: <1331163340.11.0.494916770875.issue14226@psf.upfronthosting.co.za> Message-ID: <1340488090.0.0.364532113951.issue14226@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: ---------- resolution: -> duplicate status: open -> closed superseder: -> Expose dict_proxy internal type as types.MappingProxyType _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14226> _______________________________________ From report at bugs.python.org Sat Jun 23 23:48:41 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 23 Jun 2012 21:48:41 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340488121.56.0.526534910956.issue15061@psf.upfronthosting.co.za> Changes by Gregory P. Smith <greg at krypto.org>: ---------- nosy: +gregory.p.smith _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sun Jun 24 00:01:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 22:01:17 +0000 Subject: [issue11626] Py_LIMITED_API on windows: unresolved symbol __imp___PyArg_ParseTuple_SizeT In-Reply-To: <1300733675.89.0.959184580863.issue11626@psf.upfronthosting.co.za> Message-ID: <E1SiYOJ-0002xM-F4@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 3f14119e4af7 by Martin v. L?wis in branch 'default': Issue #11626: Add _SizeT functions to stable ABI. http://hg.python.org/cpython/rev/3f14119e4af7 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11626> _______________________________________ From report at bugs.python.org Sun Jun 24 00:02:44 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 22:02:44 +0000 Subject: [issue11626] Py_LIMITED_API on windows: unresolved symbol __imp___PyArg_ParseTuple_SizeT In-Reply-To: <1300733675.89.0.959184580863.issue11626@psf.upfronthosting.co.za> Message-ID: <1340488964.0.0.403097848915.issue11626@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: As some time has passed (unfortunately), I now decided to add these functions only to the stable ABI of 3.3+. I'd appreciate if you could review the beta releases and comment whether they fix the issue. Notice that you will have to set Py_LIMITED_API to 0x03030000 (or higher) to access them. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11626> _______________________________________ From report at bugs.python.org Sun Jun 24 00:03:54 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 22:03:54 +0000 Subject: [issue14286] xxlimited.obj: unresolved external symbol __imp__PyObject_New In-Reply-To: <1331634330.54.0.0691133791003.issue14286@psf.upfronthosting.co.za> Message-ID: <1340489034.17.0.182891756915.issue14286@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Closing as works-for-me. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14286> _______________________________________ From report at bugs.python.org Sun Jun 24 00:06:45 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jun 2012 22:06:45 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340489205.84.0.908569399705.issue15133@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Just that, which I used to verify with 2.7.3 and 3.3.0a4 in Win7 and do some more experiments: bv.set/get happily accept *and return* 2, -1, bv.set(2.2) 'works' bv.get() then raises TypeError: must be str, not float This will annoy you ;-) bv.set('1'); bv.get() returns True, '0'=>False most other string inputs raise ValueError: invalid literal for getboolean() (but see below). Doc: "There are many useful subclasses of Variable already defined: StringVar, IntVar, DoubleVar, and BooleanVar." Looking into tkinter.__init__, *all* subclasses just inherit Variable.set(self, value): return self._tk.globalsetvar(self._name, value). So there is no input validation or conversion. I wonder is here should be? It appears that anything can be set to anything. I was thinking that everything was converted to a string, and the error message for 2.2 above suggests that, but the (surprising to me) different behavior of 1 and '1' says that is not right. So does iv=IntVar(); iv.set(2.2); iv.get() returning 2. Variable.get(self) returns self._tk.globalgetvar(self._name). String/Int/Double/Var call str/int/float as appropriate. BooleanVar calls tk.getboolean which is supposed to "Convert true and false to integer values 1 and 0.". Well, it should not do that and does not do that for tcl false and true, as with '0' and '1'. Further checking shows that 'no', 'false', 'yes', 'true' or any prefix thereof return False or True as desired. So getboolean was partially changed after the introduction of bool to return bool instead int for tcl booleans, but it was not changed to convert ints to bool. And if one inputs a Python bool, it somehow gets converted to an int instead of being returned as is. I see three possible fixes, but I do not know enough of tk/inter usage to choose. 1) add BooleanVar.set to convert Python bool to tcl bool. Other python objects could be converted, except that some people might be using python strings that become tcl bools (as above) which come back as python bools. 2. change getboolean to not convert python bool (if that is where is happens) and do convert int to bool (just 0,1 or all ints?). 3. change BooleanVar.get to convert 0/1 (or all returns?) to False/True. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Sun Jun 24 00:16:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 23 Jun 2012 22:16:22 +0000 Subject: [issue15146] Implemented PyType_FromSpecWithBases In-Reply-To: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za> Message-ID: <1340489782.06.0.52800308787.issue15146@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I have no clue what might have caused this. My guess is that there is a refcounting bug *somewhere*. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15146> _______________________________________ From report at bugs.python.org Sun Jun 24 00:22:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 22:22:37 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <E1SiYix-0004HO-Hd@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 9c71d7f057b3 by Martin v. L?wis in branch 'default': Issue #15102: find python.exe in OutDir, not SolutionDir. http://hg.python.org/cpython/rev/9c71d7f057b3 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 00:48:00 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Jun 2012 22:48:00 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1340491680.07.0.322189711613.issue15003@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: Here's an updated patch to address the use of _PyNamespace_New() in changeset 77414:0011536f2a06. ---------- Added file: http://bugs.python.org/file26119/issue15003_public.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Sun Jun 24 00:48:31 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 Jun 2012 22:48:31 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1340491711.31.0.64119951229.issue15003@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: Removed file: http://bugs.python.org/file25853/issue15003_public.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Sun Jun 24 00:59:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 22:59:17 +0000 Subject: [issue15146] Implemented PyType_FromSpecWithBases In-Reply-To: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za> Message-ID: <1340492357.46.0.619957229993.issue15146@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Ok, 33737210c906 seems to have fixed it. ---------- stage: -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15146> _______________________________________ From report at bugs.python.org Sun Jun 24 01:03:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 23:03:27 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <E1SiZMP-0006o6-PD@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 688d48e434e4 by Ned Deily in branch 'default': Issue #13590: Improve support for OS X Xcode 4: http://hg.python.org/cpython/rev/688d48e434e4 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Sun Jun 24 01:08:19 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 23 Jun 2012 23:08:19 +0000 Subject: [issue15078] Change os.sendfile so its arguments are stable In-Reply-To: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za> Message-ID: <1340492899.7.0.704897133986.issue15078@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: It is usually folly to disagree with MvL, and yet I am about to do just that. As stated, I don't believe in the "thin wrappers" theory of os; where would a Windows programmer find the man page to learn how os.access works on their system? I think os should provide helpful functionality to the programmer, specifically functions that are calling into the system API. But unlike MvL I would *much* rather see consistent functionality across systems than expose the Python programmer to every fiddling nook and cranny of the local API. I prefer "Python" programs to "Python-on-Linux" and "Python-on-Windows" programs. Yet, as much as I'm willing to disagree with MvL, I'm not so sure of myself that I'll check this in against his wishes. If this idea wins more support in the future, we could still make my proposed change to the interface without breaking backwards-compatibility. So I volunteer to table the discussion at least for the 3.3 release. TBH I don't see the benefit of the extra three parameters anyway. headers/trailers is redundant with os.writev, and the three flags are for shaving off cycles that are lost in the noise of the Python interpreter. If I ran the circus I'd remove the latter three parameters and have the same interface everywhere sendfile is available. But I suspect there's no way I can get away with *that* for the 3.3 beta, and once we hit feature freeze I won't be able to remove it. So I guess we're just going to be stuck with them forever. *sigh* -- Let me controversially, hypothetically, propose: if we really want to make raw OS functions available to Python programmers, then so be it, but not in the os module. We could add an "osx" module, and a "linux" module, and a "freebsd" module, and a "win32" module (though I suppose win32all covers that). And we could ditch the whole "rename posix to os" shenanigans. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15078> _______________________________________ From report at bugs.python.org Sun Jun 24 01:21:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Jun 2012 23:21:45 +0000 Subject: [issue15155] sporadic failure in RecvmsgSCTPStreamTest Message-ID: <1340493704.97.0.818384658063.issue15155@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: Sometimes seen on buildbots (e.g. http://www.python.org/dev/buildbot/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/309/steps/test/logs/stdio ). It seems it's always testRecvmsgEOF which fails. $ ./python -m test -m RecvmsgSCTPStreamTest -unetwork -Fv test_socket [...] [ 36] test_socket testRecvmsg (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgAfterClose (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgBadArgs (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgEOF (test.test_socket.RecvmsgSCTPStreamTest) ... ERROR testRecvmsgExplicitDefaults (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgFromSendmsg (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgLongAncillaryBuf (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgOverflow (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgPeek (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgShortAncillaryBuf (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgShorter (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgTimeout (test.test_socket.RecvmsgSCTPStreamTest) ... ok testRecvmsgTrunc (test.test_socket.RecvmsgSCTPStreamTest) ... ok ====================================================================== ERROR: testRecvmsgEOF (test.test_socket.RecvmsgSCTPStreamTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/test/test_socket.py", line 2192, in testRecvmsgEOF msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024) File "/home/antoine/cpython/default/Lib/test/test_socket.py", line 1683, in doRecvmsg result = sock.recvmsg(bufsize, *args) OSError: [Errno 107] Transport endpoint is not connected ---------------------------------------------------------------------- ---------- components: Library (Lib), Tests messages: 163693 nosy: giampaolo.rodola, neologix, pitrou priority: normal severity: normal status: open title: sporadic failure in RecvmsgSCTPStreamTest type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15155> _______________________________________ From report at bugs.python.org Sun Jun 24 01:55:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Jun 2012 23:55:47 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir In-Reply-To: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> Message-ID: <E1SiaB7-0001RM-CO@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 3b7230997425 by Larry Hastings in branch 'default': Issue #15154: Add "dir_fd" parameter to os.rmdir, remove "rmdir" http://hg.python.org/cpython/rev/3b7230997425 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sun Jun 24 01:56:56 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 23 Jun 2012 23:56:56 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir In-Reply-To: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> Message-ID: <1340495816.97.0.79231721973.issue15154@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I made two documentation changes to the patch before committing it: * I restored the text under os.remove about how it doesn't handle directories. * I added a Misc/NEWS entry. But I didn't have to touch the code--that looked dead-on to me. Proper job, Georg! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sun Jun 24 01:58:06 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 23 Jun 2012 23:58:06 +0000 Subject: [issue15154] remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir In-Reply-To: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za> Message-ID: <1340495886.56.0.381393838273.issue15154@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15154> _______________________________________ From report at bugs.python.org Sun Jun 24 02:07:50 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 24 Jun 2012 00:07:50 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340496470.8.0.055721809264.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: New patch. I've removed the special handling of PyBytes_CheckExact, support subclasses of str, non compact ASCII str and updated the docs. (Next time I'll create a sandbox and push my work to its own branch.) ---------- Added file: http://bugs.python.org/file26120/compare_digest_c-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sun Jun 24 02:17:48 2012 From: report at bugs.python.org (Glenn Linderman) Date: Sun, 24 Jun 2012 00:17:48 +0000 Subject: [issue15016] Add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1340497068.05.0.903185561314.issue15016@psf.upfronthosting.co.za> Glenn Linderman <v+python at g.nevcal.com> added the comment: Patch is interesting, using an encoder to detect validity. However, it suffers from some performance problems for long text that has large ASCII prefixes. This seems to be an enhancement sort of request rather than a bug... so I wonder why Python 3.2 is listed? And in Python 3.3 with PEP 393 strings the C API to strings provides a quick way to determine the maximum character in the string... although I see nothing in the PEP about how to access that information from Python. If it is available, it could provide a much quicker precheck rather than multiple attempts to encode strings with large ASCII prefixes only to discover that the next to last character is in (128,255) and the last character is > 255 (which would be about the worst case scenario for the algorithm in the patch). ---------- nosy: +v+python _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Sun Jun 24 03:38:11 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 01:38:11 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340501891.17.0.292150423324.issue15118@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Okay, this patch is definitely ready. Changes from the last patch: * The two return types are now exposed in the os module (os.uname_result and os.times_result) and are permanently on even if os.uname() or os.times() are not available. * I updated the library to use the field names where appropriate. Fun trivia: there are no uses of os.times() in the library--not even in the regression test suite. Of course, with the patch applied python passes the entire regression test suite. (Of course!) Can I get a review? ---------- Added file: http://bugs.python.org/file26121/larry.uname.and.times.structseq.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sun Jun 24 04:00:52 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 02:00:52 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340503252.03.0.117952766137.issue15147@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: On it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 04:25:21 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 02:25:21 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340504721.31.0.903509168044.issue15147@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: The sysconfig module was modified (and sysconfig.cfg was introduced) to serve the needs of the resource system (install_data putting files into system-configured locations and packaging.database finding them); one of the thousand things mentioned in the ?Status of Packaging? thread was an opinion by PJE that this was a bad choice, and even if I disagree (being a Debian guy and all :), a PEP would be in order to decide on such a big new functionality. Should these changes be reverted too? (I?d think yes.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 04:37:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 02:37:51 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <E1Sichx-0001xt-SM@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2b54e25d6ecb by Ezio Melotti in branch 'default': #11113: add a new "html5" dictionary containing the named character references defined by the HTML5 standard and the equivalent Unicode character(s) to the html.entities module. http://hg.python.org/cpython/rev/2b54e25d6ecb ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sun Jun 24 04:40:13 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 24 Jun 2012 02:40:13 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340505613.54.0.39827211313.issue11113@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sun Jun 24 04:45:43 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 24 Jun 2012 02:45:43 +0000 Subject: [issue15156] Refactor HTMLParser.unescape to use html.entities.html5 Message-ID: <1340505943.38.0.45190182563.issue15156@psf.upfronthosting.co.za> New submission from Ezio Melotti <ezio.melotti at gmail.com>: HTMLParser has an internal method called unescape [0] used to convert named character references to the equivalent characters, and it does so by using html.entities.name2codepoint to recreate the equivalent of html.entities.entityrefs with the addition of '. Now that the html5 entities have been added to html.entities, the parser should use them instead of name2codepoint. [0]: see Lib/html/parser.py:500 ---------- assignee: ezio.melotti components: Library (Lib) messages: 163702 nosy: eric.araujo, ezio.melotti, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Refactor HTMLParser.unescape to use html.entities.html5 type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15156> _______________________________________ From report at bugs.python.org Sun Jun 24 04:47:23 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 02:47:23 +0000 Subject: [issue15157] venvs should include pydoc Message-ID: <1340506043.04.0.340918087163.issue15157@psf.upfronthosting.co.za> New submission from ?ric Araujo <merwok at netwok.org>: To get documentation about a module installed in a venv, one needs to use ?python -m pydoc? instead of just ?pydoc?; I would like a pydoc script with the appropriate shebang to be installed in the venv?s bin dir. Similar request in virtualenv for the reference: https://github.com/pypa/virtualenv/issues/149 ---------- assignee: vinay.sajip components: Library (Lib) messages: 163703 nosy: carljm, eric.araujo, vinay.sajip priority: normal severity: normal status: open title: venvs should include pydoc type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15157> _______________________________________ From report at bugs.python.org Sun Jun 24 04:59:50 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 02:59:50 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340506790.6.0.503491147536.issue11113@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: The ';' is not part of the entity name but an SGML delimiter, like '&'; the strings in the dict should not include it (like in the other dict they don?t). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sun Jun 24 05:04:31 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 03:04:31 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340507071.27.0.734445662225.issue11113@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: BTW in the doc you may point to collections.ChainMap to explain to people how to make one dict with HTML 4 and HTML 5 entities. (Note that I assume there are two dicts, but I only skimmed the diff.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sun Jun 24 05:11:36 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 24 Jun 2012 03:11:36 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340507496.32.0.519686741143.issue11113@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: The problem is that the standard allows some charref to end without a ';', but not all of them. So both "Éric" and Éric" will be parsed as "?ric", but only "αcentauri" will result in "?centauri" -- "&alphacentauri" will be returned unchanged. I'm now working on #15156 to use this dict in HTMLParser, and detecting the ';'-less entities is not easy. A possible solution is to keep the names that are accepted without ',' in a separate (private) dict and expose a function like HTMLParser.unescape that implements all the necessary logic. Regarding ChainMap, the html5 dict should be a superset of the html4 one. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sun Jun 24 05:32:55 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 03:32:55 +0000 Subject: [issue11113] html.entities mapping dicts need updating? In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za> Message-ID: <1340508775.11.0.749605944149.issue11113@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: The explanations make sense, don?t change anything. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11113> _______________________________________ From report at bugs.python.org Sun Jun 24 05:47:25 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 24 Jun 2012 03:47:25 +0000 Subject: [issue15158] Add support for multi-character delimiters in csv Message-ID: <1340509645.86.0.375714044709.issue15158@psf.upfronthosting.co.za> New submission from Ramchandra Apte <maniandram01 at gmail.com>: It would be nice if csv supported multi-character delimiters. I need it for my project. Another person had this problem: http://stackoverflow.com/questions/6352409/how-to-use-python-csv-module-for-splitting-double-pipe-delimited-data . ---------- components: Library (Lib) messages: 163708 nosy: ramchandra.apte priority: normal severity: normal status: open title: Add support for multi-character delimiters in csv type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15158> _______________________________________ From report at bugs.python.org Sun Jun 24 05:51:23 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 24 Jun 2012 03:51:23 +0000 Subject: [issue15158] Add support for multi-character delimiters in csv In-Reply-To: <1340509645.86.0.375714044709.issue15158@psf.upfronthosting.co.za> Message-ID: <1340509883.98.0.37478638289.issue15158@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: BTW, conincidentally just like the stackoverflow, even I want to split double pipes ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15158> _______________________________________ From report at bugs.python.org Sun Jun 24 06:21:26 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 04:21:26 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340511686.02.0.374583802745.issue15147@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Packaging removed in 576b8b182039. I?m going to wait an hour or two and in the absence of feedback will remove sysconfig.cfg too; that will be easy to revert if consensus was to keep it and I was not online (but I really think sysconfig.cfg should go). I?ll also look at the buildbots. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 06:31:13 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 24 Jun 2012 04:31:13 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340512273.22.0.865651047428.issue15147@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Why are you removing packaging? ---------- nosy: +ramchandra.apte _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 06:43:40 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 24 Jun 2012 04:43:40 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340513020.23.0.73405385234.issue15147@psf.upfronthosting.co.za> Ramchandra Apte <maniandram01 at gmail.com> added the comment: Oh.. understand now packaging is being deferred. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 07:06:13 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 05:06:13 +0000 Subject: [issue15159] Add failover for follow_symlinks and effective_ids where possible Message-ID: <1340514372.7.0.0626020739455.issue15159@psf.upfronthosting.co.za> New submission from Larry Hastings <larry at hastings.org>: Serhiy Storchaka suggested (in private email, not on tracker or python-dev): why not make follow_symlinks and effective_ids failover where possible? Let's take the example of effective_ids first, that's simpler. Let's say the user calls os.access("x", os.F_OK, effective_ids=True) But they doesn't have faccessat() for some reason. IF euid==uid, and egid==gid, then it's harmless to ignore the effective_ids flag and just use normal access(). Supporting this is easy: if effective_ids=True, and !defined(HAVE_FACCESSAT), but we have all four of the get{e|}{u|g}id() functions, do the above comparison and if it is just call access(). It's a bit more complicated with follow_symlinks. Let's say they call os.chmod("x", 0o644, follow_symlinks=False) As it happens, they're on Linux so they don't have lchmod() and their fchmodat() doesn't support AT_SYMLINK_NOFOLLOW. But! "x" isn't a symbolic link! In this case normal chmod would be fine fine. How do we detect that the file is a symbolic link? That's easy, call lstat(). On Windows, if they gave us a wide path, call win32_lstat_w(). If they passed in a non-default dir_fd, call fstatat() (if available). The one place where we can't fail over gracefully: os.stat() If we don't have the appropriate native stat function (lstat or fstatat), then obviously we can't stat nofollow the file to see if it's not a symbolic link and call normal stat(). Sad face. The attached patch implements all of the above. It passes the regression test suite on Linux 64-bit (with and without pydebug) and Windows 32-bit (Debug and Release). ---------- assignee: larry files: larry.kinder.gentler.follow_symlinks.1.diff keywords: patch messages: 163713 nosy: georg.brandl, larry, pitrou, storchaka priority: normal severity: normal stage: patch review status: open title: Add failover for follow_symlinks and effective_ids where possible type: behavior Added file: http://bugs.python.org/file26122/larry.kinder.gentler.follow_symlinks.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15159> _______________________________________ From report at bugs.python.org Sun Jun 24 07:21:42 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 05:21:42 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340515302.07.0.12445700764.issue15118@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Attached is patch #3. Ned Deily advised me not to touch distutils, and packaging is in the process of being removed. So I backed out of my changes to those two packages. Apart from that the patch is the same as #2. Georg: mind if this goes in before freeze? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sun Jun 24 07:22:26 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 05:22:26 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340515346.52.0.814621932048.issue15118@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Whoops, here's the patch. ---------- Added file: http://bugs.python.org/file26123/larry.uname.and.times.structseq.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sun Jun 24 07:46:39 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 05:46:39 +0000 Subject: [issue14917] Make os.symlink on Win32 detect if target is directory In-Reply-To: <1337962561.24.0.688592071719.issue14917@psf.upfronthosting.co.za> Message-ID: <1340516799.23.0.317482174391.issue14917@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Patch attached. Implementation now uses GetFileAttributes (A or W) to determine whether or not src is a directory. Fixed docstring, docs, and updated Misc/NEWS. ---------- assignee: -> larry keywords: +patch nosy: +mhammond stage: needs patch -> patch review Added file: http://bugs.python.org/file26124/larry.deprecate.target_is_directory.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14917> _______________________________________ From report at bugs.python.org Sun Jun 24 08:00:04 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 06:00:04 +0000 Subject: [issue14917] Make os.symlink on Win32 detect if target is directory In-Reply-To: <1337962561.24.0.688592071719.issue14917@psf.upfronthosting.co.za> Message-ID: <1340517604.39.0.284588678647.issue14917@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Note: I can't test this, as I only run Windows XP. But it compiles cleanly on Windows, and on Linux it compiles and passes the test suite fine. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14917> _______________________________________ From report at bugs.python.org Sun Jun 24 08:00:51 2012 From: report at bugs.python.org (Dmitry Shachnev) Date: Sun, 24 Jun 2012 06:00:51 +0000 Subject: [issue15016] Add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1340517651.8.0.518683369949.issue15016@psf.upfronthosting.co.za> Dmitry Shachnev <Mitya57 at gmail.com> added the comment: > This seems to be an enhancement sort of request rather than a bug... so I wonder why Python 3.2 is listed? Fixed. > ... although I see nothing in the PEP about how to access that information from Python. You are right, it seems there is no Python API for that (yet?), so I don't see any better solutions for determining the maximum character for now. Also, note that this algorithm had already been used before my patch. ---------- type: behavior -> enhancement versions: -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Sun Jun 24 08:01:41 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 06:01:41 +0000 Subject: [issue14815] random_seed uses only 32-bits of hash on Win64 In-Reply-To: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za> Message-ID: <1340517701.63.0.212070656884.issue14815@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I got bored so I made you a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file26125/larry.random_seed.ssize_t.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14815> _______________________________________ From report at bugs.python.org Sun Jun 24 08:08:20 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 06:08:20 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340518100.53.0.860663460423.issue15118@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- assignee: -> larry stage: -> patch review type: -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sun Jun 24 08:16:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 06:16:18 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <E1Sig7M-00070S-I6@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 796d9fc28e95 by Ned Deily in branch 'default': Issue #13590: Improve support for OS X Xcode 4: http://hg.python.org/cpython/rev/796d9fc28e95 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Sun Jun 24 08:20:34 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 06:20:34 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340518834.84.0.0869235985703.issue4489@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Can I suggest setting a ?safe? attribute on the rmtree function object instead of adding another name to the module? ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:26:29 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 06:26:29 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340519189.83.0.452224217913.issue4489@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: I thought about that too but couldn't find a precedent (I didn't look very long though :)) where we've done that before so I went for an attribute. I'd change it immediately if others agree. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:28:04 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jun 2012 06:28:04 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340519284.58.0.574109401336.issue4489@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I'm in the process of updating the LBYL support to use a "rmtree.avoids_symlink_attacks" function attribute rather than the "rmtree_is_safe" module level attribute. As I said in the hmac.secure_compare function discussion, the words "safe" and "secure" are too vague to ever make for good API design. Much better to tell people exactly what they're safe against (rmtree_is_safe -> rmtree.avoids_symlink_attacks), or designed to be appropriate for (hmac.secure_compare -> hmac.compare_digest). ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:28:59 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 06:28:59 +0000 Subject: [issue13512] ~/.pypirc created insecurely In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za> Message-ID: <1340519339.87.0.106138318286.issue13512@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Do you have links to those patches? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13512> _______________________________________ From report at bugs.python.org Sun Jun 24 08:29:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 06:29:00 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1340519340.14.0.207487727093.issue14772@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Thanks! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14772> _______________________________________ From report at bugs.python.org Sun Jun 24 08:31:00 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 06:31:00 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340519460.5.0.20528006393.issue4489@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Excellent Nick! I discussed the very same thing with David yesterday but somehow we didn't come up with a good name. So we kept it on "safe" (which predates the secure discussion). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:33:49 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 06:33:49 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1340519629.95.0.242458537024.issue15056@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > So sys.dont_write_bytecode is there to prevent bytecode writing but not loading. Ah right. Providing a way to avoid reading them sounds good. > If you set sys.implementation.cache_tag to None you stop all bytecode usage (reading and writing) This I feel uncomfortable with. First, I would separate writing and reading; second, I think of sys.implementation as a read-only information holder, and would think it immutable (note that I haven?t read the latest version of the PEP); just like sys.flags.dont_write_bytecode does not change but sys.dont_write_bytecode can change. So even though I think sys has a lot of attributes, the cleanest thing here would be a new sys.dont_read_bytecode attribute (as was proposed in the thread), maybe also with a new command-line option (or using -BB) and environment variable. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Sun Jun 24 08:35:13 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 06:35:13 +0000 Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?= =?utf-8?b?dF9fIGZhaWxz?= In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za> Message-ID: <1340519713.92.0.322726373624.issue10053@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I don?t know; Antoine is the io expert. I just remember that io used to be in C and was moved to _pyio for documentation and experimentation purposes, so I was sure it was a fully standalone lib but I could be mistaken. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10053> _______________________________________ From report at bugs.python.org Sun Jun 24 08:36:55 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 06:36:55 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340519815.42.0.370836717709.issue4489@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Bikeshedding: (os.unlink in os.supports_dir_fd and os.open in os.supports_dir_fd) could be rewritten as { os.open, os.unlink } <= os.supports_dir_fd As you were! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:37:42 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 24 Jun 2012 06:37:42 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1340519862.42.0.0876220217831.issue15056@psf.upfronthosting.co.za> Eric Snow <ericsnowcurrently at gmail.com> added the comment: Brett meant the implementation would set it. You'd still expect it to not change values during the execution of the interpreter. I suppose anyone could change that value, but I'd see that more as a consenting adults situation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Sun Jun 24 08:42:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 06:42:05 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340520125.8.0.923122930859.issue4489@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: The code using set operations seems slightly too cryptic for me, even though I?m comfortable with sets and functions as first-class objects. A matter of taste I guess. BTW it sounds a bit strange to me to have the verb in the singular in supports_dir_fd when its meaning is ?the functions in this set support dir_fd?. I guess it?s too late to propose ?os.open.supports_dir_fd and os.unlink.supports_dir_fd? (and I don?t know if that is feasible with C functions) :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:43:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 06:43:21 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <E1SigXY-0008Nz-HG@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c2be81151994 by Nick Coghlan in branch 'default': Issue #4489: Rename the feature marker for the symlink resistant rmtree and store it as a function attribute http://hg.python.org/cpython/rev/c2be81151994 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:44:06 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 06:44:06 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340520246.72.0.18998716501.issue4489@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > I guess it?s too late to propose ?os.open.supports_dir_fd and > os.unlink.supports_dir_fd? (and I don?t know if that is feasible > with C functions) :) Where were you when "is_implemented" was being savagely torn apart last week? ;-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:46:27 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 06:46:27 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340520387.45.0.187434354771.issue4489@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I was at work, and moving out of my apartment, and desperating at the subthreads spawned by my mail about packaging, and agreeing with the people being -1 on is_implemented on Signature objects :-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:46:41 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jun 2012 06:46:41 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340520401.24.0.571809032983.issue4489@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: ?ric - there's almost certainly going to be a PEP for 3.4 about doing this kind of feature advertisement in a cleaner and more consistent way. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:48:20 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 06:48:20 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340520500.74.0.340951575928.issue4489@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Yep, that is promising. At worst we?ll have a new cool API and three obsolete sets in the os module, not a big deal. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 08:56:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 24 Jun 2012 06:56:03 +0000 Subject: [issue14815] random_seed uses only 32-bits of hash on Win64 In-Reply-To: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za> Message-ID: <1340520963.51.0.433728638512.issue14815@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: LGTM ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14815> _______________________________________ From report at bugs.python.org Sun Jun 24 09:08:23 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 07:08:23 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340521703.55.0.771176729954.issue4489@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Okay everyone, let's call it day ? after 3,5 years. :) Further enhancement requests please in separate tickets. Thanks to everybody who took part! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Sun Jun 24 09:20:21 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jun 2012 07:20:21 +0000 Subject: [issue1767933] Badly formed XML using etree and utf-16 Message-ID: <1340522421.58.0.228994040366.issue1767933@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: It would be nice to fix this bug before forking of the 3.3.0b1 release clone. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1767933> _______________________________________ From report at bugs.python.org Sun Jun 24 09:20:38 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jun 2012 07:20:38 +0000 Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16) Message-ID: <1340522438.0.0.0567650260487.issue1470548@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: It would be nice to fix this bug before forking of the 3.3.0b1 release clone. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1470548> _______________________________________ From report at bugs.python.org Sun Jun 24 09:23:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 Jun 2012 07:23:28 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1340522608.55.0.691800349099.issue15003@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: -1. The entire Python API is already accessible from C, so expansions to the public C API need more justification than "it's exposed in Python". If new instances of this type end up being used in performance critical third party C extensions, then we can have a conversation about whether or not it needs to be exposed directly in C. ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Sun Jun 24 09:24:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 07:24:48 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <E1SihBe-0002ZS-Iq@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 781b95159954 by Gregory P. Smith in branch '3.2': Fixes issue #12268: File readline, readlines and read() or readall() methods http://hg.python.org/cpython/rev/781b95159954 New changeset 19a6bef57490 by Gregory P. Smith in branch 'default': Fixes issue #12268: File readline, readlines and read() or readall() methods http://hg.python.org/cpython/rev/19a6bef57490 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Sun Jun 24 09:26:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jun 2012 07:26:27 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1340522787.65.0.846617556475.issue14315@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Any chance to commit the patch before final feature freeze? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14315> _______________________________________ From report at bugs.python.org Sun Jun 24 09:27:14 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 24 Jun 2012 07:27:14 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1340522834.86.0.872576601023.issue12268@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: I'm leaving this open as I still need to audit the write methods and commit the fix(es) for 2.7. I tried to merge the test into test_io's signals tests but I could not get that to actually work to reproduce the original problem so I kept my process based test_file_eintr one which easily reproduces it prior to these patches being applied instead. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Sun Jun 24 09:27:41 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jun 2012 07:27:41 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1340522861.51.0.835005966259.issue14304@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Any chance to commit the patch before final feature freeze? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14304> _______________________________________ From report at bugs.python.org Sun Jun 24 09:28:53 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 07:28:53 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340522933.7.0.815315903146.issue15147@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: sysonfig.cfg removed in e989e7586da6. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 09:29:49 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 07:29:49 +0000 Subject: [issue15100] Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile In-Reply-To: <1340020668.92.0.801725909503.issue15100@psf.upfronthosting.co.za> Message-ID: <1340522989.19.0.835089416241.issue15100@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15100> _______________________________________ From report at bugs.python.org Sun Jun 24 09:31:31 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 07:31:31 +0000 Subject: [issue13520] Patch to make pickle aware of __qualname__ In-Reply-To: <1322843353.56.0.297081736881.issue13520@psf.upfronthosting.co.za> Message-ID: <1340523091.56.0.168778070478.issue13520@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: -hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13520> _______________________________________ From report at bugs.python.org Sun Jun 24 09:32:55 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 07:32:55 +0000 Subject: [issue7719] distutils: ignore .nfsXXXX files In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za> Message-ID: <1340523175.29.0.287413965396.issue7719@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: -hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7719> _______________________________________ From report at bugs.python.org Sun Jun 24 09:33:27 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 07:33:27 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index In-Reply-To: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za> Message-ID: <1340523207.87.0.259296465421.issue14974@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: -hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14974> _______________________________________ From report at bugs.python.org Sun Jun 24 09:34:23 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 07:34:23 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340523263.45.0.305081782012.issue10142@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: -hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Sun Jun 24 09:36:43 2012 From: report at bugs.python.org (Mark Summerfield) Date: Sun, 24 Jun 2012 07:36:43 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340523403.11.0.738776452991.issue15133@psf.upfronthosting.co.za> Mark Summerfield <mark at qtrac.eu> added the comment: I think that BooleanVar.set(x) should do bool(x) on its argument (and raise an exception if this isn't valid) and BooleanVar.get() should return a bool. Similarly I think that IntVar.set(x) should do int(x) and IntVar.get() should return an int, and that DoubleVar.set(x) should do float(x) and should return a float. I will mention this issue on tkinter-discuss and encourage people to comment. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Sun Jun 24 09:41:26 2012 From: report at bugs.python.org (Mark Summerfield) Date: Sun, 24 Jun 2012 07:41:26 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340523686.95.0.613719601951.issue15133@psf.upfronthosting.co.za> Mark Summerfield <mark at qtrac.eu> added the comment: Oh, and I forgot to say that I think StringVar.set(x) should do str(x) and StringVar.get() should return a str. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Sun Jun 24 09:41:52 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 24 Jun 2012 07:41:52 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1340523712.11.0.0784257264071.issue14315@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Strictly speaking, the feature freeze has passed already, so you'll need the time machine. However, this is not the *final* feature freeze - there will be a 3.4 release of Python also. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14315> _______________________________________ From report at bugs.python.org Sun Jun 24 09:59:51 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 07:59:51 +0000 Subject: [issue15159] Add failover for follow_symlinks and effective_ids where possible In-Reply-To: <1340514372.7.0.0626020739455.issue15159@psf.upfronthosting.co.za> Message-ID: <1340524791.04.0.942370867096.issue15159@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: It also passes OS X. There are no patch specific tests though. And alas, I don't have any platform at hand that would benefit from these additions. :( The idea sounds good to me and the code LGTM though. However I can't really say much as I couldn't actually run it. ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15159> _______________________________________ From report at bugs.python.org Sun Jun 24 10:37:35 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 24 Jun 2012 08:37:35 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340527055.01.0.297635121602.issue15118@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sun Jun 24 10:53:09 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Jun 2012 08:53:09 +0000 Subject: [issue15160] Add support for MIME header parsing to the new provisional email policies Message-ID: <1340527988.81.0.399006538534.issue15160@psf.upfronthosting.co.za> New submission from R. David Murray <rdmurray at bitdance.com>: I've been working on this steadily for a while. I think it is now all working correctly. At least, it passes all the same tests that the existing RFC mime header parser passes, plus a bunch of additional ones. There are a couple of commented out tests where there are issues with the folding. The folding doesn't normally get invoked for headers parsed from source, and the cases are marginal anyway (headers with invalid binary data) so I'm not worried about them, but will fix them after the beta. There are things that can be done to make this API even more convenient, but I think this is a solid foundation worth having. And the parser is a full RFC parser, so it handles cases that the current parser doesn't. (There are also probably cases where it fails when the current parser doesn't, but I haven't found them yet ;) ---------- components: email files: mime_parsing.patch keywords: patch messages: 163751 nosy: barry, georg.brandl, r.david.murray priority: normal severity: normal stage: commit review status: open title: Add support for MIME header parsing to the new provisional email policies type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file26126/mime_parsing.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15160> _______________________________________ From report at bugs.python.org Sun Jun 24 10:54:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 08:54:43 +0000 Subject: [issue14815] random_seed uses only 32-bits of hash on Win64 In-Reply-To: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za> Message-ID: <E1Siiag-0000CE-ED@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 166599219bd4 by Larry Hastings in branch 'default': Issue #14815: Use Py_ssize_t instead of long for the object hash, to http://hg.python.org/cpython/rev/166599219bd4 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14815> _______________________________________ From report at bugs.python.org Sun Jun 24 10:56:13 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 08:56:13 +0000 Subject: [issue14815] random_seed uses only 32-bits of hash on Win64 In-Reply-To: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za> Message-ID: <1340528173.68.0.509237907718.issue14815@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- resolution: -> fixed stage: -> commit review status: open -> closed type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14815> _______________________________________ From report at bugs.python.org Sun Jun 24 11:04:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 09:04:38 +0000 Subject: [issue15160] Add support for MIME header parsing to the new provisional email policies In-Reply-To: <1340527988.81.0.399006538534.issue15160@psf.upfronthosting.co.za> Message-ID: <E1SiikG-0000ry-Ra@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 0adccb941200 by R David Murray in branch 'default': #15160: Extend the new email parser to handle MIME headers. http://hg.python.org/cpython/rev/0adccb941200 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15160> _______________________________________ From report at bugs.python.org Sun Jun 24 11:05:34 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Jun 2012 09:05:34 +0000 Subject: [issue15160] Add support for MIME header parsing to the new provisional email policies In-Reply-To: <1340527988.81.0.399006538534.issue15160@psf.upfronthosting.co.za> Message-ID: <1340528734.58.0.718028445999.issue15160@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Committed with release manager agreement. ---------- stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15160> _______________________________________ From report at bugs.python.org Sun Jun 24 11:35:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 09:35:51 +0000 Subject: [issue15157] venvs should include pydoc In-Reply-To: <1340506043.04.0.340918087163.issue15157@psf.upfronthosting.co.za> Message-ID: <E1SijET-0002zI-Ug@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 84db4c3ce318 by Vinay Sajip in branch 'default': Closes #15157: pydoc script added to venvs. http://hg.python.org/cpython/rev/84db4c3ce318 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15157> _______________________________________ From report at bugs.python.org Sun Jun 24 11:43:45 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 24 Jun 2012 09:43:45 +0000 Subject: [issue1767933] Badly formed XML using etree and utf-16 Message-ID: <1340531025.67.0.492838175701.issue1767933@psf.upfronthosting.co.za> Eli Bendersky <eliben at gmail.com> added the comment: I will try to find time to review it before the fork, but since time is tight I don't promise. That said, this patch falls more into the bugfix category than a new feature, so I think it will be OK after beta as well. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1767933> _______________________________________ From report at bugs.python.org Sun Jun 24 11:49:46 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 24 Jun 2012 09:49:46 +0000 Subject: [issue14906] rotatingHandler WindowsError In-Reply-To: <1337912379.85.0.584273983424.issue14906@psf.upfronthosting.co.za> Message-ID: <1340531386.77.0.456272048643.issue14906@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: Closed for lack of evidence, please re-open when and if more information is available. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14906> _______________________________________ From report at bugs.python.org Sun Jun 24 11:52:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 09:52:33 +0000 Subject: [issue14815] random_seed uses only 32-bits of hash on Win64 In-Reply-To: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za> Message-ID: <E1SijUd-0003y4-TV@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 4445608cf434 by Larry Hastings in branch 'default': Issue #14815: Bugfix: the PyLong fed into the seed generator must be unsigned. http://hg.python.org/cpython/rev/4445608cf434 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14815> _______________________________________ From report at bugs.python.org Sun Jun 24 12:26:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 10:26:08 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340504721.31.0.903509168044.issue15147@psf.upfronthosting.co.za> Message-ID: <1340533354.3390.0.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > The sysconfig module was modified (and sysconfig.cfg was introduced) > to serve the needs of the resource system (install_data putting files > into system-configured locations and packaging.database finding them); > one of the thousand things mentioned in the ?Status of Packaging? > thread was an opinion by PJE that this was a bad choice, and even if I > disagree (being a Debian guy and all :), a PEP would be in order to > decide on such a big new functionality. Should these changes be > reverted too? (I?d think yes.) What is sysconfig.cfg? Keeping sysconfig is ok IMO. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 12:31:24 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 24 Jun 2012 10:31:24 +0000 Subject: [issue15161] add new-style os API to two missing functions Message-ID: <1340533884.88.0.13348326144.issue15161@psf.upfronthosting.co.za> New submission from Georg Brandl <georg at python.org>: For pathconf() / fpathconf() and truncate() / ftruncate() the former didn't support fds as path. These two patches should fix it. ---------- assignee: larry components: Extension Modules files: pathconf.diff keywords: patch messages: 163760 nosy: georg.brandl, larry priority: critical severity: normal status: open title: add new-style os API to two missing functions versions: Python 3.3 Added file: http://bugs.python.org/file26127/pathconf.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15161> _______________________________________ From report at bugs.python.org Sun Jun 24 12:31:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 10:31:32 +0000 Subject: [issue15159] Add failover for follow_symlinks and effective_ids where possible In-Reply-To: <1340514372.7.0.0626020739455.issue15159@psf.upfronthosting.co.za> Message-ID: <1340533892.94.0.288940177417.issue15159@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I don't like this idea. Normally the system calls wrapped by the os module are fairly atomic. Here you're introducing the possibility for potentially nasty race conditions and exploits. ---------- nosy: +neologix _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15159> _______________________________________ From report at bugs.python.org Sun Jun 24 12:31:33 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 24 Jun 2012 10:31:33 +0000 Subject: [issue15161] add new-style os API to two missing functions In-Reply-To: <1340533884.88.0.13348326144.issue15161@psf.upfronthosting.co.za> Message-ID: <1340533893.39.0.388409743684.issue15161@psf.upfronthosting.co.za> Changes by Georg Brandl <georg at python.org>: Added file: http://bugs.python.org/file26128/truncate.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15161> _______________________________________ From report at bugs.python.org Sun Jun 24 12:35:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 10:35:52 +0000 Subject: [issue13512] ~/.pypirc created insecurely In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za> Message-ID: <1340534152.05.0.152000547461.issue13512@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I have a link to the Mageia patch: http://svnweb.mageia.org/packages/cauldron/python/current/SOURCES/python-2.7.3-upstream-pypirc-secure.patch?revision=261722&view=markup ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13512> _______________________________________ From report at bugs.python.org Sun Jun 24 12:37:53 2012 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sun, 24 Jun 2012 10:37:53 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340534273.51.0.358490307738.issue15147@psf.upfronthosting.co.za> Tarek Ziad? <ziade.tarek at gmail.com> added the comment: We should keep sysconfig imo ---------- status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 12:42:42 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 24 Jun 2012 10:42:42 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340534562.24.0.630182209956.issue444582@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: >From 3.2, os has a function get_exec_path -- shouldn't which() use it instead of rolling its own query of $PATH? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Sun Jun 24 12:45:50 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 10:45:50 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340534750.18.0.495520937068.issue15102@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: All Windows buildbots are failing now: C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "cd "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\" [d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\ssl.vcxproj] C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\Debug\python_d.exe" build_ssl.py Release Win32 -a [d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\ssl.vcxproj] C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: " exited with code 3. [d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\ssl.vcxproj] Perhaps it would be possible to set HOST_PYTHON in build-amd64.bat as a temporary measure until a more elegant solution is found? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 12:57:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 10:57:09 +0000 Subject: [issue15161] add new-style os API to two missing functions In-Reply-To: <1340533884.88.0.13348326144.issue15161@psf.upfronthosting.co.za> Message-ID: <E1SikV9-0007lT-ML@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset da416ff1ecf5 by Georg Brandl in branch 'default': Closes #15161: add support for giving path as a fd for truncate() and pathconf(). http://hg.python.org/cpython/rev/da416ff1ecf5 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15161> _______________________________________ From report at bugs.python.org Sun Jun 24 13:02:57 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 11:02:57 +0000 Subject: [issue15159] Add failover for follow_symlinks and effective_ids where possible In-Reply-To: <1340514372.7.0.0626020739455.issue15159@psf.upfronthosting.co.za> Message-ID: <1340535777.77.0.257894168603.issue15159@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I think you're right. As Antoine pointed out in irc, for POSIX platforms, modules in os are almost exclusively atomic. This is a useful (if undocumented) feature from a security viewpoint, and we should not break it lightly. Closing as wontfix. If someone thinks it's salvageable and wants to resurrect it, please discuss here. ---------- resolution: -> wont fix stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15159> _______________________________________ From report at bugs.python.org Sun Jun 24 13:04:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 11:04:55 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <E1Sikcf-0008C7-W4@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset fc84ac3e8dfc by Stefan Krah in branch 'default': Issue #15102: Try setting HOST_PYTHON in build-amd64.bat as a temporary http://hg.python.org/cpython/rev/fc84ac3e8dfc ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 13:06:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 11:06:08 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340535968.03.0.679688657624.issue15102@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: I'm trying out my suggestion on the 64-bit bot. Will revert if it doesn't work out. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 13:19:10 2012 From: report at bugs.python.org (klappnase) Date: Sun, 24 Jun 2012 11:19:10 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340536750.09.0.554415511975.issue15133@psf.upfronthosting.co.za> klappnase <klappnase at web.de> added the comment: The behavior of Tkinter when handling boolean values appears to be a bit erratic at times, not only BooleanVar.get() returns 0/1 instead of True/False (e.g. see the thread at tkinter-discuss: http://mail.python.org/pipermail/tkinter-discuss/2012-June/003176.html ). This is apparently because tk itself uses the strings '0' and '1' as boolean values, so behind the scenes Tkinter has to convert any bool into a string when setting a value and the string back into a bool when retrieving it, and it seems like most of the Tkinter code (and docstrings) was written in the good ol' days when Python used 0 / 1 itself. Now when it comes to change Tkinter's behavior I'd tend to be careful. For example BooleanVar.get() could easily be changed to always return True/False. But imho this change would only make sense if you add strict input value checking for set() either, otherwise we just change one incoherency with another. But this would mean that we might end up breaking a lot of working code, for what seems to me a primarily aesthetic reason. And of course, I don't see much use in isolated changes of the behavior of one function here and another method there. I feel that if the behavior of Tkinter concerning bool values was to be changed, there should at least be a thorough change of *any* Tkinter method that gets / sets boolean values so we at least end up with an overall coherent solution. But again, this looks like quite a lot of work, will break running code and add no significant benefit besides a cosmetic improvement. So my vote goes to accepting that 0 and 1 are ok boolean values in Tkinter and changing no more than misleading docstrings, as in this example of BooleanVar.get(): def get(self): """Return the value of the variable as 1 (True) or 0 (False).""" return self._tk.getboolean(self._tk.globalgetvar(self._name)) ---------- nosy: +klappnase _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Sun Jun 24 13:21:09 2012 From: report at bugs.python.org (Pan Yongzhi) Date: Sun, 24 Jun 2012 11:21:09 +0000 Subject: [issue7391] Re-title the "Using Backslash to Continue Statements" anti-idiom In-Reply-To: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za> Message-ID: <1340536869.38.0.380946716842.issue7391@psf.upfronthosting.co.za> Changes by Pan Yongzhi <fossilet at users.sourceforge.net>: ---------- nosy: +fossilet _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7391> _______________________________________ From report at bugs.python.org Sun Jun 24 13:22:58 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 11:22:58 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340536978.38.0.254231341299.issue15102@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Well, the path to python_d.exe looks right now, but Perl and nasm aren't found: "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe" build_ssl.py Release x64 -a Found a working perl at 'C:\perl\bin\perl.exe' 'nasm' is not recognized as an internal or external command, operable program or batch file. nasm assembler has failed. Jeremy, did you install these on your machine? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 13:23:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 24 Jun 2012 11:23:18 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340535968.03.0.679688657624.issue15102@psf.upfronthosting.co.za> Message-ID: <4FE6F8A4.9080808@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > I'm trying out my suggestion on the 64-bit bot. Will revert if it > doesn't work out. Even if it does work out it should be reverted. As HOST_PYTHON is not set, PythonExe should be computed correctly. So we really need to find out why it isn't. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 13:32:00 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 24 Jun 2012 11:32:00 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340536978.38.0.254231341299.issue15102@psf.upfronthosting.co.za> Message-ID: <4FE6FAAE.70204@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: On 24.06.2012 13:22, Stefan Krah wrote: > > Stefan Krah <stefan-usenet at bytereef.org> added the comment: > > Well, the path to python_d.exe looks right now, but Perl and nasm > aren't found: perl shouldn't be necessary. Not sure why nasm is. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 13:33:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 11:33:48 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <E1Sil4c-0001ZG-Fw@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 460407f35aa9 by Larry Hastings in branch 'default': Issue #15118: Change return value of os.uname() and os.times() from http://hg.python.org/cpython/rev/460407f35aa9 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sun Jun 24 13:35:15 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 11:35:15 +0000 Subject: [issue15118] uname and other os functions should return a struct sequence instead of a tuple In-Reply-To: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za> Message-ID: <1340537715.34.0.995711150082.issue15118@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Yummy! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15118> _______________________________________ From report at bugs.python.org Sun Jun 24 13:36:25 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 11:36:25 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <4FE6F8A4.9080808@v.loewis.de> Message-ID: <20120624113622.GA30659@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Martin v. L??wis <report at bugs.python.org> wrote: > Even if it does work out it should be reverted. As HOST_PYTHON is not > set, PythonExe should be computed correctly. So we really need to find > out why it isn't. Yes, of course. It's meant as a temporary measure to work out things like the missing nasm and hopefully get a functioning bot before the beta. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 13:40:43 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 11:40:43 +0000 Subject: [issue14917] Make os.symlink on Win32 detect if target is directory In-Reply-To: <1337962561.24.0.688592071719.issue14917@psf.upfronthosting.co.za> Message-ID: <1340538043.1.0.705898719435.issue14917@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Martin: does this sound good or bad? ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14917> _______________________________________ From report at bugs.python.org Sun Jun 24 13:45:40 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 11:45:40 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340536978.38.0.254231341299.issue15102@psf.upfronthosting.co.za> Message-ID: <20120624114539.GA30751@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: > Well, the path to python_d.exe looks right now, but Perl and nasm > aren't found: > > > "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe" build_ssl.py Release x64 -a > > Found a working perl at 'C:\perl\bin\perl.exe' Hmm, obviously Perl *is* found. That leaves nasm. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 13:46:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 11:46:49 +0000 Subject: [issue14917] Make os.symlink on Win32 detect if target is directory In-Reply-To: <1337962561.24.0.688592071719.issue14917@psf.upfronthosting.co.za> Message-ID: <1340538409.57.0.103202857173.issue14917@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Uh. This was *removed* in a7406565ef1c :) See issue13772. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14917> _______________________________________ From report at bugs.python.org Sun Jun 24 13:49:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 11:49:01 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <E1SilJM-0002Ul-BO@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c82451eeb595 by Christian Heimes in branch 'default': Issue #15061: Re-implemented hmac.compare_digest() in C http://hg.python.org/cpython/rev/c82451eeb595 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sun Jun 24 13:51:35 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 11:51:35 +0000 Subject: [issue14917] Make os.symlink on Win32 detect if target is directory In-Reply-To: <1337962561.24.0.688592071719.issue14917@psf.upfronthosting.co.za> Message-ID: <1340538695.81.0.216156490029.issue14917@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Well then! Let's close this before the adults notice. ---------- resolution: -> wont fix stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14917> _______________________________________ From report at bugs.python.org Sun Jun 24 14:24:39 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 24 Jun 2012 12:24:39 +0000 Subject: [issue15162] help() says "This is the online help utility." even though it isn't Message-ID: <1340540679.64.0.68125783941.issue15162@psf.upfronthosting.co.za> New submission from Ramchandra Apte <maniandram01 at gmail.com>: help() says "This is the online help utility." even though it isn't. I think this sentence should be hanged to "This is the offline help utility." ---------- components: Library (Lib) messages: 163782 nosy: ramchandra.apte priority: normal severity: normal status: open title: help() says "This is the online help utility." even though it isn't type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15162> _______________________________________ From report at bugs.python.org Sun Jun 24 14:44:59 2012 From: report at bugs.python.org (Barry Alan Scott) Date: Sun, 24 Jun 2012 12:44:59 +0000 Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilation In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za> Message-ID: <1340541899.04.0.80874169369.issue10910@psf.upfronthosting.co.za> Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment: I'm happy to review patches or create them for you. I see a related set of errors on Mac OS X that are down to issues in bytes_methods.py that mirror the pyport.h issues. In C++ isspace and friends are functions not macros. You cannot go around defining them. Here are the lines in python2.7 that cause compilation errors for me. /Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/bytes_methods.h:#undef isspace /Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/bytes_methods.h:#define isspace(c) undefined_isspace(c) ---------- nosy: +barry-scott _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10910> _______________________________________ From report at bugs.python.org Sun Jun 24 15:12:05 2012 From: report at bugs.python.org (Christian Heimes) Date: Sun, 24 Jun 2012 13:12:05 +0000 Subject: [issue15061] hmac.secure_compare() leaks information about length of strings In-Reply-To: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za> Message-ID: <1340543525.71.0.925057192439.issue15061@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Thanks to all for your input and assistance! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ From report at bugs.python.org Sun Jun 24 15:53:20 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 24 Jun 2012 13:53:20 +0000 Subject: [issue15162] help() says "This is the online help utility." even though it isn't In-Reply-To: <1340540679.64.0.68125783941.issue15162@psf.upfronthosting.co.za> Message-ID: <1340546000.45.0.549513179811.issue15162@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Not sure "offline" is more true here; maybe "integrated" is better. Also not sure the sentence deserves the death penalty. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15162> _______________________________________ From report at bugs.python.org Sun Jun 24 15:54:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 13:54:01 +0000 Subject: [issue15162] help() says "This is the online help utility." even though it isn't In-Reply-To: <1340540679.64.0.68125783941.issue15162@psf.upfronthosting.co.za> Message-ID: <1340546041.02.0.723501690849.issue15162@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: "interactive" then? ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15162> _______________________________________ From report at bugs.python.org Sun Jun 24 16:00:10 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Sun, 24 Jun 2012 14:00:10 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <20120624114539.GA30751@sleipnir.bytereef.org> Message-ID: <CAGvrs3+Oqsh9ka4+oVBUWQA+_L3SE0FpPrhA+94pY1HHxiCMEA@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: > Hmm, obviously Perl *is* found. That leaves nasm. nasm.exe was installed for myself (hence testing worked). I've now made it available to the buildbot account as well. Note that I have Perl installed but *not* on my PATH (on purpose). The patch supplied in issue15052 will fix the issue brought out by that circumstance. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 16:09:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 14:09:50 +0000 Subject: [issue15163] pydoc displays __loader__ as module data Message-ID: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: Everything's in the title. __loader__ probably needs to be blacklisted. ---------- components: Library (Lib) messages: 163788 nosy: brett.cannon, eric.snow, pitrou priority: low severity: normal stage: needs patch status: open title: pydoc displays __loader__ as module data type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15163> _______________________________________ From report at bugs.python.org Sun Jun 24 16:17:09 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 14:17:09 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <CAGvrs3+Oqsh9ka4+oVBUWQA+_L3SE0FpPrhA+94pY1HHxiCMEA@mail.gmail.com> Message-ID: <20120624141706.GA32278@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Jeremy Kloth <report at bugs.python.org> wrote: > nasm.exe was installed for myself (hence testing worked). I've now > made it available to the buildbot account as well. > > Note that I have Perl installed but *not* on my PATH (on purpose). > The patch supplied in issue15052 will fix the issue brought out by > that circumstance. Thanks. The Perl situation looks OK since the buildbot has proceeded to the testing stage in the last build. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 16:26:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 24 Jun 2012 14:26:51 +0000 Subject: [issue15156] Refactor HTMLParser.unescape to use html.entities.html5 In-Reply-To: <1340505943.38.0.45190182563.issue15156@psf.upfronthosting.co.za> Message-ID: <1340548011.25.0.0313683756287.issue15156@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Here's a patch, please review. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file26129/issue15156.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15156> _______________________________________ From report at bugs.python.org Sun Jun 24 16:48:07 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Jun 2012 14:48:07 +0000 Subject: [issue15016] Add special case for latin messages in email.mime.text In-Reply-To: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za> Message-ID: <1340549287.11.0.173590036197.issue15016@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Well, the original change to using utf-8 by default was considered a bug fix. But I suppose you are right that this goes beyond that into enhancement territory. In which case we could wait for an enhancement to the C API to base it on, for which we'd need to open a new issue. On the other hand, the email package already uses the "encode to see if we have ascii" trick elsewhere (though on smaller strings), and the ascii codec is the fastest codec, with latin-1 only slightly slower. The critical difference here, though, is that we end up doing two encoding passes, once to test it and a second time to actually create the message body. The same is true of the ascii case. It should be possible to fix this, by using the encoded string in generating the _payload, short circuiting the set_payload mechanism. That's a somewhat ugly hack, necessitated because of the incomplete conversion of email to a unicode-centric design. I'm working on that :) So, again, we may be waiting on other enhancements, in this case in the email package, to do this fix "right". But it would be worth figuring out *how* to do it, so that we know what kind of (internal?) API enhancements we want in order to serve this kind of use case. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15016> _______________________________________ From report at bugs.python.org Sun Jun 24 16:57:46 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 14:57:46 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <CAGvrs3+Oqsh9ka4+oVBUWQA+_L3SE0FpPrhA+94pY1HHxiCMEA@mail.gmail.com> Message-ID: <20120624145742.GA32561@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Jeremy, your python-dev suggestion to move x64.props before pyproject.props does not work for me. For instance, in python3dll.vcxproj: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The comma nd "cd C:\Users\stefan\pydev\cpython\PCbuild\\..\PC [C:\Users\stefan\pydev\cpython\PCbuild\python3dll.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake /f py thon3.mak MACHINE=x64 OutDir=C:\Users\stefan\pydev\cpython\PCbuild\x64-pgo\" exited with code 9009. [C:\Users\ stefan\pydev\cpython\PCbuild\python3dll.vcxproj] ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 17:13:19 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Jun 2012 15:13:19 +0000 Subject: [issue15152] test_subprocess fqailures on awfully slow builtbots In-Reply-To: <1340442442.66.0.972780604979.issue15152@psf.upfronthosting.co.za> Message-ID: <1340550799.79.0.291823496864.issue15152@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: You could make the test a loop, with the timeout increasing each time through the loop, failing only if all tries fail. That way on faster machines the test will pass faster. It'll take even longer on slow machines, but they are slow anyway so that may be acceptable. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15152> _______________________________________ From report at bugs.python.org Sun Jun 24 17:20:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 15:20:35 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1340551235.7.0.583190970302.issue12268@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: For the record, there was a crash on the ARM buildbot: [196/368/1] test_io Timeout (1:00:00)! Thread 0x2aac5300: File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_io.py", line 3051 in check_interrupted_write_retry File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_io.py", line 3073 in test_interrupted_write_retry_text File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/unittest/case.py", line 385 in _executeTestPart File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/unittest/case.py", line 440 in run File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/unittest/case.py", line 492 in __call__ File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/unittest/suite.py", line 105 in run File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/unittest/suite.py", line 67 in __call__ File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/unittest/suite.py", line 105 in run File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/unittest/suite.py", line 67 in __call__ File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/unittest/runner.py", line 168 in run File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/support.py", line 1383 in _run_suite File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/support.py", line 1417 in run_unittest File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_io.py", line 3121 in test_main File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/regrtest.py", line 1194 in runtest_inner File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/regrtest.py", line 905 in runtest File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/regrtest.py", line 708 in main File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/__main__.py", line 13 in <module> File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/runpy.py", line 75 in _run_code File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/runpy.py", line 162 in _run_module_as_main make: *** [buildbottest] Error 1 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Sun Jun 24 17:20:46 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Jun 2012 15:20:46 +0000 Subject: [issue15162] help() says "This is the online help utility." even though it isn't In-Reply-To: <1340540679.64.0.68125783941.issue15162@psf.upfronthosting.co.za> Message-ID: <1340551246.96.0.71512300363.issue15162@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Oh you youngsters. "Offline" doesn't mean "not on the Internet", it means "not on a computer" :) Yes, "interactive" would be clearer. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15162> _______________________________________ From report at bugs.python.org Sun Jun 24 17:25:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 15:25:48 +0000 Subject: [issue15162] help() says "This is the online help utility." even though it isn't In-Reply-To: <1340540679.64.0.68125783941.issue15162@psf.upfronthosting.co.za> Message-ID: <E1Sioh5-0007tQ-Fu@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 1ff29f3b8da7 by Georg Brandl in branch 'default': Closes #15162: the meaning of "online" has shifted a bit in recent years, use "interactive" instead. http://hg.python.org/cpython/rev/1ff29f3b8da7 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15162> _______________________________________ From report at bugs.python.org Sun Jun 24 17:28:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 15:28:57 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1340551737.01.0.534674640372.issue14578@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Yes, it should be tackled soon, but I lack Windows access so I can't do the work myself. Basically no one seems to use or care about this feature so it might die "on the vine" if someone doesn't step forward. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14578> _______________________________________ From report at bugs.python.org Sun Jun 24 17:30:28 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 15:30:28 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1340551828.33.0.79359235758.issue13959@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Sorry, been on vacation the past week. Georg is right, nothing left is a b1 blocker, just stuff I want to get in before 3.3 ships. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Sun Jun 24 17:32:39 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 15:32:39 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1340551959.75.0.844774060266.issue15056@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Thanks for the patch, Pranav. I'm probably going to be too busy for a couple of weeks, so I won't look at this immediately, but I wanted to let you know I will eventually get to it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Sun Jun 24 17:33:44 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 24 Jun 2012 15:33:44 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <1340552024.28.0.178707862138.issue444582@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: I don't think the Windows example in the reST documentation is correct: >>> print(shutil.which("python")) 'c:\\python33\\python.exe' It should be either >>> shutil.which("python") 'c:\\python33\\python.exe' or >>> print(shutil.which("python")) c:\python33\python.exe ---------- nosy: +belopolsky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Sun Jun 24 17:34:16 2012 From: report at bugs.python.org (Brian Curtin) Date: Sun, 24 Jun 2012 15:34:16 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1340552056.31.0.505334014604.issue14578@psf.upfronthosting.co.za> Brian Curtin <brian at python.org> added the comment: I will take a look at it shortly...was too busy with installer/path issues and then PEP 397 last week. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14578> _______________________________________ From report at bugs.python.org Sun Jun 24 17:37:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 15:37:42 +0000 Subject: [issue444582] Finding programs in PATH, adding shutil.which Message-ID: <E1Siosc-0000Cy-Cb@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 84b48551cd13 by Georg Brandl in branch 'default': #444582: fix example and rewrap docs a bit. http://hg.python.org/cpython/rev/84b48551cd13 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue444582> _______________________________________ From report at bugs.python.org Sun Jun 24 17:44:13 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 15:44:13 +0000 Subject: [issue415492] Compiler generates relative filenames Message-ID: <1340552653.34.0.545248091021.issue415492@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: So co_filename is absolute in Python 3.3, but __file__ on modules is not if a relative path is used from sys.path (as Nick pointed out). Changing this would possibly break code as this has been baked into the import system for quite some time. I think Nick as suggested making all paths absolute for __file__, but I can't remember where that discussion was held and why we never changed the semantics. Regardless, __file__ being absolute is a different issue than co_filename, so I'm closing this at out of date. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue415492> _______________________________________ From report at bugs.python.org Sun Jun 24 17:47:42 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 15:47:42 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1340552862.48.0.0280354924531.issue14657@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Do people feel the need to change the importlib tests to run against both the frozen code and importlib/_bootstrap.py? If so either the test_warnings approach (or a new one using class decorators or something) should be used to run the tests twice. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14657> _______________________________________ From report at bugs.python.org Sun Jun 24 17:50:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 15:50:41 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340553041.73.0.813920033221.issue15102@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Ouch. The test failures on the buildbot now seem to point to problems with OpenSSL's SHA1 implementation. Jeremy, perhaps you can try to run the OpenSSL self-tests? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 18:43:30 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 16:43:30 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340556210.92.0.0112806461975.issue15102@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: outdir.diff contains a solution that doesn't rely on HOST_PYTHON. Works for both x64 and Win32. Note that I've edited the files using Vim. -- I'm not sure if one can even select Condition="'$(Platform)'=='Win32'" using Visual Studio. ---------- Added file: http://bugs.python.org/file26130/outdir.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 18:51:01 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 24 Jun 2012 16:51:01 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340556661.0.0.4453054974.issue15102@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Stefan: I think that's acceptable. Perhaps someone will come up with a better solution; if this works, it's good enough for me. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 19:05:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 17:05:52 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <E1SiqFy-0006SC-Rg@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset f12a2f2c93e5 by Stefan Krah in branch 'default': Issue #15102: Fix paths of python executables. http://hg.python.org/cpython/rev/f12a2f2c93e5 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 19:08:16 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 17:08:16 +0000 Subject: [issue7897] Support parametrized tests in unittest In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za> Message-ID: <1340557696.03.0.467937025217.issue7897@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I like test_email?s decorator. It looks like https://github.com/wolever/nose-parameterized which I?m using. (The implementation and generation of test method names may be less nice than what was discussed here, but the API (decorator + list of arguments) is something I like (much better than nose?s built-in parametrization). ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7897> _______________________________________ From report at bugs.python.org Sun Jun 24 19:32:50 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 24 Jun 2012 17:32:50 +0000 Subject: [issue15164] add platform.uname() namedtuple interface? Message-ID: <1340559170.31.0.985080804132.issue15164@psf.upfronthosting.co.za> New submission from Georg Brandl <georg at python.org>: Followup to #15118. See rev 75b818d7c50d -- the patch converted a usage of platform.uname(), which errored out on Mac. Since os.uname() is supposed to be the "low-level" interface, it suggests that platform.uname() should also return an attribute-rich object; in this case probably a namedtuple. ---------- assignee: larry components: Library (Lib) messages: 163810 nosy: georg.brandl, larry priority: deferred blocker severity: normal status: open title: add platform.uname() namedtuple interface? versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15164> _______________________________________ From report at bugs.python.org Sun Jun 24 19:35:32 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 24 Jun 2012 17:35:32 +0000 Subject: [issue15156] Refactor HTMLParser.unescape to use html.entities.html5 In-Reply-To: <1340505943.38.0.45190182563.issue15156@psf.upfronthosting.co.za> Message-ID: <1340559332.41.0.589606779811.issue15156@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Patch updated after the review. ---------- Added file: http://bugs.python.org/file26131/issue15156-2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15156> _______________________________________ From report at bugs.python.org Sun Jun 24 19:41:09 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sun, 24 Jun 2012 17:41:09 +0000 Subject: [issue11728] mbox parser incorrect behaviour In-Reply-To: <1301573066.6.0.277247050127.issue11728@psf.upfronthosting.co.za> Message-ID: <1340559669.43.0.326236024944.issue11728@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: It seems to me that "^From " is the correct way to match the start of each message. This is also what the qmail manual page (linked in the previous message) says. So closing as invalid. ---------- nosy: +petri.lehtinen resolution: -> invalid stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11728> _______________________________________ From report at bugs.python.org Sun Jun 24 19:48:35 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Jun 2012 17:48:35 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1340560115.75.0.517706423776.issue14315@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: This issue is currently marked as a bugfix for current releases also. Since the proposal seems to be to introduce a new flag, should it be re-classified as enhancement (for 3.4)? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14315> _______________________________________ From report at bugs.python.org Sun Jun 24 19:54:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 17:54:30 +0000 Subject: [issue15157] venvs should include pydoc In-Reply-To: <1340506043.04.0.340918087163.issue15157@psf.upfronthosting.co.za> Message-ID: <E1Sir12-0001kl-LY@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 9cf4dc975a32 by ?ric Araujo in branch 'default': Restore test that was using pysetup and can now (#15157) use pydoc http://hg.python.org/cpython/rev/9cf4dc975a32 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15157> _______________________________________ From report at bugs.python.org Sun Jun 24 19:55:09 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 17:55:09 +0000 Subject: [issue15157] venvs should include pydoc In-Reply-To: <1340506043.04.0.340918087163.issue15157@psf.upfronthosting.co.za> Message-ID: <1340560509.48.0.102478023808.issue15157@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Great to get this for 3.3, thanks! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15157> _______________________________________ From report at bugs.python.org Sun Jun 24 20:03:26 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 18:03:26 +0000 Subject: [issue13512] ~/.pypirc created insecurely In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za> Message-ID: <1340561006.97.0.56073312893.issue13512@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: And I see that doko has applied the same patch for Debian and derivatives: http://patch-tracker.debian.org/patch/series/view/python2.7/2.7.3~rc2-2.1/pypirc-secure.diff Will commit today. Release managers: there are CVE and ocert numbers for this; do we take that as indication that it should be fixed in security releases too or do we stand by our own assessment? ---------- priority: normal -> high _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13512> _______________________________________ From report at bugs.python.org Sun Jun 24 20:32:50 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:32:50 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562770.55.0.406873290319.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Removed file: http://bugs.python.org/file12172/poplib.rst.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:33:06 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:33:06 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562786.53.0.214932123326.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Removed file: http://bugs.python.org/file12187/poplib_02_sock_shutdown.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:33:20 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:33:20 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562800.26.0.486756796719.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Removed file: http://bugs.python.org/file12188/poplib_03_SSL_refactor.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:33:35 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:33:35 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562815.04.0.315068622922.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Removed file: http://bugs.python.org/file12189/poplib_04_STLS.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:33:48 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:33:48 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562828.1.0.0689353095353.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Removed file: http://bugs.python.org/file12192/poplib_01_CAPA.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:34:00 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:34:00 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562840.03.0.820570403759.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Removed file: http://bugs.python.org/file12965/test_popnet.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:34:08 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:34:08 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562848.83.0.814426919395.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Removed file: http://bugs.python.org/file12966/test_popnet.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:34:55 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:34:55 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562895.82.0.169018079632.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Added file: http://bugs.python.org/file26132/poplib_01_socket_shutdown.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:35:26 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:35:26 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562926.9.0.472333967553.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Added file: http://bugs.python.org/file26133/poplib_02_server_capabilities.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:35:42 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:35:42 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340562942.66.0.932122110208.issue4473@psf.upfronthosting.co.za> Changes by Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it>: Added file: http://bugs.python.org/file26134/poplib_03_starttls.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:36:57 2012 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 24 Jun 2012 18:36:57 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340563017.23.0.311160359278.issue4473@psf.upfronthosting.co.za> Lorenzo M. Catucci <lorenzo at sancho.ccd.uniroma2.it> added the comment: I've refreshed the patches to apply on 3.3, and adapted the to the unit-test framework by giampaolo.rodola. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 20:45:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 18:45:33 +0000 Subject: [issue15147] Remove packaging from the stdlib In-Reply-To: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za> Message-ID: <1340563533.68.0.862862195696.issue15147@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > What is sysconfig.cfg? A file containing the install schemes for packaging (not for distutils, these are still in distutils.commands.install) and the categories for data files, to allow installation to various directories for scripts, doc, etc (cf. FHS). The idea AFAICT was to allow OS-level customization of the install paths with a config file instead of code patches. There are already complaints about the sysconfig module API, so I wanted to avoid locking us into this new sysconfig.cfg file format without a longer discussion: - is this file needed for built-from-source Pythons installed in e.g. /usr/local? - should it apply to distributions installed using non-OS packaging tools with the OS Python? - does it remove the need for the --layout=deb gross patch that you can see for example in Debian and derivatives? (i.e. a layout used to build Python projects in a debian/tmp/usr subdirectory of the source package, before using non-Python packaging tools to move these files to the right location) These are the kind of questions from the top of my head which I think haven?t been hashed out. Or maybe it?s perfectly clear between Tarek and the few OS packagers that discussed this matter but there is no documentation of that. As the only client of the sysconfig.cfg file was packaging, I think the safe thing to do is to not add it in 3.3 and make it a part of the discussions for 3.4 (i.e. may need a PEP). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15147> _______________________________________ From report at bugs.python.org Sun Jun 24 21:00:37 2012 From: report at bugs.python.org (Mark Shannon) Date: Sun, 24 Jun 2012 19:00:37 +0000 Subject: [issue15003] make PyNamespace_New() public In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za> Message-ID: <1340564437.69.0.363163416631.issue15003@psf.upfronthosting.co.za> Mark Shannon <mark at hotpy.org> added the comment: -1 for the reasons Nick stated. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15003> _______________________________________ From report at bugs.python.org Sun Jun 24 21:02:46 2012 From: report at bugs.python.org (Mark Shannon) Date: Sun, 24 Jun 2012 19:02:46 +0000 Subject: [issue15055] dictnotes.txt is out of date In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za> Message-ID: <1340564566.48.0.400139106023.issue15055@psf.upfronthosting.co.za> Mark Shannon <mark at hotpy.org> added the comment: Is there any reason not to commit this patch? The docs are out of sync with the code and need to be updated. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15055> _______________________________________ From report at bugs.python.org Sun Jun 24 21:07:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 19:07:30 +0000 Subject: [issue15055] dictnotes.txt is out of date In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za> Message-ID: <E1Sis9h-0006aF-B2@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 1120041f2df4 by Antoine Pitrou in branch 'default': Issue #15055: update dictnotes.txt. Patch by Mark Shannon. http://hg.python.org/cpython/rev/1120041f2df4 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15055> _______________________________________ From report at bugs.python.org Sun Jun 24 21:08:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 19:08:34 +0000 Subject: [issue15055] dictnotes.txt is out of date In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za> Message-ID: <1340564914.11.0.153674982436.issue15055@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Sorry, Mark. This is committed now. ---------- assignee: rhettinger -> nosy: +pitrou resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15055> _______________________________________ From report at bugs.python.org Sun Jun 24 21:13:47 2012 From: report at bugs.python.org (Mark Shannon) Date: Sun, 24 Jun 2012 19:13:47 +0000 Subject: [issue15055] dictnotes.txt is out of date In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za> Message-ID: <1340565227.82.0.492147658804.issue15055@psf.upfronthosting.co.za> Mark Shannon <mark at hotpy.org> added the comment: No apology needed :) Thanks. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15055> _______________________________________ From report at bugs.python.org Sun Jun 24 21:25:36 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Jun 2012 19:25:36 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340565936.28.0.303851844632.issue15133@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Mark: "Variable.get(self) returns self._tk.globalgetvar(self._name). String/Int/Double/Var call str/int/float as appropriate." was meant to say that String/Int/Double/Var.get(self) already call str/int/float on the result of self._tk.globalgetvar(self._name) before returning it. BooleanVar.get does not call bool, but instead calls self._tk.getboolean, which fails to always return a boolean. Klappnase: I disagree, somehow. bool is a subclass of int, so that False, True are arithmetically indistinguishable from 0, 1. The main difference is on display and 'type(x) = int/bool' comparisons (which should be isinstance()). BooleanVar.get already returns False, True for the tcl boolean values '0', '1' set by tk rather than the user (which I expect should be the usual case for retrieval). So a Python/tkinter program has to be prepared to get proper booleans anyway. Since the purpose of Variables is to synchronize values between user code and tk, TypeVar().set(x).get() should be x when has the proper type. That is now true for everything but bool/Boolean. I do wonder whether not converting or rejecting bad inputs to .set could cause problems with tk, but maybe some of that is handled later (and silently? if so bad) within _tkinter. I could be persuaded that a behavior fix should only be applied to 3.3. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Sun Jun 24 21:28:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 19:28:05 +0000 Subject: [issue15137] Cleaned source of `cmd` module In-Reply-To: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> Message-ID: <1340566085.46.0.56982061324.issue15137@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Just wanted to offer a comment on this: > Last point. Please use .diff or .patch for diff/patch files as that > extension works better for people Depending on OS and file association settings, yes. > and, I believe, hg. Mercurial does not care about file extensions, it works with standard input or any file path or URI. ---------- nosy: +eric.araujo resolution: rejected -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Sun Jun 24 21:28:35 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 19:28:35 +0000 Subject: [issue15137] Cleaned source of `cmd` module In-Reply-To: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> Message-ID: <1340566115.52.0.180253673484.issue15137@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Sun Jun 24 21:29:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 19:29:26 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340566166.61.0.756159653728.issue15102@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Note that there also appears to be a compile error on the 3.2 and 2.7 branches: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.2 http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7 Build started: Project: ssl, Configuration: Debug|x64 Performing Makefile project actions '""' is not recognized as an internal or external command, operable program or batch file. Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions" Project : warning PRJ0018 : The following environment variables were not found: $(HOST_PYTHON) Build log was saved at "file://C:\Users\Buildbot\buildbot.python.org\3.2.kloth-win64\build\PCbuild\x64-temp-Debug\ssl\BuildLog.htm" ssl - 1 error(s), 0 warning(s) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 21:31:52 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 19:31:52 +0000 Subject: [issue15090] Add etag support to urllib.request.urlopen In-Reply-To: <1339916557.45.0.663415683134.issue15090@psf.upfronthosting.co.za> Message-ID: <1340566312.5.0.999253669288.issue15090@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +eric.araujo stage: -> needs patch title: Add etag support to urllib.request.urlretrieve() -> Add etag support to urllib.request.urlopen versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15090> _______________________________________ From report at bugs.python.org Sun Jun 24 21:36:30 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 19:36:30 +0000 Subject: [issue15137] Cleaned source of `cmd` module In-Reply-To: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za> Message-ID: <1340566590.1.0.679268593739.issue15137@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- resolution: -> invalid stage: -> committed/rejected _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15137> _______________________________________ From report at bugs.python.org Sun Jun 24 21:43:57 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 19:43:57 +0000 Subject: [issue15165] test_email: failure on Windows 64-bit Message-ID: <1340567037.81.0.496566862614.issue15165@psf.upfronthosting.co.za> New submission from Stefan Krah <stefan-usenet at bytereef.org>: I'm getting this failure in test_email (Windows 64-bit build): ====================================================================== ERROR: test_localtime_epoch_notz_daylight_false (test_utils.LocaltimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\stefan\pydev\cpython\lib\test\test_email\test_utils.py", line 112, in test_localtime_epoch_notz_dayl ight_false t1 = utils.localtime(t0) File "C:\Users\stefan\pydev\cpython\lib\email\utils.py", line 397, in localtime seconds = time.mktime(tm) OverflowError: mktime argument out of range ====================================================================== ERROR: test_localtime_epoch_notz_daylight_true (test_utils.LocaltimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\stefan\pydev\cpython\lib\test\test_email\test_utils.py", line 105, in test_localtime_epoch_notz_dayl ight_true t1 = utils.localtime(t0) File "C:\Users\stefan\pydev\cpython\lib\email\utils.py", line 397, in localtime seconds = time.mktime(tm) OverflowError: mktime argument out of range ---------- components: Tests keywords: buildbot messages: 163827 nosy: r.david.murray, skrah priority: normal severity: normal status: open title: test_email: failure on Windows 64-bit type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15165> _______________________________________ From report at bugs.python.org Sun Jun 24 21:47:08 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 24 Jun 2012 19:47:08 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (issue 15102) In-Reply-To: <1340566166.61.0.756159653728.issue15102@psf.upfronthosting.co.za> Message-ID: <4FE76EBA.3040803@v.loewis.de> Martin v. L?wis <martin at v.loewis.de> added the comment: > Note that there also appears to be a compile error on the 3.2 and 2.7 branches: Can we please, pretty pretty please, deal with one issue at a time? If you want to keep this issue open until everything works, you will probably see a dozen more commits, and wait several more months. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 21:50:12 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 19:50:12 +0000 Subject: [issue15166] Implement imp.get_tag() using sys.implementation Message-ID: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za> New submission from Brett Cannon <brett at python.org>: Title says it all. This also implies updating importlib to use sys.implementation directly. ---------- components: Library (Lib) keywords: easy messages: 163829 nosy: brett.cannon, eric.snow priority: deferred blocker severity: normal stage: needs patch status: open title: Implement imp.get_tag() using sys.implementation versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15166> _______________________________________ From report at bugs.python.org Sun Jun 24 21:50:23 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 19:50:23 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1340567423.69.0.186242016114.issue13959@psf.upfronthosting.co.za> Changes by Brett Cannon <brett at python.org>: ---------- dependencies: +Implement imp.get_tag() using sys.implementation _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Sun Jun 24 21:51:26 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 19:51:26 +0000 Subject: [issue15167] Re-implement imp.get_magic() in pure Python Message-ID: <1340567486.25.0.718240162307.issue15167@psf.upfronthosting.co.za> New submission from Brett Cannon <brett at python.org>: Title says it all. Issue #13959 has a patch. ---------- messages: 163830 nosy: brett.cannon, eric.snow priority: normal severity: normal status: open title: Re-implement imp.get_magic() in pure Python _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15167> _______________________________________ From report at bugs.python.org Sun Jun 24 21:51:41 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 19:51:41 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1340567501.48.0.134585471626.issue13959@psf.upfronthosting.co.za> Changes by Brett Cannon <brett at python.org>: ---------- dependencies: +Re-implement imp.get_magic() in pure Python _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Sun Jun 24 21:53:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jun 2012 19:53:16 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1340560115.75.0.517706423776.issue14315@psf.upfronthosting.co.za> Message-ID: <1340567608.2758.8.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: I think this is a bugfix. I also don't think that "strict" attribute makes sense if we can't guarantee strong validity (see issue15114). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14315> _______________________________________ From report at bugs.python.org Sun Jun 24 21:54:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 19:54:33 +0000 Subject: [issue8371] Add options to distutils2.install and pysetup install to only download In-Reply-To: <1271004631.29.0.0742687502668.issue8371@psf.upfronthosting.co.za> Message-ID: <1340567673.44.0.637866507933.issue8371@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > downloading a distribution is not a final goal, imho. > Wouldn't it be simpler to have a simple function that provides this feature ? The reasoning behind my request was that providing a way to do steps from the command-line is good. pysetup install figures dependencies + downloads + builds and installs; I think it?s good to let user do each step at a time, or at separate time. Packaging systems and installers like pip support this usage. (I was mistaken in suggesting a command though; commands work in a project directory.) ---------- title: Add a command to download distributions -> Add options to distutils2.install and pysetup install to only download versions: +3rd party, Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8371> _______________________________________ From report at bugs.python.org Sun Jun 24 21:55:30 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 19:55:30 +0000 Subject: [issue15168] Move importlib.test to test.importlib Message-ID: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za> New submission from Brett Cannon <brett at python.org>: Should also update to use unittest discovery. Might also need to update tests to use both _frozen_importlib and importlib._bootstrap. ---------- messages: 163833 nosy: brett.cannon priority: normal severity: normal status: open title: Move importlib.test to test.importlib _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15168> _______________________________________ From report at bugs.python.org Sun Jun 24 21:57:58 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 24 Jun 2012 19:57:58 +0000 Subject: [issue15168] Move importlib.test to test.importlib In-Reply-To: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za> Message-ID: <1340567878.94.0.915871576485.issue15168@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti stage: -> needs patch type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15168> _______________________________________ From report at bugs.python.org Sun Jun 24 21:59:16 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 24 Jun 2012 19:59:16 +0000 Subject: [issue15169] Clear C code under PyImport_ExecCodeModuleObject() Message-ID: <1340567956.17.0.18413889062.issue15169@psf.upfronthosting.co.za> New submission from Brett Cannon <brett at python.org>: import.c:PyImport_ExecCodeModuleObject() is holding on to a ton of C code thanks to get_sourcefile(). Should have PyImport_ExecCodeModuleWithPathnames() use get_sourcefile() only. And then get_sourcefile() should get re-implemented in Python code. ---------- components: Interpreter Core messages: 163834 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Clear C code under PyImport_ExecCodeModuleObject() versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15169> _______________________________________ From report at bugs.python.org Sun Jun 24 22:01:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 24 Jun 2012 20:01:06 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1340568066.61.0.969484851603.issue14315@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I still don't see the bug; the module is behaving correctly - it is the zipfile that is buggy. Supporting this specific kind of buggy zipfiles is a new feature. For reasons discussed, I also disagree with the proposed patch (file24902). If this helps to advance this issue, I can formally reject it if desired. ---------- type: behavior -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14315> _______________________________________ From report at bugs.python.org Sun Jun 24 22:02:12 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 24 Jun 2012 20:02:12 +0000 Subject: [issue15169] Clear C code under PyImport_ExecCodeModuleObject() In-Reply-To: <1340567956.17.0.18413889062.issue15169@psf.upfronthosting.co.za> Message-ID: <1340568132.8.0.755227675652.issue15169@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I propose to defer this to 3.4. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15169> _______________________________________ From report at bugs.python.org Sun Jun 24 22:04:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 20:04:10 +0000 Subject: [issue15156] Refactor HTMLParser.unescape to use html.entities.html5 In-Reply-To: <1340505943.38.0.45190182563.issue15156@psf.upfronthosting.co.za> Message-ID: <E1Sit2W-00022v-PQ@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 0d53703b1a99 by Ezio Melotti in branch 'default': #15156: HTMLParser now uses the new "html.entities.html5" dictionary. http://hg.python.org/cpython/rev/0d53703b1a99 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15156> _______________________________________ From report at bugs.python.org Sun Jun 24 22:05:36 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 24 Jun 2012 20:05:36 +0000 Subject: [issue15156] Refactor HTMLParser.unescape to use html.entities.html5 In-Reply-To: <1340505943.38.0.45190182563.issue15156@psf.upfronthosting.co.za> Message-ID: <1340568336.46.0.748608199971.issue15156@psf.upfronthosting.co.za> Ezio Melotti <ezio.melotti at gmail.com> added the comment: Fixed, thanks for the reviews! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15156> _______________________________________ From report at bugs.python.org Sun Jun 24 22:08:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:08:31 +0000 Subject: [issue5302] Allow package_data specs/globs to match directories In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za> Message-ID: <1340568511.31.0.452213502668.issue5302@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Cannot block a release anymore, since packaging has gone. ---------- nosy: +pitrou priority: release blocker -> normal _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5302> _______________________________________ From report at bugs.python.org Sun Jun 24 22:10:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:10:19 +0000 Subject: [issue14446] Remove deprecated tkinter functions In-Reply-To: <1333051070.39.0.337099775152.issue14446@psf.upfronthosting.co.za> Message-ID: <1340568619.45.0.561458584403.issue14446@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14446> _______________________________________ From report at bugs.python.org Sun Jun 24 22:11:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:11:54 +0000 Subject: [issue2919] Merge profile/cProfile in 3.n+1 In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za> Message-ID: <1340568714.0.0.403616611133.issue2919@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- title: Merge profile/cProfile in 3.0 -> Merge profile/cProfile in 3.n+1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue2919> _______________________________________ From report at bugs.python.org Sun Jun 24 22:12:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:12:44 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1340568764.59.0.387717834714.issue11205@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +benjamin.peterson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11205> _______________________________________ From report at bugs.python.org Sun Jun 24 22:13:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:13:40 +0000 Subject: [issue4473] POP3 missing support for starttls In-Reply-To: <1228063143.07.0.0563421485939.issue4473@psf.upfronthosting.co.za> Message-ID: <1340568820.39.0.13133595078.issue4473@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4473> _______________________________________ From report at bugs.python.org Sun Jun 24 22:14:53 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 20:14:53 +0000 Subject: [issue11678] Add support for Arch Linux to platform.linux_distributions() In-Reply-To: <1301098195.86.0.891765525403.issue11678@psf.upfronthosting.co.za> Message-ID: <1340568893.13.0.0123856554095.issue11678@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Feature freeze just came by; sorry we missed this. Given our recent-ish discussion about additions to mimetypes (and the consensus (IIRC) that matching the IANA database can be considered a bug fix), I wonder if detecting more OSes in platform should be considered a new feature. On one end we have mimetypes when there is just a dictionary update with no risk, on the other end we have ports to new OSes which clearly are new features; I think platform is on the fence, maybe just a bit on the new feature side. ---------- nosy: +eric.araujo, pitrou, r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11678> _______________________________________ From report at bugs.python.org Sun Jun 24 22:16:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:16:26 +0000 Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za> Message-ID: <1340568986.38.0.42462348643.issue5067@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I would say this is a bugfix, so it can go in after the beta. Georg? ---------- assignee: bob.ippolito -> components: -Documentation nosy: +georg.brandl, pitrou stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5067> _______________________________________ From report at bugs.python.org Sun Jun 24 22:17:06 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 20:17:06 +0000 Subject: [issue5302] Allow package_data specs/globs to match directories In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za> Message-ID: <1340569026.93.0.0444264642188.issue5302@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I explained in another issue that I had been using priority release blocker + version third-party to keep track of distutils2 release blockers. This can be distracting for CPython devs and RMs so I?ll just use high now. ---------- priority: normal -> high _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5302> _______________________________________ From report at bugs.python.org Sun Jun 24 22:17:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 20:17:46 +0000 Subject: [issue11678] Add support for Arch Linux to platform.linux_distributions() In-Reply-To: <1301098195.86.0.891765525403.issue11678@psf.upfronthosting.co.za> Message-ID: <E1SitFe-0002sl-Kk@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 97a098aa4205 by Georg Brandl in branch 'default': Closes #11678: support Arch linux in the platform module. http://hg.python.org/cpython/rev/97a098aa4205 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11678> _______________________________________ From report at bugs.python.org Sun Jun 24 22:18:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:18:42 +0000 Subject: [issue15124] _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock. In-Reply-To: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> Message-ID: <1340569122.89.0.728794658098.issue15124@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Closing as fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15124> _______________________________________ From report at bugs.python.org Sun Jun 24 22:21:11 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 24 Jun 2012 20:21:11 +0000 Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za> Message-ID: <1340569271.15.0.821037191274.issue5067@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Agreed. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5067> _______________________________________ From report at bugs.python.org Sun Jun 24 22:24:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:24:45 +0000 Subject: [issue5302] Allow package_data specs/globs to match directories In-Reply-To: <1340569026.93.0.0444264642188.issue5302@psf.upfronthosting.co.za> Message-ID: <1340569269.3390.47.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > I explained in another issue that I had been using priority release > blocker + version third-party to keep track of distutils2 release > blockers. This can be distracting for CPython devs and RMs so I?ll > just use high now. Woops, sorry. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5302> _______________________________________ From report at bugs.python.org Sun Jun 24 22:24:56 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 24 Jun 2012 20:24:56 +0000 Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za> Message-ID: <1340569496.49.0.250931279599.issue5067@psf.upfronthosting.co.za> Changes by Ezio Melotti <ezio.melotti at gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5067> _______________________________________ From report at bugs.python.org Sun Jun 24 22:28:54 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 20:28:54 +0000 Subject: [issue15170] Fix 64-bit building for buildbot scripts (2.7) Message-ID: <1340569734.61.0.00630889671182.issue15170@psf.upfronthosting.co.za> New submission from Stefan Krah <stefan-usenet at bytereef.org>: [from #15102] http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7 ---------- components: Build messages: 163847 nosy: brian.curtin, jeremy.kloth, jkloth, loewis, pitrou, python-dev, skrah, zach.ware priority: normal severity: normal status: open title: Fix 64-bit building for buildbot scripts (2.7) type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15170> _______________________________________ From report at bugs.python.org Sun Jun 24 22:30:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 20:30:08 +0000 Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2) Message-ID: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za> New submission from Stefan Krah <stefan-usenet at bytereef.org>: [from #15102] http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.2 ---------- messages: 163848 nosy: brian.curtin, jeremy.kloth, jkloth, loewis, pitrou, skrah, zach.ware priority: normal severity: normal status: open title: Fix 64-bit building for buildbot scripts (3.2) _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15171> _______________________________________ From report at bugs.python.org Sun Jun 24 22:32:27 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 20:32:27 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot Message-ID: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za> New submission from Stefan Krah <stefan-usenet at bytereef.org>: [Antoine] Ouch. The test failures on the buildbot now seem to point to problems with OpenSSL's SHA1 implementation. Jeremy, perhaps you can try to run the OpenSSL self-tests? ---------- components: Tests keywords: buildbot messages: 163849 nosy: brian.curtin, jeremy.kloth, jkloth, loewis, pitrou, skrah, zach.ware priority: normal severity: normal status: open title: SHA1 failures on the 64-bit Windows buildbot type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Sun Jun 24 22:32:39 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 20:32:39 +0000 Subject: [issue15173] Copyright/licensing statement in new venv module Message-ID: <1340569959.64.0.251231198721.issue15173@psf.upfronthosting.co.za> New submission from ?ric Araujo <merwok at netwok.org>: While reading the venv source I noticed a typo in the copyright/license line (?20011?); I propose a patch that removes that line in favor of the customary ?Licensed to the PSF? line, which is IMO much clearer (I never understand what the combination of ?all rights reserved? and a free software license means). I have added a comment to preserve the mention of your authorship (as well as a reference to virtualenv?s authors, which sounds fair to me?but maybe it?s good enough that the PEP mention them). I do hope this does not seem disrespectful to you; I really appreciate your work and don?t wish to diminish your merit, but I think the notice is strange and should be fixed. Another minor edit in the diff is the removal of an obsolete mention of pythonv; could be another commit if you prefer. ---------- assignee: vinay.sajip components: Library (Lib) files: venv-licensing.diff keywords: patch messages: 163850 nosy: eric.araujo, vinay.sajip priority: normal severity: normal stage: commit review status: open title: Copyright/licensing statement in new venv module versions: Python 3.3 Added file: http://bugs.python.org/file26135/venv-licensing.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15173> _______________________________________ From report at bugs.python.org Sun Jun 24 22:35:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 20:35:18 +0000 Subject: [issue15165] test_email: failure on Windows 64-bit In-Reply-To: <1340567037.81.0.496566862614.issue15165@psf.upfronthosting.co.za> Message-ID: <1340570118.57.0.0141116692168.issue15165@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Same here with VS 2008. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15165> _______________________________________ From report at bugs.python.org Sun Jun 24 22:35:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 20:35:41 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (3.3) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340570141.31.0.122640254221.issue15102@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: As far as I can see, the 3.3 buildbot scripts are fixed: After af1d98b7ca80 I can run Tools/buildbot/build.bat and Tools/buildbot/build-amd64.bat successfully in any order. I've run the tests, too, and I'm not getting the SHA1 failures. As requested, I've opened separate issues for the 2.7/3.2 scripts and one for the SHA1 failures on the bot. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed title: Fix 64-bit building for buildbot scripts (issue 15102) -> Fix 64-bit building for buildbot scripts (3.3) _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 22:38:31 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 20:38:31 +0000 Subject: [issue13173] Default values for string.Template In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za> Message-ID: <1340570311.65.0.961643529118.issue13173@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: It looks like a doc update to mention the excellent ChainMap class would be a good thing. Bfontaine, are you happy with using a Template subclass or changing your code slightly to have defaults outside of the Template objects, or do you still think the class should be changed? We could run this by the python-ideas mailing list. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13173> _______________________________________ From report at bugs.python.org Sun Jun 24 22:41:03 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 20:41:03 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za> Message-ID: <1340570463.02.0.430911834235.issue15172@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Well, as I said in the other issue, I can't reproduce. Apart from running the self tests, perhaps delete the openssl directory and start afresh? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Sun Jun 24 22:42:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 Jun 2012 20:42:08 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1340570528.36.0.375877833067.issue14315@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: Given that the overall trend in the stdlib seems to be to be more lenient in parsing, as with htmlparser, and that the not-really-strict 'strict' parameter for that is being removed, (#15114) I do not understand the objection to accepting one more malformation in zip files and the desire to add a not-really-strict 'strict' parameter here. Perhaps this philosophical issue should be discussed on pydev. ---------- versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14315> _______________________________________ From report at bugs.python.org Sun Jun 24 22:46:46 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Jun 2012 20:46:46 +0000 Subject: [issue15165] test_email: failure on Windows 64-bit In-Reply-To: <1340567037.81.0.496566862614.issue15165@psf.upfronthosting.co.za> Message-ID: <1340570806.94.0.886037835333.issue15165@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: I haven't touched localtime since pycon, so I presume this hasn't been detected before due to our lack of a windows 64bit buildbot. ---------- components: +email nosy: +barry, belopolsky priority: normal -> high _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15165> _______________________________________ From report at bugs.python.org Sun Jun 24 22:48:24 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Jun 2012 20:48:24 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1340568066.61.0.969484851603.issue14315@psf.upfronthosting.co.za> Message-ID: <1340570921.2758.10.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > I still don't see the bug; the module is behaving correctly - it is the zipfile that is buggy. Supporting this specific kind of buggy zipfiles is a new feature. I agree. The module is behaving correctly. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14315> _______________________________________ From report at bugs.python.org Sun Jun 24 22:52:41 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 20:52:41 +0000 Subject: [issue8916] Move PEP 362 (function signature objects) into inspect In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za> Message-ID: <1340571161.92.0.329819184276.issue8916@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: This may be closed as superseded by #15008, or become a new bug to deprecate getargspec with signature, or a bug for a doc-only deprecation. (Can?t add Yuri to nosy?!) ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8916> _______________________________________ From report at bugs.python.org Sun Jun 24 23:00:42 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 24 Jun 2012 21:00:42 +0000 Subject: [issue8355] diff.py to produce unified format by default In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za> Message-ID: <1340571642.78.0.580764722473.issue8355@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: All of them, especially the last one by Benjamin. ---------- stage: patch review -> committed/rejected status: open -> closed title: diff.py produce unified format by default -> diff.py to produce unified format by default _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8355> _______________________________________ From report at bugs.python.org Sun Jun 24 23:02:36 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 21:02:36 +0000 Subject: [issue15164] add platform.uname() namedtuple interface? In-Reply-To: <1340559170.31.0.985080804132.issue15164@psf.upfronthosting.co.za> Message-ID: <1340571756.27.0.971506892828.issue15164@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Patch isn't ready, no doc changes. But code review can happen. ---------- keywords: +patch Added file: http://bugs.python.org/file26136/larry.platform.unamedtuple.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15164> _______________________________________ From report at bugs.python.org Sun Jun 24 23:15:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 21:15:00 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (3.3) In-Reply-To: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za> Message-ID: <1340572500.18.0.777759464226.issue15102@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Hmm, the buildbot fails compiling again after af1d98b7ca801049803d83a85bb8558f6e59f2a1: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/139 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 23:17:35 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 21:17:35 +0000 Subject: [issue15164] add platform.uname() namedtuple interface? In-Reply-To: <1340559170.31.0.985080804132.issue15164@psf.upfronthosting.co.za> Message-ID: <1340572655.51.0.922047607356.issue15164@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Docs fixed, new unit tests for namedtuple interface added. ---------- Added file: http://bugs.python.org/file26137/larry.platform.unamedtuple.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15164> _______________________________________ From report at bugs.python.org Sun Jun 24 23:18:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 24 Jun 2012 21:18:09 +0000 Subject: [issue1160] Medium size regexp crashes python In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za> Message-ID: <1340572689.67.0.0252878683768.issue1160@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: This has probably been fixed in 3.3 in c67b7e0c818a. ---------- assignee: effbot -> versions: +Python 3.2 -Python 3.1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1160> _______________________________________ From report at bugs.python.org Sun Jun 24 23:20:02 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 21:20:02 +0000 Subject: [issue15102] Fix 64-bit building for buildbot scripts (3.3) In-Reply-To: <1340572500.18.0.777759464226.issue15102@psf.upfronthosting.co.za> Message-ID: <20120624212000.GA3572@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Antoine Pitrou <report at bugs.python.org> wrote: > Hmm, the buildbot fails compiling again after af1d98b7ca801049803d83a85bb8558f6e59f2a1: > > http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/139 I think it's unrelated (probably ssl maintenance going on): cd "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\" "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe" build_ssl.py Release x64 -a Found a working perl at 'C:\perl\bin\perl.exe' Traceback (most recent call last): File "build_ssl.py", line 253, in <module> main() File "build_ssl.py", line 187, in main os.chdir(ssl_dir) PermissionError: [Error 5] Access is denied: '..\\..\\openssl-1.0.1c' [55050 refs] ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15102> _______________________________________ From report at bugs.python.org Sun Jun 24 23:21:16 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 24 Jun 2012 21:21:16 +0000 Subject: [issue15165] test_email: failure on Windows 64-bit In-Reply-To: <1340570806.94.0.886037835333.issue15165@psf.upfronthosting.co.za> Message-ID: <5FBDBB06-E7E6-48ED-806A-D489CE0B7142@gmail.com> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: I don't have a Win 64 setup, but I think replacing 1970 with say 1990 in the tests should fix the problem. ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15165> _______________________________________ From report at bugs.python.org Sun Jun 24 23:27:31 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 21:27:31 +0000 Subject: [issue15164] add platform.uname() namedtuple interface? In-Reply-To: <1340559170.31.0.985080804132.issue15164@psf.upfronthosting.co.za> Message-ID: <1340573251.02.0.42491935906.issue15164@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Third diff, incorporating all of Georg's suggestions. ---------- Added file: http://bugs.python.org/file26138/larry.platform.unamedtuple.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15164> _______________________________________ From report at bugs.python.org Sun Jun 24 23:31:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 21:31:37 +0000 Subject: [issue15164] add platform.uname() namedtuple interface? In-Reply-To: <1340559170.31.0.985080804132.issue15164@psf.upfronthosting.co.za> Message-ID: <E1SiuP9-0007QM-Sb@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 344b06318aca by Larry Hastings in branch 'default': Issue #15164: Change return value of platform.uname() from a http://hg.python.org/cpython/rev/344b06318aca ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15164> _______________________________________ From report at bugs.python.org Sun Jun 24 23:32:25 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 21:32:25 +0000 Subject: [issue15164] add platform.uname() namedtuple interface? In-Reply-To: <1340559170.31.0.985080804132.issue15164@psf.upfronthosting.co.za> Message-ID: <1340573545.93.0.8303312669.issue15164@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Done! And just in time for... something! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15164> _______________________________________ From report at bugs.python.org Sun Jun 24 23:57:09 2012 From: report at bugs.python.org (anatoly techtonik) Date: Sun, 24 Jun 2012 21:57:09 +0000 Subject: [issue8355] diff.py to produce unified format by default In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za> Message-ID: <1340575029.94.0.851137105156.issue8355@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: Eric, you're refering to argument: > -1 Even if diff.py is not exaclty a diff replacement, it still makes > sense to emulate what's in people's minds. Could you explain it in your own words, because I don't posess the skills to read people's minds. > I really don't find having to type 3 more characters a very convincing argument. Which basically reads "my argument against is that your argument for is not a convincing argument", which I read as - "ok, your argument is valid - I don't mind, I don't have arguments - I just don't agree". So, Eric, it will help me understand you better it you could state your own opinion and list arguments that are valid for you in your own words. It is easy to be a part of a public opinion, so without explicit arguments it is hard to say if people just follow the majority to get rid of annoyance or really have the point. ---------- status: closed -> languishing _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8355> _______________________________________ From report at bugs.python.org Mon Jun 25 00:24:12 2012 From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=) Date: Sun, 24 Jun 2012 22:24:12 +0000 Subject: [issue1250] Building external modules using Sun Studio 12 In-Reply-To: <1191964251.86.0.558465608726.issue1250@psf.upfronthosting.co.za> Message-ID: <1340576652.05.0.424090296762.issue1250@psf.upfronthosting.co.za> Maciej Blizi?ski <maciej.blizinski at gmail.com> added the comment: I just hit this issue when trying to build matplotlib. The setup script indeed tries to run the C compiler (/opt/SUNWspro/bin/cc) instead of the C++ compiler (/opt/SUNWspro/bin/CC) and fails. This was with Python 2.6.7. Could the problem be that the UnixCCompiler.executables["compiler_cxx"] is defined to "cc" instead of "CC"? ---------- nosy: +automatthias status: pending -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1250> _______________________________________ From report at bugs.python.org Mon Jun 25 00:34:13 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 24 Jun 2012 22:34:13 +0000 Subject: [issue15174] amd64\python_d.exe -m test fails Message-ID: <1340577253.64.0.707739710326.issue15174@psf.upfronthosting.co.za> New submission from Stefan Krah <stefan-usenet at bytereef.org>: I'm quite sure this worked before, but fails now: C:\Users\stefan\pydev\cpython\PCbuild>amd64\python_d.exe -m test test_ssl Traceback (most recent call last): File "C:\Users\stefan\pydev\cpython\lib\runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "C:\Users\stefan\pydev\cpython\lib\runpy.py", line 75, in _run_code exec(code, run_globals) File "C:\Users\stefan\pydev\cpython\lib\test\__main__.py", line 1, in <module> from test import regrtest, support ImportError: cannot import name regrtest [84466 refs] Calling *from* the amd64 directory is OK: C:\Users\stefan\pydev\cpython\PCbuild\amd64>python_d.exe -m test test_ssl [1/1] test_ssl 1 test OK. [155820 refs] ---------- components: Tests messages: 163871 nosy: pitrou, skrah priority: normal severity: normal status: open title: amd64\python_d.exe -m test fails type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15174> _______________________________________ From report at bugs.python.org Mon Jun 25 00:48:15 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 24 Jun 2012 22:48:15 +0000 Subject: [issue15168] Move importlib.test to test.importlib In-Reply-To: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za> Message-ID: <1340578095.74.0.890499489854.issue15168@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: ---------- nosy: +eric.snow _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15168> _______________________________________ From report at bugs.python.org Mon Jun 25 01:03:54 2012 From: report at bugs.python.org (valera) Date: Sun, 24 Jun 2012 23:03:54 +0000 Subject: [issue11728] mbox parser incorrect behaviour In-Reply-To: <1340559669.43.0.326236024944.issue11728@psf.upfronthosting.co.za> Message-ID: <CALBh0hL54qPvxGnyBqU3i_2hvReJ7C=VD74C2PwMPFaT-d-W=Q@mail.gmail.com> valera <vmasutin at apache.org> added the comment: Hello Petri Qmail manpage does not sound as a valid reference for me, I've pointed relevant RFC (which dictates correct behaviour) as a reference, python mbox parser does not conform to it. Best regards, Valery Masiutsin On Sun, Jun 24, 2012 at 6:41 PM, Petri Lehtinen <report at bugs.python.org>wrote: > > Petri Lehtinen <petri at digip.org> added the comment: > > It seems to me that "^From " is the correct way to match the start of each > message. This is also what the qmail manual page (linked in the previous > message) says. So closing as invalid. > > ---------- > nosy: +petri.lehtinen > resolution: -> invalid > stage: test needed -> committed/rejected > status: open -> closed > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue11728> > _______________________________________ > ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11728> _______________________________________ From report at bugs.python.org Mon Jun 25 01:14:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 23:14:06 +0000 Subject: [issue15039] module/ found before module.py when both are in the CWD In-Reply-To: <1339199943.51.0.731148494988.issue15039@psf.upfronthosting.co.za> Message-ID: <E1Siw0L-0005At-C8@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2051fead1933 by Eric V. Smith in branch 'default': Fixes issue 15039: namespace packages are no longer imported in preference to modules of the same name. http://hg.python.org/cpython/rev/2051fead1933 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15039> _______________________________________ From report at bugs.python.org Mon Jun 25 01:27:42 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 24 Jun 2012 23:27:42 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340580462.22.0.168204681908.issue4489@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment: The fix for this issue broke support for bytes in shutil.rmtree: $ mkdir -p /tmp/a/b $ python3.2 -c 'import shutil; shutil.rmtree(b"/tmp/a")' $ mkdir -p /tmp/a/b $ python3.3 -c 'import shutil; shutil.rmtree(b"/tmp/a")' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib64/python3.3/shutil.py", line 444, in rmtree _rmtree_safe_fd(fd, path, onerror) File "/usr/lib64/python3.3/shutil.py", line 381, in _rmtree_safe_fd fullname = os.path.join(path, name) File "/usr/lib64/python3.3/posixpath.py", line 78, in join if b.startswith(sep): TypeError: startswith first arg must be str or a tuple of str, not bytes $ ---------- priority: normal -> release blocker resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Mon Jun 25 01:44:48 2012 From: report at bugs.python.org (Shanker) Date: Sun, 24 Jun 2012 23:44:48 +0000 Subject: [issue15175] pydoc -k zip throws segmentation fault Message-ID: <1340581488.74.0.233169752541.issue15175@psf.upfronthosting.co.za> New submission from Shanker <shank76 at gmail.com>: user at test:~/learn/python$ pydoc -k zip zipimport - zipimport provides support for importing Python modules from Zip archives. gzip - Functions that read and write gzipped files. lib2to3.fixes.fix_itertools - Fixer for itertools.(imap|ifilter|izip) --> (map|filter|zip) and lib2to3.fixes.fix_itertools_imports - Fixer for imports of itertools.(imap|ifilter|izip|ifilterfalse) lib2to3.fixes.fix_zip - Fixer that changes zip(seq0, seq1, ...) into list(zip(seq0, seq1, ...) zipfile - Read and write ZIP files. ** (python2.7:2599): CRITICAL **: pyg_register_boxed: assertion `boxed_type != 0' failed Segmentation fault (core dumped) user at test:~/learn/python$ user at test:~/learn/python$ uname -a Linux govinda 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux user at test:~/learn/python$ ---------- components: None messages: 163875 nosy: shank priority: normal severity: normal status: open title: pydoc -k zip throws segmentation fault versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15175> _______________________________________ From report at bugs.python.org Mon Jun 25 01:47:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Jun 2012 23:47:56 +0000 Subject: [issue15173] Copyright/licensing statement in new venv module In-Reply-To: <1340569959.64.0.251231198721.issue15173@psf.upfronthosting.co.za> Message-ID: <E1SiwX4-0007Ae-6N@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c96dd645825e by Vinay Sajip in branch 'default': Closes #15173: Tidied up copyright statements and removed pythonv references. http://hg.python.org/cpython/rev/c96dd645825e ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15173> _______________________________________ From report at bugs.python.org Mon Jun 25 01:52:05 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 24 Jun 2012 23:52:05 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340581925.81.0.0558070709456.issue4489@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > The fix for this issue broke support for bytes in shutil.rmtree: What platform? Windows, or non-Windows? It'll probably be obvious regardless, but that might help. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Mon Jun 25 02:40:04 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 Jun 2012 00:40:04 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1340584804.25.0.773664455441.issue14657@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Given Antoine's other change to the build process to fix the bootstrapping problem, I'm OK with leaving it up to anyone hacking on _bootstrap.py to remember that they need to run make if they want the interpreter to see any of their changes. Unlike the C accelerator cases, it's not possible for the two implementations to get out of sync on the buildbots, so running the tests twice would just be a convenience change for anyone hacking on _bootstrap.py rather than being needed for correctness. That said, if someone created a new issue and posted a patch to run the tests twice, I wouldn't object - a classic case of +0 :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14657> _______________________________________ From report at bugs.python.org Mon Jun 25 02:44:03 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jun 2012 00:44:03 +0000 Subject: [issue8355] diff.py to produce unified format by default In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za> Message-ID: <1340585043.42.0.285820583501.issue8355@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Status quo wins a stalemate (and this isn't even really a stalemate. Languishing is for bugs/enhancements no one has stepped up to implement. This one is rejected. ---------- status: languishing -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8355> _______________________________________ From report at bugs.python.org Mon Jun 25 02:52:00 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jun 2012 00:52:00 +0000 Subject: [issue15175] pydoc -k zip throws segmentation fault In-Reply-To: <1340581488.74.0.233169752541.issue15175@psf.upfronthosting.co.za> Message-ID: <1340585520.23.0.686152321417.issue15175@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: This works fine for me. It is almost certain to be a case of something on your pythonpath crashing when pydoc imports it while looking for things that match the keyword. There is unfortunately no way to bullet proof pydoc against this. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15175> _______________________________________ From report at bugs.python.org Mon Jun 25 03:05:44 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 Jun 2012 01:05:44 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1340586344.33.0.673462406609.issue1820@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: ---------- nosy: +eric.snow _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1820> _______________________________________ From report at bugs.python.org Mon Jun 25 03:21:32 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Jun 2012 01:21:32 +0000 Subject: [issue15175] pydoc -k zip throws segmentation fault In-Reply-To: <1340581488.74.0.233169752541.issue15175@psf.upfronthosting.co.za> Message-ID: <1340587292.24.0.690461729898.issue15175@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Which version of Python 2.7.x are you running? If it is less than Python 2.7.3, this is likely a duplicate of Issue7425, the fix for which improved the robustness of pydoc -k as of 2.7.3. ---------- nosy: +ned.deily _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15175> _______________________________________ From report at bugs.python.org Mon Jun 25 03:35:01 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jun 2012 01:35:01 +0000 Subject: [issue15175] pydoc -k zip throws segmentation fault In-Reply-To: <1340581488.74.0.233169752541.issue15175@psf.upfronthosting.co.za> Message-ID: <1340588101.0.0.0366544243822.issue15175@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Ned: since it is a core dump, I doubt the patch for ignoring exceptions during import will fix this. Note that 'pyg_register_boxed' is not a string that appears in the python source, so it is pretty certainly a third party extension module that is segfaulting the interpreter. The following ubuntu bug appears to be relevant: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/896836 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15175> _______________________________________ From report at bugs.python.org Mon Jun 25 05:02:01 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 03:02:01 +0000 Subject: [issue15063] Source code links for JSON documentation In-Reply-To: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za> Message-ID: <1340593321.33.0.532606896909.issue15063@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- resolution: rejected -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15063> _______________________________________ From report at bugs.python.org Mon Jun 25 05:18:55 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 Jun 2012 03:18:55 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340594335.78.0.785867991206.issue4489@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Tinkering with os.path.join, that traceback means that "name" is a str instance, while "path" is a bytes instance. The culprit actually appears to be the fact that the type returned by os.listdir (et al) when handed a file descriptor is always a string (this is not explicitly documented, a problem in itself, but that's the behaviour I see here on linux). One way to handle this would be to use the filesystem encoding with surrogateescape to decode any bytes path passed in to shutil.rmtree (at least in the _rmtree_safe_fd case) and handle the actual removal with Unicode throughout. So long as the original encoding of the supplied bytes path is compatible with that of the underlying filesystem, surrogateescape should ensure that everything round trips correctly. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Mon Jun 25 05:32:06 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 03:32:06 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340595126.33.0.933172428039.issue4489@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Your deduction is correct. listdir can't tell what the original argument type was based on the output--path_converter abstracts away those details. So it separately tests the type of the first argument. Staring at it again it's about as clear as mud, but the goal was, the output is always strings unless the user specified "path" as bytes. I'll make a separate issue regarding making the code easier to read and adding a clarification to the documentation. We should spare future programmers from having to guess at this behavior :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Mon Jun 25 05:39:58 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 03:39:58 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation Message-ID: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> New submission from Larry Hastings <larry at hastings.org>: When you pass in a file descriptor as the first argument to listdir, its output is a list of strings, not a list of bytes. This should be mentioned in the documentation. It's also worth making a pass over the other functions accepting an fd. As it happens, the code that implements this behavior is obtuse. So I propose also modifying it to be more intelligible. ---------- assignee: larry messages: 163885 nosy: georg.brandl, larry, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Clarify the behavior of listdir(fd) in both code and documentation type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 05:57:25 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 25 Jun 2012 03:57:25 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340596645.54.0.801150204796.issue15176@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 06:13:22 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 04:13:22 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) Message-ID: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> New submission from Larry Hastings <larry at hastings.org>: Consider: should os.fwalk() support dir_fd? I think so. In fact, in retrospect it seems like a bug that os.fwalk *doesn't* already support this. Georg: is this a feature or a bugfix? (Wish I'd thought of this Saturday!) I actually did a little experimenting, and got os.fwalk(fd) to work with very little trouble. os.walk(fd) is harder because the recursive step appends a string to the existing path, and it really needs to be relative to the fd, and there's no way to pass both of those at once with the current signature. It's doable but it would require a separate function for the recursive step that accepted a dir_fd anyway. ---------- assignee: larry messages: 163886 nosy: georg.brandl, hynek, larry, pitrou priority: normal severity: normal stage: needs patch status: open title: Support os.walk(dir_fd=) and os.fwalk(dir_fd=) type: behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 06:17:11 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 25 Jun 2012 04:17:11 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340597831.8.0.184761932635.issue15177@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 06:33:05 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 04:33:05 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340598785.37.0.089476229239.issue15176@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Maybe the correct fix for this is to change the interface? os.listdir(path, *, dir_fd=None) Then we'll pick up the return type (str/bytes) from the path variable. It would make #15177 even easier too, should we go down that route. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 06:45:41 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 04:45:41 +0000 Subject: [issue14674] Link to & explain deviations from RFC 4627 in json module docs In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1340599541.14.0.764073814398.issue14674@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: This looks good to me, apart from very minor style things that I can change before committing. Ezio, any last comments? One thing I haven?t done is comparing the length of the new section to the rest of the file to see if it?s a small or big addition; if it?s too big, that would be distracting. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14674> _______________________________________ From report at bugs.python.org Mon Jun 25 06:45:46 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 Jun 2012 04:45:46 +0000 Subject: [issue10592] pprint module doesn't work well with OrderedDicts In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za> Message-ID: <1340599546.56.0.819787041913.issue10592@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- resolution: -> duplicate status: open -> closed superseder: -> general pprint rewrite _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10592> _______________________________________ From report at bugs.python.org Mon Jun 25 06:49:01 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 04:49:01 +0000 Subject: [issue14893] Tutorial: Add function annotation example to function tutorial In-Reply-To: <1337802155.15.0.316800230533.issue14893@psf.upfronthosting.co.za> Message-ID: <1340599741.48.0.203517644065.issue14893@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: LGTM, will commit. ---------- assignee: docs at python -> eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14893> _______________________________________ From report at bugs.python.org Mon Jun 25 06:57:51 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 Jun 2012 04:57:51 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340600271.64.0.897208008255.issue15176@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: +1 for changing the API for any cases where the filesystem path is also used to determine the return type - given that we stuffed this up for the rmtree implementation, I expect end users would be prone to making exactly the same mistake. Retaining the ability to control the return type explicitly even when pass a descriptor would be a *lot* cleaner than other possibilities (which would all involve a bunch of manual encoding and decoding with os.fsencode() and os.fsdecode()). ---------- priority: normal -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 06:59:44 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 04:59:44 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340600384.14.0.500431203891.issue15176@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Nick, how do you feel specifically about listdir(path, *, dir_fd)? I'm mentally exhausted from the past couple of days and have temporarily lost the ability to infer. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 07:11:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 05:11:33 +0000 Subject: [issue12415] Missing: How to checkout the Doc sources In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za> Message-ID: <1340601093.45.0.81251746244.issue12415@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Any comment on my last message? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12415> _______________________________________ From report at bugs.python.org Mon Jun 25 07:14:38 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 05:14:38 +0000 Subject: [issue13799] Base 16 should be hexadecimal in Unicode HOWTO In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za> Message-ID: <1340601278.72.0.832577649632.issue13799@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: I think that when I started programming I was exposed to ?hexadecimal? (e.g. HTML character references can use decimal or hexadecimal numbers) before understanding the generic principle of bases for numbers, so I?m sympathetic to the request. Terry, Sandro, do you have feedback on that? ---------- nosy: +sandro.tosi _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13799> _______________________________________ From report at bugs.python.org Mon Jun 25 07:19:27 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 Jun 2012 05:19:27 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1340601567.4.0.248481924718.issue14591@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: The patch is fine but would be a bit better if the two loop passes were merged and if the "tmp" variable were renamed to something like "nonzero" or somesuch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14591> _______________________________________ From report at bugs.python.org Mon Jun 25 07:20:30 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 05:20:30 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340601630.79.0.0228521103317.issue15176@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Nevermind, I'm an idiot. fdopendir doesn't support dir_fd as a separate path, so listdir can't support it either. There's an unwritten property of the os module on a POSIX system: all the functions are essentially-atomic. This is useful and should not be broken lightly. I'll make a patch clarifying the behavior of listdir. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 07:35:50 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 Jun 2012 05:35:50 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340602550.01.0.570728086932.issue15176@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Don't forget to point people to os.fsencode() if they actually wanted bytes, or os.fsdecode() if they already have bytes and want to convert them to text. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 07:35:52 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 05:35:52 +0000 Subject: [issue12559] gzip.open() needs an optional encoding argument In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za> Message-ID: <1340602552.31.0.901663486395.issue12559@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- nosy: +nadeem.vawda versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12559> _______________________________________ From report at bugs.python.org Mon Jun 25 07:38:14 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 Jun 2012 05:38:14 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1340602694.04.0.0338097160311.issue1508475@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- priority: normal -> high _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1508475> _______________________________________ From report at bugs.python.org Mon Jun 25 07:51:54 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 05:51:54 +0000 Subject: [issue14273] distutils2: logging handler not properly initialized In-Reply-To: <1331592978.94.0.127505196077.issue14273@psf.upfronthosting.co.za> Message-ID: <1340603514.73.0.206049237743.issue14273@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > DEBUG should only be set for messages of interest to developers/support staff/system admins, > and which might confuse end users. The thing is that all logging messages from distutils2 should be sent to handlers, and client code such as pysetup or pip2 can choose the level. The library code however should not filter out DEBUG messages at the logger level?that would make them useless :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14273> _______________________________________ From report at bugs.python.org Mon Jun 25 07:59:13 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 05:59:13 +0000 Subject: [issue14894] distutils.LooseVersion fails to compare number and a word In-Reply-To: <1337805749.61.0.661955519892.issue14894@psf.upfronthosting.co.za> Message-ID: <1340603953.49.0.489464980478.issue14894@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > I think the comparison should continue to succeed, > with whatever results it produces in Python 2.7 The point I was trying to make is that this is not something done on purpose, nor useful or guaranteed, but only a side effect of 2.x?s mixed comparisons. As undefined behavior, I don?t want to change 3.x to match it. Natalia, could you reply to my questions in msg161515 ? Thanks. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14894> _______________________________________ From report at bugs.python.org Mon Jun 25 08:05:18 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 06:05:18 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index In-Reply-To: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za> Message-ID: <1340604318.46.0.555381071019.issue14974@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Fully agreed with Alexis. > index is too generic to convey any kind of meaning and can be confused--at least for > me--with list.index. Sometimes it is better for a name to be specific. But it is specific, thanks to the use of namespaces in Python: it?s distutils2.index/packaging.index. Also take into account that this a module name that will be seen by people writing packaging tools (and thus familiar with ?the Python Packages Index?), not end-users which may be Python developers. Hynek: I don?t understand ?I also think that the pypi term is overloaded with both meanings?. ---------- versions: +Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14974> _______________________________________ From report at bugs.python.org Mon Jun 25 08:05:28 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 06:05:28 +0000 Subject: [issue14974] rename packaging.pypi to packaging.index In-Reply-To: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za> Message-ID: <1340604328.32.0.713821652561.issue14974@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- versions: -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14974> _______________________________________ From report at bugs.python.org Mon Jun 25 08:07:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 06:07:10 +0000 Subject: [issue10968] threading.Timer should be a class so that it can be derived In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za> Message-ID: <1340604430.29.0.540668758709.issue10968@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Ping. ---------- keywords: +needs review stage: -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10968> _______________________________________ From report at bugs.python.org Mon Jun 25 08:09:33 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 06:09:33 +0000 Subject: [issue14202] The docs of xml.dom.pulldom are almost nonexistent In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za> Message-ID: <1340604573.33.0.310009882721.issue14202@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Unassigning; I have to use my Python time for distutils bugs, or doc bugs for modules I actually like (I?m no fan of XML nor DOM :). I would politely insist that doc fixes have to get backported to 2.7 unless it would be really bothersome (like a big change to IO docs done by Antoine and not backported). ---------- assignee: eric.araujo -> docs at python _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14202> _______________________________________ From report at bugs.python.org Mon Jun 25 08:15:55 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 25 Jun 2012 06:15:55 +0000 Subject: [issue11728] mbox parser incorrect behaviour In-Reply-To: <1301573066.6.0.277247050127.issue11728@psf.upfronthosting.co.za> Message-ID: <1340604955.15.0.808570501197.issue11728@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Actually, you're right. Sorry for overlooking the RFC. But that said, the RFC itself refers to the same manpage as a reference that's "mostly authoritative for those variations that are otherwise only documented in anecdotal form". So I guess it's quite a good reference after all :) In Appendix A, RFC 4155 defines a set of rules for a "default" mbox format that maximizes interoperability between different mbox implementations. The important things in the RFC concerning this issue are: * There MUST be an empty line after each message. * The RFC does not specify any escape syntax for message body lines starting with "From ". It says: "Recipient systems are expected to parse full separator lines as they are documented above." Because the RFC states that there must be an empty line after each message, and it aims for maximum interoperability, I think we can assume that there always is an empty line there. But looking for "\n\nFrom " is not enough for finding the starting points of messages. We should actually parse the whole separator line which consists of "From ", an email address (addr-spec in RFC 2822), a timestamp (in UNIX ctime format without timezone), and a newline character. I think this should be the default mode for reading mbox files. See #13698 for adding support for other formats. ---------- components: +email nosy: +barry resolution: invalid -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11728> _______________________________________ From report at bugs.python.org Mon Jun 25 08:17:15 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 06:17:15 +0000 Subject: [issue14920] help(urllib.parse) fails when LANG=C In-Reply-To: <1337976863.52.0.802945658166.issue14920@psf.upfronthosting.co.za> Message-ID: <1340605035.38.0.62902078864.issue14920@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: IMO the right fix would have been to make the docstring a raw string. ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14920> _______________________________________ From report at bugs.python.org Mon Jun 25 08:22:00 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 25 Jun 2012 06:22:00 +0000 Subject: [issue13698] Mailbox module should support other mbox formats in addition to mboxo In-Reply-To: <1325540787.88.0.149207146949.issue13698@psf.upfronthosting.co.za> Message-ID: <1340605320.47.0.240003083837.issue13698@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: The default mode for reading mbox files should also be modified a bit to maximize the support fordifferent implementations. See #11728. I think we should still use the mboxo format by default when writing, and the "default" format of RFC 4155 when reading. We could then add a "format" parameter to the mbox constructor to alter the writing and/or reading behavior to match a specific mbox format. According to RFC 4155, the best reference for different mbox formats is http://qmail.org./man/man5/mbox.html. ---------- components: +email nosy: +barry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13698> _______________________________________ From report at bugs.python.org Mon Jun 25 08:36:06 2012 From: report at bugs.python.org (Mark Summerfield) Date: Mon, 25 Jun 2012 06:36:06 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340606166.24.0.389396927981.issue15133@psf.upfronthosting.co.za> Mark Summerfield <mark at qtrac.eu> added the comment: How about a compromise? Deprecate (but keep BooleanVar) and add BoolVar with proper True/False behavior to match the other *Vars? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Mon Jun 25 09:07:58 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 07:07:58 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340608078.75.0.582022233862.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: My first cut at a patch. Made the logic in posix_listdir easy to follow, fixed up the docstring and docs. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file26139/larry.listdir.clarification.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 09:08:22 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 07:08:22 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340608102.28.0.441768840263.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Whoops, wrong issue, ignore that. (Meant for #15176, going there now.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 09:08:30 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 07:08:30 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340608110.52.0.230452537594.issue15177@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- stage: patch review -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 09:09:53 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 07:09:53 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340608193.31.0.286717813549.issue15176@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: My first cut at a patch. Made the logic in posix_listdir easy to follow, fixed up the docstring and docs. Posted in the correct issue this time. (And Nick: I thought of that independently :D ) ---------- keywords: +patch Added file: http://bugs.python.org/file26140/larry.listdir.clarification.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 09:49:21 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 07:49:21 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340610561.3.0.757498951868.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: What I did: * Added dir_fd=None as a keyword only parameter. * Gave top a default of ".". * Passed through dir_fd in two spots--that was all it took! * Made fwalk contingent on os.stat and os.open both being in support_dir_fd, and os.listdir being in support_fd. * Fixed docstring and docs. * Added unit test for using dir_fd. ---------- Added file: http://bugs.python.org/file26141/larry.fwalk.dir_fd.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 10:01:40 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 25 Jun 2012 08:01:40 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1340611300.2.0.848299820406.issue12268@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: I'm attaching an updated patch for 2.7. It fixes read, readline, readlines and readinto and includes tests. More code auditing for other methods to fix is still needed. ---------- versions: -Python 3.1 Added file: http://bugs.python.org/file26142/fix-signal-eintr-read-27-gps02.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Mon Jun 25 10:05:19 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 25 Jun 2012 08:05:19 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1340611519.74.0.926964625351.issue12268@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: The 3.* ubuntu arm buildbot hanging in test_io is very odd. I'm going to undo my supposedly straight forward signal.alarm(...) to signal.setitimer(...) change first to see if that is related. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Mon Jun 25 10:07:36 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 25 Jun 2012 08:07:36 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1340611656.1.0.211972344023.issue12268@psf.upfronthosting.co.za> Changes by Gregory P. Smith <greg at krypto.org>: Removed file: http://bugs.python.org/file22258/file-signal-eintr-27.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Mon Jun 25 10:12:36 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 25 Jun 2012 08:12:36 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340611956.9.0.911946278811.issue15177@psf.upfronthosting.co.za> Changes by Georg Brandl <georg at python.org>: Removed file: http://bugs.python.org/file26139/larry.listdir.clarification.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 10:14:31 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jun 2012 08:14:31 +0000 Subject: [issue13799] Base 16 should be hexadecimal in Unicode HOWTO In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za> Message-ID: <1340612071.28.0.937179852863.issue13799@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: I learned about different number bases in 8th grade math class (a long time ago) and how to use base 2 to win nim. I learned 'octal' and 'hexadecimal' much later. In the absence of an official, documented vocabulary for such non-Python concepts, I think this should be closed as overly picky and based on an erroneous premise. In any case, programmers should know both terms. Anyone with a deficient math education can look up 'base 16' on Wikipedia and be redirected to hexadecimal as a synonym and read an article that is much longer than one might expect, with more detail than most would want to know. A more obscure term that one might more reasonably object to is 'radix', as in 'radix 16', as a synonym for 'base'. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13799> _______________________________________ From report at bugs.python.org Mon Jun 25 10:16:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 08:16:04 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <E1Sj4Sp-0008BV-B4@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 95b071194ddd by Gregory P. Smith in branch '3.2': Backout change e8f44ebacda7052267318cecf5b6f128d35add17. Reverting the test http://hg.python.org/cpython/rev/95b071194ddd New changeset b4ae7aa21b46 by Gregory P. Smith in branch 'default': Backout change e8f44ebacda7052267318cecf5b6f128d35add17. Reverting the test http://hg.python.org/cpython/rev/b4ae7aa21b46 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Mon Jun 25 10:17:40 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 25 Jun 2012 08:17:40 +0000 Subject: [issue13799] Base 16 should be hexadecimal in Unicode HOWTO In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za> Message-ID: <1340612260.28.0.660772825574.issue13799@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: ?0 from me. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13799> _______________________________________ From report at bugs.python.org Mon Jun 25 10:38:11 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 25 Jun 2012 08:38:11 +0000 Subject: [issue14273] distutils2: logging handler not properly initialized In-Reply-To: <1331592978.94.0.127505196077.issue14273@psf.upfronthosting.co.za> Message-ID: <1340613491.57.0.296989180072.issue14273@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: It's been a while since I looked at this issue, so it would be helpful if you summarised exactly what sort of events are logged at INFO or DEBUG level, and why adding a handler early doesn't work. You said in msg155614 that you would try adding the handler earlier as per my suggestion in msg155584, but I see no feedback on how that changed things. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14273> _______________________________________ From report at bugs.python.org Mon Jun 25 10:39:34 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 25 Jun 2012 08:39:34 +0000 Subject: [issue14273] distutils2: logging handler not properly initialized In-Reply-To: <1331592978.94.0.127505196077.issue14273@psf.upfronthosting.co.za> Message-ID: <1340613574.3.0.467773759496.issue14273@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: One more thing (referring to the opening comment by Tarek): if you add a NullHandler to the top-level logger as recommended in the library docs for libraries, you won't get the "No handlers could be found" message. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14273> _______________________________________ From report at bugs.python.org Mon Jun 25 10:40:22 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 25 Jun 2012 08:40:22 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1340613622.22.0.0156964499683.issue12268@psf.upfronthosting.co.za> Changes by Gregory P. Smith <greg at krypto.org>: Removed file: http://bugs.python.org/file22262/test_and_fix_readers_3.2-gps02.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Mon Jun 25 10:51:51 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 25 Jun 2012 08:51:51 +0000 Subject: [issue13799] Base 16 should be hexadecimal in Unicode HOWTO In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za> Message-ID: <1340614311.27.0.409166651315.issue13799@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: I was tempted to suggest that 'hexadecimal' would be more searchable than 'base 16', but the first Google hit for 'base 16' is: en.wikipedia.org/wiki/Hexadecimal :-) ---------- nosy: +mark.dickinson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13799> _______________________________________ From report at bugs.python.org Mon Jun 25 11:32:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 09:32:25 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340616745.91.0.845449671576.issue15177@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +neologix versions: +Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 11:38:56 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 09:38:56 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340617136.64.0.256882954595.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Second revision of patch. * Removed os.fwalk from os.supports_dir_fd. As Georg points out, you can't test it. (Well, you can, but only if the test would have succeeded.) * Changed fstat(fd) calls to stat(fd) calls. ---------- Added file: http://bugs.python.org/file26143/larry.fwalk.dir_fd.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 11:45:29 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Jun 2012 09:45:29 +0000 Subject: [issue13173] Default values for string.Template In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za> Message-ID: <1340617529.79.0.849769811275.issue13173@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: If the Template defaults should be attached directly to the template instance, then they should be attached directly to the string instance, for classic and modern string formatting. And this obviously is absurd. I agree with ?ric, to mention ChainMap class in the string formatting documentation will be enough. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13173> _______________________________________ From report at bugs.python.org Mon Jun 25 11:45:40 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 09:45:40 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340617540.5.0.192813804283.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Here's a variant of the patch adding os.walk(dir_fd=) support. I'm not pushing for this. I'm not sure it's a must-have; it seems like a nice-to-have, but we're past the time for nice-to-haves. ---------- Added file: http://bugs.python.org/file26144/larry.fwalk.and.walk.dir_fd.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 11:49:35 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 09:49:35 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340617775.5.0.487320262563.issue15176@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Removed "do we have os.listdir" checks from the unit tests. Yes, Virginia, we always have os.listdir in Python 3.3. ---------- Added file: http://bugs.python.org/file26145/larry.listdir.clarification.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 12:10:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Jun 2012 10:10:39 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340619039.2.0.48229540187.issue15177@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Larry, please regenerate patch in Mercurial for review. I have some comments. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 12:16:50 2012 From: report at bugs.python.org (klappnase) Date: Mon, 25 Jun 2012 10:16:50 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340619410.96.0.231244214078.issue15133@psf.upfronthosting.co.za> klappnase <klappnase at web.de> added the comment: I agree that get() should better return a boolean in any case, however the bug then is not one of BooleanVar but rather one of tk.getboolean(). I did some experimenting with get() and it seems that there are three possibilities: getboolean() returns True/False as it should when the variable value was previously set() to anything Tcl accepts as boolean value (like 'yes'/'no', '0'/'1', 'on'/'off', 'true'/'false'). If something which is not a proper Tcl-bool was passed to set() before, getboolean will produce a TclError or TypeError. If set() got 0/1 (as integers) or True/False before, getboolean() will return 0/1 and this appears to me to be the only bug here. But this is not at all a sole BooleanVar bug, e.g.: >>> root=Tk() >>> root.tk_strictMotif() 0 >>> root.tk_strictMotif(1) 1 You will find this everywhere in Tkinter where getboolean() is used, so I think that rather this should be fixed in _tkinter.c than applying a workaround to BooleanVar.get() and leaving all other uses of getboolean() as they are; even worse, if BooleanVar.set() was changed to accept only True/False and getboolean() left as it is, you could not pass the return value of getboolean() any longer to BooleanVar.get() which would be really bad. As far as set() is concerned, it should at least allow everything that Tcl accepts as boolean, according to http://wiki.tcl.tk/16235 these are at least the above mentioned 'yes'/'no', '0'/'1', 'on'/'off', 'true'/'false' (btw. all of these seem to be ok even case insensitive on the tcl side) plus of course 0/1 and True/False. Otherwise it might break existing code. Terry: "Since the purpose of Variables is to synchronize values between user code and tk, TypeVar().set(x).get() should be x when has the proper type. That is now true for everything but bool/Boolean." But when the input type is not proper you can do e.g.: >>> d = DoubleVar() >>> d.set('1.1') >>> d.get() 1.1 >>> i = IntVar() >>> i.set(True) >>> i.get() 1 >>> I think the Variable classes can also be considered convenience objects that save the application programmer a lot of headaches when they have to convert Python objects into Tcl which usually expects strings, so I think there is nothing wrong with set() accepting "improper" values. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Mon Jun 25 12:19:13 2012 From: report at bugs.python.org (klappnase) Date: Mon, 25 Jun 2012 10:19:13 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1340619553.33.0.908910762287.issue15133@psf.upfronthosting.co.za> klappnase <klappnase at web.de> added the comment: "...you could not pass the return value of getboolean() any longer to BooleanVar.get() which would be really bad." Ooops, typo, should be BooleanVar.set() of course. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15133> _______________________________________ From report at bugs.python.org Mon Jun 25 12:26:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Jun 2012 10:26:51 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1340620011.35.0.0207812569954.issue1508475@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: The first step is to answer on the fundamental question: on what level transparent decompression will work? On http.client level or on urllib level? Patch for first case will be much more difficult, but will benefit from compression in other http-based protocols. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1508475> _______________________________________ From report at bugs.python.org Mon Jun 25 12:28:03 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 25 Jun 2012 10:28:03 +0000 Subject: [issue3244] multipart/form-data encoding In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za> Message-ID: <1340620083.92.0.952635501614.issue3244@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: Thanks for the patch, Forest Bond. However, the way I look at this feature, it could be added into urllib.request as a separate handler called MultiPostHandler and request object when it requires it should be able to add it and then use it. Here is a first version of this patch, which would give the idea of how it would be added to the urllib.request (Note this is python3 adaptation of PyPi package by name MultipartPostHandler). I shall see to add this in 3.3 and shall include the tests/docs/howto. ---------- Added file: http://bugs.python.org/file26146/Issue3244.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3244> _______________________________________ From report at bugs.python.org Mon Jun 25 12:30:40 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 10:30:40 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340620240.54.0.252824528984.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Regenerated fwalk(dir_fd=) patch to make Rietveld happy. ---------- Added file: http://bugs.python.org/file26147/larry.fwalk.dir_fd.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 12:30:42 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Jun 2012 10:30:42 +0000 Subject: [issue12559] gzip.open() needs an optional encoding argument In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za> Message-ID: <1340620242.3.0.226927039194.issue12559@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Why not use io.TextWrapper? I think it is the right answer for this issue. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12559> _______________________________________ From report at bugs.python.org Mon Jun 25 12:31:29 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 10:31:29 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340620289.04.0.587840158107.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Regenerated walk(dir_fd=) patch to make Rietveld happy. ---------- Added file: http://bugs.python.org/file26148/larry.fwalk.and.walk.dir_fd.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 12:32:49 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 10:32:49 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340620369.52.0.0518904607874.issue15176@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Regenerated patch to make Reitveld happy. ---------- Added file: http://bugs.python.org/file26149/larry.listdir.clarification.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 12:33:04 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Jun 2012 10:33:04 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340620384.13.0.333441213269.issue15177@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Rietveld is not happy with git diffs. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 12:41:47 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 10:41:47 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340620907.52.0.886892075103.issue15176@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: GRAHH HULK SMASH Regenerating again, because I wasn't actually fresh enough last time. ---------- Added file: http://bugs.python.org/file26150/larry.listdir.clarification.4.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 12:42:37 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 10:42:37 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340620957.21.0.602575437249.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Fourth time's the charm. ---------- Added file: http://bugs.python.org/file26151/larry.fwalk.dir_fd.4.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 12:43:59 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 10:43:59 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340621039.83.0.939129087655.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: What's better than regenerating a bunch of diffs on the off chance that it'll make Rietveld happy? Nothing, that's what. ---------- Added file: http://bugs.python.org/file26152/larry.fwalk.and.walk.dir_fd.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 12:53:45 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 25 Jun 2012 10:53:45 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1340621625.85.0.432705916638.issue1508475@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: I think, the transparent compression should work at http.client level. I also agree with other points made by Serhiy: - transparent decompression should delete headers Content-Encoding and Content-Length (this is as per RFC too) - Should not do another compression if the user has a explicit specified intent of using Content-Encoding: gzip and is ready to do decompression himself. - This transparent compression/decompression would require the availability gzip module, if not then the feature may be disabled and normal request-response cycle would proceed. - I think, having it 'ON' with a flag to switch 'OFF' would be more desirable than having this feature via Handler. The reason being it can help in performance of any requests on servers that support it and browsers have adopted similar approach too. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1508475> _______________________________________ From report at bugs.python.org Mon Jun 25 13:01:45 2012 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Mon, 25 Jun 2012 11:01:45 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable Message-ID: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> New submission from Bohuslav "Slavek" Kabrda <bkabrda at redhat.com>: Hi, I think that doctest should be able to handle situations when the file that is being tested does not exist/is unreadable/etc... Currently, doctest raises an IOError exception and the whole Python ends with an exception and backtrace. I'm attaching a patch that fixes this and prints a simple description of what has gone wrong. Thanks for considering! ---------- components: Library (Lib) files: doctest-dont-end-with-exception-on-unreadable-files.patch keywords: patch messages: 163936 nosy: bkabrda priority: normal severity: normal status: open title: Doctest should handle situations when test files are not readable type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26153/doctest-dont-end-with-exception-on-unreadable-files.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15178> _______________________________________ From report at bugs.python.org Mon Jun 25 13:13:32 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:13:32 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340622812.13.0.111347463727.issue15177@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: Removed file: http://bugs.python.org/file26143/larry.fwalk.dir_fd.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 13:13:39 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:13:39 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340622819.44.0.188322431947.issue15177@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: Removed file: http://bugs.python.org/file26144/larry.fwalk.and.walk.dir_fd.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 13:13:44 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:13:44 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340622824.83.0.0451805550607.issue15177@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: Removed file: http://bugs.python.org/file26147/larry.fwalk.dir_fd.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 13:13:51 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:13:51 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340622831.62.0.494765820728.issue15177@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: Removed file: http://bugs.python.org/file26148/larry.fwalk.and.walk.dir_fd.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 13:14:01 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:14:01 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340622841.79.0.111669453891.issue15176@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: Removed file: http://bugs.python.org/file26145/larry.listdir.clarification.2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 13:14:07 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:14:07 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340622847.59.0.0469184841875.issue15176@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: Removed file: http://bugs.python.org/file26149/larry.listdir.clarification.3.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 13:16:41 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 25 Jun 2012 11:16:41 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340623001.38.0.435564878416.issue15177@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Let's keep it to fwalk. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 13:19:47 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 25 Jun 2012 11:19:47 +0000 Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?= =?utf-8?b?dF9fIGZhaWxz?= In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za> Message-ID: <1340623187.01.0.851967058427.issue10053@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Indeed, there is no pure-Python FileIO: _pyio.py imports it from C: "from _io import FileIO" ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10053> _______________________________________ From report at bugs.python.org Mon Jun 25 13:29:31 2012 From: report at bugs.python.org (Kazutaka Morita) Date: Mon, 25 Jun 2012 11:29:31 +0000 Subject: [issue15179] An infinite loop happens when we use SysLogHandler with eventlet Message-ID: <1340623771.92.0.68954184969.issue15179@psf.upfronthosting.co.za> New submission from Kazutaka Morita <morita.kazutaka at gmail.com>: If we stop a syslog daemon when running the following program, it leads to an infinite loop. == #!/usr/bin/env python import eventlet from logging.handlers import SysLogHandler import time import logging eventlet.patcher.monkey_patch(all=False, socket=True) logger = logging.getLogger('log') logger.addHandler(SysLogHandler('/dev/log')) while True: print "send a message to logger" logger.error("syslog test") time.sleep(1) == It is because there is a close leak in the python logging module, and SysLogHandler continues to send a log message against the closed connection forever. The following patch seems to fix this problem: diff -r 3b5545ba6432 Lib/logging/handlers.py --- a/Lib/logging/handlers.py Wed Jun 13 22:15:26 2012 -0400 +++ b/Lib/logging/handlers.py Mon Jun 25 20:27:46 2012 +0900 @@ -801,7 +801,11 @@ except socket.error: self.socket.close() self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) - self.socket.connect(address) + try: + self.socket.connect(address) + except socket.error: + self.socket.close() + raise def encodePriority(self, facility, priority): """ ---------- components: Library (Lib) messages: 163939 nosy: Kazutaka.Morita priority: normal severity: normal status: open title: An infinite loop happens when we use SysLogHandler with eventlet type: behavior versions: Python 2.7, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15179> _______________________________________ From report at bugs.python.org Mon Jun 25 13:30:40 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 25 Jun 2012 11:30:40 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1340623840.84.0.221735067903.issue14443@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Ping. I would like to have this test failure fixed for 3.3 rc. ---------- nosy: +georg.brandl priority: normal -> deferred blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14443> _______________________________________ From report at bugs.python.org Mon Jun 25 13:32:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 11:32:48 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <E1Sj7XD-00073y-Ba@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 2e2329aeb5c1 by Hynek Schlawack in branch 'default': #4489 Make fd based rmtree work on bytes http://hg.python.org/cpython/rev/2e2329aeb5c1 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Mon Jun 25 13:35:16 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 25 Jun 2012 11:35:16 +0000 Subject: [issue12927] test_ctypes: segfault with suncc In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za> Message-ID: <1340624116.38.0.584364425526.issue12927@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Ping. Could we update libffi for 3.3 final? ---------- nosy: +doko, georg.brandl, loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12927> _______________________________________ From report at bugs.python.org Mon Jun 25 13:35:38 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:35:38 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340624138.09.0.814392092455.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Sure, for 3.3 anyway. I think walk(dir_fd=) should be okay for 3.4. There's a better implementation anyway, where walk() just calls fwalk() and strips the last element off the yielded stuff. But moving on! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 13:41:14 2012 From: report at bugs.python.org (Kazutaka Morita) Date: Mon, 25 Jun 2012 11:41:14 +0000 Subject: [issue15179] An infinite loop happens when we use SysLogHandler with eventlet In-Reply-To: <1340623771.92.0.68954184969.issue15179@psf.upfronthosting.co.za> Message-ID: <1340624474.3.0.879568510876.issue15179@psf.upfronthosting.co.za> Changes by Kazutaka Morita <morita.kazutaka at gmail.com>: ---------- hgrepos: +137 keywords: +patch Added file: http://bugs.python.org/file26154/syslog.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15179> _______________________________________ From report at bugs.python.org Mon Jun 25 13:41:38 2012 From: report at bugs.python.org (Kazutaka Morita) Date: Mon, 25 Jun 2012 11:41:38 +0000 Subject: [issue15179] An infinite loop happens when we use SysLogHandler with eventlet In-Reply-To: <1340623771.92.0.68954184969.issue15179@psf.upfronthosting.co.za> Message-ID: <1340624498.58.0.342290135431.issue15179@psf.upfronthosting.co.za> Changes by Kazutaka Morita <morita.kazutaka at gmail.com>: ---------- hgrepos: -137 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15179> _______________________________________ From report at bugs.python.org Mon Jun 25 13:42:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 11:42:33 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <E1Sj7ge-0007ou-6b@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 8172d8e907a4 by Larry Hastings in branch 'default': Issue #15176: Clarified behavior, documentation, and implementation http://hg.python.org/cpython/rev/8172d8e907a4 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 13:45:37 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 Jun 2012 11:45:37 +0000 Subject: [issue15180] Cryptic traceback from os.path.join when mixing str & bytes Message-ID: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: As seen in #4489, the traceback when mixing str and bytes in os.path.join is rather cryptic and hard to decipher if you've never encountered it before: >>> import os.path >>> os.path.join(b'', '') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.2/posixpath.py", line 78, in join if b.startswith(sep): TypeError: startswith first arg must be str or a tuple of str, not bytes >>> os.path.join('', b'') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.2/posixpath.py", line 78, in join if b.startswith(sep): TypeError: startswith first arg must be bytes or a tuple of bytes, not str While it's slightly less cryptic with a real source file (since you can at least see the os.path.join call), you have to have some how idea of how os.path.join works to realise that: - type(sep) == type(args[0]) - b in args[1:] The challenge is to generate a more user friendly error message without making the normal case of correct types any slower. ---------- components: Library (Lib) messages: 163945 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Cryptic traceback from os.path.join when mixing str & bytes type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15180> _______________________________________ From report at bugs.python.org Mon Jun 25 13:46:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 11:46:36 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <E1Sj7kZ-0008AI-9r@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 814557548af5 by Jesus Cea in branch 'default': Skip test in freebsd entirely - Kernel bug in freebsd7/8/9 - #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/814557548af5 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Mon Jun 25 13:46:46 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 11:46:46 +0000 Subject: [issue12927] test_ctypes: segfault with suncc In-Reply-To: <1340624116.38.0.584364425526.issue12927@psf.upfronthosting.co.za> Message-ID: <20120625114642.GA17703@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Coincidentally, I've just asked the Solaris buildbot owner if he could try out the system libffi. I'm not sure if even the latest libffi supports suncc out of the box. Meador, did you get any answers on libffi-discuss? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12927> _______________________________________ From report at bugs.python.org Mon Jun 25 13:47:20 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 25 Jun 2012 11:47:20 +0000 Subject: [issue15180] Cryptic traceback from os.path.join when mixing str & bytes In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za> Message-ID: <1340624840.94.0.113285837029.issue15180@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Catch TypeError, check whether bytes & str are being mixed, re-raise if not, say something user-friendly if yes? ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15180> _______________________________________ From report at bugs.python.org Mon Jun 25 13:49:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 11:49:15 +0000 Subject: [issue15177] Support os.walk(dir_fd=) and os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <E1Sj7n7-0008HB-SM@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 7bebd9870c75 by Larry Hastings in branch 'default': Issue #15177: Added dir_fd parameter to os.fwalk(). http://hg.python.org/cpython/rev/7bebd9870c75 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 13:50:17 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:50:17 +0000 Subject: [issue15177] Support os.fwalk(dir_fd=) In-Reply-To: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za> Message-ID: <1340625017.74.0.694942095993.issue15177@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: While I was at it, I changed the subject to accurately reflect the changeset's final disposition. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed title: Support os.walk(dir_fd=) and os.fwalk(dir_fd=) -> Support os.fwalk(dir_fd=) _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15177> _______________________________________ From report at bugs.python.org Mon Jun 25 13:50:45 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 11:50:45 +0000 Subject: [issue15176] Clarify the behavior of listdir(fd) in both code and documentation In-Reply-To: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za> Message-ID: <1340625045.81.0.839224599611.issue15176@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Good news, everyone! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15176> _______________________________________ From report at bugs.python.org Mon Jun 25 13:55:49 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 25 Jun 2012 11:55:49 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340625349.4.0.373024445565.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Stefan, I am confused with your comments. The thing is that freebsd defines SEEK_HOLE/SEEK_DATA but reports an error when you use them. I guess they are errors when used on a filesystem that doesn't support them. This is a bug, in my opinion (if a FS doesn't support them, compatible implementation are trivial). In the meantime, I am skipping the test completely under freebsd7/8/9. patch just committed. Testing the patch, but freebsd7 buildbot is really SLOW. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Mon Jun 25 13:57:11 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 Jun 2012 11:57:11 +0000 Subject: [issue15180] Cryptic traceback from os.path.join when mixing str & bytes In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za> Message-ID: <1340625431.29.0.994249132211.issue15180@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Yeah, that should do it - I just hadn't looked at the structure of the code to see how annoying it will be to separate the check out from the if statement. Good use case for PEP 409, too :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15180> _______________________________________ From report at bugs.python.org Mon Jun 25 14:00:26 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 12:00:26 +0000 Subject: [issue15181] importlib.h: suncc warnings Message-ID: <1340625626.44.0.511955354059.issue15181@psf.upfronthosting.co.za> New submission from Stefan Krah <stefan-usenet at bytereef.org>: suncc complains about negative values that are assigned to unsigned char: "Python/importlib.h", line 3634: warning: initializer does not fit or is out of range: -125 "Python/importlib.h", line 3635: warning: initializer does not fit or is out of range: -125 [...] ---------- components: Build messages: 163954 nosy: skrah priority: normal severity: normal status: open title: importlib.h: suncc warnings type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15181> _______________________________________ From report at bugs.python.org Mon Jun 25 14:01:15 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 25 Jun 2012 12:01:15 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340625675.87.0.661099147744.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Greog, I am confused about ARM ubuntu errors. Do we know what ubuntu version is running there?. What is the filesystem?. I am seriously thinking about supporting these flags only in "real" OSs like Solaris & derivatives :-) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Mon Jun 25 14:01:47 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 25 Jun 2012 12:01:47 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340625707.2.0.0525044710481.issue10142@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Jesus, what do you think about removing that test entirely? IMO it is not our job to verify the OS' proper behavior in the face of SEEK_HOLE/SEEK_DATA; it is enough to provide the constants, and let whoever uses it face the perils of the platform. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Mon Jun 25 14:05:11 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 25 Jun 2012 12:05:11 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340625911.72.0.247597139467.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Georg, I am fine with that if you are fine with that :-). Please, confirm :) (sorry for mistyping your name before!) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Mon Jun 25 14:05:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 12:05:49 +0000 Subject: [issue13950] rm commented-out code In-Reply-To: <1328517147.42.0.318507953737.issue13950@psf.upfronthosting.co.za> Message-ID: <E1Sj83A-0001oa-0C@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 381c7f897207 by Ned Deily in branch 'default': Issue #13950: Improve support for OS X Xcode 4: http://hg.python.org/cpython/rev/381c7f897207 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13950> _______________________________________ From report at bugs.python.org Mon Jun 25 14:09:03 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Jun 2012 12:09:03 +0000 Subject: [issue13950] rm commented-out code In-Reply-To: <1328517147.42.0.318507953737.issue13950@psf.upfronthosting.co.za> Message-ID: <1340626143.6.0.606193298223.issue13950@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: ---------- Removed message: http://bugs.python.org/msg163958 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13950> _______________________________________ From report at bugs.python.org Mon Jun 25 14:21:03 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Jun 2012 12:21:03 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340626863.37.0.0865085315875.issue13590@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: [wrong issue number in commit] New changeset 381c7f897207 by Ned Deily in branch 'default': Issue #13590: Improve support for OS X Xcode 4: http://hg.python.org/cpython/rev/381c7f897207 I think this is now in decent shape for 3.3.0b1. Remaining work includes: 1. A backport of a minimal subset to 2.7 and 3.2 so they are usable with Xcode 4 as well 2. Further updates to the README and other documentation 3. Support in distutils2 and post-3.3 packaging 4. More robust support in configure Some of these items may get pushed to separate issues. ---------- priority: deferred blocker -> critical stage: commit review -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Mon Jun 25 14:27:09 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 12:27:09 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1340625349.4.0.373024445565.issue10142@psf.upfronthosting.co.za> Message-ID: <20120625122706.GA14593@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Jes??s Cea Avi??n <report at bugs.python.org> wrote: > Stefan, I am confused with your comments. The FreeBSD bug report you linked to had a test case attached. The test case uses errno == ENXIO. I could not reproduce the failure, so in my *first* comment I questioned whether the failures in test_posix were caused by that particular bug. Then I noticed that the test_posix traceback shows errno == 25 == ENOTTY. So I ran the test case with errno == ENOTTY and I *could* reproduce the bug. In short, I think you linked to the right bug after all. :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Mon Jun 25 14:29:23 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Jun 2012 12:29:23 +0000 Subject: [issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move In-Reply-To: <1333576900.91.0.0583021085072.issue14499@psf.upfronthosting.co.za> Message-ID: <1340627363.27.0.119759287207.issue14499@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: An initial set of changes to support Xcode 4.3+ have been applied for Python 3.3.0b1 have been applied via Issue13590. As noted there, a back port of some subset is needed for 3.2 and 2.7. I'll update this after 3.3.0b1 has been released. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14499> _______________________________________ From report at bugs.python.org Mon Jun 25 14:55:17 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 25 Jun 2012 12:55:17 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340628917.35.0.460965505082.issue14814@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Currently, we get the following warnings: [ 26/369] test_ipaddress /home/vagrant/default/Lib/ipaddress.py:1401: BytesWarning: str() on a bytes instance addr = str(address).split('/') /home/vagrant/default/Lib/ipaddress.py:2004: BytesWarning: str() on a bytes instance addr = str(address).split('/') /home/vagrant/default/Lib/ipaddress.py:1258: BytesWarning: str() on a bytes instance Hadn't time yet to look into it, I might update the ticket as soon as I had. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 25 15:04:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 13:04:37 +0000 Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2) In-Reply-To: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za> Message-ID: <E1Sj8y3-00075I-1l@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 334ff92a8483 by Stefan Krah in branch '3.2': Issue #15171: Try the HOST_PYTHON hack for 3.2. http://hg.python.org/cpython/rev/334ff92a8483 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15171> _______________________________________ From report at bugs.python.org Mon Jun 25 15:06:03 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jun 2012 13:06:03 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1340629563.03.0.434416578848.issue15178@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: In general in Python we let exceptions speak for themselves. It would, however, probably be reasonable to add the try/except and error message in _test, which should only be called when the module is run as a script. ---------- nosy: +r.david.murray versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15178> _______________________________________ From report at bugs.python.org Mon Jun 25 15:10:52 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jun 2012 13:10:52 +0000 Subject: [issue15179] An infinite loop happens when we use SysLogHandler with eventlet In-Reply-To: <1340623771.92.0.68954184969.issue15179@psf.upfronthosting.co.za> Message-ID: <1340629852.12.0.288525506515.issue15179@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +vinay.sajip versions: +Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15179> _______________________________________ From report at bugs.python.org Mon Jun 25 15:20:23 2012 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Mon, 25 Jun 2012 13:20:23 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1340630423.37.0.816293170552.issue15178@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda <bkabrda at redhat.com> added the comment: Thanks for the comment David. I'm attaching second version that does the same in the _test function. ---------- Added file: http://bugs.python.org/file26155/doctest-dont-end-with-exception-on-unreadable-files-v2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15178> _______________________________________ From report at bugs.python.org Mon Jun 25 15:21:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 13:21:52 +0000 Subject: [issue15170] Fix 64-bit building for buildbot scripts (2.7) In-Reply-To: <1340569734.61.0.00630889671182.issue15170@psf.upfronthosting.co.za> Message-ID: <E1Sj9Ek-0000VK-Qh@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 723dbf99f9c2 by Stefan Krah in branch '2.7': Issue #15170: Try the HOST_PYTHON hack for 2.7. http://hg.python.org/cpython/rev/723dbf99f9c2 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15170> _______________________________________ From report at bugs.python.org Mon Jun 25 15:35:11 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 25 Jun 2012 13:35:11 +0000 Subject: [issue15180] Cryptic traceback from os.path.join when mixing str & bytes In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za> Message-ID: <1340631311.24.0.776775067957.issue15180@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Here's a fix. It would be nice if it could make for 3.3 final I guess. Tests pass for Linux and OS X. ---------- keywords: +needs review, patch stage: needs patch -> patch review Added file: http://bugs.python.org/file26156/nicer-error-on-str-bytes-mix.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15180> _______________________________________ From report at bugs.python.org Mon Jun 25 15:42:16 2012 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 25 Jun 2012 13:42:16 +0000 Subject: [issue15182] find_library_file() should try to link Message-ID: <1340631736.41.0.714328941122.issue15182@psf.upfronthosting.co.za> New submission from Jeroen Demeyer <jdemeyer at cage.ugent.be>: The find_library_function() in Lib/distutils/unixccompiler.py does a very simple-minded check to determine the existence of a library. It basically only checks that a certain .so file exists. This may lead to false positives: the mere existence of a .so file does not imply that we can actually link against that library. In addition to (or even better: instead of) checking the existence of the file, you should try to (in the spirit of autoconf) compile a simple program using $CC -l$LIB prog.c -o prog One particular instance of where things can go wrong is with a 32-bit/64-bit multilib installation. Python might find a 64-bit library in /usr/lib when we're actually compiling 32-bit with libraries in /usr/lib32. ---------- assignee: eric.araujo components: Distutils messages: 163968 nosy: eric.araujo, jdemeyer, tarek priority: normal severity: normal status: open title: find_library_file() should try to link type: compile error versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15182> _______________________________________ From report at bugs.python.org Mon Jun 25 15:51:36 2012 From: report at bugs.python.org (Forest Bond) Date: Mon, 25 Jun 2012 13:51:36 +0000 Subject: [issue3244] multipart/form-data encoding In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za> Message-ID: <1340632296.02.0.644118690816.issue3244@psf.upfronthosting.co.za> Forest Bond <forest at alittletooquiet.net> added the comment: Hi Senthil Kumaran, Thanks for the feedback & patch. I agree having support in urllib probably makes some sense. But why not implement basic support elsewhere and then tie it into urllib so those of us using something else can also use it? I'm using httplib in my application. Thanks, Forest ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3244> _______________________________________ From report at bugs.python.org Mon Jun 25 16:01:04 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Jun 2012 14:01:04 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1340632864.99.0.786784341337.issue15178@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Great, thanks. There's a loop around testfiles. I think it would be nicer to not call sys.exit. You could at the same time fix what appears to be a bug in the loop code. It looks like 1 is currently returned only if the last file fails. Hmm, and given that there is a bug, adding tests would be great if you are up for it. I don't think there are currently any tests of the doctest command line functionality. That's more complicated than writing the fix, though :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15178> _______________________________________ From report at bugs.python.org Mon Jun 25 16:02:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 14:02:45 +0000 Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2) In-Reply-To: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za> Message-ID: <1340632965.07.0.391880406202.issue15171@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: The buildbot works with the HOST_PYTHON hack. Should we just leave this as a permanent solution? -- I don't feel like touching the project files for stable releases. [%CD% should probably be quoted in the patch.] ---------- components: +Build resolution: -> fixed stage: -> commit review type: -> crash versions: +Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15171> _______________________________________ From report at bugs.python.org Mon Jun 25 16:10:02 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 14:10:02 +0000 Subject: [issue12927] test_ctypes: segfault with suncc In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za> Message-ID: <1340633402.29.0.426285229762.issue12927@psf.upfronthosting.co.za> Changes by Stefan Krah <stefan-usenet at bytereef.org>: ---------- nosy: +Justin.Venus _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12927> _______________________________________ From report at bugs.python.org Mon Jun 25 16:15:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 14:15:10 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za> Message-ID: <1340633710.5.0.807889433293.issue15172@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: By contrast, 2.7 and 3.2 look ok. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Mon Jun 25 16:19:01 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 25 Jun 2012 14:19:01 +0000 Subject: [issue15180] Cryptic traceback from os.path.join when mixing str & bytes In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za> Message-ID: <1340633941.65.0.757489864627.issue15180@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15180> _______________________________________ From report at bugs.python.org Mon Jun 25 16:26:47 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 25 Jun 2012 14:26:47 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za> Message-ID: <1340634407.51.0.850857301802.issue15172@psf.upfronthosting.co.za> Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment: The OpenSSL (64-bit build) does not pass its own tests, while the 32-bit build from the same source works just fine. Stefan, how did you get your 64-bit build to work? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Mon Jun 25 16:41:05 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 25 Jun 2012 14:41:05 +0000 Subject: [issue12927] test_ctypes: segfault with suncc In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za> Message-ID: <1340635265.78.0.156531772576.issue12927@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: Stefan, nope -- I never got a reply. I will try again. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12927> _______________________________________ From report at bugs.python.org Mon Jun 25 16:44:55 2012 From: report at bugs.python.org (endolith) Date: Mon, 25 Jun 2012 14:44:55 +0000 Subject: [issue13698] Mailbox module should support other mbox formats in addition to mboxo In-Reply-To: <1325540787.88.0.149207146949.issue13698@psf.upfronthosting.co.za> Message-ID: <1340635495.1.0.488099254513.issue13698@psf.upfronthosting.co.za> endolith <endolith at gmail.com> added the comment: > - If the mailbox is written using the mboxrd format and read using the mboxo format, lines that were meant to start with ">From " are changed to ">>>From ". This is a new type of corruption. Well, yes. So the choices are: mboxrd as default: Sometimes results in corruption mboxo as default: Always results in corruption Is there a way to reliably detect the format of the file and produce an error if it seems to be reading it wrong? If not, maybe just include a function that guesses the format so the correct option can be found easily? If there are consecutive ">" quoted lines, like this, for instance: >This is the body. >>From my point of view >there are 3 lines. then it was probably encoded with mboxrd? If instead you find: >This is the body. >From my point of view >there are 3 lines. then it was probably encoded with mboxo? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13698> _______________________________________ From report at bugs.python.org Mon Jun 25 16:56:02 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 14:56:02 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za> Message-ID: <1340636162.64.0.95838002998.issue15172@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: It worked out of the box for me. These are the versions I use: # openssl version: svn export http://svn.python.org/projects/external/openssl-1.0.1c # nasm version (installer): nasm-2.10.01-installer.exe Let me see what I did: cd openssl-1.0.1c nmake -f ms\nt.mak clean nmake -f ms\nt64.mak clean cd ..\cpython Tools\buildbot\clean.bat Tools\buildbot\clean-amd64.bat Tools\buildbot\build-amd64.bat cd PCbuild\amd64 python_d.exe -m test -uall test_hmac [1/1] test_hmac 1 test OK. [111184 refs] python_d.exe -m test -uall test_ssl [...] File "C:\Users\stefan\pydev\cpython\lib\ssl.py", line 513, in do_handshake self._sslobj.do_handshake() ConnectionResetError: [Error 10054] An existing connection was forcibly closed by the remote host Now I get this error but it seems quite unrelated. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Mon Jun 25 17:06:19 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 25 Jun 2012 15:06:19 +0000 Subject: [issue15179] An infinite loop happens when we use SysLogHandler with eventlet In-Reply-To: <1340623771.92.0.68954184969.issue15179@psf.upfronthosting.co.za> Message-ID: <1340636779.93.0.171189477395.issue15179@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: Why should the socket need closing if the connect fails? This seems a flawed contract; either connect() should work (in which case the socket will need closing when it's finished with) or it should fail, not connect and not require a close call (as it isn't connected). Could this be a problem with eventlet? One could argue that the leak is actually in whatever implements socket.connect in this case (presumably eventlet). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15179> _______________________________________ From report at bugs.python.org Mon Jun 25 17:06:25 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 15:06:25 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za> Message-ID: <1340636785.67.0.883770352767.issue15172@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: The openssl self tests also pass here. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Mon Jun 25 17:23:49 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 25 Jun 2012 15:23:49 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <1340636785.67.0.883770352767.issue15172@psf.upfronthosting.co.za> Message-ID: <CAGvrs3LsZdp4OVMM7MD9YDc1qR1rsL3dKT9kL0+ES7FNXfPPMg@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: I've narrowed this down to a CPU capabilities issue with OpenSSL. What CPU are you using? I have a Q9450 (Core2 Quad) If I set OPENSSL_ia32cap to 0 the self tests work. I'm now off to debug OpenSSL CPUID support... :( ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Mon Jun 25 17:26:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 15:26:41 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za> Message-ID: <1340638001.88.0.313343304683.issue15172@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > If I set OPENSSL_ia32cap to 0 the self tests work. I'm now off to > debug OpenSSL CPUID support... :( At this point, I think asking for help on an OpenSSL mailing-list or IRC channel is a good idea. (unless you want to do the debugging yourself, that is :)) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Mon Jun 25 17:30:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 15:30:16 +0000 Subject: [issue15179] An infinite loop happens when we use SysLogHandler with eventlet In-Reply-To: <1340623771.92.0.68954184969.issue15179@psf.upfronthosting.co.za> Message-ID: <1340638216.87.0.088167255581.issue15179@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > This seems a flawed contract; either connect() should work (in which > case the socket will need closing when it's finished with) or it should > fail, not connect and not require a close call (as it isn't connected) socket.close() closes the file descriptor, not only the underlying network connection. Otherwise the file descriptor will stay open until the socket object is garbage collected. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15179> _______________________________________ From report at bugs.python.org Mon Jun 25 17:31:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 15:31:43 +0000 Subject: [issue15180] Cryptic traceback from os.path.join when mixing str & bytes In-Reply-To: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za> Message-ID: <1340638303.15.0.454054136165.issue15180@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Just a nit, you can use double quotes instead of escaping apostrophes ;) ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15180> _______________________________________ From report at bugs.python.org Mon Jun 25 17:33:48 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 25 Jun 2012 15:33:48 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340638428.83.0.495264707494.issue14814@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Ok I looked into it. It uses str() to convert objects into text representation which it then parses. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 25 17:36:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 15:36:28 +0000 Subject: [issue15181] importlib.h: suncc warnings In-Reply-To: <1340625626.44.0.511955354059.issue15181@psf.upfronthosting.co.za> Message-ID: <E1SjBL0-0004dq-GL@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 6dc9472346de by Antoine Pitrou in branch 'default': Issue #15181: importlib bytecode is unsigned and shouldn't have negative numbers. http://hg.python.org/cpython/rev/6dc9472346de ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15181> _______________________________________ From report at bugs.python.org Mon Jun 25 17:36:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 15:36:55 +0000 Subject: [issue15181] importlib.h: suncc warnings In-Reply-To: <1340625626.44.0.511955354059.issue15181@psf.upfronthosting.co.za> Message-ID: <1340638615.02.0.225681007609.issue15181@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: It should be fixed now! ---------- nosy: +pitrou resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15181> _______________________________________ From report at bugs.python.org Mon Jun 25 17:40:24 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 15:40:24 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <CAGvrs3LsZdp4OVMM7MD9YDc1qR1rsL3dKT9kL0+ES7FNXfPPMg@mail.gmail.com> Message-ID: <20120625154022.GA14017@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Jeremy Kloth <report at bugs.python.org> wrote: > I've narrowed this down to a CPU capabilities issue with OpenSSL. > What CPU are you using? I have a Q9450 (Core2 Quad) Core 2 Duo E8500. But I run Windows under Linux/kvm/qemu, in case that matters. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Mon Jun 25 17:47:23 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 15:47:23 +0000 Subject: [issue15181] importlib.h: suncc warnings In-Reply-To: <1340638615.02.0.225681007609.issue15181@psf.upfronthosting.co.za> Message-ID: <20120625154721.GB14017@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: + fprintf(outfile, "%d,", (unsigned int) data[i]); Hmm, "%u"? :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15181> _______________________________________ From report at bugs.python.org Mon Jun 25 17:49:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 15:49:10 +0000 Subject: [issue15181] importlib.h: suncc warnings In-Reply-To: <20120625154721.GB14017@sleipnir.bytereef.org> Message-ID: <1340639133.3387.0.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: Le lundi 25 juin 2012 ? 15:47 +0000, Stefan Krah a ?crit : > > + fprintf(outfile, "%d,", (unsigned int) data[i]); > > Hmm, "%u"? :) It doesn't change anything, since data[i] is between 0 and 255. (unless C `int` is 8 bits on your computer, but I doubt it :-)) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15181> _______________________________________ From report at bugs.python.org Mon Jun 25 17:53:03 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 15:53:03 +0000 Subject: [issue15181] importlib.h: suncc warnings In-Reply-To: <1340639133.3387.0.camel@localhost.localdomain> Message-ID: <20120625155302.GA14186@sleipnir.bytereef.org> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Antoine Pitrou <report at bugs.python.org> wrote: > > + fprintf(outfile, "%d,", (unsigned int) data[i]); > > > > Hmm, "%u"? :) > > It doesn't change anything, since data[i] is between 0 and 255. > (unless C `int` is 8 bits on your computer, but I doubt it :-)) That's true, but we might get another compiler warning about that. No big deal of course. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15181> _______________________________________ From report at bugs.python.org Mon Jun 25 18:03:32 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 25 Jun 2012 16:03:32 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1340640212.04.0.209667980177.issue10142@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: As long as we have a test confirming that SEEK_HOLE/SEEK_DATA are *accepted* by the io module (which is a big part of the patch), it is fine. E.g. calling seek() with the constants and check that it only raises OSError or nothing should work, right? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10142> _______________________________________ From report at bugs.python.org Mon Jun 25 18:26:47 2012 From: report at bugs.python.org (Philip Olson) Date: Mon, 25 Jun 2012 16:26:47 +0000 Subject: [issue12415] Missing: How to checkout the Doc sources In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za> Message-ID: <1340641607.67.0.902478313873.issue12415@psf.upfronthosting.co.za> Philip Olson <philip at roshambo.org> added the comment: I think you should make the commit. Also, the aforementioned [old] Subversion reference for Sphinx is a real issue here. And I think the "Without make" section should link to http://sphinx.pocoo.org/ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12415> _______________________________________ From report at bugs.python.org Mon Jun 25 19:04:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 17:04:36 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1340643876.7.0.317274746971.issue12268@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I don't think setitimer() is the culprit, rather the fact that the timeout is too short. You could try setting it to e.g. 0.4. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Mon Jun 25 19:07:22 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 25 Jun 2012 17:07:22 +0000 Subject: [issue15165] test_email: failure on Windows 64-bit In-Reply-To: <1340567037.81.0.496566862614.issue15165@psf.upfronthosting.co.za> Message-ID: <1340644042.05.0.892966499831.issue15165@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: I am surprised that we don't see the same failure on 32-bit windows buildbot. Windows mktime does not support negative time_t in either 32 or 64 bit version: http://msdn.microsoft.com/en-us/library/d1y53h2a(v=vs.110).aspx We are probably just lucky and no Windows buildbot uses a TZ set ahead of UTC. Stefan, what is your timezone? What is happening here is that mktime() is called for 1970-01-01 00:00 which results in positive timestamp for the timezones west of Greenwich and negative timestamp east of Greenwich. For example, using GNU date: $ TZ=Europe/Paris date -d "1970-01-01 00:00" +%s -3600 $ TZ=America/New_York date -d "1970-01-01 00:00" +%s 18000 I am adding Victor as an expert on pushing the limits of date/time functions. ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15165> _______________________________________ From report at bugs.python.org Mon Jun 25 19:24:56 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 25 Jun 2012 17:24:56 +0000 Subject: [issue15165] test_email: failure on Windows In-Reply-To: <1340567037.81.0.496566862614.issue15165@psf.upfronthosting.co.za> Message-ID: <1340645096.84.0.220406417774.issue15165@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: My timezone is CET, so that fits your explanation. Indeed, the failure also occurs on Windows 32-bit. ---------- title: test_email: failure on Windows 64-bit -> test_email: failure on Windows _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15165> _______________________________________ From report at bugs.python.org Mon Jun 25 19:28:27 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 25 Jun 2012 17:28:27 +0000 Subject: [issue15155] sporadic failure in RecvmsgSCTPStreamTest In-Reply-To: <1340493704.97.0.818384658063.issue15155@psf.upfronthosting.co.za> Message-ID: <1340645307.98.0.644294722387.issue15155@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali <neologix at free.fr>: ---------- resolution: -> duplicate status: open -> closed superseder: -> Sporadic failure in test_socket _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15155> _______________________________________ From report at bugs.python.org Mon Jun 25 19:33:33 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 25 Jun 2012 17:33:33 +0000 Subject: [issue15165] test_email: failure on Windows In-Reply-To: <1340567037.81.0.496566862614.issue15165@psf.upfronthosting.co.za> Message-ID: <1340645613.92.0.499041913555.issue15165@psf.upfronthosting.co.za> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment: Is this something that has to be fixed during the freeze? The fix is trivial: s/1970/1990/g, but I planned to revisit TZ-dependent tests during the beta period. I think we don't use run_with_tz() enough. It would also be great to make it work on windows. ---------- assignee: -> belopolsky _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15165> _______________________________________ From report at bugs.python.org Mon Jun 25 19:35:10 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 25 Jun 2012 17:35:10 +0000 Subject: [issue15152] test_subprocess fqailures on awfully slow builtbots In-Reply-To: <1340550799.79.0.291823496864.issue15152@psf.upfronthosting.co.za> Message-ID: <CAH_1eM175aqwKVDBrznLm8Kjg+_4YBmnb39KumaueCuMAr9HdA@mail.gmail.com> Charles-Fran?ois Natali <neologix at free.fr> added the comment: > You could make the test a loop, with the timeout increasing each time through the loop, failing only if all tries fail. ?That way on faster machines the test will pass faster. ?It'll take even longer on slow machines, but they are slow anyway so that may be acceptable. Yes, sure, but then it'll only make the test non determinist: let's say there's a non reproductible bug in subprocess' timeout implementation, if we retry upon error, it won't get caught unless if fails a couple time in a row, which may never happen. The idea is to have a timeout large enough so that the probablility of false positives is *low enough*. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15152> _______________________________________ From report at bugs.python.org Mon Jun 25 19:37:11 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 25 Jun 2012 17:37:11 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1337623099.23.0.0346715901578.issue14702@psf.upfronthosting.co.za> Message-ID: <CAH_1eM3uk2KPGRxZo5eeREm+EuLCO3vtKAstB_5A=E05jVvC3Q@mail.gmail.com> Charles-Fran?ois Natali <neologix at free.fr> added the comment: I still don't like the idea of adding such a kludge to work around OS bugs, so I'd suggest closing as won't fix. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14702> _______________________________________ From report at bugs.python.org Mon Jun 25 19:46:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 17:46:33 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1340646393.57.0.74526340059.issue14702@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: +1 for closing. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14702> _______________________________________ From report at bugs.python.org Mon Jun 25 19:55:52 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 25 Jun 2012 17:55:52 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1340646952.39.0.744594995443.issue6422@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6422> _______________________________________ From report at bugs.python.org Mon Jun 25 19:56:54 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 25 Jun 2012 17:56:54 +0000 Subject: [issue5633] fix for timeit when the statement is a string and the setup is not (and tests) In-Reply-To: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za> Message-ID: <1340647014.84.0.0353696072305.issue5633@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- title: fix for timeit when the statment is a string and the setup is not (and tests) -> fix for timeit when the statement is a string and the setup is not (and tests) _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5633> _______________________________________ From report at bugs.python.org Mon Jun 25 20:02:00 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 25 Jun 2012 18:02:00 +0000 Subject: [issue15183] it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count Message-ID: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>: I looked at 'python -m time -h' and the timeit doc, and it was not clear to me (after a quick read) that the statement(s) inside --setup option and setup keyword argument weren't included in the speed test. I had to check for myself by writing code. ---------- assignee: docs at python components: Documentation messages: 163999 nosy: docs at python, tshepang priority: normal severity: normal status: open title: it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15183> _______________________________________ From report at bugs.python.org Mon Jun 25 20:02:47 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 25 Jun 2012 18:02:47 +0000 Subject: [issue15183] it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count In-Reply-To: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za> Message-ID: <1340647367.89.0.690327792806.issue15183@psf.upfronthosting.co.za> Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment: sorry, I meant 'python -m timeit -h' ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15183> _______________________________________ From report at bugs.python.org Mon Jun 25 20:19:45 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 25 Jun 2012 18:19:45 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340648385.49.0.834776088706.issue14814@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: And the origin of the bytes seems to be: # Compatibility function to cast str to bytes objects _cb = lambda bytestr: bytes(bytestr, 'charmap') ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Mon Jun 25 20:59:04 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 25 Jun 2012 18:59:04 +0000 Subject: [issue13698] Mailbox module should support other mbox formats in addition to mboxo In-Reply-To: <1340635495.1.0.488099254513.issue13698@psf.upfronthosting.co.za> Message-ID: <20120625185900.GA3555@chang> Petri Lehtinen <petri at digip.org> added the comment: endolith wrote: > > - If the mailbox is written using the mboxrd format and read using > > - the mboxo format, lines that were meant to start with ">From " > > - are changed to ">>>From ". This is a new type of corruption. > > Well, yes. So the choices are: > > mboxrd as default: Sometimes results in corruption > mboxo as default: Always results in corruption I don't think so. Assuming that mboxo (the current default) was used to write the mailbox, both formats sometimes result in corruption. mboxo as default: "From " lines get written (and subsequently read) as ">From ". mboxrd as default: ">From " lines were written as ">From " but are read as "From ". Furthermore, if Python's mailbox module is used to write the mbox file and another software, that only supports mboxo, is used to read it (e.g. mutt), having mboxrd as the default would case ">From " lines to be written as ">>From ". These linew would then be read as ">>From " by the reading software. So, I'd like to keep the default as is, and add a parameter to change to mboxrd when it's OK for the use case at hand. We should also clearly document that mboxrd is recommended as it never corrupts data if used for both reading and writing. > Is there a way to reliably detect the format of the file and produce > an error if it seems to be reading it wrong? > > If not, maybe just include a function that guesses the format so the > correct option can be found easily? If there are consecutive ">" > quoted lines, like this, for instance: > > >This is the body. > >>From my point of view > >there are 3 lines. > > then it was probably encoded with mboxrd? If instead you find: > > >This is the body. > >From my point of view > >there are 3 lines. > > then it was probably encoded with mboxo? It's not possible to automatically detect the format. Guessing like you suggested is too fragile. It might work on some situations, but wouldn't work on others. If it was possible to detect the format by guessing, I'm sure RFC 4155 would mention that, as it aims for the best possible outcome for reading any of the formats, without knowing which format is actually in use. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13698> _______________________________________ From report at bugs.python.org Mon Jun 25 21:07:58 2012 From: report at bugs.python.org (Dave Malcolm) Date: Mon, 25 Jun 2012 19:07:58 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1340651278.32.0.838769664289.issue14443@psf.upfronthosting.co.za> Dave Malcolm <dmalcolm at redhat.com> added the comment: The approach Nick suggests seems reasonable, but rpm.expandMacro isn't usable: there's no guarantee that the machine has Python bindings for rpm installed (especially not for the version of Python that we've just built). However, we can get at the macro by shelling out to the "rpm" command: subprocess.getoutput('rpm --eval %{__os_install_post}') I'm attaching a patch which does this; works on my RHEL 6.3 test box. ---------- Added file: http://bugs.python.org/file26157/fix-14443.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14443> _______________________________________ From report at bugs.python.org Mon Jun 25 21:13:21 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 25 Jun 2012 19:13:21 +0000 Subject: [issue1599254] mailbox: other programs' messages can vanish without trace Message-ID: <1340651601.81.0.675938804435.issue1599254@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: It seems to me that there are three separate issues here: 1) Concurrent access to a single-file mailbox will discard some messages even if locking is correctly used. This is demonstrated by mailbox-test.patch, which despite its age applies on top of 3.2 and fails (at least for me) 2) Detecting changes to mbox files is hard and should be improved. 3) When the TOC of an mbox is re-read, the message keys should probably be kept intact. Otherwise, the application would need to prepare for the fact that keys can change without notice in the middle of a loop, for example. The first point is a serious bug that should be fixed somehow. The second point has been discussed in greath lengths, but it strikes me that the mtime tracking has not been suggested. AFAIK, this is what most/all mbox readers do. The toc should be re-read when the mtime changes and/or is newer than atime. The third point also sounds important, but might be tricky to implement. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1599254> _______________________________________ From report at bugs.python.org Mon Jun 25 21:15:34 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 25 Jun 2012 19:15:34 +0000 Subject: [issue15184] Test failure in test_sysconfig_module Message-ID: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za> New submission from Georg Brandl <georg at python.org>: On default, have this single failure on my box (Gentoo amd64): ====================================================================== FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python/Lib/distutils/tests/test_sysconfig.py", line 105, in test_sysconfig_module self.assertEqual(global_sysconfig.get_config_var('LDSHARED'),sysconfig.get_config_var('LDSHARED')) AssertionError: 'gcc -pthread -shared' != '/usr/bin/clang -shared' - gcc -pthread -shared + /usr/bin/clang -shared While clang is installed, I haven't set anything to clang while configuring, or in my environment. ---------- components: Tests messages: 164005 nosy: eric.araujo, georg.brandl priority: high severity: normal status: open title: Test failure in test_sysconfig_module versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15184> _______________________________________ From report at bugs.python.org Mon Jun 25 21:19:52 2012 From: report at bugs.python.org (Dave Malcolm) Date: Mon, 25 Jun 2012 19:19:52 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1340651992.28.0.908520275073.issue14443@psf.upfronthosting.co.za> Dave Malcolm <dmalcolm at redhat.com> added the comment: (with the patch, it also continues to work on a test Fedora 15 box) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14443> _______________________________________ From report at bugs.python.org Mon Jun 25 21:20:31 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 25 Jun 2012 19:20:31 +0000 Subject: [issue14698] test_posix failures - getpwduid()/initgroups()/getgroups() In-Reply-To: <1335774640.36.0.246153891142.issue14698@psf.upfronthosting.co.za> Message-ID: <1340652031.71.0.895849367338.issue14698@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali <neologix at free.fr>: ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14698> _______________________________________ From report at bugs.python.org Mon Jun 25 21:22:13 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 25 Jun 2012 19:22:13 +0000 Subject: [issue1522400] irda socket support Message-ID: <1340652133.89.0.730018895492.issue1522400@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali <neologix at free.fr>: ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1522400> _______________________________________ From report at bugs.python.org Mon Jun 25 21:53:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 19:53:21 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <E1SjFLb-000303-4I@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset a9a12ad553f0 by David Malcolm in branch 'default': Issue #14443: ensure that brp-python-bytecompile is invoked with the correct http://hg.python.org/cpython/rev/a9a12ad553f0 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14443> _______________________________________ From report at bugs.python.org Mon Jun 25 22:06:06 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 25 Jun 2012 20:06:06 +0000 Subject: [issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za> Message-ID: <1340654766.72.0.260031037314.issue13590@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: This may have caused failures on non-darwin unix OSes: #15184 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13590> _______________________________________ From report at bugs.python.org Mon Jun 25 22:09:15 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 25 Jun 2012 20:09:15 +0000 Subject: [issue15172] SHA1 failures on the 64-bit Windows buildbot In-Reply-To: <20120625154022.GA14017@sleipnir.bytereef.org> Message-ID: <CAGvrs3KzuZ0yH3OcjhkE+j7hhKtuTRSPuwZ7VLsX+S0mKxy5qw@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: Ok, the final verdict on this issue is that nasm is to blame. I had nasm 2.09.02 installed. I upgraded it to version 2.10.01 and magically OpenSSL started working. >From the nasm changelog is seems that the added instruction sets in 2.10 are required for building OpenSSL with asm optimizations (the default for Windows from 1.0.1). This seems like a good candidate for adding to the devguide (and any other building documents). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Mon Jun 25 22:16:50 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 25 Jun 2012 20:16:50 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340655410.99.0.874679737629.issue15110@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Here is a patch which removes "<frozen importlib._bootstrap>" frames from tracebacks. Tests are missing, but this gives good result on the few samples I tried. "python -v" does not suppress importlib frames. ---------- keywords: +patch Added file: http://bugs.python.org/file26158/importlib-frames.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 22:17:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 25 Jun 2012 20:17:39 +0000 Subject: [issue13672] Add co_qualname attribute in code objects In-Reply-To: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za> Message-ID: <1340655459.16.0.424414770037.issue13672@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment: Could this patch be included in Python 3.3? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13672> _______________________________________ From report at bugs.python.org Mon Jun 25 22:20:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 20:20:07 +0000 Subject: [issue13672] Add co_qualname attribute in code objects In-Reply-To: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za> Message-ID: <1340655607.97.0.485961688097.issue13672@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: PyCode_New and PyCode_NewEmpty are documented public APIs, so you can't change their signatures like that. ---------- nosy: +georg.brandl stage: needs patch -> patch review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13672> _______________________________________ From report at bugs.python.org Mon Jun 25 22:21:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 20:21:17 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340655677.38.0.814763771206.issue15110@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Wouldn't it be better to do it in pure Python in importlib itself? ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 22:23:29 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 25 Jun 2012 20:23:29 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340655809.53.0.324861704571.issue15110@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 22:26:01 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 25 Jun 2012 20:26:01 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340655961.89.0.464682556634.issue15110@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: I tried to do it in importlib, with code like raise original_exception.with_traceback(trimmed_traceback) but the function containing this very line would always be part of the displayed stack trace. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 22:30:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 20:30:54 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340656254.6.0.253915370803.issue15110@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Perhaps at least the trimming should only be done for ImportErrors, then? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 22:35:52 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 25 Jun 2012 20:35:52 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340656552.72.0.321794847397.issue15110@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: No, the example above is a SyntaxError, and I claim the importlib frames should be removed as well. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 22:40:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 20:40:27 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340656827.55.0.956506343754.issue15110@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Ah, you're right. But it could become confusing if some error is raised inside of importlib itself (not an ImportError, something else - perhaps a bug). So I would suggest the following: - trim ImportErrors - trim errors raised when executing the code of an imported module (i.e. in _LoaderBasics._load_module()) - don't trim other errors, since they can be importlib programming errors ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 22:42:11 2012 From: report at bugs.python.org (Dave Malcolm) Date: Mon, 25 Jun 2012 20:42:11 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340656931.14.0.0204977473783.issue15110@psf.upfronthosting.co.za> Changes by Dave Malcolm <dmalcolm at redhat.com>: ---------- nosy: +dmalcolm _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 22:49:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 Jun 2012 20:49:12 +0000 Subject: [issue15110] strange Tracebacks with importlib In-Reply-To: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za> Message-ID: <1340657352.93.0.835747706898.issue15110@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: About this proposal: > - trim errors raised when executing the code of an imported module (i.e. in _LoaderBasics._load_module()) The exec() could be isolated in a distinctly-named submethod (e.g. _exec_module()), so that it is easy to detect it in a traceback. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15110> _______________________________________ From report at bugs.python.org Mon Jun 25 23:08:27 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 Jun 2012 21:08:27 +0000 Subject: [issue15184] Test failure in test_sysconfig_module In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za> Message-ID: <1340658507.77.0.0843139333134.issue15184@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: ---------- nosy: +ned.deily _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15184> _______________________________________ From report at bugs.python.org Mon Jun 25 23:29:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 25 Jun 2012 21:29:35 +0000 Subject: [issue15169] Clear C code under PyImport_ExecCodeModuleObject() In-Reply-To: <1340567956.17.0.18413889062.issue15169@psf.upfronthosting.co.za> Message-ID: <1340659775.96.0.432941332033.issue15169@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: The problem of deferring to 3.4 is that it will lock in semantics which are honestly weird and not desirable for PyImport_ExecCodeModuleObject() which is new in 3.3. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15169> _______________________________________ From report at bugs.python.org Tue Jun 26 00:20:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Jun 2012 22:20:39 +0000 Subject: [issue15179] An infinite loop happens when we use SysLogHandler with eventlet In-Reply-To: <1340623771.92.0.68954184969.issue15179@psf.upfronthosting.co.za> Message-ID: <E1SjHeA-00080m-Js@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 99f0c0207faa by Vinay Sajip in branch '2.7': Issue #15179: Closed socket on connection failure. Thanks to Kazutaka Morita for the patch. http://hg.python.org/cpython/rev/99f0c0207faa New changeset 1bc1a14feb70 by Vinay Sajip in branch '3.2': Issue #15179: Closed socket on connection failure. Thanks to Kazutaka Morita for the patch. http://hg.python.org/cpython/rev/1bc1a14feb70 New changeset 6af0535b5e3a by Vinay Sajip in branch 'default': Closes #15179: Merged fix from 3.2. http://hg.python.org/cpython/rev/6af0535b5e3a ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15179> _______________________________________ From report at bugs.python.org Tue Jun 26 00:31:41 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Jun 2012 22:31:41 +0000 Subject: [issue15185] Validate callbacks in 'contextlib.ExitStack.callback()' Message-ID: <1340663500.78.0.8609663108.issue15185@psf.upfronthosting.co.za> New submission from Yury Selivanov <yselivanov at gmail.com>: With this patch 'contextlib.ExitStack.callback(callback, *args, **kwds)' will validate that the passed callback actually accept the passed '*args' and '**kwds'. P.S. If this patch comes through - I'll create two more issues for 'atexit.register' and 'unittest.TestCase.addCleanup'. (I'll also look through the stdlib to find if there are some other places where this is needed.) ---------- components: Library (Lib) files: contextlib.patch keywords: patch messages: 164021 nosy: Yury.Selivanov, ncoghlan priority: normal severity: normal status: open title: Validate callbacks in 'contextlib.ExitStack.callback()' type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file26159/contextlib.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15185> _______________________________________ From report at bugs.python.org Tue Jun 26 01:05:43 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Jun 2012 23:05:43 +0000 Subject: [issue8916] Move PEP 362 (function signature objects) into inspect In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za> Message-ID: <1340665543.51.0.69152721152.issue8916@psf.upfronthosting.co.za> Yury Selivanov <yselivanov at gmail.com> added the comment: ?ric, yes, please close it. ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8916> _______________________________________ From report at bugs.python.org Tue Jun 26 01:11:34 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Jun 2012 23:11:34 +0000 Subject: [issue15185] Validate callbacks in 'contextlib.ExitStack.callback()' In-Reply-To: <1340663500.78.0.8609663108.issue15185@psf.upfronthosting.co.za> Message-ID: <1340665894.42.0.882943728992.issue15185@psf.upfronthosting.co.za> Changes by Yury Selivanov <yselivanov.ml at gmail.com>: ---------- nosy: +yselivanov _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15185> _______________________________________ From report at bugs.python.org Tue Jun 26 01:39:45 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 Jun 2012 23:39:45 +0000 Subject: [issue15186] Support os.walk(dir_fd=) Message-ID: <1340667585.2.0.886069096281.issue15186@psf.upfronthosting.co.za> New submission from Larry Hastings <larry at hastings.org>: Adds dir_fd support to os.walk(). Just re-yields from os.fwalk(), removing the last element. Note: Python 3.4. ---------- assignee: larry files: larry.os.walk.dir_fd.1.diff keywords: patch messages: 164023 nosy: larry priority: normal severity: normal stage: patch review status: open title: Support os.walk(dir_fd=) type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26160/larry.os.walk.dir_fd.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15186> _______________________________________ From report at bugs.python.org Tue Jun 26 02:03:30 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 26 Jun 2012 00:03:30 +0000 Subject: [issue15186] Support os.walk(dir_fd=) In-Reply-To: <1340667585.2.0.886069096281.issue15186@psf.upfronthosting.co.za> Message-ID: <1340669010.44.0.315195563562.issue15186@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15186> _______________________________________ From report at bugs.python.org Tue Jun 26 02:07:28 2012 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 Jun 2012 00:07:28 +0000 Subject: [issue15185] Validate callbacks in 'contextlib.ExitStack.callback()' In-Reply-To: <1340663500.78.0.8609663108.issue15185@psf.upfronthosting.co.za> Message-ID: <1340669248.74.0.865907872102.issue15185@psf.upfronthosting.co.za> Yury Selivanov <yselivanov.ml at gmail.com> added the comment: (my previous message edit: no support for 'atexit' - it's implemented in C) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15185> _______________________________________ From report at bugs.python.org Tue Jun 26 03:02:41 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Jun 2012 01:02:41 +0000 Subject: [issue15185] Validate callbacks in 'contextlib.ExitStack.callback()' In-Reply-To: <1340663500.78.0.8609663108.issue15185@psf.upfronthosting.co.za> Message-ID: <1340672561.73.0.12990485662.issue15185@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: I'm not comfortable adding a dependency on inspect to the contextlib module, and I think it would be undesirable to have too many cases where the early validation is silently skipped. While I like the idea of adding early signature validation to these APIs in principle, given the above concerns and the fact this probably crosses the line into "feature" territory, I think we want to wait until 3.4 and the introduction of a mechanism that adds introspection support to callables implemented in C. That will likely involve moving the signature support somewhere lower in the module stack (perhaps to a private "_signature" module, with inspect remaining the official API), and will reduce the number of cases where pre-validation is skipped. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15185> _______________________________________ From report at bugs.python.org Tue Jun 26 03:54:54 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jun 2012 01:54:54 +0000 Subject: [issue15187] test_shutil does not clean up after itself Message-ID: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> New submission from R. David Murray <rdmurray at bitdance.com>: test_shutil leaves several (six) directories in /tmp. This eventually fills /tmp on my buildbots and causes subsequent test runs to fail. ---------- components: Tests keywords: buildbot messages: 164026 nosy: hynek, r.david.murray priority: normal severity: normal stage: needs patch status: open title: test_shutil does not clean up after itself type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 04:29:46 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 26 Jun 2012 02:29:46 +0000 Subject: [issue8916] Move PEP 362 (function signature objects) into inspect In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za> Message-ID: <1340677786.91.0.000978900825872.issue8916@psf.upfronthosting.co.za> Changes by ?ric Araujo <merwok at netwok.org>: ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> PEP 362 "Signature Objects" reference implementation _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue8916> _______________________________________ From report at bugs.python.org Tue Jun 26 04:40:21 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Jun 2012 02:40:21 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1340678421.72.0.430209251882.issue6422@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: Looking at this again after more time has passes, I still think exposing autoranging is a good idea but I don't like the patch as it stands. It "infects" the API in a number of places and makes the overall module harder to use and learn. Ideally, there should be a cleaner interface, or more limited API change, or a separate high level function that can autorange existing functions without changing their API. Anyone care to propose a cleaner API? ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6422> _______________________________________ From report at bugs.python.org Tue Jun 26 05:57:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jun 2012 03:57:59 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <E1SjMub-00065f-FD@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 67dc99a989cd by Gregory P. Smith in branch '2.7': Fixes issue #12268 for file readline, readlines and read() and readinto methods. http://hg.python.org/cpython/rev/67dc99a989cd ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Tue Jun 26 06:04:59 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 26 Jun 2012 04:04:59 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1340683499.62.0.638177100924.issue12268@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: The uses of fwrite() and fflush() also need this EINTR treatment in 2.7. I haven't checked the write paths in 3.2 yet. Also, the fix change to 3.2's _io module needs backporting to 2.7's _io module for people using that. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12268> _______________________________________ From report at bugs.python.org Tue Jun 26 06:10:51 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 04:10:51 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <1340683851.97.0.244099624643.issue15187@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 06:21:23 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 04:21:23 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <1340684483.28.0.714680139088.issue15187@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Patch attached. On my machine it used to leave six directories, now it leaves none. ---------- keywords: +patch Added file: http://bugs.python.org/file26161/larry.fix.shutil.test.tmp.dirs.1.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 06:21:31 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Jun 2012 04:21:31 +0000 Subject: [issue15186] Support os.walk(dir_fd=) In-Reply-To: <1340667585.2.0.886069096281.issue15186@psf.upfronthosting.co.za> Message-ID: <1340684491.02.0.855802808937.issue15186@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: Can you elaborate on why this is needed? The os.path.walk() API is already somewhat complex. Additional features can make the tool less usable/learnable for most users. ---------- nosy: +rhettinger _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15186> _______________________________________ From report at bugs.python.org Tue Jun 26 06:25:54 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Jun 2012 04:25:54 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1340684754.94.0.421378396751.issue14591@psf.upfronthosting.co.za> Changes by Raymond Hettinger <raymond.hettinger at gmail.com>: ---------- assignee: rhettinger -> mark.dickinson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14591> _______________________________________ From report at bugs.python.org Tue Jun 26 06:32:29 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 04:32:29 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <1340685149.28.0.202931824082.issue15187@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Georg, you want this fixed for beta 1? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 06:33:26 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Jun 2012 04:33:26 +0000 Subject: [issue15034] tutorial should use best practices in user defined exceptions section In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1340685206.19.0.148201502268.issue15034@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: This seems more like a Stack Overflow question or fodder for a blog post. When such best practices become well known and agreed upon, they can be added toa HOWTO document. The tutorial is problematic because beginners start there and sprinkling the nuances of super() throughout the tutorial will only get in the way of the main learning points for a given section. ---------- nosy: +rhettinger resolution: -> later status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Tue Jun 26 06:52:50 2012 From: report at bugs.python.org (Justin Venus) Date: Tue, 26 Jun 2012 04:52:50 +0000 Subject: [issue12927] test_ctypes: segfault with suncc In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za> Message-ID: <1340686370.26.0.692392124607.issue12927@psf.upfronthosting.co.za> Justin Venus <justin.venus at gmail.com> added the comment: I can confirm (see attachement) that `--with-system-ffi` prevents the segfault on test_ctypes with the solaris compiler on Solaris11 x86. I did not have to update the system at all for this switch to work. ---------- Added file: http://bugs.python.org/file26162/python3x_ctypes-systemffi.txt.gz _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12927> _______________________________________ From report at bugs.python.org Tue Jun 26 07:09:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 26 Jun 2012 05:09:45 +0000 Subject: [issue12927] test_ctypes: segfault with suncc In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za> Message-ID: <1340687385.02.0.823621120854.issue12927@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Antoine, is it possible to add --with-system-ffi to the build rules of the Solaris/suncc bot? This will prevent the segfaults. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12927> _______________________________________ From report at bugs.python.org Tue Jun 26 07:21:36 2012 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 26 Jun 2012 05:21:36 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1340688096.08.0.874199690595.issue15178@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda <bkabrda at redhat.com> added the comment: Sure, if you give me some time, I'll try to do everything as you suggest. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15178> _______________________________________ From report at bugs.python.org Tue Jun 26 07:27:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jun 2012 05:27:45 +0000 Subject: [issue15186] Support os.walk(dir_fd=) In-Reply-To: <1340667585.2.0.886069096281.issue15186@psf.upfronthosting.co.za> Message-ID: <1340688465.29.0.624912690554.issue15186@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Can you elaborate on why this is needed? 1. Unification with fwalk and other os functions. 2. Performance. Larry, can you use fwalk even for dir_fd is None (if fwalk exists, of cause)? ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15186> _______________________________________ From report at bugs.python.org Tue Jun 26 07:30:13 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 26 Jun 2012 05:30:13 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <1340688613.4.0.692820845151.issue15187@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: LGTM ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 08:05:21 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 26 Jun 2012 06:05:21 +0000 Subject: [issue15172] Document nasm-2.10.01 as required version for openssl In-Reply-To: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za> Message-ID: <1340690721.27.0.707480389165.issue15172@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Good that it works now. I've tagged this as a documentation issue. ---------- assignee: -> docs at python components: +Documentation -Tests keywords: -buildbot nosy: +docs at python title: SHA1 failures on the 64-bit Windows buildbot -> Document nasm-2.10.01 as required version for openssl type: behavior -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15172> _______________________________________ From report at bugs.python.org Tue Jun 26 08:16:39 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 26 Jun 2012 06:16:39 +0000 Subject: [issue13685] argparse update help msg for % signs In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za> Message-ID: <1340691399.64.0.477481235732.issue13685@psf.upfronthosting.co.za> Changes by Senthil Kumaran <senthil at uthcode.com>: ---------- title: argparse does not sanitize help strings for % signs -> argparse update help msg for % signs _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13685> _______________________________________ From report at bugs.python.org Tue Jun 26 08:17:31 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 06:17:31 +0000 Subject: [issue15186] Support os.walk(dir_fd=) In-Reply-To: <1340667585.2.0.886069096281.issue15186@psf.upfronthosting.co.za> Message-ID: <1340691451.45.0.925436589154.issue15186@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Actually I think Raymond makes a good point. Re: symmetry: tbh that's nonsense. The reason for symmetry among functions in the os module is because they do similar things--but this is because "form follows function". We didn't decide to decorate functions with extra parameters just so they'd look nice. The reason you want a function to support "dir_fd" is to make it safer; using functions taking "dir_fd" and some careful programming, you can prevent some forms of timing attack. But we can't fix os.walk to make it safe in this way--which is why we have os.fwalk in the first place! So users of os.walk with this problem simply don't need "dir_fd"--they need os.fwalk. Re: performance: if some people care about performance here, and this approach is faster, then those people can just call os.fwalk directly. This approach to os.walk(dir_fd=) just calls os.fwalk--so calling it directly could only be even faster. (This is assuming my favored implementation which just calls os.fwalk--which is simple, and leverages os.fwalk doing a proper safe job of it. If we use my hackier previous version, I suspect it only made os.walk slower. Of course all of this is silly microbenchmarking anyway, and I'm not sure that these fiddling implementation details of os.walk / os.fwalk contribute to their runtime cost in any significant way.) I counter-propose adding some text to os.walk steering people to os.fwalk for "advanced usage". That might even be appropriate for 3.3 (beta 2). I realize they are neighbors in the documentation, but it might save at least one benighted myopic soul. I further propose to leave this issue open for now--there's no rush, really--and see if a compelling reason for os.walk(dir_fd=) appears. If none does, then in the fullness of time we can close this as wontfix and move on, living our lives in the dazzling sunshine of righteous truth and justice. Your move, Serhiy ;-) p.s. Serhiy: yes, you can call os.fwalk() with dir_fd=None. It would be *awful* if you could not! And actually, os.fwalk didn't even support dir_fd until... 26 hours ago. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15186> _______________________________________ From report at bugs.python.org Tue Jun 26 08:18:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jun 2012 06:18:31 +0000 Subject: [issue13685] argparse update help msg for % signs In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za> Message-ID: <E1SjP6a-0007gl-06@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c696416eb4e9 by Senthil Kumaran in branch '3.2': Issue #13685 - Update argparse help message for % sign usage. http://hg.python.org/cpython/rev/c696416eb4e9 New changeset 493d58c3c57f by Senthil Kumaran in branch 'default': merge from 3.2 - Issue13685 http://hg.python.org/cpython/rev/493d58c3c57f ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13685> _______________________________________ From report at bugs.python.org Tue Jun 26 08:19:09 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 26 Jun 2012 06:19:09 +0000 Subject: [issue13685] argparse update help msg for % signs In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za> Message-ID: <1340691549.98.0.664984829249.issue13685@psf.upfronthosting.co.za> Changes by Senthil Kumaran <senthil at uthcode.com>: ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13685> _______________________________________ From report at bugs.python.org Tue Jun 26 08:19:34 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 26 Jun 2012 06:19:34 +0000 Subject: [issue15184] Test failure in test_sysconfig_module In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za> Message-ID: <1340691574.39.0.996245547498.issue15184@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: This test failure points at a few issues: - The CFLAGS modification should only be taking place on OS X systems. AFAICT, all of that code is protected by sys.platform checks. One possible culprit, though, might be distutils test test_unixccompiler which attempts to test various platforms by mocking sys.platform. It so happens that "darwin" is the first platform it tests and, while the test setup and teardown does preserve and restore the get_config_var function in distutils.sysconfig, it doesn't preserve the module global _config_vars which distutils.sysconfig uses to cache the results of parsing the Makefile. I wonder what happens if test_unixccompiler happens to be the first caller of distutils.sys_config_vars(). I think it will get invoked with sys.platform = 'darwin' and trigger the customization code on what becomes the cached copy for remaining tests. I'm attaching a patch to preserve and restore the cached values as well. Georg, I'd appreciate it if you could try this on your system. - More importantly, the test failure shows that the code we added for Xcode 4 support in Issue13590 only addressed distutils.sysconfig and not the identical code in standalone sysconfig. With the removal of packaging in 3.3, AFAIK there now is nothing in the standard library that should depend on this at the moment but it will undoubtedly be an issue for distutil2 and future packaging features. We had discussed dealing with this by factoring out the common customization code into a separate module to avoid DRY but I didn't get that done. I'm attaching a first rough patch that does that; it is only very lightly tested and so should not be a candidate for 3.3.0b1. I recommend the following steps: 1. For 3.3.0b1, either ignore the test failure or add a skip for 3.3.0b1. (This failure will also likely show up if OS X installer users attempt to run the tests.) 2. Resolve the test failure on non-OS X platforms. 3. Test and review the refactoring patch and plan to push it for 3.3.0rc1. 4. Post 3.3.0, regardless of the outcome of the proposed packaging PEPs, finally replace distutils.sysconfig with sysconfig. Attempting to continue to maintain both of them is just asking for more trouble. ---------- assignee: -> ned.deily components: +Distutils, Macintosh -Tests keywords: +patch nosy: +ronaldoussoren, tarek priority: high -> deferred blocker stage: -> patch review Added file: http://bugs.python.org/file26163/issue15184_preserve_config_vars.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15184> _______________________________________ From report at bugs.python.org Tue Jun 26 08:20:04 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 26 Jun 2012 06:20:04 +0000 Subject: [issue15184] Test failure in test_sysconfig_module In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za> Message-ID: <1340691604.61.0.812613807645.issue15184@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: Added file: http://bugs.python.org/file26164/issue15184_osx_support.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15184> _______________________________________ From report at bugs.python.org Tue Jun 26 08:21:22 2012 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 26 Jun 2012 06:21:22 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1340691682.17.0.834621891258.issue15178@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda <bkabrda at redhat.com> added the comment: So I figured it might be best to first agree on the actual behaviour (what the patch will look like) and then I can write the tests. So here is my 3rd version: - It seems that returning 1 only if last file fails is intentional, as it is _inside_ the loop, so unsuccessful test immediately terminates the _test function - I thought it might be better to carry on with all of the tests, so here is what I did: - I made a variable "failures", which represents if there were any failures during tests; - I took the "return 1" one indentation level down, so all files are now traversed no matter how many of them fail; - An error message is printed and "failures" set to True if a file is unopenable. Does this look acceptable? If not, I will happily work further :) (and provide the tests once the behaviour is clear). Thanks! ---------- Added file: http://bugs.python.org/file26165/doctest-dont-end-with-exception-on-unreadable-files-v3.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15178> _______________________________________ From report at bugs.python.org Tue Jun 26 08:29:54 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 06:29:54 +0000 Subject: [issue15186] Support os.walk(dir_fd=) In-Reply-To: <1340667585.2.0.886069096281.issue15186@psf.upfronthosting.co.za> Message-ID: <1340692194.86.0.435551016682.issue15186@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: p.s. Raymond: fwiw, I think "makes it easy / hard for beginners" is only of secondary importance. Certainly I think it's reasonable to point out in a discussion, and if the beginners are easy to accommodate then okay. But if there was something that was a big win in most ways but made life harder for beginners, imo the beginners would have to take it on the chin. I reflect now and then on the fascinating point you made on Radio Free Python--"Unicode is now day-0 knowledge for Python"--but I have no idea what to do about it. Or about the larger point of accommodating beginners in the face of mounting language complexity. *shrug* My point is, I agree that os.walk(dir_fd=) probably shouldn't happen--but that's simply because we don't need it. Whether or not it made life easier or harder for beginners didn't really figure into my consideration. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15186> _______________________________________ From report at bugs.python.org Tue Jun 26 08:31:35 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 06:31:35 +0000 Subject: [issue15186] Support os.walk(dir_fd=) In-Reply-To: <1340667585.2.0.886069096281.issue15186@psf.upfronthosting.co.za> Message-ID: <1340692295.98.0.155655357456.issue15186@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Whoops, you wrote "for most users" rather than talking about beginners. Sorry if I was responding to a point you weren't making ;-) I guess I assumed you were coming at this at least partially while wearing your "Python lecturer" hat. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15186> _______________________________________ From report at bugs.python.org Tue Jun 26 08:32:17 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 06:32:17 +0000 Subject: [issue15184] Test failure in test_sysconfig_module In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za> Message-ID: <1340692337.62.0.320971747617.issue15184@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Sounds good. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15184> _______________________________________ From report at bugs.python.org Tue Jun 26 08:32:45 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 06:32:45 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <1340692365.11.0.0150384179709.issue15187@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Yep. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 08:39:01 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 26 Jun 2012 06:39:01 +0000 Subject: [issue7360] [mailbox] race: mbox may lose data with concurrent access In-Reply-To: <1258647622.46.0.810277433722.issue7360@psf.upfronthosting.co.za> Message-ID: <1340692741.8.0.504631482015.issue7360@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: I created #15122 for adding an option to rewrite the contents of single-file mailboxes in-place. Closing this issue as wontfix. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed superseder: -> Add an option to always rewrite single-file mailboxes in-place. _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7360> _______________________________________ From report at bugs.python.org Tue Jun 26 08:51:16 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 06:51:16 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <1340693476.28.0.603495065801.issue15187@psf.upfronthosting.co.za> Changes by Larry Hastings <larry at hastings.org>: ---------- assignee: -> larry priority: normal -> release blocker resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 08:52:27 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 26 Jun 2012 06:52:27 +0000 Subject: [issue15188] test_ldshared_value failure on OS X using python.org Pythons Message-ID: <1340693547.43.0.234356884387.issue15188@psf.upfronthosting.co.za> New submission from Ned Deily <nad at acm.org>: ====================================================================== FAIL: test_ldshared_value (test.test_sysconfig.TestSysConfig) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_sysconfig.py", line 288, in test_ldshared_value self.assertIn(ldflags, ldshared) AssertionError: '-arch i386 -arch x86_64 -g -L/tmp/_py/libraries/usr/local/lib' not found in 'gcc-4.2 -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -isysroot /Developer/SDKs/MacOSX10.6.sdk -g -L/tmp/_py/libraries/usr/local/lib' ---------------------------------------------------------------------- There is code in Mac/BuildScript/build-installer.py to remove the temporary build library path (/tmp/_py/libraries/usr/local/lib) from the Makefile after the build is complete and before the files are packaged. In 3.3 there is now also a Makefile cache file, _sysconfigdata.py, which is produced as a build target. build-installer.py needs to learn how to clean it up as well. ---------- assignee: ned.deily components: Build, Macintosh messages: 164049 nosy: ned.deily, ronaldoussoren priority: high severity: normal status: open title: test_ldshared_value failure on OS X using python.org Pythons versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15188> _______________________________________ From report at bugs.python.org Tue Jun 26 08:54:31 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 06:54:31 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <1340693671.62.0.427460844318.issue15187@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: This was fixed in 1fa50bbcc21f1458c1dc00ea733b76e6405b8cbb . (I think the tracker had an aneurysm when the notification showed up.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 09:10:57 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 07:10:57 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340694657.05.0.20796188842.issue1677@psf.upfronthosting.co.za> Changes by Georg Brandl <georg at python.org>: ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Tue Jun 26 09:11:18 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 07:11:18 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340694678.67.0.446408443375.issue1677@psf.upfronthosting.co.za> Changes by Georg Brandl <georg at python.org>: ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Tue Jun 26 09:15:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jun 2012 07:15:28 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <E1SjPzi-0003jk-F9@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 6b1d4e3ce867 by Larry Hastings in branch 'default': Fix issue # in Misc/NEWS (should be #15187, not 15817.) http://hg.python.org/cpython/rev/6b1d4e3ce867 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 09:16:31 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 Jun 2012 07:16:31 +0000 Subject: [issue15187] test_shutil does not clean up after itself In-Reply-To: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za> Message-ID: <1340694991.19.0.846596968992.issue15187@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: (No wonder it had an aneurysm!) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15187> _______________________________________ From report at bugs.python.org Tue Jun 26 09:19:48 2012 From: report at bugs.python.org (Mark Summerfield) Date: Tue, 26 Jun 2012 07:19:48 +0000 Subject: [issue15189] tkinter.messagebox does not use the application's icon Message-ID: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za> New submission from Mark Summerfield <mark at qtrac.eu>: The tkinter.messagebox functions, e.g., askyesno(), do not use the application's icon (if it has one). Nor do they accept a bitmapicon option, so ISTM that it is "impossible" to set one. The same is true of tkinter.dialog, but for that it is easy enough to write one's own replacement with the code like this: try: tkinter._default_root.iconbitmap(iconName) except tk.TclError as err: print(err) (where iconName is "path/to/icon.ico" on windows, "@path/to/icon.xbm" on Unix; and this isn't done on Mac). ---------- components: Tkinter messages: 164053 nosy: mark priority: normal severity: normal status: open title: tkinter.messagebox does not use the application's icon versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15189> _______________________________________ From report at bugs.python.org Tue Jun 26 09:21:51 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 26 Jun 2012 07:21:51 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340695311.34.0.510040618286.issue4489@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Tue Jun 26 09:28:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jun 2012 07:28:04 +0000 Subject: [issue12170] index() and count() methods of bytes and bytearray should accept byte ints In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za> Message-ID: <E1SjQBv-0004qr-76@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 018fe1dee9b3 by Petri Lehtinen in branch 'default': What's new: Add myself as the contributor of issue 12170 http://hg.python.org/cpython/rev/018fe1dee9b3 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12170> _______________________________________ From report at bugs.python.org Tue Jun 26 10:22:25 2012 From: report at bugs.python.org (Ztatik Light) Date: Tue, 26 Jun 2012 08:22:25 +0000 Subject: [issue15190] Allow whitespace and comments after line line continuation character \ Message-ID: <1340698945.14.0.356106357277.issue15190@psf.upfronthosting.co.za> New submission from Ztatik Light <ztatik.light at gmail.com>: See Title ---------- components: Interpreter Core messages: 164055 nosy: Ztatik.Light priority: normal severity: normal status: open title: Allow whitespace and comments after line line continuation character \ type: enhancement versions: 3rd party _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15190> _______________________________________ From report at bugs.python.org Tue Jun 26 10:23:24 2012 From: report at bugs.python.org (Ztatik Light) Date: Tue, 26 Jun 2012 08:23:24 +0000 Subject: [issue15190] Allow whitespace and comments after line continuation character \ In-Reply-To: <1340698945.14.0.356106357277.issue15190@psf.upfronthosting.co.za> Message-ID: <1340699004.28.0.146304569336.issue15190@psf.upfronthosting.co.za> Changes by Ztatik Light <ztatik.light at gmail.com>: ---------- title: Allow whitespace and comments after line line continuation character \ -> Allow whitespace and comments after line continuation character \ _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15190> _______________________________________ From report at bugs.python.org Tue Jun 26 10:25:06 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 26 Jun 2012 08:25:06 +0000 Subject: [issue5346] mailbox._singlefileMailbox.flush doesn't preserve file rights In-Reply-To: <1235317721.52.0.542523133974.issue5346@psf.upfronthosting.co.za> Message-ID: <1340699106.49.0.645858260203.issue5346@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Attached a patch. It copies the mode of the original mailbox file to the new file on flush(). ---------- components: +email keywords: +patch nosy: +barry, r.david.murray stage: test needed -> patch review versions: +Python 3.3 -Python 3.1 Added file: http://bugs.python.org/file26166/issue5346.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5346> _______________________________________ From report at bugs.python.org Tue Jun 26 10:41:34 2012 From: report at bugs.python.org (Mark Summerfield) Date: Tue, 26 Jun 2012 08:41:34 +0000 Subject: [issue15191] tkinter convenience dialogs don't use themed widgets Message-ID: <1340700094.05.0.57171486761.issue15191@psf.upfronthosting.co.za> New submission from Mark Summerfield <mark at qtrac.eu>: Some of the tkinter convenience dialogs, e.g., tkinter.filedialog.FileDialog, tkinter.scrolledtext.ScrolledText, tkinter.simpledialog.SimpleDialog, tkinter.simpledialog.Dialog, and tkinter.simpledialog._QueryDialog. Ideally they should use ttk.Frame, ttk.Button, etc. Or if that is risky for compatibility, then couldn't they be copied to tkinter.ttk and the copies themized? ---------- components: Tkinter messages: 164057 nosy: mark priority: normal severity: normal status: open title: tkinter convenience dialogs don't use themed widgets versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15191> _______________________________________ From report at bugs.python.org Tue Jun 26 10:53:53 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 26 Jun 2012 08:53:53 +0000 Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library. In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za> Message-ID: <1340700833.41.0.903294190834.issue10924@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: I just found mksalt in the whatsnew section and got curious how you've implemented the function. IMHO it has one major security flaw. The function uses random.choice(). The choice() function generates random values with a Mersenne Twister. However MTs are not suited for any cryptographic purpose and must not be used to generate passwords, session keys or salts. The random.SystemRandom class uses os.urandom() as source which is a wrapper around /dev/urandom or the Windows crypto API. The output is suitable for short living states and salts. I'm going to chance the implementation to a global instance of random.SystemRandom() and _sr.samples() as soon as Georg has cut beta 1. _sr = random.SystemRandom() s += ''.join(_sr.samples(_saltchars, method.salt_chars)) ---------- assignee: brett.cannon -> christian.heimes nosy: +christian.heimes resolution: fixed -> status: closed -> open type: enhancement -> security _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10924> _______________________________________ From report at bugs.python.org Tue Jun 26 10:57:36 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 26 Jun 2012 08:57:36 +0000 Subject: [issue15190] Allow whitespace and comments after line continuation character \ In-Reply-To: <1340698945.14.0.356106357277.issue15190@psf.upfronthosting.co.za> Message-ID: <1340701056.43.0.476652117612.issue15190@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: I think a change at this level should be discussed on the python-ideas mailing list: http://mail.python.org/mailman/listinfo/python-ideas . Ztatik, please can you post there? It would help to include some motivation for the change in your posting; if you have a working patch, that would also be useful. ---------- nosy: +mark.dickinson versions: +Python 3.4 -3rd party _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15190> _______________________________________ From report at bugs.python.org Tue Jun 26 10:59:13 2012 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 26 Jun 2012 08:59:13 +0000 Subject: [issue15190] Allow whitespace and comments after line continuation character \ In-Reply-To: <1340698945.14.0.356106357277.issue15190@psf.upfronthosting.co.za> Message-ID: <1340701153.55.0.0197936979941.issue15190@psf.upfronthosting.co.za> Eric V. Smith <eric at trueblade.com> added the comment: This would be a big change. Please bring it up on the python-ideas mailing list for discussion first. If it is approved there, we can re-open this issue. You'll need to present your use-case: Why this would be an improvement to Python? What would it allow you to do that you can't do now? ---------- nosy: +eric.smith resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15190> _______________________________________ From report at bugs.python.org Tue Jun 26 11:28:40 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Tue, 26 Jun 2012 09:28:40 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1340702920.11.0.36116024739.issue9559@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Attached a patch that doesn't rewrite+rename if messages have only been added. In this case, flush() only syncs the mailbox file to make sure all changes have been written to disk. David & Barry: what do you think about including this on bugfix releases? Could someone depend on the file being rewritten in all situations? ---------- components: +email keywords: +patch nosy: +barry, r.david.murray stage: needs patch -> patch review Added file: http://bugs.python.org/file26167/issue9559.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Tue Jun 26 11:54:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 09:54:54 +0000 Subject: [issue12927] test_ctypes: segfault with suncc In-Reply-To: <1340687385.02.0.823621120854.issue12927@psf.upfronthosting.co.za> Message-ID: <1340704271.3367.0.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Antoine, is it possible to add --with-system-ffi to the build rules > of the Solaris/suncc bot? This will prevent the segfaults. Ok, done. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12927> _______________________________________ From report at bugs.python.org Tue Jun 26 12:31:14 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 26 Jun 2012 10:31:14 +0000 Subject: [issue14979] pdb doc: Add link to source In-Reply-To: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za> Message-ID: <1340706674.17.0.590622528567.issue14979@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: Adding link to pdb source may be not be suitable. Readers may require to understand the states which pdb goes through. Docs here are better, IMO. -1 vote from me. ---------- nosy: +orsenthil _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14979> _______________________________________ From report at bugs.python.org Tue Jun 26 13:17:38 2012 From: report at bugs.python.org (Devin Jeanpierre) Date: Tue, 26 Jun 2012 11:17:38 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340709458.0.0.668340255983.issue1677@psf.upfronthosting.co.za> Devin Jeanpierre <jeanpierreda at gmail.com> added the comment: For extra clarification, this issue can crop up with even a single press of ctrl-c. It's not really related to multiple presses, except that pressing it more increases the odds of it happening. ---------- nosy: +Devin Jeanpierre _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Tue Jun 26 13:26:16 2012 From: report at bugs.python.org (Christian Heimes) Date: Tue, 26 Jun 2012 11:26:16 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340709976.45.0.234235150856.issue1677@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Could add a printf() to PC/launcher.c:ctrl_c_handler() to test if the handler is called in the error case? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Tue Jun 26 13:45:20 2012 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 26 Jun 2012 11:45:20 +0000 Subject: [issue14979] pdb doc: Explain how to extend debugger instead of sending readers to the source In-Reply-To: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za> Message-ID: <1340711120.27.0.721786750555.issue14979@psf.upfronthosting.co.za> anatoly techtonik <techtonik at gmail.com> added the comment: I agree that reading the source doesn't make it clear how to extend or use PDB, so I've changed the title. High level overview is required. I think an example would really help there. For instance a simple execution scroller - analogue of `python -m trace --trace <filename.py>`, but with PDB and play/pause buttons controlled from external script. ---------- title: pdb doc: Add link to source -> pdb doc: Explain how to extend debugger instead of sending readers to the source _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14979> _______________________________________ From report at bugs.python.org Tue Jun 26 14:05:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jun 2012 12:05:33 +0000 Subject: [issue13666] datetime documentation typos In-Reply-To: <1324936913.94.0.649454454071.issue13666@psf.upfronthosting.co.za> Message-ID: <E1SjUWR-0001wa-FY@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset ec970793f390 by Senthil Kumaran in branch '3.2': issue13666 - Fixing datetime documentation example when using tzinfo http://hg.python.org/cpython/rev/ec970793f390 New changeset 98d40bd23381 by Senthil Kumaran in branch 'default': issue13666 - merge from 3.2 http://hg.python.org/cpython/rev/98d40bd23381 New changeset 01d180987d90 by Senthil Kumaran in branch '2.7': issue13666 - Fixing datetime documentation example when using tzinfo http://hg.python.org/cpython/rev/01d180987d90 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13666> _______________________________________ From report at bugs.python.org Tue Jun 26 14:07:48 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 26 Jun 2012 12:07:48 +0000 Subject: [issue13666] datetime documentation typos In-Reply-To: <1324936913.94.0.649454454071.issue13666@psf.upfronthosting.co.za> Message-ID: <1340712468.45.0.0828857344591.issue13666@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: The docs are fixed now. ---------- nosy: +orsenthil resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13666> _______________________________________ From report at bugs.python.org Tue Jun 26 14:28:00 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Jun 2012 12:28:00 +0000 Subject: [issue5441] Convenience API for timeit.main In-Reply-To: <1236492146.81.0.454674408295.issue5441@psf.upfronthosting.co.za> Message-ID: <1340713680.74.0.340408155825.issue5441@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Close in favour of #6422 - that one at least has a patch :) ---------- resolution: -> duplicate superseder: -> timeit called from within Python should allow autoranging _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5441> _______________________________________ From report at bugs.python.org Tue Jun 26 14:37:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Jun 2012 12:37:40 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1340714260.59.0.11027008172.issue6422@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: In #5442, I proposed leaving the architecture of the module alone, and simply exposing the main module functionality as a high level helper function: def measure(stmt="pass", setup="pass", timer=default_timer, repeat=default_repeat, number=default_number, verbosity=0, precision=3) The return value would simply be a (number, results) 2-tuple with the number of iterations per test (which may have been calculated automatically), and then a list of the results. To get "timeit" style behavior, simply set "repeat=1". ---------- nosy: +ncoghlan _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6422> _______________________________________ From report at bugs.python.org Tue Jun 26 14:39:27 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Jun 2012 12:39:27 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1340714367.57.0.646631279645.issue6422@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Oops, that link reference should have been to #5441. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6422> _______________________________________ From report at bugs.python.org Tue Jun 26 14:45:07 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Jun 2012 12:45:07 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1340714707.43.0.125762395107.issue6422@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- resolution: accepted -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6422> _______________________________________ From report at bugs.python.org Tue Jun 26 14:45:22 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Jun 2012 12:45:22 +0000 Subject: [issue5441] Convenience API for timeit.main In-Reply-To: <1236492146.81.0.454674408295.issue5441@psf.upfronthosting.co.za> Message-ID: <1340714722.81.0.448888367389.issue5441@psf.upfronthosting.co.za> Changes by Nick Coghlan <ncoghlan at gmail.com>: ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5441> _______________________________________ From report at bugs.python.org Tue Jun 26 14:45:48 2012 From: report at bugs.python.org (Mark Hammond) Date: Tue, 26 Jun 2012 12:45:48 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340714748.19.0.728549787996.issue1677@psf.upfronthosting.co.za> Changes by Mark Hammond <skippy.hammond at gmail.com>: ---------- nosy: +mhammond _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Tue Jun 26 14:53:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 12:53:29 +0000 Subject: [issue15192] test_bufio failures on Win64 buildbot Message-ID: <1340715209.45.0.994879492682.issue15192@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: test_bufio fails sporadically on the AMD64 Windows7 SP1 buildbot, e.g.: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/161/steps/test/logs/stdio test_nullpat (test.test_bufio.CBufferSizeTest) ... ok test_primepat (test.test_bufio.CBufferSizeTest) ... ERROR test_nullpat (test.test_bufio.PyBufferSizeTest) ... ok test_primepat (test.test_bufio.PyBufferSizeTest) ... ok ====================================================================== ERROR: test_primepat (test.test_bufio.CBufferSizeTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_bufio.py", line 59, in test_primepat self.drive_one(b"1234567890\00\01\02\03\04\05\06") File "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_bufio.py", line 52, in drive_one self.try_one(teststring) File "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_bufio.py", line 20, in try_one support.unlink(support.TESTFN) File "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\lib\test\support.py", line 229, in unlink os.unlink(filename) PermissionError: [Error 5] Access is denied: '@test_2420_tmp' Is there some kind of anti-virus installed on the machine? ---------- components: Tests keywords: buildbot messages: 164072 nosy: jkloth, pitrou, skrah priority: normal severity: normal status: open title: test_bufio failures on Win64 buildbot type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15192> _______________________________________ From report at bugs.python.org Tue Jun 26 15:05:21 2012 From: report at bugs.python.org (Mithilesh Kumar) Date: Tue, 26 Jun 2012 13:05:21 +0000 Subject: [issue15193] Exception AttributeError: "'NoneType' object has no attribute Message-ID: <1340715921.04.0.519471476982.issue15193@psf.upfronthosting.co.za> New submission from Mithilesh Kumar <thesixthprime at gmail.com>: Behavior of the program changes with number of charaters used in variable name. Attached file shows a simple example. ---------- files: objectvar.py messages: 164073 nosy: prime priority: normal severity: normal status: open title: Exception AttributeError: "'NoneType' object has no attribute type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26168/objectvar.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15193> _______________________________________ From report at bugs.python.org Tue Jun 26 15:19:10 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 26 Jun 2012 13:19:10 +0000 Subject: [issue15193] Exception AttributeError: "'NoneType' object has no attribute In-Reply-To: <1340715921.04.0.519471476982.issue15193@psf.upfronthosting.co.za> Message-ID: <1340716750.78.0.344401203877.issue15193@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: The exception you report looks incomplete: there should be something after the 'no attribute' saying which attribute lookup failed. In any case, I don't thing this is a bug. It sounds like a result of the unpredictability of cleanup order at interpreter shutdown: you're encountering a situation where the 'Person' reference has already been deleted from the module namespace before the __del__ method for one of the Person instances gets called; so the 'Person' name lookup in the __del__ method fails. You could get around this by replacing 'Person' with 'type(self)' in __del__. ---------- nosy: +mark.dickinson resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15193> _______________________________________ From report at bugs.python.org Tue Jun 26 15:31:58 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 26 Jun 2012 13:31:58 +0000 Subject: [issue15193] Exception AttributeError: "'NoneType' object has no attribute In-Reply-To: <1340715921.04.0.519471476982.issue15193@psf.upfronthosting.co.za> Message-ID: <1340717518.75.0.0328144594654.issue15193@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: See also this warning message: http://docs.python.org/reference/datamodel.html#object.__del__ ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15193> _______________________________________ From report at bugs.python.org Tue Jun 26 15:43:24 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jun 2012 13:43:24 +0000 Subject: [issue15034] Devguide should document best practices for stdlib exceptions In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1340718204.68.0.805313396117.issue15034@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: OK, let's move this, then. I asked the question because I'd like to know what the best practice is for exceptions in the stdlib. This is an area in which we have made quite a bit of progress recently (ie: the work done on exceptions for Python3, and PEP 3151), but I think there is still a lack of documentation (and possibly consensus?) on best practices for the stdlib. ---------- components: +Devguide -Documentation resolution: later -> status: closed -> open title: tutorial should use best practices in user defined exceptions section -> Devguide should document best practices for stdlib exceptions _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Tue Jun 26 15:56:31 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 26 Jun 2012 13:56:31 +0000 Subject: [issue12713] argparse: allow abbreviation of sub commands by users In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za> Message-ID: <1340718991.71.0.873825101685.issue12713@psf.upfronthosting.co.za> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment: You could consider just a small refinement: in the first loop in _SubParsersAction.__call__ where you look for the abbreviation, you can just set parser_name = p and break. Then the logic just below that can stay as it is: all you've done is morphed the abbreviation to the full command name. ---------- nosy: +vinay.sajip _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12713> _______________________________________ From report at bugs.python.org Tue Jun 26 16:11:05 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jun 2012 14:11:05 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1340719865.96.0.424695869476.issue15178@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Ah, right, I misread the code when I looked at it. There is usually a reason why something is done the way it is...though not always. But, running some example command lines, it looks to me like the current behavior is there because without it, you won't notice if the tests in the middle of your list of files failed. So, I think your second patch is more what we need. However, rather than calling sys.exit, I think it would be better to just print the message and do a return 1. It is also possible we shouldn't change it at all. unittest (which has had some thought put in to the commnd line interface) just ends in a traceback in a similar situation (except that in unittest's case it is an ImportError...) ---------- nosy: +michael.foord _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15178> _______________________________________ From report at bugs.python.org Tue Jun 26 16:43:13 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 26 Jun 2012 14:43:13 +0000 Subject: [issue15184] Test failure in test_sysconfig_module In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za> Message-ID: <1340721793.55.0.316111891114.issue15184@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Moving stuff common to both sysconfig modules into a shared module sounds good, but the existence and API of distutils.sysconfig needs to be preserved. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15184> _______________________________________ From report at bugs.python.org Tue Jun 26 17:06:58 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 26 Jun 2012 15:06:58 +0000 Subject: [issue15194] libffi-3.0.11 update Message-ID: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za> New submission from Matthias Klose <doko at debian.org>: here is an update for libffi 3.0.11. For now, only tested on x86-linux and arm-linux-gnueabi. Proposing the check it in, and then test again, if the libffi_osx and libffi_msvc copies can be removed, if 3.0.11 works on these platforms (however I can't test on these myself). ---------- components: ctypes files: libffi-3.0.11.diff.xz keywords: patch messages: 164080 nosy: doko priority: normal severity: normal status: open title: libffi-3.0.11 update versions: Python 3.3 Added file: http://bugs.python.org/file26169/libffi-3.0.11.diff.xz _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15194> _______________________________________ From report at bugs.python.org Tue Jun 26 17:13:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 15:13:41 +0000 Subject: [issue15194] libffi-3.0.11 update In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za> Message-ID: <1340723621.4.0.272283859352.issue15194@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +meador.inge, ned.deily, skrah _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15194> _______________________________________ From report at bugs.python.org Tue Jun 26 17:26:08 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 26 Jun 2012 15:26:08 +0000 Subject: [issue15195] test_distutils fails when ARCHFLAGS is set on a Mac Message-ID: <1340724368.12.0.314472087482.issue15195@psf.upfronthosting.co.za> New submission from Marc Abramowitz <msabramo at gmail.com>: $ export ARCHFLAGS="-arch i386 -arch x86_64" $ ./python.exe -m test -v test_distutils [last: 0] marca at scml-marca:~/dev/hg-repos/cpython$ ./python.exe Python 3.3.0a4+ (default:6af0535b5e3a, Jun 25 2012, 16:59:49) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sysconfig [59901 refs] >>> sysconfig.get_config_var('LDSHARED') 'gcc -bundle -undefined dynamic_lookup' [59906 refs] >>> import distutils.sysconfig [61596 refs] >>> distutils.sysconfig.get_config_var('LDSHARED') 'gcc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64' [77979 refs] ---------- components: Tests messages: 164081 nosy: Marc.Abramowitz priority: normal severity: normal status: open title: test_distutils fails when ARCHFLAGS is set on a Mac versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15195> _______________________________________ From report at bugs.python.org Tue Jun 26 17:33:49 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 26 Jun 2012 15:33:49 +0000 Subject: [issue15195] test_distutils fails when ARCHFLAGS is set on a Mac In-Reply-To: <1340724368.12.0.314472087482.issue15195@psf.upfronthosting.co.za> Message-ID: <1340724829.7.0.0203541675441.issue15195@psf.upfronthosting.co.za> Changes by Marc Abramowitz <msabramo at gmail.com>: ---------- type: -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15195> _______________________________________ From report at bugs.python.org Tue Jun 26 17:37:22 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 26 Jun 2012 15:37:22 +0000 Subject: [issue15194] libffi-3.0.11 update In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za> Message-ID: <1340725042.7.0.0449230603581.issue15194@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: ---------- nosy: +ronaldoussoren _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15194> _______________________________________ From report at bugs.python.org Tue Jun 26 18:01:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jun 2012 16:01:09 +0000 Subject: [issue15194] libffi-3.0.11 update In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za> Message-ID: <E1SjYCH-0007YW-W2@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 25421e1c48bb by doko in branch 'default': - Issue #15194: Update libffi to the 3.0.11 release. http://hg.python.org/cpython/rev/25421e1c48bb ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15194> _______________________________________ From report at bugs.python.org Tue Jun 26 18:25:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 26 Jun 2012 16:25:45 +0000 Subject: [issue15192] test_bufio failures on Win64 buildbot In-Reply-To: <1340715209.45.0.994879492682.issue15192@psf.upfronthosting.co.za> Message-ID: <1340727945.46.0.985829325996.issue15192@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Looks similar to the sporadic test_reprlib failure. Roumen has explained that here: http://bugs.python.org/issue14599#msg162727 I didn't test myself though, just a guess. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15192> _______________________________________ From report at bugs.python.org Tue Jun 26 18:32:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 16:32:00 +0000 Subject: [issue15192] test_bufio failures on Win64 buildbot In-Reply-To: <1340727945.46.0.985829325996.issue15192@psf.upfronthosting.co.za> Message-ID: <1340728090.3418.0.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Looks similar to the sporadic test_reprlib failure. Roumen has explained > that here: I don't think there's anything similar. The path is much smaller in test_bufio. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15192> _______________________________________ From report at bugs.python.org Tue Jun 26 18:37:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 16:37:44 +0000 Subject: [issue15192] test_bufio failures on Win64 buildbot In-Reply-To: <1340715209.45.0.994879492682.issue15192@psf.upfronthosting.co.za> Message-ID: <1340728664.66.0.299020576211.issue15192@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +jeremy.kloth _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15192> _______________________________________ From report at bugs.python.org Tue Jun 26 18:39:07 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 26 Jun 2012 16:39:07 +0000 Subject: [issue15194] libffi-3.0.11 update In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za> Message-ID: <1340728747.54.0.327543699407.issue15194@psf.upfronthosting.co.za> Ronald Oussoren <ronaldoussoren at mac.com> added the comment: Removing libffi_osx would be fairly hard due to the creation of fat binaries, the libffi_osx tree supports building all files using 'cc -arch i386 -arch ppc -arch x86_64', the regular libffi sources require a more complex dance (basically build all architectures separately then merge them together). OTOH libffi_osx seems to have problems when using with recent versions of clang. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15194> _______________________________________ From report at bugs.python.org Tue Jun 26 19:20:23 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 26 Jun 2012 17:20:23 +0000 Subject: [issue15192] test_bufio failures on Win64 buildbot In-Reply-To: <1340728665.13.0.136775602906.issue15192@psf.upfronthosting.co.za> Message-ID: <CAGvrs3KEighgDnsuhJXqkQgb4Xhs4zsF6QkVOPmqqUbJSTX6Nw@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: I've changed the malware scanner to disable real-time protection and have disabled scanning of the buildbot directories. Note that I could reproduce intermittent failures when using '-j' of regrtest, but with these changes they no longer appear. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15192> _______________________________________ From report at bugs.python.org Tue Jun 26 19:27:35 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jun 2012 17:27:35 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1340731655.58.0.191933594928.issue9559@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Could someone be depending on it? Sure. Is that likely enough to block this as a bug fix? Personally I think not. Appending to the mailbox when adding messages is, I think, the expected behavior, and always rewriting it is the surprising behavior. The patch looks good to me, though personally I'd eliminate the extra blank lines. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Tue Jun 26 20:10:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jun 2012 18:10:33 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <E1SjaDc-0002Pg-Jf@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 76f2b99f3568 by David Malcolm in branch '3.2': Issue #14443: ensure that brp-python-bytecompile is invoked with the correct http://hg.python.org/cpython/rev/76f2b99f3568 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14443> _______________________________________ From report at bugs.python.org Tue Jun 26 20:26:22 2012 From: report at bugs.python.org (moijes12) Date: Tue, 26 Jun 2012 18:26:22 +0000 Subject: [issue11681] -b option undocumented In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za> Message-ID: <1340735182.61.0.174129672244.issue11681@psf.upfronthosting.co.za> moijes12 <moijes12 at gmail.com> added the comment: Hi Marc I tried reproducing this for bytearray using Python 2.7.2 but I can't see a warning. devel at moses:~$ python --version Python 2.7.2+ devel at moses:~$ cat test_py.py k = range(10) kb = bytearray(k) print kb kb = bytearray("hi") print kb devel at moses:~$ python -b test_py.py hi devel at moses:~$ python -bb test_py.py hi Please correct me if I'm wrong anywhere here. I'd like to work on this. ---------- nosy: +moijes12 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11681> _______________________________________ From report at bugs.python.org Tue Jun 26 21:04:02 2012 From: report at bugs.python.org (Ben Longbons) Date: Tue, 26 Jun 2012 19:04:02 +0000 Subject: [issue15196] os.path.realpath gets confused when symlinks include '..' Message-ID: <1340737442.15.0.365871986623.issue15196@psf.upfronthosting.co.za> New submission from Ben Longbons <b.r.longbons at gmail.com>: I encountered this bug with the following filesystem layout project/build/bin/main-gdb.py -> ../src/main-gdb.py project/build/src -> ../src/ project/src/main-gdb.py -> ../py/main-gdb.py project/py/main-gdb.py where root/py/main-gdb.py contains import os print(os.path.realpath(__file__)) Actual Result: project/build/py/main-gdb.py instead of project/py/main-gdb.py The cause of this bug is the fact that os.path._resolve_link calls os.path.normpath, which is not symlink-safe. Specically, this is bad: os.path.normpath('project/build/src/../py/main-gdb.py') The correct thing to do is never call normpath; instead leave .. components and pop off the last element after ensuring that the preceding directory is not a symlink. This bug seems pretty severe to me, because it prevents imports from working. Exact python --version and Debian package versions: Python 2.6.7 (2.6.7-4) Python 2.7.3rc2 (2.7.3~rc2-2.1) Python 3.2.3 (3.2.3-1) ---------- components: Library (Lib) messages: 164090 nosy: o11c priority: normal severity: normal status: open title: os.path.realpath gets confused when symlinks include '..' versions: Python 2.6, Python 2.7, Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15196> _______________________________________ From report at bugs.python.org Tue Jun 26 21:12:13 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 26 Jun 2012 19:12:13 +0000 Subject: [issue15194] libffi-3.0.11 update In-Reply-To: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za> Message-ID: <1340737933.97.0.976831667823.issue15194@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15194> _______________________________________ From report at bugs.python.org Tue Jun 26 21:21:37 2012 From: report at bugs.python.org (Dave Malcolm) Date: Tue, 26 Jun 2012 19:21:37 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1340738497.98.0.746002415701.issue14443@psf.upfronthosting.co.za> Dave Malcolm <dmalcolm at redhat.com> added the comment: Fixes committed to 3.2 and default: RHEL 6.3 is now green for both branches. Closing this bug out. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14443> _______________________________________ From report at bugs.python.org Tue Jun 26 21:45:25 2012 From: report at bugs.python.org (florian-rathgeber) Date: Tue, 26 Jun 2012 19:45:25 +0000 Subject: [issue672115] Assignment to __bases__ of direct object subclasses Message-ID: <1340739925.99.0.638956987346.issue672115@psf.upfronthosting.co.za> Changes by florian-rathgeber <florian.rathgeber at gmail.com>: ---------- nosy: +florian-rathgeber _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue672115> _______________________________________ From report at bugs.python.org Tue Jun 26 21:53:43 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jun 2012 19:53:43 +0000 Subject: [issue15196] os.path.realpath gets confused when symlinks include '..' In-Reply-To: <1340737442.15.0.365871986623.issue15196@psf.upfronthosting.co.za> Message-ID: <1340740423.82.0.132766385171.issue15196@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Is this a duplicate of issue 6975, or something different? 2.6 only gets security patches. (We use the version field to show what version we need to apply the fix to.) ---------- nosy: +r.david.murray versions: +Python 3.3 -Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15196> _______________________________________ From report at bugs.python.org Tue Jun 26 22:08:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 20:08:57 +0000 Subject: [issue15196] os.path.realpath gets confused when symlinks include '..' In-Reply-To: <1340737442.15.0.365871986623.issue15196@psf.upfronthosting.co.za> Message-ID: <1340741337.61.0.289069594029.issue15196@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Indeed, this is pretty bad behaviour, especially for realpath(). Both abspath() and normpath() should never be called before any symlinks are resolved. Of course, fixing it as a bug means it could break existing code which relies on ".." fragments being folded. ---------- nosy: +hynek, pitrou priority: normal -> high stage: -> needs patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15196> _______________________________________ From report at bugs.python.org Tue Jun 26 22:19:53 2012 From: report at bugs.python.org (Jeff Knupp) Date: Tue, 26 Jun 2012 20:19:53 +0000 Subject: [issue15166] Implement imp.get_tag() using sys.implementation In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za> Message-ID: <1340741993.87.0.87232390452.issue15166@psf.upfronthosting.co.za> Jeff Knupp <jknupp at gmail.com> added the comment: Adding patch. If I misunderstood the issue, let me know. ---------- keywords: +patch nosy: +Jeff.Knupp Added file: http://bugs.python.org/file26170/imp.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15166> _______________________________________ From report at bugs.python.org Tue Jun 26 22:21:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 20:21:18 +0000 Subject: [issue15192] test_bufio failures on Win64 buildbot In-Reply-To: <CAGvrs3KEighgDnsuhJXqkQgb4Xhs4zsF6QkVOPmqqUbJSTX6Nw@mail.gmail.com> Message-ID: <1340742030.3415.0.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > I've changed the malware scanner to disable real-time protection and > have disabled scanning of the buildbot directories. Thank you. I hope that, thanks to this change, we later can make the Win64 buildbot part of the bunch of stable buildbots. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15192> _______________________________________ From report at bugs.python.org Tue Jun 26 22:47:23 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:47:23 +0000 Subject: [issue14940] Usage documentation for pysetup In-Reply-To: <1338246677.91.0.429583785939.issue14940@psf.upfronthosting.co.za> Message-ID: <1340743642.92.0.222628220065.issue14940@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Packaging is out, no more blocking. ---------- priority: deferred blocker -> normal versions: +Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14940> _______________________________________ From report at bugs.python.org Tue Jun 26 22:50:17 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:50:17 +0000 Subject: [issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier In-Reply-To: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za> Message-ID: <1340743817.38.0.0439376030157.issue15037@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: I agree it should be documented, probably wherever unget_wch is documented. If there is a way to detect the ncurses version, the test should be skipped on < 5.8 as well. ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15037> _______________________________________ From report at bugs.python.org Tue Jun 26 22:50:38 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:50:38 +0000 Subject: [issue15151] Documentation for Signature, Parameter and signature in inspect module In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za> Message-ID: <1340743838.13.0.0441407555757.issue15151@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Moving back to blocker for beta2. ---------- nosy: +georg.brandl priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15151> _______________________________________ From report at bugs.python.org Tue Jun 26 22:50:53 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:50:53 +0000 Subject: [issue14340] Update embedded copy of expat - fix security & crash issues In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za> Message-ID: <1340743853.15.0.64557342579.issue14340@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Moving back to blocker for beta2. ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14340> _______________________________________ From report at bugs.python.org Tue Jun 26 22:51:12 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:51:12 +0000 Subject: [issue15056] Have imp.cache_from_source() raise NotImplementedError when cache tag not available In-Reply-To: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za> Message-ID: <1340743872.51.0.956864362659.issue15056@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Moving back to blocker for beta2. ---------- nosy: +georg.brandl priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15056> _______________________________________ From report at bugs.python.org Tue Jun 26 22:51:26 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:51:26 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1340743886.7.0.793896783015.issue14578@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Moving back to blocker for beta2. ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14578> _______________________________________ From report at bugs.python.org Tue Jun 26 22:51:42 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:51:42 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1340743901.99.0.909068715195.issue13959@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Moving back to blocker for beta2. ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13959> _______________________________________ From report at bugs.python.org Tue Jun 26 22:52:03 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:52:03 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340743923.31.0.476958463512.issue14814@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Moving back to blocker for beta2. ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Tue Jun 26 22:52:14 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:52:14 +0000 Subject: [issue15184] Test failure in test_sysconfig_module In-Reply-To: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za> Message-ID: <1340743934.37.0.748374076431.issue15184@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Moving to blocker for beta2. ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15184> _______________________________________ From report at bugs.python.org Tue Jun 26 22:52:40 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Jun 2012 20:52:40 +0000 Subject: [issue15166] Implement imp.get_tag() using sys.implementation In-Reply-To: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za> Message-ID: <1340743960.55.0.707983481205.issue15166@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Moving to blocker for beta2. ---------- nosy: +georg.brandl priority: deferred blocker -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15166> _______________________________________ From report at bugs.python.org Tue Jun 26 22:53:11 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 26 Jun 2012 20:53:11 +0000 Subject: [issue15011] Change Scripts to bin on Windows In-Reply-To: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za> Message-ID: <1340743991.0.0.301582507752.issue15011@psf.upfronthosting.co.za> Changes by Brian Curtin <brian at python.org>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15011> _______________________________________ From report at bugs.python.org Tue Jun 26 23:02:21 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Tue, 26 Jun 2012 21:02:21 +0000 Subject: [issue12559] gzip.open() needs an optional encoding argument In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za> Message-ID: <1340744541.58.0.93964324663.issue12559@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: I already fixed this without knowing about this issue; see 55202ca694d7. storchaka: > Why not use io.TextWrapper? I think it is the right answer for this issue. The proposed patch (and the code I committed) *do* use TextIOWrapper. Unless you mean that callers should create the TextIOWrapper themselves. This is certainly possible, but quite inconvenient for something that is conceptually simple, and not difficult to implement. amaury.forgeotdarc: > There remains a difference between open() and gzip.open(): > open(filename, 'r', encoding=None) is a text file (with a default encoding), gzip.open() with the same arguments returns a binary file. The committed code unfortunately still has gzip.open(filename, "r") returning a binary file. This is something that cannot be fixed without breaking backward compatibility. However, it does provide a way to open a text file with the system's default encoding (encoding=None, or no encoding argument specified). To do this, you can use the "rt"/"wt"/"at" modes, just like with builtins.open(). Of course, this also works if you do specify an encoding explicitly. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12559> _______________________________________ From report at bugs.python.org Tue Jun 26 23:06:29 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Jun 2012 21:06:29 +0000 Subject: [issue15079] pickle: Possibly misplaced test In-Reply-To: <1339778270.97.0.949730169084.issue15079@psf.upfronthosting.co.za> Message-ID: <E1Sjcxv-00020Y-6k@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 5881a58c5425 by Antoine Pitrou in branch '3.2': Issue #15079: make a test applicable to both C and Python versions of the pickle module. http://hg.python.org/cpython/rev/5881a58c5425 New changeset b66e82c9f852 by Antoine Pitrou in branch 'default': Issue #15079: make a test applicable to both C and Python versions of the pickle module. http://hg.python.org/cpython/rev/b66e82c9f852 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15079> _______________________________________ From report at bugs.python.org Tue Jun 26 23:08:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 21:08:04 +0000 Subject: [issue15079] pickle: Possibly misplaced test In-Reply-To: <1339778270.97.0.949730169084.issue15079@psf.upfronthosting.co.za> Message-ID: <1340744884.83.0.0069618747695.issue15079@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Committed. Congratulations on your first patch! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15079> _______________________________________ From report at bugs.python.org Tue Jun 26 23:23:12 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 26 Jun 2012 21:23:12 +0000 Subject: [issue12605] Enhancements to gdb 7 debugging hooks In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za> Message-ID: <1340745792.3.0.802888354613.issue12605@psf.upfronthosting.co.za> Gregory P. Smith <greg at krypto.org> added the comment: Better debuggability FTW! This is an update to Tools/gdb/ as such I'd like to see this make it into 3.3. It doesn't touch the runtime or stdlib so I personally wouldn't consider this "adding a feature" and thus preventing its inclusion with 3.3 despite the beta process having started. It'd the release manager's call. I'm bumping to release blocker for a decision from Georg. :) ---------- nosy: +benjamin.peterson, gregory.p.smith priority: normal -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12605> _______________________________________ From report at bugs.python.org Tue Jun 26 23:23:30 2012 From: report at bugs.python.org (Ben Longbons) Date: Tue, 26 Jun 2012 21:23:30 +0000 Subject: [issue15196] os.path.realpath gets confused when symlinks include '..' In-Reply-To: <1340737442.15.0.365871986623.issue15196@psf.upfronthosting.co.za> Message-ID: <1340745810.06.0.22835583025.issue15196@psf.upfronthosting.co.za> Ben Longbons <b.r.longbons at gmail.com> added the comment: Yeah, this is a duplicate of issue 6975. Sorry also about the version thing. Although I can set this as closed: duplicate, I don't seem to be able to set what bug this is a duplicate of. ---------- resolution: -> duplicate status: open -> closed type: -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15196> _______________________________________ From report at bugs.python.org Tue Jun 26 23:23:37 2012 From: report at bugs.python.org (Ben Longbons) Date: Tue, 26 Jun 2012 21:23:37 +0000 Subject: [issue6975] symlinks incorrectly resolved on Linux In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1340745817.06.0.435053919793.issue6975@psf.upfronthosting.co.za> Ben Longbons <b.r.longbons at gmail.com> added the comment: After filing a duplicate, issue 15196, I analyzed this: What happens: test/one/that_dir test/one/../two/this_dir/this_dir/this_dir/this_dir test/two/this_dir/this_dir/this_dir/this_dir test/two/this_dir/this_dir/this_dir/../two test/two/this_dir/this_dir/two What should happen: test/one/that_dir test/two/this_dir/this_dir/this_dir/this_dir test/two/../two/this_dir/this_dir/this_dir test/two/this_dir/this_dir/this_dir test/two/../two/this_dir/this_dir test/two/this_dir/this_dir test/two/../two/this_dir test/two/this_dir test/two/../two test/two ---------- nosy: +o11c versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6975> _______________________________________ From report at bugs.python.org Tue Jun 26 23:36:13 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jun 2012 21:36:13 +0000 Subject: [issue15196] os.path.realpath gets confused when symlinks include '..' In-Reply-To: <1340737442.15.0.365871986623.issue15196@psf.upfronthosting.co.za> Message-ID: <1340746573.22.0.22714531348.issue15196@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- superseder: -> symlinks incorrectly resolved on Linux _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15196> _______________________________________ From report at bugs.python.org Tue Jun 26 23:36:58 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 Jun 2012 21:36:58 +0000 Subject: [issue6975] symlinks incorrectly resolved on Linux In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za> Message-ID: <1340746618.27.0.800595533086.issue6975@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- nosy: +hynek, pitrou, r.david.murray versions: -Python 3.1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6975> _______________________________________ From report at bugs.python.org Tue Jun 26 23:39:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Jun 2012 21:39:19 +0000 Subject: [issue15197] test_gettext failure on Win64 buildbot Message-ID: <1340746759.25.0.721381261355.issue15197@psf.upfronthosting.co.za> New submission from Antoine Pitrou <pitrou at free.fr>: Another weird failure that isn't common on other buildbots: test test_gettext failed -- Traceback (most recent call last): File "C:\Users\Buildbot\buildbot.python.org\3.2.kloth-win64\build\lib\test\test_gettext.py", line 80, in tearDown shutil.rmtree(os.path.split(LOCALEDIR)[0]) File "C:\Users\Buildbot\buildbot.python.org\3.2.kloth-win64\build\lib\shutil.py", line 289, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "C:\Users\Buildbot\buildbot.python.org\3.2.kloth-win64\build\lib\shutil.py", line 287, in rmtree os.rmdir(path) WindowsError: [Error 145] The directory is not empty: 'xx' ---------- components: Tests keywords: buildbot messages: 164112 nosy: jeremy.kloth, pitrou, skrah priority: normal severity: normal status: open title: test_gettext failure on Win64 buildbot type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15197> _______________________________________ From report at bugs.python.org Tue Jun 26 23:39:39 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 26 Jun 2012 21:39:39 +0000 Subject: [issue12605] Enhancements to gdb 7 debugging hooks In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za> Message-ID: <1340746779.91.0.739402235419.issue12605@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I'm +1 on adding this in general, +0 on adding this to 3.3, and -0 on adding it to 2.7 right away. I agree that the usual reasoning against new features doesn't apply here, since it's not a new Python (language or library) feature. However, one concern is that it is a large change, and I predict that it will introduce some breakage regardless of what amount of code review goes into it. If the breakage can be detected during the betas, fine, but we need to consider that it may cause breakage of the entire python-gdb feature for some people after the release (which probably wouldn't be that terrible). Hence the +0 for 3.3. For 2.7, it should only be added if it has survived in a prerelease branch for some time, hence the -0. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12605> _______________________________________ From report at bugs.python.org Wed Jun 27 00:27:18 2012 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 26 Jun 2012 22:27:18 +0000 Subject: [issue15197] test_gettext failure on Win64 buildbot In-Reply-To: <1340746759.25.0.721381261355.issue15197@psf.upfronthosting.co.za> Message-ID: <CAGvrs3KSncz+SorHExcE1DJUD5h5MCT1kk3B8u=r21sWudbkuw@mail.gmail.com> Jeremy Kloth <jeremy.kloth at gmail.com> added the comment: I've now also turned off indexing for the Buildbot account (and folders). Hopefully this is the last directory walking process interfering with the tests. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15197> _______________________________________ From report at bugs.python.org Wed Jun 27 00:50:21 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 26 Jun 2012 22:50:21 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1340751021.95.0.0140083600421.issue15031@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Another package that inspects pyc files and which also ran into trouble because of the 8 to 12 byte change is distribute. See: https://bitbucket.org/tarek/distribute/issue/283/bdist_egg-issues-with-python-330ax Some kind of abstraction for loading pyc files would be nice. ---------- nosy: +Marc.Abramowitz _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Wed Jun 27 01:21:02 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 26 Jun 2012 23:21:02 +0000 Subject: [issue12971] os.isdir() should contain skiplinks=False in arguments In-Reply-To: <1315920238.53.0.290032380593.issue12971@psf.upfronthosting.co.za> Message-ID: <1340752862.51.0.853637469846.issue12971@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' <g.rodola at gmail.com>: ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12971> _______________________________________ From report at bugs.python.org Wed Jun 27 02:03:54 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 27 Jun 2012 00:03:54 +0000 Subject: [issue12971] os.isdir() should contain skiplinks=False in arguments In-Reply-To: <1315920238.53.0.290032380593.issue12971@psf.upfronthosting.co.za> Message-ID: <1340755434.68.0.382285544317.issue12971@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: If this happens, in keeping with the new os module aesthetic, I suggest the prototype should be os.isdir(path, *, follow_symlinks=True) ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12971> _______________________________________ From report at bugs.python.org Wed Jun 27 03:00:01 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 27 Jun 2012 01:00:01 +0000 Subject: [issue13685] argparse update help msg for % signs In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za> Message-ID: <1340758801.83.0.878400807491.issue13685@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Senthil, would you mind porting the fix to 2.7? Thanks. ---------- nosy: +eric.araujo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13685> _______________________________________ From report at bugs.python.org Wed Jun 27 04:49:25 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 Jun 2012 02:49:25 +0000 Subject: [issue15195] test_distutils fails when ARCHFLAGS is set on a Mac In-Reply-To: <1340724368.12.0.314472087482.issue15195@psf.upfronthosting.co.za> Message-ID: <1340765365.92.0.215325964705.issue15195@psf.upfronthosting.co.za> Changes by Ned Deily <nad at acm.org>: ---------- assignee: -> ned.deily nosy: +ned.deily _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15195> _______________________________________ From report at bugs.python.org Wed Jun 27 05:25:49 2012 From: report at bugs.python.org (Ian Bell) Date: Wed, 27 Jun 2012 03:25:49 +0000 Subject: [issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error Message-ID: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za> New submission from Ian Bell <ian.h.bell at gmail.com>: When a non-picklable object is sent through a multiprocessing.Pipe, no exception is raised, instead when trying to read the other end of the pipe, a TypeError is raised: TypeError: Required argument 'handle' (pos 1) not found ---------- components: Windows messages: 164118 nosy: Ian.Bell priority: normal severity: normal status: open title: multiprocessing Pipe send of non-picklable objects doesn't raise error versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15198> _______________________________________ From report at bugs.python.org Wed Jun 27 05:26:17 2012 From: report at bugs.python.org (Ian Bell) Date: Wed, 27 Jun 2012 03:26:17 +0000 Subject: [issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error In-Reply-To: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za> Message-ID: <1340767577.94.0.864633993587.issue15198@psf.upfronthosting.co.za> Changes by Ian Bell <ian.h.bell at gmail.com>: ---------- type: -> crash _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15198> _______________________________________ From report at bugs.python.org Wed Jun 27 07:07:04 2012 From: report at bugs.python.org (Justin Venus) Date: Wed, 27 Jun 2012 05:07:04 +0000 Subject: [issue3786] _curses, _curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio 12 In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za> Message-ID: <1340773624.19.0.463763904019.issue3786@psf.upfronthosting.co.za> Justin Venus <justin.venus at gmail.com> added the comment: The attached patch allows _curses and _curses_panel to build with the sunpro compiler on Solaris11. The only changes were compiler/linker options in the main setup.py. The interactive curses_test works on my system. I can easily make patches for python2.7 and python3.2 as well. This patch may also address the issue in bug 13552 as well. ---------- keywords: +patch nosy: +Justin.Venus Added file: http://bugs.python.org/file26171/bug3786.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3786> _______________________________________ From report at bugs.python.org Wed Jun 27 07:26:27 2012 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 27 Jun 2012 05:26:27 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1340774787.08.0.756938284037.issue15178@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda <bkabrda at redhat.com> added the comment: Ok, attaching 4th version :) I think it is nice when the testing library can react in situations like this one and not show a traceback. IMHO it is always nicer to display a pretty user-readable message than ending with a traceback. ---------- Added file: http://bugs.python.org/file26172/doctest-dont-end-with-exception-on-unreadable-files-v4.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15178> _______________________________________ From report at bugs.python.org Wed Jun 27 07:36:58 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 05:36:58 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340775418.26.0.951147292631.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Attaching a patch... Using Ronan's test_PyPyc.diff, before my patch: {{{ ~/dev/hg-repos/cpython$ ./python.exe -m unittest Lib/importlib/test/source/test_abc_loader.py ...........................................E.................. ====================================================================== ERROR: test_pyc_compatibility (Lib.importlib.test.source.test_abc_loader.RegeneratedBytecodeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "./Lib/importlib/test/source/util.py", line 23, in wrapper to_return = fxn(*args, **kwargs) File "./Lib/importlib/test/source/test_abc_loader.py", line 473, in test_pyc_compatibility mock.load_module(name) File "<frozen importlib._bootstrap>", line 760, in load_module File "<frozen importlib._bootstrap>", line 408, in module_for_loader_wrapper File "<frozen importlib._bootstrap>", line 636, in _load_module File "./Lib/importlib/test/source/test_abc_loader.py", line 201, in get_code code_object = super().get_code(name) File "/Users/marca/dev/hg-repos/cpython/Lib/importlib/abc.py", line 305, in get_code return marshal.loads(bytecode) ValueError: bad marshal data (unknown type code) ---------------------------------------------------------------------- Ran 62 tests in 0.076s FAILED (errors=1) [114118 refs] }}} After my patch: {{{ ~/dev/hg-repos/cpython$ patch -p1 < ~/Desktop/cpython-issue-15030.patch patching file Lib/importlib/abc.py ~/dev/hg-repos/cpython$ ./python.exe -m unittest Lib/importlib/test/source/test_abc_loader.py .............................................................. ---------------------------------------------------------------------- Ran 62 tests in 0.079s OK [114118 refs] }}} ---------- nosy: +Marc.Abramowitz Added file: http://bugs.python.org/file26173/cpython-issue-15030.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 08:16:37 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 27 Jun 2012 06:16:37 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340777797.93.0.443578075246.issue15030@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Patch looks innocent enough; would be nice to fix this for 3.3. ---------- nosy: +georg.brandl priority: normal -> release blocker _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 08:18:30 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 06:18:30 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340777910.9.0.413696840782.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Similar issue in distribute: https://bitbucket.org/tarek/distribute/issue/283/bdist_egg-issues-with-python-330ax ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 08:20:41 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 27 Jun 2012 06:20:41 +0000 Subject: [issue12605] Enhancements to gdb 7 debugging hooks In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za> Message-ID: <1340778041.83.0.578336152294.issue12605@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: Agreed with Martin, can't say I'm +1 on 3.3 either. But I've just reviewed the patch, and it looks correct to me, so go ahead and I'll take the blame. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12605> _______________________________________ From report at bugs.python.org Wed Jun 27 09:00:30 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 27 Jun 2012 07:00:30 +0000 Subject: [issue13876] Sporadic failure in test_socket In-Reply-To: <1327588563.2.0.447366914719.issue13876@psf.upfronthosting.co.za> Message-ID: <1340780430.33.0.138506780382.issue13876@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: Merging nosy list from duplicate issue 15155. ---------- nosy: +giampaolo.rodola, neologix, pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13876> _______________________________________ From report at bugs.python.org Wed Jun 27 09:10:19 2012 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 27 Jun 2012 07:10:19 +0000 Subject: [issue15199] Default mimetype for javascript should be application/javascript Message-ID: <1340781019.87.0.733806504492.issue15199@psf.upfronthosting.co.za> New submission from Bohuslav "Slavek" Kabrda <bkabrda at redhat.com>: Hi, when using Python's Lib/mimetypes.py and none of the default files is present, there are some defaults used. For javascript, the default is application/x-javascript. However, according to IANA specification [1], this is not a registered type, and application/javascript should be used (see section 7). I'm attaching a simple patch that fixes this. [1] http://www.rfc-editor.org/rfc/rfc4329.txt ---------- components: Library (Lib) files: python-correct-default-js-mimetype.patch keywords: patch messages: 164126 nosy: bkabrda priority: normal severity: normal status: open title: Default mimetype for javascript should be application/javascript type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26174/python-correct-default-js-mimetype.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15199> _______________________________________ From report at bugs.python.org Wed Jun 27 10:11:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 08:11:22 +0000 Subject: [issue15200] Faster os.walk Message-ID: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: Using os.fwalk (if it is available) we can make os.walk more fast. Microbenchmark: ./python -m timeit -s "from os import walk" "for x in walk('Lib'): pass" Results: Vanilla: 112 msec Patched: 90.5 msec ---------- components: Library (Lib) files: faster_walk.patch keywords: patch messages: 164127 nosy: storchaka priority: normal severity: normal status: open title: Faster os.walk type: performance versions: Python 3.4 Added file: http://bugs.python.org/file26175/faster_walk.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15200> _______________________________________ From report at bugs.python.org Wed Jun 27 10:29:56 2012 From: report at bugs.python.org (=?utf-8?q?Beno=C3=AEt_Bryon?=) Date: Wed, 27 Jun 2012 08:29:56 +0000 Subject: [issue14899] Naming conventions and guidelines for packages and namespace packages In-Reply-To: <1337863326.85.0.0790625001968.issue14899@psf.upfronthosting.co.za> Message-ID: <1340785796.19.0.66569040019.issue14899@psf.upfronthosting.co.za> Beno?t Bryon <benoit at marmelune.net> added the comment: The proposal has been added to PEPs repository as PEP 423 : http://hg.python.org/peps/rev/52767ab7e140 Review is about to be started at python-dev at python.org. To adapt the scope of this issue, in cpython documentation, I am to: * remove the Doc/packaging/packagenames.rst document * replace it by references to PEP 423 Obviously, this work requires that PEP 423 is accepted. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14899> _______________________________________ From report at bugs.python.org Wed Jun 27 10:59:22 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 27 Jun 2012 08:59:22 +0000 Subject: [issue15201] C argument errors and Python arguments error are different Message-ID: <1340787562.9.0.381014932259.issue15201@psf.upfronthosting.co.za> New submission from Ramchandra Apte <maniandram01 at gmail.com>: C argument errors and Python arguments error are different. For example: all(4,4,4) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: all() takes exactly one argument (3 given) def func(a):pass a(4,4) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: func() takes exactly 1 positional argument (2 given) I do not know which error message is better. I think the second example's (func) error message is better. Though feel free to vote by commenting on this bug. Another example with not enough arguments given: hasattr(4) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: hasattr expected 2 arguments, got 1 func() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: func() takes exactly 1 argument (0 given) I don't know which of this error messages are better. You can vote on this by commenting. ---------- components: Interpreter Core messages: 164129 nosy: ramchandra.apte priority: normal severity: normal status: open title: C argument errors and Python arguments error are different type: behavior versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15201> _______________________________________ From report at bugs.python.org Wed Jun 27 10:59:40 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 08:59:40 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification. Message-ID: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: Now three different flag are used to denote the same behavior. followlinks is used in os.(f)walk, symlinks is used in shutil functions (with opposite meaning), and follow_symlinks is just added to many os functions. Unfortunately, symlinks, like followlinks, is used prior to 3.3. But follow_symlinks appeared only in 3.3 (besides, it's too long a name for this frequently used parameter) and it can be unified with one of the earlier spelling. Replacing follow_symlinks to followlinks is simpler than to symlinks. ---------- components: Library (Lib) files: followlinks.patch keywords: patch messages: 164130 nosy: storchaka priority: normal severity: normal status: open title: followlinks/follow_symlinks/symlinks flags unification. Added file: http://bugs.python.org/file26176/followlinks.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 11:00:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 09:00:10 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340787610.45.0.0396992352976.issue15202@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- title: followlinks/follow_symlinks/symlinks flags unification. -> followlinks/follow_symlinks/symlinks flags unification _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 11:11:34 2012 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 27 Jun 2012 09:11:34 +0000 Subject: [issue12971] os.isdir() should contain skiplinks=False in arguments In-Reply-To: <1340755434.68.0.382285544317.issue12971@psf.upfronthosting.co.za> Message-ID: <9004CDF3-A020-4D4F-A8FA-D6DCEA3F9F3C@gmail.com> ???? ????????? <socketpair at gmail.com> added the comment: ?????????? ? iPad 27.06.2012, ? 6:03, Larry Hastings <report at bugs.python.org> ???????(?): No, follow symlinks is not the same. Skiplinks mean returning true or false depending on fact that last path element is symlink. Checking If symlink appear in the middle of the path, this is not issue of this feature request. > > ---------- > nosy: +larry > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue12971> > _______________________________________ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12971> _______________________________________ From report at bugs.python.org Wed Jun 27 11:27:20 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 09:27:20 +0000 Subject: [issue15203] Accepting of os functions of (path, dir_fd) pair as argument Message-ID: <1340789239.97.0.934534609374.issue15203@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: Since many of os functions were polymorphic in its first argument (path or fd), the logical continuation is to add a (path, dir_fd) pair as yet one case of this argument. In any case dir_fd is incopatible with fd. This simplifies the code of certain functions which takes patch and dir_fd and pass them to lower level without changes, or that use same patch and dir_fd in calls of several functions. This freely adds support of dir_fd to many functions, such as os.path.isdir. This solves the problem of naming multiple dir_fd arguments (src_dir_fd/dst_dir_fd looks ugly). This saves a pre-3.3 signature of some functions, which will facilitate the use of decorators and improve compatibility with alternative implementations. ---------- components: Library (Lib) messages: 164132 nosy: storchaka priority: normal severity: normal status: open title: Accepting of os functions of (path, dir_fd) pair as argument versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15203> _______________________________________ From report at bugs.python.org Wed Jun 27 11:33:47 2012 From: report at bugs.python.org (Tim Golden) Date: Wed, 27 Jun 2012 09:33:47 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340789627.24.0.612606927872.issue1677@psf.upfronthosting.co.za> Tim Golden <mail at timgolden.me.uk> added the comment: Just to confirm: I can reproduce this more or less consistently on all versions of Python 2.2 -> 3.2 on Windows 7. Those are distribution builds -- ie not debug builds I've made myself. But it certainly does occur on a debug build of 2.7. I'm trying to narrow it down through some instrumentation (read: printf) on the 2.7 branch. The MSDN page for signal warns that a separate thread will be created for the signal handler which will muddy the waters. ---------- nosy: +tim.golden _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Wed Jun 27 11:33:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 09:33:52 +0000 Subject: [issue15200] Faster os.walk In-Reply-To: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za> Message-ID: <1340789632.37.0.268472785812.issue15200@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15200> _______________________________________ From report at bugs.python.org Wed Jun 27 11:34:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 09:34:07 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340789647.37.0.0308612861343.issue15202@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 11:34:18 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 09:34:18 +0000 Subject: [issue15203] Accepting of os functions of (path, dir_fd) pair as argument In-Reply-To: <1340789239.97.0.934534609374.issue15203@psf.upfronthosting.co.za> Message-ID: <1340789658.54.0.00983419961685.issue15203@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +larry _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15203> _______________________________________ From report at bugs.python.org Wed Jun 27 11:35:20 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 27 Jun 2012 09:35:20 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340789720.44.0.665570268632.issue15202@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Yeah, would be nice if that was consistent. ---------- nosy: +hynek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 11:41:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 09:41:03 +0000 Subject: [issue15186] Support os.walk(dir_fd=) In-Reply-To: <1340691451.45.0.925436589154.issue15186@psf.upfronthosting.co.za> Message-ID: <1340790082.2462.11.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Your move, Serhiy ;-) It seems that you play for both sides in the last days. ;-) I surrender. Really, I'm not interested in this feature, but as of symmetry, and this is a very weak motive. > p.s. Serhiy: yes, you can call os.fwalk() with dir_fd=None. It would be *awful* if you could not! And actually, os.fwalk didn't even support dir_fd until... 26 hours ago. See issue15200. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15186> _______________________________________ From report at bugs.python.org Wed Jun 27 11:50:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 09:50:19 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340790619.99.0.43933418009.issue15202@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- type: -> behavior versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 11:52:19 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 27 Jun 2012 09:52:19 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340790739.23.0.034936254511.issue15202@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I assert that "followlinks" and "symlinks" are both bad names. I dislike "followlinks" because "links" is ambiguous; both hard links and soft links are "links", but it's only modifying behavior regarding one of them. Also, it's not PEP-8-compliant (which we can forgive because I'm pretty sure it predates PEP 8). "symlinks" is far worse, because it's so ambiguous--quick, what does "symlinks=False" mean? Examine symlinks, or follow them? I agree that we can't rename "followlinks" and "symlinks" in 3.x. All we can do for now is move forward. At the same time I refused to be shackled by misguided old nomenclature. So, certainly, I don't want to see "follow_symlinks" changed. True story: the reason I started writing the patch for #14626 was so I could make sure it used the name "follow_symlinks". I was dead certain Serhiy would use one of the existing names ;-) If you really really want this to happen, you'll have to get Georg's permission--and the sooner the better. Already I suspect it is too late. If it ships in 3.3 it will absolutely be too late. I suggest another approach: add a redundant "follow_symlinks" argument to os.walk, os.fwalk, and the shutil functions. Prefer the new name in documentation but document the presence of the old one. Throw an exception if both are specified in an invocation. We could do that in 3.4. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 11:58:11 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 27 Jun 2012 09:58:11 +0000 Subject: [issue15200] Faster os.walk In-Reply-To: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za> Message-ID: <1340791091.08.0.987234303255.issue15200@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: It's amusing that using fwalk and throwing away the last argument is faster than a handwritten implementation. On the other hand, fwalk also uses a lot of file descriptors. Users with processes which were already borderline on max file descriptors might not appreciate upgrading to find their os.walk calls suddenly failing. Can you figure out why fwalk is faster, and apply that advantage to walk *without* consuming so many file descriptors? No rush... :) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15200> _______________________________________ From report at bugs.python.org Wed Jun 27 11:59:45 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 27 Jun 2012 09:59:45 +0000 Subject: [issue15203] Accepting of os functions of (path, dir_fd) pair as argument In-Reply-To: <1340789239.97.0.934534609374.issue15203@psf.upfronthosting.co.za> Message-ID: <1340791185.18.0.632050518011.issue15203@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I dislike this and always have. I think it would look ugly and be obnoxious to use. If you really think you can get this in for 3.3, you will have to bring it up with Georg. I think your chances are about zero. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15203> _______________________________________ From report at bugs.python.org Wed Jun 27 12:05:08 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 27 Jun 2012 10:05:08 +0000 Subject: [issue13876] Sporadic failure in test_socket In-Reply-To: <1340780430.33.0.138506780382.issue13876@psf.upfronthosting.co.za> Message-ID: <CAH_1eM2PPOvawJPsESv4TDRnpF1XniDd7WGT4gdL8dXgx44M-Q@mail.gmail.com> Charles-Fran?ois Natali <neologix at free.fr> added the comment: Looks like a kernel bug. The only thing "non-standard" the test does is let the client call close() before the server has called accept(), but this shouldn't result in ENOTCONN - and doesn't for TCP sockets. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13876> _______________________________________ From report at bugs.python.org Wed Jun 27 12:10:47 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 27 Jun 2012 10:10:47 +0000 Subject: [issue12971] os.isdir() should contain skiplinks=False in arguments In-Reply-To: <1315920238.53.0.290032380593.issue12971@psf.upfronthosting.co.za> Message-ID: <1340791847.17.0.675543609393.issue12971@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: First: there's no chance this will go into 3.1, 3.2, or 3.3 at this point. Second: I can assure you that switching to the l... version of a function and not following the last symlink is exactly what "follow_symlinks" is for. Please see the 3.3 documentation on follow_symlinks for more: http://docs.python.org/3.3/library/os.html#follow-symlinks Third: I think it's better to keep os.isdir() simple. Users who want more sophisticated use cases (what to do about symlinks, using a dir_fd parameter) should use os.stat(). So I'm -1 on this. TBH I'm not sure this even warrants a documentation change ("for more functionality, use os.stat()"). ---------- versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12971> _______________________________________ From report at bugs.python.org Wed Jun 27 12:20:53 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 27 Jun 2012 10:20:53 +0000 Subject: [issue15200] Faster os.walk In-Reply-To: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za> Message-ID: <1340792453.46.0.683006432244.issue15200@psf.upfronthosting.co.za> Charles-Fran?ois Natali <neologix at free.fr> added the comment: > On the other hand, fwalk also uses a lot of file descriptors. Users > with processes which were already borderline on max file descriptors > might not appreciate upgrading to find their os.walk calls suddenly > failing. It doesn't have to. Right now, it uses O(depth of the directory tree) FDs. It can be changed to only require O(1) FDs, see http://bugs.python.org/issue13734. For example, GNU coreutils "rm -rf" uses *at() syscalls and only requires a constant number of FDs. > Can you figure out why fwalk is faster, and apply that advantage to > walk *without* consuming so many file descriptors? I didn't run any benchmark or test, but one reason why fwalk() is faster could be simply because it doesn't do as much path resolution - which is a somewhat expensive operation - thanks to the relative FD being passed. I guess your mileage will vary with the FS in use, and the kernel version (there's been a lot of work to speed up path resolution by Nick Piggin during the last years or so). Anyway, I think that such optimization is useless, because this micro-benchmark doesn't make much sense: when you walk a directory tree, it's usually to do something with the files/directories encountered, and as soon as you do something with them - stat(), unlink(), etc - the gain on the walking time will become negligible. ---------- nosy: +neologix _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15200> _______________________________________ From report at bugs.python.org Wed Jun 27 12:29:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 10:29:51 +0000 Subject: [issue15204] Deprecate the 'U' open mode Message-ID: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> New submission from Serhiy Storchaka <storchaka at gmail.com>: Since Python 2.3 many open functions supports "Universal line mode" (PEP 278). Since 3.0 (and 2.6) PEP 3116 suggests better alternative -- io.TextWrapper. Now support for the 'U' mode in the different open functions is heterogeneous. Some functions simply ignore the 'U' mode (but accept it), others perceive it as a synonym for text-mode, others just pass it on lower lever, other attempt to implement it, but the implementation is obtained imperfect and contradictory (as in ZipExtFile). The documentation for built-in open does not advise the use of the 'U' mode. The 'U' mode support cumbersome. I propose to deprecate the 'U' mode. If someone wanted to work with the universal line support, he'll surely need to work with encodings too, and io.TextWrapper provides is better choise. The deprecation plan for the 'U' mode of open functions might be as follow: 3.3. Deprecating the 'U' mode in docs for all opens (building open, io.open, codecs.open, gzip.open, ZipFile.open, etc). Add suggestion about io.TextWrapper. 3.4. Raise a warning on use of the 'U' mode. 3.5. Raise an exception on use of the 'U' mode. 3.6 (or 4.0?). Remove the 'U' mode processing code. As the first stage involves only the changes to the documentation, I hope deprecation can starts in 3.3. ---------- assignee: docs at python components: Documentation, IO, Library (Lib) messages: 164142 nosy: docs at python, storchaka priority: normal severity: normal status: open title: Deprecate the 'U' open mode type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Wed Jun 27 12:31:18 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 27 Jun 2012 10:31:18 +0000 Subject: [issue15200] Faster os.walk In-Reply-To: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za> Message-ID: <1340793078.97.0.424986247396.issue15200@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > It doesn't have to. > Right now, it uses O(depth of the directory tree) FDs. > It can be changed to only require O(1) FDs But closing and reopening those file descriptors seems like it might slow it down; would it still be a performance win? Also, I'm not a security expert, but would the closing/reopening allow the possibility of timing attacks? If so, that might still be okay for walk which makes no guarantees about safety. (But obviously it would be unacceptable for fwalk.) > Anyway, I think that such optimization is useless, because this > micro-benchmark doesn't make much sense: when you walk a > directory tree, it's usually to do something with the > files/directories encountered, and as soon as you do something > with them - stat(), unlink(), etc - the gain on the walking > time will become negligible. I'm not sure that "usually" is true here. I suggest that "usually" people use os.walk to find *particular files* in a directory tree, generally by filename. So most of the time os.walk really is quickly iterating over directory trees doing very little. I think 20% is a respectable gain, and it's hard for me to say "no" to functions that make Python faster for free. (Well, for the possible cost of a slightly more expensive algorithm.) So I'm +x for now. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15200> _______________________________________ From report at bugs.python.org Wed Jun 27 12:32:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 10:32:30 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1340793150.66.0.0621555940582.issue15204@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +gvanrossum, jackjansen, pitrou, stutzbach _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Wed Jun 27 12:50:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 10:50:58 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1340794258.0.0.381368337223.issue15204@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Related issues: #2091, #5148, #6759, #12900. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Wed Jun 27 12:53:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 27 Jun 2012 10:53:21 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1340794401.58.0.268876514955.issue15204@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Starting to deprecate "U" in the 3.3 docs sounds reasonable to me. ---------- nosy: +georg.brandl, nadeem.vawda _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Wed Jun 27 13:12:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 11:12:33 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340790739.23.0.034936254511.issue15202@psf.upfronthosting.co.za> Message-ID: <1340795569.2462.25.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Also, it's not PEP-8-compliant (which we can forgive because I'm pretty sure it predates PEP 8). I don't see how this is contrary to PEP 8. PEP 8 says nothing about the names of function arguments. > Already I suspect it is too late. If it ships in 3.3 it will > absolutely be too late. Unfortunately, too little time has passed between #14626 accepting and shipping of 3.3b1. In any case, with accepted #14626 better than without it. > I suggest another approach: add a redundant "follow_symlinks" argument > to os.walk, os.fwalk, and the shutil functions. This is a bad solution, and I do not think that the benefits would outweigh the disadvantages. I am -0. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 13:17:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 27 Jun 2012 11:17:13 +0000 Subject: [issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error In-Reply-To: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za> Message-ID: <1340795833.09.0.594077538214.issue15198@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15198> _______________________________________ From report at bugs.python.org Wed Jun 27 13:28:03 2012 From: report at bugs.python.org (Anthony Kong) Date: Wed, 27 Jun 2012 11:28:03 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1340796483.47.0.522084351771.issue13241@psf.upfronthosting.co.za> Changes by Anthony Kong <anthony.hw.kong at gmail.com>: ---------- nosy: +Anthony.Kong _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13241> _______________________________________ From report at bugs.python.org Wed Jun 27 13:55:59 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 27 Jun 2012 11:55:59 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340798159.25.0.788363523915.issue15202@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > I don't see how this is contrary to PEP 8. PEP 8 says nothing about > the names of function arguments. Certainly it says *something*: http://www.python.org/dev/peps/pep-0008/#function-and-method-arguments But I grant you, it only specifically addresses "self", "cls", and function argument names that clash with keywords. I therefore suggest that function arguments are most similar to "method names and instance variables"--after all, they *are* instance variables. And "method names and instance variables" say "Use the function naming rules". And function names "should be lowercase, with words separated by underscores as necessary to improve readability." "followlinks" is comprised of two words but they are not separated by underscores. (We can also reason by process of elimination: function arguments are wholly dissimilar to constants, package/module names, classes, and exception. All the remaining types of identifiers in Python follow the above rule.) It might actually be nice to clarify PEP 8 on this. > Unfortunately, too little time has passed between #14626 accepting > and shipping of 3.3b1. I am genuinely sorry about that--but #14626 just wasn't ready earlier. I'm glad you think it's an improvement--we can certainly agree on that! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 14:12:14 2012 From: report at bugs.python.org (Olivier Berten) Date: Wed, 27 Jun 2012 12:12:14 +0000 Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE In-Reply-To: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za> Message-ID: <1340799134.0.0.95637168795.issue1276@psf.upfronthosting.co.za> Olivier Berten <olivier.berten at gmail.com> added the comment: Any idea why mac cjk encodings still aren't available in Python 2.7 and 3.2 ? ---------- components: -Build, Demos and Tools, Library (Lib), Macintosh nosy: +ezio.melotti, olivier-berten versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1276> _______________________________________ From report at bugs.python.org Wed Jun 27 14:53:41 2012 From: report at bugs.python.org (Ollie Walsh) Date: Wed, 27 Jun 2012 12:53:41 +0000 Subject: [issue15205] distutils dereferences symlinks on Mac OS X but not on Linux Message-ID: <1340801621.17.0.778641533675.issue15205@psf.upfronthosting.co.za> New submission from Ollie Walsh <ollie.walsh at gmail.com>: Hi, This is related to #12585. Distutils sdist builds a package tree using hardlinks to the source if supported by the OS. This is then tarred/zipped/etc... If the source contains symbolic links to external files: On Linux (and apparently Solaris) they are not dereferenced and the resulting package is broken. On OSX (and apparently all BSD kernels) a hardlink to a symlink will dereference the symlink first and the resulting tgz package is ok. However I would expect issue #8876 to be more likely as the symlink could references a different filesystem which would case hardlinking to fail. In #12585 I assume that zip dereferences the symlinks which masks the issue. distutils2 appears to always copy instead of hardlinking resolving all of these issues. distutils can be monkey patched to do the same: http://article.gmane.org/gmane.comp.python.distutils.devel/2078 ---------- assignee: eric.araujo components: Distutils messages: 164149 nosy: eric.araujo, ollie.walsh at gmail.com, tarek priority: normal severity: normal status: open title: distutils dereferences symlinks on Mac OS X but not on Linux type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15205> _______________________________________ From report at bugs.python.org Wed Jun 27 15:04:06 2012 From: report at bugs.python.org (Tim Golden) Date: Wed, 27 Jun 2012 13:04:06 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340802246.22.0.447176582953.issue1677@psf.upfronthosting.co.za> Tim Golden <mail at timgolden.me.uk> added the comment: OK, I've run out of time to look, but the culprit looks like it's an odd interaction between my_fgets in myreadline.c and the interrupt handler in signal. There's a section of code which is conditional on ERROR_OPERATION_ABORTED being returned from fgets in the CRT. That then tries to play ball with a the interrupt handler having fired already (in a separate thread) by sleeping for one second and checking that the handler was tripped. If it has then the function returns one and stuff happens elsewhere; it it hasn't then the function behaves as if EOF (ie Ctrl-Z) was pressed and Python exits. That's as far as I've got; it looks like a race condition of some sort but I can't see where. I'm not 100% sure that the SIGINT handler is tripping. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Wed Jun 27 15:16:45 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jun 2012 13:16:45 +0000 Subject: [issue15199] Default mimetype for javascript should be application/javascript In-Reply-To: <1340781019.87.0.733806504492.issue15199@psf.upfronthosting.co.za> Message-ID: <1340803005.13.0.601242306809.issue15199@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- components: +email nosy: +barry, r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15199> _______________________________________ From report at bugs.python.org Wed Jun 27 15:24:21 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jun 2012 13:24:21 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340803461.56.0.905813454387.issue15202@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Although I do dislike how long it is, I think I agree with larry on this one that follow_symlinks is the cleanest choice. And we are post feature-freeze, so I think changing it should be done only if there is a strong reason. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 15:30:35 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 27 Jun 2012 13:30:35 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340803835.81.0.390826359604.issue1677@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Great analysis! > ... by sleeping for one second ... Note that Sleep(1) only sleeps for 1 millisecond. Does the issue go away if you replace with Sleep(10)? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Wed Jun 27 15:31:01 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jun 2012 13:31:01 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1340803861.6.0.985390625011.issue15204@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Unless there are places where it is actually broken, I don't think there is a good reason to have step 3.5, though. Just add the deprecation warning and remove it in 4.0. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Wed Jun 27 15:31:39 2012 From: report at bugs.python.org (Tim Golden) Date: Wed, 27 Jun 2012 13:31:39 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1340803835.81.0.390826359604.issue1677@psf.upfronthosting.co.za> Message-ID: <4FEB0B36.8090203@timgolden.me.uk> Tim Golden <mail at timgolden.me.uk> added the comment: That'll be my next move when I get some more time. I've got someone coming over to see me (about real work!) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Wed Jun 27 15:33:26 2012 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 27 Jun 2012 13:33:26 +0000 Subject: [issue15205] distutils dereferences symlinks on Mac OS X but not on Linux In-Reply-To: <1340801621.17.0.778641533675.issue15205@psf.upfronthosting.co.za> Message-ID: <1340804006.92.0.101621963008.issue15205@psf.upfronthosting.co.za> Changes by Eric V. Smith <eric at trueblade.com>: ---------- nosy: +eric.smith _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15205> _______________________________________ From report at bugs.python.org Wed Jun 27 15:37:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 Jun 2012 13:37:57 +0000 Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library. In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za> Message-ID: <E1SjsRP-0000NL-3q@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 74a1110a3b50 by Christian Heimes in branch 'default': Issue 10924: Fixed mksalt() to use a RNG that is suitable for cryptographic purpose http://hg.python.org/cpython/rev/74a1110a3b50 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10924> _______________________________________ From report at bugs.python.org Wed Jun 27 15:52:48 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 Jun 2012 13:52:48 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1340805168.14.0.443064689757.issue15031@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Why is distribute reading bytecode to begin with? What's the use case, especially considering that using bytecode screws over other Python VMs like Jython and IronPython. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Wed Jun 27 16:01:39 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Jun 2012 14:01:39 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG Message-ID: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> New submission from Christian Heimes <lists at cheimes.de>: The uuid module uses Mersenne Twister from the random module as last fallback. However a MT isn't suitable for cryptographic purposes. The module should first try to use os.urandom() and then perhaps use its own instance of random.Random, similar to uuid_generate_* [1] The problem doesn't apply to most modern platforms as the uuid module uses either libuuid or the Windows API with ctypes. Therefore I consider the real world severity as low. It may not require a backport to Python 2.x. [1] http://linux.die.net/man/3/uuid_generate ---------- components: Library (Lib) messages: 164157 nosy: christian.heimes priority: normal severity: normal status: open title: uuid module falls back to unsuitable RNG type: security versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Wed Jun 27 16:02:35 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Jun 2012 14:02:35 +0000 Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library. In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za> Message-ID: <1340805755.06.0.100861348975.issue10924@psf.upfronthosting.co.za> Changes by Christian Heimes <lists at cheimes.de>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10924> _______________________________________ From report at bugs.python.org Wed Jun 27 16:08:57 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 14:08:57 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1340806137.58.0.931507102292.issue15031@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Well, it may be a vestige from setuptools and I don't know if it's still needed/appropriate, but distribute scans the pyc modules to try to see whether stuff is zip_safe or not when you run `python setup.py bdist_egg`: https://bitbucket.org/tarek/distribute/src/da2848d34282/setuptools/command/bdist_egg.py#cl-420 Personally, I always set zip_safe to True as I find zipped distributions to be a pain in the butt, but not all distributions out there always set it and currently `python setup.py bdist_egg` (and probably other commands?) bombs on such packages. We should probably get Tarek to weigh in here. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Wed Jun 27 16:16:43 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 14:16:43 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340806603.35.0.364303883455.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Updated patch based on feedback from Brett (thanks!) ---------- Added file: http://bugs.python.org/file26177/cpython-issue-15030.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 16:30:32 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 14:30:32 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340807432.49.0.509036775686.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Third revision of my patch based on additional feedback from Brett (thanks!)... ---------- Added file: http://bugs.python.org/file26178/cpython-issue-15030.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 16:37:49 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 Jun 2012 14:37:49 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1340807869.75.0.35039099806.issue15031@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: This all goes back to my original point: I don't want to promote people shipping around bytecode only as it hampers the use of other VMs. Anyway, I'll continue to contemplate this. Any function would have to verify the magic number and flat-out fail otherwise to prevent parsing issues (e.g. Marc's patch works with or without the file size field to stay compatible with PyPycLoader.write_bytecode() implementations that might not set the file size field; a design flaw that I fixed in SourceLoader by taking away the ability to write bytecode). It would also have it return a dict much like path_stats() for easy comparison / verification. But just to be very clear in case someone is hoping, I will NOT support an API to write bytecode as it make compatibility a nightmare and hampers changing the format as necessary. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Wed Jun 27 16:40:34 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 Jun 2012 14:40:34 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340808034.24.0.232549675188.issue15030@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: Patch looks good, Marc. Can you sign a PSF contributor agreement and send it in (http://www.python.org/psf/contrib/)? ---------- assignee: -> brett.cannon stage: -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 16:56:12 2012 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 27 Jun 2012 14:56:12 +0000 Subject: [issue11442] list_directory() in SimpleHTTPServer.py should add charset=... to Content-type header In-Reply-To: <1299611115.64.0.389023379939.issue11442@psf.upfronthosting.co.za> Message-ID: <1340808972.69.0.342966317235.issue11442@psf.upfronthosting.co.za> Guido van Rossum <guido at python.org> added the comment: For posterity, according to the red hat tracker at https://bugzilla.redhat.com/show_bug.cgi?id=803500 this issue has been assigned a CVE number: CVE-2011-4940 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11442> _______________________________________ From report at bugs.python.org Wed Jun 27 17:05:39 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 15:05:39 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340809539.87.0.215214597176.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Brett, I just emailed the contributor agreement. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 17:15:33 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 27 Jun 2012 15:15:33 +0000 Subject: [issue14954] weakref doc clarification In-Reply-To: <1338307482.44.0.878689614277.issue14954@psf.upfronthosting.co.za> Message-ID: <1340810133.92.0.667579645159.issue14954@psf.upfronthosting.co.za> Ethan Furman <ethan at stoneleaf.us> added the comment: Changed "... will return the object ..." to " ... may return the object ..." For reference, here's the new text: A weak reference to an object is not enough to keep the object alive: when the only remaining references to a referent are weak references, :term:`garbage collection` is free to destroy the referent and reuse its memory for something else. However, until the object is actually destroyed the weak reference may return the object even if there are no strong references to it. ---------- Added file: http://bugs.python.org/file26179/weakref_doc_updates_v2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14954> _______________________________________ From report at bugs.python.org Wed Jun 27 17:23:31 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 27 Jun 2012 15:23:31 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340810611.7.0.212703457825.issue15202@psf.upfronthosting.co.za> Georg Brandl <georg at python.org> added the comment: IMO adding follow_symlinks to the functions currently supporting symlinks/followlinks is a bugfix. Such a patch would be ok to go into 3.3. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 17:45:30 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:45:30 +0000 Subject: [issue15200] Faster os.walk In-Reply-To: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za> Message-ID: <1340811930.65.0.532567810446.issue15200@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15200> _______________________________________ From report at bugs.python.org Wed Jun 27 17:46:44 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:46:44 +0000 Subject: [issue15201] C argument errors and Python arguments error are different In-Reply-To: <1340787562.9.0.381014932259.issue15201@psf.upfronthosting.co.za> Message-ID: <1340812004.63.0.885458027404.issue15201@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15201> _______________________________________ From report at bugs.python.org Wed Jun 27 17:50:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:50:39 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340812239.77.0.561572683459.issue15202@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 17:51:48 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:51:48 +0000 Subject: [issue15203] Accepting of os functions of (path, dir_fd) pair as argument In-Reply-To: <1340789239.97.0.934534609374.issue15203@psf.upfronthosting.co.za> Message-ID: <1340812308.05.0.0704301015537.issue15203@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15203> _______________________________________ From report at bugs.python.org Wed Jun 27 17:52:50 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:52:50 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1340812370.22.0.531796967769.issue15204@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Wed Jun 27 17:53:46 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:53:46 +0000 Subject: [issue15205] distutils dereferences symlinks on Mac OS X but not on Linux In-Reply-To: <1340801621.17.0.778641533675.issue15205@psf.upfronthosting.co.za> Message-ID: <1340812426.43.0.295770974179.issue15205@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15205> _______________________________________ From report at bugs.python.org Wed Jun 27 17:55:11 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:55:11 +0000 Subject: [issue15031] Split .pyc parsing from module loading In-Reply-To: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za> Message-ID: <1340812511.86.0.649316916531.issue15031@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15031> _______________________________________ From report at bugs.python.org Wed Jun 27 17:56:03 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:56:03 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340812563.88.0.983461666066.issue15206@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Wed Jun 27 17:59:19 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 15:59:19 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340812759.9.0.371403383147.issue15030@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 18:03:29 2012 From: report at bugs.python.org (Dave Chambers) Date: Wed, 27 Jun 2012 16:03:29 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings Message-ID: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> New submission from Dave Chambers <dlchambers at aol.com>: The current mimetypes.read_windows_registry() enums the values under HKCR\MIME\Database\Content Type However, this is the key for mimetype to extension lookups, NOT for extension to mimetype lookups. As a result, when >1 MIME types are mapped to a particular extension, the last-found entry is used. For example, both "image/png" and "image/x-png" map to the ".png" file extension. Unfortunately, what happens is this code finds "image/png", then later finds "image/x-png" and this steals the ".png" extension. The solution is to use the correct regkey, which is the HKCR root. This is the correct location for extension-to-mimetype lookups. What we should do is enum the HKCR root, find all subkeys that start with a dot (i.e. file extensions), then inspect those for a 'Content Type' value. The attached ZIP contains: mimetype_flaw_demo.py - this demonstrates the error (due to wrong regkey) and my fix (uses the correct regkey) mimetypes_fixed.py - My suggested fix to the standard mimetypes.py module. ---------- components: Windows files: mimetype_flaw_demo.zip messages: 164167 nosy: dlchambers priority: normal severity: normal status: open title: mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26180/mimetype_flaw_demo.zip _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15207> _______________________________________ From report at bugs.python.org Wed Jun 27 18:04:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 27 Jun 2012 16:04:42 +0000 Subject: [issue12605] Enhancements to gdb 7 debugging hooks In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za> Message-ID: <1340813082.35.0.597040947963.issue12605@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Got the following error on Mageia 1: ====================================================================== FAIL: test_threads (test.test_gdb.PyBtTests) Verify that "py-bt" indicates threads that are waiting for the GIL ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/test/test_gdb.py", line 697, in test_threads cmds_after_breakpoint=['thread apply all py-bt']) File "/home/antoine/cpython/default/Lib/test/test_gdb.py", line 153, in get_stack_trace self.assertEqual(err, '') AssertionError: "Error occurred in Python command: 'NoneType' object has no attribute 'startswit [truncated]... != '' - Error occurred in Python command: 'NoneType' object has no attribute 'startswith' ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12605> _______________________________________ From report at bugs.python.org Wed Jun 27 18:50:57 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 27 Jun 2012 16:50:57 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340815857.1.0.286370533875.issue15030@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: I think the loader should just unconditionally assume 12 bytes header. This is meant to work only for the exact version it ships with, so it just has to match. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 18:53:56 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Wed, 27 Jun 2012 16:53:56 +0000 Subject: [issue15200] Faster os.walk In-Reply-To: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za> Message-ID: <1340816036.11.0.880478383589.issue15200@psf.upfronthosting.co.za> Ross Lagerwall <rosslagerwall at gmail.com> added the comment: This looks like the kind of optimization that depends hugely on what kernel you're using. Maybe on FreeBSD/Solaris/whatever, standard os.walk() is faster? If this micro-optimization were to be accepted, someone would have to be keen enough to test it is different ways on many different versions of every platform to conclusively prove that it is faster in general. ---------- nosy: +rosslagerwall _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15200> _______________________________________ From report at bugs.python.org Wed Jun 27 18:57:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 27 Jun 2012 16:57:27 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340816247.46.0.207347719678.issue15030@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > I think the loader should just unconditionally assume 12 bytes header. > This is meant to work only for the exact version it ships with, so it > just has to match. Agreed with Martin. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 19:00:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 27 Jun 2012 17:00:46 +0000 Subject: [issue15200] Faster os.walk In-Reply-To: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za> Message-ID: <1340816446.16.0.987119025975.issue15200@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > This looks like the kind of optimization that depends hugely on what > kernel you're using. Agreed. Also, I'm worried that there might be subtle differences between walk() and fwalk() which could come and bite users if we silently redirect the former to the latter. (for the record, I get a 15% speedup on this Linux box) ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15200> _______________________________________ From report at bugs.python.org Wed Jun 27 19:02:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 17:02:57 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340798159.25.0.788363523915.issue15202@psf.upfronthosting.co.za> Message-ID: <1340816597.2462.54.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > I dislike "followlinks" because "links" is ambiguous; both hard links > and soft links are "links", but it's only modifying behavior regarding > one of them. Technically, in Unix world any file is a hard link. It is impossible to distinguish a hard link from the "original", they are completely equal. So I don't think that there will be a ambiguity, what links are implied, especially, if the documentation is clearly says "symbolic links". > I therefore suggest that function arguments are most similar to "method names and instance variables"--after all, they *are* instance variables. Technically, they are local variables. > "followlinks" is comprised of two words but they are not separated by underscores. As "getgrouplist" or "sendfile". What about such argument names as "filename" and "newline"? If being a consistent in that, then it must be "follow_symbolic_links". And "source_directory_file_descriptor" instead "src_dir_fd". > It might actually be nice to clarify PEP 8 on this. I agree. > I'm glad you think it's an improvement--we can certainly agree on that! Of course. This is the issue, for the solution of which I registered here. All other issues and patches were just distractions and practice. ;-) I am grateful to you. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 19:21:10 2012 From: report at bugs.python.org (Roger Serwy) Date: Wed, 27 Jun 2012 17:21:10 +0000 Subject: [issue14667] No IDLE In-Reply-To: <1335313762.17.0.753940415621.issue14667@psf.upfronthosting.co.za> Message-ID: <1340817670.49.0.416360019352.issue14667@psf.upfronthosting.co.za> Roger Serwy <roger.serwy at gmail.com> added the comment: James, do you have IDLE working? ---------- nosy: +serwy status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14667> _______________________________________ From report at bugs.python.org Wed Jun 27 19:33:04 2012 From: report at bugs.python.org (kracekumar ramaraju) Date: Wed, 27 Jun 2012 17:33:04 +0000 Subject: [issue15208] Uparrow doesn't show previously typed variable or character Message-ID: <1340818384.4.0.370220221204.issue15208@psf.upfronthosting.co.za> New submission from kracekumar ramaraju <me at kracekumar.com>: Below is the copy & paste from the Interpreter. kracekumar at python-lover:~/codes/python/Python-3.3.0b1$ python3.3 Python 3.3.0b1 (default, Jun 27 2012, 22:27:38) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> __builtins__ <module 'builtins'> >>> ^[[A^[[A On pressing the up arrow inside 3.3 b1 interpreter doesn't show previously typed variable or statement. This test was carried out in ubuntu 12.04. ---------- components: Interpreter Core messages: 164175 nosy: kracekumar priority: normal severity: normal status: open title: Uparrow doesn't show previously typed variable or character type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15208> _______________________________________ From report at bugs.python.org Wed Jun 27 19:39:18 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jun 2012 17:39:18 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> Message-ID: <1340818758.06.0.88156517543.issue15207@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Thanks for working on this. Could you please post the fix as a patch file? If you don't have mercurial, you can generate the diff on windows using the python diff module (scripts/diff.py -u <yourfile> <origfile>). Actually, I'm not sure exactly where diff is in the windows install, but I know it is there. Do you know if image/x-png and image/png are included in the registry on all windows versions? If so we could use that key for a unit test. ---------- components: +email nosy: +barry, r.david.murray stage: -> needs patch versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15207> _______________________________________ From report at bugs.python.org Wed Jun 27 19:54:13 2012 From: report at bugs.python.org (Dave Chambers) Date: Wed, 27 Jun 2012 17:54:13 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> Message-ID: <1340819653.87.0.436594589163.issue15207@psf.upfronthosting.co.za> Dave Chambers <dlchambers at aol.com> added the comment: My first diff file... I hope I did it right :) ---------- keywords: +patch Added file: http://bugs.python.org/file26181/mimetypes.py.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15207> _______________________________________ From report at bugs.python.org Wed Jun 27 19:55:13 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 Jun 2012 17:55:13 +0000 Subject: [issue15208] Uparrow doesn't show previously typed variable or character In-Reply-To: <1340818384.4.0.370220221204.issue15208@psf.upfronthosting.co.za> Message-ID: <1340819713.08.0.665715305795.issue15208@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: It looks like the Python you are using was built without GNU readline. You probably need to install the libreadline-dev package from Ubuntu and rebuild Python. ---------- nosy: +ned.deily resolution: -> invalid status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15208> _______________________________________ From report at bugs.python.org Wed Jun 27 19:57:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 17:57:44 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340810611.7.0.212703457825.issue15202@psf.upfronthosting.co.za> Message-ID: <1340819877.2462.62.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > IMO adding follow_symlinks to the functions currently supporting symlinks/followlinks is a bugfix. Such a patch would be ok to go into 3.3. Here is an other patch, that implements Larry's suggestion about renaming followlinks in (f)walk to follow_symlinks (with keeping old name as alias). I hope native speakers corrected me in docs. However, I don't think that this is the best solution (but it better than nothing). ---------- Added file: http://bugs.python.org/file26182/followlinks-to-follow_symlinks.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ -------------- next part -------------- diff -r b66e82c9f852 Doc/library/os.rst --- a/Doc/library/os.rst Tue Jun 26 23:05:27 2012 +0200 +++ b/Doc/library/os.rst Wed Jun 27 20:49:59 2012 +0300 @@ -2128,7 +2128,7 @@ and the *dir_fd*, *follow_symlinks*, and *ns* parameters. -.. function:: walk(top, topdown=True, onerror=None, followlinks=False) +.. function:: walk(top, topdown=True, onerror=None, follow_symlinks=False) .. index:: single: directory; walking @@ -2168,12 +2168,12 @@ is available as the ``filename`` attribute of the exception object. By default, :func:`walk` will not walk down into symbolic links that resolve to - directories. Set *followlinks* to ``True`` to visit directories pointed to by + directories. Set *follow_symlinks* to ``True`` to visit directories pointed to by symlinks, on systems that support them. .. note:: - Be aware that setting *followlinks* to ``True`` can lead to infinite + Be aware that setting *follow_symlinks* to ``True`` can lead to infinite recursion if a link points to a parent directory of itself. :func:`walk` does not keep track of the directories it visited already. @@ -2210,8 +2210,12 @@ for name in dirs: os.rmdir(os.path.join(root, name)) - -.. function:: fwalk(top='.', topdown=True, onerror=None, followlinks=False, *, dir_fd=None) + .. versionchanged:: 3.3 + *followlinks* renamed to *follow_symlinks*. For backward compatibility + the old name accepted as alias to new one. + + +.. function:: fwalk(top='.', topdown=True, onerror=None, follow_symlinks=False, *, dir_fd=None) .. index:: single: directory; walking diff -r b66e82c9f852 Lib/os.py --- a/Lib/os.py Tue Jun 26 23:05:27 2012 +0200 +++ b/Lib/os.py Wed Jun 27 20:49:59 2012 +0300 @@ -331,7 +331,9 @@ __all__.extend(["makedirs", "removedirs", "renames"]) -def walk(top, topdown=True, onerror=None, followlinks=False): +_sentry = object() + +def walk(top, topdown=True, onerror=None, follow_symlinks=_sentry, *, followlinks=_sentry): """Directory tree generator. For each directory in the directory tree rooted at top (including top @@ -369,7 +371,7 @@ By default, os.walk does not follow symbolic links to subdirectories on systems that support them. In order to get this functionality, set the - optional argument 'followlinks' to true. + optional argument 'follow_symlinks' to true. Caution: if you pass a relative pathname for top, don't change the current working directory between resumptions of walk. walk never @@ -387,7 +389,18 @@ if 'CVS' in dirs: dirs.remove('CVS') # don't visit CVS directories """ + if follow_symlinks is _sentry: + if followlinks is _sentry: + follow_symlinks = False + else: + follow_symlinks = followlinks + elif followlinks is not _sentry: + raise ValueError( + "'follow_symlinks' and 'followlinks' arguments are incompatible") + yield from _walk(top, topdown, onerror, follow_symlinks) + +def _walk(top, topdown, onerror, follow_symlinks): islink, join, isdir = path.islink, path.join, path.isdir # We may not have read permission for top, in which case we can't @@ -415,8 +428,8 @@ yield top, dirs, nondirs for name in dirs: new_path = join(top, name) - if followlinks or not islink(new_path): - yield from walk(new_path, topdown, onerror, followlinks) + if follow_symlinks or not islink(new_path): + yield from walk(new_path, topdown, onerror, follow_symlinks) if not topdown: yield top, dirs, nondirs @@ -424,7 +437,7 @@ if {open, stat} <= supports_dir_fd and {listdir, stat} <= supports_fd: - def fwalk(top=".", topdown=True, onerror=None, followlinks=False, *, dir_fd=None): + def fwalk(top=".", topdown=True, onerror=None, follow_symlinks=False, *, dir_fd=None): """Directory tree generator. This behaves exactly like walk(), except that it yields a 4-tuple @@ -435,7 +448,7 @@ and `dirfd` is a file descriptor referring to the directory `dirpath`. The advantage of fwalk() over walk() is that it's safe against symlink - races (when followlinks is False). + races (when follow_symlinks is False). If dir_fd is not None, it should be a file descriptor open to a directory, and top should be relative; top will then be relative to that directory. @@ -462,13 +475,13 @@ orig_st = stat(top, follow_symlinks=False, dir_fd=dir_fd) topfd = open(top, O_RDONLY, dir_fd=dir_fd) try: - if (followlinks or (st.S_ISDIR(orig_st.st_mode) and - path.samestat(orig_st, stat(topfd)))): - yield from _fwalk(topfd, top, topdown, onerror, followlinks) + if (follow_symlinks or (st.S_ISDIR(orig_st.st_mode) and + path.samestat(orig_st, stat(topfd)))): + yield from _fwalk(topfd, top, topdown, onerror, follow_symlinks) finally: close(topfd) - def _fwalk(topfd, toppath, topdown, onerror, followlinks): + def _fwalk(topfd, toppath, topdown, onerror, follow_symlinks): # Note: This uses O(depth of the directory tree) file descriptors: if # necessary, it can be adapted to only require O(1) FDs, see issue # #13734. @@ -499,16 +512,16 @@ for name in dirs: try: - orig_st = stat(name, dir_fd=topfd, follow_symlinks=followlinks) + orig_st = stat(name, dir_fd=topfd, follow_symlinks=follow_symlinks) dirfd = open(name, O_RDONLY, dir_fd=topfd) except error as err: if onerror is not None: onerror(err) return try: - if followlinks or path.samestat(orig_st, stat(dirfd)): + if follow_symlinks or path.samestat(orig_st, stat(dirfd)): dirpath = path.join(toppath, name) - yield from _fwalk(dirfd, dirpath, topdown, onerror, followlinks) + yield from _fwalk(dirfd, dirpath, topdown, onerror, follow_symlinks) finally: close(dirfd) diff -r b66e82c9f852 Lib/test/test_os.py --- a/Lib/test/test_os.py Tue Jun 26 23:05:27 2012 +0200 +++ b/Lib/test/test_os.py Wed Jun 27 20:49:59 2012 +0300 @@ -712,6 +712,14 @@ if support.can_symlink(): # Walk, following symlinks. + for root, dirs, files in os.walk(walk_path, follow_symlinks=True): + if root == link_path: + self.assertEqual(dirs, []) + self.assertEqual(files, ["tmp4"]) + break + else: + self.fail("Didn't follow symlink with follow_symlinks=True") + # Walk, using backward compatible argument name "followlinks". for root, dirs, files in os.walk(walk_path, followlinks=True): if root == link_path: self.assertEqual(dirs, []) @@ -720,6 +728,10 @@ else: self.fail("Didn't follow symlink with followlinks=True") + # Incopatible using new and old argument names for "follow_symlinks". + self.assertRaises(ValueError, os.walk, walk_path, + follow_links=True, followlinks=True) + def tearDown(self): # Tear everything down. This is a decent use for bottom-up on # Windows, which doesn't have a recursive delete command. The @@ -745,8 +757,8 @@ """ compare with walk() results. """ - for topdown, followlinks in itertools.product((True, False), repeat=2): - d = {'topdown': topdown, 'followlinks': followlinks} + for topdown, follow_symlinks in itertools.product((True, False), repeat=2): + d = {'topdown': topdown, 'follow_symlinks': follow_symlinks} walk_kwargs.update(d) fwalk_kwargs.update(d) @@ -774,8 +786,8 @@ def test_yields_correct_dir_fd(self): # check returned file descriptors - for topdown, followlinks in itertools.product((True, False), repeat=2): - args = support.TESTFN, topdown, None, followlinks + for topdown, follow_symlinks in itertools.product((True, False), repeat=2): + args = support.TESTFN, topdown, None, follow_symlinks for root, dirs, files, rootfd in os.fwalk(*args): # check that the FD is valid os.fstat(rootfd) diff -r b66e82c9f852 Modules/_ctypes/libffi/generate-ios-source-and-headers.py --- a/Modules/_ctypes/libffi/generate-ios-source-and-headers.py Tue Jun 26 23:05:27 2012 +0200 +++ b/Modules/_ctypes/libffi/generate-ios-source-and-headers.py Wed Jun 27 20:49:59 2012 +0300 @@ -83,7 +83,7 @@ headers_seen = collections.defaultdict(set) def move_source_tree(src_dir, dest_dir, dest_include_dir, arch=None, prefix=None, suffix=None): - for root, dirs, files in os.walk(src_dir, followlinks=True): + for root, dirs, files in os.walk(src_dir, follow_symlinks=True): relroot = os.path.relpath(root,src_dir) def move_dir(arch, prefix='', suffix='', files=[]): diff -r b66e82c9f852 Modules/_ctypes/libffi/generate-osx-source-and-headers.py --- a/Modules/_ctypes/libffi/generate-osx-source-and-headers.py Tue Jun 26 23:05:27 2012 +0200 +++ b/Modules/_ctypes/libffi/generate-osx-source-and-headers.py Wed Jun 27 20:49:59 2012 +0300 @@ -77,7 +77,7 @@ headers_seen = collections.defaultdict(set) def move_source_tree(src_dir, dest_dir, dest_include_dir, arch=None, prefix=None, suffix=None): - for root, dirs, files in os.walk(src_dir, followlinks=True): + for root, dirs, files in os.walk(src_dir, follow_symlinks=True): relroot = os.path.relpath(root,src_dir) def move_dir(arch, prefix='', suffix='', files=[]): From report at bugs.python.org Wed Jun 27 20:06:04 2012 From: report at bugs.python.org (Dave Chambers) Date: Wed, 27 Jun 2012 18:06:04 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340818758.06.0.88156517543.issue15207@psf.upfronthosting.co.za> Message-ID: <8CF22A69F9852DB-14C4-227A1@webmail-d017.sysops.aol.com> Dave Chambers <dlchambers at aol.com> added the comment: I added a diff file to the bug. Dunno if that's the same as a patch file, or how to create a patchfile if it's not. >Do you know if image/x-png and image/png are included in the registry on all > windows versions? I think your question is reversed, in the same way that the code was reversed. You're not looking for image/png and/or image/x-png. You're looking for .png in order to retrieve its mimetype (aka Content Type). While nothing is 100% certain on Windows :), I'm quite confident that every copy will have an HKCR\.png regkey, and that regkey will have a Content Type value, and that value's setting will be the appropriate mometype, which I'd expect to be image/png. I was kinda surprised to find this bug as it's so obvious I started chasing it because Chrome kept complaining that pngs were being served as image/x-png (by CherryPy). There are other bugs (eg: 15199, 10551) that my patch should fix. -Dave ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15207> _______________________________________ From report at bugs.python.org Wed Jun 27 20:10:54 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Jun 2012 18:10:54 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340820654.83.0.0855941953762.issue15206@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Further analysis: * uuid1() uses random.randrange() if the system doesn't provide uuid_generate_time * uuid1() also falls back to random.randrange() in getnode()'s _random_getnode() if no hardware address can be acquired. * uuid4() is fine as it only falls back to random.randrange() when os.urandom() fails. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Wed Jun 27 20:12:43 2012 From: report at bugs.python.org (Dave Malcolm) Date: Wed, 27 Jun 2012 18:12:43 +0000 Subject: [issue12605] Enhancements to gdb 7 debugging hooks In-Reply-To: <1340813082.35.0.597040947963.issue12605@psf.upfronthosting.co.za> Message-ID: <1340820714.20337.34.camel@surprise> Dave Malcolm <dmalcolm at redhat.com> added the comment: I believe this was due to this line: return self._gdbframe.name().startswith('pthread_cond_timedwait') within is_waiting_for_gil(), and your gdb returned None for self._gdbframe.name() for your build. I've changed it to: name = self._gdbframe.name() if name: return name.startswith('pthread_cond_timedwait') in my latest version. I've also bulletproofed against the --without-threads case by simply skipping the cases that fail (some tests run into this gdb error: Cannot find new threads: generic error unless we add LD_PRELOAD=PATH-TO-libpthread.so.1 as a workaround, but it seems that trying to add that workaround is more risky (what path?) than simply skipping the tests under those circumstances. Tested successfully on a Fedora 15 x86_64 box (gdb-7.3-43.fc15.x86_64) with these configurations: * --with-pydebug * --with-pydebug --enable-shared * (no flags = optimized) * --enable-shared (optimized) * --with-pydebug --without-threads (Note that because of issue #14774 I have to regenerate _sysconfigdata.py between each configuration, otherwise it gets confused about whether or not the build is optimized) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12605> _______________________________________ From report at bugs.python.org Wed Jun 27 20:16:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 Jun 2012 18:16:31 +0000 Subject: [issue12605] Enhancements to gdb 7 debugging hooks In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za> Message-ID: <E1Sjwmz-00019a-2g@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset abcd29c9a791 by David Malcolm in branch 'default': Issue #12605: Show information on more C frames within gdb backtraces http://hg.python.org/cpython/rev/abcd29c9a791 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12605> _______________________________________ From report at bugs.python.org Wed Jun 27 20:27:46 2012 From: report at bugs.python.org (Tyler Crompton) Date: Wed, 27 Jun 2012 18:27:46 +0000 Subject: [issue15209] Re-raising exceptions from an expression Message-ID: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> New submission from Tyler Crompton <gtr053 at gmail.com>: As you know, a caught exception can be re-raised with a simple `raise` statement. Plain and simple. However, one cannot re-raise an error with this new `"from" expression` clause. For example: def getch(prompt=''): '''Get and return a character (similar to `input()`).''' print(prompt, end='') try: return windows_module.getch() except NameError: try: fallback_module.getch() except Exception: raise from None Output: File "getch.py", line 11 raise from None ^ SyntaxError: invalid syntax A quick look at the documentation about [raise](http://docs.python.org/dev/reference/simple_stmts.html#the-raise-statement) confirms that this is the intended behavior. In my opinion, one should be able to still re-raise from an expression. ---------- components: Interpreter Core files: getch.py messages: 164184 nosy: Tyler.Crompton priority: normal severity: normal status: open title: Re-raising exceptions from an expression type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26183/getch.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Wed Jun 27 20:29:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 27 Jun 2012 18:29:03 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340821743.91.0.467018106761.issue15206@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: Can you elaborate why it is unsuitable? None of the uuid functions claim any cryptographic properties, so even if MT was unsuitable for cryptographic purposes, this wouldn't rule it out for generating uuids. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Wed Jun 27 20:34:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 18:34:52 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340822092.42.0.678995072246.issue15202@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: Removed file: http://bugs.python.org/file26182/followlinks-to-follow_symlinks.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 20:36:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 18:36:12 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340822172.04.0.657861458674.issue15202@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: Added file: http://bugs.python.org/file26184/followlinks-to-follow_symlinks.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 20:36:33 2012 From: report at bugs.python.org (Tyler Crompton) Date: Wed, 27 Jun 2012 18:36:33 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340822193.03.0.850059488623.issue15209@psf.upfronthosting.co.za> Tyler Crompton <gtr053 at gmail.com> added the comment: Relevent PEP: http://www.python.org/dev/peps/pep-0409/ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Wed Jun 27 20:47:47 2012 From: report at bugs.python.org (Tim Golden) Date: Wed, 27 Jun 2012 18:47:47 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <4FEB0B36.8090203@timgolden.me.uk> Message-ID: <4FEB5546.40905@timgolden.me.uk> Tim Golden <mail at timgolden.me.uk> added the comment: OK, it is a race condition between the code in myreadline.c and the signal_handler in signalmodule.c. It can take between 0 and 3 sleeps for the myreadline code to see the signal tripped. Patch on its way for 2.7; VS 2010 downloading so that 3.x patch can be tested. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Wed Jun 27 20:57:55 2012 From: report at bugs.python.org (Tyler Crompton) Date: Wed, 27 Jun 2012 18:57:55 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340823475.13.0.430648853149.issue15209@psf.upfronthosting.co.za> Changes by Tyler Crompton <gtr053 at gmail.com>: ---------- nosy: +ncoghlan, stoneleaf _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Wed Jun 27 21:21:10 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 Jun 2012 19:21:10 +0000 Subject: [issue15210] importlib.__init__ checks for the wrong exception when looking for _frozen_importlib Message-ID: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za> New submission from Brett Cannon <brett at python.org>: If you look at http://hg.python.org/cpython/file/abcd29c9a791/Lib/importlib/__init__.py you will notice that the try/except block for seeing if _frozen_importlib exists catches ImportError, not KeyError like it should since it is checking sys. modules and not performing an import. ---------- components: Library (Lib) messages: 164188 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: importlib.__init__ checks for the wrong exception when looking for _frozen_importlib versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15210> _______________________________________ From report at bugs.python.org Wed Jun 27 21:23:52 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 19:23:52 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340825032.77.0.472370272076.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Hmmm if I simply do: diff -r b66e82c9f852 Lib/importlib/abc.py --- a/Lib/importlib/abc.py Tue Jun 26 23:05:27 2012 +0200 +++ b/Lib/importlib/abc.py Wed Jun 27 12:15:55 2012 -0700 @@ -282,7 +282,7 @@ if len(raw_timestamp) < 4: raise EOFError("bad timestamp in {}".format(fullname)) pyc_timestamp = _bootstrap._r_long(raw_timestamp) - bytecode = data[8:] + bytecode = data[12:] # Verify that the magic number is valid. if imp.get_magic() != magic: raise ImportError( then I get two "ValueError: bad marshal data (unknown type code)" test errors in test_abc_loader. I am unsure as to whether this is a bug in the test or the implementation. The following quells the errors, but I am not all confident that it's correct: @@ -302,7 +302,10 @@ raise else: # Bytecode seems fine, so try to use it. - return marshal.loads(bytecode) + try: + return marshal.loads(bytecode) + except ValueError: + return '' elif source_timestamp is None: raise ImportError("no source or bytecode available to create code " "object for {0!r}".format(fullname), ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 21:28:38 2012 From: report at bugs.python.org (j) Date: Wed, 27 Jun 2012 19:28:38 +0000 Subject: [issue15211] Test Message-ID: <1340825318.64.0.0530853129884.issue15211@psf.upfronthosting.co.za> New submission from j <jeffrey.gatto at bwater.com>: asdf fsa sads f ---------- assignee: collinwinter components: Benchmarks messages: 164190 nosy: collinwinter, jgbw priority: normal severity: normal status: open title: Test type: crash versions: Python 3.1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15211> _______________________________________ From report at bugs.python.org Wed Jun 27 21:30:56 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jun 2012 19:30:56 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> Message-ID: <1340825456.63.0.410532037288.issue15207@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: Well, I had no involvement in the windows registry reading stuff, and it is relatively new. And, as issue 10551 indicates, a bit controversial. (issue 15199 is a different bug, in python's own internal table). Can you run that diff again and use the '-u' flag? The -u (universal) format is the one we are used to working with. The one you posted still lets us read the changes, though, which is very helpful. ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15207> _______________________________________ From report at bugs.python.org Wed Jun 27 21:32:54 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jun 2012 19:32:54 +0000 Subject: [issue15211] Test In-Reply-To: <1340825318.64.0.0530853129884.issue15211@psf.upfronthosting.co.za> Message-ID: <1340825574.3.0.96158845905.issue15211@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- assignee: collinwinter -> resolution: -> invalid stage: -> committed/rejected status: open -> closed type: crash -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15211> _______________________________________ From report at bugs.python.org Wed Jun 27 21:49:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 27 Jun 2012 19:49:59 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340826599.28.0.887193020071.issue15030@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > I am unsure as to whether this is a bug in the test or the implementation. You should probably investigate a bit more. We don't want to silence exceptions if there's not a good reason to. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 21:53:17 2012 From: report at bugs.python.org (Tyler Crompton) Date: Wed, 27 Jun 2012 19:53:17 +0000 Subject: [issue15208] Uparrow doesn't show previously typed variable or character In-Reply-To: <1340818384.4.0.370220221204.issue15208@psf.upfronthosting.co.za> Message-ID: <1340826796.98.0.602847367457.issue15208@psf.upfronthosting.co.za> Tyler Crompton <gtr053 at gmail.com> added the comment: I recreated this issue on (mostly) fresh install of Ubuntu Server 12.04. I installed libreadline-dev and then removed and re-installed Python 3.3.0b1. This resolved the issue. ---------- nosy: +Tyler.Crompton status: pending -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15208> _______________________________________ From report at bugs.python.org Wed Jun 27 21:54:01 2012 From: report at bugs.python.org (Dave Chambers) Date: Wed, 27 Jun 2012 19:54:01 +0000 Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za> Message-ID: <1340826841.59.0.959753899452.issue15207@psf.upfronthosting.co.za> Changes by Dave Chambers <dlchambers at aol.com>: Added file: http://bugs.python.org/file26185/mimetypes.py.diff.u _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15207> _______________________________________ From report at bugs.python.org Wed Jun 27 21:54:16 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Jun 2012 19:54:16 +0000 Subject: [issue15208] Uparrow doesn't show previously typed variable or character In-Reply-To: <1340818384.4.0.370220221204.issue15208@psf.upfronthosting.co.za> Message-ID: <1340826856.57.0.62089132119.issue15208@psf.upfronthosting.co.za> Changes by R. David Murray <rdmurray at bitdance.com>: ---------- stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15208> _______________________________________ From report at bugs.python.org Wed Jun 27 22:12:43 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 Jun 2012 20:12:43 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340827963.92.0.298094169806.issue15030@psf.upfronthosting.co.za> Brett Cannon <brett at python.org> added the comment: The patch could be updated to ignore the 12 bytes unconditionally when reading bytecode but still write out the accurate file size (when possible). That should be fully compatible within Python 3.3 no matter who generated the bytecode (PyPycLoader or import). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 22:29:45 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 27 Jun 2012 20:29:45 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za> Message-ID: <1340828985.0.0.711561533284.issue15202@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: > > after all, they *are* instance variables. > Technically, they are local variables. Yeah, tbh I was thinking "instance of an invocation" here. But PEP 8 probably means "instance of a class" here. Still, there are three classes of naming things in Python: all uppercase (constants), CapCase (class and exception names), and everything else (lowercase with underscores). I suggest that arguments and local variables belong in the latter camp. At no point does PEP 8 suggest naming anything in lowercase without underscores. > As "getgrouplist" or "sendfile". What about such argument names as > "filename" and "newline"? If being a consistent in that, then it > must be "follow_symbolic_links". And > "source_directory_file_descriptor" instead "src_dir_fd". You are muddling the issue--PEP 8 makes no ruling on abbreviations. Personally, I prefer not to use abbreviations where possible. I've found over the years that they are painfully ambiguous--I can never remember what abbreviation I used. ("control" becomes... "ctl"? "cntl"?) MvL also makes a good point that abbreviations are a hinderance to people who speak little or no English. That said, naming things after their POSIX counterparts has to be okay, and abbreviations are occasionally called for when they are widely understood / have a precedent in the library. So with every example you cite I prefer the extant name over any counterproposal you explicitly suggested. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ From report at bugs.python.org Wed Jun 27 22:32:16 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 20:32:16 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340829136.66.0.00970777718045.issue4489@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment: The fix (c910af2e3c98 + 53fc7f59c7bb) for this issue broke deletion of directories, which contain symlinks to directories. (Directories with symlinks to regular files or symlinks to nonexistent files are unaffected.) $ mkdir -p /tmp/a/b $ ln -s b /tmp/a/c $ python3.2 -c 'import shutil; shutil.rmtree("/tmp/a")' $ mkdir -p /tmp/a/b $ ln -s b /tmp/a/c $ python3.3 -c 'import shutil; shutil.rmtree("/tmp/a")' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib64/python3.3/shutil.py", line 447, in rmtree _rmtree_safe_fd(fd, path, onerror) File "/usr/lib64/python3.3/shutil.py", line 395, in _rmtree_safe_fd _rmtree_safe_fd(dirfd, fullname, onerror) File "/usr/lib64/python3.3/shutil.py", line 406, in _rmtree_safe_fd onerror(os.rmdir, path, sys.exc_info()) File "/usr/lib64/python3.3/shutil.py", line 404, in _rmtree_safe_fd os.rmdir(path) NotADirectoryError: [Errno 20] Not a directory: '/tmp/a/c' $ ---------- resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Wed Jun 27 22:33:40 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 27 Jun 2012 20:33:40 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340829220.66.0.526465791769.issue15209@psf.upfronthosting.co.za> Ethan Furman <ethan at stoneleaf.us> added the comment: I agree that "raise from None" would be a nice enhancement. I don't see it going into 3.3 since we've hit feature freeze. Nick, do we need another PEP, or just consensus on pydev? (If consensus, I can bring it up there after 3.3.0final is released.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Wed Jun 27 23:04:59 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 21:04:59 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340831099.21.0.0759891797435.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Here's a patch that unconditionally switches over to the 12 byte format. I'm assuming the "size" in data[8:12] is the length of the bytecode? ---------- Added file: http://bugs.python.org/file26186/cpython-issue-15030.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 23:05:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Jun 2012 21:05:53 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340819877.2462.62.camel@raxxla> Message-ID: <1340831165.2462.66.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: And here is a patch, that replaces "symlinks" arguments in shutil by "follow_symlinks" (with keeping old name if it exists before 3.3). I very hope native speakers corrected me in docs. ---------- Added file: http://bugs.python.org/file26187/symlinks-to-follow_symlinks.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ -------------- next part -------------- diff -r b66e82c9f852 Doc/library/shutil.rst --- a/Doc/library/shutil.rst Tue Jun 26 23:05:27 2012 +0200 +++ b/Doc/library/shutil.rst Thu Jun 28 00:00:38 2012 +0300 @@ -47,7 +47,7 @@ be copied. -.. function:: copyfile(src, dst, symlinks=False) +.. function:: copyfile(src, dst, follow_symlinks=True) Copy the contents (no metadata) of the file named *src* to a file named *dst* and return *dst*. *dst* must be the complete target file name; look at @@ -59,63 +59,63 @@ such as character or block devices and pipes cannot be copied with this function. *src* and *dst* are path names given as strings. - If *symlinks* is true and *src* is a symbolic link, a new symbolic link will + If *follow_symlinks* is false and *src* is a symbolic link, a new symbolic link will be created instead of copying the file *src* points to. .. versionchanged:: 3.3 :exc:`IOError` used to be raised instead of :exc:`OSError`. - Added *symlinks* argument. + Added *follow_symlinks* argument. .. versionchanged:: 3.3 Added return of the *dst*. -.. function:: copymode(src, dst, symlinks=False) +.. function:: copymode(src, dst, follow_symlinks=True) Copy the permission bits from *src* to *dst*. The file contents, owner, and group are unaffected. *src* and *dst* are path names given as strings. If - *symlinks* is true, *src* a symbolic link and the operating system supports + *follow_symlinks* is false, *src* a symbolic link and the operating system supports modes for symbolic links (for example BSD-based ones), the mode of the link will be copied. .. versionchanged:: 3.3 - Added *symlinks* argument. + Added *follow_symlinks* argument. -.. function:: copystat(src, dst, symlinks=False) +.. function:: copystat(src, dst, follow_symlinks=True) Copy the permission bits, last access time, last modification time, and flags from *src* to *dst*. The file contents, owner, and group are unaffected. *src* and *dst* are path names given as strings. If *src* and *dst* are both - symbolic links and *symlinks* true, the stats of the link will be copied as + symbolic links and *follow_symlinks* false, the stats of the link will be copied as far as the platform allows. .. versionchanged:: 3.3 - Added *symlinks* argument. + Added *follow_symlinks* argument. -.. function:: copy(src, dst, symlinks=False)) +.. function:: copy(src, dst, follow_symlinks=True)) Copy the file *src* to the file or directory *dst* and return the file's destination. If *dst* is a directory, a file with the same basename as *src* is created (or overwritten) in the directory specified. Permission bits are copied. *src* and *dst* are path - names given as strings. If *symlinks* is true, symbolic links won't be + names given as strings. If *follow_symlinks* is false, symbolic links won't be followed but recreated instead -- this resembles GNU's :program:`cp -P`. .. versionchanged:: 3.3 - Added *symlinks* argument. + Added *follow_symlinks* argument. .. versionchanged:: 3.3 Added return of the *dst*. -.. function:: copy2(src, dst, symlinks=False) +.. function:: copy2(src, dst, follow_symlinks=False) Similar to :func:`shutil.copy`, including that the destination is returned, but metadata is copied as well. This is - similar to the Unix command :program:`cp -p`. If *symlinks* is true, + similar to the Unix command :program:`cp -p`. If *follow_symlinks* is false, symbolic links won't be followed but recreated instead -- this resembles GNU's :program:`cp -P`. .. versionchanged:: 3.3 - Added *symlinks* argument, try to copy extended file system attributes + Added *follow_symlinks* argument, try to copy extended file system attributes too (currently Linux only). .. versionchanged:: 3.3 @@ -128,7 +128,9 @@ match one of the glob-style *patterns* provided. See the example below. -.. function:: copytree(src, dst, symlinks=False, ignore=None, copy_function=copy2, ignore_dangling_symlinks=False) +.. function:: copytree(src, dst, symlinks=False, ignore=None, + copy_function=copy2, ignore_dangling_symlinks=False, *, + follow_symlinks=True) Recursively copy an entire directory tree rooted at *src*, returning the destination directory. The destination @@ -137,12 +139,14 @@ are copied with :func:`copystat`, individual files are copied using :func:`shutil.copy2`. - If *symlinks* is true, symbolic links in the source tree are represented as + If *follow_symlinks* is false or *symlinks* is true, + symbolic links in the source tree are represented as symbolic links in the new tree and the metadata of the original links will be copied as far as the platform allows; if false or omitted, the contents and metadata of the linked files are copied to the new tree. - When *symlinks* is false, if the file pointed by the symlink doesn't + When *follow_symlinks* is true or *symlinks* is false, + if the file pointed by the symlink doesn't exist, a exception will be added in the list of errors raised in a :exc:`Error` exception at the end of the copy process. You can set the optional *ignore_dangling_symlinks* flag to true if you @@ -172,10 +176,13 @@ .. versionchanged:: 3.2 Added the *ignore_dangling_symlinks* argument to silent dangling symlinks - errors when *symlinks* is false. + errors when *follow_symlinks* is true or *symlinks* is false. .. versionchanged:: 3.3 - Copy metadata when *symlinks* is false. + Copy metadata when *follow_symlinks* is true or *symlinks* is false. + + .. versionchanged:: 3.3 + Added *follow_symlinks* argument with opposite meaning to *symlinks*. .. versionchanged:: 3.3 Added return of the *dst*. diff -r b66e82c9f852 Lib/shutil.py --- a/Lib/shutil.py Tue Jun 26 23:05:27 2012 +0200 +++ b/Lib/shutil.py Thu Jun 28 00:00:38 2012 +0300 @@ -82,10 +82,10 @@ return (os.path.normcase(os.path.abspath(src)) == os.path.normcase(os.path.abspath(dst))) -def copyfile(src, dst, symlinks=False): +def copyfile(src, dst, follow_symlinks=True): """Copy data from src to dst. - If optional flag `symlinks` is set and `src` is a symbolic link, a new + If optional flag `follow_symlinks` is not set and `src` is a symbolic link, a new symlink will be created instead of copying the file it points to. """ @@ -103,7 +103,7 @@ if stat.S_ISFIFO(st.st_mode): raise SpecialFileError("`%s` is a named pipe" % fn) - if symlinks and os.path.islink(src): + if not follow_symlinks and os.path.islink(src): os.symlink(os.readlink(src), dst) else: with open(src, 'rb') as fsrc: @@ -111,15 +111,15 @@ copyfileobj(fsrc, fdst) return dst -def copymode(src, dst, symlinks=False): +def copymode(src, dst, follow_symlinks=True): """Copy mode bits from src to dst. - If the optional flag `symlinks` is set, symlinks aren't followed if and + If the optional flag `follow_symlinks` is not set, symlinks aren't followed if and only if both `src` and `dst` are symlinks. If `lchmod` isn't available (eg. Linux), in these cases, this method does nothing. """ - if symlinks and os.path.islink(src) and os.path.islink(dst): + if not follow_symlinks and os.path.islink(src) and os.path.islink(dst): if hasattr(os, 'lchmod'): stat_func, chmod_func = os.lstat, os.lchmod else: @@ -132,10 +132,10 @@ st = stat_func(src) chmod_func(dst, stat.S_IMODE(st.st_mode)) -def copystat(src, dst, symlinks=False): +def copystat(src, dst, follow_symlinks=True): """Copy all stat info (mode bits, atime, mtime, flags) from src to dst. - If the optional flag `symlinks` is set, symlinks aren't followed if and + If the optional flag `follow_symlinks` is not set, symlinks aren't followed if and only if both `src` and `dst` are symlinks. """ @@ -143,7 +143,7 @@ pass # follow symlinks (aka don't not follow symlinks) - follow = not (symlinks and os.path.islink(src) and os.path.islink(dst)) + follow = follow_symlinks or not (os.path.islink(src) and os.path.islink(dst)) if follow: # use the real function if it exists def lookup(name): @@ -186,19 +186,19 @@ raise if hasattr(os, 'listxattr'): - def _copyxattr(src, dst, symlinks=False): + def _copyxattr(src, dst, follow_symlinks=True): """Copy extended filesystem attributes from `src` to `dst`. Overwrite existing attributes. - If the optional flag `symlinks` is set, symlinks won't be followed. + If the optional flag `follow_symlinks` is not set, symlinks won't be followed. """ - for name in os.listxattr(src, follow_symlinks=symlinks): + for name in os.listxattr(src, follow_symlinks=follow_symlinks): try: - value = os.getxattr(src, name, follow_symlinks=symlinks) - os.setxattr(dst, name, value, follow_symlinks=symlinks) + value = os.getxattr(src, name, follow_symlinks=follow_symlinks) + os.setxattr(dst, name, value, follow_symlinks=follow_symlinks) except OSError as e: if e.errno not in (errno.EPERM, errno.ENOTSUP, errno.ENODATA): raise @@ -206,36 +206,36 @@ def _copyxattr(*args, **kwargs): pass -def copy(src, dst, symlinks=False): +def copy(src, dst, follow_symlinks=True): """Copy data and mode bits ("cp src dst"). Return the file's destination. The destination may be a directory. - If the optional flag `symlinks` is set, symlinks won't be followed. This + If the optional flag `follow_symlinks` is not set, symlinks won't be followed. This resembles GNU's "cp -P src dst". """ if os.path.isdir(dst): dst = os.path.join(dst, os.path.basename(src)) - copyfile(src, dst, symlinks=symlinks) - copymode(src, dst, symlinks=symlinks) + copyfile(src, dst, follow_symlinks=follow_symlinks) + copymode(src, dst, follow_symlinks=follow_symlinks) return dst -def copy2(src, dst, symlinks=False): +def copy2(src, dst, follow_symlinks=True): """Copy data and all stat info ("cp -p src dst"). Return the file's destination." The destination may be a directory. - If the optional flag `symlinks` is set, symlinks won't be followed. This + If the optional flag `follow_symlinks` is set, symlinks won't be followed. This resembles GNU's "cp -P src dst". """ if os.path.isdir(dst): dst = os.path.join(dst, os.path.basename(src)) - copyfile(src, dst, symlinks=symlinks) - copystat(src, dst, symlinks=symlinks) - _copyxattr(src, dst, symlinks=symlinks) + copyfile(src, dst, follow_symlinks=follow_symlinks) + copystat(src, dst, follow_symlinks=follow_symlinks) + _copyxattr(src, dst, follow_symlinks=follow_symlinks) return dst def ignore_patterns(*patterns): @@ -250,8 +250,10 @@ return set(ignored_names) return _ignore_patterns -def copytree(src, dst, symlinks=False, ignore=None, copy_function=copy2, - ignore_dangling_symlinks=False): +_sentry = object() + +def copytree(src, dst, symlinks=_sentry, ignore=None, copy_function=copy2, + ignore_dangling_symlinks=False, *, follow_symlinks=_sentry): """Recursively copy a directory tree. The destination directory must not already exist. @@ -286,6 +288,15 @@ function that supports the same signature (like copy()) can be used. """ + if symlinks is _sentry: + if follow_symlinks is _sentry: + symlinks = False + else: + symlinks = not follow_symlinks + elif follow_symlinks is not _sentry: + raise ValueError( + "'follow_symlinks' and 'symlinks' arguments are incompatible") + names = os.listdir(src) if ignore is not None: ignored_names = ignore(src, names) @@ -307,7 +318,7 @@ # code with a custom `copy_function` may rely on copytree # doing the right thing. os.symlink(linkto, dstname) - copystat(srcname, dstname, symlinks=symlinks) + copystat(srcname, dstname, follow_symlinks=not symlinks) else: # ignore dangling symlink if the flag is on if not os.path.exists(linkto) and ignore_dangling_symlinks: diff -r b66e82c9f852 Lib/test/test_shutil.py --- a/Lib/test/test_shutil.py Tue Jun 26 23:05:27 2012 +0200 +++ b/Lib/test/test_shutil.py Thu Jun 28 00:00:38 2012 +0300 @@ -245,17 +245,17 @@ os.lchmod(src_link, stat.S_IRWXO|stat.S_IRWXG) # link to link os.lchmod(dst_link, stat.S_IRWXO) - shutil.copymode(src_link, dst_link, symlinks=True) + shutil.copymode(src_link, dst_link, follow_symlinks=False) self.assertEqual(os.lstat(src_link).st_mode, os.lstat(dst_link).st_mode) self.assertNotEqual(os.stat(src).st_mode, os.stat(dst).st_mode) # src link - use chmod os.lchmod(dst_link, stat.S_IRWXO) - shutil.copymode(src_link, dst, symlinks=True) + shutil.copymode(src_link, dst, follow_symlinks=False) self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode) # dst link - use chmod os.lchmod(dst_link, stat.S_IRWXO) - shutil.copymode(src, dst_link, symlinks=True) + shutil.copymode(src, dst_link, follow_symlinks=False) self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode) @unittest.skipIf(hasattr(os, 'lchmod'), 'requires os.lchmod to be missing') @@ -270,7 +270,7 @@ write_file(dst, 'foo') os.symlink(src, src_link) os.symlink(dst, dst_link) - shutil.copymode(src_link, dst_link, symlinks=True) # silent fail + shutil.copymode(src_link, dst_link, follow_symlinks=False) # silent fail @support.skip_unless_symlink def test_copystat_symlinks(self): @@ -294,10 +294,10 @@ src_link_stat = os.lstat(src_link) # follow if hasattr(os, 'lchmod'): - shutil.copystat(src_link, dst_link, symlinks=False) + shutil.copystat(src_link, dst_link, follow_symlinks=True) self.assertNotEqual(src_link_stat.st_mode, os.stat(dst).st_mode) # don't follow - shutil.copystat(src_link, dst_link, symlinks=True) + shutil.copystat(src_link, dst_link, follow_symlinks=False) dst_link_stat = os.lstat(dst_link) if os.utime in os.supports_follow_symlinks: for attr in 'st_atime', 'st_mtime': @@ -309,7 +309,7 @@ if hasattr(os, 'lchflags') and hasattr(src_link_stat, 'st_flags'): self.assertEqual(src_link_stat.st_flags, dst_link_stat.st_flags) # tell to follow but dst is not a link - shutil.copystat(src_link, dst, symlinks=True) + shutil.copystat(src_link, dst, follow_symlinks=False) self.assertTrue(abs(os.stat(src).st_mtime - os.stat(dst).st_mtime) < 00000.1) @@ -397,10 +397,10 @@ dst_link = os.path.join(tmp_dir, 'qux') write_file(dst, 'bar') os.symlink(dst, dst_link) - shutil._copyxattr(src_link, dst_link, symlinks=True) + shutil._copyxattr(src_link, dst_link, follow_symlinks=False) self.assertEqual(os.getxattr(dst_link, 'trusted.foo', follow_symlinks=False), b'43') self.assertRaises(OSError, os.getxattr, dst, 'trusted.foo') - shutil._copyxattr(src_link, dst, symlinks=True) + shutil._copyxattr(src_link, dst, follow_symlinks=False) self.assertEqual(os.getxattr(dst, 'trusted.foo'), b'43') @support.skip_unless_symlink @@ -414,12 +414,12 @@ if hasattr(os, 'lchmod'): os.lchmod(src_link, stat.S_IRWXU | stat.S_IRWXO) # don't follow - shutil.copy(src_link, dst, symlinks=False) + shutil.copy(src_link, dst, follow_symlinks=True) self.assertFalse(os.path.islink(dst)) self.assertEqual(read_file(src), read_file(dst)) os.remove(dst) # follow - shutil.copy(src_link, dst, symlinks=True) + shutil.copy(src_link, dst, follow_symlinks=False) self.assertTrue(os.path.islink(dst)) self.assertEqual(os.readlink(dst), os.readlink(src_link)) if hasattr(os, 'lchmod'): @@ -441,12 +441,12 @@ src_stat = os.stat(src) src_link_stat = os.lstat(src_link) # follow - shutil.copy2(src_link, dst, symlinks=False) + shutil.copy2(src_link, dst, follow_symlinks=True) self.assertFalse(os.path.islink(dst)) self.assertEqual(read_file(src), read_file(dst)) os.remove(dst) # don't follow - shutil.copy2(src_link, dst, symlinks=True) + shutil.copy2(src_link, dst, follow_symlinks=False) self.assertTrue(os.path.islink(dst)) self.assertEqual(os.readlink(dst), os.readlink(src_link)) dst_stat = os.lstat(dst) @@ -484,7 +484,7 @@ write_file(src, 'foo') os.symlink(src, link) # don't follow - shutil.copyfile(link, dst_link, symlinks=True) + shutil.copyfile(link, dst_link, follow_symlinks=False) self.assertTrue(os.path.islink(dst_link)) self.assertEqual(os.readlink(link), os.readlink(dst_link)) # follow @@ -555,6 +555,33 @@ if hasattr(os, 'lchflags') and hasattr(stat, 'UF_NODUMP'): os.lchflags(src_link, stat.UF_NODUMP) src_stat = os.lstat(src_link) + shutil.copytree(src_dir, dst_dir, follow_symlinks=False) + self.assertTrue(os.path.islink(os.path.join(dst_dir, 'sub', 'link'))) + self.assertEqual(os.readlink(os.path.join(dst_dir, 'sub', 'link')), + os.path.join(src_dir, 'file.txt')) + dst_stat = os.lstat(dst_link) + if hasattr(os, 'lchmod'): + self.assertEqual(dst_stat.st_mode, src_stat.st_mode) + if hasattr(os, 'lchflags'): + self.assertEqual(dst_stat.st_flags, src_stat.st_flags) + + def test_copytree_symlinks_old(self): + tmp_dir = self.mkdtemp() + src_dir = os.path.join(tmp_dir, 'src') + dst_dir = os.path.join(tmp_dir, 'dst') + sub_dir = os.path.join(src_dir, 'sub') + os.mkdir(src_dir) + os.mkdir(sub_dir) + write_file((src_dir, 'file.txt'), 'foo') + src_link = os.path.join(sub_dir, 'link') + dst_link = os.path.join(dst_dir, 'sub/link') + os.symlink(os.path.join(src_dir, 'file.txt'), + src_link) + if hasattr(os, 'lchmod'): + os.lchmod(src_link, stat.S_IRWXU | stat.S_IRWXO) + if hasattr(os, 'lchflags') and hasattr(stat, 'UF_NODUMP'): + os.lchflags(src_link, stat.UF_NODUMP) + src_stat = os.lstat(src_link) shutil.copytree(src_dir, dst_dir, symlinks=True) self.assertTrue(os.path.islink(os.path.join(dst_dir, 'sub', 'link'))) self.assertEqual(os.readlink(os.path.join(dst_dir, 'sub', 'link')), @@ -565,6 +592,15 @@ if hasattr(os, 'lchflags'): self.assertEqual(dst_stat.st_flags, src_stat.st_flags) + def test_copytree_incompatible_args(self): + tmp_dir = self.mkdtemp() + src_dir = os.path.join(tmp_dir, 'src') + dst_dir = os.path.join(tmp_dir, 'dst') + sub_dir = os.path.join(src_dir, 'sub') + os.mkdir(src_dir) + os.mkdir(sub_dir) + self.assertRaises(ValueError, shutil.copytree, src_dir, dst_dir, symlinks=True, follow_symlinks=False) + def test_copytree_with_exclude(self): # creating data join = os.path.join @@ -748,9 +784,9 @@ shutil.copytree(src_dir, dst_dir, ignore_dangling_symlinks=True) self.assertNotIn('test.txt', os.listdir(dst_dir)) - # a dangling symlink is copied if symlinks=True + # a dangling symlink is copied if follow_symlinks=False dst_dir = os.path.join(self.mkdtemp(), 'destination3') - shutil.copytree(src_dir, dst_dir, symlinks=True) + shutil.copytree(src_dir, dst_dir, follow_symlinks=False) self.assertIn('test.txt', os.listdir(dst_dir)) def _copy_file(self, method): From report at bugs.python.org Wed Jun 27 23:07:13 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 21:07:13 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340831233.53.0.535930774122.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Oops, last attachment included the source timestamp twice instead of timestamp + bytecode size. ---------- Added file: http://bugs.python.org/file26188/cpython-issue-15030.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 23:08:48 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Wed, 27 Jun 2012 21:08:48 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340831328.62.0.774557562076.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Oops. Refactor. :-) ---------- Added file: http://bugs.python.org/file26189/cpython-issue-15030.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Wed Jun 27 23:11:27 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Jun 2012 21:11:27 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340831487.44.0.474109149569.issue15206@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: IMHO it's all about managing expectations. As libuuid is using a crypto RNG before it falls back to a less suitable RNG. We should follow this example. I couldn't find any information about the implementation details of Window's UuidCreate(). I agree that we can disagree on my reasoning. However the usage of random.random() and random.randint() in uuid is flawed for a second reason. The default instance random._inst doesn't compensate for fork(). After fork() the two processes share the same random state and thus will create the same uuids. For example tempfile._RandomNameSequence re-creates the RNG when it notices a different PID. ---------- keywords: +patch Added file: http://bugs.python.org/file26190/issue15206.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Wed Jun 27 23:19:36 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 21:19:36 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340831976.75.0.358667609287.issue15209@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Wed Jun 27 23:20:11 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 Jun 2012 21:20:11 +0000 Subject: [issue15210] importlib.__init__ checks for the wrong exception when looking for _frozen_importlib In-Reply-To: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za> Message-ID: <1340832011.36.0.497377650846.issue15210@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15210> _______________________________________ From report at bugs.python.org Wed Jun 27 23:28:17 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 27 Jun 2012 21:28:17 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340831976.77.0.625442955023.issue15209@psf.upfronthosting.co.za> Message-ID: <CADiSq7f=pjYCxxbkvjO8V7UPaMA1D7JeR_jucwpexJS2BQ2xWQ@mail.gmail.com> Nick Coghlan <ncoghlan at gmail.com> added the comment: The from clause is intended for replacing previous exceptions with *new* exceptions, not editing the attributes of existing ones which may already have a different __cause__ set. So - 1 from me, even for 3.4. A patch to the docs explaining that this is not supported syntactically because it risks losing debugging data would be fine, though. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Wed Jun 27 23:36:33 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 27 Jun 2012 21:36:33 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340832993.17.0.414457616208.issue15209@psf.upfronthosting.co.za> Ethan Furman <ethan at stoneleaf.us> added the comment: Okay, I see your point. It's also not difficult to work around if you really want to toss the extra info: except NameError: try: fallback_module.getch() except Exception as exc: raise exc from None A total of three more words to get the desired behavior (and small ones at that). I'll work on a doc patch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 00:20:12 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 27 Jun 2012 22:20:12 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340835612.57.0.306236807074.issue15209@psf.upfronthosting.co.za> Ethan Furman <ethan at stoneleaf.us> added the comment: Patch attached. It basically says: 8<-------------------------------------------------------------------- Note: Because using :keyword:`from` can throw away valuable debugging information, its use with a bare :keyword:`raise` is not supported. If you are trying to do this: try: some_module.not_here() except NameError: try: backup_module.not_here() except NameError: raise from None # suppress context in NameError do this instead: try: some_module.not_here() except NameError: try: backup_module.not_here() except NameError as exc: raise exc from None # suppress context in NameError 8<-------------------------------------------------------------------- ---------- keywords: +patch Added file: http://bugs.python.org/file26191/raise_from_doc_update.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 00:22:11 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 27 Jun 2012 22:22:11 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340835731.85.0.692620040657.issue15206@psf.upfronthosting.co.za> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment: Are uuid's promised to be cryptographically secure? ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 00:27:45 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 27 Jun 2012 22:27:45 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <CADiSq7f=pjYCxxbkvjO8V7UPaMA1D7JeR_jucwpexJS2BQ2xWQ@mail.gmail.com> Message-ID: <4FEB8BE1.1060509@stoneleaf.us> Ethan Furman <ethan at stoneleaf.us> added the comment: Nick Coghlan wrote: > The from clause is intended for replacing previous exceptions with *new* > exceptions, not editing the attributes of existing ones which may already > have a different __cause__ set. Huh. While I agree with the doc patch solution, I think the most common use of 'from' will be 'raise SomeException from None' or, as the patch suggests, 'raise exc from None' (exc being an already existing exception). Any examples of when somebody might do: try: do_something() except NameError: raise NewError from SomeOtherError ? I am unsure of the advantages in replacing NameError in the above stack trace with SomeOtherError instead... although NameError would still be there in __context__... Still, any examples? ~Ethan~ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 00:38:28 2012 From: report at bugs.python.org (pmoody) Date: Wed, 27 Jun 2012 22:38:28 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340836708.24.0.320208270367.issue14814@psf.upfronthosting.co.za> pmoody <python at hda3.com> added the comment: Hynek, I don't see that error when I run the tests on a freshly built python. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Thu Jun 28 00:44:19 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Jun 2012 22:44:19 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340837059.52.0.275339130516.issue15206@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Not, not by definition. However an uuid generator shall geenerate uuid in a way that make collisions highly improbable. IMHO this verdict implies that an uuid generator should use the cryptographic RNG if available. The behavior after fork() is clearly a bug as it will generate lots of collisions on systems that fall back to random. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 01:25:38 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 27 Jun 2012 23:25:38 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340839538.95.0.477475728545.issue15206@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: > However a MT isn't suitable for cryptographic purposes. > The module should first try to use os.urandom() and > then perhaps use its own instance of random.Random, > similar to uuid_generate_* [1] os.urandom() is not suitable for cryptographic purposes :-) Python 3.3 has also ssl.RAND_bytes() which is better than os.urandom(), but it's not possible (easy?) to build a custom random.Random class with an arbitrary RNG (like os.urandom or ssl.RAND_bytes). It would be nice to provide an API to choose the best RNG depending on a set of requirements. I wrote the Hasard library which implements such idea: the library provides "profiles" and chooses the best RNG for a profile. Profiles: - fast - secure nonblocking - secure blocking - hardware See the doc directory the Hasard project for details: https://bitbucket.org/haypo/hasard/ https://bitbucket.org/haypo/hasard/src/82d13450c552/doc/profile_list.rst See also the issue #12858 for another user of a better RNG. I'm quite sure that all these RNG issues are a good candidate for a PEP because RNG is complex problem, there are different use cases, various implements, and a lot of common issue (in RNG implementations). Handling fork or not is an important question, which impact performances, for example. See also the issue #12754: "Add alternative random number generators". ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 01:29:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 27 Jun 2012 23:29:29 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340839769.89.0.355134147182.issue15206@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: >From the /dev/urandom Linux man page: If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys. If a seed file is saved across reboots as recommended below (all major Linux distributions have done this since 2000 at least), the output is cryptographically secure against attackers without local root access as soon as it is reloaded in the boot sequence, and perfectly adequate for network encryption session keys. So, yes, /dev/urandom is suitable for most cryptographic purposes (except long-lived private keys). ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 01:38:29 2012 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Jun 2012 23:38:29 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340840309.19.0.624669030294.issue15206@psf.upfronthosting.co.za> Christian Heimes <lists at cheimes.de> added the comment: Antoine beat me to it and he is totally right. Please don't derail this bug report. I agree with your analysis that the RNG core of random.Random subclass can't be replaced easily and that more implementations for different purposes would be great. You should stick the analysis into a different ticket or write a PEP. This ticket is the wrong place. I'll support you if you keep the ticket on course. ;) Let's concentrate on the topic at hand and discuss if a) my patch handles the fork() issue correctly b) if it's a good idea to try SystemRandom first c) a backport to 2.6, 2.7, 3.1 and 3.2 is required and perhaps d) if I should open another ticket to work on a general solution for the RNG + fork() issue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 02:11:58 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 00:11:58 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340842318.69.0.233084380387.issue15209@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: The purpose of the from clause in general is to change the exception *type* (for example, from KeyError -> AttributeError or vice-versa), or to add additional information without losing access to any previous information (like the original traceback). This is covered in PEP 3134. In some cases, the appropriate way to convey the information is to copy relevant details to the new exception, leave the context set, and suppress display of that context by default. In other cases, the developer may want to display the chained exception explicitly, because it *isn't* part of the current exception handling context (e.g. this is quite likely in an event loop scheduler that passes exception information between events - the __cause__ chain would track the *event stack* rather than the Python call stack). Thus, in the recommended use for the "raise X from Y" syntax, you're always setting __cause__ on a *new* exception, so you know you're not overwriting a preexisting __cause__ and thus there's no risk of losing information that might be relevant for debugging the failure. When you use "raise X from Y" directly on a *pre-existing* exception (however you managed to get hold of it), there's a chance that __cause__ is already set. If you blindly overwrite it, then you've deleted part of the exception chain that PEP 3134 is designed to preserve. This is also why Guido and I were so adamant that just setting __context__ to None was not an acceptable solution for PEP 409 - the whole point of PEP 3144 is to make it difficult to accidentally lose the full details of the traceback even if some of the exception handlers in the stack are written by developers that don't have much experience in debugging other people's code. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 02:41:13 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 28 Jun 2012 00:41:13 +0000 Subject: [issue15212] Rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT in compiler module Message-ID: <1340844073.78.0.438515570461.issue15212@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: Revision 4809afa85a9b introduced a typo in compiler module: SC_GLOBAL_EXPLICT instead of SC_GLOBAL_EXPLICIT The attached patch fixes this typo. ---------- components: Library (Lib) files: compiler-SC_GLOBAL_EXPLICIT.patch keywords: easy, patch messages: 164215 nosy: Arfrever priority: normal severity: normal stage: patch review status: open title: Rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT in compiler module versions: Python 2.7 Added file: http://bugs.python.org/file26192/compiler-SC_GLOBAL_EXPLICIT.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15212> _______________________________________ From report at bugs.python.org Thu Jun 28 02:42:58 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 28 Jun 2012 00:42:58 +0000 Subject: [issue15212] Rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT in compiler module In-Reply-To: <1340844073.78.0.438515570461.issue15212@psf.upfronthosting.co.za> Message-ID: <1340844178.01.0.856563369354.issue15212@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +nascheme _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15212> _______________________________________ From report at bugs.python.org Thu Jun 28 02:46:09 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Jun 2012 00:46:09 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1340844369.41.0.55095615737.issue6422@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: Hi, I wrote recently a similar function because timeit is not reliable by default. Results look random and require to run the same benchmark 3 times or more on the command line. https://bitbucket.org/haypo/misc/src/tip/python/benchmark.py By default, the benchmark takes at least 5 measures, one measure should be greater than 100 ms, and the benchmark should not be longer than 1 second. I chose these parameters to get reliable results on microbenchmarks like "abc".encode("utf-8"). The calibration function uses also the precision of the timer. The user may define a minimum time (of one measure) smaller than the timer precision, so the calibration function tries to solve such issue. The calibration computes the number of loops and the number of repetitions. Look at BenchmarkRunner.calibrate_timer() and BenchmarkRunner.run_benchmark(). https://bitbucket.org/haypo/misc/src/bfacfb9a1224/python/benchmark.py#cl-362 ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6422> _______________________________________ From report at bugs.python.org Thu Jun 28 02:55:26 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 28 Jun 2012 00:55:26 +0000 Subject: [issue6422] timeit called from within Python should allow autoranging In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za> Message-ID: <1340844926.12.0.0769003095302.issue6422@psf.upfronthosting.co.za> STINNER Victor <victor.stinner at gmail.com> added the comment: > The calibration function uses also the precision of the timer. Oh, I forgot to mention that it computes the precision in Python, it doesn't read the precision announced by the OS or the precision of the C structure. https://bitbucket.org/haypo/misc/src/bfacfb9a1224/python/benchmark.py#cl-66 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6422> _______________________________________ From report at bugs.python.org Thu Jun 28 02:57:03 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 28 Jun 2012 00:57:03 +0000 Subject: [issue15213] _PyOS_URandom documentation Message-ID: <1340845023.83.0.143337072725.issue15213@psf.upfronthosting.co.za> New submission from Christian Heimes <lists at cheimes.de>: The comment for Python/random.c:_PyOS_URandom() states > Fill buffer with size pseudo-random bytes, not suitable for cryptographic use, from the operating random number generator (RNG). which is not correct as all paths use a RNG that is suitable for most cryptographic purposes except long living private keys for asymmetric encryption. Also the function isn't documented although it's an official API function and plays a vital role on the new hash randomization. ---------- assignee: docs at python components: Documentation messages: 164218 nosy: christian.heimes, docs at python, haypo, pitrou priority: low severity: normal status: open title: _PyOS_URandom documentation versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15213> _______________________________________ From report at bugs.python.org Thu Jun 28 05:44:53 2012 From: report at bugs.python.org (Isaac) Date: Thu, 28 Jun 2012 03:44:53 +0000 Subject: [issue15214] list.startswith() and list.remove() fails to catch consecutive items in a list. Message-ID: <1340855093.79.0.494705749272.issue15214@psf.upfronthosting.co.za> New submission from Isaac <isaacloves2run at yahoo.com>: The simple repro below, shows that if a list of strings has two consecutive items that begin with the same letter, an iteration over the list to find and remove all strings that start with that letter fails. The second string that starts with the same letter to remove remains in the list. In the example below, both "bananna" and "blueberry" should be removed from the list, but only "bananna" is removed. I verified this on both 2.7 and 3.2. ----------------------------------------------------- --- Output --- -------------- Before: ['apple', 'bananna', 'blueberry', 'coconut'] After: ['apple', 'blueberry', 'coconut'] ----------------------------------------------------- --- Repro --- ------------- itemList = ["apple", "bananna", "blueberry", "coconut"] print("Before: {0}".format(itemList)) for item in itemList: if(item.startswith("b")): itemList.remove(item) print("After: {0}".format(itemList)) ---------- files: listRemovalBug.py messages: 164219 nosy: Eklutna priority: normal severity: normal status: open title: list.startswith() and list.remove() fails to catch consecutive items in a list. type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file26193/listRemovalBug.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15214> _______________________________________ From report at bugs.python.org Thu Jun 28 07:06:27 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 28 Jun 2012 05:06:27 +0000 Subject: [issue15214] list.startswith() and list.remove() fails to catch consecutive items in a list. In-Reply-To: <1340855093.79.0.494705749272.issue15214@psf.upfronthosting.co.za> Message-ID: <1340859987.88.0.0830426556627.issue15214@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: This happens because you modify the list while iterating over it, which makes the loop not work as you expect. Essentially, when you remove the item that's currently being pointed to, the loop skips over the next item. An idiomatic way to remove items from a list is to use a list comprehension to create a new list without the unwanted items: item_list = ["apple", "bananna", "blueberry", "coconut"] new_list = [item for item in item_list if not item.startswith('b')] ---------- nosy: +petri.lehtinen resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15214> _______________________________________ From report at bugs.python.org Thu Jun 28 07:54:52 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 28 Jun 2012 05:54:52 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340840309.19.0.624669030294.issue15206@psf.upfronthosting.co.za> Message-ID: <20120628075449.Horde.nsEAfUlCcOxP6-Gp3T3WMyA@webmail.df.eu> Martin v. L?wis <martin at v.loewis.de> added the comment: > a) my patch handles the fork() issue correctly If the system has urandom, yes. > b) if it's a good idea to try SystemRandom first Certainly. > c) a backport to 2.6, 2.7, 3.1 and 3.2 is required > and perhaps Cannot backport to 2.6 and 3.1; it's not a security issue. > d) if I should open another ticket to work on a general solution for > the RNG + fork() issue. I'm not quite sure what a solution could be, or wether there is an issue in the first place, so -0. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 07:55:35 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 28 Jun 2012 05:55:35 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340862935.18.0.476979151256.issue15206@psf.upfronthosting.co.za> Changes by Martin v. L?wis <martin at v.loewis.de>: ---------- versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 08:27:42 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 28 Jun 2012 06:27:42 +0000 Subject: [issue15213] _PyOS_URandom documentation In-Reply-To: <1340845023.83.0.143337072725.issue15213@psf.upfronthosting.co.za> Message-ID: <1340864862.4.0.456609795796.issue15213@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: It's not an official API, as the leading underscore specifies. Changing the comment sounds fine to me. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15213> _______________________________________ From report at bugs.python.org Thu Jun 28 09:08:17 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 07:08:17 +0000 Subject: [issue15203] Accepting of os functions of (path, dir_fd) pair as argument In-Reply-To: <1340789239.97.0.934534609374.issue15203@psf.upfronthosting.co.za> Message-ID: <1340867297.0.0.76474105178.issue15203@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Correctly avoiding symlink attacks, which is the whole reason the POSIX *at variants and the dir_fd parameters were added, is not trivial in general. os.fwalk and shutil.rmtree went through many iterations before reaching a state where they should successfully avoid the problem. Simply passing a (path, dir_fd) 2-tuple instead of a string and calling it done is highly unlikely to produce a secure result, thus rather missing the point of the exercise. ---------- nosy: +ncoghlan resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15203> _______________________________________ From report at bugs.python.org Thu Jun 28 09:13:02 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 07:13:02 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1340867582.97.0.841391837597.issue7475@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: My current opinion is that this should be a PEP for 3.4, to make sure we flush out all the corner cases and other details correctly. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7475> _______________________________________ From report at bugs.python.org Thu Jun 28 09:26:19 2012 From: report at bugs.python.org (Frank Ling) Date: Thu, 28 Jun 2012 07:26:19 +0000 Subject: [issue15215] socket module setblocking and settimeout problem Message-ID: <1340868379.68.0.473827205648.issue15215@psf.upfronthosting.co.za> New submission from Frank Ling <ufwtlsb at gmail.com>: i use socket such as : self.socket.setblocking(1) self.socket.settimeout(1) but this socket is no-block ,i find socketmodule.c sock_settimeout s->sock_timeout = timeout; internal_setblocking(s, timeout < 0.0); if timeout >0, so internal_setblocking(s,false=0),so socket is no-block by the way: in sock_settimeout,call internal_setblocking params have error? init_sockobject: if (defaulttimeout >= 0.0) internal_setblocking(s, 0); ---------- messages: 164225 nosy: Frank.Ling priority: normal severity: normal status: open title: socket module setblocking and settimeout problem type: behavior versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15215> _______________________________________ From report at bugs.python.org Thu Jun 28 09:26:32 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 07:26:32 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1340868392.93.0.181468773374.issue7475@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: For that matter, with the relevant codecs restored in 3.2, a transform() helper could probably be added to six (or a new project on PyPI) to prototype the approach. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7475> _______________________________________ From report at bugs.python.org Thu Jun 28 09:45:57 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 28 Jun 2012 07:45:57 +0000 Subject: [issue11959] smtpd cannot be used without affecting global state In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za> Message-ID: <1340869557.86.0.651137127828.issue11959@psf.upfronthosting.co.za> Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11959> _______________________________________ From report at bugs.python.org Thu Jun 28 10:25:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 08:25:12 +0000 Subject: [issue15202] followlinks/follow_symlinks/symlinks flags unification In-Reply-To: <1340810611.7.0.212703457825.issue15202@psf.upfronthosting.co.za> Message-ID: <1340871903.2462.85.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: Here is updated patches. The type of exception thrown when specifying mutually exclusive arguments changed from ValueError to TypeError (in accordance with the raised in similar conflicts exceptions). Slightly modified documentation. Taken into account some of Larry's comments. Only os.walk had followlinks and shutil.copytree had symlinks before 3.3. So these are the only functions preserved the old arguments. os.fwalk and another five public functions from shutil got a new argument only in 3.3, for them it just renamed (may be to make them keyword-only?). Larry worrying, isn't it too late? But it would be strange to have in 3.3 new and immediately obsolete arguments. Moreover the support for the two arguments complicate and slow down the code. If you postpone it to 3.4, there will not be another solution, but now we can do less mess. ---------- Added file: http://bugs.python.org/file26194/followlinks-to-follow_symlinks-2.patch Added file: http://bugs.python.org/file26195/symlinks-to-follow_symlinks-2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15202> _______________________________________ -------------- next part -------------- diff -r d0f775432705 Doc/library/os.rst --- a/Doc/library/os.rst Thu Jun 28 01:45:48 2012 +0200 +++ b/Doc/library/os.rst Thu Jun 28 11:02:52 2012 +0300 @@ -2128,7 +2128,8 @@ and the *dir_fd*, *follow_symlinks*, and *ns* parameters. -.. function:: walk(top, topdown=True, onerror=None, followlinks=False) +.. function:: walk(top, topdown=True, onerror=None, followlinks=False, *, + follow_symlinks=False) .. index:: single: directory; walking @@ -2168,12 +2169,12 @@ is available as the ``filename`` attribute of the exception object. By default, :func:`walk` will not walk down into symbolic links that resolve to - directories. Set *followlinks* to ``True`` to visit directories pointed to by + directories. Set *follow_symlinks* to ``True`` to visit directories pointed to by symlinks, on systems that support them. .. note:: - Be aware that setting *followlinks* to ``True`` can lead to infinite + Be aware that setting *follow_symlinks* to ``True`` can lead to infinite recursion if a link points to a parent directory of itself. :func:`walk` does not keep track of the directories it visited already. @@ -2210,8 +2211,13 @@ for name in dirs: os.rmdir(os.path.join(root, name)) - -.. function:: fwalk(top='.', topdown=True, onerror=None, followlinks=False, *, dir_fd=None) + .. versionchanged:: 3.3 + Added *follow_symlinks* as alias to *followlinks*. *followlinks* should + not be used in new code. A :exc:`TypeError` is raised if both + *followlinks* and *follow_symlinks* are specified. + + +.. function:: fwalk(top='.', topdown=True, onerror=None, follow_symlinks=False, *, dir_fd=None) .. index:: single: directory; walking diff -r d0f775432705 Lib/os.py --- a/Lib/os.py Thu Jun 28 01:45:48 2012 +0200 +++ b/Lib/os.py Thu Jun 28 11:02:52 2012 +0300 @@ -331,7 +331,9 @@ __all__.extend(["makedirs", "removedirs", "renames"]) -def walk(top, topdown=True, onerror=None, followlinks=False): +_sentry = object() + +def walk(top, topdown=True, onerror=None, followlinks=_sentry, *, follow_symlinks=_sentry): """Directory tree generator. For each directory in the directory tree rooted at top (including top @@ -369,7 +371,7 @@ By default, os.walk does not follow symbolic links to subdirectories on systems that support them. In order to get this functionality, set the - optional argument 'followlinks' to true. + optional argument 'follow_symlinks' to True. Caution: if you pass a relative pathname for top, don't change the current working directory between resumptions of walk. walk never @@ -387,7 +389,15 @@ if 'CVS' in dirs: dirs.remove('CVS') # don't visit CVS directories """ + if follow_symlinks is _sentry: + follow_symlinks = followlinks is not _sentry and followlinks + elif followlinks is not _sentry: + raise TypeError("walk() got values for both 'follow_symlinks' and" + " 'followlinks' arguments") + yield from _walk(top, topdown, onerror, follow_symlinks) + +def _walk(top, topdown, onerror, follow_symlinks): islink, join, isdir = path.islink, path.join, path.isdir # We may not have read permission for top, in which case we can't @@ -415,8 +425,8 @@ yield top, dirs, nondirs for name in dirs: new_path = join(top, name) - if followlinks or not islink(new_path): - yield from walk(new_path, topdown, onerror, followlinks) + if follow_symlinks or not islink(new_path): + yield from walk(new_path, topdown, onerror, follow_symlinks) if not topdown: yield top, dirs, nondirs @@ -424,7 +434,7 @@ if {open, stat} <= supports_dir_fd and {listdir, stat} <= supports_fd: - def fwalk(top=".", topdown=True, onerror=None, followlinks=False, *, dir_fd=None): + def fwalk(top=".", topdown=True, onerror=None, follow_symlinks=False, *, dir_fd=None): """Directory tree generator. This behaves exactly like walk(), except that it yields a 4-tuple @@ -435,7 +445,7 @@ and `dirfd` is a file descriptor referring to the directory `dirpath`. The advantage of fwalk() over walk() is that it's safe against symlink - races (when followlinks is False). + races (when follow_symlinks is False). If dir_fd is not None, it should be a file descriptor open to a directory, and top should be relative; top will then be relative to that directory. @@ -462,13 +472,13 @@ orig_st = stat(top, follow_symlinks=False, dir_fd=dir_fd) topfd = open(top, O_RDONLY, dir_fd=dir_fd) try: - if (followlinks or (st.S_ISDIR(orig_st.st_mode) and - path.samestat(orig_st, stat(topfd)))): - yield from _fwalk(topfd, top, topdown, onerror, followlinks) + if (follow_symlinks or (st.S_ISDIR(orig_st.st_mode) and + path.samestat(orig_st, stat(topfd)))): + yield from _fwalk(topfd, top, topdown, onerror, follow_symlinks) finally: close(topfd) - def _fwalk(topfd, toppath, topdown, onerror, followlinks): + def _fwalk(topfd, toppath, topdown, onerror, follow_symlinks): # Note: This uses O(depth of the directory tree) file descriptors: if # necessary, it can be adapted to only require O(1) FDs, see issue # #13734. @@ -499,16 +509,16 @@ for name in dirs: try: - orig_st = stat(name, dir_fd=topfd, follow_symlinks=followlinks) + orig_st = stat(name, dir_fd=topfd, follow_symlinks=follow_symlinks) dirfd = open(name, O_RDONLY, dir_fd=topfd) except error as err: if onerror is not None: onerror(err) return try: - if followlinks or path.samestat(orig_st, stat(dirfd)): + if follow_symlinks or path.samestat(orig_st, stat(dirfd)): dirpath = path.join(toppath, name) - yield from _fwalk(dirfd, dirpath, topdown, onerror, followlinks) + yield from _fwalk(dirfd, dirpath, topdown, onerror, follow_symlinks) finally: close(dirfd) diff -r d0f775432705 Lib/test/test_os.py --- a/Lib/test/test_os.py Thu Jun 28 01:45:48 2012 +0200 +++ b/Lib/test/test_os.py Thu Jun 28 11:02:52 2012 +0300 @@ -712,6 +712,14 @@ if support.can_symlink(): # Walk, following symlinks. + for root, dirs, files in os.walk(walk_path, follow_symlinks=True): + if root == link_path: + self.assertEqual(dirs, []) + self.assertEqual(files, ["tmp4"]) + break + else: + self.fail("Didn't follow symlink with follow_symlinks=True") + # Walk, using backward compatible argument name "followlinks". for root, dirs, files in os.walk(walk_path, followlinks=True): if root == link_path: self.assertEqual(dirs, []) @@ -720,6 +728,12 @@ else: self.fail("Didn't follow symlink with followlinks=True") + # Incompatible using new and old argument names for "follow_symlinks". + with self.assertRaises(TypeError): + for x in os.walk(walk_path, + follow_symlinks=True, followlinks=True): + break + def tearDown(self): # Tear everything down. This is a decent use for bottom-up on # Windows, which doesn't have a recursive delete command. The @@ -745,8 +759,8 @@ """ compare with walk() results. """ - for topdown, followlinks in itertools.product((True, False), repeat=2): - d = {'topdown': topdown, 'followlinks': followlinks} + for topdown, follow_symlinks in itertools.product((True, False), repeat=2): + d = {'topdown': topdown, 'follow_symlinks': follow_symlinks} walk_kwargs.update(d) fwalk_kwargs.update(d) @@ -774,8 +788,8 @@ def test_yields_correct_dir_fd(self): # check returned file descriptors - for topdown, followlinks in itertools.product((True, False), repeat=2): - args = support.TESTFN, topdown, None, followlinks + for topdown, follow_symlinks in itertools.product((True, False), repeat=2): + args = support.TESTFN, topdown, None, follow_symlinks for root, dirs, files, rootfd in os.fwalk(*args): # check that the FD is valid os.fstat(rootfd) diff -r d0f775432705 Modules/_ctypes/libffi/generate-ios-source-and-headers.py --- a/Modules/_ctypes/libffi/generate-ios-source-and-headers.py Thu Jun 28 01:45:48 2012 +0200 +++ b/Modules/_ctypes/libffi/generate-ios-source-and-headers.py Thu Jun 28 11:02:52 2012 +0300 @@ -83,7 +83,7 @@ headers_seen = collections.defaultdict(set) def move_source_tree(src_dir, dest_dir, dest_include_dir, arch=None, prefix=None, suffix=None): - for root, dirs, files in os.walk(src_dir, followlinks=True): + for root, dirs, files in os.walk(src_dir, follow_symlinks=True): relroot = os.path.relpath(root,src_dir) def move_dir(arch, prefix='', suffix='', files=[]): diff -r d0f775432705 Modules/_ctypes/libffi/generate-osx-source-and-headers.py --- a/Modules/_ctypes/libffi/generate-osx-source-and-headers.py Thu Jun 28 01:45:48 2012 +0200 +++ b/Modules/_ctypes/libffi/generate-osx-source-and-headers.py Thu Jun 28 11:02:52 2012 +0300 @@ -77,7 +77,7 @@ headers_seen = collections.defaultdict(set) def move_source_tree(src_dir, dest_dir, dest_include_dir, arch=None, prefix=None, suffix=None): - for root, dirs, files in os.walk(src_dir, followlinks=True): + for root, dirs, files in os.walk(src_dir, follow_symlinks=True): relroot = os.path.relpath(root,src_dir) def move_dir(arch, prefix='', suffix='', files=[]): -------------- next part -------------- diff -r d0f775432705 Doc/library/shutil.rst --- a/Doc/library/shutil.rst Thu Jun 28 01:45:48 2012 +0200 +++ b/Doc/library/shutil.rst Thu Jun 28 11:03:18 2012 +0300 @@ -47,7 +47,7 @@ be copied. -.. function:: copyfile(src, dst, symlinks=False) +.. function:: copyfile(src, dst, follow_symlinks=True) Copy the contents (no metadata) of the file named *src* to a file named *dst* and return *dst*. *dst* must be the complete target file name; look at @@ -59,63 +59,63 @@ such as character or block devices and pipes cannot be copied with this function. *src* and *dst* are path names given as strings. - If *symlinks* is true and *src* is a symbolic link, a new symbolic link will + If *follow_symlinks* is false and *src* is a symbolic link, a new symbolic link will be created instead of copying the file *src* points to. .. versionchanged:: 3.3 :exc:`IOError` used to be raised instead of :exc:`OSError`. - Added *symlinks* argument. + Added *follow_symlinks* argument. .. versionchanged:: 3.3 Added return of the *dst*. -.. function:: copymode(src, dst, symlinks=False) +.. function:: copymode(src, dst, follow_symlinks=True) Copy the permission bits from *src* to *dst*. The file contents, owner, and group are unaffected. *src* and *dst* are path names given as strings. If - *symlinks* is true, *src* a symbolic link and the operating system supports + *follow_symlinks* is false, *src* a symbolic link and the operating system supports modes for symbolic links (for example BSD-based ones), the mode of the link will be copied. .. versionchanged:: 3.3 - Added *symlinks* argument. + Added *follow_symlinks* argument. -.. function:: copystat(src, dst, symlinks=False) +.. function:: copystat(src, dst, follow_symlinks=True) Copy the permission bits, last access time, last modification time, and flags from *src* to *dst*. The file contents, owner, and group are unaffected. *src* and *dst* are path names given as strings. If *src* and *dst* are both - symbolic links and *symlinks* true, the stats of the link will be copied as + symbolic links and *follow_symlinks* false, the stats of the link will be copied as far as the platform allows. .. versionchanged:: 3.3 - Added *symlinks* argument. + Added *follow_symlinks* argument. -.. function:: copy(src, dst, symlinks=False) +.. function:: copy(src, dst, follow_symlinks=True) Copy the file *src* to the file or directory *dst* and return the file's destination. If *dst* is a directory, a file with the same basename as *src* is created (or overwritten) in the directory specified. Permission bits are copied. *src* and *dst* are path - names given as strings. If *symlinks* is true, symbolic links won't be + names given as strings. If *follow_symlinks* is false, symbolic links won't be followed but recreated instead -- this resembles GNU's :program:`cp -P`. .. versionchanged:: 3.3 - Added *symlinks* argument. + Added *follow_symlinks* argument. .. versionchanged:: 3.3 Added return of the *dst*. -.. function:: copy2(src, dst, symlinks=False) +.. function:: copy2(src, dst, follow_symlinks=False) Similar to :func:`shutil.copy`, including that the destination is returned, but metadata is copied as well. This is - similar to the Unix command :program:`cp -p`. If *symlinks* is true, + similar to the Unix command :program:`cp -p`. If *follow_symlinks* is false, symbolic links won't be followed but recreated instead -- this resembles GNU's :program:`cp -P`. .. versionchanged:: 3.3 - Added *symlinks* argument, try to copy extended file system attributes + Added *follow_symlinks* argument, try to copy extended file system attributes too (currently Linux only). .. versionchanged:: 3.3 @@ -128,7 +128,9 @@ match one of the glob-style *patterns* provided. See the example below. -.. function:: copytree(src, dst, symlinks=False, ignore=None, copy_function=copy2, ignore_dangling_symlinks=False) +.. function:: copytree(src, dst, symlinks=False, ignore=None, + copy_function=copy2, ignore_dangling_symlinks=False, *, + follow_symlinks=True) Recursively copy an entire directory tree rooted at *src*, returning the destination directory. The destination @@ -137,15 +139,17 @@ are copied with :func:`copystat`, individual files are copied using :func:`shutil.copy2`. - If *symlinks* is true, symbolic links in the source tree are represented as + If *follow_symlinks* is false or *symlinks* is true, + symbolic links in the source tree are represented as symbolic links in the new tree and the metadata of the original links will be copied as far as the platform allows; if false or omitted, the contents and metadata of the linked files are copied to the new tree. - When *symlinks* is false, if the file pointed by the symlink doesn't + When *follow_symlinks* is true or *symlinks* is false, + if the file pointed by the symlink doesn't exist, a exception will be added in the list of errors raised in a :exc:`Error` exception at the end of the copy process. - You can set the optional *ignore_dangling_symlinks* flag to true if you + You can set the optional *ignore_dangling_symlinks* flag to ``True`` if you want to silence this exception. Notice that this option has no effect on platforms that don't support :func:`os.symlink`. @@ -172,10 +176,15 @@ .. versionchanged:: 3.2 Added the *ignore_dangling_symlinks* argument to silent dangling symlinks - errors when *symlinks* is false. + errors when *follow_symlinks* is true or *symlinks* is false. .. versionchanged:: 3.3 - Copy metadata when *symlinks* is false. + Copy metadata when *follow_symlinks* is true or *symlinks* is false. + + .. versionchanged:: 3.3 + Added *follow_symlinks* argument with opposite meaning to *symlinks*. + *symlinks* should not be used in new code. A :exc:`TypeError` is raised if + both *symlinks* and *follow_symlinks* are specified. .. versionchanged:: 3.3 Added return of the *dst*. @@ -312,7 +321,7 @@ above, with the docstring omitted. It demonstrates many of the other functions provided by this module. :: - def copytree(src, dst, symlinks=False): + def copytree(src, dst, *, follow_symlinks=True): names = os.listdir(src) os.makedirs(dst) errors = [] @@ -320,11 +329,11 @@ srcname = os.path.join(src, name) dstname = os.path.join(dst, name) try: - if symlinks and os.path.islink(srcname): + if not follow_symlinks and os.path.islink(srcname): linkto = os.readlink(srcname) os.symlink(linkto, dstname) elif os.path.isdir(srcname): - copytree(srcname, dstname, symlinks) + copytree(srcname, dstname, follow_symlinks = follow_symlinks) else: copy2(srcname, dstname) # XXX What about devices, sockets etc.? diff -r d0f775432705 Lib/os.py --- a/Lib/os.py Thu Jun 28 01:45:48 2012 +0200 +++ b/Lib/os.py Thu Jun 28 11:03:18 2012 +0300 @@ -388,6 +388,15 @@ dirs.remove('CVS') # don't visit CVS directories """ + try: + fwalk + except NameError: + pass + else: + for x in fwalk(top, topdown=topdown, onerror=onerror, followlinks=followlinks): + yield x[:-1] + return + islink, join, isdir = path.islink, path.join, path.isdir # We may not have read permission for top, in which case we can't diff -r d0f775432705 Lib/shutil.py --- a/Lib/shutil.py Thu Jun 28 01:45:48 2012 +0200 +++ b/Lib/shutil.py Thu Jun 28 11:03:18 2012 +0300 @@ -82,10 +82,10 @@ return (os.path.normcase(os.path.abspath(src)) == os.path.normcase(os.path.abspath(dst))) -def copyfile(src, dst, symlinks=False): +def copyfile(src, dst, follow_symlinks=True): """Copy data from src to dst. - If optional flag `symlinks` is set and `src` is a symbolic link, a new + If optional flag `follow_symlinks` is not set and `src` is a symbolic link, a new symlink will be created instead of copying the file it points to. """ @@ -103,7 +103,7 @@ if stat.S_ISFIFO(st.st_mode): raise SpecialFileError("`%s` is a named pipe" % fn) - if symlinks and os.path.islink(src): + if not follow_symlinks and os.path.islink(src): os.symlink(os.readlink(src), dst) else: with open(src, 'rb') as fsrc: @@ -111,15 +111,15 @@ copyfileobj(fsrc, fdst) return dst -def copymode(src, dst, symlinks=False): +def copymode(src, dst, follow_symlinks=True): """Copy mode bits from src to dst. - If the optional flag `symlinks` is set, symlinks aren't followed if and + If the optional flag `follow_symlinks` is not set, symlinks aren't followed if and only if both `src` and `dst` are symlinks. If `lchmod` isn't available (eg. Linux), in these cases, this method does nothing. """ - if symlinks and os.path.islink(src) and os.path.islink(dst): + if not follow_symlinks and os.path.islink(src) and os.path.islink(dst): if hasattr(os, 'lchmod'): stat_func, chmod_func = os.lstat, os.lchmod else: @@ -132,10 +132,10 @@ st = stat_func(src) chmod_func(dst, stat.S_IMODE(st.st_mode)) -def copystat(src, dst, symlinks=False): +def copystat(src, dst, follow_symlinks=True): """Copy all stat info (mode bits, atime, mtime, flags) from src to dst. - If the optional flag `symlinks` is set, symlinks aren't followed if and + If the optional flag `follow_symlinks` is not set, symlinks aren't followed if and only if both `src` and `dst` are symlinks. """ @@ -143,7 +143,7 @@ pass # follow symlinks (aka don't not follow symlinks) - follow = not (symlinks and os.path.islink(src) and os.path.islink(dst)) + follow = follow_symlinks or not (os.path.islink(src) and os.path.islink(dst)) if follow: # use the real function if it exists def lookup(name): @@ -186,19 +186,19 @@ raise if hasattr(os, 'listxattr'): - def _copyxattr(src, dst, symlinks=False): + def _copyxattr(src, dst, follow_symlinks=True): """Copy extended filesystem attributes from `src` to `dst`. Overwrite existing attributes. - If the optional flag `symlinks` is set, symlinks won't be followed. + If the optional flag `follow_symlinks` is not set, symlinks won't be followed. """ - for name in os.listxattr(src, follow_symlinks=symlinks): + for name in os.listxattr(src, follow_symlinks=follow_symlinks): try: - value = os.getxattr(src, name, follow_symlinks=symlinks) - os.setxattr(dst, name, value, follow_symlinks=symlinks) + value = os.getxattr(src, name, follow_symlinks=follow_symlinks) + os.setxattr(dst, name, value, follow_symlinks=follow_symlinks) except OSError as e: if e.errno not in (errno.EPERM, errno.ENOTSUP, errno.ENODATA): raise @@ -206,36 +206,36 @@ def _copyxattr(*args, **kwargs): pass -def copy(src, dst, symlinks=False): +def copy(src, dst, follow_symlinks=True): """Copy data and mode bits ("cp src dst"). Return the file's destination. The destination may be a directory. - If the optional flag `symlinks` is set, symlinks won't be followed. This + If the optional flag `follow_symlinks` is not set, symlinks won't be followed. This resembles GNU's "cp -P src dst". """ if os.path.isdir(dst): dst = os.path.join(dst, os.path.basename(src)) - copyfile(src, dst, symlinks=symlinks) - copymode(src, dst, symlinks=symlinks) + copyfile(src, dst, follow_symlinks=follow_symlinks) + copymode(src, dst, follow_symlinks=follow_symlinks) return dst -def copy2(src, dst, symlinks=False): +def copy2(src, dst, follow_symlinks=True): """Copy data and all stat info ("cp -p src dst"). Return the file's destination." The destination may be a directory. - If the optional flag `symlinks` is set, symlinks won't be followed. This + If the optional flag `follow_symlinks` is set, symlinks won't be followed. This resembles GNU's "cp -P src dst". """ if os.path.isdir(dst): dst = os.path.join(dst, os.path.basename(src)) - copyfile(src, dst, symlinks=symlinks) - copystat(src, dst, symlinks=symlinks) - _copyxattr(src, dst, symlinks=symlinks) + copyfile(src, dst, follow_symlinks=follow_symlinks) + copystat(src, dst, follow_symlinks=follow_symlinks) + _copyxattr(src, dst, follow_symlinks=follow_symlinks) return dst def ignore_patterns(*patterns): @@ -250,8 +250,10 @@ return set(ignored_names) return _ignore_patterns -def copytree(src, dst, symlinks=False, ignore=None, copy_function=copy2, - ignore_dangling_symlinks=False): +_sentry = object() + +def copytree(src, dst, symlinks=_sentry, ignore=None, copy_function=copy2, + ignore_dangling_symlinks=False, *, follow_symlinks=_sentry): """Recursively copy a directory tree. The destination directory must not already exist. @@ -264,7 +266,7 @@ exist, an exception will be added in the list of errors raised in an Error exception at the end of the copy process. - You can set the optional ignore_dangling_symlinks flag to true if you + You can set the optional ignore_dangling_symlinks flag to True if you want to silence this exception. Notice that this has no effect on platforms that don't support os.symlink. @@ -286,6 +288,12 @@ function that supports the same signature (like copy()) can be used. """ + if symlinks is _sentry: + symlinks = follow_symlinks is not _sentry and not follow_symlinks + elif follow_symlinks is not _sentry: + raise TypeError("copytree() got values for both 'symlinks' and" + " 'follow_symlinks' arguments") + names = os.listdir(src) if ignore is not None: ignored_names = ignore(src, names) @@ -307,7 +315,7 @@ # code with a custom `copy_function` may rely on copytree # doing the right thing. os.symlink(linkto, dstname) - copystat(srcname, dstname, symlinks=symlinks) + copystat(srcname, dstname, follow_symlinks=not symlinks) else: # ignore dangling symlink if the flag is on if not os.path.exists(linkto) and ignore_dangling_symlinks: diff -r d0f775432705 Lib/test/test_shutil.py --- a/Lib/test/test_shutil.py Thu Jun 28 01:45:48 2012 +0200 +++ b/Lib/test/test_shutil.py Thu Jun 28 11:03:18 2012 +0300 @@ -245,17 +245,17 @@ os.lchmod(src_link, stat.S_IRWXO|stat.S_IRWXG) # link to link os.lchmod(dst_link, stat.S_IRWXO) - shutil.copymode(src_link, dst_link, symlinks=True) + shutil.copymode(src_link, dst_link, follow_symlinks=False) self.assertEqual(os.lstat(src_link).st_mode, os.lstat(dst_link).st_mode) self.assertNotEqual(os.stat(src).st_mode, os.stat(dst).st_mode) # src link - use chmod os.lchmod(dst_link, stat.S_IRWXO) - shutil.copymode(src_link, dst, symlinks=True) + shutil.copymode(src_link, dst, follow_symlinks=False) self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode) # dst link - use chmod os.lchmod(dst_link, stat.S_IRWXO) - shutil.copymode(src, dst_link, symlinks=True) + shutil.copymode(src, dst_link, follow_symlinks=False) self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode) @unittest.skipIf(hasattr(os, 'lchmod'), 'requires os.lchmod to be missing') @@ -270,7 +270,7 @@ write_file(dst, 'foo') os.symlink(src, src_link) os.symlink(dst, dst_link) - shutil.copymode(src_link, dst_link, symlinks=True) # silent fail + shutil.copymode(src_link, dst_link, follow_symlinks=False) # silent fail @support.skip_unless_symlink def test_copystat_symlinks(self): @@ -294,10 +294,10 @@ src_link_stat = os.lstat(src_link) # follow if hasattr(os, 'lchmod'): - shutil.copystat(src_link, dst_link, symlinks=False) + shutil.copystat(src_link, dst_link, follow_symlinks=True) self.assertNotEqual(src_link_stat.st_mode, os.stat(dst).st_mode) # don't follow - shutil.copystat(src_link, dst_link, symlinks=True) + shutil.copystat(src_link, dst_link, follow_symlinks=False) dst_link_stat = os.lstat(dst_link) if os.utime in os.supports_follow_symlinks: for attr in 'st_atime', 'st_mtime': @@ -309,7 +309,7 @@ if hasattr(os, 'lchflags') and hasattr(src_link_stat, 'st_flags'): self.assertEqual(src_link_stat.st_flags, dst_link_stat.st_flags) # tell to follow but dst is not a link - shutil.copystat(src_link, dst, symlinks=True) + shutil.copystat(src_link, dst, follow_symlinks=False) self.assertTrue(abs(os.stat(src).st_mtime - os.stat(dst).st_mtime) < 00000.1) @@ -397,10 +397,10 @@ dst_link = os.path.join(tmp_dir, 'qux') write_file(dst, 'bar') os.symlink(dst, dst_link) - shutil._copyxattr(src_link, dst_link, symlinks=True) + shutil._copyxattr(src_link, dst_link, follow_symlinks=False) self.assertEqual(os.getxattr(dst_link, 'trusted.foo', follow_symlinks=False), b'43') self.assertRaises(OSError, os.getxattr, dst, 'trusted.foo') - shutil._copyxattr(src_link, dst, symlinks=True) + shutil._copyxattr(src_link, dst, follow_symlinks=False) self.assertEqual(os.getxattr(dst, 'trusted.foo'), b'43') @support.skip_unless_symlink @@ -414,12 +414,12 @@ if hasattr(os, 'lchmod'): os.lchmod(src_link, stat.S_IRWXU | stat.S_IRWXO) # don't follow - shutil.copy(src_link, dst, symlinks=False) + shutil.copy(src_link, dst, follow_symlinks=True) self.assertFalse(os.path.islink(dst)) self.assertEqual(read_file(src), read_file(dst)) os.remove(dst) # follow - shutil.copy(src_link, dst, symlinks=True) + shutil.copy(src_link, dst, follow_symlinks=False) self.assertTrue(os.path.islink(dst)) self.assertEqual(os.readlink(dst), os.readlink(src_link)) if hasattr(os, 'lchmod'): @@ -441,12 +441,12 @@ src_stat = os.stat(src) src_link_stat = os.lstat(src_link) # follow - shutil.copy2(src_link, dst, symlinks=False) + shutil.copy2(src_link, dst, follow_symlinks=True) self.assertFalse(os.path.islink(dst)) self.assertEqual(read_file(src), read_file(dst)) os.remove(dst) # don't follow - shutil.copy2(src_link, dst, symlinks=True) + shutil.copy2(src_link, dst, follow_symlinks=False) self.assertTrue(os.path.islink(dst)) self.assertEqual(os.readlink(dst), os.readlink(src_link)) dst_stat = os.lstat(dst) @@ -484,7 +484,7 @@ write_file(src, 'foo') os.symlink(src, link) # don't follow - shutil.copyfile(link, dst_link, symlinks=True) + shutil.copyfile(link, dst_link, follow_symlinks=False) self.assertTrue(os.path.islink(dst_link)) self.assertEqual(os.readlink(link), os.readlink(dst_link)) # follow @@ -555,6 +555,33 @@ if hasattr(os, 'lchflags') and hasattr(stat, 'UF_NODUMP'): os.lchflags(src_link, stat.UF_NODUMP) src_stat = os.lstat(src_link) + shutil.copytree(src_dir, dst_dir, follow_symlinks=False) + self.assertTrue(os.path.islink(os.path.join(dst_dir, 'sub', 'link'))) + self.assertEqual(os.readlink(os.path.join(dst_dir, 'sub', 'link')), + os.path.join(src_dir, 'file.txt')) + dst_stat = os.lstat(dst_link) + if hasattr(os, 'lchmod'): + self.assertEqual(dst_stat.st_mode, src_stat.st_mode) + if hasattr(os, 'lchflags'): + self.assertEqual(dst_stat.st_flags, src_stat.st_flags) + + def test_copytree_symlinks_old(self): + tmp_dir = self.mkdtemp() + src_dir = os.path.join(tmp_dir, 'src') + dst_dir = os.path.join(tmp_dir, 'dst') + sub_dir = os.path.join(src_dir, 'sub') + os.mkdir(src_dir) + os.mkdir(sub_dir) + write_file((src_dir, 'file.txt'), 'foo') + src_link = os.path.join(sub_dir, 'link') + dst_link = os.path.join(dst_dir, 'sub/link') + os.symlink(os.path.join(src_dir, 'file.txt'), + src_link) + if hasattr(os, 'lchmod'): + os.lchmod(src_link, stat.S_IRWXU | stat.S_IRWXO) + if hasattr(os, 'lchflags') and hasattr(stat, 'UF_NODUMP'): + os.lchflags(src_link, stat.UF_NODUMP) + src_stat = os.lstat(src_link) shutil.copytree(src_dir, dst_dir, symlinks=True) self.assertTrue(os.path.islink(os.path.join(dst_dir, 'sub', 'link'))) self.assertEqual(os.readlink(os.path.join(dst_dir, 'sub', 'link')), @@ -565,6 +592,15 @@ if hasattr(os, 'lchflags'): self.assertEqual(dst_stat.st_flags, src_stat.st_flags) + def test_copytree_incompatible_args(self): + tmp_dir = self.mkdtemp() + src_dir = os.path.join(tmp_dir, 'src') + dst_dir = os.path.join(tmp_dir, 'dst') + sub_dir = os.path.join(src_dir, 'sub') + os.mkdir(src_dir) + os.mkdir(sub_dir) + self.assertRaises(TypeError, shutil.copytree, src_dir, dst_dir, symlinks=True, follow_symlinks=False) + def test_copytree_with_exclude(self): # creating data join = os.path.join @@ -748,9 +784,9 @@ shutil.copytree(src_dir, dst_dir, ignore_dangling_symlinks=True) self.assertNotIn('test.txt', os.listdir(dst_dir)) - # a dangling symlink is copied if symlinks=True + # a dangling symlink is copied if follow_symlinks=False dst_dir = os.path.join(self.mkdtemp(), 'destination3') - shutil.copytree(src_dir, dst_dir, symlinks=True) + shutil.copytree(src_dir, dst_dir, follow_symlinks=False) self.assertIn('test.txt', os.listdir(dst_dir)) def _copy_file(self, method): From report at bugs.python.org Thu Jun 28 10:45:34 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 08:45:34 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1340836708.24.0.320208270367.issue14814@psf.upfronthosting.co.za> Message-ID: <4FEC19AC.3050702@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: Try running the test like: ./python[.exe] -bb -Wd -m test test_ipaddress ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Thu Jun 28 10:58:37 2012 From: report at bugs.python.org (Patrick Westerhoff) Date: Thu, 28 Jun 2012 08:58:37 +0000 Subject: [issue14133] improved PEP 409 implementation In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za> Message-ID: <1340873917.12.0.250678088787.issue14133@psf.upfronthosting.co.za> Patrick Westerhoff <PatrickWesterhoff at gmail.com> added the comment: Hey, I just saw the release notes for 3.3 and would like a quick confirmation: This is included in 3.3, right? ^^ ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14133> _______________________________________ From report at bugs.python.org Thu Jun 28 11:05:06 2012 From: report at bugs.python.org (Christian Heimes) Date: Thu, 28 Jun 2012 09:05:06 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <20120628075449.Horde.nsEAfUlCcOxP6-Gp3T3WMyA@webmail.df.eu> Message-ID: <4FEC1E38.6010507@cheimes.de> Christian Heimes <lists at cheimes.de> added the comment: Am 28.06.2012 07:54, schrieb Martin v. L?wis: > > Martin v. L?wis <martin at v.loewis.de> added the comment: > >> a) my patch handles the fork() issue correctly > > If the system has urandom, yes. That's the easy and trivial case. It also handles fork() by storing the PID and comparing it to os.getpid() whenever the RNG is acquired. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 11:27:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 09:27:30 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1340875650.26.0.847533085371.issue15206@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: + except Exception: I don't think that's a good idea. You should list the specific exceptions here (NotImplementedError, OSError perhaps?). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ From report at bugs.python.org Thu Jun 28 11:30:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 09:30:28 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340803861.6.0.985390625011.issue15204@psf.upfronthosting.co.za> Message-ID: <1340875849.2462.92.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Unless there are places where it is actually broken, I don't think there is a good reason to have step 3.5, though. Just add the deprecation warning and remove it in 4.0. Well. In any case, the 'U' mode in most cases has no effect, and the code, where it has an effect (in zipfile), is very rarely used (and it is actually complicated and broken). Here are the patches for the first (documentation) and the second stage (warnings). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Thu Jun 28 11:32:01 2012 From: report at bugs.python.org (Tim Golden) Date: Thu, 28 Jun 2012 09:32:01 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340875921.63.0.961083702042.issue1677@psf.upfronthosting.co.za> Tim Golden <mail at timgolden.me.uk> added the comment: Attached is a patch against Python 2.7. It checks in a loop for SIGINT and, if it still hasn't fired, assumed Ctrl-Z was pressed which generates the same error. ---------- assignee: -> tim.golden keywords: +patch Added file: http://bugs.python.org/file26196/issue1677-python27.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 11:32:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 09:32:08 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1340875928.61.0.421413945054.issue15204@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- keywords: +patch Added file: http://bugs.python.org/file26197/deprecate-U-mode-stage1.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Thu Jun 28 11:32:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 09:32:47 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1340875967.71.0.23477911662.issue15204@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: Added file: http://bugs.python.org/file26198/deprecate-U-mode-stage2.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Thu Jun 28 12:08:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jun 2012 10:08:10 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <E1SkBdw-0001ik-0C@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset f9f798f1421e by Hynek Schlawack in branch 'default': #4489: Don't follow ever symlinks in rmtree http://hg.python.org/cpython/rev/f9f798f1421e ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 28 12:08:32 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 10:08:32 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340878112.57.0.647780338965.issue4489@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Thanks you for catching that! It seems we did something really stupid: followed symlinks. I?ve fixed that and added regression tests. This one is a facepalm gentlepeople. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 28 12:26:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 10:26:27 +0000 Subject: [issue15215] socket module setblocking and settimeout problem In-Reply-To: <1340868379.68.0.473827205648.issue15215@psf.upfronthosting.co.za> Message-ID: <1340879187.42.0.738368938523.issue15215@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Yes, this is normal. Timeout sockets use a non-blocking fd internally: http://docs.python.org/dev/library/socket.html#notes-on-socket-timeouts This won't be visible to you if you only use the socket object, but it will if you call fileno() and use the file descriptor directly. ---------- nosy: +pitrou resolution: -> wont fix status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15215> _______________________________________ From report at bugs.python.org Thu Jun 28 12:39:45 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 10:39:45 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340879985.01.0.250766726307.issue4489@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 28 12:41:30 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 10:41:30 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1340880090.93.0.445504821045.issue7475@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Setting as a release blocker for 3.4 - this is important. ---------- priority: normal -> release blocker stage: commit review -> _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue7475> _______________________________________ From report at bugs.python.org Thu Jun 28 12:45:16 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 28 Jun 2012 10:45:16 +0000 Subject: [issue14469] Python 3 documentation links In-Reply-To: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za> Message-ID: <1340880316.05.0.827804775332.issue14469@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: Right now, I do not see the problem mentioned in this report. http://www.python.org/doc/ point to a page which has reference docs to both 2.7 and 3.0. The left hand side, Other Resources Link are generic too. docs.python.org pointing to py2.7 is a python-dev decision and outside scope of this bug. I am closing this one as works for me. ---------- nosy: +orsenthil resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14469> _______________________________________ From report at bugs.python.org Thu Jun 28 12:49:18 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 10:49:18 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation Message-ID: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> New submission from Nick Coghlan <ncoghlan at gmail.com>: As discussed on python-ideas, swapping out the sys.std* streams can be fraught with peril. This can make writing code that wants to support an "--encoding" option for pipeline processing difficult. The proposal [1] is that TextIOWrapper support a set_encoding() method that is only supported between creation of the stream and the first read or write operation. Once the stream is "dirty", you can no longer change the encoding - you must replace the stream (e.g. by passing stream.fileNo() to open()) [1] http://mail.python.org/pipermail/python-ideas/2012-June/015535.html ---------- messages: 164239 nosy: ncoghlan priority: release blocker severity: normal stage: needs patch status: open title: Support setting the encoding on a text stream after creation type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15216> _______________________________________ From report at bugs.python.org Thu Jun 28 12:59:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jun 2012 10:59:04 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <E1SkCRC-0005ih-Jd@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c37cb11b546f by Petri Lehtinen in branch '2.7': #9559: Append data to single-file mailbox files if messages are only added http://hg.python.org/cpython/rev/c37cb11b546f New changeset 5f447a005d67 by Petri Lehtinen in branch '3.2': #9559: Append data to single-file mailbox files if messages are only added http://hg.python.org/cpython/rev/5f447a005d67 New changeset 0bacbab678ed by Petri Lehtinen in branch 'default': #9559: Append data to single-file mailbox files if messages are only added http://hg.python.org/cpython/rev/0bacbab678ed ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Thu Jun 28 13:00:03 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 28 Jun 2012 11:00:03 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1340881203.25.0.803581988998.issue9559@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Fixed. I removed the extra newlines. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Thu Jun 28 13:01:09 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 28 Jun 2012 11:01:09 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1340881269.08.0.953938763591.issue9559@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: See #15122 for always modifying single-file mailboxes in-place. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Thu Jun 28 13:09:37 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 11:09:37 +0000 Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does not support the buffer interface In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za> Message-ID: <1340881777.14.0.322822122561.issue10571@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- nosy: +hynek versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10571> _______________________________________ From report at bugs.python.org Thu Jun 28 13:10:37 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 28 Jun 2012 11:10:37 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340881837.66.0.907193841482.issue1677@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Shouldn't we be using a proper synchronization primitive? What about waiting for an event? ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 13:15:04 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 28 Jun 2012 11:15:04 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340882104.32.0.983234631461.issue1677@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: In fact, there is _PyOS_SigintEvent at the end of signalmodule.c ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 13:22:29 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 28 Jun 2012 11:22:29 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340882549.88.0.883055659456.issue4489@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I'm not a security guy, but: shouldn't the os.unlink call when it isn't a directory specify follow_symlinks=False? And wouldn't it be safer if the os.rmdir() call also used dir_fd=? Additionally, I think you missed some stuff for shutil._use_fd_functions. Assuming I'm right on both of the above, you should also check: * os.listdir in os.supports_dir_fd * os.rmdir in os.supports_dir_fd * os.stat in os.supports_dir_fd * os.stat in os.supports_follow_symlinks * os.unlink in os.supports_follow_symlinks I'd spell that _use_fd_functions = ({os.listdir, os.open, os.rmdir, os.stat, os.unlink} < os.supports_dir_fd and {os.stat, os.unlink} <= os.supports_follow_symlinks) Finally, up to you, but I'd be tempted to change the "lstat" "and "fstat" calls to "stat" calls using the relevant parameters. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 28 13:33:04 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 28 Jun 2012 11:33:04 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340883184.91.0.478064176541.issue1677@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Is the ERROR_OPERATION_ABORTED set when Ctrl-Z is hit? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 13:53:28 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 11:53:28 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1340882549.88.0.883055659456.issue4489@psf.upfronthosting.co.za> Message-ID: <4FEC45B4.8000004@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: > I'm not a security guy, but: shouldn't the os.unlink call when it isn't a directory specify follow_symlinks=False? os.unlink has no follow_symlinks argument. Imagine what would happen if you?d do a os.unlink() on a link and it would just remove the link destination. :) > And wouldn't it be safer if the os.rmdir() call also used dir_fd=? Unfortunately, os.rmdir('.', dir_fd=topfd) doesn?t work. As in the worst case it could delete only an empty directory, I think it?s fine. > Additionally, I think you missed some stuff for shutil._use_fd_functions. Assuming I'm right on both of the above, you should also check: > * os.listdir in os.supports_dir_fd > * os.rmdir in os.supports_dir_fd > * os.stat in os.supports_dir_fd > * os.stat in os.supports_follow_symlinks > * os.unlink in os.supports_follow_symlinks Interestingly, os.listdir is not in os.supports_dir_fd although it works: False Will you fix it right away or shall I open a ticket? > I'd spell that > _use_fd_functions = ({os.listdir, os.open, os.rmdir, os.stat, os.unlink} < > os.supports_dir_fd and > {os.stat, os.unlink} <= os.supports_follow_symlinks) It would be: _use_fd_functions = ({os.listdir, os.open, os.stat, os.unlink} <= os.supports_dir_fd and os.stat in os.supports_follow_symlinks) But currently can?t do. > Finally, up to you, but I'd be tempted to change the "lstat" "and "fstat" calls to "stat" calls using the relevant parameters. That's not 3.3 fodder IMHO, feel free to open an enhancement ticket. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 28 14:01:43 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 28 Jun 2012 12:01:43 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1340884903.64.0.698523145315.issue4489@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I'm pretty busy right now, please open a ticket for listdir. _rmtree_safe_fd could remove the directory just after the recursive step using the parent's dirfd. Of course you'd also have to add a rmdir for the very-tippy-top after the original call in shutil.rmtree too. But this would prevent the malicious user from even removing empty directories. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 28 14:04:20 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 12:04:20 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd Message-ID: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> New submission from Hynek Schlawack <hs at ox.cx>: >>> n = os.open('/tmp', os.O_RDONLY) >>> l = os.listdir(n) >>> os.listdir in os.supports_dir_fd False ---------- assignee: larry components: Library (Lib) messages: 164249 nosy: hynek, larry priority: release blocker severity: normal stage: needs patch status: open title: os.listdir is missing in os.supports_dir_fd type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Thu Jun 28 14:31:51 2012 From: report at bugs.python.org (Tim Golden) Date: Thu, 28 Jun 2012 12:31:51 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1340883184.91.0.478064176541.issue1677@psf.upfronthosting.co.za> Message-ID: <4FEC4EB4.8030507@timgolden.me.uk> Tim Golden <mail at timgolden.me.uk> added the comment: Yep. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 14:33:04 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 12:33:04 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1340884903.64.0.698523145315.issue4489@psf.upfronthosting.co.za> Message-ID: <4FEC4EFC.2010400@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: > I'm pretty busy right now, please open a ticket for listdir. done > _rmtree_safe_fd could remove the directory just after the recursive step using the parent's dirfd. Of course you'd also have to add a rmdir for the very-tippy-top after the original call in shutil.rmtree too. But this would prevent the malicious user from even removing empty directories. Okay I looked into it and it seems okay. IIRC, when Martin wrote the code (and I the fwalk version before), there was no known fd-based rmdir function. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 28 14:35:02 2012 From: report at bugs.python.org (Tim Golden) Date: Thu, 28 Jun 2012 12:35:02 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <4FEC4EB4.8030507@timgolden.me.uk> Message-ID: <4FEC4EFF.8010105@timgolden.me.uk> Tim Golden <mail at timgolden.me.uk> added the comment: To be clear: ERROR_OPERATION_ABORTED is set when Ctrl-Z is hit as the only thing on a line. If it's just an extra character then it operates like any other keypress. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 15:03:57 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 28 Jun 2012 13:03:57 +0000 Subject: [issue13886] readline-related test_builtin failure In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za> Message-ID: <1340888637.38.0.237287049022.issue13886@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: I had exactly the same error on 3.3b1 when running the test suite with randomized order. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13886> _______________________________________ From report at bugs.python.org Thu Jun 28 15:20:01 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Thu, 28 Jun 2012 13:20:01 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1340889601.29.0.921948578938.issue9559@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: The _pre_mailbox_hook may be called twice, like this: babyl = mailbox.Babyl('new_file') babyl.add('foo\n') babyl.remove(0) babyl.add('bar\n') This only affects Babyl, that writes the mailbox header in _pre_mailbox_hook. The mailbox is corrupted on disk until flush() is called. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Thu Jun 28 15:32:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jun 2012 13:32:20 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <E1SkEpX-00054W-9X@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 9134bb4d0578 by Hynek Schlawack in branch 'default': #4489: Use dir_fd in rmdir in _rmtree_safe_fd() http://hg.python.org/cpython/rev/9134bb4d0578 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4489> _______________________________________ From report at bugs.python.org Thu Jun 28 16:08:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 14:08:28 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1340892508.06.0.724521868861.issue15216@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: > The proposal [1] is that TextIOWrapper support a set_encoding() method that is only supported between creation of the stream and the first read or write operation. IMHO "encoding", "errors", "buffering", "line_buffering" and "newline" should be writable properties (unless first read/write). ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15216> _______________________________________ From report at bugs.python.org Thu Jun 28 16:20:06 2012 From: report at bugs.python.org (Pankaj D) Date: Thu, 28 Jun 2012 14:20:06 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function In-Reply-To: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za> Message-ID: <1340893206.43.0.115104577328.issue15108@psf.upfronthosting.co.za> Pankaj D <pxd at comcast.net> added the comment: I believe I have found the root-cause for this issue. It is occurring due to the use of the garbage collector in another ?memMonitor? thread (we run it periodically to get stats on objects, track mem leaks, etc). Since _pysqlite_fetch_one_row() releases the GIL before calling PyTuple_SetItem(), if the memMonitor is scheduled to run and, say, calls gc.get_objects(), it increments the refcount on all tracked objects (via append_objects()->PyList_Append()->app1()->PY_INCREF()). I have stack traces to confirm. This seems to rule out the use of gc methods (such as get_objects(), get_referrers/referents()) in multi-threaded programs or have them handle SystemError arising from such usage. Agree? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Thu Jun 28 16:20:54 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 14:20:54 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> Message-ID: <1340893254.35.0.850207864677.issue15217@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Thu Jun 28 16:28:44 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 28 Jun 2012 14:28:44 +0000 Subject: [issue12142] Reference cycle when importing ctypes In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za> Message-ID: <1340893724.36.0.268360624554.issue12142@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Meador, can we close this issue? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12142> _______________________________________ From report at bugs.python.org Thu Jun 28 16:35:59 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 14:35:59 +0000 Subject: [issue15218] Check for all necessary dir_fd and follow_symlinks functions Message-ID: <1340894159.39.0.860885591292.issue15218@psf.upfronthosting.co.za> New submission from Hynek Schlawack <hs at ox.cx>: Currently not all functions are checked. As soon as #15217 is fixed, we have to add the rest. ---------- assignee: hynek components: Library (Lib) files: fd-protection.diff keywords: patch messages: 164259 nosy: hynek priority: release blocker severity: normal status: open title: Check for all necessary dir_fd and follow_symlinks functions type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26199/fd-protection.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15218> _______________________________________ From report at bugs.python.org Thu Jun 28 16:36:11 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 14:36:11 +0000 Subject: [issue15218] Check for all necessary dir_fd and follow_symlinks functions In-Reply-To: <1340894159.39.0.860885591292.issue15218@psf.upfronthosting.co.za> Message-ID: <1340894171.7.0.572419137141.issue15218@psf.upfronthosting.co.za> Changes by Hynek Schlawack <hs at ox.cx>: ---------- dependencies: +os.listdir is missing in os.supports_dir_fd _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15218> _______________________________________ From report at bugs.python.org Thu Jun 28 16:43:57 2012 From: report at bugs.python.org (Tyler Crompton) Date: Thu, 28 Jun 2012 14:43:57 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340894637.46.0.0674161925355.issue15209@psf.upfronthosting.co.za> Tyler Crompton <gtr053 at gmail.com> added the comment: I'm in a little over my head as I can't conceptualize __cause__, so I may be looking over things. First, you, Ethan, said the following: >It's also not difficult to work around if you really want to toss the extra info: > > except NameError: > try: > fallback_module.getch() > except Exception as exc: > raise exc from None > >A total of three more words to get the desired behavior (and small ones at that). Counter-argument: if it's just three words, then why was the shorthand without the from clause implemented in the first place? My use case was primarily based on the idea that the unavailability of the windows module (from the example) is irrelevant information to, say, Unix users. When an exception is raised, the user shouldn't have to see any Windows-related exceptions (that is if there is an alternate solution). One could fix this with a little bit of refactoring, though: import sys as _sys def getch(prompt=''): '''Get and return a character (similar to `input()`).''' print(prompt, end='') if 'windows_module' in _sys.modules: return windows_module.getch() else: try: return fallback_module.getch() except Exception: raise from None But it's EAFP. Heck, one could even do the following: def getch(prompt=''): '''Get and return a character (similar to `input()`).''' print(prompt, end='') try: return windows_module.getch() except NameError: pass try: return fallback_module.getch() except Exception: raise But that's not really ideal. I've played around with the traceback module a little and (very) briefly played with the exceptions themselves. Is there not an easier way to suppress a portion of an exception? Like I said, such information is irrelevant to non-Windows users. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 16:49:34 2012 From: report at bugs.python.org (Tim Golden) Date: Thu, 28 Jun 2012 14:49:34 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1340882104.32.0.983234631461.issue1677@psf.upfronthosting.co.za> Message-ID: <4FEC6EFB.5090404@timgolden.me.uk> Tim Golden <mail at timgolden.me.uk> added the comment: This patch is for 2.7 and does enough to solve the issue without a major rework. The signal module onthe default branch has had a lot of love recently and I'll definitely make use of that for a 3.x patch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 16:53:46 2012 From: report at bugs.python.org (Meador Inge) Date: Thu, 28 Jun 2012 14:53:46 +0000 Subject: [issue12142] Reference cycle when importing ctypes In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za> Message-ID: <1340895226.01.0.512653025599.issue12142@psf.upfronthosting.co.za> Meador Inge <meadori at gmail.com> added the comment: > Meador, can we close this issue? I wanted to keep it open until the 'long double' problem is fixed as well. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue12142> _______________________________________ From report at bugs.python.org Thu Jun 28 17:06:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 15:06:02 +0000 Subject: [issue15218] Check for all necessary dir_fd and follow_symlinks functions In-Reply-To: <1340894159.39.0.860885591292.issue15218@psf.upfronthosting.co.za> Message-ID: <1340895962.2.0.958931030303.issue15218@psf.upfronthosting.co.za> Changes by Serhiy Storchaka <storchaka at gmail.com>: ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15218> _______________________________________ From report at bugs.python.org Thu Jun 28 17:13:31 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 28 Jun 2012 15:13:31 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function In-Reply-To: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za> Message-ID: <1340896411.29.0.0874288919666.issue15108@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Thanks for the analysis! This is quite similar to issue793822: gc.get_referrers() can access unfinished tuples. The difference here is that what breaks is not the monitoring tool, but the "main" program! Here is a simple script inspired from the original bug; PySequence_Tuple() uses PyTuple_SET_ITEM() which is a macro without the ob_refcnt check, but we can make it call _PyTuple_Resize() and fail there. All versions of CPython are affected: import gc TAG = object() def monitor(): lst = [x for x in gc.get_referrers(TAG) if isinstance(x, tuple)] t = lst[0] # this *is* the result tuple print(t) # full of nulls ! return t # Keep it alive for some time def my_iter(): yield TAG # 'tag' gets stored in the result tuple t = monitor() for x in range(10): yield x # SystemError when the tuple needs to be resized tuple(my_iter()) ---------- nosy: +amaury.forgeotdarc, arigo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Thu Jun 28 17:34:57 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 28 Jun 2012 15:34:57 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340897697.08.0.0891598478961.issue1677@psf.upfronthosting.co.za> Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment: Hm, I wonder if the test for the SIGINT event is required at all. Could it be sufficient to simply check for the EOF state? EOF would indicate ctrl z and distinguish it thus from ctrl-c. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 17:40:47 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Thu, 28 Jun 2012 15:40:47 +0000 Subject: [issue15030] PyPycLoader can't read cached .pyc files In-Reply-To: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za> Message-ID: <1340898047.34.0.244028882128.issue15030@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: I don't know if I'll have time soon to do the tweaks to Ronan's test (and maybe he wants to do them himself anyway?), but here's the correction of the size calculation in the header (from size of bytecode to size of source -- thanks, Brett!) ---------- Added file: http://bugs.python.org/file26200/cpython-issue-15030.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15030> _______________________________________ From report at bugs.python.org Thu Jun 28 17:53:58 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 15:53:58 +0000 Subject: [issue14133] improved PEP 409 implementation In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za> Message-ID: <1340898838.99.0.546672405509.issue14133@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Yep - note that PEP 409 was updated to say that the the implementation discussion has been superceded by PEP 415. It may be worth making that note more prominent, though... ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14133> _______________________________________ From report at bugs.python.org Thu Jun 28 17:56:03 2012 From: report at bugs.python.org (Michael Gundlach) Date: Thu, 28 Jun 2012 15:56:03 +0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za> Message-ID: <1340898963.64.0.589045870967.issue1251@psf.upfronthosting.co.za> Michael Gundlach <gundlach at gmail.com> added the comment: I recently started getting what appears to be this bug in 2.6.6 and 2.7.3 when connecting to Google. My script does this: while True: get an IMAP connection to Google, if our old one timed out fetch unread messages. if any: make an SMTP connection to Google and send some emails mark the unread messages as read sleep 10 seconds It used to run fine on 2.6. I'm assuming something changed at Google, because it started hanging, whether in 2.6 or 2.7. Here's the stack trace when I eventually press Ctrl-C: File "./main.py", line 21, in loop the_emails = list(emails.messages('(UNSEEN)')) File "./emails.py", line 129, in messages for chunk in chunks_of_length(32, messages): File "./chunks.py", line 9, in chunks_of_length for item in iterable: File "./emails.py", line 90, in email_messages m = open_mailbox(label, readonly=True) File "./emails.py", line 30, in open_mailbox m = imaplib.IMAP4_SSL('imap.gmail.com', 993) File "/usr/lib64/python2.6/imaplib.py", line 1138, in __init__ IMAP4.__init__(self, host, port) File "/usr/lib64/python2.6/imaplib.py", line 163, in __init__ self.open(host, port) File "/usr/lib64/python2.6/imaplib.py", line 1150, in open self.sslobj = ssl.wrap_socket(self.sock, self.keyfile, self.certfile) File "/usr/lib64/python2.6/ssl.py", line 338, in wrap_socket suppress_ragged_eofs=suppress_ragged_eofs) File "/usr/lib64/python2.6/ssl.py", line 120, in __init__ self.do_handshake() File "/usr/lib64/python2.6/ssl.py", line 279, in do_handshake self._sslobj.do_handshake() KeyboardInterrupt FWIW, for the last couple of days my script is *not* hanging, so perhaps Google changed something on their end, avoiding the Python bug. Should this Issue be reopened or should I file a new Issue? ---------- nosy: +gundlach _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1251> _______________________________________ From report at bugs.python.org Thu Jun 28 17:59:35 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 15:59:35 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340899175.26.0.0278419216435.issue15209@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: If you don't want the exception context set *at all*, just use a pass statement to get out of the exception before trying the fallback. try: return windows_module.getch() except NameError: pass # No exception chaining fallback_module.getch() ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 18:02:12 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 Jun 2012 16:02:12 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340899332.63.0.332558967214.issue15209@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Correction, your try block is overbroad and will suppress errors in the getch implementation. This is better: try: _getch = windows_module.getch except NameError: _ getch = fallback_module.getch _getch() So I'm sticking with my perspective that wanting to do this is a sign of something else being wrong with the exception handling setup. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 18:04:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 16:04:27 +0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <1340898963.64.0.589045870967.issue1251@psf.upfronthosting.co.za> Message-ID: <1340899413.3379.1.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: [...] > > Should this Issue be reopened or should I file a new Issue? I would prefer a new issue to be filed (assuming the error happens again). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1251> _______________________________________ From report at bugs.python.org Thu Jun 28 18:08:16 2012 From: report at bugs.python.org (Ethan Furman) Date: Thu, 28 Jun 2012 16:08:16 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340894637.46.0.0674161925355.issue15209@psf.upfronthosting.co.za> Message-ID: <4FEC846F.8020006@stoneleaf.us> Ethan Furman <ethan at stoneleaf.us> added the comment: Tyler Crompton wrote: > I'm in a little over my head as I can't conceptualize __cause__, so I may be looking over things. > > First, you, Ethan, said the following: > >> It's also not difficult to work around if you really want to toss the extra info: >> >> except NameError: >> try: >> fallback_module.getch() >> except Exception as exc: >> raise exc from None >> >> A total of three more words to get the desired behavior (and small ones at that). > > Counter-argument: if it's just three words, then why was the shorthand without the from clause implemented in the first place? I'm not sure I understand the question -- do you mean why can we do 'raise' by itself to re-raise an exception? 'from' is new, and was added in Py3k (see below). 'raise', as a shortcut, is there to allow clean-up (or whatever) in the except clause before re-raising the same exception. In 3.0 exceptions were enhanced to include a link to previous exceptions. So if you are handling exception A and exception B occurs, exception B will be raised and will have a link to A. That link is kept in __context__. This complete chain will then be printed if the last exception raised is uncaught. However, there are times when you may want to add more exception information yourself, so we have the `from` clause, which store the extra exception in __cause__. And, there are times when you are changing from one exception to another and do not want the previous one displayed -- so we now have 'from None' (which sets __suppress_context__ to True). So if some underlying function raises ValueError, but you want to transform that to an XyzError, your can do: try: some_function() except ValueError: raise XyzError from None and then, if the exception is uncaught and printed, only the XyzError will be displayed (barring custom print handlers). > My use case was primarily based on the idea that the unavailability of the windows module (from the example) is irrelevant information to, say, Unix users. When an exception is raised, the user shouldn't have to see any Windows-related exceptions (that is if there is an alternate solution). So you are using the absence of the Windows based module as evidence that you are not running on Windows... but what if you are on Windows and there is some other problem with that module? The usual way to code for possible different modules is: try: import windows_module as utils # or whatever name except ImportError: import fallback_module as utils ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 18:15:22 2012 From: report at bugs.python.org (Ethan Furman) Date: Thu, 28 Jun 2012 16:15:22 +0000 Subject: [issue15209] Re-raising exceptions from an expression In-Reply-To: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za> Message-ID: <1340900122.24.0.836704612664.issue15209@psf.upfronthosting.co.za> Ethan Furman <ethan at stoneleaf.us> added the comment: Removed sample code from doc patch as it was not robust, nor recommended practice. New patch is effectively: Note: Because using :keyword:`from` can throw away valuable debugging information, its use with a bare :keyword:`raise` is not supported. ---------- Added file: http://bugs.python.org/file26201/raise_from_doc_update_v2.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15209> _______________________________________ From report at bugs.python.org Thu Jun 28 18:43:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 16:43:49 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function In-Reply-To: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za> Message-ID: <1340901829.98.0.692562407838.issue15108@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: I wonder why _pysqlite_fetch_one_row() releases the GIL around sqlite3_column_type(). By its name, it doesn't sound like an expensive function. Another workaround would be to call PyTuple_SET_ITEM instead of PyTuple_SetItem. ---------- components: +Extension Modules nosy: +ghaering, pitrou versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Thu Jun 28 18:45:53 2012 From: report at bugs.python.org (=?utf-8?q?Michael_F=C3=B6tsch?=) Date: Thu, 28 Jun 2012 16:45:53 +0000 Subject: [issue15219] Leak in "_hashlib.new()" if argument is not a string Message-ID: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za> New submission from Michael F?tsch <foetsch at yahoo.com>: If the "name" argument to "_hashlib.new()" is not a string, the reference count for the "string" argument is not decremented. In the file "Modules/_hashopenssl.c", function "EVP_new()", a call to "PyBuffer_Release()" is missing: if (!PyArg_Parse(name_obj, "s", &name)) { + PyBuffer_Release(&view); PyErr_SetString(PyExc_TypeError, "name must be a string"); return NULL; } ---------- components: Library (Lib) messages: 164274 nosy: mfoetsch priority: normal severity: normal status: open title: Leak in "_hashlib.new()" if argument is not a string type: resource usage versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15219> _______________________________________ From report at bugs.python.org Thu Jun 28 18:46:20 2012 From: report at bugs.python.org (Tim Golden) Date: Thu, 28 Jun 2012 16:46:20 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1340897697.08.0.0891598478961.issue1677@psf.upfronthosting.co.za> Message-ID: <4FEC8A58.6010605@timgolden.me.uk> Tim Golden <mail at timgolden.me.uk> added the comment: Nope. Ctrl-C also sets EOF ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 18:48:40 2012 From: report at bugs.python.org (=?utf-8?q?Michael_F=C3=B6tsch?=) Date: Thu, 28 Jun 2012 16:48:40 +0000 Subject: [issue15219] Leak in "_hashlib.new()" if argument is not a string In-Reply-To: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za> Message-ID: <1340902120.49.0.874710626834.issue15219@psf.upfronthosting.co.za> Michael F?tsch <foetsch at yahoo.com> added the comment: The change is against the 2.7 branch. The 3.2 branch is not affected. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15219> _______________________________________ From report at bugs.python.org Thu Jun 28 19:00:12 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 28 Jun 2012 17:00:12 +0000 Subject: [issue15219] Leak in "_hashlib.new()" if argument is not a string In-Reply-To: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za> Message-ID: <1340902812.81.0.416643754314.issue15219@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: Could you possibly provide a testcase?. ---------- nosy: +jcea _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15219> _______________________________________ From report at bugs.python.org Thu Jun 28 19:10:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 17:10:23 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1340903423.08.0.0376525894434.issue5765@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Terry, try a large constant. I can reproduce it on all versions from 2.6 to 3.3 with eval("()" * 300000). ---------- nosy: +storchaka versions: +Python 2.6, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5765> _______________________________________ From report at bugs.python.org Thu Jun 28 19:10:52 2012 From: report at bugs.python.org (Tim Golden) Date: Thu, 28 Jun 2012 17:10:52 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340903452.32.0.796157270673.issue1677@psf.upfronthosting.co.za> Tim Golden <mail at timgolden.me.uk> added the comment: And here's a patch for the default branch, using the new sigint event as Kristan suggested. ---------- Added file: http://bugs.python.org/file26202/issue1677-python3x.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Thu Jun 28 19:13:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 17:13:52 +0000 Subject: [issue15077] Regexp match goes into infinite loop In-Reply-To: <1339756870.03.0.464046287951.issue15077@psf.upfronthosting.co.za> Message-ID: <1340903632.17.0.881213822886.issue15077@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: I think it's a bug. The issue can be closed. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15077> _______________________________________ From report at bugs.python.org Thu Jun 28 19:15:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 17:15:10 +0000 Subject: [issue15077] Regexp match goes into infinite loop In-Reply-To: <1339756870.03.0.464046287951.issue15077@psf.upfronthosting.co.za> Message-ID: <1340903710.69.0.0456204026662.issue15077@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: I think it's *not* a bug. The issue can be closed. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15077> _______________________________________ From report at bugs.python.org Thu Jun 28 19:36:10 2012 From: report at bugs.python.org (Pankaj D) Date: Thu, 28 Jun 2012 17:36:10 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function In-Reply-To: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za> Message-ID: <1340904970.5.0.248320618591.issue15108@psf.upfronthosting.co.za> Pankaj D <pxd at comcast.net> added the comment: Wondering the same thing myself, and yes sqlite3_column_type() by itself doesn't seem expensive. I assumed in general it was to allow more responsiveness for apps with huge number of columns (i.e. large tuple size). But we have about 20-25 columns and so I was going to try removing it and seeing the results. In any case, it seems, fewer GIL acquire/releases will help with throughput. Are there any guidelines on when GIL should be released? Re PyTuple_SET_ITEM...yes that's also a possibility but it would then hide genuine bugs. ---------- versions: +Python 2.6 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Thu Jun 28 19:36:46 2012 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 28 Jun 2012 17:36:46 +0000 Subject: [issue15077] Regexp match goes into infinite loop In-Reply-To: <1339756870.03.0.464046287951.issue15077@psf.upfronthosting.co.za> Message-ID: <1340905006.55.0.276660858427.issue15077@psf.upfronthosting.co.za> Matthew Barnett <python at mrabarnett.plus.com> added the comment: It's not a bug, it's a pathological regex (i.e. it causes catastrophic backtracking). It also works correctly in the "regex" module. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15077> _______________________________________ From report at bugs.python.org Thu Jun 28 19:39:38 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 28 Jun 2012 17:39:38 +0000 Subject: [issue15219] Leak in "_hashlib.new()" if argument is not a string In-Reply-To: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za> Message-ID: <1340905178.96.0.212461427919.issue15219@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Here is a test, which fails when I run regrtest with leak detection: ./python -m test.regrtest -R:: test_hashlib ---------- keywords: +patch nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file26203/hashlib-leak.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15219> _______________________________________ From report at bugs.python.org Thu Jun 28 19:40:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 17:40:06 +0000 Subject: [issue15108] ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function In-Reply-To: <1340904970.5.0.248320618591.issue15108@psf.upfronthosting.co.za> Message-ID: <1340905152.3379.8.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Are there any guidelines on when GIL should be released? The GIL should be released: - for CPU-heavy external functions (e.g. compression, cryptography) - for external functions which wait for I/O > Re PyTuple_SET_ITEM...yes that's also a possibility but it would then > hide genuine bugs. Well, as long as your monitor only increfs the tuple and doesn't mutate it, there shouldn't be any problem. We use PyTuple_SET_ITEM in many other places. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15108> _______________________________________ From report at bugs.python.org Thu Jun 28 19:57:25 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 17:57:25 +0000 Subject: [issue13532] In IDLE, sys.stdout.write and sys.stderr can write any pickleable object In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za> Message-ID: <1340906245.47.0.866252997569.issue13532@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Does anyone know a good way to make the exception render as: "must be str, not int" instead of "must be str, not <class 'int'>" ? raise TypeError('must be str, not %s' % type(s).__name__) ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13532> _______________________________________ From report at bugs.python.org Thu Jun 28 20:02:04 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 18:02:04 +0000 Subject: [issue13532] In IDLE, sys.stdout.write and sys.stderr can write any pickleable object In-Reply-To: <1323094063.21.0.960772272227.issue13532@psf.upfronthosting.co.za> Message-ID: <1340906524.7.0.1873267817.issue13532@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: > The following code prevents another prompt from appearing: And this a more serious issue concerns 3.3. ---------- versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13532> _______________________________________ From report at bugs.python.org Thu Jun 28 20:26:18 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 28 Jun 2012 18:26:18 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> Message-ID: <1340907978.84.0.481161963462.issue15217@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Thu Jun 28 20:27:37 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 28 Jun 2012 18:27:37 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1340908057.66.0.676480950027.issue15216@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15216> _______________________________________ From report at bugs.python.org Thu Jun 28 20:28:11 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 28 Jun 2012 18:28:11 +0000 Subject: [issue15218] Check for all necessary dir_fd and follow_symlinks functions In-Reply-To: <1340894159.39.0.860885591292.issue15218@psf.upfronthosting.co.za> Message-ID: <1340908091.64.0.799293653664.issue15218@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15218> _______________________________________ From report at bugs.python.org Thu Jun 28 20:32:33 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Jun 2012 18:32:33 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1340908353.28.0.456820908793.issue5765@psf.upfronthosting.co.za> Terry J. Reedy <tjreedy at udel.edu> added the comment: In 3.3.3a4 and b1, with original 30000, I no longer get TypeError, but box "python(w).exe has stopped working". So either Win7, 64 bit, on machine with much more memory makes a diffence, or something in code reverted. Is this really a security issue? (If so, up priority?) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5765> _______________________________________ From report at bugs.python.org Thu Jun 28 20:50:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jun 2012 18:50:51 +0000 Subject: [issue5765] stack overflow evaluating eval("()" * 30000) In-Reply-To: <1239838657.22.0.326859227165.issue5765@psf.upfronthosting.co.za> Message-ID: <1340909451.8.0.880590016089.issue5765@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: I don't think that eval is used in security context. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5765> _______________________________________ From report at bugs.python.org Thu Jun 28 22:03:46 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 28 Jun 2012 20:03:46 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> Message-ID: <1340913826.46.0.696601959866.issue15217@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I want to mark this as wontfix. >>> os.listdir in os.supports_fd True The concept we're struggling with here: is the "fd" you pass in to os.listdir a "dir_fd"? I claim that it isn't. I'm trying to enforce the concept, in both the documentation and the code, that "dir_fd" is a directory fd *accompanying a path*. With listdir, it isn't accompanied by a path, it replaces the path. So I suggest it's not a "dir_fd", it's just an "fd" which by sheer coincidence happens to reference a directory. I proposed making os.listdir accept dir_fd, and internally use open and listdir to emulate the behavior. But someone (Antoine?) rightly pointed out, this would break the guideline that POSIX os.* functions on Unix-y OSes are atomic. I might go so far as to say this needs a documentation fix. But I won't condone any sort of code fix (like adding os.listdir to os.supports_dir_fd). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Thu Jun 28 22:23:36 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 20:23:36 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340913826.46.0.696601959866.issue15217@psf.upfronthosting.co.za> Message-ID: <5D765060-24DB-46BE-B5BC-F662AC74BC46@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: I don't really care about the name but I'd really like some way to check whether listdir supports fds. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Thu Jun 28 22:38:04 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 28 Jun 2012 20:38:04 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> Message-ID: <1340915884.9.0.0874579618734.issue15217@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Like I said: use os.supports_fd. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Thu Jun 28 23:11:32 2012 From: report at bugs.python.org (Patrick Westerhoff) Date: Thu, 28 Jun 2012 21:11:32 +0000 Subject: [issue14133] improved PEP 409 implementation In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za> Message-ID: <1340917892.42.0.00348547383808.issue14133@psf.upfronthosting.co.za> Patrick Westerhoff <PatrickWesterhoff at gmail.com> added the comment: Alright, thought so but wanted a confirmation anyway ? thanks a lot :D ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14133> _______________________________________ From report at bugs.python.org Thu Jun 28 23:12:43 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 28 Jun 2012 21:12:43 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340915884.9.0.0874579618734.issue15217@psf.upfronthosting.co.za> Message-ID: <E5C2D521-ECB2-4050-88DB-D18D00E0B4DB@ox.cx> Hynek Schlawack <hs at ox.cx> added the comment: Ah sorry, that wasn't in the mail (stupid >>>). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Thu Jun 28 23:19:24 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Jun 2012 21:19:24 +0000 Subject: [issue15220] Reduce parsing overhead in email.feedparser.BufferedSubFile Message-ID: <1340918364.55.0.874046229823.issue15220@psf.upfronthosting.co.za> New submission from R. David Murray <rdmurray at bitdance.com>: The idea for the attached patch comes from the QNX development team. In their measurements, replacing the re.split-plus-line-reassembly code in BufferedSubFile with str.splitlines provided a 30% reduction in email parsing time. The code is also a lot more readable, which is a plus. The patch is simple enough, and the improvement is large enough, that I'd like to apply this to all active branches. ---------- components: email files: feedparser_performance.patch keywords: patch messages: 164295 nosy: barry, r.david.murray priority: normal severity: normal stage: patch review status: open title: Reduce parsing overhead in email.feedparser.BufferedSubFile type: performance versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26204/feedparser_performance.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15220> _______________________________________ From report at bugs.python.org Thu Jun 28 23:28:36 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Thu, 28 Jun 2012 21:28:36 +0000 Subject: [issue15204] Deprecate the 'U' open mode In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za> Message-ID: <1340918916.39.0.958081555109.issue15204@psf.upfronthosting.co.za> Nadeem Vawda <nadeem.vawda at gmail.com> added the comment: +1 for the general idea of deprecating and eventually removing the "U" modes. But I agree with David, that it doesn't make sense to have separate steps for 3.5 and 3.6/4.0. If you make the code raise an exception when "U" is used, how is that different from what will happen when you remove the code for processing it? Surely we want it to eventually be treated just like any other invalid mode string? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15204> _______________________________________ From report at bugs.python.org Fri Jun 29 01:01:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 23:01:50 +0000 Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does not support the buffer interface In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za> Message-ID: <1340924510.3.0.199919183384.issue10571@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- stage: test needed -> patch review versions: +Python 2.7 -Python 3.4 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10571> _______________________________________ From report at bugs.python.org Fri Jun 29 01:03:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 23:03:12 +0000 Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does not support the buffer interface In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za> Message-ID: <1340924592.9.0.39818760303.issue10571@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- versions: -Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10571> _______________________________________ From report at bugs.python.org Fri Jun 29 01:07:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jun 2012 23:07:52 +0000 Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does not support the buffer interface In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za> Message-ID: <E1SkNoU-0004db-Dh@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset ef16a3db4628 by Antoine Pitrou in branch '3.2': Issue #10571: Fix the "--sign" option of distutils' upload command. http://hg.python.org/cpython/rev/ef16a3db4628 New changeset b45f105dbdfb by Antoine Pitrou in branch 'default': Issue #10571: Fix the "--sign" option of distutils' upload command. http://hg.python.org/cpython/rev/b45f105dbdfb ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10571> _______________________________________ From report at bugs.python.org Fri Jun 29 01:08:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 23:08:13 +0000 Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does not support the buffer interface In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za> Message-ID: <1340924893.68.0.803417745231.issue10571@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Committed. Thank you Jakub! ---------- nosy: +pitrou resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10571> _______________________________________ From report at bugs.python.org Fri Jun 29 01:14:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Jun 2012 23:14:23 +0000 Subject: [issue15219] Leak in "_hashlib.new()" if argument is not a string In-Reply-To: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za> Message-ID: <1340925263.72.0.0741098178163.issue15219@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Looks good to me. ---------- assignee: -> amaury.forgeotdarc nosy: +pitrou stage: -> commit review _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15219> _______________________________________ From report at bugs.python.org Fri Jun 29 01:45:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jun 2012 23:45:56 +0000 Subject: [issue15219] Leak in "_hashlib.new()" if argument is not a string In-Reply-To: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za> Message-ID: <E1SkOPK-0007In-Tw@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 49dee01d72f9 by Amaury Forgeot d'Arc in branch '2.7': Issue #15219: Fix a reference leak when hashlib.new() is called with http://hg.python.org/cpython/rev/49dee01d72f9 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15219> _______________________________________ From report at bugs.python.org Fri Jun 29 01:50:37 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 28 Jun 2012 23:50:37 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> Message-ID: <1340927437.6.0.336539996748.issue15217@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: I'm closing this. os.listdir should not be listed in supports_dir_fd, because it has no dir_fd parameter. For reference, we discussed all this previously in issue #15176. ---------- resolution: -> invalid stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Fri Jun 29 01:53:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Jun 2012 23:53:45 +0000 Subject: [issue15219] Leak in "_hashlib.new()" if argument is not a string In-Reply-To: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za> Message-ID: <E1SkOWs-0007nW-S8@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset c974c99acdf5 by Amaury Forgeot d'Arc in branch 'default': Port tests from Issue #15219, and verify we don't have a reference leak. http://hg.python.org/cpython/rev/c974c99acdf5 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15219> _______________________________________ From report at bugs.python.org Fri Jun 29 01:54:31 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 28 Jun 2012 23:54:31 +0000 Subject: [issue15219] Leak in "_hashlib.new()" if argument is not a string In-Reply-To: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za> Message-ID: <1340927671.28.0.838302923873.issue15219@psf.upfronthosting.co.za> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment: Fixed in 2.7, and ported test to 3.3. Thanks for the report and the fix! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15219> _______________________________________ From report at bugs.python.org Fri Jun 29 02:03:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Jun 2012 00:03:52 +0000 Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za> Message-ID: <E1SkOgg-0008Sn-Gc@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 9854520c8200 by Antoine Pitrou in branch '3.2': Issue #5067: improve some json error messages. http://hg.python.org/cpython/rev/9854520c8200 New changeset 7523ab4e6e06 by Antoine Pitrou in branch 'default': Issue #5067: improve some json error messages. http://hg.python.org/cpython/rev/7523ab4e6e06 New changeset 7762816e3fcd by Antoine Pitrou in branch '2.7': Issue #5067: improve some json error messages. http://hg.python.org/cpython/rev/7762816e3fcd ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5067> _______________________________________ From report at bugs.python.org Fri Jun 29 02:04:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 00:04:20 +0000 Subject: [issue5067] Error msg from using wrong quotes in JSON is unhelpful In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za> Message-ID: <1340928260.31.0.46912058722.issue5067@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Committed now. Thanks Serhiy for the patch! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5067> _______________________________________ From report at bugs.python.org Fri Jun 29 02:04:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 00:04:48 +0000 Subject: [issue15145] Faster *_find_max_char In-Reply-To: <1340398318.47.0.89388206382.issue15145@psf.upfronthosting.co.za> Message-ID: <1340928288.23.0.415583939509.issue15145@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15145> _______________________________________ From report at bugs.python.org Fri Jun 29 02:05:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 00:05:04 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1340928304.65.0.618483860827.issue13968@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13968> _______________________________________ From report at bugs.python.org Fri Jun 29 02:05:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 00:05:13 +0000 Subject: [issue15071] TLS get keys and randoms In-Reply-To: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za> Message-ID: <1340928313.45.0.425191304648.issue15071@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15071> _______________________________________ From report at bugs.python.org Fri Jun 29 02:05:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 00:05:46 +0000 Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za> Message-ID: <1340928346.56.0.368184504728.issue11943@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11943> _______________________________________ From report at bugs.python.org Fri Jun 29 02:11:24 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 29 Jun 2012 00:11:24 +0000 Subject: [issue15220] Reduce parsing overhead in email.feedparser.BufferedSubFile In-Reply-To: <1340918364.55.0.874046229823.issue15220@psf.upfronthosting.co.za> Message-ID: <1340928684.96.0.707341889451.issue15220@psf.upfronthosting.co.za> Jes?s Cea Avi?n <jcea at jcea.es> added the comment: This is a performance enhancement. Out of question for 3.2. Python 3.3 is in beta now, and this would be considered a new feature, but I think it is pretty safe to apply. I am +1 to applying it. Personally I would apply it to 2.7 too, but current official position is "bug fixes only". We have rejected performance improvements for 2.7 in the past, for this reason. ---------- nosy: +jcea versions: -Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15220> _______________________________________ From report at bugs.python.org Fri Jun 29 02:19:49 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 29 Jun 2012 00:19:49 +0000 Subject: [issue15221] os.path.is*() may return False if path can't be accessed Message-ID: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' <g.rodola at gmail.com>: It seems a doc fix is the best way to go, in which case I leave this one to a native English speaker: http://mail.python.org/pipermail/python-dev/2012-June/120788.html Alternatively a new 'strict' parameter has been proposed as a workaround: http://mail.python.org/pipermail/python-dev/2012-June/120800.html ---------- assignee: docs at python components: Documentation messages: 164307 nosy: christian.heimes, docs at python, eric.araujo, ezio.melotti, georg.brandl, giampaolo.rodola, ncoghlan priority: normal severity: normal status: open title: os.path.is*() may return False if path can't be accessed versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15221> _______________________________________ From report at bugs.python.org Fri Jun 29 02:39:38 2012 From: report at bugs.python.org (Luke Carrier) Date: Fri, 29 Jun 2012 00:39:38 +0000 Subject: [issue9216] FIPS support for hashlib In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za> Message-ID: <1340930378.75.0.221768275871.issue9216@psf.upfronthosting.co.za> Luke Carrier <hey at lukecarrier.me> added the comment: I've not done enough digging on the issue I'm presently experiencing to draw any conclusions make any suggestions, but this change seems to break the present distribute module (version 0.6.27). It appears it will likely break a great deal of other code too. I've pasted the relevant output here and attached the full traceback. File "/usr/lib64/python3.2/hashlib.py", line 112, in __get_openssl_constructor f(usedforsecurity=False) TypeError: openssl_md5() takes no keyword arguments Whilst I agree with the notion behind this change, Fedora's quick actions have led to me spending the best part of an hour of the night before ship day diagnosing issues caused by undocumented (or at least under-documented) changes to code I haven't written or interfaced with. _Please_ publicise the change a little better? Pretty please!? ---------- nosy: +lukecarrier Added file: http://bugs.python.org/file26205/virtualenv_distribute _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9216> _______________________________________ From report at bugs.python.org Fri Jun 29 02:43:24 2012 From: report at bugs.python.org (Cameron Simpson) Date: Fri, 29 Jun 2012 00:43:24 +0000 Subject: [issue15221] os.path.is*() may return False if path can't be accessed In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za> Message-ID: <1340930604.2.0.780884505341.issue15221@psf.upfronthosting.co.za> Changes by Cameron Simpson <cs at zip.com.au>: ---------- nosy: +cameron _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15221> _______________________________________ From report at bugs.python.org Fri Jun 29 02:50:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 00:50:26 +0000 Subject: [issue15221] os.path.is*() may return False if path can't be accessed In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za> Message-ID: <1340931026.13.0.894741475344.issue15221@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: -1 on a "strict" parameter. This is a pointless obfuscation of the API. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15221> _______________________________________ From report at bugs.python.org Fri Jun 29 03:14:48 2012 From: report at bugs.python.org (Frank Ling) Date: Fri, 29 Jun 2012 01:14:48 +0000 Subject: [issue15215] socket module setblocking and settimeout problem In-Reply-To: <1340868379.68.0.473827205648.issue15215@psf.upfronthosting.co.za> Message-ID: <1340932488.32.0.516989183975.issue15215@psf.upfronthosting.co.za> Frank Ling <ufwtlsb at gmail.com> added the comment: how to create socket and have block timeout mode? self.socket.setblocking(1) self.socket.settimeout(1) this program is error? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15215> _______________________________________ From report at bugs.python.org Fri Jun 29 03:18:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 01:18:37 +0000 Subject: [issue15215] socket module setblocking and settimeout problem In-Reply-To: <1340868379.68.0.473827205648.issue15215@psf.upfronthosting.co.za> Message-ID: <1340932717.31.0.101862734514.issue15215@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Frank, this bug tracker is not for posting general programming questions. Please see http://mail.python.org/mailman/listinfo/python-list instead. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15215> _______________________________________ From report at bugs.python.org Fri Jun 29 05:54:52 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 29 Jun 2012 03:54:52 +0000 Subject: [issue15221] os.path.is*() may return False if path can't be accessed In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za> Message-ID: <1340942092.71.0.125281108715.issue15221@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: The os.path.exists() docs already cover all the gory details of when it may be false due to limited permissions. The is* docs refer to this by their use of the word "existing", but that's probably too subtle. I suggest adding an extra sentence to the docs of all affected functions: "This always returns False if os.path.exists(path) returns False." ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15221> _______________________________________ From report at bugs.python.org Fri Jun 29 07:14:58 2012 From: report at bugs.python.org (lilydjwg) Date: Fri, 29 Jun 2012 05:14:58 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1340946898.96.0.620254223127.issue9559@psf.upfronthosting.co.za> Changes by lilydjwg <lilydjwg at gmail.com>: ---------- nosy: +lilydjwg _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Fri Jun 29 07:47:05 2012 From: report at bugs.python.org (lilydjwg) Date: Fri, 29 Jun 2012 05:47:05 +0000 Subject: [issue15222] mailbox.mbox writes without end-of-line at the file end. Message-ID: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> New submission from lilydjwg <lilydjwg at gmail.com>: I find that when mbox writes mails back, it loses the last end-of-line, making appending new mails to the mbox becomes incorrect. I'm using Linux. In _singlefileMailbox.flush(), when writing the mbox, it loses the last byte ('\n') at the end of each message (because the position from '_toc' is inclusive), and mbox._pre_message_hook() adds it back, but only between two messages. So the last message ends without a '\n'. ---------- components: Library (Lib) messages: 164313 nosy: lilydjwg priority: normal severity: normal status: open title: mailbox.mbox writes without end-of-line at the file end. type: behavior versions: Python 3.2 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15222> _______________________________________ From report at bugs.python.org Fri Jun 29 07:58:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 Jun 2012 05:58:23 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340913826.46.0.696601959866.issue15217@psf.upfronthosting.co.za> Message-ID: <1340949524.2515.9.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > I proposed making os.listdir accept dir_fd, and internally use open and listdir to emulate the behavior. Hmm, I understood the issue as the request for adding dir_fd argument to os.listdir. openat+fdopendir+readdir+closedir+close or, in Python, def listdir2(path, dir_fd=None): fd = os.open(path, dir_fd) try: return os.listdir(fd) finally: os.close(fd) > But someone (Antoine?) rightly pointed out, this would break the guideline that POSIX os.* functions on Unix-y OSes are atomic. os.listdir is not atomic. opendir+readdir+closedir+close or fdup +fdopendir+readdir+closedir+close. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Fri Jun 29 08:25:43 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 29 Jun 2012 06:25:43 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> Message-ID: <1340951143.81.0.164502606652.issue15217@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: Storchaka: please take it up with Antoine, he's the defender of the realm for POSIX-functions-are-atomic iirc. I'd be happy with dir_fd for os.listdir, though it may be too late for 3.3 anyway. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Fri Jun 29 08:29:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Jun 2012 06:29:35 +0000 Subject: [issue15218] Check for all necessary dir_fd and follow_symlinks functions In-Reply-To: <1340894159.39.0.860885591292.issue15218@psf.upfronthosting.co.za> Message-ID: <E1SkUhv-0007NH-FS@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 992be49127e1 by Hynek Schlawack in branch 'default': Check for all used fd-based functions in shutil.rmdir, closes #15218 http://hg.python.org/cpython/rev/992be49127e1 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15218> _______________________________________ From report at bugs.python.org Fri Jun 29 08:32:45 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 29 Jun 2012 06:32:45 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> Message-ID: <1340951565.7.0.603177694949.issue15217@psf.upfronthosting.co.za> Hynek Schlawack <hs at ox.cx> added the comment: Just in my defense: Larry suggested in msg164245 to me to check for listdir in supports_dir_fd so I just assumed it's broken as it didn't work. I'm totally fine with the current behavior, the discussion about dir_fd support in listdir isn't what I intended with this ticket. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Fri Jun 29 09:20:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 Jun 2012 07:20:47 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340951143.81.0.164502606652.issue15217@psf.upfronthosting.co.za> Message-ID: <1340954458.2515.19.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Storchaka: please take it up with Antoine, he's the defender of the realm for POSIX-functions-are-atomic iirc. I'd be happy with dir_fd for os.listdir, though it may be too late for 3.3 anyway. I know that this is possible (and relatively easy), but I don't think it's useful. If you use at-functions, then after listdir should be at-function, and for this purpose you need to get directory's fd in any case. I don't see useful use cases for listdir(name, dir_fd). So I'm not going to open a new issue and I'm happy with closing this one. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Fri Jun 29 10:24:26 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 29 Jun 2012 08:24:26 +0000 Subject: [issue15217] os.listdir is missing in os.supports_dir_fd In-Reply-To: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za> Message-ID: <1340958266.53.0.54521768104.issue15217@psf.upfronthosting.co.za> Larry Hastings <larry at hastings.org> added the comment: WFM. That is, unless people want to bring up additional only-tangentially-related topics to annoy Hynek ;-) How about those <local sports team>? They're really having a year of it, aren't they! ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15217> _______________________________________ From report at bugs.python.org Fri Jun 29 11:36:44 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 29 Jun 2012 09:36:44 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> Message-ID: <1340962604.11.0.34118646032.issue15009@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: Let me address this one thing at a time, the point on smb really confused me and I got into thinking that how smb (being more common), the issue was not raised. Looks smb url will always start with smb:// (// are the requirements for identified netloc, empty or otherwise) and cases for smb are fine - http://tools.ietf.org/html/draft-crhertel-smb-url-00 That said, the dependency on uses_netloc has come many times and I am still looking for way to remove the dependency without affecting the previous parsing behaviors and ofcourse tests. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15009> _______________________________________ From report at bugs.python.org Fri Jun 29 12:55:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Jun 2012 10:55:35 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <E1SkYrN-0001JF-C2@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 3d7a75e945ee by Petri Lehtinen in branch '2.7': #9559: Don't call _pre_mailbox_hook more than once http://hg.python.org/cpython/rev/3d7a75e945ee New changeset 7cf5a629fde2 by Petri Lehtinen in branch '3.2': #9559: Don't call _pre_mailbox_hook more than once http://hg.python.org/cpython/rev/7cf5a629fde2 New changeset 5a0ec296b287 by Petri Lehtinen in branch 'default': #9559: Don't call _pre_mailbox_hook more than once http://hg.python.org/cpython/rev/5a0ec296b287 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Fri Jun 29 13:07:33 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 29 Jun 2012 11:07:33 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> Message-ID: <1340968053.12.0.194484238252.issue15009@psf.upfronthosting.co.za> Senthil Kumaran <senthil at uthcode.com> added the comment: Look at the following two bugs which dwelt on similar issues: Issue8339 and Issue7904 and in one message particular, msg102737, I seem to have come to a conclusion that " I don't see that 'x://' and 'x:///y' qualifies as valid URLS as per RFC 3986" and it applies to this bug too where the url is requested as yelp:///x Does yelp://localhost/x be a way to access in your case? That would be consistent with specification. Or in your code, you can add 'yelp' to uses_netloc list and then expect the desired behavior. from urlparse import uses_netloc uses_netloc.append('yelp') I understand that, using of the uses_netloc is a limitation, but given the requirements of both absolute and relative parsing that lists has served a useful behavior. I would like to close this one for the above mention points and open a feature request (or convert this to a feature request) which asks to remove the dependency of uses_netloc in urlparse. Does this resolution sound okay? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15009> _______________________________________ From report at bugs.python.org Fri Jun 29 13:13:01 2012 From: report at bugs.python.org (Matthias Klose) Date: Fri, 29 Jun 2012 11:13:01 +0000 Subject: [issue14327] replace use of uname in the configury with macros set by AC_CANONICAL_HOST In-Reply-To: <1331842473.11.0.734789766158.issue14327@psf.upfronthosting.co.za> Message-ID: <1340968381.18.0.64060168241.issue14327@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: that was checked in ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14327> _______________________________________ From report at bugs.python.org Fri Jun 29 13:15:52 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 29 Jun 2012 11:15:52 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1340968552.77.0.47543680768.issue9559@psf.upfronthosting.co.za> Changes by Petri Lehtinen <petri at digip.org>: ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9559> _______________________________________ From report at bugs.python.org Fri Jun 29 13:31:24 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 29 Jun 2012 11:31:24 +0000 Subject: [issue15222] mailbox.mbox writes without end-of-line at the file end. In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1340969484.29.0.765556595043.issue15222@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: I cannot reproduce this on 3.2 or 2.7. My mailboxes always have an ending newline if the last message also has it. Only if the last message doesn't end in a newline, there's no newline in the end of the mbox. Furthermore, if a message doesn't end with a newline, there's no blank line between that message and the next. ---------- nosy: +petri.lehtinen status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15222> _______________________________________ From report at bugs.python.org Fri Jun 29 13:51:27 2012 From: report at bugs.python.org (Rainer Schaaf) Date: Fri, 29 Jun 2012 11:51:27 +0000 Subject: [issue11626] Py_LIMITED_API on windows: unresolved symbol __imp___PyArg_ParseTuple_SizeT In-Reply-To: <1300733675.89.0.959184580863.issue11626@psf.upfronthosting.co.za> Message-ID: <1340970687.15.0.821027000051.issue11626@psf.upfronthosting.co.za> Rainer Schaaf <rjs at pdflib.com> added the comment: Thanks, I tested it with 3.3beta1 and it works fine now. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue11626> _______________________________________ From report at bugs.python.org Fri Jun 29 14:16:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Jun 2012 12:16:23 +0000 Subject: [issue5346] mailbox._singlefileMailbox.flush doesn't preserve file rights In-Reply-To: <1235317721.52.0.542523133974.issue5346@psf.upfronthosting.co.za> Message-ID: <E1Ska7Z-0002VN-SH@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 69f654f718f4 by Petri Lehtinen in branch '2.7': #5346: Preserve permissions of mbox, MMDF and Babyl mailbox files on flush() http://hg.python.org/cpython/rev/69f654f718f4 New changeset 13fb85ef0eea by Petri Lehtinen in branch '3.2': #5346: Preserve permissions of mbox, MMDF and Babyl mailbox files on flush() http://hg.python.org/cpython/rev/13fb85ef0eea New changeset 23beb7f8561a by Petri Lehtinen in branch 'default': #5346: Preserve permissions of mbox, MMDF and Babyl mailbox files on flush() http://hg.python.org/cpython/rev/23beb7f8561a ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5346> _______________________________________ From report at bugs.python.org Fri Jun 29 14:16:46 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 29 Jun 2012 12:16:46 +0000 Subject: [issue5346] mailbox._singlefileMailbox.flush doesn't preserve file rights In-Reply-To: <1235317721.52.0.542523133974.issue5346@psf.upfronthosting.co.za> Message-ID: <1340972206.5.0.721898690378.issue5346@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Fixed. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue5346> _______________________________________ From report at bugs.python.org Fri Jun 29 14:25:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 12:25:21 +0000 Subject: [issue9216] FIPS support for hashlib In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za> Message-ID: <1340972721.02.0.752010759669.issue9216@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > _Please_ publicise the change a little better? Pretty please!? This changes haven't been committed in Python, so you probably want to post on the Fedora bug tracker instead. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9216> _______________________________________ From report at bugs.python.org Fri Jun 29 16:21:24 2012 From: report at bugs.python.org (lilydjwg) Date: Fri, 29 Jun 2012 14:21:24 +0000 Subject: [issue15222] mailbox.mbox writes without end-of-line at the file end. In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1340979684.58.0.40142206607.issue15222@psf.upfronthosting.co.za> lilydjwg <lilydjwg at gmail.com> added the comment: I think I got something wrong. It seems that it only happens when the last message is deleted. I've also made up a sample mbox attached. The code to reproduce: from mailbox import mbox mb = mbox('mbox') del mb[len(mb)-1] mb.close() ---------- status: pending -> open Added file: http://bugs.python.org/file26206/mbox _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15222> _______________________________________ From report at bugs.python.org Fri Jun 29 16:41:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 14:41:35 +0000 Subject: [issue15220] Reduce parsing overhead in email.feedparser.BufferedSubFile In-Reply-To: <1340918364.55.0.874046229823.issue15220@psf.upfronthosting.co.za> Message-ID: <1340980895.67.0.144351703405.issue15220@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Realistically, any performance improvement is 3.4-only now. ---------- nosy: +pitrou versions: +Python 3.4 -Python 2.7, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15220> _______________________________________ From report at bugs.python.org Fri Jun 29 16:55:47 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 14:55:47 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340981747.57.0.12900529157.issue1677@psf.upfronthosting.co.za> Tim Golden <mail at timgolden.me.uk> added the comment: And here's the patch against 3.2 (essentially the 2.7 patch but allowing for the removal of RISCOS support) ---------- Added file: http://bugs.python.org/file26207/issue1677-python32.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Fri Jun 29 17:12:45 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 15:12:45 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340982765.9.0.11924836399.issue1677@psf.upfronthosting.co.za> Changes by Tim Golden <mail at timgolden.me.uk>: Removed file: http://bugs.python.org/file26207/issue1677-python32.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Fri Jun 29 17:15:22 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 15:15:22 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340982922.95.0.59188986861.issue1677@psf.upfronthosting.co.za> Changes by Tim Golden <mail at timgolden.me.uk>: Added file: http://bugs.python.org/file26208/issue1677-python32.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Fri Jun 29 18:05:27 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 29 Jun 2012 16:05:27 +0000 Subject: [issue15223] datetime instances lack __module__ attribute Message-ID: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za> New submission from Chris Jerdonek <chris.jerdonek at gmail.com>: Instances of datetime.datetime don't seem to have the '__module__' attribute even though the datetime class itself does. This seems to contradict Section 3.2 of the Python documentation about the standard type hierarchy (in the subsection called "Class instances"): http://docs.python.org/dev/reference/datamodel.html#the-standard-type-hierarchy "A class instance has a namespace implemented as a dictionary which is the first place in which attribute references are searched. When an attribute is not found there, and the instance?s class has an attribute by that name, the search continues with the class attributes." Instances of other classes defined in the standard library do have the attribute. The session below illustrates the issue: Python 3.3.0a4 (v3.3.0a4:7c51388a3aa7, May 30 2012, 16:58:42) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> datetime.__module__ 'datetime' >>> d = datetime(2000, 1, 1) >>> d.__class__ <class 'datetime.datetime'> >>> d.__module__ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'datetime.datetime' object has no attribute '__module__' ---------- components: Library (Lib) messages: 164332 nosy: cjerdonek priority: normal severity: normal status: open title: datetime instances lack __module__ attribute type: behavior versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15223> _______________________________________ From report at bugs.python.org Fri Jun 29 18:37:03 2012 From: report at bugs.python.org (Yclept Nemo) Date: Fri, 29 Jun 2012 16:37:03 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) Message-ID: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> New submission from Yclept Nemo <orbisvicis at gmail.com>: Python 3.3 expands the range class but I would find some additional methods useful: min/max: provides O(1) time __and__: provides intersection: Range(...) & Range(...) examples: intersection #1: a=Range.Range(9,58,4) b=Range.Range(15,69,6) c=a&b print(c) Range(21, 69, 12) list(c) [21, 33, 45, 57] intersection #2: a=Range.Range(-75,-7,4) b=Range.Range(-111, -26, 6) c=a&b print(c) Range(-75, -15, 12) list(c) [-75, -63, -51, -39, -27] intersection #3: a=Range.Range(58,9,-4) b=Range.Range(15,69,6) c=a&b print(c) Range(0, 0, 1) list(c) [] I've attached an example Range class implemented in python that includes the min, max, and __and__ functions. It should be useful because the intersection algorithm is complicated. Extending the range class was a requirement for a python 3.2 project and hopefully python 3.4 can benefit. ---------- components: None files: Range.py messages: 164333 nosy: Yclept.Nemo priority: normal severity: normal status: open title: Range: Additional Methods (min/max/__and__) type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26209/Range.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Fri Jun 29 19:02:26 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 29 Jun 2012 17:02:26 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> Message-ID: <1340989346.45.0.0351452219527.issue15224@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: max and min for a range object are already O(1) one-liners: >>> a = range(3, 21, 5) >>> a[-1] if a.step > 0 else a[0] # max(a) 18 >>> a[0] if a.step > 0 else a[-1] # min(a) 3 As for __and__, it doesn't feel like a particularly natural operation to me, given that a range object represents an *ordered* sequence of integers rather than just a subset. For example, what should the first element of range(7, -3, -2) & range(10) be? 7 or 1? And why? ---------- nosy: +mark.dickinson _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Fri Jun 29 19:20:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 17:20:56 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1340990456.98.0.446851341794.issue1677@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Tim, you've got tabs in your 3.3 patch. Other than that, I wonder why you wait for 100 ms in 3.3 but 10 ms in the other versions? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Fri Jun 29 19:23:16 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 17:23:16 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1340990456.98.0.446851341794.issue1677@psf.upfronthosting.co.za> Message-ID: <4FEDE47E.7030708@timgolden.me.uk> Tim Golden <mail at timgolden.me.uk> added the comment: > Tim, you've got tabs in your 3.3 patch. Thanks, Antoine. I'll sort that out. (Goodness know how; none of my editors use tabs). > Other than that, I wonder why you wait for 100 ms in 3.3 but 10 ms in the other versions? Ummm. Because they were written separately and I didn't check carefully enough? I'll drop back to 10ms all round; it never took more than 3 1-ms loops to fire in testing. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Fri Jun 29 19:43:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 Jun 2012 17:43:45 +0000 Subject: [issue9239] zipfile: truncating comment can corrupt the zipfile In-Reply-To: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za> Message-ID: <1340991825.78.0.693209027475.issue9239@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: Anyone may close the issue as "out of date"? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9239> _______________________________________ From report at bugs.python.org Fri Jun 29 19:45:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 17:45:58 +0000 Subject: [issue9670] Exceed Recursion Limit in Thread In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za> Message-ID: <1340991958.33.0.378340212366.issue9670@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Re-opening. The test fails on 3.2 on the new Lion buildbot (but neither on 3.3 nor 2.7, it seems). See http://buildbot.python.org/all/builders/AMD64%20Lion%203.2 ---------- nosy: +lukasz.langa, pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9670> _______________________________________ From report at bugs.python.org Fri Jun 29 19:46:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 17:46:20 +0000 Subject: [issue9670] Exceed Recursion Limit in Thread In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za> Message-ID: <1340991980.07.0.746265788688.issue9670@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- status: closed -> open _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9670> _______________________________________ From report at bugs.python.org Fri Jun 29 19:47:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 17:47:24 +0000 Subject: [issue9239] zipfile: truncating comment can corrupt the zipfile In-Reply-To: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za> Message-ID: <1340992044.42.0.69806565047.issue9239@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > The bug is no longer there. Probably it is fixed in issue14399. Then the tests may still be added to test_zipfile? ---------- assignee: alanmcintyre -> nosy: +pitrou priority: high -> normal _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9239> _______________________________________ From report at bugs.python.org Fri Jun 29 19:54:09 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 29 Jun 2012 17:54:09 +0000 Subject: [issue15223] datetime instances lack __module__ attribute In-Reply-To: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za> Message-ID: <1340992449.77.0.00351648358793.issue15223@psf.upfronthosting.co.za> Chris Jerdonek <chris.jerdonek at gmail.com> added the comment: Also, FWIW, in PyPy the behavior is different. Datetime instances do have the __module__ attribute: Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 09 2012, 14:24:11) [PyPy 1.9.0] on darwin Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``pypy is the nuclear fusion of programming language implementation (pedronis)'' >>>> from datetime import datetime >>>> datetime.__module__ 'datetime' >>>> d = datetime(2000, 1, 1) >>>> d.__module__ 'datetime' ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15223> _______________________________________ From report at bugs.python.org Fri Jun 29 19:54:33 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 29 Jun 2012 17:54:33 +0000 Subject: [issue15223] datetime instances lack __module__ attribute In-Reply-To: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za> Message-ID: <1340992473.52.0.921886344067.issue15223@psf.upfronthosting.co.za> Changes by Chris Jerdonek <chris.jerdonek at gmail.com>: ---------- versions: +Python 2.7 -Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15223> _______________________________________ From report at bugs.python.org Fri Jun 29 19:55:46 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 29 Jun 2012 17:55:46 +0000 Subject: [issue15223] datetime instances lack __module__ attribute In-Reply-To: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za> Message-ID: <1340992546.18.0.827677302387.issue15223@psf.upfronthosting.co.za> Changes by Chris Jerdonek <chris.jerdonek at gmail.com>: ---------- versions: +Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15223> _______________________________________ From report at bugs.python.org Fri Jun 29 19:59:36 2012 From: report at bugs.python.org (pmoody) Date: Fri, 29 Jun 2012 17:59:36 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340992776.61.0.381201387213.issue14814@psf.upfronthosting.co.za> pmoody <python at hda3.com> added the comment: Reported externally, ipaddress tries to parse 4 character strings as bytes. https://groups.google.com/forum/?hl=en_US&fromgroups#!topic/ipaddr-py-dev/j6FkeJtsBz4 ---------- Added file: http://bugs.python.org/file26210/ipaddress-bytes-str.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Fri Jun 29 20:13:44 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 29 Jun 2012 18:13:44 +0000 Subject: [issue9670] Exceed Recursion Limit in Thread In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za> Message-ID: <1340993624.92.0.265880074627.issue9670@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: 3x is now using clang to compile on 10.7 Lion; 32 is failing back to the Xcode 4 default of llvm-gcc which has proved problematic fox 3x. Rather than tweak the test again, try appending a CC=clang to the ./configure for the 3.2 buildbot until the clang changes are backported. The builds should run faster, too, with clang. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9670> _______________________________________ From report at bugs.python.org Fri Jun 29 20:17:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 Jun 2012 18:17:32 +0000 Subject: [issue13790] In str.format an incorrect error message for list, tuple, dict, set In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za> Message-ID: <1340993852.12.0.3688715368.issue13790@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: >>> '%d' % ([],) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: %d format: a number is required, not list ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13790> _______________________________________ From report at bugs.python.org Fri Jun 29 20:26:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 18:26:02 +0000 Subject: [issue9670] Exceed Recursion Limit in Thread In-Reply-To: <1340993624.92.0.265880074627.issue9670@psf.upfronthosting.co.za> Message-ID: <1340994306.3387.8.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > try appending a CC=clang to the ./configure for the 3.2 buildbot until > the clang changes are backported. Ok, done that. Can someone watch the next builds? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9670> _______________________________________ From report at bugs.python.org Fri Jun 29 20:29:26 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 29 Jun 2012 18:29:26 +0000 Subject: [issue13790] In str.format an incorrect error message for list, tuple, dict, set In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za> Message-ID: <1340994566.92.0.459079076756.issue13790@psf.upfronthosting.co.za> Eric V. Smith <eric at trueblade.com> added the comment: Serhiy: I'm not sure what you're saying. At the point that str.format() is producing its error message, it doesn't know as much as %-formatting does about the original arguments, so it can't produce a similar message. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13790> _______________________________________ From report at bugs.python.org Fri Jun 29 20:32:00 2012 From: report at bugs.python.org (pmoody) Date: Fri, 29 Jun 2012 18:32:00 +0000 Subject: [issue14814] Implement PEP 3144 (the ipaddress module) In-Reply-To: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za> Message-ID: <1340994720.32.0.599705603581.issue14814@psf.upfronthosting.co.za> pmoody <python at hda3.com> added the comment: one more patch, superseding the last patch. also reported externally, the v6 parser would incorrectly parse some v6 addresses. http://code.google.com/p/ipaddr-py/issues/detail?id=97 ---------- Added file: http://bugs.python.org/file26211/ipaddress-bytes-str-v6-parsing.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14814> _______________________________________ From report at bugs.python.org Fri Jun 29 20:42:00 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 29 Jun 2012 18:42:00 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1340995320.24.0.311722260926.issue15139@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: Currently negative timeouts are treated as zero timeouts by Condition.wait(). The patches turns them into errors. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15139> _______________________________________ From report at bugs.python.org Fri Jun 29 20:49:40 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Fri, 29 Jun 2012 18:49:40 +0000 Subject: [issue15225] Add negative tests for passing str to hmac.HMAC and hmac.new Message-ID: <1340995780.51.0.208862174905.issue15225@psf.upfronthosting.co.za> New submission from Marc Abramowitz <msabramo at gmail.com>: I had been thinking of improving the error message for this case slightly -- and then couldn't find a test for this case so I'm adding one in the attached patch... ---------- components: Tests files: test_hmac.py.patch keywords: patch messages: 164348 nosy: Marc.Abramowitz priority: normal severity: normal status: open title: Add negative tests for passing str to hmac.HMAC and hmac.new versions: Python 3.3 Added file: http://bugs.python.org/file26212/test_hmac.py.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15225> _______________________________________ From report at bugs.python.org Fri Jun 29 20:52:10 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 29 Jun 2012 18:52:10 +0000 Subject: [issue15158] Add support for multi-character delimiters in csv In-Reply-To: <1340509645.86.0.375714044709.issue15158@psf.upfronthosting.co.za> Message-ID: <1340995930.12.0.785169631766.issue15158@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15158> _______________________________________ From report at bugs.python.org Fri Jun 29 20:53:41 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Fri, 29 Jun 2012 18:53:41 +0000 Subject: [issue15225] Add negative tests for passing str to hmac.HMAC and hmac.new In-Reply-To: <1340995780.51.0.208862174905.issue15225@psf.upfronthosting.co.za> Message-ID: <1340996021.11.0.359017633983.issue15225@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: And here is the tiny patch to make it clear in the error message which of the 3 arguments had the wrong type -- I follow the convention followed in some TypeErrors raised in Lib/zipfile.py ---------- Added file: http://bugs.python.org/file26213/hmac.py.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15225> _______________________________________ From report at bugs.python.org Fri Jun 29 20:55:53 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 29 Jun 2012 18:55:53 +0000 Subject: [issue15148] shutil.which() docstring could be clearer In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za> Message-ID: <1340996153.87.0.168055584084.issue15148@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- resolution: -> fixed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________ From report at bugs.python.org Fri Jun 29 20:57:58 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 29 Jun 2012 18:57:58 +0000 Subject: [issue15034] Devguide should document best practices for stdlib exceptions In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za> Message-ID: <1340996278.37.0.783545882502.issue15034@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>: ---------- nosy: +tshepang _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________ From report at bugs.python.org Fri Jun 29 21:22:24 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 29 Jun 2012 19:22:24 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1340997744.08.0.800686493987.issue15222@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: Since there's no empty line between the content of mail 2 and the "From " line of mail 3, the body of mail 2 isn't really terminated by a newline. Reading the message confirms this: >>> import mailbox >>> mbox = mailbox.mbox('mbox') >>> mbox[1].get_payload() 'The mail content of mail 2...' However, according to RFC 4155 this is a bug, as each message in a mbox must be terminated by an empty line. ---------- title: mailbox.mbox writes without end-of-line at the file end. -> mailbox.mbox writes without empty line after each message versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15222> _______________________________________ From report at bugs.python.org Fri Jun 29 21:53:25 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 29 Jun 2012 19:53:25 +0000 Subject: [issue15226] max( str ) should be fast with PEP 393 Message-ID: <1340999605.61.0.988726046922.issue15226@psf.upfronthosting.co.za> New submission from Glenn Linderman <v+python at g.nevcal.com>: This is stupid code, but it should be faster with PEP 393 than before, should it not? str = ' ' * 5000000 + "this is really a string example....wow!!!"; for ix in range( 9000 ): z = max(str) print("Max character: " + max(str)) While the new C API seems to support quickly finding the max character in a string, Python code does not benefit. ---------- components: Interpreter Core messages: 164351 nosy: v+python priority: normal severity: normal status: open title: max( str ) should be fast with PEP 393 versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15226> _______________________________________ From report at bugs.python.org Fri Jun 29 21:55:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 19:55:04 +0000 Subject: [issue15226] max( str ) should be fast with PEP 393 In-Reply-To: <1340999605.61.0.988726046922.issue15226@psf.upfronthosting.co.za> Message-ID: <1340999704.13.0.116495005984.issue15226@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +haypo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15226> _______________________________________ From report at bugs.python.org Fri Jun 29 23:09:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 29 Jun 2012 21:09:09 +0000 Subject: [issue15226] max( str ) should be fast with PEP 393 In-Reply-To: <1340999605.61.0.988726046922.issue15226@psf.upfronthosting.co.za> Message-ID: <1341004149.24.0.971316717598.issue15226@psf.upfronthosting.co.za> Martin v. L?wis <martin at v.loewis.de> added the comment: What the C code finds quickly (in constant time) is that the maximum is <=127. Most code doesn't know (and doesn't care) what the actual maximum is. So I see no bug here. ---------- nosy: +loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15226> _______________________________________ From report at bugs.python.org Fri Jun 29 23:14:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Jun 2012 21:14:49 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <E1SkiWd-0000rk-7q@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset bb4b184e5b33 by Tim Golden in branch '2.7': Issue #1677: Handle better a race condition between the interactive interpreter and http://hg.python.org/cpython/rev/bb4b184e5b33 New changeset 52af10209976 by Tim Golden in branch '3.2': Issue #1677: Handle better a race condition between the interactive interpreter and http://hg.python.org/cpython/rev/52af10209976 New changeset 9523c122d6fc by Tim Golden in branch 'default': Issue #1677: Handle better a race condition between the interactive interpreter and http://hg.python.org/cpython/rev/9523c122d6fc ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Fri Jun 29 23:28:52 2012 From: report at bugs.python.org (Daniel Lenski) Date: Fri, 29 Jun 2012 21:28:52 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1341005332.85.0.983196491987.issue14243@psf.upfronthosting.co.za> Changes by Daniel Lenski <dlenski at gmail.com>: ---------- nosy: +dlenski _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14243> _______________________________________ From report at bugs.python.org Fri Jun 29 23:34:34 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 21:34:34 +0000 Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za> Message-ID: <1341005674.02.0.115698762968.issue1677@psf.upfronthosting.co.za> Changes by Tim Golden <mail at timgolden.me.uk>: ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1677> _______________________________________ From report at bugs.python.org Fri Jun 29 23:42:43 2012 From: report at bugs.python.org (Yclept Nemo) Date: Fri, 29 Jun 2012 21:42:43 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> Message-ID: <1341006163.18.0.894349239682.issue15224@psf.upfronthosting.co.za> Yclept Nemo <orbisvicis at gmail.com> added the comment: > max and min for a range object are already O(1) one-liners: true; dropping > As for __and__, it doesn't feel like a particularly natural operation to me, given that a range object represents an *ordered* sequence of integers rather than just a subset. True, there is no canonical sorting. However, the concept of the intersection of ordered sets is commonplace and implemented in other libraries, for example: http://www.swi-prolog.org/pldoc/doc_for?object=section%282,%27A.17%27,swi%28%27/doc/Manual/ordsets.html%27%29%29 http://hackage.haskell.org/packages/archive/containers/0.4.1.0/doc/html/Data-Set.html#v:intersection http://hackage.haskell.org/packages/archive/data-ordlist/0.2/doc/html/Data-List-Ordered.html#v:isect My implementation inherets the ordering of the first range: R(1) R(2) R(F) p p p n p n p n p n n n key: p === positive === increasing key: n === negative === decreasing Haskell documentation has an apt paradigm for the ordering: "Elements of the result come from the first set"; similary my implementation selects elements from the first set common to the second. >From a programming persepctive this is quite natural too: lcm = (a*b)/gcd(a,b) where lcm determines the ordering. Basically, the behavior of the attached __and__ implementation is driven by python's gcd function. ---------- Added file: http://bugs.python.org/file26214/Range.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Fri Jun 29 23:46:28 2012 From: report at bugs.python.org (Yclept Nemo) Date: Fri, 29 Jun 2012 21:46:28 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> Message-ID: <1341006388.22.0.166153911199.issue15224@psf.upfronthosting.co.za> Yclept Nemo <orbisvicis at gmail.com> added the comment: >>> a=Range.Range(5,61,4) >>> ar=Range.Range(57,1,-4) >>> b=Range.Range(21,63,6) >>> br=Range.Range(57,15,-6) >>> list(a); list(ar); list(b); list(br) [5, 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57] [57, 53, 49, 45, 41, 37, 33, 29, 25, 21, 17, 13, 9, 5] [21, 27, 33, 39, 45, 51, 57] [57, 51, 45, 39, 33, 27, 21] >>> list(a&b) [21, 33, 45, 57] >>> list(a&br) [21, 33, 45, 57] >>> list(ar&br) [57, 45, 33, 21] >>> list(ar&b) [57, 45, 33, 21] >>> a&b Range(21, 69, 12) >>> a&br Range(21, 69, 12) >>> ar&br Range(57, 9, -12) >>> ar&b Range(57, 9, -12) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Fri Jun 29 23:49:14 2012 From: report at bugs.python.org (Yclept Nemo) Date: Fri, 29 Jun 2012 21:49:14 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> Message-ID: <1341006554.27.0.0516877868846.issue15224@psf.upfronthosting.co.za> Yclept Nemo <orbisvicis at gmail.com> added the comment: On a side note, glancing at Python-3.3.0a4/Objects/rangeobject.c: range_contains seems to iterate through the entire range whereas __contains__ from the attached Range.py is O(1) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Fri Jun 29 23:56:21 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 21:56:21 +0000 Subject: [issue798876] windows sys.path contains nonexistant directory Message-ID: <1341006981.02.0.491277347958.issue798876@psf.upfronthosting.co.za> Tim Golden <mail at timgolden.me.uk> added the comment: THis was fixed almost two years ago in Py3K. Won't fix for 2.7 ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue798876> _______________________________________ From report at bugs.python.org Sat Jun 30 00:01:12 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 22:01:12 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1341005332.95.0.779167056877.issue14243@psf.upfronthosting.co.za> Message-ID: <4FEE25A1.5050603@timgolden.me.uk> Tim Golden <mail at timgolden.me.uk> added the comment: Daniel. If you have any interest in this issue, would you mind summarising the state of affairs, please? I have no direct interest in the result but I'm happy to commit a patch or even to work one up if somone can come up with a single, concrete suggestion. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14243> _______________________________________ From report at bugs.python.org Sat Jun 30 00:06:21 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 22:06:21 +0000 Subject: [issue4485] fast swap of "default" Windows python versions In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za> Message-ID: <1341007581.93.0.925360994888.issue4485@psf.upfronthosting.co.za> Tim Golden <mail at timgolden.me.uk> added the comment: Effectively made redundant by PEP 397, implemented in 3.3 ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue4485> _______________________________________ From report at bugs.python.org Sat Jun 30 00:07:55 2012 From: report at bugs.python.org (Tim Golden) Date: Fri, 29 Jun 2012 22:07:55 +0000 Subject: [issue13792] The "os.execl" call doesn't give programs exit code In-Reply-To: <1326668704.55.0.266446288638.issue13792@psf.upfronthosting.co.za> Message-ID: <1341007675.71.0.879220301046.issue13792@psf.upfronthosting.co.za> Tim Golden <mail at timgolden.me.uk> added the comment: Closing as it's been pending for six months and I see nothing further to add ---------- stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13792> _______________________________________ From report at bugs.python.org Sat Jun 30 00:20:33 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 29 Jun 2012 22:20:33 +0000 Subject: [issue6021] itertools.grouper In-Reply-To: <1242320731.02.0.157515578486.issue6021@psf.upfronthosting.co.za> Message-ID: <1341008433.65.0.773859854677.issue6021@psf.upfronthosting.co.za> Changes by Eric Snow <ericsnowcurrently at gmail.com>: ---------- nosy: +eric.snow _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue6021> _______________________________________ From report at bugs.python.org Sat Jun 30 00:21:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Jun 2012 22:21:11 +0000 Subject: [issue15225] Add negative tests for passing str to hmac.HMAC and hmac.new In-Reply-To: <1340995780.51.0.208862174905.issue15225@psf.upfronthosting.co.za> Message-ID: <1341008471.09.0.189736202379.issue15225@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: You don't need to call self.fail(), assertRaises() will do it for you. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15225> _______________________________________ From report at bugs.python.org Sat Jun 30 01:27:41 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 29 Jun 2012 23:27:41 +0000 Subject: [issue15226] max( str ) should be fast with PEP 393 In-Reply-To: <1340999605.61.0.988726046922.issue15226@psf.upfronthosting.co.za> Message-ID: <1341012461.4.0.0155825632591.issue15226@psf.upfronthosting.co.za> Glenn Linderman <v+python at g.nevcal.com> added the comment: Ah, so then it would require a new API to make the Python code as smart as the C code, max is too general. Issue 15016 is an example of Python code that could benefit from knowing in constant time if the string contained only characters < 128, or if the string contained only characters < 256... a three way decision. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15226> _______________________________________ From report at bugs.python.org Sat Jun 30 01:28:21 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 29 Jun 2012 23:28:21 +0000 Subject: [issue15226] max( str ) should be fast with PEP 393 In-Reply-To: <1340999605.61.0.988726046922.issue15226@psf.upfronthosting.co.za> Message-ID: <1341012501.97.0.19668158293.issue15226@psf.upfronthosting.co.za> Changes by Glenn Linderman <v+python at g.nevcal.com>: ---------- type: -> enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15226> _______________________________________ From report at bugs.python.org Sat Jun 30 03:28:57 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 Jun 2012 01:28:57 +0000 Subject: [issue9670] Exceed Recursion Limit in Thread In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za> Message-ID: <1341019737.55.0.592451087757.issue9670@psf.upfronthosting.co.za> Ned Deily <nad at acm.org> added the comment: Looks like using clang brought the size back down again. Closing. ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9670> _______________________________________ From report at bugs.python.org Sat Jun 30 03:36:32 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Jun 2012 01:36:32 +0000 Subject: [issue15223] datetime instances lack __module__ attribute In-Reply-To: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za> Message-ID: <1341020192.31.0.627438324753.issue15223@psf.upfronthosting.co.za> R. David Murray <rdmurray at bitdance.com> added the comment: This is true for most (all?) CPython classes that are implemented in C. For example io.StringIO instances do not have a __module__ attribute either. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15223> _______________________________________ From report at bugs.python.org Sat Jun 30 03:43:44 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 30 Jun 2012 01:43:44 +0000 Subject: [issue15223] datetime instances lack __module__ attribute In-Reply-To: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za> Message-ID: <1341020624.07.0.697553978168.issue15223@psf.upfronthosting.co.za> Chris Jerdonek <chris.jerdonek at gmail.com> added the comment: Thanks. I suspected that might be the case. Then the question becomes whether failing to fall back to the class attribute is the desired behavior, and if not, to update the documentation accordingly. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15223> _______________________________________ From report at bugs.python.org Sat Jun 30 05:46:29 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 30 Jun 2012 03:46:29 +0000 Subject: [issue15223] datetime instances lack __module__ attribute In-Reply-To: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za> Message-ID: <1341027989.97.0.86758778028.issue15223@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15223> _______________________________________ From report at bugs.python.org Sat Jun 30 06:09:56 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 30 Jun 2012 04:09:56 +0000 Subject: [issue15223] datetime instances lack __module__ attribute In-Reply-To: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za> Message-ID: <1341029396.67.0.710366606713.issue15223@psf.upfronthosting.co.za> Chris Jerdonek <chris.jerdonek at gmail.com> added the comment: datetime.__dict__ is another attribute that behaves this way (i.e. doesn't exist for instances in CPython but does for PyPy). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15223> _______________________________________ From report at bugs.python.org Sat Jun 30 06:25:56 2012 From: report at bugs.python.org (Thomas Maslach) Date: Sat, 30 Jun 2012 04:25:56 +0000 Subject: [issue15227] Fatal Python error: PyEval_RestoreThread: NULL tstate on example script.. Message-ID: <1341030356.65.0.710942348238.issue15227@psf.upfronthosting.co.za> New submission from Thomas Maslach <tommaslach at gmail.com>: I've been running into a bug recently and reduced the code to the following: import Tkinter tk = Tkinter.Tk() window = Tkinter.Frame(tk) def onDestroy (event): pass window.bind ("<Destroy>", onDestroy) Just run and the following will be displayed: Fatal Python error: PyEval_RestoreThread: NULL tstate This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. If you add window.mainloop(), the issue goes aware. However, I don't do that in my case. window.update(), by the way, still causes the crash if that is of any interest (I found this tinkering).. I'm running with: - Window 7 - Python 2.7.2 - 64-bit machine, but 32-bit Python Thanks! ---------- components: Tkinter messages: 164367 nosy: tmaslach priority: normal severity: normal status: open title: Fatal Python error: PyEval_RestoreThread: NULL tstate on example script.. type: crash versions: Python 2.7 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15227> _______________________________________ From report at bugs.python.org Sat Jun 30 07:22:23 2012 From: report at bugs.python.org (lilydjwg) Date: Sat, 30 Jun 2012 05:22:23 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1341033743.4.0.998549180745.issue15222@psf.upfronthosting.co.za> lilydjwg <lilydjwg at gmail.com> added the comment: Hi, Petri Lehtinen. That's a bug of mine. That mbox is made up by me for demo, not procmail which has the newline. However, a newline is indeed lost and in some way it does corrupt my real mbox. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15222> _______________________________________ From report at bugs.python.org Sat Jun 30 07:45:37 2012 From: report at bugs.python.org (Daniel Lenski) Date: Sat, 30 Jun 2012 05:45:37 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1341035137.77.0.664208977189.issue14243@psf.upfronthosting.co.za> Daniel Lenski <dlenski at gmail.com> added the comment: Tim Golden, My preferred solution would be to replace the binary delete argument of the current NamedTemporaryFile implementation with finer-grained options: delete=False # don't delete delete=True # delete after file closed, current behavior delete=AFTER_CLOSE # delete after file closed delete=AFTER_CM_EXIT # delete after context manager exits delete=AFTER_CM_EXIT_NO_EXCEPTION # delete after CM exit, unless this is due to an exception I have implemented a Windows-friendly solution to the latter case using Nick Coghlan's code. My version does not delete the file until the context manager exits, and *if* the context manager exits due to an exception it leaves the file in place and reports its location, to aid me in debugging. ---------- Added file: http://bugs.python.org/file26215/ntempfile.py _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14243> _______________________________________ From report at bugs.python.org Sat Jun 30 08:13:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Jun 2012 06:13:22 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> Message-ID: <1341036802.16.0.219089478922.issue15224@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: > On a side note, glancing at Python-3.3.0a4/Objects/rangeobject.c: > range_contains seems to iterate through the entire range whereas __contains__ from the attached Range.py is O(1) See issue1766304. For int range.__contains__ is O(1), for custom types this optimization is impossible without losing backward compatibility. ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Sat Jun 30 08:26:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Jun 2012 06:26:12 +0000 Subject: [issue9239] zipfile: truncating comment can corrupt the zipfile In-Reply-To: <1340992044.42.0.69806565047.issue9239@psf.upfronthosting.co.za> Message-ID: <1341037595.3957.7.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Then the tests may still be added to test_zipfile? Yes, they may. Here is a patch with adapted for 3.3 tests only. ---------- Added file: http://bugs.python.org/file26216/zipfile_appendmode_comment_tests.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9239> _______________________________________ -------------- next part -------------- diff -r 5fea362b92fc Lib/test/test_zipfile.py --- a/Lib/test/test_zipfile.py Wed Apr 25 19:45:11 2012 +0200 +++ b/Lib/test/test_zipfile.py Sat Apr 28 22:16:43 2012 +0300 @@ -970,6 +970,24 @@ with zipfile.ZipFile(TESTFN, mode="r") as zipfr: self.assertEqual(zipfr.comment, comment2) + # check that comments are correctly modified in append mode + with zipfile.ZipFile(TESTFN,mode="w") as zipf: + zipf.comment = b"original comment" + zipf.writestr("foo.txt", "O, for a Muse of Fire!") + with zipfile.ZipFile(TESTFN,mode="a") as zipf: + zipf.comment = b"an updated comment" + with zipfile.ZipFile(TESTFN,mode="r") as zipf: + self.assertEqual(zipf.comment, b"an updated comment") + + # check that comments are correctly shortened in append mode + with zipfile.ZipFile(TESTFN,mode="w") as zipf: + zipf.comment = b"original comment that's longer" + zipf.writestr("foo.txt", "O, for a Muse of Fire!") + with zipfile.ZipFile(TESTFN,mode="a") as zipf: + zipf.comment = b"shorter comment" + with zipfile.ZipFile(TESTFN,mode="r") as zipf: + self.assertEqual(zipf.comment, b"shorter comment") + def test_unicode_comment(self): with zipfile.ZipFile(TESTFN, "w", zipfile.ZIP_STORED) as zipf: zipf.writestr("foo.txt", "O, for a Muse of Fire!") From report at bugs.python.org Sat Jun 30 08:40:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Jun 2012 06:40:59 +0000 Subject: [issue1160] Medium size regexp crashes python In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za> Message-ID: <1341038459.95.0.572609399959.issue1160@psf.upfronthosting.co.za> Serhiy Storchaka <storchaka at gmail.com> added the comment: > This has probably been fixed in 3.3 in c67b7e0c818a. Then the issue may be closed? ---------- nosy: +storchaka _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1160> _______________________________________ From report at bugs.python.org Sat Jun 30 09:01:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Jun 2012 07:01:09 +0000 Subject: [issue13790] In str.format an incorrect error message for list, tuple, dict, set In-Reply-To: <1340994566.92.0.459079076756.issue13790@psf.upfronthosting.co.za> Message-ID: <1341039690.3957.24.camel@raxxla> Serhiy Storchaka <storchaka at gmail.com> added the comment: > Serhiy: I'm not sure what you're saying. At the point that str.format() is producing its error message, it doesn't know as much as %-formatting does about the original arguments, so it can't produce a similar message. I'm surprised that the code of the classic and the modern formatting is so different. Looking deeper, I saw that the issue will go away in 3.4. I agree with you in msg151728. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue13790> _______________________________________ From report at bugs.python.org Sat Jun 30 09:42:16 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 30 Jun 2012 07:42:16 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> Message-ID: <1341042136.8.0.313941302688.issue15224@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: > However, the concept of the intersection of ordered sets is commonplace > and implemented in other libraries, for example: None of those are specific to arithmetic progressions (i.e., range-like lists / sets), as far as I can tell. I could see more use for general list-intersection functionality. I'm still -1 on this; it seems too specialised a need to belong in the core language. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Sat Jun 30 10:46:28 2012 From: report at bugs.python.org (Davide Rizzo) Date: Sat, 30 Jun 2012 08:46:28 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1341045988.98.0.559965486608.issue14243@psf.upfronthosting.co.za> Davide Rizzo <sorcio at gmail.com> added the comment: Daniel, Nick, shouldn't the context manager yield f within a with block? ---------- nosy: +davide.rizzo _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14243> _______________________________________ From report at bugs.python.org Sat Jun 30 12:12:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 30 Jun 2012 10:12:06 +0000 Subject: [issue15226] max( str ) should be fast with PEP 393 In-Reply-To: <1340999605.61.0.988726046922.issue15226@psf.upfronthosting.co.za> Message-ID: <1341051126.65.0.467343924152.issue15226@psf.upfronthosting.co.za> Changes by Martin v. L?wis <martin at v.loewis.de>: ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15226> _______________________________________ From report at bugs.python.org Sat Jun 30 14:33:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 12:33:40 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <E1Skwrn-0005xh-Ma@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 56c574a1819a by doko in branch 'default': - Issue #3754, refactor sys.platform / get_platform bits, use a http://hg.python.org/cpython/rev/56c574a1819a ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 14:34:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 12:34:03 +0000 Subject: [issue15227] Fatal Python error: PyEval_RestoreThread: NULL tstate on example script.. In-Reply-To: <1341030356.65.0.710942348238.issue15227@psf.upfronthosting.co.za> Message-ID: <1341059643.74.0.0760883752863.issue15227@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +gpolo, loewis _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15227> _______________________________________ From report at bugs.python.org Sat Jun 30 14:39:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 12:39:25 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1341059965.48.0.0987968142229.issue15216@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > The proposal [1] is that TextIOWrapper support a set_encoding() method > that is only supported between creation of the stream and the first > read or write operation. That will be fragile. A bit of prematurate input or output (for whatever reason) and your program breaks. ---------- nosy: +pitrou _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15216> _______________________________________ From report at bugs.python.org Sat Jun 30 14:44:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 12:44:14 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <E1Skx24-0006fZ-Q0@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset af15910d2ffb by doko in branch 'default': - Issue #3754: Use AC_PATH_TOOL and AC_CHECK_TOOLS instead of http://hg.python.org/cpython/rev/af15910d2ffb ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 14:56:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 Jun 2012 12:56:40 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1341061000.59.0.584814332043.issue15216@psf.upfronthosting.co.za> Nick Coghlan <ncoghlan at gmail.com> added the comment: Indeed. However, the current alternatives (based on detach() and fileNo()) are also problematic - using detach() breaks the corresponding sys.__std*__ entry, while using fileNo() means you now have two independent IO stacks using the same underlying descriptor. My own preference is to have a set_encoding() method that *can* be used even if IO has already occurred. Yes, there's the chance of mixing encodings if data is processed before the encoding is changed, but that's also true for both of the alternatives. Pipeline applications written in Python should have an easy way to implement "--encoding" parameters for the standard IO streams, and a method to update the settings is the obvious choice. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15216> _______________________________________ From report at bugs.python.org Sat Jun 30 15:28:46 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 13:28:46 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1341062926.67.0.270406442428.issue14330@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: the updated patch addresses: - fix typo mentioned in msg156044 - don't use the host python during build and installation - for include files and libraries, use the search directories provided by gcc, and only fall back to hard coded directories for native builds. - fix the dpkg-architecture call for cross builds - pass the --host and --build arguments to the libffi build - fix the pydebug check, taken from issue #3871. The patch introduces two new variables, which are set in the environment for cross builds: - _PROJECT_BASE is used by Lib/sysconfig.py to point to the current source, while using the python3 interpreter of the build machine, so that the Makefile and the pyconfig.h are read from the current sources. - _HOST_PLATFORM is used to override the get_platform calls in Lib/sysconfig.py, Lib/distutils/utils.py and setup.py. Yes, distutils is frozen, however this change shouldn't break anything else. It only relies on one environment variable _HOST_PLATFORM, so if this is an issue, then the name can be obfuscated even more. tested with a cross build for arm-linux-gnueabihf on x86_64-linux-gnu, and a native build. ---------- title: do not use the host python for cross builds -> don't use host python, use host search paths for host compiler Added file: http://bugs.python.org/file26217/no-host-python-and-host-gcc.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 15:29:33 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 13:29:33 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1341062973.0.0.160644023465.issue14330@psf.upfronthosting.co.za> Changes by Matthias Klose <doko at debian.org>: ---------- nosy: +tarek _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 15:30:55 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 13:30:55 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1341063055.4.0.992629536637.issue3754@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: updated the patch in issue #14330. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 15:51:24 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 13:51:24 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1341064284.51.0.0455923910625.issue3754@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: some chunks of the python-py3k-20120607-CROSS.patch patch are now checked in. I didn't see any issues with the symlinks, and generating the posix vars, so maybe these bits should be dropped from the patch. remaining issues are: - the readline/ncurses configury. maybe this should be done in the configure.ac using the host tools, and then provided to setup.py by a Makefile macro? - why are the Makefile changes for setup.info, pyconfig.h needed? - is the _testembed change still needed? - does Python/importlib.h really need a rebuild if it's there? I think this should just fail, not removed for the cross build. - why is the ac_cv_thread vs. ac_cv_pthread change needed? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 16:54:14 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 14:54:14 +0000 Subject: [issue14324] Do not rely on AC_RUN_IFELSE tests in the configury In-Reply-To: <1331832189.68.0.401858624599.issue14324@psf.upfronthosting.co.za> Message-ID: <1341068054.5.0.300376422996.issue14324@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: use a linker test to check for profiling support (derived from the patch in issue #3754. ---------- Added file: http://bugs.python.org/file26218/profiling.diff _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14324> _______________________________________ From report at bugs.python.org Sat Jun 30 16:54:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 14:54:49 +0000 Subject: [issue14324] Do not rely on AC_RUN_IFELSE tests in the configury In-Reply-To: <1331832189.68.0.401858624599.issue14324@psf.upfronthosting.co.za> Message-ID: <E1Skz4R-00064Q-Lv@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 575efae8ec57 by doko in branch 'default': - Issue #14324: use a linker test to check for profiling support http://hg.python.org/cpython/rev/575efae8ec57 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14324> _______________________________________ From report at bugs.python.org Sat Jun 30 17:06:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 15:06:38 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <E1SkzFt-0006ut-81@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset d158b0a78390 by doko in branch 'default': - Issue #3754: Some unrelated configure.ac cleanups. http://hg.python.org/cpython/rev/d158b0a78390 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 17:24:33 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Sat, 30 Jun 2012 15:24:33 +0000 Subject: [issue15225] Add negative tests for passing str to hmac.HMAC and hmac.new In-Reply-To: <1340995780.51.0.208862174905.issue15225@psf.upfronthosting.co.za> Message-ID: <1341069873.95.0.92574249481.issue15225@psf.upfronthosting.co.za> Marc Abramowitz <msabramo at gmail.com> added the comment: Updating patch ---------- Added file: http://bugs.python.org/file26219/hmac.py.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15225> _______________________________________ From report at bugs.python.org Sat Jun 30 17:25:55 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Sat, 30 Jun 2012 15:25:55 +0000 Subject: [issue15225] Add negative tests for passing str to hmac.HMAC and hmac.new In-Reply-To: <1340995780.51.0.208862174905.issue15225@psf.upfronthosting.co.za> Message-ID: <1341069955.03.0.109870889084.issue15225@psf.upfronthosting.co.za> Changes by Marc Abramowitz <msabramo at gmail.com>: ---------- type: -> enhancement Added file: http://bugs.python.org/file26220/test_hmac.py.patch _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15225> _______________________________________ From report at bugs.python.org Sat Jun 30 17:29:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 15:29:21 +0000 Subject: [issue15225] Add negative tests for passing str to hmac.HMAC and hmac.new In-Reply-To: <1340995780.51.0.208862174905.issue15225@psf.upfronthosting.co.za> Message-ID: <E1Skzbr-0008P7-82@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset b0605b34b2de by Antoine Pitrou in branch 'default': Issue #15225: improve error message when hmac is passed a wrong key type. http://hg.python.org/cpython/rev/b0605b34b2de ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15225> _______________________________________ From report at bugs.python.org Sat Jun 30 17:34:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 15:34:20 +0000 Subject: [issue9239] zipfile: truncating comment can corrupt the zipfile In-Reply-To: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za> Message-ID: <E1Skzgh-0000GA-2u@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset e13c9f99fbae by Antoine Pitrou in branch '3.2': Issue #9239: add tests for modifying zipfile comments in append mode. http://hg.python.org/cpython/rev/e13c9f99fbae New changeset b299b4279e13 by Antoine Pitrou in branch 'default': Issue #9239: add tests for modifying zipfile comments in append mode. http://hg.python.org/cpython/rev/b299b4279e13 ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9239> _______________________________________ From report at bugs.python.org Sat Jun 30 17:34:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 15:34:59 +0000 Subject: [issue9239] zipfile: truncating comment can corrupt the zipfile In-Reply-To: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za> Message-ID: <1341070499.45.0.490999783646.issue9239@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Thanks, committed! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue9239> _______________________________________ From report at bugs.python.org Sat Jun 30 17:35:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 15:35:34 +0000 Subject: [issue15225] Add negative tests for passing str to hmac.HMAC and hmac.new In-Reply-To: <1340995780.51.0.208862174905.issue15225@psf.upfronthosting.co.za> Message-ID: <1341070534.34.0.489312124057.issue15225@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Thank you Marc, your patches are now committed! ---------- components: +Library (Lib) resolution: -> fixed stage: -> committed/rejected status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15225> _______________________________________ From report at bugs.python.org Sat Jun 30 17:36:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 15:36:54 +0000 Subject: [issue1160] Medium size regexp crashes python In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za> Message-ID: <1341070614.88.0.750185617515.issue1160@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: > Then the issue may be closed? Well, it's still present in 2.7 and 3.2 (assuming we consider it's important enough to fix). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue1160> _______________________________________ From report at bugs.python.org Sat Jun 30 18:07:30 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 30 Jun 2012 16:07:30 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1341072450.66.0.0658698533961.issue14243@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: Rather than add a NamedTemporaryFile.delete_after() classmethod, would it not be simpler to just add a close_without_unlink() method to NamedTemporaryFile? with NamedTemporaryFile() as f: <write to f> f.close_without_unlink() with open(f.name, 'rb') as f: <read from f> ---------- nosy: +sbt _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14243> _______________________________________ From report at bugs.python.org Sat Jun 30 18:19:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 16:19:50 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <E1Sl0Oi-0003AL-Vy@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 6df0b4ed8617 by Mark Dickinson in branch '2.7': Closes #14591: Random.jumpahead could produce an invalid MT state on 64-bit machines. http://hg.python.org/cpython/rev/6df0b4ed8617 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14591> _______________________________________ From report at bugs.python.org Sat Jun 30 18:24:09 2012 From: report at bugs.python.org (Matthew Barnett) Date: Sat, 30 Jun 2012 16:24:09 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1341073449.28.0.370484594724.issue15216@psf.upfronthosting.co.za> Matthew Barnett <python at mrabarnett.plus.com> added the comment: Would a "set_encoding" method be Pythonic? I would've preferred an "encoding" property which flushes the output when it's changed. ---------- nosy: +mrabarnett _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15216> _______________________________________ From report at bugs.python.org Sat Jun 30 18:26:03 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 16:26:03 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1341073563.25.0.497676135259.issue3754@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: for the readline ldd check, I'm checking in a patch to use readelf instead of ldd for the cross build. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 18:27:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 16:27:54 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <E1Sl0WW-0003pP-0I@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset e6e99d449bdc by doko in branch 'default': - Issue #3754: Use readelf instead of ldd for the cross build readline check http://hg.python.org/cpython/rev/e6e99d449bdc ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 18:33:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 16:33:31 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <E1Sl0by-0004As-1j@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset b285ec79e5de by Matthias Klose in branch 'default': previous patch needs patch from issue #14330 http://hg.python.org/cpython/rev/b285ec79e5de ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 18:35:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 16:35:40 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1341073449.28.0.370484594724.issue15216@psf.upfronthosting.co.za> Message-ID: <1341074080.9718.1.camel@localhost.localdomain> Antoine Pitrou <pitrou at free.fr> added the comment: > Would a "set_encoding" method be Pythonic? I would've preferred an > "encoding" property which flushes the output when it's changed. I would prefer to have a method. The side-effect is too violent to be hidden behind a property. Besides, you want to set encoding and errors in a single operation. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15216> _______________________________________ From report at bugs.python.org Sat Jun 30 18:39:56 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 30 Jun 2012 16:39:56 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1341074396.51.0.438010868012.issue3871@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > I thought that the distutils-is-frozen rule was only for Python 2.x > and that they would be allowed for 3.x? Is this not true? It is not. The normal rule is that stable versions (like 2.7) get only bug fixes while new features go only to the development version (like 3.3 before it went into beta last Tuesday). For distutils there is a special rule that prevents new features for all versions. The only exceptions are side effects of changes in other parts of Python (for example __pycache__ directories in 3.2 or virtualenv in 3.3). > Obviously making Python cross compile properly is a very desired feature (in this day and age > I'd say cross-compilation for any major software is expected to be honest with you). Well I for one am a unix user but not a C guy; I compile Python easily and don?t fully get the benefits of cross compilation. distutils2 is the place to add such new features. We wanted to release it in the standard library for 3.3 but it was not ready, so it should be in 3.4. ---------- versions: +Python 3.4 -3rd party, Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Sat Jun 30 18:43:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 16:43:36 +0000 Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2) In-Reply-To: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za> Message-ID: <E1Sl0li-0004kK-OZ@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 177f93f0f5b9 by Stefan Krah in branch '3.2': Issue #15171: Quote the variable that expands to the current directory. http://hg.python.org/cpython/rev/177f93f0f5b9 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15171> _______________________________________ From report at bugs.python.org Sat Jun 30 18:47:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 16:47:02 +0000 Subject: [issue15170] Fix 64-bit building for buildbot scripts (2.7) In-Reply-To: <1340569734.61.0.00630889671182.issue15170@psf.upfronthosting.co.za> Message-ID: <E1Sl0p1-0004z4-98@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 97445ca895d5 by Stefan Krah in branch '2.7': Issue #15170: Quote the variable that expands to the current directory. http://hg.python.org/cpython/rev/97445ca895d5 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15170> _______________________________________ From report at bugs.python.org Sat Jun 30 18:48:18 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 16:48:18 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1341074898.52.0.179429490363.issue3754@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: the ncurses/_flags changes seem to be unrelated. please open a separate issue. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 19:29:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 17:29:46 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <E1Sl1UP-0007g1-8I@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 12a56a349af2 by doko in branch 'default': - Issue #3754: Fix /dev/ptmx, /dev/ptc file checks for cross builds, http://hg.python.org/cpython/rev/12a56a349af2 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 19:30:45 2012 From: report at bugs.python.org (Yclept Nemo) Date: Sat, 30 Jun 2012 17:30:45 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> Message-ID: <1341077445.38.0.763643231695.issue15224@psf.upfronthosting.co.za> Yclept Nemo <orbisvicis at gmail.com> added the comment: >> None of those are specific to arithmetic progressions (i.e., range-like lists / sets), as far as I can tell. Does this (the data-type involved) really matter? >> I could see more use for general list-intersection functionality. The way to implement generic functionality is to define a protocol and override inherited behavior when necessary. Generic intersection (when semantics can be agreed upon) can computed using the iterator protocol, but __and__ of the range class should be overridden to provide O(1) behavior. So, perhaps a proposal for implementing __and__ for lists as well ? >> I'm still -1 on this; it seems too specialised a need to belong in the core language. While I do see several arguments against the inclusion of __and__: . it would require the inclusion of union and difference operations . vague definition of intersection with regard to ranges. Do you treat range like a linear equation, so only consider intersections at the same index. Also the issue regarding ordering. . re issue1766304, it may be pointless providing an O(1) __and__ for range if it can only work for ints(??) I don't think that complexity or specialisation should matter. A range is already a specialised data type (do any other languages have a range class - separate from slices?) Python's data model provides __and__. Conceptually, why not bring range to its full potential using facilities that python already provides. By the way, I don't have anything at stake in this - just arguing for argument's sake - so you can close this if you feel strongly enough about not implementing it. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Sat Jun 30 20:21:46 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 30 Jun 2012 18:21:46 +0000 Subject: [issue15222] mailbox.mbox writes without empty line after each message In-Reply-To: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za> Message-ID: <1341080506.39.0.680756959363.issue15222@psf.upfronthosting.co.za> Petri Lehtinen <petri at digip.org> added the comment: I'm afraid that's not enough details to do any fixing. I would need a concrete way to reproduce the issue. ---------- status: open -> pending _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15222> _______________________________________ From report at bugs.python.org Sat Jun 30 20:22:42 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 30 Jun 2012 18:22:42 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1341080562.26.0.991486199234.issue14330@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: Patch looks okay as it contains no important changes to distutils, the compilers or any big part; it?s the sort of changes that have been accepted to fix Mac issue or support multiarch on Debian. I would prefer safer names for environment variables though, for example PYTHON_BUILD_HOST_PLATFORM instead of just _HOST_PLATFORM (unless this is not specific to the Python build process but used by all cross-compiling builds). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 20:27:58 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 30 Jun 2012 18:27:58 +0000 Subject: [issue15224] Range: Additional Methods (min/max/__and__) In-Reply-To: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za> Message-ID: <1341080878.66.0.547904831323.issue15224@psf.upfronthosting.co.za> Mark Dickinson <dickinsm at gmail.com> added the comment: Okay, I'm closing this as rejected. Some responses: > I don't think that complexity or specialisation should matter. Well, Python's supposed to be a general-purpose language; range objects *are* generally useful for all sorts of tasks, but it's far from clear that being able to intersect them would be valuable to a wide range of people. > Conceptually, why not bring range to its full potential using facilities that python already provides. Because additions to the language (especially the core language, as opposed to the standard library) are far from free. First the feature needs to be implemented, reviewed, fully tested and documented. Then it needs to be maintained. Other Python implementations (PyPy, IronPython, Jython, etc.) need to create their own implementations. Text book writers need to keep up with the changes. The addition makes the language larger, making more to learn for students of the language and more to teach for teachers. In this particular case, I'm worried that there's a real risk of making a poor API choice that will inhibit later language expansion---you can't just add a method to a builtin type without considering the impact on the language as a whole, both now and in the future. So there's a significant cost in each core language addition, even for something as simple-looking as this. And the benefits of the addition have to be weighed against that cost. In this case, I see very little benefit---I doubt that there's a real and common need for range intersections. And all of the above is before discussing the implementation difficulties associated with this particular feature: it would likely require a C implementation of the gcd function, which is *not* a trivial thing to do efficiently, so we're looking at much more than just a few lines of code, with all the attendant risks of introducing new bugs. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15224> _______________________________________ From report at bugs.python.org Sat Jun 30 20:33:44 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 18:33:44 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1341081224.21.0.0247131551771.issue14330@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: PYTHON_BUILD_HOST_PLATFORM is confusing/misleading. I'll use _PYTHON_HOST_PLATFORM (with the leading underscore to mark it somehow internal). ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 20:42:50 2012 From: report at bugs.python.org (Ray Donnelly) Date: Sat, 30 Jun 2012 18:42:50 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1341081770.95.0.204958277651.issue3754@psf.upfronthosting.co.za> Ray Donnelly <mingw.android at gmail.com> added the comment: NCURSES_INTERNALS stuff appears to be redundant: Mac OS X curses.h, Linux curses.h and Windows PDCurses.h don't reference it, nor does the Python 3.3.0b1 source code. Of course, I haven't checked any other systems. However: see http://bugs.python.org/issue14598, so maybe for older Linux ncurses and Cygwin it is still needed. NCURSES_OPAQUE investigation: Linux ncurses.h: #ifndef NCURSES_OPAQUE #define NCURSES_OPAQUE 0 #endif Mac OS X ncurses.h: #ifndef NCURSES_OPAQUE #define NCURSES_OPAQUE 1 #endif So for OSX we need to be defining it to 0... but IMHO, these parts are not directly related to cross compilation support so shouldn't be part of this patch. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 20:44:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 18:44:57 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <E1Sl2f9-0003eH-AO@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset cfbe51e66749 by doko in branch 'default': - Issue #14330: For cross builds, don't use host python, use host search paths http://hg.python.org/cpython/rev/cfbe51e66749 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 20:48:12 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 18:48:12 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1341082092.18.0.0846875410717.issue14330@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: applied ---------- status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 20:52:34 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 18:52:34 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1341082354.44.0.653658393094.issue3754@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: Roumen, I would like to close this issue. Please could you file separate issues for the remaining bits? - the thread/pthread configure issue - the generation of the Setup / pyconfig.h files? ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 20:56:07 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 18:56:07 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1341082567.6.0.134794936271.issue3871@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: the cross build support is now updated for 3.3. so the mingw32 patches need an update. Not sure if they will go into 3.3, because there seem to be non-trivial changes for in Lib/distutils. Other self-contained changes probably should still go into 3.3. ---------- nosy: +doko _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Sat Jun 30 21:09:47 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 30 Jun 2012 19:09:47 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1341083387.67.0.234465240204.issue14330@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: +if "_PROJECT_BASE" in os.environ: Can you use _PYTHON_PROJECT_BASE here? Thanks. (BTW it would be nice if you could mark the bugs for which you did commits as closed+fixed+committed.) ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 21:17:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 30 Jun 2012 19:17:05 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1341083825.5.0.977852095701.issue3871@psf.upfronthosting.co.za> ?ric Araujo <merwok at netwok.org> added the comment: > Not sure if they will go into 3.3, because there seem to be non-trivial changes for in Lib/distutils. The feature freeze applies to all branches. Even when 3.4 starts, the same rule that has been repeatedly explained for two years will apply: no new features in distutils. Again, neither Tarek nor I are happy about that, but it was the decision taken by python-dev due to the big number of setup.py scripts depending on undocumented behavior, bugs and quirks. > Other self-contained changes probably should still go into 3.3. Not sure; we are in beta now, and cross-compilation does not look like an existing feature that is being fixed, but a new feature being added despite the beta status. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Sat Jun 30 21:23:48 2012 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 30 Jun 2012 19:23:48 +0000 Subject: [issue3754] cross-compilation support for python build In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za> Message-ID: <1341084228.23.0.222857498971.issue3754@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: Matthias I cannot follow all you questions as I'm on vacation so briefly: a) ac_cv_thread is type correct one is with'p' b) ncurses NCURSES_INTERNALS reported again in issue 14598 NCURSES_OPAQUE - i don't have time to explain all details but it could be reproduces on linux with version 2.7 Even on linux to linux build it is required as it could depend from ncurses library version. c) setup_info is my proposition to pass detection of readline libs from configure to setup.py . Use of readelf is not portable. Why to test again ? If on host platforms shared library is not in elf format which tool to use ? d) importlib.h is build now from executable. Probably we could introduce BUILD_CC . Out of scope for now e) executable that load packages has to be located in builddir to allow "is python build" to be activated and packages from cross-build environment to be loaded. After 3 weeks I could answer more. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3754> _______________________________________ From report at bugs.python.org Sat Jun 30 21:25:53 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 30 Jun 2012 19:25:53 +0000 Subject: [issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error In-Reply-To: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za> Message-ID: <1341084353.95.0.486286136263.issue15198@psf.upfronthosting.co.za> Richard Oudkerk <shibturn at gmail.com> added the comment: What type of object did you try to send, and how can the problem be reproduced? There are plenty of types which don't support pickling, and where pickling only succeeds in producing invalid data which cannot be successfully unpickled. The exception raised when unpickling will depend on the type of the object. ---------- type: crash -> behavior _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15198> _______________________________________ From report at bugs.python.org Sat Jun 30 21:26:43 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 30 Jun 2012 19:26:43 +0000 Subject: [issue15171] Fix 64-bit building for buildbot scripts (3.2) In-Reply-To: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za> Message-ID: <1341084403.29.0.56232296207.issue15171@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Did the Windows XP-4 bot start failing after 334ff92a8483 ? The logs don't go back very far: http://buildbot.python.org/all/builders/x86%20XP-4%203.2 ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15171> _______________________________________ From report at bugs.python.org Sat Jun 30 21:28:58 2012 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 30 Jun 2012 19:28:58 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1341084538.63.0.0422645529352.issue3871@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: Eric. please could could you revert PEP 405 as distutils is frozen or step down as It seems to me you don't flow distutils evolution. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Sat Jun 30 21:40:00 2012 From: report at bugs.python.org (Ian Bell) Date: Sat, 30 Jun 2012 19:40:00 +0000 Subject: [issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error In-Reply-To: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za> Message-ID: <1341085200.34.0.0537284854119.issue15198@psf.upfronthosting.co.za> Ian Bell <ian.h.bell at gmail.com> added the comment: I had issues with a class that I wrote myself. It is a rather involved data structure with all kinds of interesting things going on. Unfortunately I cannot put together a minimal working example that will cause a Python hang. ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15198> _______________________________________ From report at bugs.python.org Sat Jun 30 21:44:30 2012 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 30 Jun 2012 19:44:30 +0000 Subject: [issue3871] cross and native build of python for mingw32 with packaging In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za> Message-ID: <1341085470.24.0.934669291907.issue3871@psf.upfronthosting.co.za> Roumen Petrov <bugtrack at roumenpetrov.info> added the comment: Hi Mattias , I have ready to upload patches for 3.3.30b1 but after recent changes I will postpone upload . Part of already uploaded patch cover cygwin native build . For instance a) --enable-new-dtags is only for elf binaries. b) use of libpython$(LDVERSION), i.e. LD...) has to be reported again in another cygwin related issue c) .... etc?(?) ... 10x for you efforts to review, analyze, commit patches related to cross-build. Eric packaging seem to me a good tool to replace distutils remaining compatible but unfortunately is removed from 3.3 :( ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ From report at bugs.python.org Sat Jun 30 21:55:23 2012 From: report at bugs.python.org (Daniel Grace) Date: Sat, 30 Jun 2012 19:55:23 +0000 Subject: [issue15228] os.utime() docs not clear on behavior on nonexistant files Message-ID: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za> New submission from Daniel Grace <thisgenericname at gmail.com>: The documentation for os.utime() at http://docs.python.org/py3k/library/os.html#os.utime states: "Set the access and modified times of the file specified by path. [...] The effect is similar to running the Unix program touch on the path.)" Unlike 'touch', os.utime() will not create an empty file if called on a file that does not exist. IMO the current behavior is correct, but the comparison of os.utime() to touch implies that it would create empty files. I suggest clarifying the documentation to emphasize that os.utime() will not create new files and raises OSError in the event that the file does not exist. ---------- assignee: docs at python components: Documentation messages: 164422 nosy: dewin, docs at python priority: normal severity: normal status: open title: os.utime() docs not clear on behavior on nonexistant files type: enhancement _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15228> _______________________________________ From report at bugs.python.org Sat Jun 30 22:09:42 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 30 Jun 2012 20:09:42 +0000 Subject: [issue15229] stringification of subclasses of OSError can cause crash Message-ID: <1341086982.43.0.276121851076.issue15229@psf.upfronthosting.co.za> New submission from Richard Oudkerk <shibturn at gmail.com>: If you subclass OSError without calling OSError.__init__() then you can get a crash. For example Python 3.3.0b1 (default:cfbe51e66749, Jun 30 2012, 20:50:54) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class MyError(OSError): ... def __init__(self): ... pass ... [61116 refs] >>> repr(MyError()) Assertion failed: obj, file ..\Objects\unicodeobject.c, line 2646 Note that str(MyError()) results in a crash without hitting a failed assertion. The problem does not occur in Python 3.2, and it does not affect subclasses of Exception. ---------- components: Interpreter Core messages: 164423 nosy: sbt priority: normal severity: normal stage: needs patch status: open title: stringification of subclasses of OSError can cause crash type: crash versions: Python 3.3 _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15229> _______________________________________ From report at bugs.python.org Sat Jun 30 22:30:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 20:30:46 +0000 Subject: [issue15229] stringification of subclasses of OSError can cause crash In-Reply-To: <1341086982.43.0.276121851076.issue15229@psf.upfronthosting.co.za> Message-ID: <1341088246.85.0.125055828434.issue15229@psf.upfronthosting.co.za> Changes by Antoine Pitrou <pitrou at free.fr>: ---------- nosy: +pitrou priority: normal -> high _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15229> _______________________________________ From report at bugs.python.org Sat Jun 30 22:38:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 20:38:25 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <E1Sl4Qx-0002FA-Uj@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 86ac09f118be by doko in branch 'default': - Issue #14330: For cross builds, don't use host python, use host search paths http://hg.python.org/cpython/rev/86ac09f118be ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 22:39:03 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 20:39:03 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1341088743.78.0.920419217505.issue14330@psf.upfronthosting.co.za> Matthias Klose <doko at debian.org> added the comment: now renamed, add added the news entry ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 22:39:37 2012 From: report at bugs.python.org (Matthias Klose) Date: Sat, 30 Jun 2012 20:39:37 +0000 Subject: [issue14330] don't use host python, use host search paths for host compiler In-Reply-To: <1331856850.28.0.590122825265.issue14330@psf.upfronthosting.co.za> Message-ID: <1341088777.61.0.251738479553.issue14330@psf.upfronthosting.co.za> Changes by Matthias Klose <doko at debian.org>: ---------- resolution: -> fixed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue14330> _______________________________________ From report at bugs.python.org Sat Jun 30 22:46:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 20:46:12 +0000 Subject: [issue15229] stringification of subclasses of OSError can cause crash In-Reply-To: <1341086982.43.0.276121851076.issue15229@psf.upfronthosting.co.za> Message-ID: <1341089172.58.0.278128754635.issue15229@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: Here is a quick patch (needs a test): diff --git a/Objects/exceptions.c b/Objects/exceptions.c --- a/Objects/exceptions.c +++ b/Objects/exceptions.c @@ -834,6 +834,7 @@ oserror_init(PyOSErrorObject *self, PyOb #endif /* Steals the reference to args */ + Py_CLEAR(self->args); self->args = args; args = NULL; @@ -916,6 +917,11 @@ OSError_new(PyTypeObject *type, PyObject )) goto error; } + else { + self->args = PyTuple_New(0); + if (self->args == NULL) + goto error; + } return (PyObject *) self; ---------- _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15229> _______________________________________ From report at bugs.python.org Sat Jun 30 23:38:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Jun 2012 21:38:50 +0000 Subject: [issue15229] stringification of subclasses of OSError can cause crash In-Reply-To: <1341086982.43.0.276121851076.issue15229@psf.upfronthosting.co.za> Message-ID: <E1Sl5NQ-0005nz-VD@dinsdale.python.org> Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment: New changeset 1cbab581bf1e by Antoine Pitrou in branch 'default': Issue #15229: An OSError subclass whose __init__ doesn't call back http://hg.python.org/cpython/rev/1cbab581bf1e ---------- nosy: +python-dev _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15229> _______________________________________ From report at bugs.python.org Sat Jun 30 23:39:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Jun 2012 21:39:09 +0000 Subject: [issue15229] stringification of subclasses of OSError can cause crash In-Reply-To: <1341086982.43.0.276121851076.issue15229@psf.upfronthosting.co.za> Message-ID: <1341092349.05.0.155878277291.issue15229@psf.upfronthosting.co.za> Antoine Pitrou <pitrou at free.fr> added the comment: It should be fixed now. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue15229> _______________________________________ From report at bugs.python.org Sat Jun 30 23:56:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 30 Jun 2012 21:56:08 +0000 Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0 In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za> Message-ID: <1341093368.83.0.7706441781.issue10650@psf.upfronthosting.co.za> Stefan Krah <stefan-usenet at bytereef.org> added the comment: Ping. We have to decide if we need watchexp in _decimal. I've left it out so far since all I can gather from the docs is that it somehow behaves like _rescale. Can we deprecate it and replace it by a proper rescale? ---------- nosy: +georg.brandl _______________________________________ Python tracker <report at bugs.python.org> <http://bugs.python.org/issue10650> _______________________________________