[issue2842] Dictionary methods: inconsistency
New submission from Chester <[EMAIL PROTECTED]>: Names of dictionary methods are not consistent with Python's coding style. Please fix the following method names: 1) fixdeepcopyto be deep_copy 2) fixfromkeysto be from_keys 3) fixpopitem to be pop_item 4) fixsetdefault to be set_default Please consider of renaming the method copy to shallow_copy. If you find any other inconsistently named method, please fix it. Thank you. -- messages: 66758 nosy: aaronsw, admin, akuchling, anonymous, barry, chester, doerwalter, effbot, fdrake, gvanrossum, jhylton, lemburg, loewis, memaul, mhammond, moshez, mpmak, mwh, nobody, ping, sjoerd, skip.montanaro, tim_one, tmick, twouters, viznut severity: normal status: open title: Dictionary methods: inconsistency versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2842> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2907] ZeroDivisionError error message needs clarification
New submission from Chester <[EMAIL PROTECTED]>:
Please fix the ZeroDivisionError error message string literal to clarify
the error message:
from
if (y == 0) {
PyErr_SetString(PyExc_ZeroDivisionError,
"integer division or modulo by zero");
return DIVMOD_ERROR;
to
if (y == 0) {
PyErr_SetString(PyExc_ZeroDivisionError,
"integer division by zero or modulo by zero");
return DIVMOD_ERROR;
This code is located here:
http://svn.python.org/view/python/trunk/Objects/intobject.c?rev=62380&view=markup
------
messages: 67033
nosy: chester
severity: normal
status: open
title: ZeroDivisionError error message needs clarification
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2907>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2961] Two error messages inconsistent
New submission from Chester <[EMAIL PROTECTED]>: Hello, I would like to report that two error messages of the Python parser are not consistent. Please take a look at this: >>> a = "hello" >>> a + 1 Traceback (most recent call last): File "", line 1, in TypeError: cannot concatenate 'str' and 'int' objects >>> 1 + a Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str' When the order of the objects is changed, that should only change the order of the 'str' and 'int' words in the message. So if a+1, then TypeError: cannot concatenate 'str' and 'int' objects and if 1+a, then TypeError: cannot concatenate 'int' and 'str' objects -- messages: 67319 nosy: chester severity: normal status: open title: Two error messages inconsistent versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2961> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2961] Two error messages inconsistent
Chester <[EMAIL PROTECTED]> added the comment: For the case a + 1 I recommend: TypeError: can't concatenate 'str' and 'int' objects And for the case 1 + a I recommend: TypeError: can't concatenate 'int' and 'str' objects Consistency matters! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2961> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2962] Goodbye, 'global' statement!
New submission from Chester <[EMAIL PROTECTED]>: The 'global' statement is used to mark a variable as global. It is used in functions to allow statements in the function body to rebind global variables. Using the 'global' statement is generally considered poor style and should be avoided whenever possible. Example: count = 1 def inc(): global count count = count + 1 Since the use of the 'global' statement is frowned upon, it should be removed from Python 3.0. -- components: Interpreter Core messages: 67322 nosy: chester severity: normal status: open title: Goodbye, 'global' statement! type: feature request versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2962> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3357] A bug in the __doc__ string of the sys module
New submission from Chester <[EMAIL PROTECTED]>: This relates to Python 3.x. Do this please: import sys; print(sys.__doc__) Please fix the following line of text in that __doc__ file of the sys module: stdin -- standard input file object; used by raw_input() and input() This line of text should just be stdin -- standard input file object; used by input() because raw_input() does not exist anymore in Python 3.x. -- assignee: georg.brandl components: Documentation messages: 69668 nosy: cheDu, georg.brandl severity: normal status: open title: A bug in the __doc__ string of the sys module versions: Python 3.0, Python 3.1 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3357> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3364] An ortographical typo in Zen of Python text
New submission from Chester <[EMAIL PROTECTED]>: I hope I chose the correct component type for this issue report. Anyway, if you do import this in the Python 3.x interactive interpreter, you get the Zen of Python by Tim Peters. This text has a line which has an ortographical typo in it. Please look at this line of text from the Zen of Python: There should be one-- and preferably only one --obvious way to do it. Now this line has the typo I am talking about, and the typo is the lack of a space before the first dash (actually before the double-hyphen) and the space after the second dash (or double-hyphen). Please note that the dash punctuation mark is by ortographical rules separated from the words, so there are two spaces separating a dash from the surrounding words. By writing the dashes in the way that are in the above sentence from the Zen of Python, we don't achieve any effect as sometimes ortographical rules can be broken to create some special effect in the sentence (like in a line that uses the asteriskes to emphasize the word 'right' with writing it as *right*), but here in the above line it is clearly a normal sentence, not needing any special effect, which is also incorrect from this point of view. So please fix the above line like this: There should be one -- and preferably only one -- obvious way to do it. Consider the fact that the last sentence is written correctly and that the dash in it is separated from the surrounding words as the ortographic rules demand. So having one line of text with an incorrectly used dash and some other line with the correctly used dash, makes the whole text either inconsistent or just bad. Okay, it isn't *really* bad but it's incorrect and it needs a little fix. And it's not too much trouble to add two missing spaces in that line of text. I think that ortography is our friend in the Python world. ;) -- assignee: georg.brandl components: Documentation messages: 69688 nosy: cheDu, georg.brandl severity: normal status: open title: An ortographical typo in Zen of Python text versions: Python 3.0, Python 3.1 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3364> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3364] An ortographical typo in Zen of Python text
Chester <[EMAIL PROTECTED]> added the comment: You're a strange man, Mr. Peters, a strange man... On Tue, Jul 15, 2008 at 9:35 PM, Tim Peters <[EMAIL PROTECTED]> wrote: > > Tim Peters <[EMAIL PROTECTED]> added the comment: > > I'm afraid you missed the joke ;-) While you believe spaces are > required on both sides of an em dash, there is no consensus on this > point. For example, most (but not all) American authorities say /no/ > spaces should be used. That's the joke. In writing a line about "only > one way to do it", I used a device (em dash) for which at least two ways > to do it (with spaces, without spaces) are commonly used, neither of > which is obvious -- and deliberately picked a third way just to rub it in. > > This will never change ;-) > > -- > nosy: +tim_one > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue3364> > ___ > Added file: http://bugs.python.org/file10928/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3364> ___You're a strange man, Mr. Peters, a strange man...On Tue, Jul 15, 2008 at 9:35 PM, Tim Peters <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Tim Peters <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: I'm afraid you missed the joke ;-) While you believe spaces are required on both sides of an em dash, there is no consensus on this point. For example, most (but not all) American authorities say /no/ spaces should be used. That's the joke. In writing a line about "only one way to do it", I used a device (em dash) for which at least two ways to do it (with spaces, without spaces) are commonly used, neither of which is obvious -- and deliberately picked a third way just to rub it in. This will never change ;-) -- nosy: +tim_one ___ Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue3364"; target="_blank">http://bugs.python.org/issue3364> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2816] Quote-type recognition bug
New submission from Chester <[EMAIL PROTECTED]>: Let's make an intentional syntax error... >>> print "Testing\" SyntaxError: EOL while scanning single-quoted string Please focus on the part of the error message that states "while scanning single-quoted string". How can Python claim it scanned a single-quoted string when I fed it with a double-quoted string? That is a quote type recognition bug in Python which should be fixed. The error message in this case should, however, be: SyntaxError: EOL while scanning double-quoted string -- messages: 66607 nosy: chester severity: normal status: open title: Quote-type recognition bug versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2816> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2816] Quote-type recognition bug
Chester <[EMAIL PROTECTED]> added the comment: I have e-mailed Guido van Rossum about this. He replied: "Good find. Please file a bug on bugs.python.org." If that wasn't a bug, he wouldn't have said that, would he? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2816> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2816] Quote-type recognition bug
Changes by Chester <[EMAIL PROTECTED]>: -- versions: +Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2816> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2816] Quote-type recognition bug
Changes by Chester <[EMAIL PROTECTED]>: -- versions: +3rd party __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2816> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2816] Quote-type recognition bug
Changes by Chester <[EMAIL PROTECTED]>: -- versions: +Python 3.0 -Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2816> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2817] Make Python create a tuple with one element in a clean way
New submission from Chester <[EMAIL PROTECTED]>: To create a tuple with one element, you need to do this: >>> my_tuple = (1,)# Note the trailing comma after the value 1 >>> type(my_tuple) But if you do this >>> my_tuple = (1) >>> type(my_tuple) you don't get a tuple. I thought that just putting a value inside ( ) would make a tuple. Apparently that is not the case. I hate ugly code so it would be clean if Python would convert anything put into ( ) to be a tuple, even if just one value was put in (without having to use that ugly looking comma with no value after it). -- messages: 66626 nosy: chester severity: normal status: open title: Make Python create a tuple with one element in a clean way type: feature request versions: 3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2817> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2816] Quote-type recognition bug
Chester <[EMAIL PROTECTED]> added the comment: It would be better to say "End of line while scanning string (, line 1)" and "End of f... while scanning multi-line string (, line 1)" These messages really need to be clear, so putting EOF for example (which I really don't know what it stands for) is really mind-bending. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2816> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2817] Make Python create a tuple with one element in a clean way
Chester <[EMAIL PROTECTED]> added the comment: Martin I see the point now. I appologize for not having the clear head of seeing the possible damage that my feature request would make. I take my request back. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2817> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2822] Quote-type recognition bug [badly fixed last time]
New submission from Chester <[EMAIL PROTECTED]>: I have a suggestion that would make the http://svn.python.org/view?rev=63068&view=rev look ever more clear. It would be better to have this kind of error messages: expect = "End of line while scanning string (, line 1)" and expect "End of f... while scanning multi-line string (, line 1)" These messages really need to be clear, so putting EOF for example (which I really don't know what it stands for) is really mind-bending. But if changing EOL and EOF to their actual meaning would cause some problems, then this look nice as well: expect = "EOL while scanning string (, line 1)" and expect "EOF while scanning multi-line string (, line 1)" The first two proposals look more readable because I think that many people don't know what EOF stands for (they can guess for EOL though, but EOF is just mind-bending and wild guessing). I Googled and found no answer, so I actually don't know what that error message is saying to me. Also, it would be good, however, to remove the 'triple-quoted string literal' and name that simply as 'multi-line string'. Simple is better than complex. :) Mister Rossum, please give a go on that. I kindly ask you to choose from the above two options. Your proposal on that was made, yes... but I find the 'multi-line string' even better than 'triple-quoted string literal'. I would love to provide a patch but I don't know how it's made. -- messages: 66652 nosy: chester, gvanrossum severity: normal status: open title: Quote-type recognition bug [badly fixed last time] versions: 3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2822> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2825] Quote-type recognition bug [got a patch!]
New submission from Chester <[EMAIL PROTECTED]>: This is a patch I made to make this messages clear now. I hope you like it. -- files: test_eof.patch keywords: patch messages: 4 nosy: chester severity: normal status: open title: Quote-type recognition bug [got a patch!] Added file: http://bugs.python.org/file10291/test_eof.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2825> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2825] Quote-type recognition bug [got a patch!]
Changes by Chester <[EMAIL PROTECTED]>: -- nosy: +gvanrossum versions: +3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2825> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2826] safe_substitute() and substitute()
New submission from Chester <[EMAIL PROTECTED]>: Please consider of removing safe_substitute() method and make the current substitute() method act like safe_substitute() method but being named substitute(). -- messages: 66675 nosy: chester, gvanrossum severity: normal status: open title: safe_substitute() and substitute() versions: 3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2826> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20863] IDLE not opening
New submission from Chester Burns: I installed python 3.3.3 and it was working fine for the moment, however the next day when I tried to open it, the idle app showed on the dock for a second and straight away quit. I am using a macbook pro on osx version 10.9.1 -- messages: 212863 nosy: chester.burns priority: normal severity: normal status: open title: IDLE not opening versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue20863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20863] IDLE not opening
Chester Burns added the comment:
I tried that and it came up with this:
Traceback (most recent call last):
File "/usr/local/bin/idle3.3", line 5, in
main()
File
"/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/idlelib/PyShell.py",
line 1572, in main
shell.interp.runcommand(''.join(("print('", tkversionwarning, "')")))
AttributeError: 'NoneType' object has no attribute 'interp'
I also tried typing 'open /usr/local/bin/idle3.3' and it returned this:
No application knows how to open /usr/local/bin/idle3.3.
--
___
Python tracker
<http://bugs.python.org/issue20863>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
