[issue10670] Provide search scope limits
New submission from anatoly techtonik techto...@gmail.com: When searching docs (e.g. for http://docs.python.org/dev/search.html?q=unicodecheck_keywords=yesarea=default) I'd like to filter out C API. -- assignee: d...@python components: Documentation messages: 123719 nosy: d...@python, techtonik priority: normal severity: normal status: open title: Provide search scope limits ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10670 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10660] format() to lower and uppercase
Hervé Cauwelier he...@itaapy.com added the comment: Thanks for the example. The Python 2.7 documentation about the mini-language doesn't clearly state that it is extensible and how. we see examples of formatting but not of extending. Your example would be welcome in the documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10660 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10667] collections.Counter object in C
Changes by Daniel Urban urban.dani...@gmail.com: -- nosy: +durban ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10669] Remove Deprecation Warnings
Eric Smith e...@trueblade.com added the comment: Are the warnings originating in your code, or in the standard library, or elsewhere? If in the standard library, please provide specific details. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10668] Array tests have nonsense in them
Georg Brandl ge...@python.org added the comment: Fixed in r87156. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10668 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10516] Add list.clear() and list.copy()
Ray.Allen ysj@gmail.com added the comment: That's good if it's so... can you explain why list_clear doesn't guarantee that the list is empty? Why would XDECREF populate the list? I don't quite understand it. Does this mean that durning the Py_DECREF progress the list may be populated again? It's not a problem. Here is the simplest example(with applying eli's patch): class A(object): def __init__(self, li): self._li = li def __del__(self): self._li.append(self) li = [] li.append(A(li)) li.clear() print(li) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10669] Remove Deprecation Warnings
Rusi rustompm...@gmail.com added the comment: Hi Eric Sorry for not being clear. This is more of a feature request than a bug report as suggested by Terry Reedy on the python mailing list (see here http://mail.python.org/pipermail/python-list/2010-December/1262149.html The warnings are in my code. The main problems are (I expect) from strings/unicode/binary-strings I am suggesting that it would be good to have a place one could go to with each such warnings that would give explanations and possible remedies Rusi On Fri, Dec 10, 2010 at 3:05 PM, Eric Smith rep...@bugs.python.org wrote: Eric Smith e...@trueblade.com added the comment: Are the warnings originating in your code, or in the standard library, or elsewhere? If in the standard library, please provide specific details. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___ -- Added file: http://bugs.python.org/file19995/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___Hi EricbrSorry for not being clear.brThis is more of a feature request than a bug report as suggested by Terry Reedy on the python mailing list (see herebrbra href=http://mail.python.org/pipermail/python-list/2010-December/1262149.html;http://mail.python.org/pipermail/python-list/2010-December/1262149.html/abr brThe warnings are in my code. brThe main problems are (I expect) from strings/unicode/binary-stringsbrI am suggesting that it would be good to have a place one could go to with each such warnings that would give explanations and possible remediesbr brRusibrbrdiv class=gmail_quoteOn Fri, Dec 10, 2010 at 3:05 PM, Eric Smith span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span wrote:brblockquote class=gmail_quote style=margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; br Eric Smith lt;a href=mailto:e...@trueblade.com;e...@trueblade.com/agt; added the comment:br br Are the warnings originating in your code, or in the standard library, or elsewhere?br br If in the standard library, please provide specific details.br br --br nosy: +eric.smithbr divdiv/divdiv class=h5br ___br Python tracker lt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;br lt;a href=http://bugs.python.org/issue10669; target=_blankhttp://bugs.python.org/issue10669/agt;br ___br /div/div/blockquote/divbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue985064] plistlib crashes too easily on bad files
Mher Movsisyan mher.movsis...@gmail.com added the comment: The attached patch fixes crashes on bad input. The patch implements validation for dict and array elements as well as some resource cleanup. The tests are included as well. -- keywords: +patch nosy: +mher Added file: http://bugs.python.org/file19996/plist_validation.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue985064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10611] sys.exit() in a test causes a test run to die
Michael Foord mich...@voidspace.org.uk added the comment: At the moment exception handling for setUp / tearDown / testMethod and cleanUp functions are all handled separately. They all have to call addError and as a result we have inconsistent handling of skips, expected failures (etc). There are separate issues for handling expected failures in setUp and skips in tearDown. I'd like to fix all these issues by moving the exception handling into a single method and unifying the reporting of failure / error / expected failure / skip test. This will fix all these issues and nicely simplify the implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10626] Bad interaction between test_logging and test_concurrent_futures
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: I've added the logging code to implement and use a logger of last resort as discussed on the thread for http://bit.ly/last-resort-handler into the py3k branch, r87157. Gist of differences is available at https://gist.github.com/736120 - so Brian could remove the STDERR_HANDLER from his code. The futures test code can set sys.stderr to an io.StringIO instance during the test; the last resort handler checks for the sys.stderr value when emitting a record, not when the handler is created. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10626] Bad interaction between test_logging and test_concurrent_futures
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: s/logger of last resort/handler of last resort/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10671] urllib2 redirect to another host doesn't work
New submission from Kirill Subbotin kir...@gmail.com: When you open url which redirects to another host (either with 301 or 302), HTTPRedirectHandler keeps Host header from the previous request, which leads to a error. Instead a host should be taken from a new location url. Attached patch is tested with Python 2.6.5. -- components: Library (Lib) files: urllib2.diff keywords: patch messages: 123729 nosy: Kirax priority: normal severity: normal status: open title: urllib2 redirect to another host doesn't work type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file19997/urllib2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10671] urllib2 redirect to another host doesn't work
Senthil Kumaran orsent...@gmail.com added the comment: Can you point me to your code and error traceback that was observed and some details about server which gave 301/302 Redirect as what was the hostname and where did it redirect to? I don't see the code changes that you provided in the patch in the latest versions of urllib, but I am equally surprised if the condition that you said may occur. Because Host will be overridden at some point in time in the Request is made for the new redirected url. You may want to try with python 2.7 or 2.7.1 too and report if you still face the problem. -- assignee: - orsenthil nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10672] [with] new in version 2.6 instead of 2.5
New submission from Mayweed norman.dena...@atosorigin.com: In the documentation, the statement with is marked as: New in version 2.5. (http://docs.python.org/reference/compound_stmts.html#the-with-statement) This new statement is new in version 2.6 ! -- assignee: d...@python components: Documentation messages: 123731 nosy: d...@python, karmaguedon priority: normal severity: normal status: open title: [with] new in version 2.6 instead of 2.5 versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10672] [with] new in version 2.6 instead of 2.5
Georg Brandl ge...@python.org added the comment: It is in fact new in 2.5, but only available when using from __future__ import with_statement, which the note near the end of the section details. -- nosy: +georg.brandl resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10673] multiprocess.Process join method - timeout indistinguishable from success
New submission from Brian Cain brian.c...@gmail.com: When calling Process' join([timeout]) method, the timeout expiration case is indistinguishable from the successful join. I suppose the 'exitcode' attribute can deliver the necessary information, but perhaps join could stand on its own. If join() shouldn't be changed, could we make explicit reference to the exitcode attribute in the documentation? -- components: Library (Lib) files: Process_join.patch keywords: patch messages: 123733 nosy: Brian.Cain priority: normal severity: normal status: open title: multiprocess.Process join method - timeout indistinguishable from success type: feature request versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file19998/Process_join.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3992] remove custom log module from distutils2
Éric Araujo mer...@netwok.org added the comment: distutils2.log has been removed in f6ef30a22a24. I’m leaving this open to remind us we want to remove the warn and announce methods. Logging all the way! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10673] multiprocess.Process join method - timeout indistinguishable from success
R. David Murray rdmur...@bitdance.com added the comment: My guess is it shouldn't, and yes, but I've added the multiprocessing maintainers as nosy and they can answer definitively. -- nosy: +asksol, jnoller, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10673] multiprocess.Process join method - timeout indistinguishable from success
Ask Solem a...@opera.com added the comment: While it makes sense for `join` to raise an error on timeout, that could possibly break existing code, so I don't think that is an option. Adding a note in the documentation would be great. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Giovanni Bajo giovannib...@gmail.com added the comment: Hi Gregory, I saw your commit here: http://code.activestate.com/lists/python-checkins/91914/ This basically means that in 3.2 it is mandatory to specify close_fds to avoid a DeprecationWarning. *BUT* there is no good value that works both on Windows and Linux if you redirect stdout/stderr, as shown in this bug. So basically in 3.2 to avoid a warning, each and every usage of Popen() with a redirection should be guarded by an if that checks the platform. I don't think this is acceptable. Have I misunderstood something? Also: can you please explain how the behaviour is going to change in 3.3? I assume that you are planning to change the default to True; but would that also cover Windows' singularity in redirection cases? -- nosy: +Giovanni.Bajo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10674] Unused dictmaker symbol in 2.* grammar
New submission from Ori Avtalion o...@avtalion.name: Using trunk r87157 The Grammar/Grammar file defines a dictmaker symbol that is no longer referenced in any other symbol. It should be removed. -- components: Interpreter Core messages: 123738 nosy: salty-horse priority: normal severity: normal status: open title: Unused dictmaker symbol in 2.* grammar versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10674 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10669] Remove Deprecation Warnings
Changes by Ezio Melotti ezio.melo...@gmail.com: -- assignee: - d...@python components: +Documentation nosy: +d...@python, ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10644] socket loses data, calling send()/sendall() on invalid socket does not report error and returns all bytes as written
Antoine Pitrou pit...@free.fr added the comment: Ok, closing as invalid. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10644 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10665] Expand unicodedata module documentation
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Thu, Dec 9, 2010 at 6:10 PM, Martin v. Löwis rep...@bugs.python.org wrote: .. Please, one issue per report and checkin, The s/5.2/6.0/ issue is hardly worth a tracker ticket. I've committed these changes in r87159. (Sorry for the unrelated changes - reverted in the next checkin.) and no work-in-progress on the tracker. Why? I thought release early, release often was a good thing. I wanted to get an early feedback because we certainly don't want to replicate the Unicode Standard in the Python documentation, but I think at least for the category() method that returns cryptic 2-letter codes, we should include a table explaining them. I am not so sure about bidirectional() or asian_width(). The issue of factually correcting claims about the unicodedata module and elaborations on how it works are unrelated issues. I am changing the title of the issue to make it cover only the latter. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10665 ___ -- title: Update and expand unicodedata module documentation - Expand unicodedata module documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10665 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10665] Expand unicodedata module documentation
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- nosy: +ezio.melotti, haypo, lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10665 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Milko Krachounov pyt...@milko.3mhz.net added the comment: I'd offer two ideas. 1. Add a constant DISREGARD_FDS to the subprocess module could help. It would allow the user to specify his intent, and let the implementation choose the best action. Popen(..., close_fds=subprocess.DISREGARD_FDS) would mean that any fds additional fds are not needed, and can be closed if it is determined that it is the best course of action. So, if DISREGARD_FDS gets passed on Windows assume close_fds=False, while on POSIX assume close_fds=True (although this has its downsides, see at the bottom). 2. Set the CLOEXEC flag on the other side of the pipes after the fork. With the attached patch, I don't get the issue I reported: Python 3.2b1 (py3k:87158, Dec 10 2010, 20:13:57) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. from subprocess import * p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE, close_fds=False) p2 = Popen(['grep', 'a'], stdin=p1.stdout, stdout=PIPE, close_fds=False) p1.stdin.write(b\n) 17 p1.stdin.close() p2.stdout.read() b'\n' Additional problem with close_fds=True is that if MAXFD is huge, it can cause a huge problem with performance, so perhaps the default being True isn't all that great. On Linux you can close only the open fds, but I'm not sure if that's possible on other POSIX systems. -- keywords: +patch Added file: http://bugs.python.org/file1/subprocess-cloexec-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Milko Krachounov pyt...@milko.3mhz.net added the comment: The cloexec approach still doesn't help with issue 2320. In fact, with threading and people calling subprocess from multiple threads, *this* issue wouldn't be fixed with my patch either unless mutexes are used. It's impossible to avoid a race here with threads and no mutex as far as I can tell. It would mean that the creation of the pipe, the fork and the setting of the CLOEXEC flag needs to be done atomically... yikes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10674] Unused dictmaker symbol in 2.* grammar
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10674 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Giovanni Bajo giovannib...@gmail.com added the comment: Setting CLOEXEC on the pipes seems like a very good fix for this bug. I'm +1 on it, but I think it should be the default; instead, your proposed patch adds a new argument to the public API. Why do you think it's necessary to do so? At the same time, we need a solution to handle close_fds, because the current status of the 3.2 with the DeprecationWarning (on 90% of subprocess uses in the world, if it ever gets backported to 2.7) and no way to fix it in a multi-platform way is really sad. I don't think a new constant DISREGARD_FDS is necessary. I think we can just use None as intermediate default (just like the current 3.2 does), and later switch it to True. The only further required action is to make True always work on Windows and never error out (just make it do nothing if there are some redirections), which is an obviously good thing to do to increase portability of subprocess. Otherwise, if this can't make 3.2, I think the DeprecationWarning should be reverted until we agree on a different solution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Changes by Milko Krachounov pyt...@milko.3mhz.net: Removed file: http://bugs.python.org/file1/subprocess-cloexec-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Milko Krachounov pyt...@milko.3mhz.net added the comment: I'm +1 on it, but I think it should be the default; instead, your proposed patch adds a new argument to the public API. Why do you think it's necessary to do so? I don't think it's necessary. I put it there because when I was testing I thought it might help. For example, you might want to keep the pipes open and then open another process with close_fds=False, thus changing the current default might cause some regressions in some software and an argument would allow an easier transition. I updated the patch removing anything unnecessary. Though it still has a huge race when used with threading. -- Added file: http://bugs.python.org/file2/subprocess-cloexec-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10675] unittest should have an assertChanges context manager
New submission from Jay Moorthi moor...@gmail.com: It would be useful to have a new assert method in the unittest.TestCase class that checks to see if a value has changed. I wrote a quick and dirty version like so: class MySpecialTestCase(unittest.TestCase): @contextmanager def assertChanges(self, thing, attr=None, by=None): def get_value(thing, attr): if callable(thing): value = thing() else: value = getattr(thing, attr) return value old_value = get_value(thing, attr) yield new_value = get_value(thing, attr) if by is None: self.assertNotEqual(new_value, old_value) else: self.assertEqual(new_value - old_value, by) I'm sure something better can be done to take better advantage of the unittest module's diffing tools, etc. -- messages: 123745 nosy: Jay.Moorthi priority: normal severity: normal status: open title: unittest should have an assertChanges context manager type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Giovanni Bajo giovannib...@gmail.com added the comment: Would you mind elaborating on where is the race condition? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: issue2636-20101210.zip is a new version of the regex module. I've extended the additional checks of the previous version. It has been tested with Python 2.5 to Python 3.2b1. -- Added file: http://bugs.python.org/file20001/issue2636-20101210.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Milko Krachounov pyt...@milko.3mhz.net added the comment: It's almost exactly the same race condition as the one described in issue 2320. The pipes are created and stay without the CLOEXEC flag for a while (until the process has been forked and fcntl has been called). During that time another thread can launch a subprocess, the subprocess will inherit the pipe, and there might be a hang similar to the one described here (or in issue 2320). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10675] unittest should have an assertChanges context manager
R. David Murray rdmur...@bitdance.com added the comment: I think this is the kind of thing where you are *much* better off writing a specialized assert method that exactly fits your use case. There are too many variations on this theme, IMO, for it to make sense as an stdlib method. -- nosy: +michael.foord, r.david.murray resolution: - rejected stage: - committed/rejected status: open - pending versions: +Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10675] unittest should have an assertChanges context manager
Changes by Benjamin Peterson benja...@python.org: -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10676] Confusing note in Numeric Types
New submission from Philip Bober pdbo...@gmail.com: In the Python Standard Library reference, section 5.4: Numeric Types, the table of operators/functions has the following unclear note: (4)Complex floor division operator, modulo operator, and divmod(). Deprecated since version 2.3: Instead convert to float using abs() if appropriate. The intention of this note is to indicate that //,%, and divmod shouldn't be used with complex numbers, but the phrasing is bad and the note being on generic operators makes it sound like the operators themselves are deprecated, not just for complex numbers. There was an earlier bugfix (621708, on the previous tracker. Archive: http://mail.python.org/pipermail/python-bugs-list/2002-October/013913.html) which fixed this bad wording elsewhere in the docs (Section 5.6 Binary arithmetic operations in the Python Reference Manual) but it seems the same wording was in both documents and it was only patched in one of them. It was replaced with: Deprecated since version 2.3: The floor division operator, the modulo operator, and the divmod() function are no longer defined for complex numbers. Instead, convert to a floating point number using the abs() function if appropriate. -- assignee: d...@python components: Documentation messages: 123750 nosy: Philip.Bober, d...@python priority: normal severity: normal status: open title: Confusing note in Numeric Types versions: Python 2.5, Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10676 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10667] collections.Counter object in C
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10675] unittest should have an assertChanges context manager
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I concur with David Murray. Usually you care about the specific value changed to, not whether it changed at all. The changed-by variant is even more specialized and you're better of using assertEqual since you know what the new value is supposed to be: assertEqual(thing.attr, x) ... assertEqual(thing.attr, x+by) -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10675] unittest should have an assertChanges context manager
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Thanks for submitting the idea though. Perhaps, post it on the ASPN Cookbook or on the newsgroup to see if others are interested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10665] Expand unicodedata module documentation
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: In issue10665.diff, I completed the character examples in the general categories table. -- Added file: http://bugs.python.org/file20002/issue10665.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10665 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Ned Deily n...@acm.org added the comment: (Adding the 3.2 release manager: a potential release blocker?) -- nosy: +georg.brandl, ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
SilentGhost michael.mischurow+...@gmail.com added the comment: Not sure this worth a patch, to me it looks like a removal of a single word. But here it goes anyway. -- nosy: +SilentGhost Added file: http://bugs.python.org/file20003/stdtypes.rst.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10665] Expand unicodedata module documentation
Martin v. Löwis mar...@v.loewis.de added the comment: Why? I thought release early, release often was a good thing. Create a branch for that, or post an issue on Rietveld. W-I-P IMO confuses people reviewing the patches, running into the same ones over-and-over again, only to find out every time it's not ready yet. So the natural reaction is to close it as rejected, for it being incomplete. Regards, Martin -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10665 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Daniel Stutzbach stutzb...@google.com added the comment: In bltinmodule.c, it looks like some of the indentation doesn't line up? Bikeshedding aside, it looks good to me. I agree with Eric Smith that the first part macro name usually refers to the type of the first argument (or the type the first argument points to). Examples: - Py_UNICODE_ISSPACE : Py_UNICODE - int - Py_UNICODE_TOLOWER : Py_UNICODE - Py_UNICODE - Py_UNICODE_strlen: Py_UNICODE * - size_t This is true elsewhere in the code as well: - PyList_GET_SIZE : PyListObject * - Py_ssize_t Yes, I know there are some unfortunate exceptions. ;-) I agree that it would be nice if something in the name hinted that the return type was Py_UCS4 though. Marc-Andre Lemburg wrote: The first argument of the macro can be any array, not just Py_UNICODE*, but also Py_UCS4* or even int*. It's true that macros in C do not have any type safety. While technically passing a Py_UCS4 * will work, on a UCS2 build it would needlessly check the Py_UCS4 data for surrogates. I think we should discourage that. You can also technically pass a PyListObject * to PyTuple_GET_SIZE, but that's also not a good idea. ;-) Alexander Belopolsky wrote: The issue is that once in in the process of reading the codepoint, it is determined whether the code point is BMP or non-BMP. Testing the result again in order to write it is somewhat wasteful. I don't think this would matter in practice, but would like to hear alternative opinions before moving further. If the common pattern is: ch = Py_UNICODE_NEXT(rp, end); uc = Py_UNICODE_SOME_TRANSFORMATION(ch); Py_UNICODE_PUT_NEXT(wp, uc); The second check for surrogates in Py_UNICODE_PUT_NEXT is necessary, unless you can prove that Py_UNICODE_SOME_TRANSFORMATION will never transform characters 0x1 into characters 0x1 or vice versa. Can we prove will always be the case, for current and future versions of Unicode, for all or almost-all of the transformations we care about? Answering that question and figuring out what to do about it are probably more trouble than it's worth. If a particularly point proves to be a bottleneck, we can always specialize the code there later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue985064] plistlib crashes too easily on bad files
Ned Deily n...@acm.org added the comment: One review comment: the patch adds a new exception class that is used for the errors that are now additionally detected. Elsewhere plistlib uses non-specific exception classes like ValueError. If starting from scratch, it might be better to consistently use a specific exception class but that would create incompatibilities if changed now. I don't see a compelling need to add one now just for these errors. (But, if kept, it should be added to the docs.) Otherwise, looks good to me. Thanks for taking this on! -- nosy: +ned.deily, ronaldoussoren stage: unit test needed - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue985064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10667] collections.Counter object in C
Justin Peel pee...@gmail.com added the comment:
I've done as Antoine asked and made a pure Python PyCounter class and a
C-enhanced Counter class that both use the mixin CounterBase class. I also
added to the tests so that both PyCounter and Counter are tested. I left the
update_fromsubs() method in Counter for now, but haven't made a Python
equivalent function for PyCounter in case the method is rejected.
Also, I realized that my build was still in debug mode so those benchmark
weren't quite accurate (Oops). The Counter class is only 4-6x faster for most
cases. That's still good, but not quite as good as I'd previously reported.
Lastly, I thought of one more method that could be quite useful. Say that you
have a list like [('apples',4),('oranges',5),('apples',8)] where the second
element in each tuple indicates how many of them there are. The resultant
Counter should have {'apples': 12, 'oranges':5}. We don't really have a good
way to count this, but we could add a small method like the following:
def fromitems(self, items):
for key, value in items:
self[key] += value
and I could easily make a C function for it. I think that this simple method
could be very useful to some people. What do you all think of this addition?
--
Added file: http://bugs.python.org/file20004/counterpatch2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10667
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Applied in r87162 -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10667] collections.Counter object in C
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I would like this API to sit and cook for a good while. There are many possible ways to add more methods and most be end-up being YAGNI. Also, my experience with dict.fromkeys() is that a fair number of people get confused by alternative constructors. So, at this point I have zero interest in adding from_items(). Am taking the C optimizations under advisement. In the meantime, there is no need to keep submitting patch variations. The question is less how-to-do-it and more a question of whether-to-do-it. We try not to add an alternate C paths unless a feature is an important building block. There is an on-going maintenance cost and a risk of slightly different behaviors (at a minimum, the tracebacks look different and the code can't be traced through pdb). That being said, there is a nice speed-up to be had, so I'll give that some weight. -- priority: normal - low resolution: - later ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Nick Coghlan ncogh...@gmail.com added the comment: The other major change for ranges is that in and not in are no longer inefficient for actual instances of int (it does an arithmetic calculation instead of a linear search). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Milko Krachounov pyt...@milko.3mhz.net added the comment: I created another patch that attempts to create the pipes atomically. On GNU/Linux, if pipe2 is available, it uses it to create the pipes, and there is no race. On other POSIX platforms, pipe and fcntl are called without releasing the GIL - relying on the fact that _posixsubprocess.fork_exec doesn't release the GIL either, so the two can't run at the same time (bonus: os.fork doesn't release the GIL either). I can't reproduce neither issue 7213 nor issue 2320 with either implementation, so the patch seems to fix them. Issues: 1. If the _posixsubprocess module isn't compiled, the race still exists (well, without it subprocess isn't safe to use with threads anyway). 2. On GNU/Linux systems where glibc was compiled with kernel headers =2.6.27, but the running kernel is 2.6.27, the subprocess module won't work. (There should be a fix for that?) 3. I have no way to tell that the non-Linux implementation works for sure. I've been running it in an endless loop, and so far there have been no hangs (*), but that doesn't mean that it doesn't have a rare race that's beyond my comprehension. With pipe2() you can be certain, but I have my doubts about the other implementation. All unit tests seem to pass. (*) Actually, I *thought* it hang on my first attempt, but I interrupted the process too soon to tell for sure. No hangs after that. :( -- Added file: http://bugs.python.org/file20005/subprocess-cloexec-atomic-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue678250] test_mmap failing on AIX
R. David Murray rdmur...@bitdance.com added the comment: Committed the patch_flush_mmap patch to 3.1 in r87163 and 2.7 in r87164. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue678250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Is the in/not-in fast path in 2.7? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
STINNER Victor victor.stin...@haypocalc.com added the comment: Can you add a test to your patch? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6697] Check that _PyUnicode_AsString() result is not NULL
STINNER Victor victor.stin...@haypocalc.com added the comment: issue6697-lsprof.diff: - Oh, I did recently a similar change on PyModule: I created PyModule_GetFilenameObject() - PyObject * mod = PyObject *mod - modname is not initialized if fn-m_module (mod) is NULL = initialize modname to NULL - there is a reference leak (modname) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10667] collections.Counter object in C
Justin Peel pee...@gmail.com added the comment: Okay, I was done submitting. I thought that Antoine was asking for a version that kept a pure Python version so I did that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10642] site.py crashes on python startup due to defective .pth file
STINNER Victor victor.stin...@haypocalc.com added the comment: Yes, I patched the C code to not clear exceptions anymore at startup: r78826 (issue #3137). But this issue is different: here the bug is in the 3rd party module (loaded by site.py), not in Python, and Donald proposes to *ignore* errors (where I did the opposite). This places python at the mercy of bugs in third-party software. Why do you consider this as a bug? Yes, Python allows to be extended by 3rd party softwares. And if you install bogus extensions, you break your Python setup. Ignore errors is never a good idea. How would you notice that the extension is disabled because it is bogus? I prefer explicit errors to force the user to fix its setup. Extract of the Gentoo issue: The direct cause of your problem is that you manually created /usr/lib64/python2.7/site-packages/zope/__init__.py file. Please remove it: rm -f /usr/lib64/python2.7/site-packages/zope/__init__.py* I close this issue because I think that ignore errors is not a good idea. If you disagree, you can still comment this issue, or reopen it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10642 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2857] add codec for java modified utf-8
STINNER Victor victor.stin...@haypocalc.com added the comment: I wonder if tkinter should use this encoding. Tkinter is used to build graphical interfaces. I don't think that users write nul bytes with their keyboard. But there is maybe a use case? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2857 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10492] test_doctest fails with iso-8859-15 locale
STINNER Victor victor.stin...@haypocalc.com added the comment: You can reproduce the bug with: $ lang=fr_fr.iso885...@euro ./python -c 'import pdb; pdb.Pdb(nosigint=True).run(exec(%r) % x=12)' /home/haypo/prog/SVN/py3k/Lib/encodings/iso8859_15.py(15)decode() - return codecs.charmap_decode(input,errors,decoding_table) (Pdb) quit (it should print x=12 in the backtrace, not ...iso8859_15.py...) Simplified C backtrace: builtin_exec() - PyRun_StringFlags() - PyAST_CompileEx() - makecode() - PyUnicode_DecodeFSDefault(). ISO-8859-15 codec is implemented in Python whereas ASCII, ISO-8859-1 and UTF-8 are implemented in C. Pdb stops at the first Python instruction. The user expects that the first instruction is x=12, but no, the real first Python instruction is calling ISO-8859-15 to decode the byte string string (script filename). I see two solutions: - set the trace function later. Eg. replace exec(cmd, ...) by code=compile(cmd, ...) + exec(code) and set the trace function after the call to compile. I don't know if both codes are equivalent. - reimplement ISO-8859-15 in Python: it doesn't solve the issue, there are other encodings implemented in Python -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10492 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10515] csv sniffer does not recognize quotes at the end of line
R. David Murray rdmur...@bitdance.com added the comment: What do you mean by there is a test for this case in csv.py? If I run sniffer against abcde\ndefgh\n I get a delimiter of 'e'. If I run it against 'a\nb\n', I get the could not determine delimiter error. Attached is a reformulated test case that lets us see the errors individually and easily add more. With this set of 10 tests, two pass without your patches (as you knew; those are your tests), and we have 4 failures and 4 errors. With p1 applied we have 4 failures and 3 errors. With p2 applied we have 5 failures. As I said, I'm not at all sure what the results *should* be for various of these cases. Certainly the long standing existing behavior seems to be to return one of the characters in an unquoted multicharacter sequence. That said, it seems like your patch p1 is good, but as you discovered not sufficient. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10515] csv sniffer does not recognize quotes at the end of line
R. David Murray rdmur...@bitdance.com added the comment: Forgot to attach the patch. -- Added file: http://bugs.python.org/file20006/csv_delimiter_tests.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10492] test_doctest fails with iso-8859-15 locale
STINNER Victor victor.stin...@haypocalc.com added the comment: See a more complex solution: #3080 (don't decode the filename in the parser, keep unicode strings). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10492 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1574217] isinstance swallows exceptions
R. David Murray rdmur...@bitdance.com added the comment: Upon reflection I think the risk of breaking apparently working programs is higher than the benefit to be obtained from backporting this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1574217 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10642] site.py crashes on python startup due to defective .pth file
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10642 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10669] Document Deprecation Warnings and how to fix
Terry J. Reedy tjre...@udel.edu added the comment: The issue is not the specific warnings Rusi got but how, in general, one can get more information when the warnings are too cryptic to deal with. One response might be that DeprecationWarnings should be much wordier than they are -- a paragraph of a few sentences rather than just a minimal sentence. Another might be that each release have a HOW-TO doc or What's New section with a paragraph for each one added to that release. Currently, information is scattered among pydev posts, tracker issues, commit messages, News entries, and maybe What's new. -- nosy: +rhettinger, terry.reedy title: Remove Deprecation Warnings - Document Deprecation Warnings and how to fix versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10674] Unused dictmaker symbol in 2.* grammar
Benjamin Peterson benja...@python.org added the comment: r87167 -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10674 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10674] Unused dictmaker symbol in 2.* grammar
Terry J. Reedy tjre...@udel.edu added the comment: Your links are to py3k branch, where dictmaker does not appear. http://svn.python.org/view/python/branches/release27-maint/Grammar/Grammar?view=markup should that Benjamin just removed it from 2.7. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10674 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Nick Coghlan ncogh...@gmail.com added the comment: No, I believe it was added as part of the .index() and .count() implementation. Checking the source, there's definitely no sq_contains implementation in 3.1 or 2.7. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10669] Document Deprecation Warnings and how to fix
Ezio Melotti ezio.melo...@gmail.com added the comment: The deprecation notes in the doc should be quite easy to find and can be more verbose, but there are a few cases where the deprecation is not about a specific function but something more abstract (e.g. some syntax change, or the Overriding __eq__ blocks inheritance of __hash__ in 3.x reported by the OP). Listing new deprecations in the what's new it's a good idea, but otherwise a clear message (that also suggests how to fix the problem) and a deprecation note in the doc (using the '.. deprecated::' directive) should be enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
