[issue12896] Recommended location of the interpreter for Python 3
New submission from Lennart Regebro : The documentation on Using Python, 2.3. Python-related paths and files says that "exec_prefix/bin/python" is the recommended location for the interpreter, while for Python 3 it's "exec_prefix/bin/python3". http://docs.python.org/py3k/using/unix.html#python-related-paths-and-files -- assignee: docs@python components: Documentation messages: 143508 nosy: docs@python, lregebro priority: normal severity: normal status: open title: Recommended location of the interpreter for Python 3 versions: Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue12896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Lennart Regebro added the comment: We *do* care about NotImplemented, that's the whole point of this bug report. I don't see how this is a problem in the new_total_ordering.py example. Can you give an example of when you get a stack overflow? The examples in new_total_ordering are in themselves badly implemented, as they do check of the class with an isinstance, but if it is not the correct instance, they will return False or raise a TypeError. That's wrong, they should return NotImplemented, to give the other class a chance. But that is not a problem for the tests, it's only a problem if you use the tests as examples of how to implement a comparable class. But in no case am I able to get a stack overflow here, which I can with the old total_ordering recipe. -- ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Lennart Regebro added the comment: I'm attaching a file with the example classes returning NotImplemented, and a different implementation of a total ordering, as an example of how returning NotImplemented by one class will give the chance to the other class. This is the ultimate cause of the bug, and new_total_ordering handles it properly. -- Added file: http://bugs.python.org/file21711/new_total_ordering_notimplemented.py ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Lennart Regebro added the comment: Ah! I see how you mean. The problem isn't just if you turn the conversion around from self > other to other < self. The problem in fact appears when a rich text function uses the <>!= operators on self directly. I tried a version which uses the __xx__ operators directly and that works for the ones that does not use "not". "not NotImplemented" is false, for obvious reasons, and that means that with for example "lambda self, other: not self.__ge__(other)" will return False, when it should return NotImplemented. In effect this means that the total ordering recipe only works as long as you don't compare two classes that use the total ordering recipe. :-) I don't think the lambda technique is going to work properly. Of course we can say that we should care about NotImplemented, but then first of all this recipe needs a big "this is broken, don't use it unless you know what you are doing" label, and secondly I don't think it should have been included in the first place if we can't make it work properly. -- ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Lennart Regebro added the comment: Yeah, I can't say it's pretty though. :) Anyway this is an issue for 3.2 and 2.7 as well, then, so I add them back. -- versions: +Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Lennart Regebro added the comment: I was also surprised by the special return value, but it seems a bit overkill to change the implementation of rich comparison operators just because it's tricky to make a short and pretty class decorator that extends some operators to all operators. :) And removing the support for returning NotImplemented is something that only can be done at the earliest in 3.4 anyway. -- ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9124] Mailbox module demonstrates infeasibly slow performance
Lennart Regebro added the comment: I can confirm on Ubuntu and with other example mailboxes. Looping through the messages and printing the subjects takes around 200-300 times longer under Python 3 than under Python 2. -- nosy: +lregebro ___ Python tracker <http://bugs.python.org/issue9124> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9124] Mailbox module demonstrates infeasibly slow performance
Lennart Regebro added the comment: 3.2 sees a small improvement when running the Steve test: Python 2.6.6: 0.0291s Python 3.1.2: 31.1s Python 3.2b2+: 28.8s This is Ubuntu 10.04 on ext3, with all Pythons compiled from source, with no configure attributes except a prefix. I wonder if the differences between different unix systems can have to do with what the default system encoding is? Mine is UTF-8. -- ___ Python tracker <http://bugs.python.org/issue9124> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10954] No warning for csv.writer API change
New submission from Lennart Regebro : In Python 2 the file used for csv.writer() should be opened in binary mode, while in Python 3 is should be opened in text mode but with newlines set to ''. This change is neither warned for by python -3, nor is there a fixer for it (and making a fixer would be tricky), thus it provides a surprising API change. I think that csv.writer() should warn or even fail if the file is opened in binary mode under Python 3. Failing is a god option, as a binary file is likely to be a port from Python 2, and you are likely to get the less useful message "must be bytes or buffer, not str". Even if you understand that message, you will then probably just change the file mode from binary to text, but you will not add the lineendings='' parameter, and thusly you might cause subtle error on windows. -- components: 2to3 (2.x to 3.0 conversion tool), Library (Lib) messages: 126596 nosy: lregebro priority: normal severity: normal status: open title: No warning for csv.writer API change type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue10954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10954] No warning for csv.writer API change
Changes by Lennart Regebro : -- nosy: +sjmachin ___ Python tracker <http://bugs.python.org/issue10954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering stack overflow
Lennart Regebro added the comment: This also affects Python 2.7, where it hasn't been fixed. Maybe reopen it? -- nosy: +lregebro ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10954] No warning for csv.writer API change
Lennart Regebro added the comment: In the worst case, not checking for newline='' is not a big problem, as anyone moving from Python 2 to Python 3 will open the file in binary mode. That error message could tell the user to use binary mode newlines=''. Using textmode and newlines is only likely to happen with people writing new code for Python 3 and not reading the docs, which is a different problem. :-) -- ___ Python tracker <http://bugs.python.org/issue10954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Changes by Lennart Regebro : Removed file: http://bugs.python.org/file15537/python-py3k-exception-detail.diff ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Changes by Lennart Regebro : Removed file: http://bugs.python.org/file15538/python-trunk-exception-detail.diff ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Lennart Regebro added the comment: New diff for trunk, with the additional test -- Added file: http://bugs.python.org/file15972/python-trunk-exception-detail.diff ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Lennart Regebro added the comment: New diff for Py3k with the additional test -- Added file: http://bugs.python.org/file15973/python-py3k-exception-detail.diff ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Lennart Regebro added the comment: The ellipsis doesn't work, because when you have an ellipsis at the beginning of the message, doctest will not understand that it's supposed to be an Exception, so it doesn't even try to match exceptions, and it will therefore always fail. -- ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Lennart Regebro added the comment:
Sure: Catch the exception in the test, and fail if it isn't catched.
>>> try:
... do_something_that_raises_exception()
... raise Assertionerror("Exception Blah was not raised")
... except Blah:
... pass
Ugly, yes, but easy. To make it less ugly you can make a "assertRaises()" like
the one that exists on standard unit tests and call that. Not so ugly.
--
___
Python tracker
<http://bugs.python.org/issue7490>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Lennart Regebro added the comment: It's not possible for 2to3 to reformat exceptions, as the formatting would need to go from TheException to themodule.TheException, and there is no way to figure out the module name... -- ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Lennart Regebro added the comment: Sure, but +IGNORE_EXCEPTION_DETAIL will only work on Python 3.2+, so 2to3 can't solve the issue. It can only help once 3.2 does the actual solving. ;) 3to2 could simply remove the module name from exceptions in the output. You don't need to touch IGNORE_EXCEPTION_DETAIL for that. -- ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8471] Unicode returns in doctest can make subsequent tests fail
New submission from Lennart Regebro :
If we return unicode, SpoofOut's buf variable becomes automagically converted
to unicode. This means all subsequent output becomes converted to unicode, and
if the output contains non-ascii characters that fails.
That means that
>>> print u'\xe9'.encode('utf-8')
é
Will work just fine, but
>>> print u'abc'
abc
>>> print u'\xe9'.encode('utf-8')
é
Will fail.
The reason for this is that when "resetting" the doctest output only a
truncate(0) is done, so the buf variable will continue to be unicode. I include
tests + a patch that will set self.buf to '' if empty when trunkated. Other
options are also possible, like changing the .truncate(0) to a .buf = '' but
that's ugly, or adding a reset() method on SpoofOUt.
--
components: Extension Modules, Tests
files: doctest_unicode.patch
keywords: patch
messages: 103728
nosy: lregebro
severity: normal
status: open
title: Unicode returns in doctest can make subsequent tests fail
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17007/doctest_unicode.patch
___
Python tracker
<http://bugs.python.org/issue8471>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8473] doctest fails if you have inconsistent lineendings
New submission from Lennart Regebro : If the doctest file has both Windows and unix lineendings you get an error. Yeah, I know, it's not a serious bug, but it's also easy to fix. Attached patch with test. Seems to not be an issue on Python 3. -- components: Extension Modules, Tests files: doctest_lineendings.patch keywords: patch messages: 103735 nosy: lregebro severity: normal status: open title: doctest fails if you have inconsistent lineendings versions: Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file17008/doctest_lineendings.patch ___ Python tracker <http://bugs.python.org/issue8473> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4559] Whats new recommendation error
New submission from Lennart Regebro <[EMAIL PROTECTED]>: The whatsnew/3.0.rst document claims "It is not recommended to try to write source code that runs unchanged under both Python 2.6 and 3.0; you’d have to use a very contorted coding style, e.g. avoiding print statements, metaclasses, and much more. " This is no longer true, since 2.6 now has much backwards compatibility, including fopr print statements and unicode, so it's prefectly possible and not at all contorted to support both any longer. I'd recommend that the above statement is changed to "under both Python 2.5 and 3.0" or simply removed. -- assignee: georg.brandl components: Documentation messages: 77108 nosy: georg.brandl, lregebro severity: normal status: open title: Whats new recommendation error versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4559> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4559] Whats new recommendation error
Lennart Regebro <[EMAIL PROTECTED]> added the comment: That is not true, and statement as it stands now is still factually incorrect. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4559> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4559] Whats new recommendation error
Lennart Regebro <[EMAIL PROTECTED]> added the comment: A future import is not much of a contortion, and metaclasses is not exactly an everyday occurrence, after 9 years of python I have yet to write a metaclass... Of course I don't like that it specifically mentiones 2.6, while 2.6 has lot's of forwards compatibility just to make it possible to write code that runs under both. It will always be true for 2.5, and then we could fix the issue by changing 2.6 to 2.5. If you want to keep the statement for 2.6, it could possibly be reformulated less strongly, or as a minimum change come up with another example than something that actually has a forward compatibility in 2.6. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4559> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4559] Whats new recommendation error
Lennart Regebro <[EMAIL PROTECTED]> added the comment: I've never said that is the goal. You are misrepresenting or misinterpreting my standpoint. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4559> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4559] Whats new recommendation error
Lennart Regebro <[EMAIL PROTECTED]> added the comment: Well, that *is* the intention of a from __future__ import, isn't it? That doesn't mean that's the intention of 2.6 as a whole, just that statement. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4559> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4559] Whats new recommendation error
Lennart Regebro <[EMAIL PROTECTED]> added the comment: Fair enough, but I still think we can come up with a better example that requires more contortions than "print", which doesn't. I think a good example of contortions is binary file data, which has two different types in 2.6 and 3.0. Also making sure that you use iterators all the time when using large sets of data can get quite contorted. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4559> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4664] import urlparse, cStringIO breaks
New submission from Lennart Regebro : If you have urlparse before cStringIO in an import line, 2to3 will not convert the cStringIO to io. However, reverse the order, and urlparse will not get translated. So this file: import urlparse, cStringIO import cStringIO, urlparse will with 2to3 return the following diff: --- test3.py (original) +++ test3.py (refactored) @@ -1,3 +1,3 @@ -import urlparse, cStringIO -import cStringIO, urlparse +import urllib.parse, cStringIO +import io, urlparse -- components: 2to3 (2.x to 3.0 conversion tool) messages: 77815 nosy: lregebro severity: normal status: open title: import urlparse, cStringIO breaks type: behavior versions: Python 3.0 ___ Python tracker <http://bugs.python.org/issue4664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4664] fix_imports does not refactor "import urlparse, cStringIO" correctly
Lennart Regebro added the comment: Heres my test file. Added file: http://bugs.python.org/file12357/test3.py ___ Python tracker <http://bugs.python.org/issue4664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4664] fix_imports does not refactor "import urlparse, cStringIO" correctly
Lennart Regebro added the comment: What version are you running? Can you post the output? ___ Python tracker <http://bugs.python.org/issue4664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12932] dircmp does not allow non-shallow comparisons
Lennart Regebro added the comment: filecmp is still there in Python 3.3 Alpha 3. I can't find any reference to it being deprecated. -- nosy: +lregebro ___ Python tracker <http://bugs.python.org/issue12932> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15760] make install should generate grammar file
New submission from Lennart Regebro: If you install Python 3.3b2 with "sudo make install", a standard way of installing it so that users don't have rights to install global modules, then everytime lib2to3.pgen2.driver.load_grammar() is called, it aims to generate a a grammar table and write it as a pickle to a cache file. However, unless you are superuser when doing this, writing the file will of course fail, with a message similar to this: INFO:root:Generating grammar tables from /opt/python33/lib/python3.3/lib2to3/PatternGrammar.txt INFO:root:Writing grammar tables to /opt/python33/lib/python3.3/lib2to3/PatternGrammar3.3.0.beta.2.pickle INFO:root:Writing failed:[Errno 13] Permission denied: '/opt/python33/lib/python3.3/lib2to3/PatternGrammar3.3.0.beta.2.pickle' A workaround is to run the script that creates the above errors as superuser once, and the message goes away. I think the correct thing to do here is for make install to Generate these grammar tables and write the pickle. Steps to reproduce: 1. Install Python 3.3.b2 with "./configure;make;sudo make install" 2. Check out the Distribute sources: "hg clone https://bitbucket.org/stefanholek/distribute"; 3. Run the Distribute tests: "python3.3 setup.py test" -- messages: 168854 nosy: lregebro priority: normal severity: normal status: open title: make install should generate grammar file type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue15760> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15760] make install should generate grammar file
Changes by Lennart Regebro : -- components: +Installation ___ Python tracker <http://bugs.python.org/issue15760> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15760] make install should generate grammar file
Lennart Regebro added the comment: Yes, and for some reason it didn't show up when I searched for "Grammar" 10 minutes ago, but now it does. :-) It's a duplicate, indeed. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue15760> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2
Lennart Regebro added the comment: I can confirm that this is an issue on Ubuntu 12.04 as well, and that removing the existing pre 3.3b2 install before installing solves the problem. -- nosy: +lregebro ___ Python tracker <http://bugs.python.org/issue15645> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21634] Pystone uses floats
New submission from Lennart Regebro: Pystone uses some floats in Python 3, while in Python 2 it's all integers. And since it is, as far as I can tell, based on Dhrystone, it should be all ints. After fixing the division in the loop to be a floor division it runs the same as in Python 2. I've verified that after the attached fix the only floats created are time stamps, so this seems to be all that's needed. This also makes the benchmark run c:a 5% faster, lessening the speed difference in pystone between Python 2 and Python 3, which contributes to the misconception that Python 3 is horribly slow. -- components: Benchmarks files: pystone.diff keywords: patch messages: 219559 nosy: lregebro priority: normal severity: normal status: open title: Pystone uses floats type: performance versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35442/pystone.diff ___ Python tracker <http://bugs.python.org/issue21634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21634] Pystone uses floats
Lennart Regebro added the comment: Yes, good point, I added this in a new diff. -- Added file: http://bugs.python.org/file35443/pystone12.diff ___ Python tracker <http://bugs.python.org/issue21634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21634] Pystone uses floats
Lennart Regebro added the comment: Oups, yes, that's a typo. -- ___ Python tracker <http://bugs.python.org/issue21634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21634] Pystone uses floats
Lennart Regebro added the comment: Awesome, thanks! -- ___ Python tracker <http://bugs.python.org/issue21634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
New submission from Lennart Regebro : In Python 3.x [1] the exception formatting prints the module path, while under 2.x it prints only the exception class name. This makes it very tricky to make doctests that pass under both Python 2 and Python 3 without resorting to ugly tricks. Since IGNORE_EXCEPTION_DETAIL was implemented to hide differences between exception messages in 2.3 and 2.4, it was suggested on python-dev [2] that IGNORE_EXCEPTION_DETAIL should be extended to also ignore the module name, so that `module.name.ExceptionClass` and `ExceptionClass` would match each other. This is easily done by just changing the regexp that is done for matching. I'll attach diffs both for trunk and for py3k-branch, so that both forms can be used on both versions. The diffs include tests and suggested documentation changes (although I reserve the right to be useless at writing documentation). [1] And possibly in some cases under Python 2.7 according to reports in the thread on python-dev about this issue, although I haven't been able to confirm this. I'll include a 2.7 diff anyway, as it would be good if both syntaxes work under both versions, if people start using 3to2, for example. [2] http://mail.python.org/pipermail/python-dev/2009-December/094460.html -- components: Tests files: python-py3k-exception-detail.diff keywords: patch messages: 96329 nosy: lregebro severity: normal status: open title: IGNORE_EXCEPTION_DETAIL should ignore the module name type: behavior versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file15537/python-py3k-exception-detail.diff ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Changes by Lennart Regebro : Added file: http://bugs.python.org/file15538/python-trunk-exception-detail.diff ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Lennart Regebro added the comment: Yes, x.y.Exception and a.b.Exception should match. I just realized I didn't add an explicit test for that, but maybe that's not strictly necessary. -- ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5616] Distutils 2to3 support doesn't have the doctest_only flag.
New submission from Lennart Regebro : The run_2to3 method, and therefore also the Mixin2to3 class doesn't take a parameter for doctest_only parameter that refactor has. That means you have to do a lot of code duplication if you want to write distutil commands that handle doctest files. The fix is simple, just add the parameter to the relevant methods. -- assignee: tarek components: 2to3 (2.x to 3.0 conversion tool), Distutils messages: 84689 nosy: lregebro, tarek severity: normal status: open title: Distutils 2to3 support doesn't have the doctest_only flag. type: feature request versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5616] Distutils 2to3 support doesn't have the doctest_only flag.
Lennart Regebro added the comment: Also, the run_2to3 method takes the explicit parameter, but does not pass it into the DistutilsRefactoringTool. -- ___ Python tracker <http://bugs.python.org/issue5616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17393] stdlib import mistaken for local by import_fixer
New submission from Lennart Regebro: If you have a local folder (without an __init__.py, hence just a normal folder) with the same name as a non local module, the import statements of that module will assumed to be local and transformed from for example ``import datetime`` to ``from . import datetime``. -- components: 2to3 (2.x to 3.x conversion tool) messages: 183894 nosy: lregebro priority: normal severity: normal status: open title: stdlib import mistaken for local by import_fixer versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue17393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17393] stdlib import mistaken for local by import_fixer
Changes by Lennart Regebro : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue17393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17393] stdlib import mistaken for local by import_fixer
Lennart Regebro added the comment: Not really, but they are related. The fixer looks for a local module, and if it finds it it will assume the import is local. #13317 is caused by it not finding the module, since it's not built and hence assuming it's a global import. This bug, contrariwise, is cause by the fixer finding a folder, and therefore assuming it is a local import when it's not. The fix for this is to check that the folder has an __init__.py. The fix for #13317 is to build extensions before running 2to3. Neither of them are huge problems since you can avoid both bugs but not using relative imports. :-) -- ___ Python tracker <http://bugs.python.org/issue17393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17486] datetime.timezone returns the wrong tzname()
New submission from Lennart Regebro:
When calling tzname() on a timezone object it will return "UTC" + the offset.
>>> from datetime import timezone, timedelta, datetime
>>> tz = timezone(timedelta(hours=3))
>>> dt = datetime(2013, 3, 14, 12, 30, tzinfo=tz)
>>> dt.tzname()
'UTC+03:00'
But this breaks strftime:
>>> dt.strftime("%Z%z")
'UTC+03:00+0300'
I think that tzname() should never return an offset, and that for the static
offset "timezone" class should always return 'GMT' for any offset, unless a
name was explicitly set when creating the timezone instance.
The timezone.utc timezone instance should have the name set to 'UTC'.
This is consistent with how time.tzname works, and hence provides Least
Surprise:
>>> import time
>>> time.timezone
86400
>>> time.tzname
('PST', 'PDT')
>>> import os
>>> os.environ['TZ'] = 'GMT-3'
>>> time.tzset()
>>> time.timezone
-10800
>>> time.tzname
('GMT', 'GMT')
>>> os.environ['TZ'] = 'UTC'
>>> time.tzset()
>>> time.timezone
0
>>> time.tzname
('UTC', 'UTC')
--
components: Library (Lib)
messages: 184673
nosy: lregebro
priority: normal
severity: normal
status: open
title: datetime.timezone returns the wrong tzname()
versions: Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue17486>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23397] PEP 431 implementation
Lennart Regebro added the comment: FYI me and Berker started over here: https://bitbucket.org/regebro/cpython -- ___ Python tracker <http://bugs.python.org/issue23397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
