[issue42886] math.log and math.log10 domain error on very large Fractions
Camion added the comment: @mark.dickinson, I fell on this problem in the reached precision evaluation, of a multiprecision algorithm designed to compute decimals of PI (using "John Machin like" formulas). The fact is that fractions module is really nice to implement this kind of multiprecision algorithm and math.log10 on each subsequent term of the series gives you an immediate evaluation of the current reached precision. I agree that the solution I used work pretty well, but it makes me sad because it's far from beautifull. I think one should consider that there are two cases with different objectives : floats and the likes which target speed, and those multiprecision types which target - well... precision. I wonder if the solution would not be to implement those functions in the fractions and decimal libraries (just calling log on integer for numerator and denominator). -- ___ Python tracker <https://bugs.python.org/issue42886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42886] math.log and math.log10 domain error on very large Fractions
Camion added the comment: A generic solution might be to consider all number as fractions (which they are) (floats have denominators being 2^n, decimals have denominators being 10^n, integers have denominators being 1, and fractions have denominators being integers... but this would be a heavy change. -- ___ Python tracker <https://bugs.python.org/issue42886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42886] math.log and math.log10 domain error on very large Fractions
Camion added the comment: math.log10 works perfectly on integers which are too large to be converted to floats. I see no reason why it couldn't work as well with fractions. >>> math.log10(math.factorial(1)) 35659.45427452078 >>> math.log10(math.factorial(100)) 5565708.917186718 >>> math.log10(float(math.factorial(1))) Traceback (most recent call last): File "", line 1, in math.log10(float(math.factorial(1))) OverflowError: int too large to convert to float -- ___ Python tracker <https://bugs.python.org/issue42886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42886] math.log and math.log10 domain error on very large Fractions
New submission from Camion : Python is able to computer the logarithms of very large integers and fractions (by using log(num)-log(denom)), However the fractions.Fraction class fails to do it and raises a math domain error exception. >>> import math, fractions >>> f=fractions.Fraction(math.factorial(1), math.factorial(2)+1) >>> math.log(f.numerator)-math.log(f.denominator) -95966.69390038431 >>> math.log(f) Traceback (most recent call last): File "", line 1, in math.log(f) ValueError: math domain error >>> math.log10(f.numerator)-math.log10(f.denominator) -41677.80560743537 >>> math.log10(f) Traceback (most recent call last): File "", line 1, in math.log10(f) ValueError: math domain error -- components: Library (Lib) messages: 384783 nosy: Camion priority: normal severity: normal status: open title: math.log and math.log10 domain error on very large Fractions versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue42886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41637] Calling with an infinite number of parameters is not detected
Camion added the comment: I understand all that. But the problem is that it should crash the program and not the interpreter. -- ___ Python tracker <https://bugs.python.org/issue41637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41637] Calling with an infinite number of parameters is not detected
Camion added the comment: Well, I know an infinite loop is not necessarily wrong, especially in a generator. and I also know how to avoid this problem. My problem is not there. It's just that I believe it should possibly crash the program and not the interpreter. I even wonder if being able to cause an interpreter crash couldn't become a security hole in some cases.probably the basic solution would be to forward an exception to the program if the interpreter running it gets an allocation error. About core dump or crash report, it didn't generate one but I think I should install a few things on the computer to get it. Le dimanche 30 août 2020 à 02:02:01 UTC+2, Terry J. Reedy a écrit : Terry J. Reedy added the comment: On Windows, I get an indefinite hang rather than an overt crash with a crash box. I believe that there was some swapping out to disk. I got the same with list(itertools.count()). If you got a core dump or crash report, you might upload it. There is infinite looping in the argument collection but no infinite recursion (calling) here. The latter is detected pretty quickly because of sys.recursion limit. Infinite loops by themselves are not necessarily wrong. This typing box is run by an infinite loop. Change your 'use' to def use(iter): for i in iter: print(i) and there would be no problem. So I disagree with 'should have been detected'. I am only leaving this open in case you got an overt crash for this particular loop. Those we try to fix. -- nosy: +terry.reedy title: Calling a function with an infinite number of parameters is not detected and crash the interpreter instead of causing an exception -> Calling with an infinite number of parameters is not detected versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue41637> ___ -- ___ Python tracker <https://bugs.python.org/issue41637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41637] Calling a function with an infinite number of parameters is not detected and crash the interpreter instead of causing an exception
New submission from Camion : The following code will obviously cause a memory leak, but this will not be detected and crash the interpreter: def inf(): while True: yield 0 def use(*parm): for i in parm: print(i) and then use(*inf()) or print(*int()) The reason of this test is that I wanted to check if ever python would be able to make lazy evaluation in parameter passing (It would be nice if it was but it is not the case). However, at least, I think this error should have been detected as well as an infinite recursion is, because it even has been able to crash and reboot a not so old (18) version of linux Mint. -- components: Interpreter Core messages: 375904 nosy: Camion priority: normal severity: normal status: open title: Calling a function with an infinite number of parameters is not detected and crash the interpreter instead of causing an exception type: crash versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36491] sum function's start optional parameter documented in help but not implemented
New submission from Camion : >>> help(sum) Help on built-in function sum in module builtins: sum(iterable, start=0, /) Return the sum of a 'start' value (default: 0) plus an iterable of numbers When the iterable is empty, return the start value. This function is intended specifically for use with numeric values and may reject non-numeric types. >>> sum([1, 2, 3], start=3) Traceback (most recent call last): File "", line 1, in sum([1, 2, 3], start=3) TypeError: sum() takes no keyword arguments By the way, it is very annoying that the start value is not available, because it hampers the possibility to use sum with things like vectors. -- components: Interpreter Core messages: 339245 nosy: Camion priority: normal severity: normal status: open title: sum function's start optional parameter documented in help but not implemented type: behavior versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue36491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35174] Calling for super().__str__ seems to call self.__repr__ in list subclass
Camion added the comment: @Serhiy Storchaka, this doesn't seem logical, is certainly counter intuitive, and I fear there is a lack of expressivity. - first of all, this is NOT about having str and repr returning the same at all, but about building the same _kind of_ structure representations for str and repr, but with str of sub elements in __str__, and with repr of sub elements in __repr__. It is not logical at all and completely counter intuitive, if you explicitely ask str of the superclass, to get repr of the subclass. Getting repr of the superclass would be logical, but not repr of the subclass. Now, it might happen that I missed another way to write what I tried (casting the object to it's super class with super(), to avoid explicitly naming the superclass) but if there is not, we then have something lacking in terms of expressivity. -- resolution: not a bug -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue35174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35174] Calling for super().__str__ seems to call self.__repr__ in list subclass
New submission from Camion :
I don't know if this is by design (for what reason ?) or if it is a bug, but I
have noticed this quite counter-intuitive behaviour :
Doing that, it seems that the logical way to make the __repr__ and __str__
methods, would be to override respectively the parent __repr__ and _str__
methods, and calling them from the inherited versions, but for some reason, it
seems that calling super().__str__ leads to call self.__repr__.
I have written the following piece of python-3 code in which I subclass the
list class in order to make a class which supports storing names and unnamed
fields the same way you can have variable named and unnamed parameters in a
function call :
class struct(list):
def __init__(self, *args, **kwargs):
super().__init__(args)
for key, value in kwargs.items():
setattr(self, key, value)
def __repr__(self):
s = super().__repr__()[1:-1]
for key, val in self.__dict__.items():
s += ', '+key+'='+repr(val)
return 'struct('+s+')'
def __str__(self):
s = super().__str__()[1:-1]
print('Debug : super().__str__() = "'+super().__str__()+'"')
print('Debug : list(self).__str__() = "'+list(self).__str__()+'"')
print('Debug : s = "'+s+'"')
for key, val in self.__dict__.items():
s += ', '+key+'='+str(val)
return '{'+s+'}'
a = struct(1, 2, 3, a="akeja", b=21, c=True, d="lkj")
print('repr(a)="'+repr(a)+'"\n')
print('str(a)="'+str(a)+'"\n')
Executing this code in idle-3.5.2 will yield the following result :
>>>
RESTART: struct.py
repr(a)="struct(1, 2, 3, b=21, d='lkj', a='akeja', c=True)"
Debug : super().__str__() = "struct(1, 2, 3, b=21, d='lkj', a='akeja',
c=True)"
Debug : list(self).__str__() = "[1, 2, 3]"
Debug : s = "truct(1, 2, 3, b=21, d='lkj', a='akeja', c=True"
str(a)="{truct(1, 2, 3, b=21, d='lkj', a='akeja', c=True, b=21, d=lkj,
a=akeja, c=True}"
>>>
As one can see in the second debug lines, the call to `super().__str__()` which
I expect to return the result from a call to the `__str__` function from my
super class (`list`), will in fact return something which looks very much like
the expected return from `self.__repr__()`
It seems that `super().__str__()` calls `self.__repr__()` instead of
`list(self).__str__()` or even `super().__repr__()`.
--
components: Interpreter Core
messages: 329331
nosy: Camion
priority: normal
severity: normal
status: open
title: Calling for super().__str__ seems to call self.__repr__ in list subclass
type: behavior
versions: Python 3.5
___
Python tracker
<https://bugs.python.org/issue35174>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: I don't think there anything in the definition of "lexical scoping", which forbids to have a way to access globals from some place. Lexical scoping just means that scoping is defined in regards of the source code, by opposition dynamic scoping, which defines the scope in regard with execution. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: Stefan, You wrote : « It certainly prevents Python scopes from being called "lexical scopes". » I don't understand why... Could you explain ? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: What I mean is that we need to clarify (by giving examples ?) what make the scope for the new binding "not be unambiguously decidable", because, for an example : My example is totaly unambiguously decidable for an interpreter. It's for a human reader that it might lead to mistakes. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: Ivan, I believe, this sentence : "(the scope in which a new binding should be created cannot be determined unambiguously)" in https://docs.python.org/fr/3/reference/simple_stmts.html#nonlocal, is the one which should be clarified first, and then this would probably give the bases to improve the error message. It raises the following concerns : 1/ Is it me or there is a nasty double negation in this sentence which make it tell the contrary of what it should ? 2/ What are the conditions which would make such an ambiguity appear ? I wonder what the persons who wrote this had on their mind when they wrote it, but in regard with code reading/reviewing, my original example might be an example of such an ambiguous situation. Now the question is: are there others and what would they look like ? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: My interrogation is about the fact that this doesn't seem to have been a collective decision and I'm not even sure it WAS anyone decision : it might as well have been an unintentional consequence of an implementation choice. So, in the "weakest" configuration, avoiding the implementation challenge for "design flaw" would require a language specification to at least mention that in this case, the behavior in undefined. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: David and Stefan, you're both missing my main point which is the fact that the presence of the global declaration in the parent (g) **blocks the access to the grand parent context**, which would be accessible without this global declaration (of another variable since that one is global. It just happen to have the same name) in g; and the stackoverflow post also ignores this question. I do not disagree that this might be a desired feature (we might wish to reject this because of the potential confusion caused by this kind of name collision situation), but without any clear specification on it (since this point doesn't seem to have been discussed in the (or any?) PEP), it could always be challenged as a design flaw. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: Ok then. Thank you :-) It also seemed strange that there were so many messages about int ;-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: Even in the code !?? I may have missed something, but I based my question on what I read in the pull request... -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: thank You Serhiy for your C implementation. About this question of the dilemma around the meaning of "non iterable int" why not simply put the "non iterable" between parenthesis to avoid making it too verbose ? "cannot unpack (non-iterable) int object" or "cannot unpack int object (not iterable) However, I wonder why nearly all the changes I've seen, seem to be about int ? This situation might arise with any non-iterable type (I got it first with Fraction). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: Oops, in my previous post please read : "but does it makes sense to have the presence of "global a" in g, block all possibility for h, to access it's grand parent's a ?" instead of "but is makes sense to [...] grand parent's a." -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: Well, David, I'm convinced this behavior is "logical" and is not some "logic" flaw. My question is more about the fact that it is desirable and was intentionally designed that way,or if on the contrary no one thought it might happen that way and it's not what was wished. I understand that it might be a problem to link to a global (global a), a variable (h's a) which was declared in a non-global way, but is makes sense to have the presence of "global a" in g, block all possibility for h, to access it's grand parent's a. In all case, I believe this should at lease be clearly documented in (or in relation with) PEP 3104 to make sure it has been decided that way, or else it will look like a design hole. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
Camion <camion_spam-pyb...@yahoo.com> added the comment: I forgot to mention, that I wonder if the interpreter shouldn't instead, - either consider that since global a is used is g, it should be considered as also local to g from h point of view, - or if h should be able to access f's version of a. - (or if on the contrary, this ambiguity is the very reason to cause a syntax error, -- but in this case, one might need to change the text of the error message to make it more accurate. --) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ?
New submission from Camion <camion_spam-pyb...@yahoo.com>:
Hello,
"PEP 3104 -- Access to Names in Outer Scopes" introduced the keywords "global"
and "nonlocal". but didn't make clear (to me) if this behaviour is a bug, an
intentional feature, or a design hole which might be considered good or bad.
I have observed that when the nonlocal keyword gives acces to a grand parent
function's variable, the presence in the parent function, of an access to a
global variable with the same name, blocks it with a syntax error (SyntaxError:
no binding for nonlocal 'a' found).
a = "a : global"
def f():
a = "a : local to f"
def g():
#global a # uncommenting this line causes a syntax error.
#a = a+", modified in g"
def h():
nonlocal a
a = a+", modified in h"
h()
print (f"in g : a = '{a}'")
g()
print (f"in f : a = '{a}'")
f()
print (f"glogal : a = '{a}'")
--
components: Interpreter Core
messages: 308537
nosy: Camion
priority: normal
severity: normal
status: open
title: global / nonlocal interference : is this a bug, a feature or a design
hole ?
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32361>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: Jerry, I've been troubleshooting thing for 30 years and I'm quite experienced at it, and in the end I was perfectly able to manage this problem and solve this problem by myself. My point is not about my own difficulty to solve this problem, but about the fact that an information was lacking clarity in a language which claims that things must be told. You mention the fact that Steven suggested playing playing around with simplified code, but it's not what Steven suggested. Steven suggested to make the example simpler, and I replied him that this example was not chosen to describe the programming situation but illustrate the troubleshooting situation and provide a good way to show how a real situation might be problematic to analyse with this message - and Steven confirmed that he was also put out on a wrong track by this message. For sure, when you are an experienced programmer, you will develop a different way to understand this. My point is that it seems to go in contradiction with "Python's Zen". You suggest that I should have split the packing and the unpacking on two separate lines. Ok, but this is an easy suggestion to make _when you already know the cause of the problem_. Each language has it's programming culture and; Ok, I'm new here but I haven't seen any recommendation going in that direction. On the contrary all the sample code and course I have seen on that topic encourage young programmer not to use this practice - and I believe it would be simpler to find a way to adapt the error message to make things clear that such an error can also arise for unpacking reasons (whatever the way you word it), than to change the programming/training culture around python. I have been made multiple propositions to re-word this message, and Steven also made some. My last proposition was motivated by the idea of keeping the message short. Some other were longer. One might also write : "not iterable (this problem may sometimes arise from unpacking)" or something else. The point is that in many situation, the problem comes from a mismatching between the number of values packed and the number of destination positions for unpacking; and in this case, you have a ValueError message stating clearly what happens. Only in this case, when the fact that you had only one value and didn't see it, makes that you no longer have an iterable type - do you get a TypeError. And Ok, I agree with Serhiy that the type of exception is correct, but I believe that the whole situation is misleading and should be corrected. (I apologize for my long sentences : My mother tongue is french and it's not always easy for me to to make them short like you do in English XD ) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: Woops, my mistake... I fumbled this one : the file was empty -- keywords: +patch Added file: https://bugs.python.org/file47330/issue-32259-iterable-unpackable.patch ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: Well I submitted a patch, but I don't see it anywhere on this page.. Is this normal ? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: @Raymond: I know that you have no obligation to make changes just because I'm demanding them and that's why I'm just trying to convince people of the validity of my observations, here. I apologize if my tone may seem "insistent", but please take in account than English is not my mother tongue. I agree with the fact that part of learning a language is learning to reason from error message to root cause but I cannot ignore that Python's Zen asks for explicitness, and Steven agreed with that this situation was tricky to interpret. It would be sly to suggest I'm be looking for vindication for one of my own programming errors. I'm experienced enough in trouble-shooting to have solved it by myself. It's just that I do not believe normal that this situation took me so much time and energy to solve from the error message **in regard with other similar situations**. @David : What other contexts are you talking about ? Instead of looking in the documentation which also talks about e.g.:unpacking archive files, You should probably grep the source code for strings containing the word unpack and it will show you that the word unpack is used in contexts fully related with the error in my example. (SEARCH='".*unpack.*"'; find -name '*.c' -print0 | xargs -0 grep -li "$SEARCH" | while read F; do echo "$F" | sed 'p;s/./-/g'; grep -niC 5 "$SEARCH" "$F"; done) | less I don't know about what would be the right error message, but since I experimented on in and Serhiy asked for it, I made a sample patch on version 3.6.3 which contains all the change which I believe, would be required. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: @Serhiy : I asked you to explain by what mean you supported the affirmation that our feeling (that the current message can be misleading in the specific situation) is wrong, but you didn't give us any element to understand your position. Steven and I did it: I gave you a sample code showing how and why a situation could be misinterpreted in regard of the current message, and Steven explained that as an experience python programmer, he experienced the same misunderstanding (I'm also an experienced programmer: started in the eighties, I'm new in Python only). May be, if you gave us some sound argument element, we could also better understand the reason why you affirm that our feeling is wrong. Because in the current situation, you only declared your own feeling, but didn't give it any support, and all we can conclude is that you are a very experienced python programmer who can understand what was beyond the text of the message, but it seems in contradiction with the principle of making things clear. @Raymond : I do not understand how you make the link between both your affirmations. The initial problem is related with the fact that in some situation, the error message lead to think that there is a problem with the loop/generator/iterator, where the problem is in reality with a simple type which cannot be unpacked or iterated. Let's assume that the interpreter could never make the difference. In what way, does it support the fact that the message shouldn't in any way, hint the programmer on the fact that the problem is not with the generator/iterator/loop, but with the returned type ? @Steven (& everybody), How about : "[TYPE] object is not iterable/unpackable" ? About patching the sources in c, the message "object is not iterable" appears in four places in the version 3.6.3 : in ./Objects/object.c:1023, twice in ./Objects/typeobject.c (lines 6329 & 6344), and in ./Objects/abstract.c:3135. I have patched them to make them recognizable from one another, and it appear that all observed messages have been generated from abstract.c:3135 (in 3.6.3) and not from the other lines. This poses problem, because not even the regression test show a case where those other 3 parts of the code are used, and I haven't figured out (yet?) what condition makes them occur. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: Serhiy, I think I got a better understanding of what is happening. It is well described by the following example : >>> a, b = 1, Traceback (most recent call last): File "<pyshell#40>", line 1, in a, b = 1, ValueError: need more than 1 value to unpack >>> a, b = 1 Traceback (most recent call last): File "<pyshell#41>", line 1, in a, b = 1 TypeError: 'int' object is not iterable Again, the message might be correct, but in this case, the combination between the message and the ambiguous syntax, makes it lack from explicitness. Understanding that, I suggest to simply add "(expected 'tuple')" at the end of the message. ex : TypeError: 'int' object is not iterable (expected 'tuple') -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: By the way, I guess if the problem arises like that, it's because it might be hard to distinguish both situations at the interpreter level, but if it was possible, it would be the best solution to have a different error message (even if I understand we should be very careful with the idea of changing the exception type, even in this case). I mean : Eric shown an equivalent error, but both are only equivalent at the present discrimination level of the interpreter & language grammar. I understand that distinguishing both those semantically different situation might be opening the Pandora box and it might be a bad idea... or not. The point is that, if ever both those situations were in some way distinguishable, then... well... we certainly have no idea of how much code confronted with this specific situation AND treated it with exception handling, BUT, we might make the assumption that a frequent confrontation with this case would then already have been raised before, and consequently, it might be relevant, at least to keep it in mind for a future evolution (4.0) of the language. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: I wrote it like that on purpose, Steven : My goal was not to show the message itself which (I believe) was sufficiently described in the explanation, but to show how hard it might be to understand the mistake in regard with the error message, even here, with a real life but not outrageously complicated code. :-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: I'm not talking about changing the type of the exception, Serhiy. but only to make the text message more explicit by adding a lead to a secondary possible cause. I do not understand how this addition would be misleading - more than the case I presented ? (Did you check my example ?) I agree that this message might possibly make my mistake obvious to an senior _python_ programmer, but doesn't the constraint of being _experienced in python_, not go in contradiction with the mantra "Explicit is better than implicit" ? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
Camion <camion_spam-pyb...@yahoo.com> added the comment: Ok, but the other explanation is valid as well. That's why I suggest to modify the error message like this : TypeError: '[TYPE]' object is not iterable - OR - ValueError: not enough values to unpack (expected [N], got 1) -- status: closed -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected
New submission from Camion <camion_spam-pyb...@yahoo.com>: I'm new with Python and I've been blocked for day on a "TypeError: 'Fraction' object is not iterable" error message, while the problem turned out to be completely different. I don't even know to what programming case this message would have been the right interpretation, but in this situation, it was completely wrong and I believe it can cause much loss of time for inexperienced python programmer (at least, I believe it should document alternative causes) Here is a sample code to show how misleading it can be (It's a program to compute pi with fractions) from fractions import Fraction def order(x): r, old_r, n, old_n = 2, 1, 1, 0 while (x>=r): r, old_r, n, old_n = r*r, r, 2*n, n return order(x >> old_n) + old_n if old_n > 0 else 0 def terms(m, n, i): return Fraction(4 * m, n**(2*i+1) * (2*i+1)) def terms_generator(exp_prec): ws = [ [terms(parm[1], parm[2], 0), 0] + list(parm) for parm in ((1, 44, 57), (1, 7, 239), (-1, 12, 682), (1, 24, 12943))] digits = 0 while digits <https://bugs.python.org/issue32259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32140] Probable bug in all python3 / idle3 debugger
New submission from Camion <camion_spam-pyb...@yahoo.com>:
Hello all,
I have been investigating a bug with a generator, which crashed, reporting that
"TypeError: 'Fraction' object is not iterable".
Then I have tried to find it with the debugger and/or to reproduce it with a
simpler program, but, I have not managed to reproduce the bug in my test
program and I have been stopped by the fact that the debugger crashes with
another error:
I have reproduced it on version 3.4.2 ans 3.6.3, BUT NOT on version 2.7.9. So I
suspect it has been introduced with version 3.
Here is how to reproduce it :
1/ Open Idle
2/ create and save this text program (or open if you already did - or don't do
anything if it's already opened X-D)
from fractions import Fraction
U=Fraction(1)
def test(x):
for i in range(1, x.denominator):
x*=x
yield i, i*x
for m, n in test(U*3/5):
print (m, n)
3/ Run/check module (F5) in Idle editors window : it works perfectly
4/ start the debugger from Idle menus
5/ activate the "source" checkbox
6/ Run/check module (F5) in Idle editors window
7/ Click 3 times on [over] to get to the "for m, n in test(U*3/5):" line
8/ Click 6 times on [step], to get to the line 116 ("for m, n in test(U*3/5):")
in the fractions.py files
9/ Click a seventh time on [step] and your program will crash with the folowing
error (here with 3.6.3)
Traceback (most recent call last):
File "/raid/ArcFolder/Mes documents/Mes Textes/Mes
programmes/Machin/Test_itérateur_et_fractions.py", line 12, in
for m, n in test(U*3/5):
File "/usr/local/lib/python3.6/fractions.py", line 376, in forward
return monomorphic_operator(a, b)
File "/usr/local/lib/python3.6/fractions.py", line 419, in _mul
return Fraction(a.numerator * b.numerator, a.denominator * b.denominator)
File "/usr/local/lib/python3.6/fractions.py", line 117, in __new__
if denominator is None:
File "/usr/local/lib/python3.6/fractions.py", line 117, in __new__
if denominator is None:
File "/usr/local/lib/python3.6/bdb.py", line 48, in trace_dispatch
return self.dispatch_line(frame)
File "/usr/local/lib/python3.6/bdb.py", line 66, in dispatch_line
self.user_line(frame)
File "/usr/local/lib/python3.6/idlelib/debugger.py", line 24, in user_line
self.gui.interaction(message, frame)
AttributeError: _numerator5/ Run/check module (F5) in Idle editors window
I have observed once 3.4.2 that the same operation without activating the
source checkbox, lead to a full idle freeze, but I have not been able to
reproduce it.
--
assignee: terry.reedy
components: IDLE
messages: 307001
nosy: Camion, terry.reedy
priority: normal
severity: normal
status: open
title: Probable bug in all python3 / idle3 debugger
type: crash
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32140>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
