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
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
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 v
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 on
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 make
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
verb
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
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
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 i
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 sho
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
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://
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
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
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 - mor
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],
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 c
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
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
po
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 &quo
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
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 tracke
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
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
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 opp
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
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
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
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
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
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/issue41
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
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))
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=
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
35 matches
Mail list logo
