Cape Town Python Users Group meeting - 22/01/2011
The next Cape Town Python Users Group meeting will be on Saturday, 22nd January, starting at 14:00. We will be using the Events room at the Bandwidth Barn. We'll have a talk on stereoscopic rendering in 3D using Blender via python. See http://www.ctpug.org.za/wiki/Meeting20110122 for more details. -- Neil Muller -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANNOUNCE: PyGTK All-in-one Installer 2.22.6
We are pleased to announce release 2.22.6 of the PyGTK All-in-one installer for Windows. More information can be found in the README file at: https://github.com/dieterv/pygtk-installer#readme * What is it? = The PyGTK All-in-one installer provides an alternative installation method for PyGTK users on Windows. It bundles PyGTK, PyGObject, PyCairo, PyGtkSourceView2, PyGooCanvas, PyRsvg, the gtk+-bundle and Glade in one handy installer. Currently 32 bit Python 2.6 and 2.7 versions are supported on Windows XP and up. Some screenshots can be seen at: https://github.com/dieterv/pygtk-installer/wiki * What's changed in 2.22.6 ? * Updated bundled GTK+ runtime packages to gtk+-bundle_2.22.1-20101227_win32 which fixes the svg pixbuf loader issues described in https://bugzilla.gnome.org/show_bug.cgi?id=637742. * Grammatical fixes to the README and build_installer.py script by David Ripton. * Updated glade3-3.6.7 packages + the build_glade.sh script is now tracked at https://bugzilla.gnome.org/show_bug.cgi?id=634978 The PyGTK, PyGObject, PyCairo, PyGtkSourceView2, PyGooCanvas and PyRsvg extension modules remain unchanged. * Where to get it? == binaries: http://download.gnome.org/binaries/win32/pygtk/2.22/pygtk-all-in-one-2.22.6.win32-py2.6.msi md5sum: 1ce2abcaa4b232e52111a71e937f52e9 size : 32,3M http://download.gnome.org/binaries/win32/pygtk/2.22/pygtk-all-in-one-2.22.6.win32-py2.7.msi md5sum: 75cfe879a13ae99d5b19fee4f1597bb5 size : 32,3M source code of the installer build tool: https://github.com/dieterv/pygtk-installer/tree/release-2.22.6 https://github.com/dieterv/pygtk-installer/tarball/release-2.22.6 https://github.com/dieterv/pygtk-installer/zipball/release-2.22.6 Enjoy! The PyGTK Team -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: [rotatingloghandler]: How to read the logs produced ?
I suggest SyslogHandler in logging package to centralize all logs . http://docs.python.org/library/logging.html#sysloghandler In my opinion, rotating, parsing, filtering logs is a different task (for a sysadmin not a developper). I'm doing this for all my projects at work : - using SyslogHandler for logging application servers - using one syslog server to get all logs from application servers Le Tue, 18 Jan 2011 23:45:36 -0800, Chris Rebert c...@rebertia.com a écrit : On Tue, Jan 18, 2011 at 11:27 PM, Low Kian Seong kianseong@lcalink.com wrote: On Jan 19, 2011, at 3:25 PM, Chris Rebert c...@rebertia.com wrote: On Tue, Jan 18, 2011 at 10:02 PM, low kian seong kianseong@logisticsconsulting.asia wrote: Dear people, I am currently using concurrentrotatingfilehandler to handle my Python logs. The situation is okay when it's only one log, but when it needs to spill over to the next log (I configured to have 2) say test.log.2 then I see that the output is sort of shared between the first log test.log and test.log.2. Am I supposed to concatenate all the logs together to get my logs back ? Google hasn't brought back any results, so I am wondering is it just me using or reading the resultant logs wrong? Since this is apparently a 3rd-party library (http://pypi.python.org/pypi/ConcurrentLogHandler/ ), have you tried asking the maintainer? (Who is evidently Lowell Alleman lowell87 at_sign gmail period com.) Could very well be a bug. Actually the default concurrent log handler produces similar results. That wouldn't be particularly surprising: 15.7.10. Logging to a single file from multiple processes Although logging is thread-safe, and logging to a single file from multiple threads in a single process is supported, logging to a single file from multiple processes is **not** supported [...] -- http://docs.python.org/library/logging.html Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On Jan 18, 4:04 am, Peter Otten __pete...@web.de wrote: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? Portability. Running the '-exec' version will work fine in a directory with a relatively small number of files, but will fail on a large one. 'xargs', which is designed to handle exactly that situations, splits the returned output into chunks that can be handled by 'rm' and such. '|xargs' is always the preferred option when you don't know how large the output is going to be. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: rantingrick rantingr...@gmail.com You know we Python programmers are professional debaters. This has been my take on the Python community. However without the virtues of compromise and community spirit all we are going to do is fight like cats and dogs forever to the very detriment of the very community we wish to muster We need to look at these problems from a community perspective and tone down the rhetoric. The layer of thick sarcasm that exists is so viscous and putrid that any semblance of civility is completely impervious to it's gelatinous all encompassing mass. We need to get more folks involved in the decision process. We need more community discussion and less community corruption. Currently we have a small subset of the community making a large proportion of the decisions. We did have a monarchy ruled by our beloved dictator however it has degenerated into a banana republic! We need democracy and we need it now! Well, those who work have the latest word and they will decide what they will want to do. We can just show our opinions and hope that they will care and take the best decision. The problem is that some people don't care and want to demonstrate that this is very normal and that they are right, which is not good at all. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
From: Stefan Behnel stefan...@behnel.de Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. Stefan Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Octavian Rasnita, 19.01.2011 11:31: From: Stefan Behnel Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. FYI, just take a look at the 'dis' module. There are also decompilers available. IIRC, one is called decompyle. Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? You can use an import hook to do anything you like. That includes decrypting a file and extracting a normal .pyc from it that can then be imported. However, that won't prevent users from inspecting the code at runtime if they get a handle at it (which they likely will if they try). Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On 2011-01-19, Tim Roberts t...@probo.com wrote: Tim Harig user...@ilthio.net wrote: On 2011-01-17, carlo syseng...@gmail.com wrote: 2- If that were true, can you point me to some documentation about the math that, as Mark says, demonstrates this? It is true because UTF-8 is essentially an 8 bit encoding that resorts to the next bit once it exhausts the addressible space of the current byte it moves to the next one. Since the bytes are accessed and assessed sequentially, they must be in big-endian order. You were doing excellently up to that last phrase. Endianness only applies when you treat a series of bytes as a larger entity. That doesn't apply to UTF-8. None of the bytes is more significant than any other, so by definition it is neither big-endian or little-endian. It depends how you process it and it doesn't generally make much difference in Python. Accessing UTF-8 data from C can be much trickier if you use a multibyte type to store the data. In that case, if happen to be on a little-endian architecture, it may be necessary to remember that the data is not in the order that your processor expects it to be for numeric operations and comparisons. That is why the FAQ I linked to says yes to the fact that you can consider UTF-8 to always be in big-endian order. Essentially all byte based data is big-endian. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 3:23 pm, Octavian Rasnita orasn...@gmail.com wrote: 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. If you want functional accessibility support, you're going to have to write it in Python yourself, and get the accessibility manufacturers to support it. All of the cross-platform toolkits have poor to non- existent accessibility support. Accessibility issues aren't going to be fixed by going to a different GUI toolkit in the standard library. The alternative is to fix the accessibility support issues in the underlying library, and Tk is no less amenable to that than wxWidgets. If that's what you want, start coding then. You have a long climb ahead of you. Accessibility will never be a particular good argument for switching toolkits. All of the cross-platform offerings with Python bindings are far too broken to be even remotely interesting. 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). Or we have cross-platform support as a requirement and no desire to develop the GUI interface three times over. Hence the continued popularity of Java GUIs. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 1:37 am, Octavian Rasnita orasn...@gmail.com wrote: The users shouldn't want something better. Everyone should create GUIs which are accessible for everyone by default, without making any special effort for doing this. Accessibility always requires special effort, and I don't see how changing toolkits gets away from this. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 1:37 am, Octavian Rasnita orasn...@gmail.com wrote: Most of the programmers don't know that and they don't even need to know that, but if a lib that create accessible GUIS would be promoted, most of the Python programmers would use that lib and would create good apps by default, without even knowing this. Have you written an accessible application in any toolkit whatsoever? It is not magic, and it does not happen by default, even when solely using the standard widgets. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On Wed, 19 Jan 2011 11:34:53 + (UTC) Tim Harig user...@ilthio.net wrote: That is why the FAQ I linked to says yes to the fact that you can consider UTF-8 to always be in big-endian order. It certainly doesn't. Read better. Essentially all byte based data is big-endian. This is pure nonsense. -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
Considering you post contained no information or evidence for your
negations, I shouldn't even bother responding. I will bite once.
Hopefully next time your arguments will contain some pith.
On 2011-01-19, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 19 Jan 2011 11:34:53 + (UTC)
Tim Harig user...@ilthio.net wrote:
That is why the FAQ I linked to
says yes to the fact that you can consider UTF-8 to always be in big-endian
order.
It certainly doesn't. Read better.
- Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If
- yes, then can I still assume the remaining UTF-8 bytes are in big-endian
^^
- order?
^^
-
- A: Yes, UTF-8 can contain a BOM. However, it makes no difference as
^^^
- to the endianness of the byte stream. UTF-8 always has the same byte
^^
- order. An initial BOM is only used as a signature -- an indication that
^^
- an otherwise unmarked text file is in UTF-8. Note that some recipients of
- UTF-8 encoded data do not expect a BOM. Where UTF-8 is used transparently
- in 8-bit environments, the use of a BOM will interfere with any protocol
- or file format that expects specific ASCII characters at the beginning,
- such as the use of #! of at the beginning of Unix shell scripts.
The question that was not addressed was whether you can consider UTF-8
to be little endian. I pointed out why you cannot always make that
assumption in my previous post.
UTF-8 has no apparent endianess if you only store it as a byte stream.
It does however have a byte order. If you store it using multibytes
(six bytes for all UTF-8 possibilites) , which is useful if you want
to have one storage container for each letter as opposed to one for
each byte(1), the bytes will still have the same order but you have
interrupted its sole existance as a byte stream and have returned it
to the underlying multibyte oriented representation. If you attempt
any numeric or binary operations on what is now a multibyte sequence,
the processor will interpret the data using its own endian rules.
If your processor is big-endian, then you don't have any problems.
The processor will interpret the data in the order that it is stored.
If your processor is little endian, then it will effectively change the
order of the bytes for its own evaluation.
So, you can always assume a big-endian and things will work out correctly
while you cannot always make the same assumption as little endian
without potential issues. The same holds true for any byte stream data.
That is why I say that byte streams are essentially big endian. It is
all a matter of how you look at it.
I prefer to look at all data as endian even if it doesn't create
endian issues because it forces me to consider any endian issues that
might arise. If none do, I haven't really lost anything. If you simply
assume that any byte sequence cannot have endian issues you ignore the
possibility that such issues might not arise. When an issue like the
above does, you end up with a potential bug.
(1) For unicode it is probably better to convert to characters to
UTF-32/UCS-4 for internal processing; but, creating a container large
enough to hold any length of UTF-8 character will work.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
Octavian, Thank you for clearly articulating your concern that Tk does not provide any support for screen readers. While I believe that people can have legitimate differences of opinion as to whether this merits its removal/replacement from stdlib, there is no question that this is a serious and significant limitation of Tk. I will attempt to find out if there has been any work done in this area with Tk, and what it would take to address this important issue. Thanks again Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On Wed, 19 Jan 2011 14:00:13 + (UTC) Tim Harig user...@ilthio.net wrote: - Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If - yes, then can I still assume the remaining UTF-8 bytes are in big-endian ^^ - order? ^^ - - A: Yes, UTF-8 can contain a BOM. However, it makes no difference as ^^^ - to the endianness of the byte stream. UTF-8 always has the same byte ^^ - order. ^^ Which certainly doesn't mean that byte order can be called big endian for any recognized definition of the latter. Similarly, ASCII test has its own order which certainly can't be characterized as either little endian or big endian. UTF-8 has no apparent endianess if you only store it as a byte stream. It does however have a byte order. If you store it using multibytes (six bytes for all UTF-8 possibilites) , which is useful if you want to have one storage container for each letter as opposed to one for each byte(1) That's a ridiculous proposition. Why would you waste so much space? UTF-8 exists *precisely* so that you can save space with most scripts. If you are ready to use 4+ bytes per character, just use UTF-32 which has much nicer properties. Bottom line: you are not describing UTF-8, only your own foolish interpretation of it. UTF-8 does not have any endianness since it is a byte stream and does not care about machine words. Antoine. -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On Tue, 18 Jan 2011 00:58:14 -0800, jmfauth wrote: It is now practically impossible to launch a Python application via a .pyc file. When has that ever been possible? .pyc files are Python byte-code. You can't run them directly using Python (except via the import machinery), you can't run them as a script, they're not machine code. Unless you write a wrapper to import the file as a module, you can't directly execute .pyc files. (For the fun, try to add the parent directory of a cached file to the sys.path). I don't understand what you're getting at there. 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. I will say that in general I'm not very happy with what seems like every second application creating huge disk caches in random locations. It's a PITA, and I wish they'd standardize on a single cache location, to make it easy to exclude them from backups, to sanitize the bred-crumbs and data trails applications leave, and so forth. But having said that, the __pycache__ idea isn't too bad. If you have this directory structure: ./module.py ./module.pyc and import module, the top-level .pyc file will continue to be used. If you delete module.py, leaving only the top-level .pyc, it will still continue to be used. That much hasn't changed. The only difference is if you start with only a .py file: ./module.py and import it, the cached version will be placed into __pycache__ instead. Unlike orphaned .pyc files in the top level, orphaned .pyc in the __pycache__ are considered stale and will be ignored. So they're safe to ignore, and safe to delete, at any time. Nothing is stopping you from moving the .pyc file into the top level and deleting the .py file, if you so desire. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!)
Mark/Octavian, It sounds like Tka11y (spelled with the digit '1' vs. the letter 'L') addresses this problem for Linux users. According to its website, adding accessability support is as simple as changing one import statement. Details follow my signature. Malcolm Tka11y - Tk Accessibility http://tkinter.unpythonic.net/wiki/Tka11y quote Note: Currently, accessibility is only available via ATK = AT-SPI on Linux. Sorry, no Windows MSAA support. Download http://pypi.python.org/pypi/Tka11y A modification to Tkinter to make widgets visible to the AT-SPI layer so that tools like dogtail and Accerciser can see them. Tka11y uses Papi, the Python Accessibility Programming Interface, which in turn uses ATK, the GNOME Accessibility Toolkit, to expose Tkinter widgets to AT-SPI, the Assistive Technologies Service Provider Interface. This allows a Tkinter application's widgets to be viewed and/or controlled by a variety of assistive technologies such as Orca and Accerciser, and automated GUI testing tools such as dogtail and LDTP. These client tools usually use either cspi (C) or pyatspi (Python). Typical usage: import Tka11y as Tkinter or from Tka11y import * /quote -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On 19 Jan 2011 14:42:14 GMT Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 18 Jan 2011 00:58:14 -0800, jmfauth wrote: It is now practically impossible to launch a Python application via a .pyc file. When has that ever been possible? .pyc files are Python byte-code. You can't run them directly using Python (except via the import machinery), you can't run them as a script, they're not machine code. Unless you write a wrapper to import the file as a module, you can't directly execute .pyc files. It seems to work here: $ echo print 'foo' toto.py $ python -m compileall -l . Listing . ... Compiling ./toto.py ... $ rm toto.py $ python toto.pyc foo But it still works under 3.2 even though the incantation is less pretty: $ echo import sys; print(sys.version) toto.py $ __svn__/python -m compileall -l . Listing . ... Compiling ./toto.py ... $ rm toto.py $ __svn__/python __pycache__/toto.cpython-32.pyc 3.2rc1+ (py3k:88095M, Jan 18 2011, 17:12:15) [GCC 4.4.3] Regards Antoine. -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On Jan 19, 9:00 am, Tim Harig user...@ilthio.net wrote: So, you can always assume a big-endian and things will work out correctly while you cannot always make the same assumption as little endian without potential issues. The same holds true for any byte stream data. You need to spend some serious time programming a serial port or other byte/bit-stream oriented interface, and then you'll realize the folly of your statement. That is why I say that byte streams are essentially big endian. It is all a matter of how you look at it. It is nothing of the sort. Some byte streams are in fact, little endian: when the bytes are combined into larger objects, the least- significant byte in the object comes first. A lot of industrial/ embedded stuff has byte streams with LSB leading in the sequence, CAN comes to mind as an example. The only way to know is for the standard describing the stream to tell you what to do. I prefer to look at all data as endian even if it doesn't create endian issues because it forces me to consider any endian issues that might arise. If none do, I haven't really lost anything. If you simply assume that any byte sequence cannot have endian issues you ignore the possibility that such issues might not arise. No, you must assume nothing unless you're told how to combine the bytes within a sequence into a larger element. Plus, not all byte streams support such operations! Some byte streams really are just a sequence of bytes and the bytes within the stream cannot be meaningfully combined into larger data types. If I give you a series of 8-bit (so 1 byte) samples from an analog-to-digital converter, tell me how to combine them into a 16, 32, or 64-bit integer. You cannot do it without altering the meaning of the samples; it is a completely non-nonsensical operation. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On 2011-01-19, geremy condra debat...@gmail.com wrote: On Tue, Jan 18, 2011 at 3:54 PM, rantingrick rantingr...@gmail.com wrote: 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? There's no chain of command here, genius. It's a mailing list. And an unmoderated Usenet newsgroup (which has even less of a chain of command than a mailing list). -- Grant Edwards grant.b.edwardsYow! I hope something GOOD at came in the mail today so gmail.comI have a REASON to live!! -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On 2011-01-19, Adam Skutt ask...@gmail.com wrote: On Jan 19, 9:00 am, Tim Harig user...@ilthio.net wrote: That is why I say that byte streams are essentially big endian. It is all a matter of how you look at it. It is nothing of the sort. Some byte streams are in fact, little endian: when the bytes are combined into larger objects, the least- significant byte in the object comes first. A lot of industrial/ embedded stuff has byte streams with LSB leading in the sequence, CAN comes to mind as an example. You are correct. Point well made. -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On 2011-01-19, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Jan 2011 14:00:13 + (UTC) Tim Harig user...@ilthio.net wrote: UTF-8 has no apparent endianess if you only store it as a byte stream. It does however have a byte order. If you store it using multibytes (six bytes for all UTF-8 possibilites) , which is useful if you want to have one storage container for each letter as opposed to one for each byte(1) That's a ridiculous proposition. Why would you waste so much space? Space is only one tradeoff. There are many others to consider. I have created data structures with much higher overhead than that because they happen to make the problem easier and significantly faster for the operations that I am performing on the data. For many operations, it is just much faster and simpler to use a single character based container opposed to having to process an entire byte stream to determine individual letters from the bytes or to having adaptive size containers to store the data. UTF-8 exists *precisely* so that you can save space with most scripts. UTF-8 has many reasons for existing. One of the biggest is that it is compatible for tools that were designed to process ASCII and other 8bit encodings. If you are ready to use 4+ bytes per character, just use UTF-32 which has much nicer properties. I already mentioned UTF-32/UCS-4 as a probable alternative; but, I might not want to have to worry about converting the encodings back and forth before and after processing them. That said, and more importantly, many variable length byte streams may not have alternate representations as unicode does. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Adam Skutt ask...@gmail.com On Jan 18, 3:23 pm, Octavian Rasnita orasn...@gmail.com wrote: 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. If you want functional accessibility support, you're going to have to write it in Python yourself, and get the accessibility manufacturers to support it. All of the cross-platform toolkits have poor to non- existent accessibility support. Accessibility issues aren't going to be fixed by going to a different GUI toolkit in the standard library. Not true. WxPython uses wxWIDGETS which uses the default OS widgets which usually offer the accessibility features. (At least under Windows, but most users that need accessibility use Windows anyway). The alternative is to fix the accessibility support issues in the underlying library, and Tk is no less amenable to that than wxWidgets. If that's what you want, start coding then. You have a long climb ahead of you. The underlying libraries for Windows offer the necessary accessibility and WxPython uses it, but Tkinter uses Tk not those libraries. Accessibility will never be a particular good argument for switching toolkits. All of the cross-platform offerings with Python bindings are far too broken to be even remotely interesting. WxPython is not perfect but most of the objects it offers are accessible so this is not true. Only Tk and GTK are bad. 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). Or we have cross-platform support as a requirement and no desire to develop the GUI interface three times over. Hence the continued popularity of Java GUIs. Java GUIS are accessible. Maybe that's the reason. SWT offers the same kind of accessibility as WxPython and for SWING there is Java Access Bridge. So they are not as accessible as the native Windows GUI objects, but they are accessible, unlike Tk and GTK which are not. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Adam Skutt ask...@gmail.com On Jan 19, 1:37 am, Octavian Rasnita orasn...@gmail.com wrote: Most of the programmers don't know that and they don't even need to know that, but if a lib that create accessible GUIS would be promoted, most of the Python programmers would use that lib and would create good apps by default, without even knowing this. Have you written an accessible application in any toolkit whatsoever? It is not magic, and it does not happen by default, even when solely using the standard widgets. Adam Of course I did. Using WxPerl, Win32::GUI Perl module, SWT and DotNet. (And without doing absolutely anything special for making them accessible). But it is very simple to test this. You can download a demo version of JAWS screen reader from www.freedomscientific.com that will run for 40 minutes or so and then you will need to reboot the computer to make it work again. It is the most used and most powerful screen reader. You will be able to see how accessible (or not accessible) are the applications made with any GUI lib. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Mark Roseman m...@markroseman.com Octavian, Thank you for clearly articulating your concern that Tk does not provide any support for screen readers. While I believe that people can have legitimate differences of opinion as to whether this merits its removal/replacement from stdlib, there is no question that this is a serious and significant limitation of Tk. I will attempt to find out if there has been any work done in this area with Tk, and what it would take to address this important issue. Thanks again Mark Thank you Mark. I don't have anything against Tk, Gtk or QT or other GUI libs, but I just shown why some interfaces are much better than others, for very important reasons, which unfortunately can't be seen, so many programmers don't know about them and promote the discrimination without wanting to do that. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Adam Skutt ask...@gmail.com On Jan 19, 1:37 am, Octavian Rasnita orasn...@gmail.com wrote: The users shouldn't want something better. Everyone should create GUIs which are accessible for everyone by default, without making any special effort for doing this. Accessibility always requires special effort, and I don't see how changing toolkits gets away from this. Adam This is the most false thing I ever heard and the most dangerous. The GUIS like wxWIDGETS and SWT (at least under Windows), Win32 GUI, MFC, WindowsForms (.Net), are accessible out of the box and they don't require any effort from the programmer. The programmer doesn't even know that the application will also offer accessibility features. Java SWING is not accessible out of the box, but Sun offers Java Access Bridge, a program which can be installed by the user which needs accessibility, so finally SWING GUIS are also pretty accessible (also without any effort from the programmer). (Which is not the case of Tk, Gtk and QT.) Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On Wed, 19 Jan 2011 16:03:11 + (UTC) Tim Harig user...@ilthio.net wrote: For many operations, it is just much faster and simpler to use a single character based container opposed to having to process an entire byte stream to determine individual letters from the bytes or to having adaptive size containers to store the data. You *have* to process the entire byte stream in order to determine boundaries of individual letters from the bytes if you want to use a character based container, regardless of the exact representation. Once you do that it shouldn't be very costly to compute the actual code points. So, much faster sounds a bit dubious to me; especially if you factor in the cost of memory allocation, and the fact that a larger container will fit less easily in a data cache. That said, and more importantly, many variable length byte streams may not have alternate representations as unicode does. This whole thread is about UTF-8 (see title) so I'm not sure what kind of relevance this is supposed to have. -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
My nightmare was mainly due, because when I read the the What's new?, I did not understand too much this caching stuff. It's only later, after testing some applications, I really got the surprise to understand it. (Py3.1 and Py3.2 pyc's mixture). Having said this, to tell you the truth. I do really not feel comfortable with it -- two working directories, a subdir in a working dir containing only a few scripts, filenames, cache multiplications (I would have 1202 caches on my hd now). There are certainly advantages, just wondering if the balance is positive ou negative. Just for the story, I'm already somwehow experencing some funny stuff. My test working dir has already a full bloated cache. You may argue, that's my fault. I may reply: bof, that Python which is doing it...) (As a Windows users, I just wondering how this will impact tools like py2exe or cx_freeze). - Antoine Pitrou Yes, I can launch a pyc, when I have a single file. But what happens, if one of your cached .pyc file import a module with a name as defined in the parent directory? The machinery is broken. The parent dir is not in the sys.path. (Unless I'm understanding nothing or I have done a huge mistake in my tests). jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!)
From: pyt...@bdurham.com Mark/Octavian, It sounds like Tka11y (spelled with the digit '1' vs. the letter 'L') addresses this problem for Linux users. According to its website, adding accessability support is as simple as changing one import statement. Details follow my signature. Malcolm Tka11y - Tk Accessibility http://tkinter.unpythonic.net/wiki/Tka11y quote Note: Currently, accessibility is only available via ATK = AT-SPI on Linux. Sorry, no Windows MSAA support. This project is good, a step ahead, but in order to be really useful it should be the one provided by the default Python package. And of course, it should also offer support for Windows, since most of the computer users use Windows, especially those who need accessibility features. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 10:41 am, Octavian Rasnita orasn...@gmail.com wrote: Not true. WxPython uses wxWIDGETS which uses the default OS widgets which usually offer the accessibility features. (At least under Windows, but most users that need accessibility use Windows anyway). Right, under Windows, which is a problem. By your line of reasoning, you really should be supporting PySide / PyQt and not wxWidgets, since they at least play at cross-platform support. The alternative is to fix the accessibility support issues in the underlying library, and Tk is no less amenable to that than wxWidgets. If that's what you want, start coding then. You have a long climb ahead of you. The underlying libraries for Windows offer the necessary accessibility and WxPython uses it, but Tkinter uses Tk not those libraries. wxWidgets' support is completely inadequate for a true cross-platform system, the developers are aware of this and acknowledge this and believe a rewrite is necessary. Thus, it is currently really in no better state than Tk. Or we have cross-platform support as a requirement and no desire to develop the GUI interface three times over. Hence the continued popularity of Java GUIs. Java GUIS are accessible. Maybe that's the reason. No, the reason is as I stated, no more, no less. Accessibility doesn't enter into most designs. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 11:09 am, Octavian Rasnita orasn...@gmail.com wrote: From: Adam Skutt ask...@gmail.com Accessibility always requires special effort, and I don't see how changing toolkits gets away from this. This is the most false thing I ever heard and the most dangerous. O RLY? http://www.wxwidgets.org/docs/technote/wxaccesstips.htm sure looks like there's a whole host of things that I, the application programmer, must do manually to enable an accessible application[1]. I can't just plop down controls and have an accessible application. The programmer doesn't even know that the application will also offer accessibility features. No, accessibility requires consideration in the design and implementation of the GUIs, in all of those toolkits. It is not transparent, nor can it be transparent. It requires both consideration when laying out the widgets, but also ensuring that the widgets have specific properties set. How many applications have you ever used that had focus order bugs? That's an accessibility issue that requires programmer intervention to get right. Adam [1] That list is not comprehensive by a long shot. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2011-01-19, Octavian Rasnita orasn...@gmail.com wrote: From: Adam Skutt ask...@gmail.com If you want functional accessibility support, you're going to have to write it in Python yourself, and get the accessibility manufacturers to support it. All of the cross-platform toolkits have poor to non- existent accessibility support. Accessibility issues aren't going to be fixed by going to a different GUI toolkit in the standard library. Not true. WxPython uses wxWIDGETS which uses the default OS widgets There's no such thing as default OS widgets on Linux/Unix/BSD/etc. which usually offer the accessibility features. (At least under Windows, but most users that need accessibility use Windows anyway). [...] WxPython is not perfect but most of the objects it offers are accessible so this is not true. Only Tk and GTK are bad. On all of my computers, wxPython uses Gtk. There are other choices for wxWidget backends on Linux, but Gtk is by far the most common. IOW, if Gtk is bad, then wxPython is bad. -- Grant Edwards grant.b.edwardsYow! People humiliating at a salami! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita orasn...@gmail.com wrote: From: Stefan Behnel stefan...@behnel.de Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. Stefan Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? Octavian The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Detecting Remaining Thread
Hi, I've been trying to track down a familiar concurrency problem without any success: Unhandled exception in thread started by Error in sys.excepthook: Original exception was: I realize that this is due to a background thread still being alive and kicking when the application terminates (ie, a missing join() on a helper thread). However, threading.enumerate() is reporting that nothing except for the main thread is running at that point: 1/19/2011 09:30:41 [INFO] Arm is shutting down. Remaining threads: [_MainThread(MainThread, started -1217079616)] What other methods are there for troubleshooting this sort of issue? I've triple checked that my threads are daemons and joined when quitting but I must be missing something... As would be expected of a timing issue, this happens intermittently (1/5 of the time) and goes away if I add a short sleep at the end. Any help would be much appreciated. Thanks! -Damian -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
H₂0.py okop...@gmail.com writes: On Jan 18, 4:04 am, Peter Otten __pete...@web.de wrote: What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'? Portability. Running the '-exec' version will work fine in a directory with a relatively small number of files, but will fail on a large one. How? -exec passes each file name to a separate invocation of the given command - it doesn't build one large command line with multiple args. sherm-- -- Sherm Pendley http://camelbones.sourceforge.net Cocoa Developer -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On Wed, 19 Jan 2011 08:30:12 -0800 (PST) jmfauth wxjmfa...@gmail.com wrote: Yes, I can launch a pyc, when I have a single file. But what happens, if one of your cached .pyc file import a module with a name as defined in the parent directory? The machinery is broken. The parent dir is not in the sys.path. Well, you don't have to launch a pyc file anyway. Put all your code in some (pyc) modules on the standard Python path, and use a clear-text script with some trivial code to invoke a function from the compiled modules. Otherwise you can customize sys.path a little from your script, using __file__ and os.path.dirname. Nothing complicated AFAICT. (by the way, the fact that pyc files are version-specific should discourage any use outside of version-specific directories, e.g. /usr/lib/pythonX.Y/site-packages) Regards Antoine. -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On 2011-01-19, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Jan 2011 16:03:11 + (UTC) Tim Harig user...@ilthio.net wrote: For many operations, it is just much faster and simpler to use a single character based container opposed to having to process an entire byte stream to determine individual letters from the bytes or to having adaptive size containers to store the data. You *have* to process the entire byte stream in order to determine boundaries of individual letters from the bytes if you want to use a character based container, regardless of the exact representation. Right, but I only have to do that once. After that, I can directly address any piece of the stream that I choose. If I leave the information as a simple UTF-8 stream, I would have to walk the stream again, I would have to walk through the the first byte of all the characters from the beginning to make sure that I was only counting multibyte characters once until I found the character that I actually wanted. Converting to a fixed byte representation (UTF-32/UCS-4) or separating all of the bytes for each UTF-8 into 6 byte containers both make it possible to simply index the letters by a constant size. You will note that Python does the former. UTF-32/UCS-4 conversion is definitly supperior if you are actually doing any major but it adds the complexity and overhead of requiring the bit twiddling to make the conversions (once in, once again out). Some programs don't really care enough about what the data actually contains to make it worth while. They just want to be able to use the characters as black boxes. Once you do that it shouldn't be very costly to compute the actual code points. So, much faster sounds a bit dubious to me; especially if you You could I suppose keep a separate list of pointers to each letter so that you could use the pointer list for indexing or keep a list of the character sizes so that you can add them and calculate the variable width index; but, that adds overhead as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On Wed, 19 Jan 2011 18:02:22 + (UTC) Tim Harig user...@ilthio.net wrote: On 2011-01-19, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Jan 2011 16:03:11 + (UTC) Tim Harig user...@ilthio.net wrote: For many operations, it is just much faster and simpler to use a single character based container opposed to having to process an entire byte stream to determine individual letters from the bytes or to having adaptive size containers to store the data. You *have* to process the entire byte stream in order to determine boundaries of individual letters from the bytes if you want to use a character based container, regardless of the exact representation. Right, but I only have to do that once. You only have to decode once as well. If I leave the information as a simple UTF-8 stream, That's not what we are talking about. We are talking about the supposed benefits of your 6-byte representation scheme versus proper decoding into fixed width code points. UTF-32/UCS-4 conversion is definitly supperior if you are actually doing any major but it adds the complexity and overhead of requiring the bit twiddling to make the conversions (once in, once again out). Bit twiddling is not something processors are particularly bad at. Actually, modern processors are much better at arithmetic and logic than at recovering from mispredicted branches, which seems to suggest that discovering boundaries probably eats most of the CPU cycles. Converting to a fixed byte representation (UTF-32/UCS-4) or separating all of the bytes for each UTF-8 into 6 byte containers both make it possible to simply index the letters by a constant size. You will note that Python does the former. Indeed, Python chose the wise option. Actually, I'd be curious of any real-world software which successfully chose your proposed approach. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 18, 9:54 pm, Adam Skutt ask...@gmail.com wrote: On Jan 18, 9:27 pm, Corey Richardson kb1...@aim.com wrote: At which point, it's pretty damn small. Not as small as all of the Tk functionality, I think, but well under 10MiB compressed. Yea but look at all your gaining. I would rather sacrifice a few megs for the rich functionality and scalability any day. The problem to me isn't the size (though some might find it objectionable), but the system dependencies you have to take: wxWidgets requires GTK+ on UNIX UNIX? are you kidding? Even if these dependancies are needed the UNIX folks are damn capable of finding and installing them with great ease. Besides most ship with this out the box already! We are not talking about the lemmings who use windows or even the weekend linuxers here. If they are using UNIX then there is no need for hand holding. , which requires a whole mess of crap in term, plus swig, plus whatever else I may or may not be missing. Thats quite an exaggeration Adam. I'm also not 100% certain as to whether it's as portable as Tk is today. Wx is just as portable as Tk -- http://mail.python.org/mailman/listinfo/python-list Now I think I understand a little better where you all are coming from -- I am a Unix person and I guess I expected to have to learn GUI's using whatever is provided for me by default. Which isn't a bad thing. And if I had to add additional software - and learn that - so be it. I am using a Windows XP system and a Windows 7 system presently. Some day I would like to switch out the Windows XP for Unix. Thanks for the link to the Python page about the various packages, that was enlightening. Who or what group is actually in charge of what libraries (and programming commands/methods such as the Python 3.x rewrite of 'print') goes into Python? Is this huge discussion really a few feature requests for additional libraries to be included for Windows programming? And aren't some of these libraries developed by 3rd parties? And how is that handled by the people in charge? Do they have to pay to license it or is this all freely contributed software? Patty -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On Jan 19, 7:03 pm, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Jan 2011 08:30:12 -0800 (PST) jmfauth wxjmfa...@gmail.com wrote: Yes, I can launch a pyc, when I have a single file. But what happens, if one of your cached .pyc file import a module with a name as defined in the parent directory? The machinery is broken. The parent dir is not in the sys.path. Well, you don't have to launch a pyc file anyway. Put all your code in some (pyc) modules on the standard Python path, and use a clear-text script with some trivial code to invoke a function from the compiled modules. That's not the point. I'm toying. And the behaviour from now is deeply different from what it was. Otherwise you can customize sys.path a little from your script, using __file__ and os.path.dirname. Nothing complicated AFAICT. That's not as simple. You have too prepare the py file in such a way, that it recognizes the path of its ancestor py file. The home dir is no more the same. (by the way, the fact that pyc files are version-specific should discourage any use outside of version-specific directories, e.g. /usr/lib/pythonX.Y/site-packages) Here we are. I'm just wondering if all this stuff is not just here in order to satisfy the missmatched Python installation on *x platforms compared to Windows whre each Python version lives cleanely in its isolated space. (Please no os war). jmf compared to -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 2011-01-19, geremy condra debat...@gmail.com wrote: On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita orasn...@gmail.com wrote: Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. And they somehow usually end up being an annoyance to customers who are not trying to reverse engineer your code but are merely trying to use it legally. -- Grant Edwards grant.b.edwardsYow! I'd like MY data-base at JULIENNED and stir-fried! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On 2011-01-19, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Jan 2011 18:02:22 + (UTC) Tim Harig user...@ilthio.net wrote: Converting to a fixed byte representation (UTF-32/UCS-4) or separating all of the bytes for each UTF-8 into 6 byte containers both make it possible to simply index the letters by a constant size. You will note that Python does the former. Indeed, Python chose the wise option. Actually, I'd be curious of any real-world software which successfully chose your proposed approach. The point is basically the same. I created an example because it was simpler to follow for demonstration purposes then an actual UTF-8 conversion to any official multibyte format. You obviously have no other purpose then to be contrary, so we ended up following tangents. As soon as you start to convert to a multibyte format the endian issues occur. For UTF-8 on big endian hardware, this is anti-climactic because all of the bits are already stored in proper order. Little endian systems will probably convert to a native native endian format. If you choose to ignore that, that is your perogative. Have a nice day. -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On Jan 19, 6:42 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: But having said that, the __pycache__ idea isn't too bad. If you have this directory structure: ./module.py ./module.pyc and import module, the top-level .pyc file will continue to be used. Nope. PEP 3147 says it now always uses __pycache__. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, Jan 19, 2011 at 10:22 AM, pa...@cruzio.com wrote: Now I think I understand a little better where you all are coming from -- I am a Unix person and I guess I expected to have to learn GUI's using whatever is provided for me by default. Which isn't a bad thing. And if I had to add additional software - and learn that - so be it. I am using a Windows XP system and a Windows 7 system presently. Some day I would like to switch out the Windows XP for Unix. Just dual boot, it isn't hard. Thanks for the link to the Python page about the various packages, that was enlightening. Who or what group is actually in charge of what libraries (and programming commands/methods such as the Python 3.x rewrite of 'print') goes into Python? Python's developers. There isn't really any other formal structure beyond that. Is this huge discussion really a few feature requests for additional libraries to be included for Windows programming? No, it's about other operating systems too, but what it comes down to is that rantingrick has been on the warpath about tkinter for a while, and hasn't proposed a particularly viable alternative. The sad thing is that if he weren't so unhinged his proposal would probably fare much better- I know I And aren't some of these libraries developed by 3rd parties? Any library to replace tkinter would come from a third party, yes. And how is that handled by the people in charge? Again, there aren't really people 'in charge' on this. Whoever wanted to push for this would have to do the legwork to make sure that the library on offer was good enough to win a lot of support from the community, was cross-platform, etc. They'd also have to convince someone with commit privs that it was a great idea, convince the rest of the dev group not to oppose it. After that would come the difficult task of slowly phasing tkinter out, which would involve substantial long-term commitment. In other words, whoever wants to push for this is in for a hard, multi-year slog. Nobody has stepped up to the plate to do any real work towards that goal. Do they have to pay to license it or is this all freely contributed software? I can't imagine non-free code making it in. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, Jan 19, 2011 at 11:37 AM, geremy condra debat...@gmail.com wrote: No, it's about other operating systems too, but what it comes down to is that rantingrick has been on the warpath about tkinter for a while, and hasn't proposed a particularly viable alternative. The sad thing is that if he weren't so unhinged his proposal would probably fare much better- I know I Sorry for the truncation. I was going to say that I know I would be more supportive of it if he was building support for something instead of tearing everything else down. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On Wed, 19 Jan 2011 19:18:49 + (UTC) Tim Harig user...@ilthio.net wrote: On 2011-01-19, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Jan 2011 18:02:22 + (UTC) Tim Harig user...@ilthio.net wrote: Converting to a fixed byte representation (UTF-32/UCS-4) or separating all of the bytes for each UTF-8 into 6 byte containers both make it possible to simply index the letters by a constant size. You will note that Python does the former. Indeed, Python chose the wise option. Actually, I'd be curious of any real-world software which successfully chose your proposed approach. The point is basically the same. I created an example because it was simpler to follow for demonstration purposes then an actual UTF-8 conversion to any official multibyte format. You obviously have no other purpose then to be contrary [...] Right. You were the one who jumped in and tried to lecture everyone on how UTF-8 was big-endian, and now you are abandoning the one esoteric argument you found in support of that. As soon as you start to convert to a multibyte format the endian issues occur. Ok. Good luck with your endian issues which don't exist. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
On 20 January 2011 06:16, Grant Edwards invalid@invalid.invalid wrote: On 2011-01-19, geremy condra debat...@gmail.com wrote: On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita orasn...@gmail.com wrote: Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. And they somehow usually end up being an annoyance to customers who are not trying to reverse engineer your code but are merely trying to use it legally. Absolutely. If you feel you absolutely *must* obfuscate your object code more than the python bytecode, just put it all into a separate module and compile it with Cython http://cython.org/. Then you end up with machine-specific object code which is somewhat harder to reverse engineer for most people (but quite a few people are experts at doing so). As a bonus, Cython might speed it up too. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
- Original Message - From: geremy condra debat...@gmail.com To: pa...@cruzio.com Cc: rantingrick rantingr...@gmail.com; python-list@python.org Sent: Wednesday, January 19, 2011 11:37 AM Subject: Re: Tkinter: The good, the bad, and the ugly! On Wed, Jan 19, 2011 at 10:22 AM, pa...@cruzio.com wrote: Now I think I understand a little better where you all are coming from -- I am a Unix person and I guess I expected to have to learn GUI's using whatever is provided for me by default. Which isn't a bad thing. And if I had to add additional software - and learn that - so be it. I am using a Windows XP system and a Windows 7 system presently. Some day I would like to switch out the Windows XP for Unix. Just dual boot, it isn't hard. True. I have a Compaq Presario that is so old hardware-wise that I don't think it could handle Unix or Linux. Thanks for the link to the Python page about the various packages, that was enlightening. Who or what group is actually in charge of what libraries (and programming commands/methods such as the Python 3.x rewrite of 'print') goes into Python? Python's developers. There isn't really any other formal structure beyond that. Is this huge discussion really a few feature requests for additional libraries to be included for Windows programming? No, it's about other operating systems too, but what it comes down to is that rantingrick has been on the warpath about tkinter for a while, and hasn't proposed a particularly viable alternative. The sad thing is that if he weren't so unhinged his proposal would probably fare much better- I know I And aren't some of these libraries developed by 3rd parties? Any library to replace tkinter would come from a third party, yes. And how is that handled by the people in charge? Again, there aren't really people 'in charge' on this. Whoever wanted to push for this would have to do the legwork to make sure that the library on offer was good enough to win a lot of support from the community, was cross-platform, etc. They'd also have to convince someone with commit privs that it was a great idea, convince the rest of the dev group not to oppose it. After that would come the difficult task of slowly phasing tkinter out, which would involve substantial long-term commitment. In other words, whoever wants to push for this is in for a hard, multi-year slog. Nobody has stepped up to the plate to do any real work towards that goal. Do they have to pay to license it or is this all freely contributed software? I can't imagine non-free code making it in. Geremy Condra From my past experience - I think you are right, this is the course of events that would have to happen and yes, it would literally take years. Patty -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 1/19/2011 11:37 AM geremy condra said... On Wed, Jan 19, 2011 at 10:22 AM,pa...@cruzio.com wrote: snip And aren't some of these libraries developed by 3rd parties? Any library to replace tkinter would come from a third party, yes. And how is that handled by the people in charge? Again, there aren't really people 'in charge' on this. Whoever wanted to push for this would have to do the legwork to make sure that the library on offer was good enough to win a lot of support from the community, was cross-platform, etc. They'd also have to convince someone with commit privs that it was a great idea, convince the rest of the dev group not to oppose it. ... and that they'd forevermore support it, which is likely to be as much of an obstacle. I suspect that's why even established libraries like PIL, numpy, mxDateTime or win32all never made it into the standard library. Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On Wed, 19 Jan 2011 16:00:20 +0100, Antoine Pitrou wrote:
.pyc files are Python byte-code. You can't run them directly using
Python (except via the import machinery), you can't run them as a
script, they're not machine code. Unless you write a wrapper to import
the file as a module, you can't directly execute .pyc files.
It seems to work here:
[snip incantation]
Then I stand corrected, thank you.
I know I've seen problems executing .pyc files from the shell in the
past... perhaps I was conflating details of something else. Ah, I know!
[steve@sylar ~]$ chmod u+x toto.pyc
[steve@sylar ~]$ ./toto.pyc
: command not found ��
./toto.pyc: line 2: syntax error near unexpected token `('
./toto.pyc: line 2: `P7Mc@s dGHdS(tfooNs./
toto.pymodules'
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
From: geremy condra debat...@gmail.com On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita orasn...@gmail.com wrote: From: Stefan Behnel stefan...@behnel.de Octavian Rasnita, 19.01.2011 07:10: aren't the Pyton bytecode-compiled files considered secure enough? Can they be easily decompiled? Yes. Stefan Would it be hard to introduce the possibility of adding encryption of the bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for Perl? Octavian The iron law of cryptography: there is no cryptographic solution to a problem in which the attacker and intended recipient are the same person. Schemes like this are at most an annoyance to people willing to reverse engineer your code. Geremy Condra I don't know how the Python bytecode works... how it is executed. I thought that Python parses the .py file and generates the bytecode that doesn't contain all the necessary information for re-creating the source code. (But that I agree, that might mean real compilation which is not the case...) Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Adam Skutt ask...@gmail.com wxWidgets' support is completely inadequate for a true cross-platform system, the developers are aware of this and acknowledge this and believe a rewrite is necessary. Thus, it is currently really in no better state than Tk. It depends on what you mean by a true cross-platform system. wxWIDGETS run on more platforms, so it is cross-platform and it is also accessible for more categories of users. Other systems are bad not only because they are not accessible for everyone, but also because they don't use the underlying GUI of the operating system they are used on, so they have a different look and feel. Even the accessibility, the possibility of accessing the GUIs with a keyboard also means look and feel. Or we have cross-platform support as a requirement and no desire to develop the GUI interface three times over. Hence the continued popularity of Java GUIs. Java GUIS are accessible. Maybe that's the reason. No, the reason is as I stated, no more, no less. Accessibility doesn't enter into most designs. Which are those most designs? I've shown you that the most used GUIS are made to be accessible out of the box and all the GUIS should offer these facilities. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Grant Edwards invalid@invalid.invalid On 2011-01-19, Octavian Rasnita orasn...@gmail.com wrote: From: Adam Skutt ask...@gmail.com If you want functional accessibility support, you're going to have to write it in Python yourself, and get the accessibility manufacturers to support it. All of the cross-platform toolkits have poor to non- existent accessibility support. Accessibility issues aren't going to be fixed by going to a different GUI toolkit in the standard library. Not true. WxPython uses wxWIDGETS which uses the default OS widgets There's no such thing as default OS widgets on Linux/Unix/BSD/etc. which usually offer the accessibility features. (At least under Windows, but most users that need accessibility use Windows anyway). [...] WxPython is not perfect but most of the objects it offers are accessible so this is not true. Only Tk and GTK are bad. On all of my computers, wxPython uses Gtk. There are other choices for wxWidget backends on Linux, but Gtk is by far the most common. IOW, if Gtk is bad, then wxPython is bad. Not true. Gtk is accessible under Linux but it is not accessible under Windows. I am not talking from the perspective of what the GUI creators say, but about the reality. Adobe and Microsoft say that Flash and Silverlight are accessible because they offer accessibility features, but this is practically absolutely unimportant for the users, because the current screen readers don't offer support for them, so they are hard accessible respectively not accessible. I don't know why Gtk is not accessible under Windows but it can be accessed fine under Linux with Orca screen reader. Either it doesn't offer the accessibility features in its Windows version, or it offers the same thing under Windows but the screen readers that work under Windows don't offer support for it. I'd say that Silverlight is pretty new and it is expected that it is not accessible, but Gtk, QT and Tk are old enough but there is no support for them yet. Under Windows there are open source screen readers also, one of them beeing NVDA, which is made in Python, so we are not talking only about commercial programs that might not offer this support because of a commercial interest, however those screen readers don't offer support for those GUIS. Orca, the most used screen reader used under Linux is also made in Python, but under Linux it can access fine the Gtk interface. So I don't know why, but maybe it is hard for the screen reader manufacturers to make them support absolutely all the possible interfaces so they choose to support only the most used GUI under each OS. So the better term would be the most used GUI type and not the default GUI type for each OS. But I as I said, all these things can be tested using that screen reader I told you about. If you use Windows, and you have an application which is made using QT, Tk or Gtk, you can download JAWS from www.freedomscientific.com, install it and try to see what you hear when you use that application and you will see that you won't hear anything, while in an application that uses wxWIDGETS or standard Win32 GUI or MFC, the most used controls are perfectly accessible. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Adam Skutt ask...@gmail.comOn Jan 19, 11:09 am, Octavian Rasnita orasn...@gmail.com wrote: From: Adam Skutt ask...@gmail.com Accessibility always requires special effort, and I don't see how changing toolkits gets away from this. This is the most false thing I ever heard and the most dangerous. O RLY? http://www.wxwidgets.org/docs/technote/wxaccesstips.htm sure looks like there's a whole host of things that I, the application programmer, must do manually to enable an accessible application[1]. I can't just plop down controls and have an accessible application. Well, to be sincere, I thought that you don't care, or even worse, and I am sorry because I was thinking that way, but I see that you don't understand what accessible means. A GUI can be more or less accessible and the most accessible is the standard Win32 GUI / MFC. wxWIDGETS is not perfect because it has some controls that steal the focus and don't allow moving it to another control by using the tab key, or it has the HTML widget which is not accessible at all, but the most used controls like the buttons, list boxes, list views, text fields, radio buttons, check boxes... are perfectly accessible out of the box. Those rules for creating an accessible application are obvious; like the fact that a button need to contain a text label and not only an image, or that an image needs to have a tooltip defined, or that a radio button needs to have a label attached to it, but all those things can be solved by the programmer and usually the programmer create those text labels. If the programmer doesn't create those labels, the application won't be totally inaccessible. The users will tab around and they will hear that there is a button without name, or a radio button without name, but the user can use the application and by trial and error he/she might learn that the second button does this and the third button does that. But the interfaces created with Tk, Gtk and QT are completely inaccessible. This means that no object confirms that it got the focus, no text field returns the text it contains, and so on. Those applications are like an opened notepad.exe program with an empty file in which you try to tab around to move the cursor, but of course, nothing happends and you can't find any button, or list box in it. In the Tk applications only the menus are accessible but that's the entire accessibility it offers. The programmer doesn't even know that the application will also offer accessibility features. No, accessibility requires consideration in the design and implementation of the GUIs, in all of those toolkits. It is not transparent, nor can it be transparent. It requires both consideration when laying out the widgets, but also ensuring that the widgets have specific properties set. How many applications have you ever used that had focus order bugs? That's an accessibility issue that requires programmer intervention to get right. Adam Yes, those things should be followed for creating a better app, but what I wanted to say is that no matter if you do those things or not in a Tk, Gtk or QT GUI, they will be useless, because the screen readers can't understand those GUIS even they have text labels, and even if you will see a focus rectangle around buttons. They don't report that those objects have the focus so the screen readers won't speak anything. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, 19 Jan 2011 12:45:22 -0800, Patty wrote: On Wed, Jan 19, 2011 at 10:22 AM, pa...@cruzio.com wrote: Now I think I understand a little better where you all are coming from -- I am a Unix person and I guess I expected to have to learn GUI's using whatever is provided for me by default. Which isn't a bad thing. And if I had to add additional software - and learn that - so be it. I am using a Windows XP system and a Windows 7 system presently. Some day I would like to switch out the Windows XP for Unix. Just dual boot, it isn't hard. True. I have a Compaq Presario that is so old hardware-wise that I don't think it could handle Unix or Linux. I think you have that backwards. You can usually run recent Linux on *much* older and cruftier hardware than will run recent Windows. You may have to forgo using the two heavyweight window managers, Gnome and KDE, in favour of a lightweight window manager, but some people would argue that's a benefit rather than a loss :) Here's an article that might be of interest: http://www.desktoplinux.com/articles/AT6185716632.html -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 12:22 pm, pa...@cruzio.com wrote: Who or what group is actually in charge of what libraries (and programming commands/methods such as the Python 3.x rewrite of 'print') goes into Python? Well it comes down to Guido, some Guys, and a mailing list. see this link fro more detail... http://www.python.org/dev/intro/ Is this huge discussion really a few feature requests for additional libraries to be included for Windows programming? No, this HUGE discussion is primarily about the worth of Tkinter as our chosen GUI module and whether or not we should replace it. It also contains (and rightly so!) undertones as to the lost vision within this community as a whole. Not to mention the missing cohesiveness to move forward in the correct direction. And aren't some of these libraries developed by 3rd parties? Yes Python has many 3rd party packages available. You should familiarize yourself with both the current stdlib AND the packages list. Both are here... http://pypi.python.org/pypi?:action=index http://docs.python.org/release/3.0.1/modindex.html And how is that handled by the people in charge? Do they have to pay to license it or is this all freely contributed software? This statement needs clarification because i cannot decide if you are asking from a Python stdlib perspective or a 3rd party package perspective. In any event Python and the stdlib should be all free and open software. And shame on anyone who releases closed source software! Shame on you greedies! Shame on you! :( -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, 19 Jan 2011 12:45:22 -0800, Patty wrote: - Original Message - From: geremy condra debat...@gmail.com To: pa...@cruzio.com On Wed, Jan 19, 2011 at 10:22 AM, pa...@cruzio.com wrote: Now I think I understand a little better where you all are coming from -- I am a Unix person and I guess I expected to have to learn GUI's using whatever is provided for me by default. Which isn't a bad thing. And if I had to add additional software - and learn that - so be it. I am using a Windows XP system and a Windows 7 system presently. Some day I would like to switch out the Windows XP for Unix. Just dual boot, it isn't hard. IME you'll find that networking a Windows box to an older, slower PC thats rescued from the attic will be much more useful than a single dual-boot arrangement. Linux will run at a usable speed on a PC with 512 MB RAM and an 866 MHz P3, though some things, such as logging in, will be slow with a graphical desktop (runlevel 5), but if it has more RAM or you run an X-server on another PC, which could be running Windows, you'll execute commands, including graphical ones - provided you have X.11 forwarding enabled, a lot faster. The Linux box can also be headless if you haven't a screen and keyboard to spare. In short, Linux will run well on a PC that can't run anything more recent than Win98 at an acceptable speed. It doesn't need a lot of disk either - anything more than 30 GB will do. However, an optical drive is needed for installation. You can install Fedora from a CD drive provided the box is networked so it can retrieve most of its packages over the net, but using a DVD drive would be easier for a first install. True. I have a Compaq Presario that is so old hardware-wise that I don't think it could handle Unix or Linux. What speed and type of CPU does it use? How much RAM? What's about disk and optical drives? FWIW my house server is an IMB Netvista that is at least 10 years old - 866MHz P3, 512 GB RAM, LG DVD drive, new 160GB hdd and runs Fedora 13. It is a bit slow at runlevel 5 (graphical desktop) when driven from its own console, but I usually access it over the house net from a more modern Core Duo laptop that runs Fedora 14. The NetVista is more than adequate for web and RDBMS development (Apache and PostgreSQL) in Python or Java and very fast for C compilation. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On Wed, 19 Jan 2011 11:30:36 -0800, Carl Banks wrote:
On Jan 19, 6:42 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
But having said that, the __pycache__ idea isn't too bad. If you have
this directory structure:
./module.py
./module.pyc
and import module, the top-level .pyc file will continue to be used.
Nope. PEP 3147 says it now always uses __pycache__.
Looks like the PEP is outdated then.
[steve@sylar ~]$ rm __pycache__/*
[steve@sylar ~]$ echo print('spam spam spam') spam.py
[steve@sylar ~]$ python3.2 -m compileall spam.py
Compiling spam.py ...
[steve@sylar ~]$ mv __pycache__/spam.cpython-32.pyc ./spam.pyc
[steve@sylar ~]$ python3.2 -m spam
spam spam spam
[steve@sylar ~]$ ls __pycache__/
[steve@sylar ~]$
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2011-01-19, Octavian Rasnita orasn...@gmail.com wrote: From: Grant Edwards invalid@invalid.invalid WxPython is not perfect but most of the objects it offers are accessible so this is not true. Only Tk and GTK are bad. On all of my computers, wxPython uses Gtk. There are other choices for wxWidget backends on Linux, but Gtk is by far the most common. IOW, if Gtk is bad, then wxPython is bad. Not true. I think you're playing a bit fast and loose with your accusations. Which of my statements was not true? 1) On all of my computers wxPython uses Gtk. 2) There are other backend choices on Linux besides Gtk. 3) Gtk is by far the most common wxWidgets backend on Linux/Unix. 4) If Gtk is bad then wxPython is bad. Note that 4) follows logically from 3), so to say that 4) is not true you have to show that 3) is not true. -- Grant Edwards grant.b.edwardsYow! WHOA!! Ken and Barbie at are having TOO MUCH FUN!! gmail.comIt must be the NEGATIVE IONS!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!)
On 1/19/2011 11:27 AM, Octavian Rasnita wrote: Note: Currently, accessibility is only available via ATK= AT-SPI on Linux. Sorry, no Windows MSAA support. This project is good, a step ahead, but in order to be really useful it should be the one provided by the default Python package. And of course, it should also offer support for Windows, since most of the computer users use Windows, especially those who need accessibility features. Octavian Please consider adding an 'Accessibility' page to the Python wiki with your info and the above for those interested. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 3:51 pm, Grant Edwards inva...@invalid.invalid wrote: On 2011-01-19, Octavian Rasnita orasn...@gmail.com wrote: Which of my statements was not true? 1) On all of my computers wxPython uses Gtk. 2) There are other backend choices on Linux besides Gtk. 3) Gtk is by far the most common wxWidgets backend on Linux/Unix. 4) If Gtk is bad then wxPython is bad. Note that 4) follows logically from 3), so to say that 4) is not true you have to show that 3) is not true. All of these folks that keep blabbing about how they may need this dependency or that dependency on Linux/Unix either need to shut up or convert to a windows box with a nice installer exe that will hold your wiener while you pee. Really, you're only going to fool the lemmings with such BS arguments! Stop whining, you choose to use an advanced OS and stop blaming the rest of the world because of your choices! -- http://mail.python.org/mailman/listinfo/python-list
Re: __pycache__, one more good reason to stck with Python 2?
On 2011-01-19 13:01:04 -0800, Steven D'Aprano said:
I know I've seen problems executing .pyc files from the shell in the
past... perhaps I was conflating details of something else. Ah, I know!
[steve@sylar ~]$ chmod u+x toto.pyc
[steve@sylar ~]$ ./toto.pyc
: command not found ��
./toto.pyc: line 2: syntax error near unexpected token `('
./toto.pyc: line 2: `P7Mc@s dGHdS(tfooNs./
toto.pymodules'
... don't do that. I do not know why that would be expected to work,
ever. (Unless you're crafty and wrap a real shell script around the
.pyc, in which case it's no longer a .pyc.)
— Alice.
--
http://mail.python.org/mailman/listinfo/python-list
Re: UTF-8 question from Dive into Python 3
On 1/19/2011 1:02 PM, Tim Harig wrote: Right, but I only have to do that once. After that, I can directly address any piece of the stream that I choose. If I leave the information as a simple UTF-8 stream, I would have to walk the stream again, I would have to walk through the the first byte of all the characters from the beginning to make sure that I was only counting multibyte characters once until I found the character that I actually wanted. Converting to a fixed byte representation (UTF-32/UCS-4) or separating all of the bytes for each UTF-8 into 6 byte containers both make it possible to simply index the letters by a constant size. You will note that Python does the former. The idea of using a custom fixed-width padded version of a UTF-8 steams waw initially shocking to me, but I can imagine that there are specialized applications, which slice-and-dice uninterpreted segments, for which that is appropriate. However, it is not germane to the folly of prefixing standard UTF-8 steams with a 3-byte magic number, mislabelled a 'byte-order-mark, thus making them non-standard. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 4:04 pm, Octavian Rasnita orasn...@gmail.com wrote: Those rules for creating an accessible application are obvious; like the fact that a button need to contain a text label and not only an image, or that an image needs to have a tooltip defined, or that a radio button needs to have a label attached to it, but all those things can be solved by the programmer and usually the programmer create those text labels. The fact that /every/ toolkit provides accessibility guidelines over and above whatever other UI guidelines they provide tells me that creating an accessible application is hardly obvious. Plus, if it were really that simple, the accessibility situation wouldn't be so poor. Yes, those things should be followed for creating a better app, but what I wanted to say is that no matter if you do those things or not in a Tk, Gtk or QT GUI, they will be useless, because the screen readers can't understand those GUIS even they have text labels, and even if you will see a focus rectangle around buttons. They don't report that those objects have the focus so the screen readers won't speak anything. Your something is better than nothing argument isn't particularly compelling to me personally as a justification for ripping out TkInter. And Qt is the only toolkit with some level of functioning accessibility support on all three major platforms, assuming the library and software are built correctly, so again, your argument is really for Qt, not for wxWidgets. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, Jan 19, 2011 at 1:40 PM, geremy condra debat...@gmail.com wrote: On Wed, Jan 19, 2011 at 11:37 AM, geremy condra debat...@gmail.com wrote: No, it's about other operating systems too, but what it comes down to is that rantingrick has been on the warpath about tkinter for a while, and hasn't proposed a particularly viable alternative. The sad thing is that if he weren't so unhinged his proposal would probably fare much better Look, the folks are c.l.py are far too touchy and they really need to lighten up. Really! The fact that my speech style and delivery does not fit some cookie cutter pre-directive is just BS. The Python community is NOT a homogeneous block you know, and it should not be! People have said to me in the past...Well you could participate at python-dev or python-ideas or the tracker but NOT as ranting rick, you need to use a better name... What? What does it matter what my name is anyway. This is just being pedantic!! Sorry for the truncation. I was going to say that I know I would be more supportive of it if he was building support for something instead of tearing everything else down. I am not tearing down anything, however that was a nice try Geremy *wink*. The only thing that is being torn down is the solid wall of rabid resistance that has been slowly built by this community over many years. We have become too centralized and many folks are being left out of the community decision process. You (and others) act like my only concern is to destroy what has been built (Tkinter) and that is not the case! But like old governments, YOU (the python elite!) have lost all vision for the future. And you've also lost all connection with the people. I am desperately trying to to snap you out of this psychosis before it is too late! Tkinter will be the downfall of Python if we cannot muster the resolve to replace it with something that is current (or more current) technology. Stop fearing change and re-ignite the vision that GvR once had. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 4:40 pm, Adam Skutt ask...@gmail.com wrote: On Jan 19, 4:04 pm, Octavian Rasnita orasn...@gmail.com wrote: Those rules for creating an accessible application are obvious; like the fact that a button need to contain a text label and not only an image, or that an image needs to have a tooltip defined, or that a radio button needs to have a label attached to it, but all those things can be solved by the programmer and usually the programmer create those text labels. The fact that /every/ toolkit provides accessibility guidelines over and above whatever other UI guidelines they provide tells me that creating an accessible application is hardly obvious. Plus, if it were really that simple, the accessibility situation wouldn't be so poor. Yes, those things should be followed for creating a better app, but what I wanted to say is that no matter if you do those things or not in a Tk, Gtk or QT GUI, they will be useless, because the screen readers can't understand those GUIS even they have text labels, and even if you will see a focus rectangle around buttons. They don't report that those objects have the focus so the screen readers won't speak anything. Your something is better than nothing argument isn't particularly compelling to me personally as a justification for ripping out TkInter. And Qt is the only toolkit with some level of functioning accessibility support on all three major platforms, assuming the library and software are built correctly, so again, your argument is really for Qt, not for wxWidgets. Adam Adam, please use the following style when posting to this group...Thanks. On Jan 19, 4:04 pm, Octavian Rasnita orasn...@gmail.com wrote: Those rules for creating an accessible application are obvious; like the fact that a button need to contain a text label and not only an image, or that an image needs to have a tooltip defined, or that a radio button needs to have a label attached to it, but all those things can be solved by the programmer and usually the programmer create those text labels. The fact that /every/ toolkit provides accessibility guidelines over and above whatever other UI guidelines they provide tells me that creating an accessible application is hardly obvious. Plus, if it were really that simple, the accessibility situation wouldn't be so poor. Yes, those things should be followed for creating a better app, but what I wanted to say is that no matter if you do those things or not in a Tk, Gtk or QT GUI, they will be useless, because the screen readers can't understand those GUIS even they have text labels, and even if you will see a focus rectangle around buttons. They don't report that those objects have the focus so the screen readers won't speak anything. Your something is better than nothing argument isn't particularly compelling to me personally as a justification for ripping out TkInter. And Qt is the only toolkit with some level of functioning accessibility support on all three major platforms, assuming the library and software are built correctly, so again, your argument is really for Qt, not for wxWidgets. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 12:22 pm, pa...@cruzio.com wrote: Who or what group is actually in charge of what libraries (and programming commands/methods such as the Python 3.x rewrite of 'print') goes into Python? Well it comes down to Guido, some Guys, and a mailing list. see this link fro more detail... http://www.python.org/dev/intro/ Well that explains Everything! Is this huge discussion really a few feature requests for additional libraries to be included for Windows programming? No, this HUGE discussion is primarily about the worth of Tkinter as our chosen GUI module and whether or not we should replace it. It also contains (and rightly so!) undertones as to the lost vision within this community as a whole. Not to mention the missing cohesiveness to move forward in the correct direction. I see why you say this. I think I am playing catchup with what has been going on for some time amongst you all. And aren't some of these libraries developed by 3rd parties? Yes Python has many 3rd party packages available. You should familiarize yourself with both the current stdlib AND the packages list. Both are here... http://pypi.python.org/pypi?:action=index http://docs.python.org/release/3.0.1/modindex.html And how is that handled by the people in charge? Do they have to pay to license it or is this all freely contributed software? This statement needs clarification because i cannot decide if you are asking from a Python stdlib perspective or a 3rd party package perspective. In any event Python and the stdlib should be all free and open software. And shame on anyone who releases closed source software! Shame on you greedies! Shame on you! :( And I am coming from background working at SCO for commercial SCO Unix and also commercial applications software. So free software is not something I am used to :) And understand what is involved with obtaining 3rd party pieces either by necessity or because of an acquistion. And the money part. It was complicated. So I was thinking from the python stdlib perspective. But your comment turned my thinking around to where it should be to discuss open source software. I don't think I am ready for the py-dev mailing list yet ;) But I do have some big ideas because of UCSC (University of California, Santa Cruz) being so close, their Computer Engineering Dept. is Really Good and I have some connections up there. Patty -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 19, 9:18 am, Grant Edwards inva...@invalid.invalid wrote: And an unmoderated Usenet newsgroup (which has even less of a chain of command than a mailing list). Moderated status has nothing to do with it. The fact is that the elite no longer feel it necessary to care about the troubles of the Python peasants. This is evident by no posting from GvR for many years, and no posting from his subordinate (and the PSF chair!) Steve Holden. The last time Steve and i rubbed shoulders was when i chastised him for engaging in trollish behavior. So now i get it... He has time for trolling and flaming but no time for real discussion on topics that concern the very future evolution of this language? hmm. -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Wednesday, January 19, 2011 7:21:53 PM UTC-4, rantingrick wrote: On Jan 19, 9:18 am, Grant Edwards inva...@invalid.invalid wrote: And an unmoderated Usenet newsgroup (which has even less of a chain of command than a mailing list). Moderated status has nothing to do with it. The fact is that the elite no longer feel it necessary to care about the troubles of the Python peasants. This is evident by no posting from GvR for many years, and no posting from his subordinate (and the PSF chair!) Steve Holden. The last time Steve and i rubbed shoulders was when i chastised him for engaging in trollish behavior. So now i get it... He has time for trolling and flaming but no time for real discussion on topics that concern the very future evolution of this language? hmm. Perhaps it is because they are either busy programming and/or busy organizing Pycon 2011. Some people do a lot, some people talk/write a lot. It is hard to find the time to do both ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, 19 Jan 2011 12:45:22 -0800, Patty wrote: - Original Message - From: geremy condra debat...@gmail.com To: pa...@cruzio.com On Wed, Jan 19, 2011 at 10:22 AM, pa...@cruzio.com wrote: Now I think I understand a little better where you all are coming from -- I am a Unix person and I guess I expected to have to learn GUI's using whatever is provided for me by default. Which isn't a bad thing. And if I had to add additional software - and learn that - so be it. I am using a Windows XP system and a Windows 7 system presently. Some day I would like to switch out the Windows XP for Unix. Just dual boot, it isn't hard. IME you'll find that networking a Windows box to an older, slower PC thats rescued from the attic will be much more useful than a single dual-boot arrangement. Linux will run at a usable speed on a PC with 512 MB RAM and an 866 MHz P3, though some things, such as logging in, will be slow with a graphical desktop (runlevel 5), but if it has more RAM or you run an X-server on another PC, which could be running Windows, you'll execute commands, including graphical ones - provided you have X.11 forwarding enabled, a lot faster. The Linux box can also be headless if you haven't a screen and keyboard to spare. In short, Linux will run well on a PC that can't run anything more recent than Win98 at an acceptable speed. It doesn't need a lot of disk either - anything more than 30 GB will do. However, an optical drive is needed for installation. You can install Fedora from a CD drive provided the box is networked so it can retrieve most of its packages over the net, but using a DVD drive would be easier for a first install. True. I have a Compaq Presario that is so old hardware-wise that I don't think it could handle Unix or Linux. What speed and type of CPU does it use? How much RAM? What's about disk and optical drives? FWIW my house server is an IMB Netvista that is at least 10 years old - 866MHz P3, 512 GB RAM, LG DVD drive, new 160GB hdd and runs Fedora 13. It is a bit slow at runlevel 5 (graphical desktop) when driven from its own console, but I usually access it over the house net from a more modern Core Duo laptop that runs Fedora 14. The NetVista is more than adequate for web and RDBMS development (Apache and PostgreSQL) in Python or Java and very fast for C compilation. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list Martin and Geremy - thank you for the suggestions. My Compaq Presario I know is maxed out on memory and I checked and my Maxtor drive says it is 28624 MB. I don't know if that is enough? I have my HP Mini Netbook running Windows 7 and do my Python programming on it. It is awesome! I don't really care if my Compaq had Windows XP plus Linux or just Linux. I would be happy to just back up what I want and install Linux for the whole Compaq and just have the two communicate. I really use the Compaq more as an email and file archive. I would probably rethink which software programming tools and languages I would want on each machine. I consider myself a C programmer and SQL and I am a linguist - several programming languages - so I would be more likely to want compilers and interpreters, favorite IDEs installed on whichever system. Patty-- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Jan 19, 5:26 pm, André andre.robe...@gmail.com wrote: Perhaps it is because they are either busy programming and/or busy organizing Pycon 2011. Some people do a lot, some people talk/write a lot. It is hard to find the time to do both ... Well perhaps. I am not suggesting that these people are not working on important issues. I am just pointing out an incident with Steve that could have been better spent on real discussion and not a flame war. Look, i am no perfect person and i do not expect that Steve is either. However attempting to say that somehow my work --engaging the community through lively debate in an attempt to re-energize the Python spirit GvR created so long ago that has now waxed cold-- is somehow less important than Steve's or anyones work is a little condescending to say the least. It takes many stones to build a house. And sometimes after you build the house you find the foundation is cracking. This could be due to poor planning in the design phase (which is not the case with Tkinter!!) OR it could be due to soil that is grown unstable (This is the case with Tkinter!!). Repairing a foundation after the fact is always going to be hard work but someone has do it. Someone has to gather the crew and create a battle plan. Well, thats me. However i cannot do this alone. I need the rest of you guys to share the load. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, Jan 19, 2011 at 3:04 PM, rantingrick rantingr...@gmail.com wrote: On Wed, Jan 19, 2011 at 1:40 PM, geremy condra debat...@gmail.com wrote: On Wed, Jan 19, 2011 at 11:37 AM, geremy condra debat...@gmail.com wrote: No, it's about other operating systems too, but what it comes down to is that rantingrick has been on the warpath about tkinter for a while, and hasn't proposed a particularly viable alternative. The sad thing is that if he weren't so unhinged his proposal would probably fare much better Look, the folks are c.l.py are far too touchy and they really need to lighten up. Really! The fact that my speech style and delivery does not fit some cookie cutter pre-directive is just BS. The Python community is NOT a homogeneous block you know, and it should not be! People have said to me in the past...Well you could participate at python-dev or python-ideas or the tracker but NOT as ranting rick, you need to use a better name... What? What does it matter what my name is anyway. This is just being pedantic!! I'm not telling you to change your behavior. I'm telling you that the way you're doing things isn't effective. You can take that advice or not, just as I can decide to listen to you... or not. I also wouldn't advise you to change your name again. I think you've already landed on a couple of spam lists for that. Sorry for the truncation. I was going to say that I know I would be more supportive of it if he was building support for something instead of tearing everything else down. I am not tearing down anything, however that was a nice try Geremy *wink*. The only thing that is being torn down is the solid wall of rabid resistance that has been slowly built by this community over many years. I don't think this is the case, first because you aren't very good at getting anybody to take you seriously and second because I don't think that resistance on this issue is as mindless as you claim. We have become too centralized and many folks are being left out of the community decision process. I disagree with the first half. The second I'm more prone to agree with, although I don't have a lot of great ideas about how to solve the problem. You seem to be full of ideas (most of which I think are terrible) but very short on actually getting anything done. Until you begin to remedy that I doubt very many people here will take you as seriously as you seem to want. Also, be careful with where you say 'we'- I certainly don't recognize your authority to speak on behalf of the community, and I suspect that an overwhelming majority of the community's other members feel the same way. You (and others) act like my only concern is to destroy what has been built (Tkinter) and that is not the case! Seems like it from where I'm sitting. YMMV, but I think you would do much better if you focused on the problem of building a system that addressed the concerns others have raised rather than pretending they aren't valid concerns. But like old governments, YOU (the python elite!) have lost all vision for the future. Hey, cool, I'm a member of the elite now. You wouldn't happen to know how to list that on a resume, would you? And you've also lost all connection with the people. I am desperately trying to to snap you out of this psychosis before it is too late! Tkinter will be the downfall of Python if we cannot muster the resolve to replace it with something that is current (or more current) technology. Citation needed. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
On Wed, Jan 19, 2011 at 3:42 PM, rantingrick rantingr...@gmail.com wrote: Look, i am no perfect person and i do not expect that Steve is either. However attempting to say that somehow my work --engaging the community through lively debate in an attempt to re-energize the Python spirit GvR created so long ago that has now waxed cold-- is somehow less important than Steve's or anyones work is a little condescending to say the least. Condescending or not, it's true. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
collections.Set Binary Reflected Operations
I am implemented a custom set-like type which interacts with some third-party software when retrieving and mutating the set, and have derived my custom type off of collections.MutableSet, however I have noticed that some of the magic methods supported by the built-in set do not fully function with my custom type. From this, I looked over the MutableSet definition in and it seems to be missing all of the reflected operators (__rsub__, __rand__, __ror__, __rxor__, and friends) for the operators it has defined. I can post a simple example case if desired. I am using Python 2.6.4 (with some in-house customizations), however a quick look over the svn repository shown on python.org makes it appear that these are also not implemented in Python 3. I was wondering if there is some reason for this, or if it was merely an oversight. Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 6:01 pm, geremy condra debat...@gmail.com wrote: I'm not telling you to change your behavior. I'm telling you that the way you're doing things isn't effective. You can take that advice or not, just as I can decide to listen to you... or not. I also wouldn't advise you to change your name again. I think you've already landed on a couple of spam lists for that. Yes i know! The whole name issue was blown out of proportion. Look i think i should explain how this whole name conundrum started. When i first came to this list you can imagine that i was not prepared to divulge every detail about my identity and personal life (as most should not!). So i choose a cryptic and nonsensical name. Yes, i made it up! And at the time i never had any inclination that i would want to get so involved with this group. Well that was then and this is now... However, after i became known within the community many folks started to debase any of my arguments simply on the fact that my name was anonymous. So at that time i started using my real name Rick Johnson and my nickname as rantingrick. After this people then accused my of identity hopping. Even some of the same folks who previously were complaining about my cryptic first name choice! Now they were complain that i choose to use my REAL name. Ironic eh! So what it boils down to is this... some people on this list just hate me and trying to please them is a waste of time. I am not tearing down anything, however that was a nice try Geremy *wink*. The only thing that is being torn down is the solid wall of rabid resistance that has been slowly built by this community over many years. I don't think this is the case, first because you aren't very good at getting anybody to take you seriously How self absorbed must someone be to blame *ME* because *THEY* cannot take *ME* seriously. Is this a joke Geremy? Sadly i know it to be true however because you are not the only person who carries this attitude. and second because I don't think that resistance on this issue is as mindless as you claim. i have exposed the baseless, nonsensical, and argumentative stance taken by some in an effort to sway public opinion with FUD and BS. So i would say that arguing with baseless facts does constitute rabid resistance. What else could it be? We have become too centralized and many folks are being left out of the community decision process. I disagree with the first half. The second I'm more prone to agree with, although I don't have a lot of great ideas about how to solve the problem. Well maybe you are not a visionary, however i believe we still need you in other areas. You seem to be full of ideas (most of which I think are terrible) but very short on actually getting anything done. Until you begin to remedy that I doubt very many people here will take you as seriously as you seem to want. Look, every organization needs workers, visionaries, liaisons, supervisors, etc. I seem to fit nicely into a Visionary role. Maybe that bothers you? I don't know? But we all have our place Geremy. Do you think any organization could survive simply with robotic workers and no guidance? No, and why not? Because workers cannot see the big picture. They are too focused (and rightly so) on some small detail that encompasses their job duty. Only the supervisor/visionary has the luxury of looking at the problem from a global perspective. Think of Python-dev as a car. A car is a machine. A very complicated machine that needs a driver to harness it's power and give it direction and purpose. -- someone who can see beyond the horizon. Someone who can read a road map and then re-calculate a path if road construction blocks the current one. Without the car the driver is nothing, and without the driver the car is nothing. But together, they are a force to reckoned with. Well, unless the driver is Asian -- then all bets are off! :-) Also, be careful with where you say 'we'- I certainly don't recognize your authority to speak on behalf of the community, and I suspect that an overwhelming majority of the community's other members feel the same way. You see! This is the resistance i am talking about. You (and others) don't want to accept me as part of the community. If you did accept me, then my speaking collectively (we) would not be troubling to you. However i do not blame you directly for this prejudice. I think it is more of a sub-conscience undercurrent that pervades this community as a whole. A fear of outsiders. A xenophobia if you will. We need to change this now! -- http://mail.python.org/mailman/listinfo/python-list
Re: Detecting Remaining Thread
Disregard, I figured it out. It turns out that the threads spawned by thread.start_new_thread are unreported by threading.enumerate. Cheers! -Damian On Wed, Jan 19, 2011 at 9:40 AM, Damian Johnson atag...@gmail.com wrote: Hi, I've been trying to track down a familiar concurrency problem without any success: Unhandled exception in thread started by Error in sys.excepthook: Original exception was: I realize that this is due to a background thread still being alive and kicking when the application terminates (ie, a missing join() on a helper thread). However, threading.enumerate() is reporting that nothing except for the main thread is running at that point: 1/19/2011 09:30:41 [INFO] Arm is shutting down. Remaining threads: [_MainThread(MainThread, started -1217079616)] What other methods are there for troubleshooting this sort of issue? I've triple checked that my threads are daemons and joined when quitting but I must be missing something... As would be expected of a timing issue, this happens intermittently (1/5 of the time) and goes away if I add a short sleep at the end. Any help would be much appreciated. Thanks! -Damian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, Jan 19, 2011 at 4:53 PM, rantingrick rantingr...@gmail.com wrote: I don't think this is the case, first because you aren't very good at getting anybody to take you seriously How self absorbed must someone be to blame *ME* because *THEY* cannot take *ME* seriously. Is this a joke Geremy? Sadly i know it to be true however because you are not the only person who carries this attitude. Welcome to real life. You convince people that you're right or they don't do what you say. and second because I don't think that resistance on this issue is as mindless as you claim. i have exposed the baseless, nonsensical, and argumentative stance taken by some in an effort to sway public opinion with FUD and BS. So i would say that arguing with baseless facts does constitute rabid resistance. What else could it be? Reasoned resistance seen through the eyes of someone whose judgement should not be trusted. I disagree with the first half. The second I'm more prone to agree with, although I don't have a lot of great ideas about how to solve the problem. Well maybe you are not a visionary, however i believe we still need you in other areas. Oh, do tell. You seem to be full of ideas (most of which I think are terrible) but very short on actually getting anything done. Until you begin to remedy that I doubt very many people here will take you as seriously as you seem to want. Look, every organization needs workers, visionaries, liaisons, supervisors, etc. I seem to fit nicely into a Visionary role. Maybe that bothers you? I don't know? But we all have our place Geremy. Do you think any organization could survive simply with robotic workers and no guidance? No, and why not? Because workers cannot see the big picture. They are too focused (and rightly so) on some small detail that encompasses their job duty. Only the supervisor/visionary has the luxury of looking at the problem from a global perspective. Think of Python-dev as a car. A car is a machine. A very complicated machine that needs a driver to harness it's power and give it direction and purpose. -- someone who can see beyond the horizon. Someone who can read a road map and then re-calculate a path if road construction blocks the current one. Without the car the driver is nothing, and without the driver the car is nothing. Python already has leadership. It does not have a command structure. There is a difference, one that you would need to understand to be an effective leader. But together, they are a force to reckoned with. Well, unless the driver is Asian -- then all bets are off! :-) Hahaha, racism was so funny in the 1700's! Now it's just asinine. Also, be careful with where you say 'we'- I certainly don't recognize your authority to speak on behalf of the community, and I suspect that an overwhelming majority of the community's other members feel the same way. You see! This is the resistance i am talking about. You (and others) don't want to accept me as part of the community. If you did accept me, then my speaking collectively (we) would not be troubling to you. However i do not blame you directly for this prejudice. I think it is more of a sub-conscience undercurrent that pervades this community as a whole. A fear of outsiders. A xenophobia if you will. We need to change this now! There's a difference between 'we should' and 'we must'. One implies that you are trying to convince, which is what communities of equals do. The other implies that you are trying to command, which is what idiots think they can do to communities of equals. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 01/19/2011 05:01 PM, geremy condra wrote: On Wed, Jan 19, 2011 at 3:04 PM, rantingrick rantingr...@gmail.com wrote: And you've also lost all connection with the people. I am desperately trying to to snap you out of this psychosis before it is too late! Tkinter will be the downfall of Python if we cannot muster the resolve to replace it with something that is current (or more current) technology. I don't see the original bizarre rants for some reason (spam filter likely), but I have to say this is the most ridiculous thing I've heard in some time. Tkinter the downfall of python? Wow. All of the python programmers I know (we use python every day at work) would say, what is tkinter? It's just not relevant to any of them that I know. Google probably uses as much Python as anyone, and their programmers would probably agree. Perhaps that's an argument to remove tkinter entirely, but not really a good one. In the meantime they happily crank out code with Django, or PyQt, or PyGTK, or even Tkinter--whatever tool is appropriate for the job. Citation needed. Perhaps a reference to Xah Lee's web site would suffice. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 9:22 pm, geremy condra debat...@gmail.com wrote: Welcome to real life. You convince people that you're right or they don't do what you say. Again you think (or miscomprehended rather!) that somehow i am here to make you do anything. On the contrary Geremy, i am here to guide, to foster, and to build a cohesive community of python programmers united in a common goal WITH a clear vision for the future. and second because I don't think that resistance on this issue is as mindless as you claim. i have exposed the baseless, nonsensical, and argumentative stance taken by some in an effort to sway public opinion with FUD and BS. So i would say that arguing with baseless facts does constitute rabid resistance. What else could it be? Reasoned resistance seen through the eyes of someone whose judgement should not be trusted. Why is my judgment in question here. As you claim i have no authority within in this group, so why does my judgment scare you? But together, they are a force to reckoned with. Well, unless the driver is Asian -- then all bets are off! :-) Hahaha, racism was so funny in the 1700's! Now it's just asinine. Actually the joke is on you Geremy. Obviously you cannot tell the difference between stereotypes and racism. And there is a HUGE, HUGE, difference! Asians are stereotypical bad drivers, just as white guys are stereotypical bad dancers, just as black guys have stereotypical huge cucumbers. The fact that you cannot distinguish racism from stereotype exposes three things about your personality (1.) You have no sense of humor and cannot laugh at yourself, (2.) You'll jump on any bandwagon just to discredit the person you are debating with outlandish and controversial accusations, and (3.) you are extremely shallow. This shows lack of intelligence, humor, and worse of all humility. Anyhow, do you have any actual arguments or ideas on keeping Tkinter or replacing Tkinter. Remember that is why we are here Geremy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Jan 19, 9:20 pm, Michael Torrie torr...@gmail.com wrote: All of the python programmers I know (we use python every day at work) would say, what is tkinter? It's just not relevant to any of them that I know. And that is the very point i am trying to make Micheal! TclTk is SO old and dated that most people don't even know it exists -- MUCH LESS TKINTER! In the meantime they happily crank out code with Django, or PyQt, or PyGTK, or even Tkinter--whatever tool is appropriate for the job. I noticed wxPython did not make your list. Was that conscience or sub- conscience because i find it hard to believe that none of them use wxPython... ever. However the REAL point is that they obviously prefer *anything* except Tkinter and only use Tkinter as a last resort. This is very interesting Micheal. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, Jan 19, 2011 at 18:53, rantingrick rantingr...@gmail.com wrote: Without the car the driver is nothing, and without the driver the car is nothing. But together, they are a force to reckoned with. Well, unless the driver is Asian -- then all bets are off! :-) Welcome to the auto-deletion filter. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, Jan 19, 2011 at 7:56 PM, rantingrick rantingr...@gmail.com wrote: But together, they are a force to reckoned with. Well, unless the driver is Asian -- then all bets are off! :-) Hahaha, racism was so funny in the 1700's! Now it's just asinine. Actually the joke is on you Geremy. Obviously you cannot tell the difference between stereotypes and racism. And there is a HUGE, HUGE, difference! Asians are stereotypical bad drivers, just as white guys are stereotypical bad dancers, just as black guys have stereotypical huge cucumbers. Congratulations; you are the second person better than a decade to land in my bozo bin. Don't bother replying- I won't be hearing from you. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: collections.Set Binary Reflected Operations
On Thu, Jan 20, 2011 at 01:51, Chris Kaynor ckay...@zindagigames.com wrote: I am implemented a custom set-like type which interacts with some third-party software when retrieving and mutating the set, and have derived my custom type off of collections.MutableSet, however I have noticed that some of the magic methods supported by the built-in set do not fully function with my custom type. From this, I looked over the MutableSet definition in and it seems to be missing all of the reflected operators (__rsub__, __rand__, __ror__, __rxor__, and friends) for the operators it has defined. I can post a simple example case if desired. I am using Python 2.6.4 (with some in-house customizations), however a quick look over the svn repository shown on python.org makes it appear that these are also not implemented in Python 3. I was wondering if there is some reason for this, or if it was merely an oversight. Chris See http://bugs.python.org/issue8743 and also http://bugs.python.org/issue2226 Daniel -- http://mail.python.org/mailman/listinfo/python-list
Re: newb
I received 1 st a href=http://bestfinance-blog.com/topics/mortgage-loans;mortgage loans/a when I was 25 and that supported my family very much. But, I need the bank loan once more time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Grant Edwards invalid@invalid.invalid On all of my computers, wxPython uses Gtk. There are other choices for wxWidget backends on Linux, but Gtk is by far the most common. IOW, if Gtk is bad, then wxPython is bad. Not true. I think you're playing a bit fast and loose with your accusations. :-) I've made no accusations, but I only try to inform the people about the accessibility of different GUI libs. Which of my statements was not true? 1) On all of my computers wxPython uses Gtk. 2) There are other backend choices on Linux besides Gtk. 3) Gtk is by far the most common wxWidgets backend on Linux/Unix. 4) If Gtk is bad then wxPython is bad. Note that 4) follows logically from 3), so to say that 4) is not true you have to show that 3) is not true. The wrong conclusion is that if Gtk is bad, then WxPython is bad. Gtk is inaccessible under Windows, not under Linux, but WxPython doesn't use Gtk under Windows so WxPython is OK. Under Linux Gtk is OK, but I don't know about Motif. Under Linux Motif might not be accessible, however note that I am not sure about Motif's accessibility. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: Adam Skutt ask...@gmail.com The fact that /every/ toolkit provides accessibility guidelines over and above whatever other UI guidelines they provide tells me that creating an accessible application is hardly obvious. Plus, if it were really that simple, the accessibility situation wouldn't be so poor. :-) Where do you got the conclusion that the accessibility is so poor? The accessibility is not so great under Mac and under Linux it is less advanced than under Windows, but under Windows the accessibility is usually very good for most apps. All the standard Windows programs are accessible, all the DotNet programs are generally accessible, SWT and wxWIDGETS - based programs are accessible, SWING-based GUIS are also pretty accessible and even more strange interfaces like the one found in Winamp are accessible. Even Flash have a very limited accessibility although I think it is too much to say that it is accessible. But You keep telling me that it is hard to create accessible programs, which is false, but you don't know and don't want to try to see. Try to create a WxPython app that doesn't do anything but only displays some menus, buttons, combo boxes, list boxes, list views, tree views, text fields, check boxes, radio buttons... and you will see that they are very accessible with that screen reader I told you about, without requiring you to do anything special that you wouldn't do otherwise. Yes, those things should be followed for creating a better app, but what I wanted to say is that no matter if you do those things or not in a Tk, Gtk or QT GUI, they will be useless, because the screen readers can't understand those GUIS even they have text labels, and even if you will see a focus rectangle around buttons. They don't report that those objects have the focus so the screen readers won't speak anything. Your something is better than nothing argument isn't particularly compelling to me personally as a justification for ripping out TkInter. And Qt is the only toolkit with some level of functioning accessibility support on all three major platforms, assuming the library and software are built correctly, so again, your argument is really for Qt, not for wxWidgets. How do you came to the conclusion that QT is accessible on all operating system? I haven't seen any QT-based accessible interface, but WxPython offers that thing without any effort. When you talk about accessibility, try it yourself and don't take the word of the GUI widgets developers. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!)
From: Terry Reedy tjre...@udel.edu On 1/19/2011 11:27 AM, Octavian Rasnita wrote: Note: Currently, accessibility is only available via ATK= AT-SPI on Linux. Sorry, no Windows MSAA support. This project is good, a step ahead, but in order to be really useful it should be the one provided by the default Python package. And of course, it should also offer support for Windows, since most of the computer users use Windows, especially those who need accessibility features. Octavian Please consider adding an 'Accessibility' page to the Python wiki with your info and the above for those interested. -- Terry Jan Reedy Well, I am not sure this is an interesting thing for the programmers. The programmers (including me) are usually interested to have the job done as fast as possible, with as few efforts as possible and to be easy to maintain. The GUIs should be accessible by default like in case of wxWIDGETS, SWT or WindowsForms. That's why I said that that lib should be included in Python implicitely eventually because if it is just promoted, the beginners won't know about it and most of the programmers won't care to add accessibility features with aditional efforts. Too bad that it doesn't support the accessibility for Windows though. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Python like lanugages [was Re: After C++, what with Python?]
Tim Harig, 18.01.2011 12:37: On 2011-01-18, Stefan Behnel wrote: Tim Harig, 17.01.2011 20:41: 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 don't really agree with the word separate, and especially not two codes. I think of Cython more as Python with the addition of C data types, integrated by a smart compiler. So the language actually is Python, it's just that you can apply it to a broader set of data representations. Stefan -- http://mail.python.org/mailman/listinfo/python-list
[issue10943] abitype: Need better support to port C extension modules to the stable C API
New submission from Leo fhaxbo...@googlemail.com: I tried to port the extension module at http://code.google.com/p/pyhyphen/source/browse/3.x/hnjmodule.c to the stable C API using abitype.py. I gave up after the following exceptions: - execption raised for missing PyVarObject_HEAD: this could be rixed by deleting a /* */ comment before. I think abitype.py should properly skip comments rather than forcing the user to delete them. - the xxxmodule.c on which hnjmodule.c is based, defines a PyObject Str_type wherr tp_basicsize is 0 rather than sizeof(XXX). This causes abitype.py to raise a key error as '0' seems to be ignored by abitype.py. Finally, I suggest to add to the source tree a boiler plate C module conforming to the stable API such as xxxmodule-stable-api.c. This would help creating extensions from scratch. -- components: Extension Modules messages: 126519 nosy: fhaxbo...@googlemail.com priority: normal severity: normal status: open title: abitype: Need better support to port C extension modules to the stable C API type: feature request versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10944] ctypes documentation does not mention c_bool in table of standard types
New submission from Марк Коренберг socketp...@gmail.com: http://docs.python.org/library/ctypes.html: --- 15.16.1.4. Fundamental data types [table without c_bool] 15.16.2.7. Fundamental data types class ctypes.c_bool New in version 2.6. -- assignee: docs@python components: Documentation messages: 126520 nosy: docs@python, mmarkk priority: normal severity: normal status: open title: ctypes documentation does not mention c_bool in table of standard types type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10834] Python 2.7 x86 IDLE fails to run in Windows 7
Peter Heiberg pe...@sveumsondre.no added the comment: Run - C:\Python27\python.exe -m test.regrtest ... stops at test_asynchat, been there for about 20mins. Can't seem to break the operation tho (Ctrl+C), it still hangs at test_asynchat with the blinking underscore one line down. -- Added file: http://bugs.python.org/file20450/python test halt.jpg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10935] wsgiref.handlers.BaseHandler and subclasses of str
Denis S. Otkidach denis.otkid...@gmail.com added the comment: Current behavior is unpythonic: documentation explicitly mentions isinstance as preferred way to check type (see http://docs.python.org/library/types.html ). Also 2.7 is the last minor version with str as main string type. So I believe it should use isinstance(val, basestring) to help transition to Python 3. -- nosy: +ods ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8954] wininst regression: errors when building on linux
anatoly techtonik techto...@gmail.com added the comment: Is this issue really critical? Bump. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8954] wininst regression: errors when building on linux
Changes by anatoly techtonik techto...@gmail.com: Added file: http://bugs.python.org/file20451/issue1774043_7001.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10828] Python 3 doesn't support non-ASCII module names with a locale encoding different than UTF-8
Changes by STINNER Victor victor.stin...@haypocalc.com: -- title: Cannot use nonascii utf8 in names of files imported from - Python 3 doesn't support non-ASCII module names with a locale encoding different than UTF-8 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Vladimir Rutsky rutsky.vladi...@gmail.com added the comment: SilentGhost, thanks for the patch! I can confirm, that adding os.path.normcase fixes issues with different cases of files. I believe there also may be issue with FAT's long file name mangling, like C:\PROGRA~1\python26\ instead of C:\Program Files\python26\. But never experienced such issue with Python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4106] multiprocessing occasionally spits out exception during shutdown
Jesse Noller jnol...@gmail.com added the comment: On Tue, Jan 18, 2011 at 6:23 PM, Brian Thorne rep...@bugs.python.org wrote: Brian Thorne hardb...@gmail.com added the comment: With the example script attached I see the exception every time. On Ubuntu 10.10 with Python 2.6 Since the offending line in multiprocesing/queues.py (233) is a debug statement, just commenting it out seems to stop this exception. Looking at the util file shows the logging functions to be all of the form: if _logger: _logger.log(... Could it be possible that after the check the _logger global (or the debug function) is destroyed by the exit handler? Can we convince them to stick around until such a time that they cannot be called? Adding a small delay before joining also seems to work, but is ugly. Why should another Process *have* to have a minimum amount of work to not throw an exception? See http://bugs.python.org/issue9207 - but yes, the problem is that the VM is nuking our imported modules before all the processes are shutdown. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4106 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Vladimir Rutsky rutsky.vladi...@gmail.com added the comment: Sorry I was wrong - patch don't fix original issue. Case should be normalized not only for directories provided through --ignore-dir, but also for directories obtained from __file__. In my tests on Windows Ignore.names(self, filename, modulename) receives `filename''s argument like: C:\Python26\Lib\site-packages\shapely\__init__.pyc Attaching patch fixes this issue for me (for Python 2.7 from http://svn.python.org/projects/python/branches/release27-maint, patch attached by SilentGhost is for 3.X I think). -- nosy: +SilentGhost Added file: http://bugs.python.org/file20452/trace_ignore_case_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Antoine Pitrou pit...@free.fr added the comment: Ok, fixed in r88111 (3.2), r88112 (3.1) and r88113 (2.7). -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10898 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
