what is new with int conversion in Python 3
I am doing a passage in a book that was written for python 2 i am writing
everything in 3.
This is the author Ivan Idris code to show time difference between python and
numpy arrays. The only edit I made was to fix the print statements.
#!/usr/bin/env/python
import sys
from datetime import datetime
import numpy as np
"""
This program demonstrates vector addition the Python way.
Run from the command line as follows
python vectorsum.py n
where n is an integer that specifies the size of the vectors.
The first vector to be added contains the squares of 0 up to n.
The second vector contains the cubes of 0 up to n.
The program prints the last 2 elements of the sum and the elapsed time.
"""
def numpysum(n):
a = np.arange(n) ** 2
b = np.arange(n) ** 3
c = a + b
return c
def pythonsum(n):
a = range(n)
b = range(n)
c = []
for i in range(len(a)):
a[i] = i ** 2
b[i] = i ** 3
c.append(a[i] + b[i])
return c
size = int(sys.argv[1])
start = datetime.now()
c = pythonsum(size)
delta = datetime.now() - start
print("The last 2 elements of the sum", c[-2:])
print("PythonSum elapsed time in microseconds", delta.microseconds)
start = datetime.now()
c = numpysum(size)
delta = datetime.now() - start
print("The last 2 elements of the sum", c[-2:])
print("NumPySum elapsed time in microseconds", delta.microseconds)
However when I run this I get a valuerror. So either something has changed with
int or datetime I cannot google a consistent answer.
---
ValueErrorTraceback (most recent call last)
in ()
37return c
38
---> 39 size = int(sys.argv[1])
40
41 start = datetime.now()
ValueError: invalid literal for int() with base 10: '-f'
Had this before?
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
Re: what is new with int conversion in Python 3
On Sun, May 22, 2016 at 5:26 PM, Sayth Renshaw wrote: > However when I run this I get a valuerror. So either something has changed > with int or datetime I cannot google a consistent answer. > > > --- > ValueErrorTraceback (most recent call last) > in () > 37return c > 38 > ---> 39 size = int(sys.argv[1]) > 40 > 41 start = datetime.now() > > ValueError: invalid literal for int() with base 10: '-f' > > Had this before? Look carefully at the error, and the line that it's coming up on. Firstly, you can rule out datetime, as nothing has been done with datetime except import it. Secondly, the invalid literal doesn't look like a decimal number at all; in fact, it looks to me like a flag of some sort. Try adding this above the failing line: print(sys.argv) And also, try running this at the terminal: $ file /usr/bin/env/python How are you invoking Python? The shebang looks wrong; perhaps it should be "/usr/bin/env python" (note the space where you have an additional slash), but perhaps it's not even being significant here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: what is new with int conversion in Python 3
On Sun, 22 May 2016 05:26 pm, Sayth Renshaw wrote: > I am doing a passage in a book that was written for python 2 i am writing > everything in 3. [...] > However when I run this I get a valuerror. So either something has changed > with int or datetime I cannot google a consistent answer. Neither. It will help if you read the error message: > ValueError: invalid literal for int() with base 10: '-f' You're passing -f as the first argument to the script, instead of an integer. Look at the command you are typing. My guess is that you are typing something like python vectorsum.py -f 27 instead of python vectorsum.py 27 -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: what is new with int conversion in Python 3
Sayth Renshaw wrote: Read carefully: > Run from the command line as follows > > python vectorsum.py n > > where n is an integer that specifies the size of the vectors. So to run the script with Python 3 you could do $ python3 vectorsum.py 42 in the shell. This implicitly sets sys.argv[1] to "42" so that the conversion size = int(sys.argv[1]) can succeed. This conversion failed because as the traceback indicates > ValueErrorTraceback (most recent call last) > in () > 37return c > 38 > ---> 39 size = int(sys.argv[1]) > 40 > 41 start = datetime.now() > > ValueError: invalid literal for int() with base 10: '-f' > sys.argv[1] is "-f" which is not a valid (base-10) integer. This value probably got into ipython3 because you invoked it with something like $ ipython3 console -f foo Python 3.4.3 (default, Oct 14 2015, 20:28:29) Type "copyright", "credits" or "license" for more information. IPython 1.2.1 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: import vectorsum --- ValueErrorTraceback (most recent call last) in () > 1 import vectorsum /home/petto/vectorsum.py in () 37return c 38 ---> 39 size = int(sys.argv[1]) 40 41 start = datetime.now() ValueError: invalid literal for int() with base 10: '-f' In [2]: ! python3 vectorsum.py 42 The last 2 elements of the sum [65600, 70602] PythonSum elapsed time in microseconds 106 The last 2 elements of the sum [65600 70602] NumPySum elapsed time in microseconds 121 By the way, I had to fix another problem to make the "In [2]:" invocation work. Let's see if you can do that yourself. -- https://mail.python.org/mailman/listinfo/python-list
Re: Image loading problem
Random832 wrote: > On Sat, May 21, 2016, at 12:54, Peter Otten wrote: >> It's not your fault, there's an odd quirk in the library: you have to >> keep a reference of the PhotoImage instance around to prevent the >> image from being garbage-collected. > > Just out of curiosity, why is this a "quirk" and not a bug? I agree that this is at least a usability bug, but I think someone with a clue (Fredrik Lundh?) wrote it that way intentionally. > Why isn't the reference held by the Label? I can only speculate: to avoid a tcl/python reference cycle? You might file a bug report and see what comes of it. -- https://mail.python.org/mailman/listinfo/python-list
Re: what is new with int conversion in Python 3
On Sunday, 22 May 2016 17:26:51 UTC+10, Sayth Renshaw wrote:
> I am doing a passage in a book that was written for python 2 i am writing
> everything in 3.
>
> This is the author Ivan Idris code to show time difference between python and
> numpy arrays. The only edit I made was to fix the print statements.
>
> #!/usr/bin/env/python
>
> import sys
> from datetime import datetime
> import numpy as np
>
> """
> This program demonstrates vector addition the Python way.
> Run from the command line as follows
>
> python vectorsum.py n
>
> where n is an integer that specifies the size of the vectors.
>
> The first vector to be added contains the squares of 0 up to n.
> The second vector contains the cubes of 0 up to n.
> The program prints the last 2 elements of the sum and the elapsed time.
> """
>
> def numpysum(n):
>a = np.arange(n) ** 2
>b = np.arange(n) ** 3
>c = a + b
>
>return c
>
> def pythonsum(n):
>a = range(n)
>b = range(n)
>c = []
>
>for i in range(len(a)):
>a[i] = i ** 2
>b[i] = i ** 3
>c.append(a[i] + b[i])
>
>return c
>
> size = int(sys.argv[1])
>
> start = datetime.now()
> c = pythonsum(size)
> delta = datetime.now() - start
> print("The last 2 elements of the sum", c[-2:])
> print("PythonSum elapsed time in microseconds", delta.microseconds)
>
> start = datetime.now()
> c = numpysum(size)
> delta = datetime.now() - start
> print("The last 2 elements of the sum", c[-2:])
> print("NumPySum elapsed time in microseconds", delta.microseconds)
>
>
> However when I run this I get a valuerror. So either something has changed
> with int or datetime I cannot google a consistent answer.
>
>
> ---
> ValueErrorTraceback (most recent call last)
> in ()
> 37return c
> 38
> ---> 39 size = int(sys.argv[1])
> 40
> 41 start = datetime.now()
>
> ValueError: invalid literal for int() with base 10: '-f'
>
> Had this before?
>
> Sayth
Thank you all, I was way wrong. I was invoking it from within ipython notebook
which I don't usually use.
Thanks'
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-21, Chris Angelico wrote:
> On Sat, May 21, 2016 at 10:35 AM, Jon Ribbens
> wrote:
>> To be fair, I'm very sympathetic to that argument. I think programming
>> languages should never magically produce floats out of nowhere unless
>> the programmer has explicitly done "import float" or "float('3.23')"
>> or somesuch. They're misunderstood so often that any convenience
>> they provide is outweighed by the danger they bring.
>>
>> "(1/10) * (1/10) * 10 != (1/10)" anyone? I was distinctly unhappy with
>> the Python 3 "2/3 ~= 0." thing and regard it as a very retrograde
>> change.
>
> The trouble is, what SHOULD 2/3 return?
>
> * An integer? Makes a lot of sense to a C programmer. Not so much to
> someone who is expecting a nonzero value. This isn't terrible (hey,
> Python 2 managed with it no problem), but will definitely confuse a
> number of people.
Yes, it should return an integer - and not because I think Python
should behave like C on principle, but because:
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
and floats are complicated.
> * A float? That's what we currently have. Not perfect, but it's going
> to confuse less people than 0 will.
That's a trap for those people though - it lulls them into thinking
that they understand what's going on, when in fact they don't,
because they don't understand floats, because almost nobody
understands floats. So they don't understand their program, and
- even worse - they don't know that they don't understand it.
Programming languages should do what they are told, and very little
more. They should not wander off on surprising jaunts of their own
invention out of the control of the programmer. It should be possible
to know and understand the language, or at least the subset of it
that you are likely to need for your everyday purposes. Floats are
generally not understood, so they shouldn't be suddenly turning up
un-called for.
Python generally sticks to this idea very well, which is one of the
things that I think make it an excellent programming language, so it
is a shame that in the Python 2 to Python 3 change when mistakes were
being rectified, a new one was introduced.
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Jon Ribbens : > On 2016-05-21, Chris Angelico wrote: >> The trouble is, what SHOULD 2/3 return? > > [...] > > Yes, it should return an integer - and not because I think Python > should behave like C on principle, but because: > > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > > and floats are complicated. Scheme has the best of both worlds: scheme@(guile-user)> 2/3 $1 = 2/3 scheme@(guile-user)> (exact->inexact $1) $2 = 0. > That's a trap for those people though - it lulls them into thinking > that they understand what's going on, when in fact they don't, because > they don't understand floats, because almost nobody understands > floats. So they don't understand their program, and - even worse - > they don't know that they don't understand it. I don't understand this rant. Numeric programming is one of the oldest uses for computers. Rounding errors have been there since the beginning. If you think people have a hard time getting floats, integers are at least as hard to get. How about classes, closures, threads, asyncio...? Python ought to be the perfect language for seasoned experts. It doesn't need to be dumbed down for noobs. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-22, Marko Rauhamaa wrote: > Jon Ribbens : >> That's a trap for those people though - it lulls them into thinking >> that they understand what's going on, when in fact they don't, because >> they don't understand floats, because almost nobody understands >> floats. So they don't understand their program, and - even worse - >> they don't know that they don't understand it. > > I don't understand this rant. And I don't understand your use of the word "rant". > Numeric programming is one of the oldest uses for computers. > Rounding errors have been there since the beginning. If you think > people have a hard time getting floats, integers are at least as > hard to get. That is clearly nonsense. > How about classes, closures, threads, asyncio...? People don't tend to think of those as simple things that they already understand when they don't. Also, those things don't tend to turn up to the party uninvited. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Mon, 23 May 2016 12:15 am, Jon Ribbens wrote:
> On 2016-05-21, Chris Angelico wrote:
>> On Sat, May 21, 2016 at 10:35 AM, Jon Ribbens
>> wrote:
>>> To be fair, I'm very sympathetic to that argument. I think programming
>>> languages should never magically produce floats out of nowhere unless
>>> the programmer has explicitly done "import float" or "float('3.23')"
>>> or somesuch. They're misunderstood so often that any convenience
>>> they provide is outweighed by the danger they bring.
>>>
>>> "(1/10) * (1/10) * 10 != (1/10)" anyone? I was distinctly unhappy with
>>> the Python 3 "2/3 ~= 0." thing and regard it as a very retrograde
>>> change.
>>
>> The trouble is, what SHOULD 2/3 return?
>>
>> * An integer? Makes a lot of sense to a C programmer. Not so much to
>> someone who is expecting a nonzero value. This isn't terrible (hey,
>> Python 2 managed with it no problem), but will definitely confuse a
>> number of people.
>
> Yes, it should return an integer - and not because I think Python
> should behave like C on principle, but because:
>
> Explicit is better than implicit.
> Simple is better than complex.
> Complex is better than complicated.
>
> and floats are complicated.
How is this any better though? Complicated or not, people want to divide 1
by 2 and get 0.5. That is the functional requirement. Furthermore, they
want to use the ordinary division symbol / rather than having to import
some library or call a function.
Having 1/2 return 0 (as Python 2 does by default) doesn't make the language
any less complicated. It doesn't avoid the complexity of floats, it merely
breaks the principle of least surprise, and forces the programmer to add
what they consider to be an unnecessary ".0" to one or the other of the
operands.
Swapping to a base-10 float will be numerically even worse than the binary
floats we use now. Swapping to rationals add complexity and performance
issues. So whatever you do, there is complexity and annoyance.
>> * A float? That's what we currently have. Not perfect, but it's going
>> to confuse less people than 0 will.
>
> That's a trap for those people though - it lulls them into thinking
> that they understand what's going on, when in fact they don't,
> because they don't understand floats, because almost nobody
> understands floats. So they don't understand their program, and
> - even worse - they don't know that they don't understand it.
And how does forcing them to write 1.0/2 solve that?
Or (hypothetical) float.divide(1, 2) if you want to be even more
explicit :-)
> Programming languages should do what they are told, and very little
> more.
Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing what
you've told it to do?
> They should not wander off on surprising jaunts of their own
> invention out of the control of the programmer. It should be possible
> to know and understand the language, or at least the subset of it
> that you are likely to need for your everyday purposes. Floats are
> generally not understood, so they shouldn't be suddenly turning up
> un-called for.
How are they uncalled for?
> Python generally sticks to this idea very well, which is one of the
> things that I think make it an excellent programming language, so it
> is a shame that in the Python 2 to Python 3 change when mistakes were
> being rectified, a new one was introduced.
*shrug*
I've programmed in Python using classic integer division and true division,
and in my experience and opinion, classic division is a real pain to work
with. You're forever having to cast things to float or write .0 literals
just to convince the interpreter to do division the way you expect.
I suppose some language some day might experiment with swapping the
operators, so that a/b is integer division and a//b is true division.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sunday, May 22, 2016 at 8:28:39 PM UTC+5:30, Marko Rauhamaa wrote: > Python ought to be the perfect language for seasoned experts. It doesn't > need to be dumbed down for noobs. There's a language you may have heard of that you'll LOVE -- C++ Or maybe Haskell On a somewhat more serious note: Speaking of Haskell there has recently been a spate of dissent in the Haskell with people like Mark Lenctzer, Eric Meijer etc saying they are quitting Haskell because its too hard to teach. [These names in roughly python-equivalents are like say Raymond Hettinger and Nick Coghlan] I'd say python has done an eminently decent job so far in being approachable +powerful. But of late its losing the edge in the noob-side at the cost of catering to cognoscenti. IMHO Pascal got things right (wrt pedagogy) that are wronger and wronger in the last 30 years; see http://blog.languager.org/2015/06/functional-programming-moving-target.html On a different note: MIT has replaced scheme by python. Cause to celebrate?? Depends... If being able to do more with less understanding is good... well maybe -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Mon, May 23, 2016 at 1:19 AM, Steven D'Aprano wrote: > Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing what > you've told it to do? That isn't the problem. With binary floats, 1/2 can be perfectly represented, so you have no trouble anywhere. The problem comes when you then try 1/5. What do you get? 3602879701896397/18014398509481984. Python shows that as 0.2. Then you do some more arithmetic, and the veil is pierced, and you discover that 1/5 doesn't actually return 0.2, but just something really really close to it - which it tells you is 0.2. I'm not saying that having 1/5 return 0 is better, but I'd like a broad acceptance that 0.2 is imperfect - that, in fact, *every* option is imperfect. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Chris Angelico : > On Mon, May 23, 2016 at 1:19 AM, Steven D'Aprano wrote: >> Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing what >> you've told it to do? > > That isn't the problem. With binary floats, 1/2 can be perfectly > represented, so you have no trouble anywhere. The problem comes when > you then try 1/5. What do you get? 3602879701896397/18014398509481984. > Python shows that as 0.2. Then you do some more arithmetic, and the > veil is pierced, and you discover that 1/5 doesn't actually return > 0.2, but just something really really close to it - which it tells you > is 0.2. > > I'm not saying that having 1/5 return 0 is better, but I'd like a > broad acceptance that 0.2 is imperfect - that, in fact, *every* option > is imperfect. Ah, that reminds me of an ancient joke: Ask an engineer what is two times two. He'll take out his slide rule, quickly move the slider and reply: "Approximately four." I remember learning my first programming language, Basic, when I was 16. One of the very first things to notice was the way "the computer" worked with approximations. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-22, Steven D'Aprano wrote: > On Mon, 23 May 2016 12:15 am, Jon Ribbens wrote: >> Yes, it should return an integer - and not because I think Python >> should behave like C on principle, but because: >> >> Explicit is better than implicit. >> Simple is better than complex. >> Complex is better than complicated. >> >> and floats are complicated. > > How is this any better though? Complicated or not, people want to divide 1 > by 2 and get 0.5. That is the functional requirement. Furthermore, they > want to use the ordinary division symbol / rather than having to import > some library or call a function. That's a circular argument. You're defining the result as the requirement and then saying that proves the result is necessary. Clearly, people managed when 1/2 returned 0, and continue to do so today in Python 2 and other languages. > Having 1/2 return 0 (as Python 2 does by default) doesn't make the > language any less complicated. It doesn't avoid the complexity of > floats, it merely breaks the principle of least surprise, No, it *adheres* to the principle of least surprise. Floats appearing out of nowhere is surprising. Python 2's behaviour adhered to the principle, and Python 3's breaks it. >> That's a trap for those people though - it lulls them into thinking >> that they understand what's going on, when in fact they don't, >> because they don't understand floats, because almost nobody >> understands floats. So they don't understand their program, and >> - even worse - they don't know that they don't understand it. > > And how does forcing them to write 1.0/2 solve that? Because it forces them to consciously address the fact that they are asking for, and getting, floats, and that floats are not something the language is willingly to silently foist upon them. >> Programming languages should do what they are told, and very little >> more. > > Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing what > you've told it to do? I didn't ask for floats, I got floats. That's how. >> They should not wander off on surprising jaunts of their own >> invention out of the control of the programmer. It should be possible >> to know and understand the language, or at least the subset of it >> that you are likely to need for your everyday purposes. Floats are >> generally not understood, so they shouldn't be suddenly turning up >> un-called for. > > How are they uncalled for? By... not being called for? I must admit I don't entirely understand your question. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Mon, May 23, 2016 at 1:52 AM, Jon Ribbens
wrote:
> That's a circular argument. You're defining the result as the
> requirement and then saying that proves the result is necessary.
> Clearly, people managed when 1/2 returned 0, and continue to do so
> today in Python 2 and other languages.
>
Python's int and float types are both approximations to a
non-representable type called a "real number". You learned about
numbers in your early childhood - you learned about the basic concepts
like addition (you have one apple here and one apple there, so you
have two apples), and division (you take those two apples and split
them between four people by cutting them both in half). If you ask
someone how much apple everyone gets when you divide one apple between
two people, the answer should be "half an apple". Not "no apples" - of
course there are situations where things are indivisible, but numbers
themselves aren't, because there are times when you can indeed halve
those apples just fine.
The problem is that computers can't actually represent real numbers.
We have to content ourselves with a variety of approximations, which
we call numeric data types. Python then treats those data types as
being a minor detail, and the underlying real number as important:
>>> 1 == 1.0 == (1+0j)
True
>>> {1.0: "foo"}[1]
'foo'
Now, there is the small problem that the numeric types can't be
arranged into a perfect tower. If Python's integer were restricted to
2**32, you could automatically upcast any integer to a float
losslessly, and you can already losslessly upcast a float to a complex
simply by adding 0j to it. But most people don't work with numbers big
enough to be unrepresentable in 64-bit IEEE floating point:
>>> (1<<53)+1
9007199254740993
>>> (1<<53)+1 == (1<<53)
False
>>> (1<<53)+1.0 == (1<<53)
True
So for *most people*, this treatment works perfectly. An int will
upcast to a float when you apply the division operator to it. An int
or float will upcast to complex when you apply the exponentiation
operator:
>>> (-4)**0.5
(1.2246467991473532e-16+2j)
Nearly everything stored in a computer is an abstraction that can
leak. In this case, we can't perfectly represent real numbers or
calculate with them, so we do the best we can. Binary floating point
is far from perfect in purity, but it's not bad in practicality.
Remind me what PEP 20 says about that? Gotcha.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-22, Chris Angelico wrote: > Python's int and float types are both approximations to a > non-representable type called a "real number". Sorry, I have to stop you there as the entire premise of your post is clearly wrong. "int" is not "an approximation of real numbers", it's a model of the mathematical concept "integers", and it's not an approximation, and since the long/int unification you can't even overflow it as I understand things (barring ridiculous situations like running out of memory). -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sunday, May 22, 2016 at 10:20:11 PM UTC+5:30, Jon Ribbens wrote: > On 2016-05-22, Chris Angelico wrote: > > Python's int and float types are both approximations to a > > non-representable type called a "real number". > > Sorry, I have to stop you there as the entire premise of your post is > clearly wrong. "int" is not "an approximation of real numbers", it's > a model of the mathematical concept "integers", and it's not an > approximation, and since the long/int unification you can't even > overflow it as I understand things (barring ridiculous situations like > running out of memory). Well maybe Chris should have said (or meant to say?) In math: ℤ ⊆ ℝ whereas in programming int and float are disjoint types. So structurally the (int,float) type pair poorly approximates the (ℤ, ℝ) pair of math sets Doesnt mean I agree with > we can't perfectly represent real numbers or calculate with them, so we do > the best we can Floats are a grotesque travesty of ℝ At the least, interval arithmetic can help automatically do the numerical analysis for you. Then there are all kinds of rational approximations like continued fractions which are better than ℚ All the way to "computable real numbers" We're stuck with them because that's the hardware we've got. Nothing intrinsic or necessary about it -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sun, May 22, 2016, at 10:58, Marko Rauhamaa wrote: > Scheme has the best of both worlds: > >scheme@(guile-user)> 2/3 >$1 = 2/3 >scheme@(guile-user)> (exact->inexact $1) >$2 = 0. Why shouldn't Python do this? Imagine some future version of Python: >>> x = 2/3 >>> x (2/3) >>> type(x) # if it's going to be so integrated into the language it's # hardly sensible to keep calling it 'fractions.Fraction' >>> float(x) 0. On Sun, May 22, 2016, at 11:52, Jon Ribbens wrote: > No, it *adheres* to the principle of least surprise. Floats appearing > out of nowhere is surprising. Python 2's behaviour adhered to the > principle, and Python 3's breaks it. Disregarding for the moment the particular imperfections of the float representation (which would be gone if we used Fraction instead), this is only true if the concrete types of results are regarded as part of the result rather than as an implementation detail for how best to return the requested value. I think it would be entirely reasonable for Fractions to not only appear out of nowhere, but to *disappear* when an operation on them yields a value which is an integer. Values are more important than types. Types are less important than values. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sun, May 22, 2016, at 12:46, Jon Ribbens wrote: > Sorry, I have to stop you there as the entire premise of your post is > clearly wrong. "int" is not "an approximation of real numbers", it's > a model of the mathematical concept "integers", It is a representation of Z, a subset of R (as is float, technically, though that particular subset has no nice name like Z and Q) The operators that apply to it are the operations on R, even operations under which Z (or even R) is not closed. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sunday, May 22, 2016 at 10:55:43 PM UTC+5:30, Random832 wrote: > Values are more important than types. Types are less important than > values. A stronger version that I occasionally tell my students: Values are in reality Types are in our heads Unfortunately we only know how to think thoughts inside our heads Which means we are stuck with the imperfections of our thinking apparatus -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-22, Random832 wrote: > On Sun, May 22, 2016, at 12:46, Jon Ribbens wrote: >> Sorry, I have to stop you there as the entire premise of your post is >> clearly wrong. "int" is not "an approximation of real numbers", it's >> a model of the mathematical concept "integers", > > It is a representation of Z, a subset of R Yes, that's what I just said. "Z" is just (an approximation of!) a symbol that means "the set of integers". > (as is float, technically, though that particular subset has no nice > name like Z and Q) The operators that apply to it are the operations > on R, even operations under which Z (or even R) is not closed. No, in Python integers are closed under the standard arithmetic operators (+ - * / % **) - except, since Python 3, for "/", which is now a special case. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-22, Random832 wrote: > On Sun, May 22, 2016, at 11:52, Jon Ribbens wrote: >> No, it *adheres* to the principle of least surprise. Floats appearing >> out of nowhere is surprising. Python 2's behaviour adhered to the >> principle, and Python 3's breaks it. > > Disregarding for the moment the particular imperfections of the float > representation (which would be gone if we used Fraction instead), this > is only true if the concrete types of results are regarded as part of > the result rather than as an implementation detail for how best to > return the requested value. > > I think it would be entirely reasonable for Fractions to not only appear > out of nowhere, but to *disappear* when an operation on them yields a > value which is an integer. > > Values are more important than types. Types are less important than > values. This would be true if we had some Grand Unified Lossless Number Type. Unfortunately, we don't, and we're not likely to any time soon. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sun, May 22, 2016, at 13:55, Jon Ribbens wrote: > No, in Python integers are closed under the standard arithmetic > operators (+ - * / % **) Z is not closed under standard division, as surely as N isn't closed under subtraction and R isn't closed under exponentiation. That is a mathematical fact, not one about any particular language. What you are saying is that Python 2's "/" is _not_ standard division (you want to talk about the principle of least surprise...), and is therefore _not_ a standard arithmetic operation. It's not Euclidean division, either, since it gives a negative remainder for negative divisors. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sun, May 22, 2016, at 14:06, Jon Ribbens wrote: > This would be true if we had some Grand Unified Lossless Number Type. > Unfortunately, we don't, and we're not likely to any time soon. Scheme manages fine without one. It uses lossless types where it can, and lets you detect that an "inexact" number (which could be float, or could be any of the other types with an inexact flag set) was used where it can't. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: limit number of connections from browser to my server?
On Wed, May 18, 2016, at 18:58, Gregory Ewing wrote: > Grant Edwards wrote: > > Product spec explicitly states HTTPS only. I'm told that is not open > > for discussion. The customer is a large, somewhat bureaucratic German > > corporation, and they generally mean it when they say something is > > non-negotiable. > > They're probably being sensible. The way the Internet of > Things is shaping up, it's far better to have too much > security than too little. HTTPS provides little to no security on a device which has no domain name, since we don't have any well-established way to manage self-signed certificates, or certificates signed on a basis other than the domain name. It'd be nice if there were a way for IOT devices to have a certificate signed *by the manufacturer*. The entire SSL browser UI paradigm is predicated on the fact that what is verified by a certificate is the domain name, which must match the CN field of the certificate, and provides no way to present a certificate issued on another basis to the user. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: limit number of connections from browser to my server?
On 2016-05-22, Random832 wrote: > On Wed, May 18, 2016, at 18:58, Gregory Ewing wrote: >> Grant Edwards wrote: >>> Product spec explicitly states HTTPS only. I'm told that is not open >>> for discussion. The customer is a large, somewhat bureaucratic German >>> corporation, and they generally mean it when they say something is >>> non-negotiable. >> >> They're probably being sensible. The way the Internet of Things is >> shaping up, it's far better to have too much security than too >> little. > > HTTPS provides little to no security on a device which has no domain > name, since we don't have any well-established way to manage > self-signed certificates, or certificates signed on a basis other > than the domain name. It'd be nice if there were a way for IOT > devices to have a certificate signed *by the manufacturer*. The customer can install their own certificate on the server and configure their browsers to require that certificate. They can also configure the server to require that the browser authenticate itself with a specific certificate (which they would have to install on the browser). So, in theory, HTTPS _could_ provide a decent level of security for products like these. Whether anybody actually goes to the trouble to do that, I don't know. I doubt they do, since it requires more than one mouse click, and reading more than 140 characters of text. And, it requires that you understand how SSL certificates work, how to generate them, and in some cases how to set up an internal domain name and DNS server for devices on an air-gapped LAN. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Image loading problem
On 05/21/2016 01:55 PM, Random832 wrote: > On Sat, May 21, 2016, at 12:54, Peter Otten wrote: >> It's not your fault, there's an odd quirk in the library: you have to >> keep a reference of the PhotoImage instance around to prevent the >> image from being garbage-collected. > > Just out of curiosity, why is this a "quirk" and not a bug? Why isn't > the reference held by the Label? The reference is indeed held by the label but the problem is the label is a Tcl/Tk object, thinly wrapped in Python. It's essentially an impedance mismatch between two different languages and object models that each do their own reference holding and counting. I've run into this issue with PySide also as one is instantiating C++ objects that do their own internal reference counting through the Python wrapper. I'm sure Python wrappers could try to correct for this somewhat, but it's not a trivial thing to solve by any means. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Jon Ribbens writes: > No, in Python integers are closed under the standard arithmetic > operators (+ - * / % **) - except, since Python 3, for "/", which > is now a special case. 2 ** -1 is 0.5 even in Python 2[*]. I agree with your general point (that floats should not pop up unbidden) but I don't think you need to exclude the possibly that an operator can do that. With perfect hindsight, I think I'd have had the integers closed under operators +, -, *, //, % and (say) ^, whilst making it clear that / and ** produce floats. There's no reason to see this as being any less explicit that writing 1.0 as a way to make your intent to use floats explicit. * Not a Python expert so all I means is that I get 0.5 on my machine and I'm assuming that's what Python 2 mandates as the result. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Image loading problem
On Sun, May 22, 2016, at 15:37, Michael Torrie wrote: > The reference is indeed held by the label but the problem is the label > is a Tcl/Tk object, thinly wrapped in Python. Okay but then in that case why doesn't the image get instantiated as a Tcl/Tk object which the label holds a reference to and then nobody cares if the python image object gets collected? (And anyway maybe the wrappers shouldn't be so thin if it causes problems like these.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Image loading problem
Am 22.05.16 um 22:19 schrieb Random832: On Sun, May 22, 2016, at 15:37, Michael Torrie wrote: The reference is indeed held by the label but the problem is the label is a Tcl/Tk object, thinly wrapped in Python. Okay but then in that case why doesn't the image get instantiated as a Tcl/Tk object which the label holds a reference to and then nobody cares if the python image object gets collected? Actually, I think it could be solved, and not too complicated either. In Tk, objects are deleted explicitly. This is how you'd do it natively: image create photo bla -file myicon.png # create an image called "bla" pack [label .l -image bla] # display it in a label with name .l Of course, the label references the image object. For instance, if you read in new image data bla read newicon.png -shrink then the label will update. What happens, when you create all those things from Tkinter, the Label object deletes the image in it's destructor: image delete bla # this will turn the label blank This is IMHO correct, but when you add an image to the label through Tkinter, then it only does it through Tk (i.e. the second line in the above code). It should store a reference the Python image object inside the label object. This is akin to a "dangling pointer" in C. It would just be some work to replicate this for all widgets in Tk, there are buttons etc. but in essence I think it would work. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Mon, 23 May 2016 01:52 am, Jon Ribbens wrote:
> On 2016-05-22, Steven D'Aprano wrote:
>> How is this any better though? Complicated or not, people want to divide
>> 1 by 2 and get 0.5. That is the functional requirement. Furthermore, they
>> want to use the ordinary division symbol / rather than having to import
>> some library or call a function.
>
> That's a circular argument. You're defining the result as the
> requirement and then saying that proves the result is necessary.
> Clearly, people managed when 1/2 returned 0, and continue to do so
> today in Python 2 and other languages.
I'm not defining the result. 4000+ years of mathematics defines the result.
If you get up off your chair and wander around and ask people other than C
programmers "What's one divide by two?", I am confident that virtually zero
percent will answer "zero".
People only managed when 1/2 returned 0 by *working around the problem*, and
yes, it is a problem. They work around it by explicitly casting values to
float (which, if carelessly done, just introduces new problems), or by
using "from __future__ import division".
>> Having 1/2 return 0 (as Python 2 does by default) doesn't make the
>> language any less complicated. It doesn't avoid the complexity of
>> floats, it merely breaks the principle of least surprise,
>
> No, it *adheres* to the principle of least surprise. Floats appearing
> out of nowhere is surprising. Python 2's behaviour adhered to the
> principle, and Python 3's breaks it.
The float isn't appearing out of nowhere. It appears because you're
performing a division.
When you call `len("hello world")`, are you shocked that an int appears out
of nowhere? Of course not. That's what len() does.
Why should you be shocked that division returns a fractional quantity?
That's what division does! Divide a cake into two pieces, and you have two
half cakes, not no cake.
>>> That's a trap for those people though - it lulls them into thinking
>>> that they understand what's going on, when in fact they don't,
>>> because they don't understand floats, because almost nobody
>>> understands floats. So they don't understand their program, and
>>> - even worse - they don't know that they don't understand it.
>>
>> And how does forcing them to write 1.0/2 solve that?
>
> Because it forces them to consciously address the fact that they are
> asking for, and getting, floats, and that floats are not something
> the language is willingly to silently foist upon them.
It does no such thing. Have you met any programmers? It forces them to add
an extraneous .0 to the end of their value, and give it no further thought
until somebody reports a bug that Fraction calculations are silently
coerced to floats, and that Decimal calculations raise an exception. And
then they close the bug report "Will not fix" because it's too hard.
>>> Programming languages should do what they are told, and very little
>>> more.
>>
>> Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing
>> what you've told it to do?
>
> I didn't ask for floats, I got floats. That's how.
You performed a division. What did you expect, a dict?
>>> They should not wander off on surprising jaunts of their own
>>> invention out of the control of the programmer. It should be possible
>>> to know and understand the language, or at least the subset of it
>>> that you are likely to need for your everyday purposes. Floats are
>>> generally not understood, so they shouldn't be suddenly turning up
>>> un-called for.
>>
>> How are they uncalled for?
>
> By... not being called for? I must admit I don't entirely understand
> your question.
You performed a division. By definition, this involves returning a
fractional amount, or at least the possibility of returning a fractional
amount. To say that it is "uncalled for" to receive a fractional amount is,
frankly, bizarre.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Sun, May 22, 2016 at 11:55 AM, Jon Ribbens wrote: > On 2016-05-22, Random832 wrote: >> On Sun, May 22, 2016, at 12:46, Jon Ribbens wrote: >>> Sorry, I have to stop you there as the entire premise of your post is >>> clearly wrong. "int" is not "an approximation of real numbers", it's >>> a model of the mathematical concept "integers", >> >> It is a representation of Z, a subset of R > > Yes, that's what I just said. "Z" is just (an approximation of!) > a symbol that means "the set of integers". > >> (as is float, technically, though that particular subset has no nice >> name like Z and Q) The operators that apply to it are the operations >> on R, even operations under which Z (or even R) is not closed. > > No, in Python integers are closed under the standard arithmetic > operators (+ - * / % **) - except, since Python 3, for "/", which > is now a special case. If you want Python integers to be closed under division *and* be mathematically correct then the result of 1 / 2 should be the multiplicative inverse of 2, which is *undefined* in Z. While that might be an argument for raising an exception, it's not in any way a justification of returning 0. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-22, Steven D'Aprano wrote: > On Mon, 23 May 2016 01:52 am, Jon Ribbens wrote: >> On 2016-05-22, Steven D'Aprano wrote: >>> How is this any better though? Complicated or not, people want to divide >>> 1 by 2 and get 0.5. That is the functional requirement. Furthermore, they >>> want to use the ordinary division symbol / rather than having to import >>> some library or call a function. >> >> That's a circular argument. You're defining the result as the >> requirement and then saying that proves the result is necessary. >> Clearly, people managed when 1/2 returned 0, and continue to do so >> today in Python 2 and other languages. > > I'm not defining the result. 4000+ years of mathematics defines the result. OK, I'm bored of you now. You clearly are not willing to imagine a world beyond your own preconceptions. I am not saying that my view is right, I'm just saying that yours is not automatically correct. If you won't even concede that much then this conversation is pointless. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-22, Ben Bacarisse wrote: > Jon Ribbens writes: > >> No, in Python integers are closed under the standard arithmetic >> operators (+ - * / % **) - except, since Python 3, for "/", which >> is now a special case. > > 2 ** -1 is 0.5 even in Python 2[*]. Haha, excellent, well found. I was wondering if there were any edge cases I was wrong about. I suppose ideally I would make it so that 2 ** -1 throws an exception or something. But of course this particular train has left the station a long time ago. > I agree with your general point (that floats should not pop up unbidden) > but I don't think you need to exclude the possibly that an operator can > do that. With perfect hindsight, I think I'd have had the integers > closed under operators +, -, *, //, % and (say) ^, whilst making it > clear that / and ** produce floats. There's no reason to see this as > being any less explicit that writing 1.0 as a way to make your intent to > use floats explicit. My fundamental point is that floats are surprising, so people should not be surprised by them arriving unbidden - and most of the time, there is no need at all for them to turn up unannounced. Making that occurrence more likely rather than less was a mistake. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Mon, May 23, 2016 at 10:36 AM, Jon Ribbens wrote: > On 2016-05-22, Steven D'Aprano wrote: >> On Mon, 23 May 2016 01:52 am, Jon Ribbens wrote: >>> On 2016-05-22, Steven D'Aprano wrote: How is this any better though? Complicated or not, people want to divide 1 by 2 and get 0.5. That is the functional requirement. Furthermore, they want to use the ordinary division symbol / rather than having to import some library or call a function. >>> >>> That's a circular argument. You're defining the result as the >>> requirement and then saying that proves the result is necessary. >>> Clearly, people managed when 1/2 returned 0, and continue to do so >>> today in Python 2 and other languages. >> >> I'm not defining the result. 4000+ years of mathematics defines the result. > > OK, I'm bored of you now. You clearly are not willing to imagine > a world beyond your own preconceptions. I am not saying that my view > is right, I'm just saying that yours is not automatically correct. > If you won't even concede that much then this conversation is pointless. The point of arithmetic in software is to do what mathematics defines. Would you expect 1+2 to return 5? No. Why not? Where was the result defined? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-23, Chris Angelico wrote: > On Mon, May 23, 2016 at 10:36 AM, Jon Ribbens > wrote: >> On 2016-05-22, Steven D'Aprano wrote: >>> On Mon, 23 May 2016 01:52 am, Jon Ribbens wrote: On 2016-05-22, Steven D'Aprano wrote: > How is this any better though? Complicated or not, people want to divide > 1 by 2 and get 0.5. That is the functional requirement. Furthermore, they > want to use the ordinary division symbol / rather than having to import > some library or call a function. That's a circular argument. You're defining the result as the requirement and then saying that proves the result is necessary. Clearly, people managed when 1/2 returned 0, and continue to do so today in Python 2 and other languages. >>> >>> I'm not defining the result. 4000+ years of mathematics defines the result. >> >> OK, I'm bored of you now. You clearly are not willing to imagine >> a world beyond your own preconceptions. I am not saying that my view >> is right, I'm just saying that yours is not automatically correct. >> If you won't even concede that much then this conversation is pointless. > > The point of arithmetic in software is to do what mathematics defines. > Would you expect 1+2 to return 5? No. Why not? Where was the result > defined? Are you trying to compete with him for the Missing The Point Award? -- https://mail.python.org/mailman/listinfo/python-list
RFC: name for project of a cross version disassembler, and unmarshal program
I'm looking for a good name for a relatively new project I'll put on pypy. I've been working on a module to disassemble Python bytecode from many versions of Python. (Right now 2.3 .. 3.5 bytecode, largely works.) Of course, in order to do that you also need routines to unmarshal bytecode. So that's in there as well. In the future, I may could add a marshaler and an assembler to Python bytecode. I know, this is kind of perverse. At any rate the name I've been using is "pyxdis". See https://github.com/rocky/python-pyxdis. In the past I've been told by Polish-speaking people that my names are hard to pronounce. (If you've ever heard any Polish tongue twisters, you'll know that this really hurts.) Any suggestions for a better name? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016-05-23 02:00, Jon Ribbens wrote: On 2016-05-23, Chris Angelico wrote: On Mon, May 23, 2016 at 10:36 AM, Jon Ribbens wrote: On 2016-05-22, Steven D'Aprano wrote: On Mon, 23 May 2016 01:52 am, Jon Ribbens wrote: On 2016-05-22, Steven D'Aprano wrote: How is this any better though? Complicated or not, people want to divide 1 by 2 and get 0.5. That is the functional requirement. Furthermore, they want to use the ordinary division symbol / rather than having to import some library or call a function. That's a circular argument. You're defining the result as the requirement and then saying that proves the result is necessary. Clearly, people managed when 1/2 returned 0, and continue to do so today in Python 2 and other languages. I'm not defining the result. 4000+ years of mathematics defines the result. OK, I'm bored of you now. You clearly are not willing to imagine a world beyond your own preconceptions. I am not saying that my view is right, I'm just saying that yours is not automatically correct. If you won't even concede that much then this conversation is pointless. The point of arithmetic in software is to do what mathematics defines. Would you expect 1+2 to return 5? No. Why not? Where was the result defined? Are you trying to compete with him for the Missing The Point Award? The relevant doc is PEP 238, dating to March 2001, when Python 2.2 was new. -- https://mail.python.org/mailman/listinfo/python-list
Interfacing a dynamic shared library gives me different results in 2.7 versus 3.5
I have a dynamic library doing some numerical computations. I used ctypes to interact it by passing numpy arrays back and forth. Python 3.5 gives me the correct results. Python 2.7 gives me different, erroneous results, but it never crashes. How is this possible? There is no string operations involved whatsoever. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Jon Ribbens writes: > OK, I'm bored of you now. You clearly are not willing to imagine > a world beyond your own preconceptions. Steven has, in the message to which you responded, asked for you to *describe* this other world you assert exists. More concretely: Steven is not denying someone might have different expectations. On the contrary, you've said your expectations differ, and Steven is *explicitly asking* you to specify those expectations. And, instead of answering, you give this dismissal. Are your expectations so hard to describe? -- \ “It is wrong to think that the task of physics is to find out | `\ how nature *is*. Physics concerns what we can *say* about | _o__) nature…” —Niels Bohr | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Monday, May 23, 2016 at 9:59:27 AM UTC+5:30, Ben Finney wrote: > Jon Ribbens writes: > > > OK, I'm bored of you now. You clearly are not willing to imagine > > a world beyond your own preconceptions. > > Steven has, in the message to which you responded, asked for you to > *describe* this other world you assert exists. > > More concretely: Steven is not denying someone might have different > expectations. On the contrary, you've said your expectations differ, and > Steven is *explicitly asking* you to specify those expectations. > > And, instead of answering, you give this dismissal. Are your > expectations so hard to describe? Steven is making wild and disingenuous statements; to wit: On Monday, May 23, 2016 at 3:39:19 AM UTC+5:30, Steven D'Aprano wrote: > I'm not defining the result. 4000+ years of mathematics defines the result. This is off by on order of magnitude. Decimal point started with Napier (improving on Stevin): 17th century OTOH it is plain numbers (ℕ) that have been in use for some 4 millennia. > > If you get up off your chair and wander around and ask people other than C > programmers "What's one divide by two?", I am confident that virtually zero > percent will answer "zero". You forget that we (most of us?) went to school. My recollections of it -- ok maybe fogged by near 5 decades: I first learnt something called 'long-division' In that procedure you take 2 numbers called divisor and dividend And GET TWO NUMBERS a quotient and a remainder. [At that point only knew of the numbers we would later call ℤ (or was it ℕ -- not sure -- decimal point would come later] Later (again dont remember order) we were taught - short division - decimal numbers [I mention short division -- put numerator on top of denominator and cancel off factors -- because the symmetry of numerator:denominator and quotient:remainder is more apparent there than in long-division] In any case if learning primacy has any significance, pure integer division is more basic than decimal number division. To recapitulate the situation: Mathematics (mathematicians if you prefer) have a strong attachment to to two nice properties of operators: The first is obvious and unarguable -- totality The second does not have a standard term but is important enough -- I will call it 'homogeneity'. By this I mean a type of the form: t × t → t Its nice to have totality because one can avoid case-analysing: f(x) when x ∈ domain(f) Its nice to have homogeneity because homogeneous operators can be nested/unnested/played-with ie for ◼ : t × t → t x ◼ y ◼ z makes sense this way x ◼ (y ◼ z) or this way (x ◼ y) ◼ z With non-homogeneous ◼ these may not make sense. - Choosing ÷ to be total and homogeneous necessitates widening ℤ (or ℕ) to ℚ or ℝ (or something as messy) - Choosing ÷ to be non-homogeneous means needing to deal with quotients and remainders Cant write if (x/4 < 256)... have to write quot, rem = x/4 # throw away rem if quot < 256: ... Haskell has (almost) what I learnt at school: Prelude> let (q,r) = 7 `divMod` 3 Prelude> (q,r) (2,1) Replace the strange `divMod` with / and we are back to the behavior I first learnt at school So with some over-simplification: - the first choice leads to numerical analysis - the second leads to number theory To say that one is natural --especially the one that chooses something other than natural numbers! --and the other is surprising is nonsense. -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: name for project of a cross version disassembler, and unmarshal program
rocky writes: > I'm looking for a good name for a relatively new project I'll put on pypy. > > I've been working on a module to disassemble Python bytecode from many > versions of Python. (Right now 2.3 .. 3.5 bytecode, largely works.) > > Of course, in order to do that you also need routines to unmarshal > bytecode. So that's in there as well. > > In the future, I may could add a marshaler and an assembler to Python > bytecode. I know, this is kind of perverse. > > At any rate the name I've been using is "pyxdis". See > https://github.com/rocky/python-pyxdis. > > In the past I've been told by Polish-speaking people that my names are > hard to pronounce. (If you've ever heard any Polish tongue twisters, > you'll know that this really hurts.) > > Any suggestions for a better name? relipmoc -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
Rustom Mody : > Haskell has (almost) what I learnt at school: > > Prelude> let (q,r) = 7 `divMod` 3 > Prelude> (q,r) > (2,1) Python: >>> divmod(7, 3) (2, 1) > Replace the strange `divMod` with / and we are back to the behavior I > first learnt at school X We never used '/' in school for anything. We used 'X : Y' or '---'. Y Anyway, every calculator in the world produces: 1 ÷ 2 = ==> 0.5 Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Monday, May 23, 2016 at 12:01:08 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > > Haskell has (almost) what I learnt at school: > > > > Prelude> let (q,r) = 7 `divMod` 3 > > Prelude> (q,r) > > (2,1) > > Python: > >>>> divmod(7, 3) >(2, 1) > > > Replace the strange `divMod` with / and we are back to the behavior I > > first learnt at school > >X > We never used '/' in school for anything. We used 'X : Y' or '---'. >Y > > Anyway, every calculator in the world produces: > >1 >÷ >2 >= > >==> 0.5 Not true: https://www.youtube.com/watch?v=iynCW9O_x58 [And ive seen such 40 years ago] -- https://mail.python.org/mailman/listinfo/python-list
