Re: GUIs - A Modest Proposal
"Grant Edwards" wrote in message news:hullf3$hl...@reader1.panix.com... On 2010-06-08, Kevin Walzer wrote: Since Tk already provides a basic GUI toolset, and Python can interface with it more directly than it can with other toolkits (PyGui -> PyGtk -> Gtk -> Xlib), Compare that to this: TkInter -> Tcl -> Tk -> Xlib Is the Tcl intepreter really need to use this GUI? Why not: (Pyton ->) Tkinter-API -> Xlib ? Most of the work of designing a GUI is, well, designing it. That's already been done for Tkinter so why not just implement the same spec in Python (with whatever lower-level code is needed). Then extending it should be simpler. it's not clear to me what is gained by starting from scratch here. (Is it the presence of the Tcl interpreter? I know Tcl is not to everyone's taste, but it is an amazing language...) Some people aren't interested in the amazing language. Only the graphics API that goes with it. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
"Steven D'Aprano" wrote in message news:4c101fbc$0$28644$c3e8...@news.astraweb.com... On Wed, 09 Jun 2010 04:16:23 -0700, ant wrote: 1 Although a few advocates of Tkinter have spoken in favour of it, most seem to think that: It's not particularly elegant, either in its use or its implementation with Tcl/Tk If we didn't have a GUI in the distribution, we wouldn't choose Tkinter now; it seems like its inclusion is a sort of historical accident. I'm not so sure about that. If we didn't have a GUI, what would we include? Is the Tkinter GUI also the basic way that Python handles a graphics display? (I've never tried it.) If it is, then perhaps it's possible to split the purely graphical drawing stuff (which is simple) from the dialog/widget stuff (which is not so simple). A library for graphical display, plus basic user-input, should be straightforward to implement. And can be used to produce crude (non-native) GUIs. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: List of lists surprising behaviour
"J Kenneth King" wrote in message news:87wrtxh0dq@agentultra.com... candide writes: Let's the following code : t=[[0]*2]*3 t [[0, 0], [0, 0], [0, 0]] t[0][0]=1 t [[1, 0], [1, 0], [1, 0]] Rather surprising, isn't it ? Not at all, actually. The code is clearly trying to set only t[0][0] to 1, not t[1][0] and t[2][0] as well. This behaviour is quite scary actually, especially when t[0]=42 *does* work as expected, while t[0][0]=42 is apparently duplicated. It appears inconsistent. I'd be surprised if the multiplication operator was aware of object constructors. Even arrays are "objects" in Python. Should the multiplication operator know how to instantiate three arrays from a single array instance? What about an instance of a user-defined class? Multiplication operators shouldn't need to be directly aware of any such thing; it should just request that an object be duplicated without worrying about how it's done. I don't know how Python does things, but an object should either specify a special way of duplicating itself, or lend itself to some standard way of doing so. (So for a list, it's just a question of copying the data in the list, then recursively duplicating each new element..) -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: List of lists surprising behaviour
Benjamin Kaplan wrote: On Thu, Jun 17, 2010 at 4:20 PM, bart.c wrote: I don't know how Python does things, but an object should either specify a special way of duplicating itself, or lend itself to some standard way of doing so. (So for a list, it's just a question of copying the data in the list, then recursively duplicating each new element..) It's the recursively duplicating each element that's the problem. How do you know when to stop? When you reach a primitive object (one not comprising other objects). (I don't know if Python allows circular references, but that would give problems anyway: how would you even print out such a list?) -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: List of lists surprising behaviour
Lie Ryan wrote: On 06/18/10 20:00, bart.c wrote: (I don't know if Python allows circular references, but that would give problems anyway: how would you even print out such a list?) Python uses ellipsis to indicate recursive list: a = [1, 2, 3] a.append(a) a [1, 2, 3, [...]] Ok, perhaps whatever logic print uses to know when to stop and show "...", can also be used by copy handlers... (Although I have an issue with the way that that append works. I tried it in another, simpler language (which always does deep copies): L:=(1,2,3) L append:= L print L output: (1,2,3,(1,2,3)) which is exactly what I'd expect, and not (1,2,3,(1,2,3,(1,2,3,...))) ) -- bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: List of lists surprising behaviour
"Steven D'Aprano" wrote in message
news:4c1b8ac6$0$14148$c3e8...@news.astraweb.com...
On Fri, 18 Jun 2010 12:07:38 +0100, bart.c wrote:
(Although I have an issue with the way that that append works. I tried
it in another, simpler language (which always does deep copies):
L:=(1,2,3)
L append:= L
print L
output: (1,2,3,(1,2,3))
which is exactly what I'd expect,
and not (1,2,3,(1,2,3,(1,2,3,...))) )
I find that behaviour a big surprise. You asked to append the list L, not
a copy of the list L. So why is this "simpler" language making a copy
without being asked?
If you asked for:
L:=(1,2,3)
M:=(0,1)
M append:= L
does it also append a copy of L instead of L?
It make a copy.
If so, how do you append
the original rather than wastefully making a copy?
I don't think it can, without perhaps doing something with explicit
pointers.
If L is huge, making a
copy before appending will be slow, and potentially fail.
I don't know whether L append:=L requires 3 times the space of L, or 2
times, during the operation. But it should be doable using just twice the
space.
I suppose there are pros and cons to both approaches; copying all the time
at least avoids some of the odd effects and inconsistencies you get using
Python:
a1=[1,2,3]
a1.append(a1)
a2=[1,2,3]
b=[1,2,3]
a2.append(b)
a3=[1,2,3]
a3.append([1,2,3])
print ("a1 = ",a1)
print ("a2 = ",a2)
print ("a3 = ",a3)
Here, a1 ends up with a different result from a2, a3, even though the same
value is being appended to the same list of numbers in each case. And it
might sometimes bite you in the arse as the OP demonstrated:
L=[1,2,3]
M=[0,1]
M.append(L)
print (M) # output: [0, 1, [1, 2, 3]]
L[1]=31416
print (M) # output: [0, 1, [1, 31416, 3]], yikes!
--
Bartc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
"sturlamolden" wrote in message news:daa07acb-d525-4e32-91f0-16490027c...@w12g2000yqj.googlegroups.com... I was just looking at Debian's benchmarks. It seems LuaJIT is now (on median) beating Intel Fortran! C (gcc) is running the benchmarks faster by less than a factor of two. Consider that Lua is a dynamically typed scripting language very similar to Python. LuaJIT also runs the benchmarks faster than Java 6 server, OCaml, and SBCL. I know it's "just a benchmark" but this has to count as insanely impressive. Beating Intel Fortran with a dynamic scripting language, how is that even possible? And what about all those arguments that dynamic languages "have to be slow"? If this keeps up we'll need a Python to Lua bytecode compiler very soon. And LuaJIT 2 is rumoured to be much faster than the current... Looking at median runtimes, here is what I got: gcc 1.10 LuaJIT1.96 Java 6 -server2.13 Intel Fortran 2.18 OCaml 3.41 SBCL 3.66 JavaScript V8 7.57 PyPy 31.5 CPython 64.6 Perl 67.2 Ruby 1.9 71.1 The only comfort for CPython is that Ruby and Perl did even worse. I didn't see the same figures; LuaJIT seem to be 4-5 times as slow as one of the C's, on average. Some benchmarks were slower than that. But I've done my own brief tests and I was quite impressed with LuaJIT which seemed to outperform C on some tests. I'm developing my own language and LuaJIT is a new standard to beat for this type of language. However, Lua is quite a lightweight language with minimalist data types, it doesn't suit everybody. I suspect also the Lua JIT compiler optimises some of the dynamicism out of the language (where it can see, for example, that something is always going to be a number, and Lua only has one numeric type with a fixed range), so that must be a big help. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- floating point arithmetic
david mainzer wrote: sum = 0.0 for i in range(10): ... sum += 0.1 ... sum 0.99989 But thats looks a little bit wrong for me ... i must be a number greater then 1.0 because 0.1 = 0.155511151231257827021181583404541015625000 in python ... if i print it. So i create an example program: sum = 0.0 n = 10 d = 1.0 / n print "%.60f" % ( d ) for i in range(n): print "%.60f" % ( sum ) sum += d print sum print "%.60f" % ( sum ) - RESULTs -- 0.1555111512312578270211815834045410156250 0. 0.1555111512312578270211815834045410156250 0.20001110223024625156540423631668090820312500 0.3000444089209850062616169452667236328125 0.40002220446049250313080847263336181640625000 0.5000 0.59997779553950749686919152736663818359375000 0.6999555910790149937383830547332763671875 0.79993338661852249060757458209991455078125000 0.8999111821580299874767661094665527343750 1.0 0.99988897769753748434595763683319091796875000 and the jump from 0.50*** to 0.5999* looks wrong for me ... do i a mistake or is there something wrong in the representation of the floating points in python? I think the main problem is, as sum gets bigger, the less significant bits of the 0.1 representation fall off the end (enough to make it effectively just under 0.1 you're adding instead of just over). can anybody tell me how python internal represent a float number?? Try "google ieee floating point". The problems aren't specific to Python. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- floating point arithmetic
david mainzer wrote: sum = 0.0 for i in range(10): ... sum += 0.1 ... sum 0.99989 But thats looks a little bit wrong for me ... i must be a number greater then 1.0 because 0.1 = 0.155511151231257827021181583404541015625000 in python ... if i print it. So i create an example program: sum = 0.0 n = 10 d = 1.0 / n print "%.60f" % ( d ) for i in range(n): print "%.60f" % ( sum ) sum += d print sum print "%.60f" % ( sum ) - RESULTs -- 0.1555111512312578270211815834045410156250 0. 0.1555111512312578270211815834045410156250 0.20001110223024625156540423631668090820312500 0.3000444089209850062616169452667236328125 0.40002220446049250313080847263336181640625000 0.5000 0.59997779553950749686919152736663818359375000 0.6999555910790149937383830547332763671875 0.79993338661852249060757458209991455078125000 0.8999111821580299874767661094665527343750 1.0 0.99988897769753748434595763683319091796875000 and the jump from 0.50*** to 0.5999* looks wrong for me ... do i a mistake or is there something wrong in the representation of the floating points in python? I think the main problem is, as sum gets bigger, the less significant bits of the 0.1 representation fall off the end (enough to make it effectively just under 0.1 you're adding instead of just over). can anybody tell me how python internal represent a float number?? Try "google ieee floating point". The problems aren't specific to Python. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: integer >= 1 == True and integer.0 == False is bad, bad, bad!!!
"rantingrick" wrote in message news:1b285203-33f6-41fb-8321-381c154bc...@w12g2000yqj.googlegroups.com... Let me tell you folks about a recent case of culo rojo i experianced whilst creating a customized bin packer with Python. First i want to say that i actually like the fact that i can do this.. py> a = [] py> if a: ... do something Instead of this py> if len(a) > 0: ... do something Or perhaps: if len(a): ... Ok but the buck stops with integers. Why? you ask in amazing befuddlement...Well I happened upon this atrocity when creating variables that hold indexes into a python list. choiceIdx1 = None choiceIdx2 = None if array[0] meets condition this condition: choiceIdx1 = 0 for i in range(len(array)): if array[i] meets this condition: choiceIdx2 = i break if choiceIdx1 and not choiceIdx2: BUT THAT WONT WORK BECAUSE OF CRAPPY INTEGER BOOLEAN DEFAULTS! So i had to do this crap...! You can also blame the 0-based indexing in Python. I'm not sure what would be the more fundamental change: changing over to 1-based indexing, or for 0 to be True (probably the opposite meaning to every other language). array = [c1,c2,c3,c4,c5,c6,...] while looping: choiceIdx1 = () choiceIdx2 = () if array[0] meets condition this condition: choiceIdx1 = (0,) for i in range(len(array)): if array[i] meets this condition: choiceIdx2 = (i,) break if choiceIdx1 and not choiceIdx2: Seems kinda dumb to build a tuple just so a conditional wont blow chunks! This integer bool-ing need to be fixed right away! So, you're simply trying to signal whether a value is in the range 0 or more, or not? That doesn't sound difficult: start with -1, then test whether it's >=0. But you're trying a boolean test where you expect None=False, and 0,1,2, etc = True. While this would save typing in the condition, you're introducing extraneous stuff elsewhere which makes it harder to read, such as (i,) just to store an index. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Easy questions from a python beginner
"MRAB" wrote in message
news:mailman.591.1278900548.1673.python-l...@python.org...
Alf P. Steinbach /Usenet wrote:
def foo():
print( blah )
blah = "this is both an assignment and a declaration causing it to
exist"
foo()
Clearly when the exception is raised, referring to the variable, the
variable exists.
How about this:
>>> def foo():
print("Before:", locals())
x = 0
print("After:", locals())
>>> foo()
Before: {}
After: {'x': 0}
That's interesting. So in Python, you can't tell what local variables a
function has just by looking at it's code:
def foo(day):
if day=="Tuesday":
x=0
print ("Locals:",locals())
#foo("Monday")
Does foo() have 1 or 2 locals? That might explain some of the difficulties
of getting Python implementations up to speed.
--
Bartc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Easy questions from a python beginner
"Steven D'Aprano" wrote in message
news:4c3aedd5$0$28647$c3e8...@news.astraweb.com...
On Mon, 12 Jul 2010 09:48:04 +0100, bart.c wrote:
That's interesting. So in Python, you can't tell what local variables a
function has just by looking at it's code:
def foo(day):
if day=="Tuesday":
x=0
print ("Locals:",locals())
#foo("Monday")
Does foo() have 1 or 2 locals?
That's easy for CPython: it prepares two slots for variables, but only
creates one:
foo("Monday")
('Locals:', {'day': 'Monday'})
foo.func_code.co_varnames
('day', 'x')
foo.func_code.co_nlocals
2
So, the question is, is x a local variable or not? It's not in locals,
but the function clearly knows that it could be.
So Alf P.S. could be right; x exists, but Python pretends it doesn't until
it's assigned to.
That might explain some of the
difficulties of getting Python implementations up to speed.
I'm not quite sure why you say that.
Only that an implementation might be obliged to keep these various tables
updated during function execution, instead of just at entry and exit.
--
Bartc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Splitting numeric litterals
"Steven D'Aprano" wrote in message news:4c4069de$0$11101$c3e8...@news.astraweb.com... On Fri, 16 Jul 2010 14:49:21 +0100, MRAB wrote: Not only that, but it only takes 73 digits to write out the total number of particles in the entire universe: 1 or 1e72. (Of course that's the lower-bound, estimates range from 1e72 all the way up to 1e87.) So for anything related to counting or labelling actual, physical objects, you will be dealing with smaller numbers than that. E.g. the number of grains of sand on the earth has been estimated (very roughly) as a mere 1, or 25 digits. Big integers tend to be used for playing around with mathematical ideas, and they have to be exact. So if you wanted to hardcode 1000! for some reason, you'd need some 2568 digits which is a little awkward on one line. It always makes me laugh when I receive an invoice from some company, and the account number or invoice number is (e.g.) 100023456789. Who do they think they're fooling? I used to do that. Giving someone an invoice number, or product serial number, 01 doesn't exactly give the impression of a thriving business. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
