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 dat
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.
>
>
> ---
> ValueError
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
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]
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 "quir
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
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 "
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 bette
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 understa
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
>
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:
S
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
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.
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
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.
>
Py
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 t
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
> cl
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
>>
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 floa
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
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 repre
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
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 fac
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" n
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
> >
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 me
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 curiosi
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
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 t
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 objec
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 t
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 mod
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
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
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 i
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 w
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
t
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? Co
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 operatio
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 migh
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 othe
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
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
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` wi
44 matches
Mail list logo
