vatnumber 0.8 is out
vatnumber is a Python module to validate VAT numbers. It can validate VAT formats for 35 countries and can use the European VIES [1] service. http://pypi.python.org/pypi/vatnumber/0.8 The changelog for this release: * Add GB validation for the 9755 checksum introduced in November 2009 [1] http://ec.europa.eu/taxation_customs/vies/vieshome.do -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: __pycache__, one more good reason to stck with Python 2?
On Jan 18, 6:07 am, Terry Reedy tjre...@udel.edu wrote: ... This is the 21-year-old behavior now changed. ... Yes, you summarized the situation very well. The way of working has changed and probably more deeply that one may think. It is now practically impossible to launch a Python application via a .pyc file. (For the fun, try to add the parent directory of a cached file to the sys.path). About the caches, I'am just fearing, they will become finally garbage collectors of orphan .pyc files, Python has seed/seeded(?). The .pyc files may not be very pleasant, but at least you can use them and you have that feeling of their existence. I my computer experience, once you start to cache/hide something for simplicity, the problems start. May be it a good move for Python, I do not feel very comfortable with all this stuff. -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
Carl Banks wrote:
On Jan 17, 6:29 pm, Alice Bevan–McGregor al...@gothcandy.com wrote:
find . -name \*.pyc -exec rm -f {} \;
vs.
rm -rf __pycache__
I do not see how this is more difficult, but I may be missing something.
Well the former deletes all the pyc files in the directory tree
whereas the latter only deletes the top level __pycache__, not the
__pycache__ for subpackages. To delete all the __pycache__s you'd
have to do something like this:
file . -name __pycache__ -prune -exec rm -rf {} \;
or, better,
file . -name __pycache__ -prune | xargs rm -rf
Still not anything really difficult. (I don't think a lot of people
know about -prune; it tells find don't recursively descend.)
What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Adam Skutt ask...@gmail.com Subject: Re: Tkinter: The good, the bad, and the ugly! On Jan 17, 3:08 pm, Octavian Rasnita orasn...@gmail.com wrote: From: Adam Skutt ask...@gmail.com And we're not discussing those languages, we're discussing Python, which has an explicit policy of batteries included. As such, criticism of the standard library is perfectly acceptable under the name Python, whether you like it or not. Besides, it's inevitable anyway. Batteries included? Python doesn't follow this policy at all. We can say that maybe PHP follows it, but not Python. http://lmgtfy.com/?q=python+%22batteries+included%22l=1 Well, this doesn't mean anything because Perl can also say that includes batteries, and PHP can say it also. And if this is the wanted policy, why should it be cheap batteries included and not strong batteries included? You'd have this same argument regardless of GUI toolkit you end up picking, or even if you choose to not include one at all. This would be because none of them are universal solutions, all of them have deficiencies (actual or perceived) that make them unsuitable for certain applications. Adam You are perfectly right. Then why favor Tkinter and not WxPython. Why not strip the Python package and offer WxPython and Tkinter separately? Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Alexander Kapps alex.ka...@web.de On 17.01.2011 21:04, Octavian Rasnita wrote: I say probably not considering the availability of 3rd party downloads. What say you, Python community? Available as 3rd party downloads: XML,HTML,... HTTP,FTP,SMTP,POP,IMAP/... MD5,SHA,... zip,bzip,... and so on and so on and so on. Remove them all just because they are available as 3rd party downloads? No, they should not be removed because they don't cause any damage, very bad damage as Tkinter does. The Batteries included of Python is just *great* and I vote for *more* not less batteries! Well, in that case, why don't you agree to also include WxPython in the Python package? And one more thing. Not all the Python programmers create desktop apps so a GUI lib is useless. Some of them use Python only for web programming or only for system administration. Not all Python programmers do web programming, so please remove the useless HTML junk too. Why do you call it html junk? Almost every beginner wants to do GUIs or at least some graphic stuff. Removing the GUI module from the stdlib would be plain wrong IMHO. But I don't understand the whole issue anyway. It isn't that you need to fire up your torrent client and wait 48 hours for the Python download to complete. Why remove useful (to many, not most) stuff from the lib? Yes it can be useful for some people, but why promote it instead of promoting a better library for beginners? Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: rusi rustompm...@gmail.com Lehman Beladys entropy law http://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution says The quality of ... systems will decline unless they are rigorously maintained and adapted to operational environment changes. Yes. Pretty right. Tkinter - WxPython change would be a very good one. Guido's 'benevolent dictatorship' has so far kept python the exception because - he give powerful batteries to start with With the exception of Tkinter. :-)) - does not introduce junk - is not afraid of backward incompatibility for the sake of clarity and cleanliness (python3) Well, on the long term this could be a very big disadvantage also. Of course, the beginners won't care, but the old users and the companies that would need to adapt the old code that might not work with newer versions of Python won't like this incompatibility. Gui (and web) frameworks are two of his more visible failures Well, Python has good GUI libs , at least WxPython, however it is not one of its included batteries. :-) Yes, for web programming Python is not as great as Perl, but I don't think this has something to do with the core Python. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
Terry Reedy, 18.01.2011 04:39: Saving module code to the filesystem speeds startup, which most find slow as it is. I've been using Jython recently, which, in addition to the huge JVM startup time, must also fire up the Jython runtime before actually doing anything useful. I must say that I never found CPython's startup time to be slow, quite the contrary. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
Peter Otten, 18.01.2011 10:04: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? The former runs in parallel, the latter runs sequentially. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
jmfauth, 18.01.2011 09:58: About the caches, I'am just fearing, they will become finally garbage collectors of orphan .pyc files, Python has seeded I can't see how that is supposed to be any different than before. If you rename a file without deleting the .pyc file, you will end up with an orphaned .pyc file, right now and as it was for the last 21 years. The same applies to the new cache directory. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficient python 2-d arrays?
On Jan 17, 10:20 pm, Jake Biesinger jake.biesin...@gmail.com wrote:
Hi all,
Using numpy, I can create large 2-dimensional arrays quite easily.
import numpy
mylist = numpy.zeros((1,2), dtype=numpy.int32)
Unfortunately, my target audience may not have numpy so I'd prefer not to use
it.
Similarly, a list-of-tuples using standard python syntax.
mylist = [(0,0) for i in xrange(1)
but this method uses way too much memory (4GB for 100 million items,
compared to 1.5GB for numpy method).
Since I want to keep the two elements together during a sort, I *can't* use
array.array.
mylist = [array.array('i',xrange(1)),
array.array('i',xrange(1))]
If I knew the size in advance, I could use ctypes arrays.
from ctypes import *
class myStruct(Structure):
_fields_ = [('x',c_int),('y',c_int)]
mylist_type = myStruct * 1
mylist = mylist_type()
but I don't know that size (and it can vary between 1 million-200 million),
so preallocating doesn't seem to be an option.
Is there a python standard library way of creating *efficient* 2-dimensional
lists/arrays, still allowing me to sort and append?
Thanks!
Since you can't depend on your users installing the dependencies, is
it vital that your users run from source? You could bundle up your
application along with numpy and other dependencies using py2Exe or
similar. This also means you wouldn't have to require users to have
the right (or any) version of Python installed.
--
http://mail.python.org/mailman/listinfo/python-list
newby qn about functions
#This has to be very simple, but I don't get it-please help def *lower_case*(s): #return s print(s) #return s.lower() print(s.lower()) s=*Testing Functions-lower case: * lower_case(s) *how can i use a return statement to write a function that returns the string Testing Functions-lower case: and the lowercase representation of its string parameter If I uncomment the above, nothing outputs to console:(* ** *Much appreciation as always.* -- http://mail.python.org/mailman/listinfo/python-list
Python unicode utf-8 characters and MySQL unicode utf-8 characters
Hello, Recently I tried to insert some unicode object in utf-8 encoding into MySQL using MySQLdb, and got MySQL warnings on characters like: βΠΥΠ i found somewhere in my data. I can't even read them. MySQL seems to cut the whole string after that characters off, so I get incomplete data. After a little bit of digging I found out, that MySQL usually supports utf-8 data but encoded into maximum three bytes. That's why I think it would help I f I was able to replace all larger unicode characters with replacement characters. Is there any way, I could adjust python unicode utf-8 encoded strings to be accepted by mysql utf-8 columns? -- http://mail.python.org/mailman/listinfo/python-list
Re: newby qn about functions
how can i use a return statement to write a function that returns the string Testing Functions-lower case: and the lowercase representation of its string parameter If I uncomment the above, nothing outputs to console:( def lower_case(s): return Testing Functions-lower case: %s % (s.lower()) print(lower_case(HeLLo)) Testing Functions-lower case: hello d = lower_case(HeLLo) print(d) Testing Functions-lower case: hello If a function returns something and you want it printed, you need to then tell Python to print the return. Please note that return and print aren't the same things, return returns a given variable or constant, and print simply prints a given variable or constant. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Mon, 17 Jan 2011 19:41:54 +, Tim Harig wrote: One of the arguments for Python has always made is that you can optimize it by writing the most important parts in C. Perhaps that is a crutch that has held the communty back from seeking higher performance solutions in the language itself. Are you aware of PyPy? Yes I have heard of PyPy, RPython, and Cython. If they were sufficient I probably wouldn't have to look around. These alternate Python projects have made some small gains; but, they still have a long way to go. PyPy is now about double the speed of CPython for most things, and they have set themselves the ambitious target of being faster than C. Let me know when they reach that target. When Java started there was hype that the JIT would be able to run faster then native C because the JIT could optimize at runtime based on the actual data that it encountered. That never really panned out either. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 3:49 am, Octavian Rasnita orasn...@gmail.com wrote: From: Adam Skutt ask...@gmail.com Subject: Re: Tkinter: The good, the bad, and the ugly! On Jan 17, 3:08 pm, Octavian Rasnita orasn...@gmail.com wrote: Batteries included? Python doesn't follow this policy at all. We can say that maybe PHP follows it, but not Python. http://lmgtfy.com/?q=python+%22batteries+included%22l=1 Well, this doesn't mean anything because Perl can also say that includes batteries, and PHP can say it also. It means that Python intentionally endeavorer to include some sort of rich and useful standard library as part of the language, ergo criticisms of the language may include criticisms of its library, like it or not. I'm not sure what makes you believe Perl or PHP are relevant here. You are perfectly right. Then why favor Tkinter and not WxPython. Why not strip the Python package and offer WxPython and Tkinter separately? As of now? There's no reason to remove what's there already as long as carrying it as a dependency isn't creating problems for building and distributing Python. But I already mentioned an important reason earlier: the dependencies of Tk are much, much smaller than the dependencies of WxWidgets (though eventually this may change with the X11 port getting complete). Another is that the scope and scale of WxWidgets is problematic: since it's a cross-platform C++ solution it provides a lot of things that it needs, but that Pyhton doesn't especially need or want. It creates incompatibility issues because you end up with a bunch of libraries that become useless when writing a GUI. This problem is minimized with Tk when compared to WxWidgets, and most other toolkits (certainly all the ones I've ever used). Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, Stefan Behnel stefan...@behnel.de wrote: Tim Harig, 17.01.2011 20:41: One of the arguments for Python has always made is that you can optimize it by writing the most important parts in C. Perhaps that is a crutch that has held the communty back from seeking higher performance solutions in the language itself. The good news with Cython is that you no longer need to write the most important parts in C. Instead, you type them statically and compile them. You don't even need to sacrifice Python source compatibility for that. So you get the best of Python at the speed of C (or 'c', as some would say ;). Well not quite. The fact that you still need a Python interpeter should tell you that the end result is not really just C. Effectively, you get the same thing that you might get from writing C modules for your performance sensitive loops. Cython just makes it a little easier to generate the C modules; but, there is still a lot of Python operating under the hood. I prefer a single language as opposed to a creolization of two. With the possible exception of Lisp, I find it hard to think of a language that's still alive and not the creolisation of (at least) two other languages. They all inherited from each other, sometimes right from the start (lessons learned) and always during their subsequent life time. I am not talking about language influences. Cython effectively requires two separate languages that interoperate. The end result is a mix of two code written in two separate langauges. That is not a single language solution. I certainly don't need to require anybody who wants to use a program I have compiled to install an interpreter. You will be happy to hear that you can link Cython programs against libpython (even statically) to build an executable that embeds the interpreter for you. Besides, on most operating systems, installing a Which means that you effectively end up with a py2exe style frozen binary. While that is a nice hack for solving some problems, it is hardly an elegant solution. It still effectively means that I have to package a redundant Python installation with every binary that I distribute. I just don't have to write installation routines that check for, and potentially install, a compatable version of Python. interpreter for you. Besides, on most operating systems, installing a dependency is done automatically, and Go code doesn't run natively on Windows either, without first installing and running the compiler over it. Go works like C. If I compile my code on Windows, then I can give the binary to another Windows user and they can execute it without having to install any additional software (gcgo currently compiles everything using static binaries. Since the linker only includes the fuctions you actually use, you don't end up with the bloat of embedding entire libraries. I am not sure about gccgo.). The same holds true for Linux, BSD, OS X, and any other supported OS. Every go program includes a runtime componet that provides the garbage collection; but, all of that is included as 100% processor native code. That is quite a bit different from having to include an interpreter to run non-native code. -- http://mail.python.org/mailman/listinfo/python-list
THE TRUTH TO MAKING $13,693.94 IN 48 HOURS
THE TRUTH TO MAKING $13,693.94 IN 48 HOURS You need to go and check this out right now! = https://secure.aischeckout.com/t/qraiI/nyPHA/subaffiliate It's an underground method to start making CRAZY cash by this time tomorrow! This method is responsible for making $112,075.22 just last month and has the guru's running scared! It even made $13,693.94 in just 48 hours! Forget everything you've been taught in the past and listen up. Go to this page NOW and learn how you can steal this exact $4.1 million business for yourself: = https://secure.aischeckout.com/t/qraiI/nyPHA/subaffiliate -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Mon, 17 Jan 2011 21:20:48 -0800 (PST)
Raymond Hettinger pyt...@rcn.com wrote:
On Jan 17, 6:51 pm, nn prueba...@latinmail.com wrote:
...But the api on this baffles me a bit:
d = OrderedDict.fromkeys('abcde')
d.move_to_end('b', last=False)
''.join(d.keys)
'bacde'
I understand that end could potentially mean either end, but would
move_to_end and move_to_beginning not have been clearer?
The default (and normal usage) is to move an item to the last
position.
So, od.move_to_end(k) becomes a fast equivalent to v=d.pop(k)
followed by d[k]=v.
The less common usage of moving to the beginning is done with
last=False. This parallels the existing API for od.popitem():
Well I have to agree that moving to the beginning using move_to_end()
with a last argument looks completely bizarre and unexpected.
Parallels popitem() is not really convincing since popitem() doesn't
have end its name.
Those were the design considerations. Sorry you didn't like the
result.
Design considerations? Where were they discussed?
Regards
Antoine.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
Terry Reedy schrieb: On 1/16/2011 11:20 PM, rantingrick wrote: Ok, try this... http://juicereceiver.sourceforge.net/screenshots/index.php http://www.sensi.org/~ak/pyslsk/pyslsk6.png http://www.wxwidgets.org/about/screensh.htm Ok, wxwidgets can look at least as good as tk. Agreed that wxpython might instead link to the excellent wxwidgets page. Well, tosssing screenshots around doesn't prove wether a framwork/toolkit is good or not; It only displays the developers commitment to create a work of art. Lets examine one of your examples: http://juicereceiver.sourceforge.net/screenshots/index.php#mac Overall impression: The software was designed for windows; more or less following the windows hci-guidelines, The windows version is resonable good. About the Aqua screenshots: 1. Negative actions are located on the falling diagonale. 2-3. The select background and foreground inside the multi-column listbox have the wrong color--the used color originates from text fields. 4. The multi-column listbox should have vertical gridlines. 5-6. Too much top and bottom padding inside the column header. 7. The column texture is wrong --there is a visible line in the bottom. 8. There are white boxess around the input fields. 9. Header column label and lisstbox content are not aligned. 10. There is separator line between the status bar and the brusshed dialog. 11. Last picture: there is a single page inside the tabet control. 12. Last picture: The text Select radio ... is trucated, the dialog isn't large enough. 13. The Scheduler activation should come before customizing the scheduler. 14. The dialog uses sunken group boxes for some sections, these group should be 2% darker than their surrounding container. 15. The spacing rules from the aqua hci guidlines are violated. The inner tabset should have 20px distance from both sides, 20px from the bottom, 14px from top. 16. Second last picture: The button lables are truncated. 17. Tree: Uses the wrong folder symbols--from windows--, select background and foreground are wrong, too. - The Aqua hci-guidlines discourage group boxes, the same with the windows guidlines, too. Get rid off group boxes. - second last picture: There should be more top padding for the checkbutton inside the white rectangle; best the same as left-padding. - There no focus frames visilbe inside these screenshots, it would be interessting to see how those are realised. - The icon buttons should be brushed, likewise shoud the column header have brushed background. - Aqua hci guidelines: All dialogs should have a centered appearance. Back to rantingrick 21st century toolkit/framwork: Let's have a look at the numbers: Worlwide pc market are 300 Million pcs per year, this number includes desktops(2/3) and servers(1/3). Your gui app is not relevant on servers. Quite a good deal of the remaining pc's are sold in countries with rampant ilict software copies; Since there are no software cost for these copies the people tend to install the big, bloated software pieces from named computer companies --you wont sell linux there, because it is more expensive than an ilict windows+office++. ~ 100 Million potential new desktop users for you. Apple's projection for the ipad in 2011 are 65 Million pieces, iphone and ipod touch will be roughly the same. 130 Million ios pieces. ~ 130 Million new ios users for you. The android market is still unclear, but I do suppose it will rival ios, lets say 100 Million in 2011. ~ 100 Million new android users for you. Microsoft mobile and blueberry are wildcards; no serious forecast is possible for these devices. Lets assume: ~ 50 Million blueberry, windows mobile. Total is: 380 Million potential new user for your application. wxWidgets: 3600 LOC, python: 140 LOC --these are very old numbers, but from the same time period. wxWidgets on desktop, present for windows, Aqua and X11. wxWidgets on ios, possible but unlikely, the thing is way to big for any ios device. wxWidgets on android not realistic. wxWidgets on blueberry not possible. wxWidgets on windows mobile; development is silverlight with .net, so wxWidgets would have to be ported to .net; not realistic. python on desktop, present. python on ios, possible --if not yet present. python on android, present. python on blueberry, possible. python on windows mobile, present--but .net support deprecated by ms. The smartphone and table market has only started, yet. In 2011 the mobile market is already larger than the desktop pc, almost 3 times largerv. The desktop pc market is in decline; there is however a shift toward pc-servers, instead. It is anybodies guess how far the pc-desktop decline will go. Every 21st century toolkit or framework must run on mobile platforms! wxWidgets was written ~1992, it is a copy of mfc, which in turn is a copy of MacApp. MacApp is also OSS, maintained through an industrie consortium. Why do you
Re: Tkinter: The good, the bad, and the ugly!
From: Arndt Roger Schneider arndt.ro...@addcom.de Overall impression: The software was designed for windows; more or less following the windows hci-guidelines, The windows version is resonable good. This is the most important thing, because most users use Windows. Those who have other preferences are not forced to choose Windows, so it's their choice, and if the interface doesn't look so nice, that's it. Back to rantingrick 21st century toolkit/framwork: Let's have a look at the numbers: Worlwide pc market are 300 Million pcs per year, this number includes desktops(2/3) and servers(1/3). Your gui app is not relevant on servers. Quite a good deal of the remaining pc's are sold in countries with rampant ilict software copies; Since there are no software cost for these copies Python is an open source software and the programmers that use Python might also prefer to offer open source software for free so this is not important. And not legal is not a very correct term, because somebody from Iran or North Corea must respect the laws from his/her country and in her/his country some things might not be forbidden by law, so it may be perfectly legal. ~ 100 Million potential new desktop users for you. Apple's projection for the ipad in 2011 are 65 Million pieces, iphone and ipod touch will be roughly the same. 130 Million ios pieces. The android market is still unclear, but I do suppose it will rival ios, lets say 100 Million in 2011. ~ 100 Million new android users for you. Microsoft mobile and blueberry are wildcards; no serious forecast is possible for these devices. Lets assume: ~ 50 Million blueberry, windows mobile. Total is: 380 Million potential new user for your application. wxWidgets: 3600 LOC, python: 140 LOC --these are very old numbers, but from the same time period. This is a bad comparison because the programs targetted to the mobile phones are in most cases very different than the programs that need to be used on the desktop. Do you want to say that WxPython is not good just because it doesn't work well on mobile phones? Those numbers show that only the mobile phones are important, because there are more mobile phones than computers. Well, Python needs a better GUI lib for using them on desktop computers, not on mobile phones. The desktop pc market is in decline; there is however a shift toward pc-servers, instead. What do you mean by declining? Are there fewer desktop PCs today than a year ago? Looking into wxWidgets: Interactivity: keyboard focus, shortcuts, function keys, active foreground, active background are obsolete. hovering tooltips obsolete, status bar to large, obsolete. scrolled dialogs, obsolete. OK, Cancel, Retry, Abort buttons, obsolete, file dialogs obsolete, old style printing obsolete, drag-and-drop obsolete... Who says that they are obsolete? A good GUI interface should offer keyboard accessibility. Otherwise it is broken. Summary wxWidgets: wxWidgets is large scale C++ library from the 20th century, solemnly dedicated toward desktop computers. Yes, Python should promote a good GUI lib for desktop computers, and not a poor GUI lib for desktop computers that might also work on other platforms. wxWidgets is not suitable for a modern type GUI ad thus clearly not the toolkit/framework of the 21st century. Why do you think that everything what's modern is better? Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
Carl Banks wrote: On Jan 17, 10:17 am, jmfauth wxjmfa...@gmail.com wrote: ... If I get (stupidly, I agree) a .pyc file and want to test it. Should I create manually a cache alongside my test.py script? Nope: according to PEP 3147 a standalone *.pyc should not be put in same directory where the source file would have been, not in the __pycache__ directory (it'll be considered stale otherwise). Typo? According to PEP 3147 a standalone *.pyc *should* (not should not) be put in the same directory where the source file would have been. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Tim Harig wrote: You still don't see many companies doing large scale internal development using Python and you definately don't see any doing external developement using a language that gives the customers full access to the source code. What you refered as full access to the source code only goes as far as the license which was imposed by the copyright holders lets it to go. If you distribute the source code along with the binaries but you only license your code if the licencees accept that they may look at the source code but they can't touch it then distributing the source code is essentially meaningless. There is a good reason why open source software is not the same thing as free software. Rui Maciel -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, Rui Maciel rui.mac...@gmail.com wrote: Tim Harig wrote: You still don't see many companies doing large scale internal development using Python and you definately don't see any doing external developement using a language that gives the customers full access to the source code. What you refered as full access to the source code only goes as far as the license which was imposed by the copyright holders lets it to go. If you distribute the source code along with the binaries but you only license your code if the licencees accept that they may look at the source code but they can't touch it then distributing the source code is essentially meaningless. There is a good reason why open source software is not the same thing as free software. That argument is not going to fly with where commericial interests are concerned. The simple fact is that there is legality and then there is reality. People follow licenses like they follow the speed limit: only when they think they might get caught and punished. When people break the licenses, the only recourse is litigation; which is expensive. Even finding and proving license violations is difficult where source is availible. It is therefore in the corporate interest to make breaking licenses as difficult, uneconomical, and tracible as possible; and that is exactly what companies do. Even companies that don't really have any trade secrets to protect are protective about their source keeping it locked out of public view. Access to the source generally means signing an NDA so that if the source is somehow leaked, they know the most likely candidates for the origin [so as not to pun with source] of the leak. Whether or not you actually agree with that economic reality is irrelevant. Those who fund commerical projects do; and, any developement tool which violates the security of the source is going to find itself climbing an uphill battle in trying to gain market penetration with commericial software producers. -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
Peter Otten __pete...@web.de writes:
Carl Banks wrote:
Well the former deletes all the pyc files in the directory tree
whereas the latter only deletes the top level __pycache__, not the
__pycache__ for subpackages. To delete all the __pycache__s you'd
have to do something like this:
file . -name __pycache__ -prune -exec rm -rf {} \;
or, better,
file . -name __pycache__ -prune | xargs rm -rf
Still not anything really difficult. (I don't think a lot of people
know about -prune; it tells find don't recursively descend.)
What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'?
Exec launches a new instance of 'rm' for each found file, while xargs
launches a single instance, and passes the list of found files as arg-
uments.
Probably not a big deal in this case, but if you're passing a long list
of files to a script that has a long startup time, it can make a big
difference.
sherm--
--
Sherm Pendley
http://camelbones.sourceforge.net
Cocoa Developer
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
Octavian Rasnita schrieb: From: Arndt Roger Schneider arndt.ro...@addcom.de At least keep the disclaimer: Well, tosssing screenshots around doesn't prove wether a framwork/toolkit is good or not; It only displays the developers commitment to create a work of art. Overall impression: The software was designed for windows; more or less following the windows hci-guidelines, The windows version is resonable good. This is the most important thing, because most users use Windows. Those who have other preferences are not forced to choose Windows, so it's their choice, and if the interface doesn't look so nice, that's it. See disclaimer. Since you mentioned nice: I do not use such words to charcterize a gui. I think the developers of said software tried hard to make it nice and beauty, hence the brushed background and group-boxes --BTW: the windows Guidelines also discourage using group-boxes for usability reasons (see Theo. Mandel object oriented user interfaces). Back to rantingrick 21st century toolkit/framwork: Let's have a look at the numbers: Worlwide pc market are 300 Million pcs per year, this number includes desktops(2/3) and servers(1/3). Your gui app is not relevant on servers. Quite a good deal of the remaining pc's are sold in countries with rampant ilict software copies; Since there are no software cost for these copies Python is an open source software and the programmers that use Python might also prefer to offer open source software for free so this is not important. And not legal is not a very correct term, because somebody from Iran or North Corea must respect the laws from his/her country and in her/his country some things might not be forbidden by law, so it may be perfectly legal. Nice cropping, the people tend to install the big, bloated software pieces from named computer companies --you wont sell linux there, because it is more expensive than an ilict windows+office++. Illict as in unlicensed. Law has nothing to do with it. And yes these unlicensed sofware has an negative impact on the distribution of free open source software. I wonder, what license do you use in your own work, and what do you think about people which violate your license? ~ 100 Million potential new desktop users for you. Apple's projection for the ipad in 2011 are 65 Million pieces, iphone and ipod touch will be roughly the same. 130 Million ios pieces. The android market is still unclear, but I do suppose it will rival ios, lets say 100 Million in 2011. ~ 100 Million new android users for you. Microsoft mobile and blueberry are wildcards; no serious forecast is possible for these devices. Lets assume: ~ 50 Million blueberry, windows mobile. Total is: 380 Million potential new user for your application. wxWidgets: 3600 LOC, python: 140 LOC --these are very old numbers, but from the same time period. This is a bad comparison because the programs targetted to the mobile phones are in most cases very different than the programs that need to be used on the desktop. This is the marketplace for all gui applications, and not a comparision. Do you want to say that WxPython is not good just because it doesn't work well on mobile phones? I do not comment on the quality of either wxWidgets nor wxPython. Both exist for certain reasons. The desktop pc was the sole target for all the big C++ gui class liraries in 1992. Over time a large code base evolved which makes it very difficult to get these class libraries into new markets--such as today with mobile devices. Those numbers show that only the mobile phones are important, because there are more mobile phones than computers. No, it doesn't. There are billions of mobile phones with graphical user interfaces, still these phones weren't relevant for gui applications. Well, Python needs a better GUI lib for using them on desktop computers, not on mobile phones. wxWidgets is suiteable for the desktop. The desktop pc market is in decline; there is however a shift toward pc-servers, instead. What do you mean by declining? Are there fewer desktop PCs today than a year ago? I am writing about graphical applications not computers. Looking into wxWidgets: Interactivity: keyboard focus, shortcuts, function keys, active foreground, active background are obsolete. hovering tooltips obsolete, status bar to large, obsolete. scrolled dialogs, obsolete. OK, Cancel, Retry, Abort buttons, obsolete, file dialogs obsolete, old style printing obsolete, drag-and-drop obsolete... Who says that they are obsolete? A good GUI interface should offer keyboard accessibility. Otherwise it is broken. OK, I take keyboard focus back. Summary wxWidgets: wxWidgets is large scale C++ library from the 20th century, solemnly dedicated toward desktop computers. Yes, Python should promote a good GUI lib for desktop computers, and not a poor GUI lib for desktop computers that might also work on other
Re: Efficient python 2-d arrays?
On 1/17/11 7:32 PM, Jake Biesinger wrote: On Monday, January 17, 2011 4:12:51 PM UTC-8, OAN wrote: Hi, what about pytables? It's built for big data collections and it doesn't clog up the memory. I thought PyTables depends on NumPy? It does. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 18, 6:46 am, Antoine Pitrou solip...@pitrou.net wrote: Design considerations? Where were they discussed? They were never discussed with the bulk of this community and that is part of what i want to change. We have a very small group of folks making all the decisions and that is fine. However this small group of privileged folks needs to gather input from the rest of us (peasants) on the value of such changes before making rash decisions. Currently we have a closed set of intellectual inbreeding that is rotting the community gene pool. We need more diversity in this milkshake to bring about and foster healthy ideas. No wonder we get these brain childs (farts) with inherited diseases from birth. -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
Stefan Behnel wrote: Peter Otten, 18.01.2011 10:04: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? The former runs in parallel, the latter runs sequentially. This may sometimes be relevant, but I doubt that it matters in this particular case. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
Sherm Pendley wrote:
Peter Otten __pete...@web.de writes:
Carl Banks wrote:
Well the former deletes all the pyc files in the directory tree
whereas the latter only deletes the top level __pycache__, not the
__pycache__ for subpackages. To delete all the __pycache__s you'd
have to do something like this:
file . -name __pycache__ -prune -exec rm -rf {} \;
or, better,
file . -name __pycache__ -prune | xargs rm -rf
Still not anything really difficult. (I don't think a lot of people
know about -prune; it tells find don't recursively descend.)
What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'?
Exec launches a new instance of 'rm' for each found file, while xargs
launches a single instance, and passes the list of found files as arg-
uments.
Probably not a big deal in this case, but if you're passing a long list
of files to a script that has a long startup time, it can make a big
difference.
You can avoid that:
$ touch {1..10}.txt
$ find . -exec python -c'import sys; print sys.argv' {} \;
['-c', '.']
['-c', './10.txt']
['-c', './1.txt']
['-c', './7.txt']
['-c', './8.txt']
['-c', './4.txt']
['-c', './6.txt']
['-c', './3.txt']
['-c', './5.txt']
['-c', './9.txt']
['-c', './2.txt']
$ find . -exec python -c'import sys; print sys.argv' {} \+
['-c', '.', './10.txt', './1.txt', './7.txt', './8.txt', './4.txt',
'./6.txt', './3.txt', './5.txt', './9.txt', './2.txt']
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On 18/01/2011 16:27, rantingrick wrote: On Jan 18, 6:46 am, Antoine Pitrousolip...@pitrou.net wrote: Design considerations? Where were they discussed? They were never discussed with the bulk of this community and that is part of what i want to change. We have a very small group of folks making all the decisions and that is fine. However this small group of privileged folks needs to gather input from the rest of us (peasants) on the value of such changes before making rash decisions. Currently we have a closed set of intellectual inbreeding that is rotting the community gene pool. We need more diversity in this milkshake to bring about and foster healthy ideas. No wonder we get these brain childs (farts) with inherited diseases from birth. Decisions are made after open discussion (although we're not sure about move to end :-)). You shouldn't complain about not being consulted if you don't take the time to join in... -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 7:09 am, Arndt Roger Schneider arndt.ro...@addcom.de wrote: Summary wxWidgets: wxWidgets is large scale C++ library from the 20th century, solemnly dedicated toward desktop computers. wxWidgets originates from a time before templates were used in C++ and thus duplicates many of today's C++ features. wxWidgets is not suitable for a modern type GUI ad thus clearly not the toolkit/framework of the 21st century. Alight i'll except that Rodger. Wx may be unusable for the mobile market. And since the mobile market is exploding --and will continue to explode-- then we need to consider this. However, does any GUI library exist that can handle desktop, mobile, and accessibility and do it all in a 21st century way? You slaughtered wx but failed to provide any alternative, however i am listing to your advice contently because it is very good advice. Read on... We DO need to consider the mobile market in this decision. Maybe it is time for us to actually get on the cutting edge of GUI's. Maybe we should head an effort to create a REAL 21st century GUI that can handle desktop, mobile, and accessibility, and do it all whilst looking very sharp! Sure we rob from peter to pay paul. We will use Tkinters awesome API and geometry managers, wxPythons feature richness, and any other code we can steal to make this work! Then we can advertise python as the best GUI language available. I have nothing against seeing Python on more devices and this would no doubt bring that dream into fruition. There is a huge hole in the market at this very moment and we need to pounce on it like a hungry tiger on wildebeest. Just think how wonderful it would be to switch from mobile to desktop and still write beatiful Python code. -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 18, 10:54 am, MRAB pyt...@mrabarnett.plus.com wrote: Decisions are made after open discussion (although we're not sure about move to end :-)). You shouldn't complain about not being consulted if you don't take the time to join in... Well don't get wrong i want to join in --not that i have all the solutions-- however python-dev is a dangerous place for the uninitiated. And we can't have thousands and thousands of posts clogging up the main pool because that would only serve to slow the process to a grinding hault. However, we need some way that the average Python programmer can speak up and be heard when any subject that he/she is passionate about comes before the council. These folks probably don't want to participate in the highly competitive environment of Python dev. However they may have very good ideas. I think we are doing this community a dis service by not giving these voices an outlet. We need either some way to vote outside of Python dev. i think it would be much easier to just have a site where all proposals can be viewed by anyone and they can offer input without clogging up Python dev with noob questions or bad ideas. Then the council can review these suggestions and make a more informed decision. Some might say well that is what blogs and c.l.py is for and i say wrong. I believe more folks would get involved if they felt that the medium was real. c.l.py is not that place (although it could be with some changes) and python.dev is not that place. I am open to any ideas you may have. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python unicode utf-8 characters and MySQL unicode utf-8 characters
2011/1/18 Grzegorz Śliwiński sliwin...@red-sky.pl: Hello, Recently I tried to insert some unicode object in utf-8 encoding into MySQL using MySQLdb, and got MySQL warnings on characters like: βΠΥΠ i found somewhere in my data. I can't even read them. MySQL seems to cut the whole string after that characters off, so I get incomplete data. After a little bit of digging I found out, that MySQL usually supports utf-8 data but encoded into maximum three bytes. That's why I think it would help I f I was able to replace all larger unicode characters with replacement characters. Is there any way, I could adjust python unicode utf-8 encoded strings to be accepted by mysql utf-8 columns? Did you pass the charset argument when creating your MySQLdb connection? -- regards, kushal -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Tue, 18 Jan 2011 09:10:48 -0800 (PST) rantingrick rantingr...@gmail.com wrote: Well don't get wrong i want to join in --not that i have all the solutions-- Take a look at http://docs.python.org/devguide/#contributing -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Mon, Jan 17, 2011 at 4:02 PM, Tim Harig user...@ilthio.net wrote:
Go is not an ideal language for high-performance code. Despite the
occasional claims of others, Go is consistently outperformed by C,
C++, and Java on a wide variety of benchmarks. Some claim that Ada and
Haskell do as well, and my benchmarks (CPU bound, focused on speed of
I much agree that Go doesn't beat C or C++. I really doubt that it could
with the runtime necessary to do garbage collction. Nevertheless, I find
that Go can be optimized to perform within tolerable limits of C given the
boost it gives in development.
The question isn't whether you will use it; right or wrong, it seems
certain that you will. The question is whether it will see significant
uptake, and this is a big barrier for many.
I really question that you get Java anywhere even close to C performance.
Google reports they get within the same order of magnitude as C for
their long-lived server processes where the JIT has had time to optimize
its results. For shorter term processes such as desktop applications,
Java performance stinks -- even after you discount the JVM starup time.
I'm sorry, but you're wrong on this. Java's performance can be
excellent, particularly when it comes to mathematical functions. I
recall reading a pretty smug paper a few years ago describing how they
managed to beat C on a number of numerical benchmarks.
Ada is capable of C++ like performance *if* you compile it to remove *all*
of runtime checking. Depending what checks you enable, it can run much
slower.
No idea, never used it.
in line with the work of others. You can argue that it's good enough-
it is, for most cases- but taking a 20% performance hit rules it out
of a lot of systems work, and the C-Go gap in many cases is much
larger than that.
I don't work anything that involves and absolute need for performance.
Then don't argue about performance, it makes you look like a hack just
eager to shill for your language.
I could probably accept penalty several times that of C for higher
level functionality; but, sometimes the penalty for Python is just
too much. Many of my programs are very quick lived such that even
loading an interpeter or VM can eclipse the actual runtime. Given less
developmental effort required, I also find that I have more time to look
for ways to optimize Go. There are many things (such as using alternate
data structures rather then the build in slices and immutable strings)
that can be used to accelerate Go when time permits and I suspect many
more will be found as the language matures.
This is inconsistent with your argument about PyPy. See my earlier comment.
Go is also not an ideal language for enterprise development. It
provides no compatibility or support guarantees; in fact, the website
describes it as 'an experiment' and recommends it for 'adventurous
There is no doubt that it is a young project and there are a number of
things that will need to be improved to be effective for some branches
of programming; but, that isn't a language restriction.
It will nevertheless preclude its use in most enterprise software
development. That's most systems software.
Frankly, I am
rather impressed by the sheer number of third party packages that have
already become available. No go isn't going to replace some of the other
top mainstream langauges today; but, I can easily see it starting to see
some market penetration 5 years from now.
I suppose that for some small value of market penetration ('mom uses
it!') you're right. I don't see any evidence of major movement at this
moment though.
users'. There are no independent experts in case something goes wrong,
and if it goes belly up a year from now you will have a one year old
piece of legacy infrastructure on your hands. Maybe you don't think
that this will be the case; in any event, I would not want to try
convincing a CFO of that.
If I was trying to convince a CFO, I would ask if he really thought Google
was likely to simply drop the time and effort that Google has already
placed into the infrastructure.
Hahahaha. You mean like wave?
Furthermore, few dying languages already
have not one, but two, open source compilers available for use.
Two compilers by the same people. Not two active projects. Big difference.
Database bindings are another weak link outside of the more common
open source databases. In both cases, Go readily capable of C library
functions as a stop-gap until a native wrapper is available. Yes it will
be nice once community has filled in the gaps; but, I am rather impressed
at what is already available in less then a years time. There are a few
libraries you may have missed here:
Sounds like a two-language solution, ie, the thing you criticized Python for.
I will point out that Go's libraries are miles ahead of the standard C
library and other minimalistic standard libraries. Many things are
possible with even the
RE: newby qn about functions
I'm not sure I understand the question completely but maybe the function below does what you want. def lower_case(s): return Testing Functions-lower case: + s.lower() print lower_case(AbCdEfG) From: python-list-bounces+joe=goldthwaites@python.org [mailto:python-list-bounces+joe=goldthwaites@python.org] On Behalf Of Cathy James Sent: Tuesday, January 18, 2011 3:02 AM To: python-list@python.org Subject: newby qn about functions #This has to be very simple, but I don't get it-please help def lower_case(s): #return s print(s) #return s.lower() print(s.lower()) s= Testing Functions-lower case: lower_case(s) how can i use a return statement to write a function that returns the string Testing Functions-lower case: and the lowercase representation of its string parameter If I uncomment the above, nothing outputs to console:( Much appreciation as always. -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On Jan 17, 2:19 pm, carlo syseng...@gmail.com wrote: Hi, recently I had to study *seriously* Unicode and encodings for one project in Python but I left with a couple of doubts arised after reading the unicode chapter of Dive into Python 3 book by Mark Pilgrim. 1- Mark says: Also (and you’ll have to trust me on this, because I’m not going to show you the math), due to the exact nature of the bit twiddling, there are no byte-ordering issues. A document encoded in UTF-8 uses the exact same stream of bytes on any computer. . . . 2- If that were true, can you point me to some documentation about the math that, as Mark says, demonstrates this? I believe Mark was referring to the bit-twiddling described in the Design section at http://en.wikipedia.org/wiki/UTF-8 . Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 1/18/2011 10:30 AM, Tim Harig wrote: Whether or not you actually agree with that economic reality is irrelevant. Those who fund commerical projects do; and, any developement tool which violates the security of the source is going to find itself climbing an uphill battle in trying to gain market penetration with commericial software producers. Of course. When I submit or commit patches, I am doing it mostly for hobby, educational, and scientific users, and maybe website makers (who make site I can visit). If commercial users piggyback on top, ok. I do not know how many developers, if any, are after such market penetration. Shedskin compiles a slowly growing subset of Python to native code. But I do not know that it has gotten any commercial support. Maybe Mark should sell it instead of giving it away for commercial use (if he does now). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
rantingrick schrieb: On Jan 18, 7:09 am, Arndt Roger Schneider arndt.ro...@addcom.de wrote: Summary wxWidgets: wxWidgets is large scale C++ library from the 20th century, solemnly dedicated toward desktop computers. wxWidgets originates from a time before templates were used in C++ and thus duplicates many of today's C++ features. wxWidgets is not suitable for a modern type GUI ad thus clearly not the toolkit/framework of the 21st century. Alight i'll except that Rodger. Wx may be unusable for the mobile market. And since the mobile market is exploding --and will continue to explode-- then we need to consider this. However, does any GUI library exist that can handle desktop, mobile, and accessibility and do it all in a 21st century way? You slaughtered wx but failed to provide any alternative, however i am listing to your advice contently because it is very good advice. Read on... Thanks! Again this is not about the quality of wxWidgets, wxWidgets grew large because there was vested interest in it. Its success is its undoing. We DO need to consider the mobile market in this decision. Maybe it is time for us to actually get on the cutting edge of GUI's. Maybe we should head an effort to create a REAL 21st century GUI that can handle desktop, mobile, and accessibility, and do it all whilst looking very sharp! Sure we rob from peter to pay paul. We will use Tkinters awesome API and geometry managers, wxPythons feature richness, and any other code we can steal to make this work! I am not sure whether this sarcasms or for real..., so I'll take for genuine. Tk is also doomed, and Tkinter isn't Tk. You are right about keeping the separate geometry managers, though. For starters: http://kenai.com/projects/swank Swank publishes java/swing classes as tk in jtcl, which is similar to what tkinter does for python and tk. It should be feasible to use swank with the tkinter interface for jpython--without jtcl. However, this doesn't make tkinter mobile, neither is swing available on android. When you look into the android developer documents concerning the gui, then you can see that the gui model is quite similar to tk. So I suppose android can be reached by jpython in a two stage process. The other devices are more difficult to reach, though. There is webkit on some, but not all. Webkit is available for the desktop, ios and android--today without svg. There are two ways to gain graphical independence: First a basic implementation for each platform and second through abstraction. With abstraction I mean to base the gui on a common graphical model present on all platforms and hence to implement the toolkit on-top of it in python (not C, C++, java,javascript), python! The single common graphical model is SVG. Then we can advertise python as the best GUI language available. I have nothing against seeing Python on more devices and this would no doubt bring that dream into fruition. There is a huge hole in the market at this very moment and we need to pounce on it like a hungry tiger on wildebeest. Just think how wonderful it would be to switch from mobile to desktop and still write beatiful Python code. So be it. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 8:09 am, Arndt Roger Schneider arndt.ro...@addcom.de wrote: Back to rantingrick 21st century toolkit/framwork: Let's have a look at the numbers: Worlwide pc market are 300 Million pcs per year, this number includes desktops(2/3) and servers(1/3). Your gui app is not relevant on servers. You should tell this fact to just about every major enterprise software manufacturer out there. They all ship GUI tools intended to be used on the server. Some of them ship only GUI tools or CLI tools that are worthless, making you use the GUI tools. The desktop pc market is in decline; there is however a shift toward pc-servers, instead. It is anybodies guess how far the pc-desktop decline will go. Every 21st century toolkit or framework must run on mobile platforms! Until we have pixel-perfect touch sensors, toolkits for devices with pointer interfaces (e.g., PCs) and toolkits for devices with touch interfaces (e.g., phones and tablets) will necessarily be different. You note this yourself: the UI paradigms that work well when you have a pixel-perfect pointer do not work at all when you have a touch screen, especially on a limited size and resolution display. Even if you're provided a single toolkit, you still end up with two, maybe three, different applications, each using different widgets targeted for the device they run on. And no one provides a single toolkit: while Silverlight can run on the desktop, the web, and now on Windows Phone, you can't use the same widgets everywhere; ditto with Cocoa for OS X and Cocoa Touch for iTouch devices. While some further unification is obviously possible, it's rather doubtful we'll ever have unified widgets that are truly workable on the web, on the desktop, and on a portable touch screen device. wxWidgets was written ~1992, it is a copy of mfc, which in turn is a copy of MacApp. MacApp is also OSS, maintained through an industrie consortium. Why do you not use the original framework? Because it's not cross-platform, I'd imagine. The entire point of wxWidgets was to provide a cross-platform OOP UI toolkit. It closely copies MFC since MFC and XView were the two backends it supported. Screen resolution: The time of 72ppi CRT monitors is over. A GUI framework/toolkit must be resolution independent, including all icons and indicators; it should use decluttering (newspeak:ZUI). WPF is the only functional resolution-independent UI toolkit in existence. While I don't disagree with you in principal, practice is pretty heavily divorced from principal here. Principal doesn't help me write GUI applications today. wxWidgets is not suitable for a modern type GUI ad thus clearly not the toolkit/framework of the 21st century. None of the toolkits accessible from CPython are suitable for a 21st century guy by your standard. If we talk about IronPython, Silverlight becomes the closest, but it isn't a panacea by any stretch of the imagination. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 18.01.2011 09:58, Octavian Rasnita wrote: From: Alexander Kapps alex.ka...@web.de On 17.01.2011 21:04, Octavian Rasnita wrote: I say probably not considering the availability of 3rd party downloads. What say you, Python community? Available as 3rd party downloads: XML,HTML,... HTTP,FTP,SMTP,POP,IMAP/... MD5,SHA,... zip,bzip,... and so on and so on and so on. Remove them all just because they are available as 3rd party downloads? No, they should not be removed because they don't cause any damage, very bad damage as Tkinter does. Tkinter causes damage? Very bad damage? What are you talking about? The Batteries included of Python is just *great* and I vote for *more* not less batteries! Well, in that case, why don't you agree to also include WxPython in the Python package? Well, I don't like wx that much and others have already highlighted some of the problems with it. I think that adding redundancy is bad and I really want a GUI toolkit that makes it easy to quickly write a simple GUI, so I do not want wx to replace Tkinter. But yes, I wouldn't mind the inclusion of a large GUI package. And one more thing. Not all the Python programmers create desktop apps so a GUI lib is useless. Some of them use Python only for web programming or only for system administration. Not all Python programmers do web programming, so please remove the useless HTML junk too. Why do you call it html junk? You said a GUI lib is useless because not all programmers write GUIs. so I say an HTML lib is useless because not all programmers write web stuff. Got it? Both are useful and I'm absolutely against any attempt to remove either from the stdlib. *That* would cause damage. Almost every beginner wants to do GUIs or at least some graphic stuff. Removing the GUI module from the stdlib would be plain wrong IMHO. But I don't understand the whole issue anyway. It isn't that you need to fire up your torrent client and wait 48 hours for the Python download to complete. Why remove useful (to many, not most) stuff from the lib? Yes it can be useful for some people, but why promote it instead of promoting a better library for beginners? Which one? That's the whole point. There currently is no better GUI lib than Tkinter which allows quick and easy GUI programming and still has a large widget set, is pythonic and so on. PyGUI might be in the future. If you care that much go on and help making it happen. I have absolutely no problem with a better GUI lib, I just don't care much and those who seem to care enough to start a war over and over again seem to be unwilling to really do anything. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 18, 11:56 am, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 18 Jan 2011 09:10:48 -0800 (PST) rantingrick rantingr...@gmail.com wrote: Well don't get wrong i want to join in --not that i have all the solutions-- Take a look athttp://docs.python.org/devguide/#contributing Thanks for this link Antoine however i think you missed the point of my post. What i would like to see is an forum where the noob to average python programmer can voice his/her opinion about the current state or future state of Pythons syntax, stdlib, goals and dreams, etc, al the while not fearing attack from all sides. Currently such a place is non-existent. I believe many folks would get involved if this place existed however it does not exist. I also believe that these same folks have no interest in debating in the highly competitive environmental of python-dev, python-ideas. Heck, even c.l.py is far too competitive! They just basically want a forum were they can come in and give their two cents and leave. comp.lang.py would be a good place for this to happen since after all Usenet was created for like-minded people to collaborate in lively discussion. However c.l.py has a problem with criminals. We need to bring these predators, bullies, and brow beaters under control. I have seen many new voices come in and then get crucified by these scoundrels causing them to quickly tuck tail and run for cover --never to return again-- and nobody says a word And anyone who dares to speak out is threatened with the kill-file. This group has been handed over to the criminals who's only concern is chaos and anarchy all the while making sure that they control the speech and content herein. Now don't get me wrong we have a lot of good people here but they are too fearful to speak up. Sadly these folks don't realize that by staying quiet they only embolden the criminals to do more dastardly deeds. These criminals are cowards by nature, and when presented with a united front they will themselves tuck tail and run for the hills never to return. I am not saying we cannot have lively discussion, or even use the occasional sarcastic quip. No, what i am saying is that we need hear all sides of the argument. Remember this is a community of many different people wanting many different things. We must be willing to first listen, and then compromise on all sides -- if we want to move forward. Ask not... What is best for me? Instead ask yourself... What is best for the entire community? So the moral is... either we need to take back c.l.py (by force if needed!) or we need to abandon c.l.py and open a more friendly environment for Python discussions. Either way if this forum is not taken seriously by the elite then it will be yet another catastrophic failure! -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 18, 12:20 am, Raymond Hettinger pyt...@rcn.com wrote:
On Jan 17, 6:51 pm, nn prueba...@latinmail.com wrote:
...But the api on this baffles me a bit:
d = OrderedDict.fromkeys('abcde')
d.move_to_end('b', last=False)
''.join(d.keys)
'bacde'
I understand that end could potentially mean either end, but would
move_to_end and move_to_beginning not have been clearer?
The default (and normal usage) is to move an item to the last
position.
So, od.move_to_end(k) becomes a fast equivalent to v=d.pop(k)
followed by d[k]=v.
The less common usage of moving to the beginning is done with
last=False. This parallels the existing API for od.popitem():
od = OrderedDict.fromkeys('abcdefghi')
od.move_to_end('c') # default case: move to last
od.popitem() # default case: pop from last
('c', None)
od.move_to_end('d', last=False) # other case: move to first
od.popitem(last=False) # other case: pop from first
('d', None)
The existing list.pop() API is similar (though it takes an index
value instead of a boolean):
mylist.pop() # default case: pop from last
mylist.pop(0) # other case: pop from first
Those were the design considerations. Sorry you didn't like the
result.
Raymond
Ah that is where it came from! I didn't remember popitem used that API
too. If you use them together it has a nice symmetry. I guess it is
just that end is more confusing than pop in that context.
Considering the precedence of popitem I withdraw my objection. I still
think it looks a bit odd but it is not unreasonable either. Sometimes
ugly consistency trumps beautiful inconsistency; c'est la vie...
--
http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On 1/18/2011 9:10 AM rantingrick said... On Jan 18, 10:54 am, MRABpyt...@mrabarnett.plus.com wrote: Decisions are made after open discussion (although we're not sure about move to end :-)). You shouldn't complain about not being consulted if you don't take the time to join in... Well don't get wrong i want to join in --not that i have all the solutions-- however python-dev is a dangerous place for the uninitiated. And we can't have thousands and thousands of posts clogging up the main pool because that would only serve to slow the process to a grinding hault. However, we need some way that the average Python programmer can speak up and be heard when any subject that he/she is passionate about comes before the council. These folks probably don't want to participate in the highly competitive environment of Python dev. However they may have very good ideas. I think we are doing this community a dis service by not giving these voices an outlet. We need either some way to vote outside of Python dev. i think it would be much easier to just have a site where all proposals can be viewed by anyone and they can offer input without clogging up Python dev with noob questions or bad ideas. Then the council can review these suggestions and make a more informed decision. Some might say well that is what blogs and c.l.py is for and i say wrong. I believe more folks would get involved if they felt that the medium was real. c.l.py is not that place (although it could be with some changes) and python.dev is not that place. I am open to any ideas you may have. Brett Cannon used to (still does?) prepare twice monthly summaries of activity on python-dev which provided insight as to what was happening on that side of things. I don't know if he or anyone else still does so, but if so, a copy to this list would at least let everyone know if something was happening that you might want to weigh in on. see http://article.gmane.org/gmane.comp.python.devel/43893 Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 12:25 pm, Arndt Roger Schneider arndt.ro...@addcom.de wrote: rantingrick schrieb: On Jan 18, 7:09 am, Arndt Roger Schneider arndt.ro...@addcom.de We DO need to consider the mobile market in this decision. Maybe it is time for us to actually get on the cutting edge of GUI's. Maybe we should head an effort to create a REAL 21st century GUI that can handle desktop, mobile, and accessibility, and do it all whilst looking very sharp! Sure we rob from peter to pay paul. We will use Tkinters awesome API and geometry managers, wxPythons feature richness, and any other code we can steal to make this work! I am not sure whether this sarcasms or for real..., so I'll take for genuine. No this is real, albeit a bit fantastical. Thats probably why you thought it was sarcasm :). However, we need to start a revolution in the GUI world. Currently we (as developers) are slaves to the OEM's and OS's. This must change. We must unify GUI coding the same way OpenGL unified graphics coding. Multiplicity is ruining any and all advancements in Graphical User Interfaces. Sure multiplicity is great in emerging systems (language, culture, GUI, etc, etc) However at some point you must reign in this multiplicity and harness the collective knowledge into an all encompassing standard. OpenGUI is that standard. It should be shipped with every OS in the world. This is the only way we can have mobile, desktop, and accessibility all combined into one beautiful package. Then the contest come down to who can create the best abstraction API. Tk is also doomed, and Tkinter isn't Tk. You are right about keeping the separate geometry managers, though. For starters:http://kenai.com/projects/swank This looks like a very young project (beta) and i could not find a widget set. However i will investigate more. Thanks However we need to think beyond even a Python community scale. This problem is inherent in every language community out there. We to unify the GUI standard. And we are a decade behind in development. (yes i am completely serious about all of this!). -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, geremy condra debat...@gmail.com wrote: On Mon, Jan 17, 2011 at 4:02 PM, Tim Harig user...@ilthio.net wrote: I really question that you get Java anywhere even close to C performance. Google reports they get within the same order of magnitude as C for their long-lived server processes where the JIT has had time to optimize its results. For shorter term processes such as desktop applications, Java performance stinks -- even after you discount the JVM starup time. I'm sorry, but you're wrong on this. Java's performance can be excellent, particularly when it comes to mathematical functions. I recall reading a pretty smug paper a few years ago describing how they managed to beat C on a number of numerical benchmarks. I have no doubt that Java *can* occasionally beat *some* C for *some* benchmarks; but, overall, Java has a terrible reputation for performance. I worked with a company a few years ago that tried replacing a C VNC client with a Java one so that its technical support contractor's wouldn't need to have the VNC client installed on the agent's workstations. Several of the contracters had to upgrade their systems in order to use the Java version because it slowed down the machines so much that the agents could not perform their jobs effectively; and that is pretty typical from what I have seen with Java overall. Java performs very well with some select tasks. For others, it does exceedingly poor. That kind of hit or miss is pretty typical for JIT compilers in general. That isn't usually the case for fully compiled langauges where you are pretty much guaranteed to get decent, if not always the absolute top, performance. Ada is capable of C++ like performance *if* you compile it to remove *all* of runtime checking. Depending what checks you enable, it can run much slower. No idea, never used it. in line with the work of others. You can argue that it's good enough- it is, for most cases- but taking a 20% performance hit rules it out of a lot of systems work, and the C-Go gap in many cases is much larger than that. I don't work anything that involves and absolute need for performance. Then don't argue about performance, it makes you look like a hack just eager to shill for your language. What you don't seem to realize is there is often a performance level that is good enough. For many things, Python is good enough. Many others, where Python is insufficient, may still be acceptable to use Java. Some things require the absolute best performance and will probably always need C/C++ or equivilantly low level language. I could probably accept penalty several times that of C for higher level functionality; but, sometimes the penalty for Python is just too much. Many of my programs are very quick lived such that even loading an interpeter or VM can eclipse the actual runtime. Given less developmental effort required, I also find that I have more time to look for ways to optimize Go. There are many things (such as using alternate data structures rather then the build in slices and immutable strings) that can be used to accelerate Go when time permits and I suspect many more will be found as the language matures. This is inconsistent with your argument about PyPy. See my earlier comment. I can accept 2 to 3 times the overall performance of C for almost all of the problems that I deal with. When that multiple gets into the double digits, it can start to cause some real headaches for some problems. When that number reaches the upper double digits, it is acceptable for even fewer problems. Python is great for those problems where performance isn't critical and I make extensive use of it. Different methods of mixing Python and C (including manual, PyPy, SWIG, boost, etc) can extend Python's useful range; but, I have not seen the kind of speed improvements that bring it to less then an order of magnitude of C's speed overall. Even assuming that PyPy does actually manage to reach within a magnitude of C with the extra effort required to leverage two languages, why would I bother when I can do it with one? PyPy and similar methods where great when there was no other mid level alternative that supported Python like features. Now it just seems like using Python as a hammer for every problem whether or not it is the right tool for the job. Go is also not an ideal language for enterprise development. It provides no compatibility or support guarantees; in fact, the website describes it as 'an experiment' and recommends it for 'adventurous There is no doubt that it is a young project and there are a number of things that will need to be improved to be effective for some branches of programming; but, that isn't a language restriction. It will nevertheless preclude its use in most enterprise software development. That's most systems software. So you conclude that because it is not quite ready for prime time yet that it never will be? I can
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 12:29 pm, Adam Skutt ask...@gmail.com wrote: Until we have pixel-perfect touch sensors, toolkits for devices with pointer interfaces (e.g., PCs) and toolkits for devices with touch interfaces (e.g., phones and tablets) will necessarily be different. You note this yourself: the UI paradigms that work well when you have a pixel-perfect pointer do not work at all when you have a touch screen, especially on a limited size and resolution display. Even if you're provided a single toolkit, you still end up with two, maybe three, different applications, each using different widgets targeted for the device they run on. And no one provides a single toolkit: while Silverlight can run on the desktop, the web, and now on Windows Phone, you can't use the same widgets everywhere; ditto with Cocoa for OS X and Cocoa Touch for iTouch devices. While some further unification is obviously possible, it's rather doubtful we'll ever have unified widgets that are truly workable on the web, on the desktop, and on a portable touch screen device. Adam now you are making sense. Everything you said here is true. This is why we must push for the OpenGUI standard. The entropy in GUIs has exploded exponentially and rendered them all useless. We must unify the collective knowledge base into a single system and shake up the GUI world from top to bottom. Any other effort is just wasted energy. Forget WxPython, Forget WxWidgets, Forget any and all GUI libraries that exists, they are all moot at this point and we are -years- DECADES behind in development and integration. See my reply to Rodger for more detail.. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
If you think the site is bad, send me a ONE better screenshot, or link thereto, of wx on WinXP/Vista/7. I promise to look at it. Then urge Robin to update the page. No wxWidgets, but real Python / wxPython applications, all updated on Windows 7. http://spinecho.ze.cx/ -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Tue, Jan 18, 2011 at 12:33, rantingrick rantingr...@gmail.com wrote: On Jan 18, 11:56 am, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 18 Jan 2011 09:10:48 -0800 (PST) rantingrick rantingr...@gmail.com wrote: Well don't get wrong i want to join in --not that i have all the solutions-- Take a look athttp://docs.python.org/devguide/#contributing Thanks for this link Antoine however i think you missed the point of my post. What i would like to see is an forum where the noob to average python programmer can voice his/her opinion about the current state or future state of Pythons syntax, stdlib, goals and dreams, etc, al the while not fearing attack from all sides. Currently such a place is non-existent. I believe many folks would get involved if this place existed however it does not exist. I'm unaware of attack from all sides on python-dev, but the standards are high, as they should be. The discussion is open to everyone, but it's not generally about opinions, goals, dreams, etc. -- it's mostly about getting work done. python-ideas might be a list that would work for what you are looking for. It's a list of possible ideas to implement in Python. Some are half-baked ideas needing community help and input, some are fully thought out implementations asking if the community thinks it's worthy of inclusion. I'm not sure why this list, python-list, isn't a good venue for any of that. A lot of the people who follow python-dev also follow this list, e.g., Raymond and Antoine who already commented on this. I also believe that these same folks have no interest in debating in the highly competitive environmental of python-dev, python-ideas. Heck, even c.l.py is far too competitive! They just basically want a forum were they can come in and give their two cents and leave. Sorry, it's not that easy, for good reason. We're talking about a programming language that has been around for quite a while, is used in many places for many reasons by many people, and the numbers surrounding just about every category are always rising. We're also talking about a group of volunteers who spend their time working on Python. Drive-by commenting likely serves little purpose other than noise. If you want to bring something up, by all means bring it up, but you will probably have to fight for it. We can't just have everyone throw two cent suggestions in a hat and move along. -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Tue, 18 Jan 2011 10:33:45 -0800 (PST) rantingrick rantingr...@gmail.com wrote: On Jan 18, 11:56 am, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 18 Jan 2011 09:10:48 -0800 (PST) rantingrick rantingr...@gmail.com wrote: Well don't get wrong i want to join in --not that i have all the solutions-- Take a look athttp://docs.python.org/devguide/#contributing Thanks for this link Antoine however i think you missed the point of my post. You did say I want to join in. What i would like to see is an forum where the noob to average python programmer can voice his/her opinion about the current state or future state of Pythons syntax, stdlib, goals and dreams, etc, al the while not fearing attack from all sides. Well the only way for that to happen is to put it up yourself. Or to gather some people around you to put it up together. Regards Antoine. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
If you guys spent 1/10th as much time articulating the problems you see with Tkinter (and being willing to listen when people offer solutions) as you do trying to convince everyone else you're right, you'd probably have ... well, anyway, no sense in being practical. -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 18, 12:55 pm, Emile van Sebille em...@fenx.com wrote: On 1/18/2011 9:10 AM rantingrick said... On Jan 18, 10:54 am, MRABpyt...@mrabarnett.plus.com wrote: Decisions are made after open discussion (although we're not sure about move to end :-)). You shouldn't complain about not being consulted if you don't take the time to join in... Well don't get wrong i want to join in --not that i have all the solutions-- however python-dev is a dangerous place for the uninitiated. And we can't have thousands and thousands of posts clogging up the main pool because that would only serve to slow the process to a grinding hault. However, we need some way that the average Python programmer can speak up and be heard when any subject that he/she is passionate about comes before the council. These folks probably don't want to participate in the highly competitive environment of Python dev. However they may have very good ideas. I think we are doing this community a dis service by not giving these voices an outlet. We need either some way to vote outside of Python dev. i think it would be much easier to just have a site where all proposals can be viewed by anyone and they can offer input without clogging up Python dev with noob questions or bad ideas. Then the council can review these suggestions and make a more informed decision. Some might say well that is what blogs and c.l.py is for and i say wrong. I believe more folks would get involved if they felt that the medium was real. c.l.py is not that place (although it could be with some changes) and python.dev is not that place. I am open to any ideas you may have. Brett Cannon used to (still does?) prepare twice monthly summaries of activity on python-dev which provided insight as to what was happening on that side of things. I don't know if he or anyone else still does so, but if so, a copy to this list would at least let everyone know if something was happening that you might want to weigh in on. seehttp://article.gmane.org/gmane.comp.python.devel/43893 Emile That is dated 2002? :D Thanks for offering a suggestion it was very welcome however i need to emphasize that what i am proposing is sort of community discussion suggestion box. Like a Python Suggestions group or something. Where any and all suggestions, rants, complaints, ideas, etc, are welcome from anyone without fear of reprisals. However, in order for this to succeed the elite must take the time to actually read it. Maybe we could have some trusted proof readers who could sift out the spam and useless stuff and then send a modified version to the senate for congressional reviewing. Of course at that point the senate can further narrow down the list before sending over to the white house. This is the only way (short of sending out warnings in the python releases) that you can actually get a feel for what Joe and Jane Python programmer are happy with. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 1:17 pm, Mark Roseman m...@markroseman.com wrote: If you guys spent 1/10th as much time articulating the problems you see with Tkinter (and being willing to listen when people offer solutions) as you do trying to convince everyone else you're right, you'd probably have ... well, anyway, no sense in being practical. Well mark why don't you offer some facts on the merits of Tkinter versus WxPython (or libray X) instead of just contributing nothing. Heck you did not even interject an opinion? This is just argumentative speech Mark, i would really like some soild input from you since you (like myself) are neck deep in Tkinter code. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Tue, Jan 18, 2011 at 11:05 AM, Tim Harig user...@ilthio.net wrote: Even assuming that PyPy does actually manage to reach within a magnitude of C with the extra effort required to leverage two languages, why would I bother when I can do it with one? PyPy and similar methods where great when there was no other mid level alternative that supported Python like features. Now it just seems like using Python as a hammer for every problem whether or not it is the right tool for the job. You clearly have no idea what you're talking about regarding PyPy. You could at least have googled it before speaking about it. Go is also not an ideal language for enterprise development. It provides no compatibility or support guarantees; in fact, the website describes it as 'an experiment' and recommends it for 'adventurous There is no doubt that it is a young project and there are a number of things that will need to be improved to be effective for some branches of programming; but, that isn't a language restriction. It will nevertheless preclude its use in most enterprise software development. That's most systems software. So you conclude that because it is not quite ready for prime time yet that it never will be? I can remember when people said C++ would never amount to anything either. We're a year past the initial announcement that it was ready. It's still 'an experiment'. It doesn't have a ratified standard, committee, or governing body. The company that developed it seems to have no interest in enterprise support. They haven't done any serious marketing for it since the initial release. Five years is, to put it mildly, an overly enthusiastic timeline for the development of broad-based industry support under those conditions. Database bindings are another weak link outside of the more common open source databases. In both cases, Go readily capable of C library functions as a stop-gap until a native wrapper is available. Yes it will be nice once community has filled in the gaps; but, I am rather impressed at what is already available in less then a years time. There are a few libraries you may have missed here: Sounds like a two-language solution, ie, the thing you criticized Python for. Not quite. 1. My arguments for dual language solutions where never directed at Python proper. They were directed at PyPy. I am rather amazed at the number of things that can be accomplished in Python without having to bind to C. Again, you don't know what you're talking about WRT PyPy. 2. There is a difference in binding to a solution that is already written in another language so as to not reinvent a wheel and implementing a *new* library in another language to be used exclusively with Python. Even if that binding is done for performance reasons? Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, Terry Reedy tjre...@udel.edu wrote: On 1/18/2011 10:30 AM, Tim Harig wrote: Whether or not you actually agree with that economic reality is irrelevant. Those who fund commerical projects do; and, any developement tool which violates the security of the source is going to find itself climbing an uphill battle in trying to gain market penetration with commericial software producers. Of course. When I submit or commit patches, I am doing it mostly for hobby, educational, and scientific users, and maybe website makers (who make site I can visit). If commercial users piggyback on top, ok. I do not know how many developers, if any, are after such market penetration. You kind of over-extended the intentions of my comment. It does not apply to open source software in general. I agree that open source authors are not interested in the quantitative value of market penetration. However, I am betting that most authors of developement tools would like to be able to use their tools on the job. I am sure that more software developers would love to develop using Python as part of their job. For some this is a reality; but, many more are stuck using their employer's choice of language. One of the factors that employers consider, when they choose a language, if they produce retail software is that the process of compiling will sufficiently obfiscate their code. -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Tue, Jan 18, 2011 at 13:22, rantingrick rantingr...@gmail.com wrote: Thanks for offering a suggestion it was very welcome however i need to emphasize that what i am proposing is sort of community discussion suggestion box. Like a Python Suggestions group or something. Where any and all suggestions, rants, complaints, ideas, etc, are welcome from anyone without fear of reprisals. What is it with all of this talk of fear? Is there some group of people who were shamed out of python-dev that I wasn't aware of? It's not a hostile mailing list, and I'm not sure why you keep saying that it is... I understand maybe I don't feel that way because I've been reading it for a while, but even thinking back to when I was new around there, I never felt any amount of fear. Sure, I've talked to people who had things shot down and they took it harshly, but they realized it was just part of the game and it wasn't personal and they weren't kicked out of the group or anything. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
rantingrick schrieb: On Jan 18, 12:25 pm, Arndt Roger Schneider arndt.ro...@addcom.de wrote: rantingrick schrieb: On Jan 18, 7:09 am, Arndt Roger Schneider arndt.ro...@addcom.de We DO need to consider the mobile market in this decision. Maybe it is time for us to actually get on the cutting edge of GUI's. Maybe we should head an effort to create a REAL 21st century GUI that can handle desktop, mobile, and accessibility, and do it all whilst looking very sharp! Sure we rob from peter to pay paul. We will use Tkinters awesome API and geometry managers, wxPythons feature richness, and any other code we can steal to make this work! I am not sure whether this sarcasms or for real..., so I'll take for genuine. No this is real, albeit a bit fantastical. Thats probably why you thought it was sarcasm :). However, we need to start a revolution in the GUI world. Currently we (as developers) are slaves to the OEM's and OS's. This must change. We must unify GUI coding the same way OpenGL unified graphics coding. Multiplicity is ruining any and all advancements in Graphical User Interfaces. Sure multiplicity is great in emerging systems (language, culture, GUI, etc, etc) However at some point you must reign in this multiplicity and harness the collective knowledge into an all encompassing standard. OpenGUI is that standard. It should be shipped with every OS in the world. This is the only way we can have mobile, desktop, and accessibility all combined into one beautiful package. Then the contest come down to who can create the best abstraction API. There has been no advancement in GUI-Design. Today it looks and behaves just the way Bill Atkinson designed it. Technical revolutions are made by disruptive thoughts, which are never collective. ...The problem with gui-design:It requires an graphical artist, a well versed writer, a software architect and a programmer. The first two job description are the important ones. ...No OS-vender is going to allow that, it equals lost control. Tk is also doomed, and Tkinter isn't Tk. You are right about keeping the separate geometry managers, though. For starters:http://kenai.com/projects/swank This looks like a very young project (beta) and i could not find a widget set. However i will investigate more. Thanks alpha However we need to think beyond even a Python community scale. This problem is inherent in every language community out there. We to unify the GUI standard. And we are a decade behind in development. (yes i am completely serious about all of this!). Then we did find common ground. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Alexander Kapps alex.ka...@web.de Tkinter causes damage? Very bad damage? What are you talking about? I am talking about the fact that Python promotes Tkinter, and many beginners will start using it, and they will start creating applications with it, and they will learn to use it better than WxPython, and they will start believing that Tkinter is better because it is easier to use than WxPython, so they will start convincing others that Tkinter is the best, and they will start finding many reasons that show that Tkinter is better. And after this, they will say that they don't care about the real problems generated by GUIs like Tk. And a very big problem is that the applications that use Tk/GTK are not accessible for screen readers, so those applications will be just blank for people with visual impairments which need to use a screen reader. Those applications won't be less nice, or just a little harder to use. They won't be accessible at all and they will help the discrimination of the blind people, and not because of technical problems, because those problems can be solved with a better interface like Wx, which is not perfectly accessible either, but it is much better. That discrimination appears just because some people say that they don't care. Well, I don't like wx that much and others have already highlighted some of the problems with it. I think that adding redundancy is bad It is a redundancy for you, but have you imagined that for some people the display is the redundant part of the computer? You said a GUI lib is useless because not all programmers write GUIs. so I say an HTML lib is useless because not all programmers write web stuff. Got it? Both are useful and I'm absolutely against any attempt to remove either from the stdlib. *That* would cause damage. I didn't say that a GUI lib is useless. The GUIS that create discrimination by offering access only for some users (when there are other GUIS that can offer access to everyone) create damage and they should be avoided, and for avoiding them, the beginners need to understand this. But Python promotes that bad GUI lib by including it in the default package instead of promoting a better lib. Which one? That's the whole point. There currently is no better GUI lib than Tkinter which allows quick and easy GUI programming and Are you a beginner? A good programmer is not interested only to create an application with 10 lines of code, no matter the results. The application need to have a good quality and to be accessible by everyone if the technology allows it. Why do we like the portable GUIS and don't really like the native interfaces that don't work on other platforms? Because we want our programs to be usable by as many people as possible. Well, some platforms render the output as sound and Tkinter are not portable on those platforms (screen readers). I have absolutely no problem with a better GUI lib, I just don't care Well, I was sure that you are one of those who don't care... Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Mark Roseman m...@markroseman.com If you guys spent 1/10th as much time articulating the problems you see with Tkinter (and being willing to listen when people offer solutions) as you do trying to convince everyone else you're right, you'd probably have ... well, anyway, no sense in being practical. The problem: The beginners use the first GUI lib they find in the default Python package and they learn how to create applications which are not accessible for screen readers (at all), while there are better solutions. Is there any other solution for the problem that Python promotes this bad GUI than removing it from the default package? Not only Python does this. For the reason that it is more simple and we don't care about the problems it generates, ActiveState does the same and it does the same with ActivePerl, but it doesn't mean that it is something good. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 2:11 pm, rantingrick rantingr...@gmail.com wrote: Adam now you are making sense. Everything you said here is true. This is why we must push for the OpenGUI standard. Funny, I write considerable detail about why such a thing is a pipedream and useless even if it came to fruition, and you somehow believe I'm in support of such an absurd idea. If you believe what I said is true, then you cannot seriously support any sort of OpenGUI standard, and I advise you to google that term before you use it again. Tell me, are you a political science major? Heck, to be totally honest, I've never been 100% convinced that cross- platform GUI APIs were even such a good idea. I certainly use them, but only in situations that are very simple or where I'm OK with accepting the fact my application will not be truly a first-class application[1][2]. Even minor differences in presentation can have large ramifications on how applications should function and therefore be written. The entropy in GUIs has exploded exponentially and rendered them all useless. Only if you have no clue what you're talking about whatsoever. You perceive them as useless because you're apparently incapable of understanding the simplest GUI precepts, nevermind APIs, which is why you've gone from Pure Python GUI to wxWidgets to this OpenGUI bullshit you're now espousing. Desperately clinging to a position doesn't make you look intelligent. Plus, I'm not sure what entropy you're talking about, but I'm not seeing it. MS continues to innovate, Apple continues to innovate, some portions of the Linux community do innovative things. Though most people just want to put something together and call it a day, and the functionality provided by a lot of toolkits is beyond adequate for that. Adam [1] Or solely on Linux where all of the native toolkits have cross- platform support. [2] To say nothing about the explosion of web applications in the world today... -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-18, geremy condra debat...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:05 AM, Tim Harig user...@ilthio.net wrote: Even assuming that PyPy does actually manage to reach within a magnitude of C with the extra effort required to leverage two languages, why would I bother when I can do it with one? PyPy and similar methods where great when there was no other mid level alternative that supported Python like features. Now it just seems like using Python as a hammer for every problem whether or not it is the right tool for the job. You clearly have no idea what you're talking about regarding PyPy. You could at least have googled it before speaking about it. No, I have watched several such projects over the years. Pysco, Unladen Swallow, Cython, PyPy, Shedskin, etc. Source to source translators, JITs, and C language integration all just add to complexity. You can't do this, you can't do that, you have to learn a new way of doing something else, ad nauseum. So when something new that provided Python like capabilities without many of Python's drawbacks came along, I jumped on it. It provides a much cleaner solution to the problem without kludges. I will use Python for what it does well and cleanly. For the rest, there are now better tools. Once again, its about the right tool for the right job. Again, you don't know what you're talking about WRT PyPy. Nor do I really want to. I have found a much simpler solution to the problem. I would recommend it to many others that like the Python language but who occassionaly struggle with its implementation constraints. I would say that I am sorry that it doesn't work for you; but, you seem to prefer Java and Pypy anyway so we are both happy. 2. There is a difference in binding to a solution that is already written in another language so as to not reinvent a wheel and implementing a *new* library in another language to be used exclusively with Python. Even if that binding is done for performance reasons? Yep, that is pretty much the summation of my dual language argument. I don't expect a pure Python implementation of curses since there is a perfectly good C library available to bind to. Why reinvent the wheel. Resorting to writing packages in another language or compiling Python code into another source language is a kludge necessary because of the performance characteristics of the language. I suppose that is an acceptable kludge when that is your only alternative. For me it no longer is. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 3:20 pm, Arndt Roger Schneider arndt.ro...@addcom.de wrote: There has been no advancement in GUI-Design. Today it looks and behaves just the way Bill Atkinson designed it. That doesn't even begin to equate to a lack of advancement. It's also not true in the least. Technical revolutions are made by disruptive thoughts, which are never collective. Revolutions are statistical anomalies, so it's best not to depend on them for progress. It's not even apparent what revolution is necessary here. ...The problem with gui-design:It requires an graphical artist, a well versed writer, a software architect and a programmer. The first two job description are the important ones. ...No OS-vender is going to allow that, it equals lost control. You need to go look at the people Apple, MS, Google, et al. hire; this statement is just patently false too. Plus, after a certainly level of functionality, the OS vendor does become rather irrelevant. Otherwise, the web would have never taken off an application platform: the HTML standard provides the smallest widget set of just about anything discussed, though it's painting / layout capabilities are both simultaneously far advanced and far worse. Yet, it is likely the way of the future for a large portion of us, like it or not. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On 18/01/2011 19:22, rantingrick wrote: On Jan 18, 12:55 pm, Emile van Sebilleem...@fenx.com wrote: On 1/18/2011 9:10 AM rantingrick said... On Jan 18, 10:54 am, MRABpyt...@mrabarnett.plus.comwrote: Decisions are made after open discussion (although we're not sure about move to end :-)). You shouldn't complain about not being consulted if you don't take the time to join in... Well don't get wrong i want to join in --not that i have all the solutions-- however python-dev is a dangerous place for the uninitiated. And we can't have thousands and thousands of posts clogging up the main pool because that would only serve to slow the process to a grinding hault. However, we need some way that the average Python programmer can speak up and be heard when any subject that he/she is passionate about comes before the council. These folks probably don't want to participate in the highly competitive environment of Python dev. However they may have very good ideas. I think we are doing this community a dis service by not giving these voices an outlet. We need either some way to vote outside of Python dev. i think it would be much easier to just have a site where all proposals can be viewed by anyone and they can offer input without clogging up Python dev with noob questions or bad ideas. Then the council can review these suggestions and make a more informed decision. Some might say well that is what blogs and c.l.py is for and i say wrong. I believe more folks would get involved if they felt that the medium was real. c.l.py is not that place (although it could be with some changes) and python.dev is not that place. I am open to any ideas you may have. Brett Cannon used to (still does?) prepare twice monthly summaries of activity on python-dev which provided insight as to what was happening on that side of things. I don't know if he or anyone else still does so, but if so, a copy to this list would at least let everyone know if something was happening that you might want to weigh in on. seehttp://article.gmane.org/gmane.comp.python.devel/43893 Emile That is dated 2002? :D Thanks for offering a suggestion it was very welcome however i need to emphasize that what i am proposing is sort of community discussion suggestion box. Like a Python Suggestions group or something. Where any and all suggestions, rants, complaints, ideas, etc, are welcome from anyone without fear of reprisals. However, in order for this to succeed the elite must take the time to actually read it. Maybe we could have some trusted proof readers who could sift out the spam and useless stuff and then send a modified version to the senate for congressional reviewing. Of course at that point the senate can further narrow down the list before sending over to the white house. This is the only way (short of sending out warnings in the python releases) that you can actually get a feel for what Joe and Jane Python programmer are happy with. The Python community are volunteers. Nothing gets done until someone volunteers to do it. The suggestion box is your idea. Why don't you set it up and report back? -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On 1/18/2011 11:27 AM, rantingrick wrote: On Jan 18, 6:46 am, Antoine Pitrousolip...@pitrou.net wrote: Design considerations? Where were they discussed? I far as I know, nowhere until that post in this thread. They were never discussed with the bulk of this community and that is part of what i want to change. We have a very small group of folks making all the decisions and that is fine. However this small group of privileged folks needs to gather input from the rest of us (peasants) on the value of such changes before making rash decisions. When proposed features are listed on the tracker, as I think this one should have been, anyone who registers can comment. Real names are strongly preferred (and required for elevated tracker and repository access). Currently we have a closed set of intellectual inbreeding that is rotting the community gene pool. Do you actually believe this nonsense, or are you just ranting for effect? In 2010, 20 people were granted commit access. We have 2 more new and active people this month. The active subset of these 22 comprise a substantial fraction of active developers. Without a constant influx of new people, the Python project would slowly die as people left to do other things. One way to demonstrate the needed technical and social skills for commit access is to participate on the tracker with comments, reviews, and patches. We need more diversity in this milkshake to bring about and foster healthy ideas. Python leaders already know we need more diversity of knowledge and skills to target Python at diverse platforms with diverse batteries. Last summer Guido said that we should be a bit more liberal with commit access. Right now, Brett Cannon is working under a PSF grant to greatly improve the developer docs so new developers can more easily get up to speed. One of the stated goals of moving the repository from svn to hg (a non-trivial project) is to make it easier for more people to contribute, with or without 'commit privileges'. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On Tue, Jan 18, 2011 at 8:27 AM, Peter Otten __pete...@web.de wrote: Stefan Behnel wrote: Peter Otten, 18.01.2011 10:04: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? The former runs in parallel, the latter runs sequentially. This may sometimes be relevant, but I doubt that it matters in this particular case. I don't think xargs is ever parallel, but GNU parallel is supposed to be a parallel tool with options and usage similar to those/that of xargs: http://www.gnu.org/software/parallel/ xargs' main advantages are: 1) Simpler quoting (correctness), especially if you use (GNU) find -print0 with xargs -0 2) Far fewer exec's, which usually means much better performance -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 18.01.2011 21:23, Octavian Rasnita wrote: From: Alexander Kappsalex.ka...@web.de Tkinter causes damage? Very bad damage? What are you talking about? I am talking about the fact that Python promotes Tkinter, and many beginners will start using it, and they will start creating applications with it, and they will learn to use it better than WxPython, and they will start believing that Tkinter is better because it is easier to use than WxPython, so they will start convincing others that Tkinter is the best, and they will start finding many reasons that show that Tkinter is better. And after this, they will say that they don't care about the real problems generated by GUIs like Tk. And a very big problem is that the applications that use Tk/GTK are not accessible for screen readers, so those applications will be just blank for people with visual impairments which need to use a screen reader. Those applications won't be less nice, or just a little harder to use. They won't be accessible at all and they will help the discrimination of the blind people, and not because of technical problems, because those problems can be solved with a better interface like Wx, which is not perfectly accessible either, but it is much better. That discrimination appears just because some people say that they don't care. Well, I don't like wx that much and others have already highlighted some of the problems with it. I think that adding redundancy is bad It is a redundancy for you, but have you imagined that for some people the display is the redundant part of the computer? I was talking about redundancy as in duplication of already existing parts. However, for some people, networking is superfluous. That's not a reason to remove the networking modules from the stdlib. Anyway, If you think duplicating functionality is a good approach here, go on, I don't mind. Just remember to stop somewhen and don't include 10 GUI toolkits and 20 HTML parsers just because some people don't like the already existing ones. You said a GUI lib is useless because not all programmers write GUIs. so I say an HTML lib is useless because not all programmers write web stuff. Got it? Both are useful and I'm absolutely against any attempt to remove either from the stdlib. *That* would cause damage. I didn't say that a GUI lib is useless. The GUIS that create discrimination by offering access only for some users (when there are other GUIS that can offer access to everyone) create damage and they should be avoided, and for avoiding them, the beginners need to understand this. But Python promotes that bad GUI lib by including it in the default package instead of promoting a better lib. Please read your previous post. Anyway *which* GUI offers access to everyone? Which one? That's the whole point. There currently is no better GUI lib than Tkinter which allows quick and easy GUI programming and Are you a beginner? A good programmer is not interested only to create an application with 10 lines of code, no matter the results. I'm neither a beginner, nor really a professional programmer. I occasionally do paid coding and that often includes small tools and helper utilities and one thing I can tell you: In approx 90% of those cases, people want a GUI. It hasn't to be fancy, they just don't want no command line tools. Tkinter is just great for quickly hacking together a GUI or for prototyping if somebody wants something more advanced. The application need to have a good quality and to be accessible by everyone if the technology allows it. Why do we like the portable GUIS and don't really like the native interfaces that don't work on other platforms? Because we want our programs to be usable by as many people as possible. Well, some platforms render the output as sound and Tkinter are not portable on those platforms (screen readers). I have absolutely no problem with a better GUI lib, I just don't care Well, I was sure that you are one of those who don't care... You make that sound as if I should feel guilty now. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
Adam Skutt schrieb: On Jan 18, 8:09 am, Arndt Roger Schneider arndt.ro...@addcom.de wrote: Back to rantingrick 21st century toolkit/framwork: Let's have a look at the numbers: Worlwide pc market are 300 Million pcs per year, this number includes desktops(2/3) and servers(1/3). Your gui app is not relevant on servers. You should tell this fact to just about every major enterprise software manufacturer out there. They all ship GUI tools intended to be used on the server. Some of them ship only GUI tools or CLI tools that are worthless, making you use the GUI tools. The desktop pc market is in decline; there is however a shift toward pc-servers, instead. It is anybodies guess how far the pc-desktop decline will go. Every 21st century toolkit or framework must run on mobile platforms! Until we have pixel-perfect touch sensors, toolkits for devices with pointer interfaces (e.g., PCs) and toolkits for devices with touch interfaces (e.g., phones and tablets) will necessarily be different. You note this yourself: the UI paradigms that work well when you have a pixel-perfect pointer do not work at all when you have a touch screen, especially on a limited size and resolution display. Yes I did and that's how it is. Even if you're provided a single toolkit, you still end up with two, maybe three, different applications, each using different widgets targeted for the device they run on. And no one provides a single toolkit: while Silverlight can run on the desktop, the web, and now on Windows Phone, you can't use the same widgets everywhere; ditto with Cocoa for OS X and Cocoa Touch for iTouch devices. While some further unification is obviously possible, it's rather doubtful we'll ever have unified widgets that are truly workable on the web, on the desktop, and on a portable touch screen device. Think about all the programmers earning their butter and bread :-). Forget toolkits and widgets for awhile. What remains are specific types of human/computer interactions, a visual representation on a screen and a predefined behaviour for said human action. E.g. a button is: A function gets asychnronously performed in response to a finger/mouse click and release inside a certain screen area. --A widget is essentially a logical abstraction. wxWidgets was written ~1992, it is a copy of mfc, which in turn is a copy of MacApp. MacApp is also OSS, maintained through an industrie consortium. Why do you not use the original framework? Because it's not cross-platform, I'd imagine. The entire point of wxWidgets was to provide a cross-platform OOP UI toolkit. It closely copies MFC since MFC and XView were the two backends it supported. MacApp is/was cross-platform, Apple pulled the plug on the non-mac platforms; the industrie consortium took charge of the other platforms. Screen resolution: The time of 72ppi CRT monitors is over. A GUI framework/toolkit must be resolution independent, including all icons and indicators; it should use decluttering (newspeak:ZUI). WPF is the only functional resolution-independent UI toolkit in existence. While I don't disagree with you in principal, practice is pretty heavily divorced from principal here. Principal doesn't help me write GUI applications today. wxWidgets is not suitable for a modern type GUI ad thus clearly not the toolkit/framework of the 21st century. None of the toolkits accessible from CPython are suitable for a 21st century guy by your standard. If we talk about IronPython, Silverlight becomes the closest, but it isn't a panacea by any stretch of the imagination. Adam According to Microsoft neither is silverlight. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 1/18/2011 3:23 PM, Octavian Rasnita wrote: I am talking about the fact that Python promotes Tkinter Python uses tkinter as the only choice available for the stdlib. Others choices not in the stdlib are available for those who want something better. TK are not accessible for screen readers, I did not know that. You could ask on the tracker that that fact be added to the docs. I would consider it reason to consider another choice if there ever were to be a suitable one offered. I'm absolutely against any attempt to remove either from the stdlib. *That* would cause damage. I agree. Besides IDLE and turtle, there are tools in the Tools directory that depend on tkinter. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Cobra seems to similar to python. Or it at least compares itself to python. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Anyone have thoughts on Cobra? On Jan 18, 2011 4:20 PM, Zach taylo...@gmail.com wrote: Cobra seems to similar to python. Or it at least compares itself to python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 1/18/2011 2:12 PM, jmfauth wrote: If you think the site is bad, send me a ONE better screenshot, or link thereto, of wx on WinXP/Vista/7. I promise to look at it. Then urge Robin to update the page. No wxWidgets, but real Python / wxPython applications, all updated on Windows 7. http://spinecho.ze.cx/ Yes wxWidgets, underneath wxPython. And yes, look very nice. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 1/18/2011 3:29 PM, Octavian Rasnita wrote: Is there any other solution for the problem that Python promotes this bad GUI than removing it from the default package? I am generally for better accessibility, but I consider the notion that if everyone cannot have something, then no one should, to be rather pernicious. Not only Python does this. For the reason that it is more simple and we don't care about the problems it generates, ActiveState does the same and it does the same with ActivePerl, but it doesn't mean that it is something good. So persuade them or someone to make it better, or is ActiveState actively opposed to that? -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficient python 2-d arrays?
Since you can't depend on your users installing the dependencies, is it vital that your users run from source? You could bundle up your application along with numpy and other dependencies using py2Exe or similar. This also means you wouldn't have to require users to have the right (or any) version of Python installed. It's a good suggestion, though I am far from familiar with the process. I've just finished implementing another alternative-- I'm doing a merge sort, where the array chunks are zipped together and then sorted using python's builtin sort then unzipped back to their original arrays. This seems fast enough and the reduced memory requirement for 2 arrays vs 1 list-of-tuples is substantial (1.5 GB vs 4GB). Thanks for the great suggestions! -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficient python 2-d arrays?
Without using third party libraries, no not really. numpy has it covered so there's not really a lot of demand for it. If your users are loading 1.5 GB arrays into memory, it's probably not unreasonable to expect them to have numpy installed. My users are biologists, and I can't expect them to have numpy (and the barrier to entry for this group is particularly high). -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On 2011-01-18, MRAB pyt...@mrabarnett.plus.com wrote: On 18/01/2011 19:22, rantingrick wrote: Thanks for offering a suggestion it was very welcome however i need to emphasize that what i am proposing is sort of community discussion suggestion box. Like a Python Suggestions group or something. Where any and all suggestions, rants, complaints, ideas, etc, are welcome from anyone without fear of reprisals. However, in order for this to succeed the elite must take the time to actually read it. Maybe we could have some trusted proof readers who could sift out the spam and useless stuff and then send a modified version to the senate for congressional reviewing. Of course at that point the senate can further narrow down the list before sending over to the white house. This is the only way (short of sending out warnings in the python releases) that you can actually get a feel for what Joe and Jane Python programmer are happy with. The Python community are volunteers. Nothing gets done until someone volunteers to do it. The suggestion box is your idea. Why don't you set it up and report back? He goes by the name of ranting rick, and you're suggesting that instead of talking he rolls up his sleeves and does something. I suspect you're barking into the wind... -- Grant Edwards grant.b.edwardsYow! Yes, but will I at see the EASTER BUNNY in gmail.comskintight leather at an IRON MAIDEN concert? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 4:45 pm, Arndt Roger Schneider arndt.ro...@addcom.de wrote: Adam Skutt schrieb: Until we have pixel-perfect touch sensors, toolkits for devices with pointer interfaces (e.g., PCs) and toolkits for devices with touch interfaces (e.g., phones and tablets) will necessarily be different. You note this yourself: the UI paradigms that work well when you have a pixel-perfect pointer do not work at all when you have a touch screen, especially on a limited size and resolution display. Yes I did and that's how it is. And then you go and advocate a single toolkit! Do you not see the inherent contradiction there? While it's certainly not impossible, the case is hardly obvious for one GUI toolkit for all possible UIs. You certainly have not presented it, and rantingrick never will. Think about all the programmers earning their butter and bread :-). Forget toolkits and widgets for awhile. What remains are specific types of human/computer interactions, a visual representation on a screen and a predefined behaviour for said human action. Also known as toolkits and widgets. Talking about such things are inescapable. E.g. a button is: A function gets asychnronously performed in response to a finger/mouse click and release inside a certain screen area. No, that is not the definition of a 'button', not even when we choose to ignore how it is rendered, which you cannot ignore even if you wish to pretend you can. Otherwise, I could always treat hyperlinks and buttons as equivalent and even interchangeable. Unfortunately, they are no such things. --A widget is essentially a logical abstraction. No, as much as we try we cannot divorce presentation from behavior fully. Because it's not cross-platform, I'd imagine. The entire point of wxWidgets was to provide a cross-platform OOP UI toolkit. It closely copies MFC since MFC and XView were the two backends it supported. MacApp is/was cross-platform, Apple pulled the plug on the non-mac platforms; the industrie consortium took charge of the other platforms. MacApp didn't even see the start of cross-platform development until 1996, four years after wxWidgets. It was not cross-platform from the start and only became cross-platform when all of Apple's other cross- platform endeavours failed. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 18, 3:05 pm, MRAB pyt...@mrabarnett.plus.com wrote: The Python community are volunteers. Nothing gets done until someone volunteers to do it. The suggestion box is your idea. Why don't you set it up and report back? Agreed, i would gladly accept you nominating me as the Suggestion Box president. However we need to decide where the best place to put the suggestion box will be. Sure i could open a website called pythonsuggestionbox.com however i doubt anybody that *needs* to find it ever would. Heck i would feel lucky if a few trolls dropped by and asked for the GIL to be removed. ;-) In light of that, the only place --and i would argue the best place-- is the official website with a nice link on the home page although i don't expect that will happen. In that case c.l.py becomes the winner by default. Why? Well imagine you are a new python user. Where would you look for help after downloading the installer? Of course you might go back to check out python.org a bit more. The next logical step would be python help and then c.l.py. So either we add a suggestions area to the official site OR make this group more accessible to the average user. If it were my choice, i would just make this group more accessible to newcomers and be done with it. Much eaiser, much less work, and more results will be produced. How can we make c.l.py more accessible you ask? Well a good start would be for some of the well known elites to make a public announcement. If we could convince Guido to make a speech that would be wonderful however i know he cannot do everything. In this statement we must stress that a new age of community has dawned -- an age of freedom. That all pythoneers are created equal and in the image of Guido. No, not of his physical image, but of his vision, his wisdom, and his compassion. That we will admonish those that wish to belittle the most feeble among us and elevate those who would carry the torch of community at the very expense of their own selfless vanity. That we are moving forward as a collective group united in vision, in spirit, and in solidarity for the future evolution of Python -- and for the greater good of all programming languages! Once we get c.l.py back on track i believe it will take some time but eventually the masses will return and rejoin our efforts. New users will mold into he community and we shall all reape the benefits. Hopefully with enough good will and collaboration we can do great things and save Python from an untimely demise. However we must act quickly, because the time is ticking away... -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 18, 3:07 pm, Terry Reedy tjre...@udel.edu wrote: On 1/18/2011 11:27 AM, rantingrick wrote: When proposed features are listed on the tracker, as I think this one should have been, anyone who registers can comment. Real names are strongly preferred (and required for elevated tracker and repository access). Agreed. However you cannot expect the ordinary python programmers to follow the tracker. They are not a political as we. However they do have a voice and we must listen. How can we call ourselves a community when there exists no means by which the real users can express themselves? Currently we have a closed set of intellectual inbreeding that is rotting the community gene pool. Do you actually believe this nonsense, or are you just ranting for effect? This was a strong statement and it was meant to be strong. On on the face of it some might take it as an insult to the intelligence of our leaders -- i can assure you that is not the case! Of course we have good people at the top, however they are not hearing the voices screaming from below. They are making decisions in a vacuum. This cannot produce positive results for very much longer. I fear we have already begun the downward spiral as a community. We must get a grip and pull ourselves together before inertia rips us apart at the seams. One way to demonstrate the needed technical and social skills for commit access is to participate on the tracker with comments, reviews, and patches. We cannot even discuss the tracker until we fix this abomination called c.l.py. We need to focus on c.l.py. We need to get it back on track. And i want everyone to participate even the outright bullies and predators (if they can tone done the rhetoric and be nice again!). We as a community are existing in a vacuum. Likewise Python dev is existing in a vacuum. However both of us are in parallel universes. We must combine the head with the tail or we have nothing but component parts. Can a car function without wheels? Can a plane function without it's wings? No, an we are just component parts idle in some intellectual factory collecting dust! We need more diversity in this milkshake to bring about and foster healthy ideas. Python leaders already know we need more diversity of knowledge and skills to target Python at diverse platforms with diverse batteries. Last summer Guido said that we should be a bit more liberal with commit access. Right now, Brett Cannon is working under a PSF grant to greatly improve the developer docs so new developers can more easily get up to speed. One of the stated goals of moving the repository from svn to hg (a non-trivial project) is to make it easier for more people to contribute, with or without 'commit privileges'. This is a great advancement! Keep them coming! -- http://mail.python.org/mailman/listinfo/python-list
Swampy Module installation
I am new to python, and attempting to install the learning module swampy. http://www.greenteapress.com/thinkpython/swampy/install.html Unfortunately, I am attempting to do this on windows vista, which does not appear to be cooperating. Once I click on the install link, it puts the file on the computer, and even if I place the file into the source folder for python, it still says that there is no module swampy. How can I get python to recognize the module as being there, and to run the suite? I admit, I may be placing it in the wrong directory, as I have so far been unable to change the working directory. Online the command os.chdir is said to change the directory, but it keeps giving an error, and saying that os is not recognized. Variations on this code do not seem to work either. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 4:57 pm, Adam Skutt ask...@gmail.com wrote: On Jan 18, 4:45 pm, Arndt Roger Schneider arndt.ro...@addcom.de E.g. a button is: A function gets asychnronously performed in response to a finger/mouse click and release inside a certain screen area. No, that is not the definition of a 'button', not even when we choose to ignore how it is rendered, which you cannot ignore even if you wish to pretend you can. Otherwise, I could always treat hyperlinks and buttons as equivalent and even interchangeable. Unfortunately, they are no such things. What! YES it is Adam! And you just exposed yourself as an argumentative moron! A hyperlink and a button are EXACTLY the same thing functionality wise. The fact that they look different has nothing to do with the argument. Would you say that a Ford Escort and a Dodge Viper do not function in basically the same way. Sure one looks much prettier and goes much faster however they both have four wheels, and engine, a drivetrain, an outer shell, burn gasoline, and are basically people movers. In other words they are both cars! *slap* --A widget is essentially a logical abstraction. No, as much as we try we cannot divorce presentation from behavior fully. More argumentative crap. Adam you are incapable of compromise or reason... or maybe both. Try more facts next time. -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On 1/18/2011 6:22 PM, rantingrick wrote: This was a strong statement and it was meant to be strong. However, it was falso. We cannot even discuss the tracker until we fix this abomination called c.l.py. I have nothing directly to do with c.l.p and care nothing for it. I read the gmane.comp.python.general mirror of python-list, which filters out some of the worse of the input from c.l.p. I mostly focus on getting real work done on the tracker and repository and am only temporarily spending this much time here as a diversion. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
Grant Edwards wrote: On 2011-01-18, MRAB pyt...@mrabarnett.plus.com wrote: On 18/01/2011 19:22, rantingrick wrote: ... The Python community are volunteers. Nothing gets done until someone volunteers to do it. The suggestion box is your idea. Why don't you set it up and report back? He goes by the name of ranting rick, and you're suggesting that instead of talking he rolls up his sleeves and does something. I suspect you're barking into the wind... To borrow from Dilbert*, perhaps rr is more of an idea rat. ~Ethan~ *http://www.dilbert.com/strips/comic/1994-12-17/ -- http://mail.python.org/mailman/listinfo/python-list
Re: issubclass(dict, Mapping)
In article ieu9bk$mt0$1...@reader1.panix.com, kj no.em...@please.post wrote: standard OOP semantics ...some experts might say a C++ program is not object-oriented without inheritance and virtual functions. As one of the early Smalltalk implementors myself, I can say they are full of themselves. --zconcept -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ The volume of a pizza of thickness 'a' and radius 'z' is given by pi*z*z*a -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
And were the hell is Steve Holden? Why has he not weighed in on these (or any) discussions. He (Steve Holden) is second in command to the entire community. Yet we have yet to hear a peep from this fella. What gives Steve? And if Steve is too busy, who is next in the chain of command? Who is going to take responsibility for this catastrophe we call c.l.py? Is there no one is man enough to step up for this community? Are all of our leaders just sticking their heads in the sand hoping for this to solve itself? I would really like for some heavy weights to get involved here. -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 18, 5:44 pm, Terry Reedy tjre...@udel.edu wrote: I have nothing directly to do with c.l.p and care nothing for it. I read the gmane.comp.python.general mirror of python-list, which filters out some of the worse of the input from c.l.p. I mostly focus on getting real work done on the tracker and repository and am only temporarily spending this much time here as a diversion. Well first of all i want to commend you for your valiant efforts. You are one the most helpful folks (anoung others) around and i believe you are a virtuous soul. However, you really should not just write off c.l.py like you have. Many new users (and old hats) still hang around here. Sure there is a lot of spam, and some trolling. However, we CAN take c.l.py back IF some heavy weights will get on board. Please don't allow c.l.py to become the habitat of vermin due to neglect. Why should we move to the sub burbs just because these fowl creatures are polluting our city? We need to run them out of town. -- http://mail.python.org/mailman/listinfo/python-list
Re: Swampy Module installation
Michael Rauh fathead9...@gmail.com writes: I am new to python, and attempting to install the learning module swampy. http://www.greenteapress.com/thinkpython/swampy/install.html Unfortunately, I am attempting to do this on windows vista, which does not appear to be cooperating. I'm not familiar with the specifics of that OS, but you should read the Python on Windows FAQ URL:http://docs.python.org/faq/windows thoroughly to see if that gets you further. -- \ “… one of the main causes of the fall of the Roman Empire was | `\that, lacking zero, they had no way to indicate successful | _o__) termination of their C programs.” —Robert Firth | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 6:36 pm, rantingrick rantingr...@gmail.com wrote: On Jan 18, 4:57 pm, Adam Skutt ask...@gmail.com wrote: On Jan 18, 4:45 pm, Arndt Roger Schneider arndt.ro...@addcom.de E.g. a button is: A function gets asychnronously performed in response to a finger/mouse click and release inside a certain screen area. No, that is not the definition of a 'button', not even when we choose to ignore how it is rendered, which you cannot ignore even if you wish to pretend you can. Otherwise, I could always treat hyperlinks and buttons as equivalent and even interchangeable. Unfortunately, they are no such things. What! YES it is Adam! And you just exposed yourself as an argumentative moron! A hyperlink and a button are EXACTLY the same thing functionality wise. :active, :visited:, :hover, and the concept of onhover all would like to have a word with you. They have different presentation which yields to different functionality: if it's important to tell a user Hey, you've been there before, then a button is entirely unsuitable, while a hyperlink is designed precisely for that situation. Hyperlinks change their presentation to indicate mouse focus (nevermind the mouse cursor itself normally), buttons don't necessarily do either[1]. Hyperlinks can certainly decay to become button-like, but buttons cannot do everything hyperlinks can do. Checkboxes and radio buttons are a much better rebuttal, as they usually present almost the same API and expect the same model on part of the application programmer. It's the almost that kills us: radio buttons only behave in the desired way when part of a button group, forcing us to be cognizant of the fact we're creating radio buttons (since we must create button groups as well). Checkboxes support tri-state functionality, and sometimes radiobuttons do as well. Pushbuttons do no such thing[2]. It'd be nice to be able to support the abstract notion of a button and get what I wanted, but that requires guessing at intent and computers are notoriously lousy at that. The fact that they look different has nothing to do with the argument. Actually it does, but they not only look different, they /behave/ differently. Both in terms of how a user interacts with them, and in terms of how we interact with them in code. More argumentative crap. Adam you are incapable of compromise or reason... or maybe both. Try more facts next time. I'm not the one suggesting that the only difference between a hyperlink and a button is how they are rendered, FFS man, have you ever even used a modern GUI? Are you posting from tin? Adam [1] Even when they do, it's not intended to be controlled by the application. Native button widgets have no real built-in support for user-controlled styling on mouse focus, you'd have to do the drawing yourself (at which point you might as well write a custom widget). [2] I'm ignoring the UI problems with radio buttons and checkboxes, of course. Point is, even among things where the differences are subtle, the differences have inescapable ramifications on the code I write. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 6:23 pm, Adam Skutt ask...@gmail.com wrote: I'm not the one suggesting that the only difference between a hyperlink and a button is how they are rendered, FFS man, have you ever even used a modern GUI? Yes i have logged many hours building GUI's... and from the comments you've made so far... obviously more that you have! But your defiance intrigues me. You still argue in the face of undeniable fact. Ok, i will lower the bar a bit this time. They (the buttons) are exactly the same thing except for a few superficial differences. Both buttons wait for activity (either by pointer, or touch) and then execute a linked block of code. The fact that hyper-link displays a visual clue that it has been activated before is just superficial. Heck a button displays a visual clue that it is a button and you are not arguing that point? And this moronic argument of :onhover :visited, and :active is completely unfounded as buttons have mouse events such as Enter and Leave, just to name a few. Adam, it is now evident that your view of the world is, at best, a superficial one. You are shallow and incapable of any coherent abstract reasoning abilities. I genuinely hope this is due to some emotional distress you are suffering and not a chronic condition, because if not, you need to give some deep mediative thoughts to how you are perceiving the world around you to heal your mind of this improper processing. Being argumentative just for the sake of being argumentative is a never ending cycle of foolishness. Now, at some point earlier you had begin to display some coherency and insights. I sure hope that behavior will return soon..? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 01/18/2011 07:53 PM, rantingrick wrote: On Jan 18, 6:23 pm, Adam Skutt ask...@gmail.com wrote: [snip] Adam, it is now evident that your view of the world is, at best, a superficial one. You are shallow and incapable of any coherent abstract reasoning abilities. I genuinely hope this is due to some emotional distress you are suffering and not a chronic condition, because if not, you need to give some deep mediative thoughts to how you are perceiving the world around you to heal your mind of this improper processing. Being argumentative just for the sake of being argumentative is a never ending cycle of foolishness. Now, at some point earlier you had begin to display some coherency and insights. I sure hope that behavior will return soon..? Because insulting others is completely how things get done. As to the button/hyperlink, they may both share some common functionality and even a common ancestor, they are different beings, otherwise they wouldn't be two separate things. It may even be that a hyperlink is a type of button, but that doesn't make a button a hyperlink. (Plant/tree, rectangle/square type deal). I for one am quite pleased with Tkinter up to this point. It allowed me to come in with extremely minimal GUI experience, and make something that worked with minimal effort. It was simple to understand, no concepts of slots and signals to learn. A project I'm working on requires PyQt, so I use PyQt. Is the fact that it's not in the stdlib a detriment? No. I think Tkinter _should_ be in the stdlib because it's simple. If something else were to take it's place I would hope that it is as easy to learn/use as Tkinter is. But I think this whole thread has gotten off topic. Why should Tkinter be replaced? Why was it added there in the first place? What should replace it, and why? Instead of arguing about little piddly details like the difference between a button and a hyperlink, just stick to the task at hand that you yourself presented. My two cents, ~Corey -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 2:37 pm, Adam Skutt ask...@gmail.com wrote: On Jan 18, 2:11 pm, rantingrick rantingr...@gmail.com wrote: The entropy in GUIs has exploded exponentially and rendered them all useless. Only if you have no clue what you're talking about whatsoever. You perceive them as useless because you're apparently incapable of understanding the simplest GUI precepts, nevermind APIs, which is why you've gone from Pure Python GUI to wxWidgets to this OpenGUI bullshit you're now espousing. Desperately clinging to a position doesn't make you look intelligent. Plus, I'm not sure what entropy you're talking about, but I'm not seeing it. MS continues to innovate, Apple continues to innovate, some portions of the Linux community do innovative things. Though most people just want to put something together and call it a day, and the functionality provided by a lot of toolkits is beyond adequate for that. Adam, i am speaking specifically about how multiplicity is ruining everything. The multiplicity is entropy incarnate. And selfishness is the heathen prodigy of multiplicity. What we have today is a zig saw puzzle of GUI libraries. Not one of them can solve all the GUI problems we have before us because of selfishness and lack of true cooperation between the diverse parties. And to add insult to injury none of the pieces where ever made so that they could mate correctly. We have been the victims of you own selfishness and vanity begotten directly from our fostering of multiplicity. Once you understand what i am talking about, you will see how it applies to almost every system we humans have ever created. And more disturbingly, how difficult it will be to undo this backward facing inertia we have set in motion. Years, decades, centuries have been lost due to nothing more than selfishness. When will we see the light? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
- Original Message - From: Corey Richardson kb1...@aim.com To: python-list@python.org Sent: Tuesday, January 18, 2011 5:19 PM Subject: Re: Tkinter: The good, the bad, and the ugly! On 01/18/2011 07:53 PM, rantingrick wrote: On Jan 18, 6:23 pm, Adam Skutt ask...@gmail.com wrote: [snip] Adam, it is now evident that your view of the world is, at best, a superficial one. You are shallow and incapable of any coherent abstract reasoning abilities. I genuinely hope this is due to some emotional distress you are suffering and not a chronic condition, because if not, you need to give some deep mediative thoughts to how you are perceiving the world around you to heal your mind of this improper processing. Being argumentative just for the sake of being argumentative is a never ending cycle of foolishness. Now, at some point earlier you had begin to display some coherency and insights. I sure hope that behavior will return soon..? Because insulting others is completely how things get done. As to the button/hyperlink, they may both share some common functionality and even a common ancestor, they are different beings, otherwise they wouldn't be two separate things. It may even be that a hyperlink is a type of button, but that doesn't make a button a hyperlink. (Plant/tree, rectangle/square type deal). I for one am quite pleased with Tkinter up to this point. It allowed me to come in with extremely minimal GUI experience, and make something that worked with minimal effort. It was simple to understand, no concepts of slots and signals to learn. A project I'm working on requires PyQt, so I use PyQt. Is the fact that it's not in the stdlib a detriment? No. I think Tkinter _should_ be in the stdlib because it's simple. If something else were to take it's place I would hope that it is as easy to learn/use as Tkinter is. But I think this whole thread has gotten off topic. Why should Tkinter be replaced? Why was it added there in the first place? What should replace it, and why? Instead of arguing about little piddly details like the difference between a button and a hyperlink, just stick to the task at hand that you yourself presented. My two cents, ~Corey -- http://mail.python.org/mailman/listinfo/python-list I agree with Corey - I also had very little experience with creating a GUI and using Tkinter combined with PIL plus a little help from various docs and getting a couple questions answered, I was pleased to find that it required very few actual lines of code to create a basic small window and display text and pictures that I am happy with and I am sure I can use this small module as a base to expand on if I want to. Regards, Patty -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 7:19 pm, Corey Richardson kb1...@aim.com wrote: I for one am quite pleased with Tkinter up to this point. It allowed me to come in with extremely minimal GUI experience, and make something that worked with minimal effort. It was simple to understand, no concepts of slots and signals to learn. I agree. I have written tons of code with Tkinter and i love both the simplistic API and the geometry managers to name a few pros. If something else were to take it's place (Tkinter) I would hope that it is as easy to learn/use as Tkinter is. I completely agree! And we should expect it to be even better! But I think this whole thread has gotten off topic. Why should Tkinter be replaced? Well there are many good reasons and most are not apparent to those with minimal to average Tkinter experience. My main beef with Tkinter is that it is limited --both widget wise and extensible wise-- and that we must recognize that web and mobile platforms are getting bigger every day. We cannot ignore this fact. The GUI landscape is changing fast and whilst desktop support will be needed for many years to come, mobile and web must be addressed and addressed quickly! Why was it added there in the first place? Well from what i understand (and feel free to correct me anyone) Guido wanted a GUI both for batteries included and for ease of introductory GUI programming. So he choose Tkinter because it would be both easy to integrate and easy to use. And i totally agree with these ideas. However that was circa 1990's and we are now in 2011. I think Tkinter (whilst still quite useful) is well pasted it's prime. We must consider keeping Pythons stdlib up to date. And doing that might mean we need to make some very tough decisions. Guido brought about Python3000 and i think he's on the right track, however more must be done. Change while painful is always necessary. Change with the times or get left behind. What should replace it, and why? Well that seems to be the burning question. Now, after considering all the options i can't see anything that truly moves us forward to were we should be. I do think wx would be a move forward however only a very *small* move in the larger scope of things. We need to think bigger, we need to think of mobile and web interfaces if we want Python to compete in the next 10 years. So when considering anything we must consider all three. Instead of arguing about little piddly details like the difference between a button and a hyperlink, just stick to the task at hand that you yourself presented. You are absolutely correct Corey. Thanks for getting us back on topic! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
You make it very hard for me to take what you say seriously. I lurk on this list and I have created a filter where emails from you go in to Spam. Good luck. Nick On Tue, Jan 18, 2011 at 5:23 PM, rantingrick rantingr...@gmail.com wrote: On Jan 18, 2:37 pm, Adam Skutt ask...@gmail.com wrote: On Jan 18, 2:11 pm, rantingrick rantingr...@gmail.com wrote: The entropy in GUIs has exploded exponentially and rendered them all useless. Only if you have no clue what you're talking about whatsoever. You perceive them as useless because you're apparently incapable of understanding the simplest GUI precepts, nevermind APIs, which is why you've gone from Pure Python GUI to wxWidgets to this OpenGUI bullshit you're now espousing. Desperately clinging to a position doesn't make you look intelligent. Plus, I'm not sure what entropy you're talking about, but I'm not seeing it. MS continues to innovate, Apple continues to innovate, some portions of the Linux community do innovative things. Though most people just want to put something together and call it a day, and the functionality provided by a lot of toolkits is beyond adequate for that. Adam, i am speaking specifically about how multiplicity is ruining everything. The multiplicity is entropy incarnate. And selfishness is the heathen prodigy of multiplicity. What we have today is a zig saw puzzle of GUI libraries. Not one of them can solve all the GUI problems we have before us because of selfishness and lack of true cooperation between the diverse parties. And to add insult to injury none of the pieces where ever made so that they could mate correctly. We have been the victims of you own selfishness and vanity begotten directly from our fostering of multiplicity. Once you understand what i am talking about, you will see how it applies to almost every system we humans have ever created. And more disturbingly, how difficult it will be to undo this backward facing inertia we have set in motion. Years, decades, centuries have been lost due to nothing more than selfishness. When will we see the light? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 7:39 pm, Patty pa...@cruzio.com wrote: I agree with Corey - I also had very little experience with creating a GUI and using Tkinter combined with PIL plus a little help from various docs and getting a couple questions answered, I was pleased to find that it required very few actual lines of code to create a basic small window and display text and pictures that I am happy with and I am sure I can use this small module as a base to expand on if I want to. Hello Patty and welcome to the debate, I am happy to see the simplicity of Tkinter has helped moved you into the joys of GUI programming. I remember my initial days with Tkinter and i remember the delight in achieving my first small GUI utilities. Like you, i love the simplistic nature of Tkinter and if TclTk had as large a widget base and maturity as wxWidgets then we would be closer to the 21st century GUI library that Python desperately needs. However as i know --and you will find out over time-- Tkinter is greatly lacking in very important widgets. Widgets that are part of every major GUI app you could imagine. If all you do is create utilities for yourself or small apps you can get by with Tkinter just fine. However if you try to go any further you will then realize the limits of TclTk --and not Tkinter-- are really the culprits behind the scenes. But again, all this is moot because as this debate has evolved so too has my understanding of where we need to be focusing or efforts -- and *desktop only* is not going to cut it for the future of Python's std- GUI-lib. We need to take a step back and see the larger picture. Currently we have our heads stuck in the vacuum of python land, however this GUI problem is much, much larger! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 01/18/2011 08:41 PM, rantingrick wrote: On Jan 18, 7:19 pm, Corey Richardson kb1...@aim.com wrote: I for one am quite pleased with Tkinter up to this point. It allowed me to come in with extremely minimal GUI experience, and make something that worked with minimal effort. It was simple to understand, no concepts of slots and signals to learn. I agree. I have written tons of code with Tkinter and i love both the simplistic API and the geometry managers to name a few pros. If something else were to take it's place (Tkinter) I would hope that it is as easy to learn/use as Tkinter is. I completely agree! And we should expect it to be even better! What out there is there that meets those requirements? But I think this whole thread has gotten off topic. Why should Tkinter be replaced? Well there are many good reasons and most are not apparent to those with minimal to average Tkinter experience. My main beef with Tkinter is that it is limited --both widget wise and extensible wise-- and that we must recognize that web and mobile platforms are getting bigger every day. We cannot ignore this fact. The GUI landscape is changing fast and whilst desktop support will be needed for many years to come, mobile and web must be addressed and addressed quickly! Mobile and web certainly have their place, but it Python the place for it? Sure, Python can be used as the back-end of web sites, but not up front like Java or Flash (aside from Jython). Especially mobile. Python was not intended for a mobile platform not should it be made to fit that niche. Python has its place, but your cell phone is not it. [snip] What should replace it, and why? Well that seems to be the burning question. Now, after considering all the options i can't see anything that truly moves us forward to were we should be. I do think wx would be a move forward however only a very *small* move in the larger scope of things. We need to think bigger, we need to think of mobile and web interfaces if we want Python to compete in the next 10 years. So when considering anything we must consider all three. From that, it appears we need to: 1. Replace Tkinter with something more modern and feature-complete, but just as easy to use. 2. Add a web framework/web-GUI As a web interface are you thinking something like Java's Swing or something like Django? Given the above, what do you guys (python-list, not just rantingrick) think fills the spot the best? Would these items inclusion in the stdlib entail unnecessary cruft added on to the size of the stdlib, are they completely cross-platform (as far as Python itself is)? Let's try not to get off track like this thing has been since it was started. Either get things done or shut up ;-). I think this is almost ready to split into a real thread, not just a giant cyclic argument that this thread has been. ~Corey -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 7:59 pm, Corey Richardson kb1...@aim.com wrote: On 01/18/2011 08:41 PM, rantingrick wrote: From that, it appears we need to: 1. Replace Tkinter with something more modern and feature-complete, but just as easy to use. 2. Add a web framework/web-GUI That would be a HUGE step in the correct direction. It would not solve all our problems however its a start. Like i mentioned earlier with Tkinter it is fact that sooner or later you will come up against the glass ceiling. At that point your only alternative is to toss away everything you have learned/written and re-learn another GUI library like wxPython. This is what bothers me most about Tkinter. It just sums to wasted time and energy. If we had a simplistic wxGUI in the stdlib, when you hit the ceiling and need to go further you could then scale nicely to the feature richness of wxPython as a 3rd party download -- WITHOUT relearning/rewriting everything! Given the above, what do you guys (python-list, not just rantingrick) think fills the spot the best? Well i hope some heavy weights weigh in however i must tell you that it don't happen very often. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 01/18/2011 09:16 PM, rantingrick wrote: On Jan 18, 7:59 pm, Corey Richardson kb1...@aim.com wrote: On 01/18/2011 08:41 PM, rantingrick wrote: From that, it appears we need to: 1. Replace Tkinter with something more modern and feature-complete, but just as easy to use. 2. Add a web framework/web-GUI That would be a HUGE step in the correct direction. It would not solve all our problems however its a start. Like i mentioned earlier with Tkinter it is fact that sooner or later you will come up against the glass ceiling. At that point your only alternative is to toss away everything you have learned/written and re-learn another GUI library like wxPython. This is what bothers me most about Tkinter. It just sums to wasted time and energy. If we had a simplistic wxGUI in the stdlib, when you hit the ceiling and need to go further you could then scale nicely to the feature richness of wxPython as a 3rd party download -- WITHOUT relearning/rewriting everything! You mentioned having a segment of wxPython in the stdlib earlier. If this actually feasible from a legal standpoint, and would the maintainers of wxPython be willing to put it in the stdlib? Not to mention the wonderful people over at python-dev. Why would you add in only a part of wxPython, instead of all of it? Is the work to cut it down really an advantage over the size of the full toolkit? From what I just checked, the source tarball is 40MB. Can that much really be added to the Python stdlib? What other alternatives are there, besides wxPython, that are perhaps a bit smaller. Given the above, what do you guys (python-list, not just rantingrick) think fills the spot the best? Well i hope some heavy weights weigh in however i must tell you that it don't happen very often. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 8:59 pm, Corey Richardson kb1...@aim.com wrote: I completely agree! And we should expect it to be even better! What out there is there that meets those requirements? Nothing, and I somewhat doubt there ever will be. Tk is somewhat of an anomaly at this point. Most of the trend in GUI toolkits is to become more HTML/JS/CSS like in nature, which isn't something I personally agree with. I certainly don't think it makes life any easier for the programmer, especially starting out. It might make certain types of applications (e.g., CRUD) easier, but that's not a laudable goal in the least. Mobile and web certainly have their place, but it Python the place for it? Sure, Python can be used as the back-end of web sites, but not up front like Java or Flash (aside from Jython). Especially mobile. Python was not intended for a mobile platform not should it be made to fit that niche. Python has its place, but your cell phone is not it. I don't think that's true per se, but I don't think it's relevant. A single GUI toolkit for traditional computers, for web, and mobile is a difficult task, one that no one has accomplished. MS has gotten closest, and I'd hesitate to call Silverlight a success. Plus, Silverlight is plugin-based rich applications (ala Flash), not HTML/ CSS/Javascript which is what most people mean/want for the web. Adding HTML/CSS/Javascript to the mix takes the problem from bad to awful, in my opinion. I'm sure the various Pyjamas users might take issue with that, but what works best inside a web browser (with its various enforced limitations) isn't what works best inside a client- side application (be it web delivered or not). As a web interface are you thinking something like Java's Swing or something like Django? You pretty clearly need both. There are times when web pages are what I want, there are times when they are inadequate and I need more functionality. You certainly don't want either Swing or Django, though. Given the above, what do you guys (python-list, not just rantingrick) think fills the spot the best? Nothing, but I'm not even convinced the spot needs to be filled. Certainly no one's made an actual case for why, much less how. Regardless, if it's really what you want, you'd have to write it yourself. Personally, while Silverlight has some interesting ideas, I'd recommend not using it as a base, especially if Python is your target language. Would these items inclusion in the stdlib entail unnecessary cruft added on to the size of the stdlib, are they completely cross-platform (as far as Python itself is)? Depends on exactly what you do, but you'd likely end up no bigger than .NET or Java. I'll leave it to others to decide whether that's a good or bad thing. Let's try not to get off track like this thing has been since it was started. That was and rantingrick's goal from the get go and still is his goal. Otherwise, he wouldn't have changed his position three times now and be overdue for a fourth. Otherwise, he would have answered my / your question about why bother putting a minimized version of wxWidgets in the standard library by now as opposed to the whole damn thing. He dodges technical questions because he lacks even the most elementary understanding. He'll do the same to you and only offer absurd platitudes and insults in return, as opposed to actual working technical solutions. Hell, he can't even offer up a consistent problem to solve, and he's honestly over do for changing it altogether.. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 8:27 pm, Corey Richardson kb1...@aim.com wrote: You mentioned having a segment of wxPython in the stdlib earlier. If this actually feasible from a legal standpoint, and would the maintainers of wxPython be willing to put it in the stdlib? Not to mention the wonderful people over at python-dev. This might come as a shock to you, but it really doesn't matter what the wxPython folks think about the inclusion of wxPython into the stdlib. If they are against it (or simply don't care) then they can continue to focus their efforts on the full version. No harm done, really. As far as python-dev is concerned -- it does matter! However if the community wants change, and makes enough noise, they will have no choice either. ;) Why would you add in only a part of wxPython, instead of all of it? see my next answer for detail... Is the work to cut it down really an advantage over the size of the full toolkit? From what I just checked, the source tarball is 40MB. Can that much really be added to the Python stdlib? 40MB is far too big. Much of wxPython is thousands of widgets that have no buisness in the stdlib. We only want a very limited set (much like what Tkinter is composed of now) and then for the people who want to create professional GUI's they can download the full 40MB. The great advantage here is scalability. Tkinter cannot do this. And anybody who alludes to this is a liar. What other alternatives are there, besides wxPython, that are perhaps a bit smaller. Well i am open to any and all alternatives. However no many have been brought forward. My dream would be to have something completely python based, although i realize that the work involved is far too enormous. So we must build from something that already exists. Nothing is really perfect. WxPython IS NOT perfect however it is a step forward. As far as alternative here is a list... http://docs.python.org/faq/gui -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 8:43 pm, Adam Skutt ask...@gmail.com wrote: That was and rantingrick's goal from the get go and still is his goal. Otherwise, he wouldn't have changed his position three times now and be overdue for a fourth. Otherwise, he would have answered my / your question about why bother putting a minimized version of wxWidgets in the standard library by now as opposed to the whole damn thing. You know Adam i was just begining to like you again ;). I HAVE answered that question a many, many times and if you actually take the time to read my posts AND comprhend them you would have found that answer by now. psst! Just recently i answered it again. And no, i will not quote myself for your convince. Get off your lazy butt and find it yourself! [...snip: Character assassination ...] -- http://mail.python.org/mailman/listinfo/python-list
