[ANNOUNCE] python-gtkmvc 1.99.1
We are proud to announce that version 1.99.1 of pygtkmvc has been released. Project homepage: http://apps.sourceforge.net/trac/pygtkmvc/wiki Download: http://sourceforge.net/projects/pygtkmvc/ == About pygtkmvc == pygtkmvc is a fully Python-based implementation of the Model-View-Controller (MVC) and Observer patterns for the PyGTK2 toolkit. MVC is a pattern that can be successfully used to design and develop well structured GUI applications. The MVC pattern basically helps in separating semantics and data of the application, from their representation. The Observer pattern helps to weaken dependencies among parts that should be separated, but need to be connected each other. pygtkmvc provides a powerful and still simple infrastructure to help designing and implement GUI applications based on the MVC and Observer patterns. The framework has been designed to be: * Essential and small, it does only what it was designed for. * Not an external dependency for your application: it fits in 200KB and can be released along with it. * Easy to understand and to use; fully documented. * Portable: straightly runs under many platforms. License: LGPL ** * Dec 30 2010* ** Released version 1.99.1 This is a release that keeps compatibility with previous version 1.99.0. However, some features provided in 1.99.0 are deprecated in 1.99.1. This version goes in the direction of stabilizing the API and making the code more robust. Many bugs were fixed, and a new, clean API is now provided for defining notification methods in observers, and logical observable properties in models. The documentation has been updated and extended to reflect all changes, and a complete Library Reference is now available. Furthermore, the documentation now uses Sphinx instead of Latex to generate both pdf and html documentation formats. Last but not the least, the team grew up! * New - Models now feature Logical Observable Properties, along with already supported Concrete Observable Properties. - In Observers notification methods have all the same prototype, which make much cleaner the application code. - New mechanism to declare both dynamically and statically notification methods in Observers. - Auto-adapt of FileChooserButton, ComboBox and Adjustment - API to extend default adapter list - More widget types now correctly cast when adapted to unicode/int/float properties. - Enable RoUserClassAdapter to update the widget. It used to only do it when connecting, not on property changes. This makes the built-in support for gtk.Calendar work in both directions. - Controller's method adapt() allows auto-adaption even if the view does not have corresponding widgets for *all* properties in the model. - Adapters can optionally call prop_write *instead of* casting the value from the widget to the type of the old property value. This was the intended behaviour all along. Default is still to call it after the cast. - Decorators for property setters/getters in models. The methods can now have arbitrary names and you are no longer limited to one property per method. * Changed - Name-based notification methods like `property_name_value_change` are still supported, but their usage is now discouraged. A new mechanism for declaring notifications is now available, and you should consider porting applications accordingly. - Decorator Observer.observes is now deprecated. A new mechanism for declaring notifications is now available, and you should consider porting applications accordingly. - Support GtkBuilder in addition to libglade, which is no longer required. This changed the signature of the View constructor. The two formats are not equivalent, as GTK cannot build only parts of a file. - Allow creation of adapters that act on spurious notifications. - Use less eval(codestring) This changed how adapters create observer functions. If you have adapter subclasses you will have to adjust them. - Misuse of the framework that used to exit your application can now be caught as exceptions. - Fewer warnings printed by the framework. Remember to increase the logging level during development. * Fixed - Assigning a tuple with length 3 to a property no longer raises - Pass the correct model when emitting notifications for an inherited signal. This changes how all property wrappers track their owners, but your code should not be affected. - Wrapped sequences lacked crucial special methods like len and iter. - Inspecting wrappers no longer omits the class name. - Various changes to make SQLObjectModel actually usable. - Wrapping more than one sequence class
[ANN] python-gtkmvc 1.99.1
We are proud to announce that version 1.99.1 of pygtkmvc has been released. Project homepage: http://apps.sourceforge.net/trac/pygtkmvc/wiki Download: http://sourceforge.net/projects/pygtkmvc/ == About pygtkmvc == pygtkmvc is a fully Python-based implementation of the Model-View-Controller (MVC) and Observer patterns for the PyGTK2 toolkit. MVC is a pattern that can be successfully used to design and develop well structured GUI applications. The MVC pattern basically helps in separating semantics and data of the application, from their representation. The Observer pattern helps to weaken dependencies among parts that should be separated, but need to be connected each other. pygtkmvc provides a powerful and still simple infrastructure to help designing and implement GUI applications based on the MVC and Observer patterns. The framework has been designed to be: * Essential and small, it does only what it was designed for. * Not an external dependency for your application: it fits in 200KB and can be released along with it. * Easy to understand and to use; fully documented. * Portable: straightly runs under many platforms. License: LGPL ** * Dec 30 2010* ** Released version 1.99.1 This is a release that keeps compatibility with previous version 1.99.0. However, some features provided in 1.99.0 are deprecated in 1.99.1. This version goes in the direction of stabilizing the API and making the code more robust. Many bugs were fixed, and a new, clean API is now provided for defining notification methods in observers, and logical observable properties in models. The documentation has been updated and extended to reflect all changes, and a complete Library Reference is now available. Furthermore, the documentation now uses Sphinx instead of Latex to generate both pdf and html documentation formats. Last but not the least, the team grew up! * New - Models now feature Logical Observable Properties, along with already supported Concrete Observable Properties. - In Observers notification methods have all the same prototype, which make much cleaner the application code. - New mechanism to declare both dynamically and statically notification methods in Observers. - Auto-adapt of FileChooserButton, ComboBox and Adjustment - API to extend default adapter list - More widget types now correctly cast when adapted to unicode/int/float properties. - Enable RoUserClassAdapter to update the widget. It used to only do it when connecting, not on property changes. This makes the built-in support for gtk.Calendar work in both directions. - Controller's method adapt() allows auto-adaption even if the view does not have corresponding widgets for *all* properties in the model. - Adapters can optionally call prop_write *instead of* casting the value from the widget to the type of the old property value. This was the intended behaviour all along. Default is still to call it after the cast. - Decorators for property setters/getters in models. The methods can now have arbitrary names and you are no longer limited to one property per method. * Changed - Name-based notification methods like `property_name_value_change` are still supported, but their usage is now discouraged. A new mechanism for declaring notifications is now available, and you should consider porting applications accordingly. - Decorator Observer.observes is now deprecated. A new mechanism for declaring notifications is now available, and you should consider porting applications accordingly. - Support GtkBuilder in addition to libglade, which is no longer required. This changed the signature of the View constructor. The two formats are not equivalent, as GTK cannot build only parts of a file. - Allow creation of adapters that act on spurious notifications. - Use less eval(codestring) This changed how adapters create observer functions. If you have adapter subclasses you will have to adjust them. - Misuse of the framework that used to exit your application can now be caught as exceptions. - Fewer warnings printed by the framework. Remember to increase the logging level during development. * Fixed - Assigning a tuple with length 3 to a property no longer raises - Pass the correct model when emitting notifications for an inherited signal. This changes how all property wrappers track their owners, but your code should not be affected. - Wrapped sequences lacked crucial special methods like len and iter. - Inspecting wrappers no longer omits the class name. - Various changes to make SQLObjectModel actually usable. - Wrapping more than one
Re: Does Python 3.1 accept \r\n in compile()?
On 30 Dez., 00:11, Terry Reedy tjre...@udel.edu wrote: On 12/29/2010 4:06 PM, jmfauth wrote: On 29 Dez., 21:14, Terry Reedytjre...@udel.edu wrote: On 12/29/2010 2:31 PM, Terry Reedy wrote: Changed in version 3.2: Allowed use of Windows and Mac newlines. Also input in 'exec' mode does not have to end in a newline anymore. Added the optimize parameter. Retest shows that above is correct. compile(print(999)\r\n, blah, exec) code objectmodule at 0x00F5EC50, file blah, line 1 Ok, I see. Thanks. The '\r\n' acceptance has been introduced in Python 2.7 and I was a little bit suprised with Python 3.1. 2.6 was followed by 3.0 and then 3.1. 2.7 will be followed by 3.2 in a couple more month. That feature was added to 2.7 and 3.2 in Nov 2009 long after 3.1. -- Terry Jan Reedy Thanks for these precisions and don't worry too much, it's not a real isssue. (I'v seen the noise on the pydev list). Thanks again. -- http://mail.python.org/mailman/listinfo/python-list
os.path.isfile and wildcard for directory name
Hi everyone, I'm just beginning to learn python language and i'm trying to do something and i can't figure it out. I want to test if a file exists but my path contain a directory name that differs from a server to another. In shell i would have done something like that : #!/bin/bash mypath=/dire*/directory02/ myfile=filename myfile=toto if [ -f $mypath/$myfile ] then echo File $file exists fi How can i do the same thing (wildcard in a directory name) in python please ? Thanks for your help ! Smaine -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.isfile and wildcard for directory name
Hello,
2010/12/30 smain...@free.fr:
How can i do the same thing (wildcard in a directory name) in python please ?
You can get the contents of a directory with os.listdir and filter
with fnmatch.fnmatch more or less as in the example from the
documentation:
-
import fnmatch
import os
for file in os.listdir('.'):
if fnmatch.fnmatch(file, '*.txt'):
print file
-
Regards,
Javier
--
http://mail.python.org/mailman/listinfo/python-list
Re: Removing an attribute from html with Regex
Selvam, 30.12.2010 08:30:
I have some HTML string which I would like to feed to BeautifulSoup.
But, One malformed attribute breaks BeautifulSoup.
p style='terp_header' wrong_tag=' text1 ' text2 ' and 'para' '
class='terp_header' My String/p
Didn't try with BS (and you forgot to say what breaks means exactly in
your case), but it parses in a somewhat reasonable way with lxml:
Python 3.2b2 (py3k:87572, Dec 29 2010, 21:25:38)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
import lxml.html as H
doc = H.fromstring('''
... p style='terp_header' wrong_tag=' text1 ' text2 ' and 'para' '
... class='terp_header' My String/p
... ''')
H.tostring(doc)
b'p style=terp_header wrong_tag= text1 text2 and \
class=terp_header My String/p'
doc.attrib
{'text2': '', 'and': '', 'style': 'terp_header', \
'wrong_tag': ' text1 ', 'class': 'terp_header'}
I would like it to replace all the occurances of that attribute with an
empty string.
I am unable to figure out the exact regex, which can do this job.
This is what, I have managed so far,
m = re.compile(rml_except='([^']*))
I assume rml_accept is the real name of the attribute?
You may be able to do this with a look-ahead expression, e.g.:
replace = re.compile('(wrong_tag\s*=\s*[^=]*)(?=|\s+\w+\s*=)').sub
html_data = replace('', html_data)
The trick is to match everything up to the next character that looks
reasonable again, i.e. a closing tag character () or another attribute.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: os.path.isfile and wildcard for directory name
On 30Dec2010 09:36, smain...@free.fr smain...@free.fr wrote: | I want to test if a file exists but my path contain a directory name that | differs from a server to another. | In shell i would have done something like that : | #!/bin/bash | mypath=/dire*/directory02/ | myfile=filename | myfile=toto | if [ -f $mypath/$myfile ] [...] Check out the glob module: http://docs.python.org/library/glob.html#module-glob Use it to do the glob, then os.path.isfile with a path constructed from the result: http://docs.python.org/library/os.path.html#os.path.isfile Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Any company large enough to have a research lab is large enough not to listen to it. - Alan Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.isfile and wildcard for directory name
smain...@free.fr wrote:
I'm just beginning to learn python language and i'm trying to do something
and i can't figure it out.
I want to test if a file exists but my path contain a directory name that
differs from a server to another.
In shell i would have done something like that :
#!/bin/bash
mypath=/dire*/directory02/
myfile=filename
myfile=toto
if [ -f $mypath/$myfile ]
then
echo File $file exists
fi
How can i do the same thing (wildcard in a directory name) in python
please ?
Given
$ mkdir yadda{1..10}
$ touch yadda{5,7}/alpha
$ mkdir yadda{2,4}/alpha
You can get a list of candidates with
import glob
candidates = glob.glob(yadda*/alpha)
candidates
['yadda5/alpha', 'yadda2/alpha', 'yadda4/alpha', 'yadda7/alpha']
and then use isfile() to find the actual files:
import os
[f for f in candidates if os.path.isfile(f)]
['yadda5/alpha', 'yadda7/alpha']
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Digitally Signing a XML Document (using SHA1+RSA or SHA1+DSA)
On Tue, 2010-12-28, Adam Tauno Williams wrote: On Tue, 2010-12-28 at 03:25 +0530, Anurag Chourasia wrote: Hi All, I have a requirement to digitally sign a XML Document using SHA1+RSA or SHA1+DSA Could someone give me a lead on a library that I can use to fulfill this requirement? http://stuvel.eu/rsa Never used it though. The XML Document has values such as RSASK-BEGIN RSA PRIVATE KEY- MIIBOgIBAAJBANWzHfF5Bppe4JKlfZDqFUpNLrwNQqguw76g/jmeO6f4i31rDLVQ n7sYilu65C8vN+qnEGnPB824t/A3yfMu1G0CAQMCQQCOd2lLpgRm6esMblO18WOG ... Is this any kind of standard or just something someone made up? Is there a namespace for the document? It seems quite odd that the document contains a *private* key. If all you need to do is parse to document to retrieve the values that seems straight-forward enough. And the XML also has another node that has a Public Key with Modules and Exponents etc that I apparently need to utilize. RSAPK M1bMd8XkGml7gkqV9kOoVSk0uvA1CqC7DvqD +OZ47p/iLfWsMtVCfuxiKW7rkLy836qcQac8Hzbi38DfJ8y7UbQ==/M EAw==/E /RSAPK I am a little thin on this concept and expecting if you could guide me to a library/documentation that I could utilize. [The original posting by Anurag Chourasia did not reach my news server.] I'd simply invoke GnuPG. A simple example: % gpg --sign --armor foo You need a passphrase to unlock the secret key for user: ... % head foo.asc -BEGIN PGP MESSAGE- Version: GnuPG v1.4.9 (GNU/Linux) owGs+TuuLdGWRQu9B1hTwsAHaRUhPjN+DjVAWBRgxs+nGAgHA58aUA88RHVw6K3N 2PfefJn5Mg2ko6N99lkrYn7G6KN//m//6//l//C/+N/8X/5P/6//+//u//r/+P/+ ... The result isn't XML, but it *is* a standardized file format readable by anyone. That's worth a lot. You can also create a detached signature and ship it together with the original file, or skip the '--armor' and get a binary signed file. If you really *do* have a requirement to make the result XML-like and incompatible with anything else, I'm afraid you're on your own, and will have a lot of extra work testing and making sure it's all secure. /Jorgen -- // Jorgen Grahn grahn@ Oo o. . . \X/ snipabacken.se O o . -- http://mail.python.org/mailman/listinfo/python-list
Re: Digitally Signing a XML Document (using SHA1+RSA or SHA1+DSA)
Jorgen Grahn, 30.12.2010 10:41: If you really *do* have a requirement to make the result XML-like and incompatible with anything else, I'm afraid you're on your own Well, there's always xmlsec if you need it. http://www.aleksey.com/xmlsec/ Stefan -- http://mail.python.org/mailman/listinfo/python-list
Embedding a Python IDE on Windows based Application
Hi Ppl, I'm trying to use python for a macro recorder. In short I have a windows based application, which has a macro recorder. The macros are captured as a python script and when the script is executed they accomplish the user action done on my application. I've written python scripts that can invoke the user events on the application through ActiveX server of my application. I've been trying to run these macro python scripts using the command line option from my application. I also explored the extending and embedding the python interpreter http://docs.python.org/extending/ option for executing my python scripts from my application. But I feel it will be great if I can embed a simple xpython IDE on my application to write these macro python scripts and debug them. I tried searching for any python IDE's which are available as ActiveX or .net containers, so that I can easily embed them. But I had no success. Is there any way I can accomplish this? Thanks, Sathish -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.isfile and wildcard for directory name
Hi Cameron, Ok, i'll try that :) Thanks Smaine Selon Cameron Simpson c...@zip.com.au: On 30Dec2010 09:36, smain...@free.fr smain...@free.fr wrote: | I want to test if a file exists but my path contain a directory name that | differs from a server to another. | In shell i would have done something like that : | #!/bin/bash | mypath=/dire*/directory02/ | myfile=filename | myfile=toto | if [ -f $mypath/$myfile ] [...] Check out the glob module: http://docs.python.org/library/glob.html#module-glob Use it to do the glob, then os.path.isfile with a path constructed from the result: http://docs.python.org/library/os.path.html#os.path.isfile Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Any company large enough to have a research lab is large enough not to listen to it. - Alan Kay -- http://mail.python.org/mailman/listinfo/python-list
Is there anyway to run JavaScript in python?
Hi, I'm writing a test tool to simulate Web browser. Is there anyway to run JavaScript in python? Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 29, 7:48 pm, Octavian Rasnita orasn...@gmail.com wrote: First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems. And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also. Which is where the contradiction comes into play: to use the actual native widgets, you have to write some C (or Objective-C). Of course, on Windows, people have faked the native widgets so many times that you could probably get away with it if you made a really good fake, though there are still a lot of gotchas that go with that (accessibility and all that other stuff). On Linux, it's not like there's really a standard anyway. That leaves OS X as the really troublesome one. WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great. Speed is not even on the list of things I'd be worried about first. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there anyway to run JavaScript in python?
In article a05193b8-46cd-4d17-a8d4-fb9106d3a...@n32g2000pre.googlegroups.com, crow wen...@gmail.com wrote: Hi, I'm writing a test tool to simulate Web browser. Is there anyway to run JavaScript in python? Thanks in advance. The answer to the question you asked is, Probably. You might want to check out SpiderMonkey as a starting point. The answer to the question you didn't ask is, Before you invest a lot of effort in this, check out Selenium. http://en.wikipedia.org/wiki/SpiderMonkey_(JavaScript_engine) http://en.wikipedia.org/wiki/Selenium_(software) Another thing to think about is whether you really do need JS to test your web app. Depending on how much your app depends on JS for its core functionality, you may find that just using urllib to fetch pages, parsing the HTML with lxml, and verifying that certain data exists in the appropriate HTML elements might get you 80% of the testing value for 20% of the effort. But, I digress. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/29/10 6:58 PM, rantingrick wrote: The answer is simple. We need a 100% Python GUI. A GUI coded in Python from top to bottom. A GUI that is cross platform to the big three (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but also a GUI that can be manipulated by the average python programmer. A GUI that not only teaches the fundamentals of using a GUI, but also a GUI that teaches how a GUI works under the hood Any GUI framework is going to require at least some heavy lifting in C, C++ or Objective-C (depending on the platform). A pure-Python approach to GUI development is technically infeasible. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there anyway to run JavaScript in python?
Am 30.12.2010 14:52, schrieb crow: Hi, I'm writing a test tool to simulate Web browser. Is there anyway to run JavaScript in python? Thanks in advance. See PyV8: http://pypi.python.org/pypi/PyV8 Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 8:59 am, Kevin Walzer k...@codebykevin.com wrote: On 12/29/10 6:58 PM, rantingrick wrote: Any GUI framework is going to require at least some heavy lifting in C, C++ or Objective-C (depending on the platform). A pure-Python approach to GUI development is technically infeasible. This is a very good point Kevin however i would much rather spend time learning a language like C --which is hugely useful in many contexts!-- than to waste one second of my time on a domain specific language like TCl which is created only for drawing GUIs using Tk. I think everyone can agree that learning C is of benefit far more benefit to anyone in the programming field. Also one could argue that C and Python are very similar. However Python and Tcl are like night and day. This monkey on our back (TclTk) is dead weight. We need to free ourselves of this GUI prison and bring Python into the 21st century. Tk is old and ugly. Tk is slow. Tk is incomplete and it will never be complete or extensible within our community. There is no OpenGL canvas readily available. Sure you can use Togl (as i have successfully!) however Togl is old and unmaintained. Any GUI library in this day and age must support opengl out of the box! Look, losing Tkinter will be very painful for me as i have tons of code written already. However the more i learn about Tkinter the more i realize how Tkinter is a dead end street. Why let a rotting dinosaur stagnate in the stdlib? Anybody that has foresight knows Tkinter is dying and cannot be revived. It is time to move on. Tkinter served us well for a time but we must let go and evolve -- lest we wither and die ourselves! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Thursday, December 30, 2010 9:59:09 AM UTC-5, kw wrote: Any GUI framework is going to require at least some heavy lifting in C, C++ or Objective-C (depending on the platform). A pure-Python approach to GUI development is technically infeasible. -- Kevin Walzer Code by Kevin http://www.codebykevin.com So I thought. Then I came across a framework (Cappucinno.org) and a Visual Designer (280Atlas.com) written entirely in JavaScript (well, Objective-J which gets compiled to JavaScript). Check out 280Slides.com or http://githubissues.heroku.com/#280north/cappuccino for examples of what can be done using JavaScript, and 280Atlas.com for a video of their visual designer. If that designer can be written in JavasScript (it runs on the web, BTW, and only as an after-thought as a desktop app), then it can be done in Python. Having worked for 20 years in a windows-based development tool that painted controls (giving them fake hwnd's) to get enough speed to run on Windows, this was a real game-changer for me. Hank -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
rantingrick, 30.12.2010 00:58: So what should we do? The answer is simple. We need a 100% Python GUI. A GUI coded in Python from top to bottom. A GUI that is cross platform to the big three (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but also a GUI that can be manipulated by the average python programmer. A GUI that not only teaches the fundamentals of using a GUI, but also a GUI that teaches how a GUI works under the hood I hope you invested as much time into writing this expose as you did searching the web before writing it. http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ (the site is currently broken for me, you can use the following instead: http://webcache.googleusercontent.com/search?q=cache:WsGrJKw6ABoJ:www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/30/10 10:24 AM, rantingrick wrote: On Dec 30, 8:59 am, Kevin Walzerk...@codebykevin.com wrote: On 12/29/10 6:58 PM, rantingrick wrote: Any GUI framework is going to require at least some heavy lifting in C, C++ or Objective-C (depending on the platform). A pure-Python approach to GUI development is technically infeasible. This is a very good point Kevin however i would much rather spend time learning a language like C --which is hugely useful in many contexts!-- than to waste one second of my time on a domain specific language like TCl which is created only for drawing GUIs using Tk. I think everyone can agree that learning C is of benefit far more benefit to anyone in the programming field. Also one could argue that C and Python are very similar. However Python and Tcl are like night and day. Tcl is not a domain-specific language for creating GUI's. Tcl is a full-featured, general-purpose programming language that is a peer to Python in its capabilities, and surpasses Python in some respects. This monkey on our back (TclTk) is dead weight. We need to free ourselves of this GUI prison and bring Python into the 21st century. Tk is old and ugly. Tk is slow. Tk is incomplete and it will never be complete or extensible within our community. In 2010, Tk only lacks two major features common to GUI toolkits: 1. A cross-platform printing API. This is mainly an issue on Windows, which lacks a rich command-line printing framework. The canvas widget can generate PostScript, and the text widget can export its contents to a text file, and then lpr can handle the rest on Unix systems (including the Mac). Still, if you want native dialogs and full integration with a platform-specific printing API, you will have to utilize one of several, incompatible, platform-specific extensions. 2. A robust widget for HTML display. The old TkHTML widget (authored by D. Richard Hipp, the author of SQLite) works, but it's very dated (last updated in 2002) and lacks modern features like CSS support. An effort to produce a next-generation HTML widget, TkHTML 3, yielded an alpha-quality widget that is enormously complex, somewhat buggy, and little used. These days, Tkinter has pretty much everything that other GUI toolkits have: tree views, multi-column listboxes, plus all the basics, available through the core widget, the themed ttk widgets, or extension packages. Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app is ugly, that's a reflection on the developer, not the toolkit. There is no OpenGL canvas readily available. Sure you can use Togl (as i have successfully!) however Togl is old and unmaintained. Any GUI library in this day and age must support opengl out of the box! Togl is still developed. One of its maintainers, Greg Couch, is a developer on the UCSF Chimera project (a Python-Tkinter based molecule viewer). Look, losing Tkinter will be very painful for me as i have tons of code written already. However the more i learn about Tkinter the more i realize how Tkinter is a dead end street. Why let a rotting dinosaur stagnate in the stdlib? Anybody that has foresight knows Tkinter is dying and cannot be revived. It is time to move on. Tkinter served us well for a time but we must let go and evolve -- lest we wither and die ourselves! I have nothing against other toolkits, and if one happens to catch on, fine. But your assertions that Tkinter/Tk is dying have no basis in fact. I'm an active developer in Tk with both Tcl and Python, and the reason I have stayed with the toolkit is precisely because it isn't dying. Check out the screenshots at my website--all those GUI's are developed in Tk. Here's one in Tkinter/Python: http://www.codebykevin.com/phynchronicity-running.png --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/30/10 10:28 AM, Hank Fay wrote: On Thursday, December 30, 2010 9:59:09 AM UTC-5, kw wrote: Any GUI framework is going to require at least some heavy lifting in C, C++ or Objective-C (depending on the platform). A pure-Python approach to GUI development is technically infeasible. -- Kevin Walzer Code by Kevin http://www.codebykevin.com So I thought. Then I came across a framework (Cappucinno.org) and a Visual Designer (280Atlas.com) written entirely in JavaScript (well, Objective-J which gets compiled to JavaScript). Check out 280Slides.com or http://githubissues.heroku.com/#280north/cappuccino for examples of what can be done using JavaScript, and 280Atlas.com for a video of their visual designer. If that designer can be written in JavasScript (it runs on the web, BTW, and only as an after-thought as a desktop app), then it can be done in Python. Having worked for 20 years in a windows-based development tool that painted controls (giving them fake hwnd's) to get enough speed to run on Windows, this was a real game-changer for me. Hank Yes, this is slick, and it looks nearly native, but, um...it's still running inside a browser. It's not a desktop app. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: How to initialize each multithreading Pool worker with an individual value?
In article mailman.61.1291152972.2649.python-l...@python.org, Valery Khamenya khame...@gmail.com wrote: However it doesn't look possible to use it to initialize each Pool's worker with some individual value (I'd wish to be wrong here) So, how to initialize each multithreading Pool worker with the individual values? The typical use case might be a connection pool, say, of 3 workers, where each of 3 workers has its own TCP/IP port. from multiprocessing.pool import Pool def port_initializer(_port): global port port = _port def use_connection(some_packet): global _port print sending data over port # %s % port if __name__ == __main__: ports=((4001,4002, 4003), ) p = Pool(3, port_initializer, ports) # oops... :-) You probably can't use initargs here. Your port_initializer needs to be some kind of class instance that works with multiprocessing and emits one port number when its __call__() method gets invoked. (There may be other ways to accomplish the same effect, but that's what springs to mind.) -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Think of it as evolution in action. --Tony Rand -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/30/10 10:52 AM, Stefan Behnel wrote: rantingrick, 30.12.2010 00:58: So what should we do? The answer is simple. We need a 100% Python GUI. A GUI coded in Python from top to bottom. A GUI that is cross platform to the big three (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but also a GUI that can be manipulated by the average python programmer. A GUI that not only teaches the fundamentals of using a GUI, but also a GUI that teaches how a GUI works under the hood I hope you invested as much time into writing this expose as you did searching the web before writing it. http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ (the site is currently broken for me, you can use the following instead: http://webcache.googleusercontent.com/search?q=cache:WsGrJKw6ABoJ:www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ This library isn't much different from other Python GUI toolkits--it's dependent on underlying, rather large, platform-specific implementations--but it provides an even higher level of abstraction. On the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11, pygtk. In short, it's a wrapper over other wrappers. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 9:52 am, Stefan Behnel stefan...@behnel.de wrote: I hope you invested as much time into writing this expose as you did searching the web before writing it. And ditto to you. If you would have followed the thread so far, in my second post i said... However i need to stress that my intention is towards a 100% Python GUI. Not a binding, not a wrapping (except for OS calls!) but a *real* Python GUI. The only thing that i know of at this point is pyGUI although there are probably others.[198:203] -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
rantingrick, 30.12.2010 17:02: On Dec 30, 9:52 am, Stefan Behnel wrote: I hope you invested as much time into writing this expose as you did searching the web before writing it. in my second post i said... However i need to stress that my intention is towards a 100% Python GUI. Not a binding, not a wrapping (except for OS calls!) but a *real* Python GUI. The only thing that i know of at this point is pyGUI although there are probably others. Sure, fine, just making sure you know the terrain. If that's not enough for you, you should follow Steven's advice to get started implementing something, because this may become a lengthy undertaking. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
These days, Tkinter has pretty much everything that other GUI toolkits have: tree views, multi-column listboxes, plus all the basics, available through the core widget, the themed ttk widgets, or extension packages. ***Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app is ugly, that's a reflection on the developer, not the toolkit*** +1 (emphasis added) Other tk/ttk benefits: - Very stable - Cross platform (w/native look and feel via Python 2.7/3.1 ttk) - Light weight - Easy to distribute - Extensible Regarding lack of print support: All GUI frameworks suck in this regard. The best approach is to use a technology designed for generating hard copy output - something like PDF, TeX, or RTF library. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: How to initialize each multithreading Pool worker with an individual value?
On Thu, 2010-12-30 at 08:01 -0800, Aahz wrote: In article mailman.61.1291152972.2649.python-l...@python.org, Valery Khamenya khame...@gmail.com wrote: However it doesn't look possible to use it to initialize each Pool's worker with some individual value (I'd wish to be wrong here) So, how to initialize each multithreading Pool worker with the individual values? The typical use case might be a connection pool, say, of 3 workers, where each of 3 workers has its own TCP/IP port. from multiprocessing.pool import Pool def port_initializer(_port): global port port = _port def use_connection(some_packet): global _port print sending data over port # %s % port if __name__ == __main__: ports=((4001,4002, 4003), ) p = Pool(3, port_initializer, ports) # oops... :-) You probably can't use initargs here. Your port_initializer needs to be some kind of class instance that works with multiprocessing and emits one port number when its __call__() method gets invoked. (There may be other ways to accomplish the same effect, but that's what springs to mind.) Maybe this is obvious; but it is possible to create a pool of workers all listening on the same socket. An idle worker will pick-up the connection. Just open the socket in the initial process and then fork your workers - they will inherit the file handle and can accept() on it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 9:51 am, Kevin Walzer k...@codebykevin.com wrote: Tcl is not a domain-specific language for creating GUI's. Tcl is a full-featured, general-purpose programming language that is a peer to Python in its capabilities, Anybody can gloat and gush about their favorite programming language however what separates fantasy from reality is evidence of these theories. Or rather, Illusions of grandeur! and surpasses Python in some respects. The only thing that Tcl has over Python is building Tk GUI's. Please post evidence otherwise if you dare! In the meantime i will not be holding my breath. In 2010, Tk only lacks two major features common to GUI toolkits: 1. A cross-platform printing API. This is mainly an issue on Windows, which lacks a rich command-line printing framework. True windows has no one-liner send-to-print-function but what it does have is GDI and GDI+ which are far more powerful for windows programmers. Sure you may have to issue a few dc.MoveTo(x,y) and dc.LineTo(x,y) and dc.TextOut(blah) but what is so hard about that? Really, if you want a one liner just wrap up some Python code into a nice interface. This argument is either completely bogus or utterly idiotic. 2. A robust widget for HTML display. The fact that Tkinter lacks an HTML widget is of no concern to me. Actually if i had a choice of including HTML support or not i would opt for not. Why? Because the simple fact is that Python needs a simplistic GUI and not bloat-ware in the stdlib. HTML widgets, handy dandy anolog clocks, happy faces and dancing bananas widgets belong in 3rd party extension library's and not in the Python stdlib. However we must make sure that any GUI we support not only has these widgets available as extension libraries but that these libraries are currently maintained. If you are going to complain about lacking widgets then Togl would be a good starting point. These days, Tkinter has pretty much everything that other GUI toolkits have: tree views, multi-column listboxes, plus all the basics, available through the core widget, the themed ttk widgets, or extension packages. Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app is ugly, that's a reflection on the developer, not the toolkit. Yes Tk is not all bad for TclTk, however it IS all bad for Python. Let the Tcl folks use Tk and we will use a python GUI. Nuff said. Togl is still developed. One of its maintainers, Greg Couch, is a developer on the UCSF Chimera project (a Python-Tkinter based molecule viewer). Have you seen the code in togl.py yourself? I mean really read it from beginning to end? It's a hodgepodge of poorly written code. I know this because i had to update the code myself for one of my projects. Look i have nothing against you Kevin. However i know you and Tkinter (and Tcl) are in bed together. So this is more of a *personal* decision for you instead of a *community* decision. Whether Tkinter exists in the stdlib or not should't matter to you because you can just download it from a 3rd party site. And *if* enough people really love Tkinter as you suggest then removing it will not kill it. However you know as well as i do that Tkinter is a drain on this community and the only thing keeping it alive is the fact that it is packaged in the stdlib. Once Tkinter is removed it will die as it should and something better will take it's place. Something more Pythonic. And most importantly something that is completely and totally under the direct control of the Python community. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 10:02 am, Kevin Walzer k...@codebykevin.com wrote: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ This library isn't much different from other Python GUI toolkits--it's dependent on underlying, rather large, platform-specific implementations--but it provides an even higher level of abstraction. On the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11, pygtk. In short, it's a wrapper over other wrappers. hmm. And what is Tkinter exactly? And more importantly how is it better than pyGUI (design wise)? And even more importanly, how will it be better in the long run? Is this just more FUD Kevin Gates? -- http://mail.python.org/mailman/listinfo/python-list
Tkinter accessability options (was Re: Tkinter: The good, the bad, and the ugly!)
Octavian, Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them. Might this package help? (I have no experience with this project) Tka11y 0.1.1 - accessibility-aware Tkinter http://pypi.python.org/pypi/Tka11y Another idea: Use Tkinters Enter events to speak TTS descriptions of the current control and/or its contents? I would love to hear from anyone using either of techniques ... or other techniques or screen reader products ... to make their Tkinter applications accessible to low vision/blind users. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
That (the desktop app issue) was the big game-change for me. It looks like a desktop app, it acts like a desktop app, and our enterprise customers would be delighted to a) have no installs to do for fat clients; or b) not have to run a TS or Citrix farm. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter accessability options (was Re: Tkinter: The good, the bad, and the ugly!)
From: pyt...@bdurham.com Subject: Tkinter accessability options (was Re: Tkinter: The good, the bad, and the ugly!) Octavian, Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them. Might this package help? (I have no experience with this project) Tka11y 0.1.1 - accessibility-aware Tkinter http://pypi.python.org/pypi/Tka11y Another idea: Use Tkinters Enter events to speak TTS descriptions of the current control and/or its contents? I would love to hear from anyone using either of techniques ... or other techniques or screen reader products ... to make their Tkinter applications accessible to low vision/blind users. Malcolm Thank you very much for those projects! I will test them. Unfortunately they are not a solution because if I want to create an accessible app I can do it using an accessible library, but if the other programmers of the world use a non-accessible by default GUI, than their programs won't be accessible, or they will offer a limited accessibility like Java Access Bridge offers to SWING-based apps. If Tkinter would use that project that should offer the accessibility by default, that would be a real solution. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: default argument in method
There's some_object.some_method.func_defaults and some_function.func_defaults both are a settable attribute. How to set the methods func_defaults? You'd have to have code in _getattribute__(yourmethod) if not __getattr__(yourmethod) def __getattribute__(self, attr): if attr == self.my_method: # something like this, but i'm probably a little off # you might need to use super or something to prevent recursive __getattribute__ calls here self.my_method.func_defaults = self.foo -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Thu, 30 Dec 2010 07:24:04 -0800, rantingrick wrote:
Also one could argue that C and Python are very similar.
One could also argue that black is white, that diamond is softer than
chalk, and that bananas are a type of spaceship. Doesn't make it so.
How to add two numbers in C:
#include stdio.h
int main()
{
int a, b;
scanf(%d%d, a, b);
printf(%d\n, a + b);
return 0;
}
And in Python:
a, b = input().split() # use raw_input in Python 2
print(int(a) + int(b))
And in Tcl:
scan [gets stdin] %d %d x y
puts [expr {$x + $y}]
None of the three are exactly clones of each other, but it seems to me
that Tcl and Python are quite close in spirit, if not syntax.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/30/2010 10:51 AM, Kevin Walzer wrote: In 2010, Tk only lacks two major features common to GUI toolkits: 1. A cross-platform printing API. This is mainly an issue on Windows, which lacks a rich command-line printing framework. The canvas widget can generate PostScript, Uh. 1. Postscript is somewhat obsolete; being superseded somewhat by svg. 2. It is not as useful on Windows as it seems to be on *nux and macs -- not easy to either view or print. 3. The files it calls '.eps' are not readable by OOo. They can be read by Photoshop, which can then write a file, supposedly the same but actually not, that *can* be read by OOo. There was a thread on this list about the issue. I do not know whether tk is too sloppy in what it writes (and the file I look for a trivial drawing did look sloppy, with lots of near repetition) or whether OOo is too strict. But clearly, TK *could* write better .eps files (like Photoshop does). And the current output is clearly limited for my purposes. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: default argument in method
On Thu, 30 Dec 2010 11:26:50 -0800, DevPlayer wrote: There's some_object.some_method.func_defaults Not quite -- method objects don't expose the function attributes directly. You need some_object.some_method.im_func to get the function object, which then has a func_defaults attribute. and some_function.func_defaults both are a settable attribute. How to set the methods func_defaults? (1) You shouldn't mess with func_defaults unless you know what you're doing. (2) If you do know what you are doing, you probably won't want to mess with func_defaults. (3) But if you insist, then you would so the same way you would set any other object's attribute. class C(object): ... def method(self, x=[]): ... print x ... C().method() [] function = inst.method.im_func function.func_defaults ([],) function.func_defaults = (spam,) inst.method() spam (4) Seriously, don't do this. You'd have to have code in _getattribute__(yourmethod) if not __getattr__(yourmethod) def __getattribute__(self, attr): if attr == self.my_method: # something like this, but i'm probably a little off # you might need to use super or something to prevent recursive __getattribute__ calls here self.my_method.func_defaults = self.foo *cries* A much better solution would be: class MyClass: def my_method(self, x=None): if x is None: x = self.foo ... Don't write slow, confusing, complex, convoluted, self-modifying code when you can write fast, simple, straight-forward, obvious code. Unless you're doing it to win a bet. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
Steven D'Aprano wrote:
On Thu, 30 Dec 2010 07:24:04 -0800, rantingrick wrote:
Also one could argue that C and Python are very similar.
One could also argue that black is white, that diamond is softer than
chalk, and that bananas are a type of spaceship. Doesn't make it so.
How to add two numbers in C:
#include stdio.h
int main()
{
int a, b;
scanf(%d%d, a, b);
printf(%d\n, a + b);
return 0;
}
And in Python:
a, b = input().split() # use raw_input in Python 2
print(int(a) + int(b))
And in Tcl:
scan [gets stdin] %d %d x y
puts [expr {$x + $y}]
None of the three are exactly clones of each other, but it seems to me
that Tcl and Python are quite close in spirit, if not syntax.
They both have the interpreter spirit. Very different under the hood; Tcl
is the LISP of strings. They could have called it STRP.
Mel.
--
http://mail.python.org/mailman/listinfo/python-list
OSError: [Errno 26] Text file busy during subprocess.check_call() :seems os dependent
Hi, I am writing some multithreaded code which aims to automate three sequential data processing applications and distribute the processing on my 16GB RAM, 64 bit Ubuntu box running Python 2.6.5 The basic class that orchestrates these jobs use Queue.Queue() to feed the product of the first job into the Queue for the next job. Each Thread receives a dynamically generated shell script from some classes I wrote and then runs the script using subprocess.call([shell_script_file.sh]) I tested the code on a mac laptop and also on ubuntu. Curiously on Mac OSX 32 bit Core duo running snow leopard, the code always runs fine. However on my ubuntu box I get sporadic errors detailed below. I tried replacing the subprocess.call() with subprocess.Popen([shellscriptfile.sh],stdout=open(unique_process_id.log,w),stderr=open(unique_error_log.log,w) But I get the same OSError: [Errno 26] Text file busy error Everytime I run the same job queue a different part of the job fails. Unfortunately I dont see anybody else reporting this OSError. ANy help in troubleshooting my newbie thread code will be greatly appreciated. Thanks hari The orchestrator class is at: https://github.com/harijay/auriga/blob/master/process_multi.py A sample thread subclass is at : https://github.com/harijay/auriga/blob/master/scatomtzrunthread.py Detailed error: Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.6/threading.py, line 532, in __bootstrap_inner self.run() File /home/hari/Dropbox/auriga/scatomtzrunthread.py, line 28, in run stat = subprocess.call([file]) File /usr/lib/python2.6/subprocess.py, line 480, in call return Popen(*popenargs, **kwargs).wait() File /usr/lib/python2.6/subprocess.py, line 633, in __init__ errread, errwrite) File /usr/lib/python2.6/subprocess.py, line 1139, in _execute_child raise child_exception OSError: [Errno 26] Text file busy -- http://mail.python.org/mailman/listinfo/python-list
Re: OSError: [Errno 26] Text file busy during subprocess.check_call() :seems os dependent
At 03:46 PM 12/30/2010, harijay wrote: Hi, I am writing some multithreaded code which aims to automate three sequential data processing applications and distribute the processing on my 16GB RAM, 64 bit Ubuntu box running Python 2.6.5 The basic class that orchestrates these jobs use Queue.Queue() to feed the product of the first job into the Queue for the next job. Each Thread receives a dynamically generated shell script from some classes I wrote and then runs the script using subprocess.call([shell_script_file.sh]) You say dynamically generated. Any chance you are (re)using the same filename each time? Is it possible that two uses of that filename could occur at the same time? That is, is it possible that at the same time while one process is running from the script file, another process is trying to re-write the script file? And so maybe you need to have dynamically generated and unique filenames Most often I see references to binary executable files for the error message, but I've also seen references to script files, e.g. http://www.cyberciti.biz/faq/binbash-bad-interpreter-text-file-busy/ I tested the code on a mac laptop and also on ubuntu. Curiously on Mac OSX 32 bit Core duo running snow leopard, the code always runs fine. However on my ubuntu box I get sporadic errors detailed below. I tried replacing the subprocess.call() with subprocess.Popen([shellscriptfile.sh],stdout=open(unique_process_id.log,w),stderr=open(unique_error_log.log,w) But I get the same OSError: [Errno 26] Text file busy error Everytime I run the same job queue a different part of the job fails. Unfortunately I dont see anybody else reporting this OSError. ANy help in troubleshooting my newbie thread code will be greatly appreciated. Thanks hari The orchestrator class is at: https://github.com/harijay/auriga/blob/master/process_multi.py A sample thread subclass is at : https://github.com/harijay/auriga/blob/master/scatomtzrunthread.py Detailed error: Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.6/threading.py, line 532, in __bootstrap_inner self.run() File /home/hari/Dropbox/auriga/scatomtzrunthread.py, line 28, in run stat = subprocess.call([file]) File /usr/lib/python2.6/subprocess.py, line 480, in call return Popen(*popenargs, **kwargs).wait() File /usr/lib/python2.6/subprocess.py, line 633, in __init__ errread, errwrite) File /usr/lib/python2.6/subprocess.py, line 1139, in _execute_child raise child_exception OSError: [Errno 26] Text file busy -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/30/10 12:36 PM, rantingrick wrote: On Dec 30, 9:51 am, Kevin Walzerk...@codebykevin.com wrote: Tcl is not a domain-specific language for creating GUI's. Tcl is a full-featured, general-purpose programming language that is a peer to Python in its capabilities, Anybody can gloat and gush about their favorite programming language however what separates fantasy from reality is evidence of these theories. Or rather, Illusions of grandeur! You can build web servers, database tools, FTP clients, test suite/automation tools, chat clients, and drivers of other CLI tools with Tcl, just to name a few. In terms of what can be done with the language, I'm not aware of anything that can be done in Python that can't be done in Tcl. The size of Python's community and its large standard library are an advantage over Tcl. While Tcl is technically capable of many things, it's often easier to find a Python library already coded for specific functions--for instance, while Tcl has XML parsing and can parse RSS, it doesn't have a rich library like feedparser all wrapped up and ready to go. and surpasses Python in some respects. The only thing that Tcl has over Python is building Tk GUI's. Please post evidence otherwise if you dare! In the meantime i will not be holding my breath. I find that Tcl's everything is a string representation offers a more flexible and expressive approach in certain contexts. Tcl's exec function makes interacting with external tools simpler than os.popen and subprocess--I can get the output of a command with less code. Of course, this is partly a matter of taste. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: OSError: [Errno 26] Text file busy during subprocess.check_call() :seems os dependent
On 12/30/2010 4:46 PM, harijay wrote: OSError: [Errno 26] Text file busy error Searching 'errno 26', the third Google response suggests that you are trying to write to a file (especially an executable or shared library?) that is already in use. Perhaps just trying to read when locked will trigger? -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 1:51 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: How to add two numbers in C: [...snip code example...] None of the three are exactly clones of each other, but it seems to me that Tcl and Python are quite close in spirit, if not syntax. Yes i'll agree to that if you also agree that Python and Perl are the same. Then i maybe your suggestion holds water, maybe. But you forgot to comment on the other big point which is... What language would you rather spend your time learning if you only had C and Tcl to choose from? If you answer Tcl you are either foolish or just trying to win the argument by playing devils advocate, and in that case you're even more foolish! The moral is that C and Python are far more useful to any programmer than Tcl will ever be -- whether you consider them together or apart does not matter. Tcl is too limited whereas Python and especially C are far more useful in various situations. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 4:44 pm, Kevin Walzer k...@codebykevin.com wrote: You can build web servers, database tools, FTP clients, test suite/automation tools, chat clients, and drivers of other CLI tools with Tcl, just to name a few. Ok, thats swell. But do you have any real examples, links, or some evidence of this? Or are we witnessing more wishful thinking? In terms of what can be done with the language, I'm not aware of anything that can be done in Python that can't be done in Tcl. Again the proof is in the pudding my friend! The size of Python's community and its large standard library are an advantage over Tcl. Yes, go on... While Tcl is technically capable of many things, it's often easier to find a Python library already coded for specific functions--for instance, while Tcl has XML parsing and can parse RSS, it doesn't have a rich library like feedparser all wrapped up and ready to go. Thanks, well i must say that it it getting easier to win this argument. I find that Tcl's everything is a string representation offers a more flexible and expressive approach in certain contexts. Maybe but that is hardly going to woo the masses is it? Tcl's exec function makes interacting with external tools simpler than os.popen and subprocess--I can get the output of a command with less code. Newsflash!, NewsFlash!, Python has an exec function. Am i missing something here? :) Of course, this is partly a matter of taste. Well your posts so far are leaning heavily that way Kevin :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Building sys.path at run-time?
On Dec 30, 4:24 am, Roy Smith r...@panix.com wrote: In article 87k4irhpoa@benfinney.id.au, Ben Finney ben+pyt...@benfinney.id.au wrote: Roy Smith r...@panix.com writes: I've got a problem that I'm sure many people have solved many times. Our project has a bunch of python scripts A very common problem. The solution is to switch to Perl. (Merry solstice silliness, everyone :-) I have another problem. I hit the Post button by accident. Please ignore. Sorry all, festive joy and all that. +1 for a laugh that your problem is [a] bunch of python scripts, and another +1 'cos I have another problem... Damn it, if this was 10-15 years ago, with bash.org/qdb.us etc..., I'd have posted that... Thanks Roy for the laugh, Jon. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
rantingrick schrieb: On Dec 29, 6:41 pm, Gerry Reno gr...@verizon.net wrote: wxPython looks good but I don't see anyone developing support for things like smartphones. No wx is not the answer to our problems Rather: ... to *your* problem... Also, what do you think about frameworks such as pyjamas? It lets you write in python and compiles everything down to Javascript so it can be used across the Web as well as on the desktop. Hmm, this is like two double edged swords smashing one another in battle. Sword One: On one hand web frameworks are going to be really big soon -- however legacy GUI's are not going away any time soon! There are enough out there in the wild, they will last quite for awhile indeed; but it's time for them to die. Sword Two: On the other hand web frameworks provide awesome cross platform ability that is surly only going to get better as time goes -- however i utterly hate JavaScript (although much worse web languages exist!). And sending requests back and forth between Python, JavaScript, Apparently the authors do know that, too: MessageID:mailman.1298.1290672551.2218.python-l...@python.org, *sigh* no svg. BTW: Look in comp.lang.javascript: javascript is framework/toolkit resistent. and BrowserX is also a real PITA. Because even though everyone knows this is coming all the major browsers are trying to insert their API into the mix. So that Joe Scripter has to write code that is compatible between many browsers. Until the world agrees on a unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of drunken sailors at the helm. svg: opera, chrome, safari(including ios), ie9, firefox. Although svg is missing under webkit/android --Apple kept the hardware accelerated part to themeselves. Goolge is currently implementing hardware acceleration for svg in chrome/webkit, likewise Microsoft/ie. Lets wait and see when svg becomes available in android, too. Although smil is quiet another subject. I believe pyjamas has a bright future in the web playground, however we still need to focus our community efforts towards a Python based GUI. I can see a pythonGUI and pyjamas existing side by side in mutual harmony for many years. pyjamas: Perhaps without javascript. -roger -- http://mail.python.org/mailman/listinfo/python-list
Re: OSError: [Errno 26] Text file busy during subprocess.check_call() :seems os dependent
I am writing to a unique script file . Each script file has prefixes like script1.sh script2.sh and they reside in different directories . The scripts will never trample each other since they are all sequential and shell scripts and no directory will have more than one shell script. The only thing I am doing is dir1 and dir2 will each have a script1.sh . But that still makes it mutually exclusive paths. Hari On Dec 30, 5:34 pm, Thomas L. Shinnick tshin...@io.com wrote: At 03:46 PM 12/30/2010, harijay wrote: Hi, I am writing some multithreaded code which aims to automate three sequential data processing applications and distribute the processing on my 16GB RAM, 64 bit Ubuntu box running Python 2.6.5 The basic class that orchestrates these jobs use Queue.Queue() to feed the product of the first job into the Queue for the next job. Each Thread receives a dynamically generated shell script from some classes I wrote and then runs the script using subprocess.call([shell_script_file.sh]) You say dynamically generated. Any chance you are (re)using the same filename each time? Is it possible that two uses of that filename could occur at the same time? That is, is it possible that at the same time while one process is running from the script file, another process is trying to re-write the script file? And so maybe you need to have dynamically generated and unique filenames Most often I see references to binary executable files for the error message, but I've also seen references to script files, e.g. http://www.cyberciti.biz/faq/binbash-bad-interpreter-text-file-busy/ I tested the code on a mac laptop and also on ubuntu. Curiously on Mac OSX 32 bit Core duo running snow leopard, the code always runs fine. However on my ubuntu box I get sporadic errors detailed below. I tried replacing the subprocess.call() with subprocess.Popen([shellscriptfile.sh],stdout=open(unique_process_id.log ,w),stderr=open(unique_error_log.log,w) But I get the same OSError: [Errno 26] Text file busy error Everytime I run the same job queue a different part of the job fails. Unfortunately I dont see anybody else reporting this OSError. ANy help in troubleshooting my newbie thread code will be greatly appreciated. Thanks hari The orchestrator class is at: https://github.com/harijay/auriga/blob/master/process_multi.py A sample thread subclass is at : https://github.com/harijay/auriga/blob/master/scatomtzrunthread.py Detailed error: Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.6/threading.py, line 532, in __bootstrap_inner self.run() File /home/hari/Dropbox/auriga/scatomtzrunthread.py, line 28, in run stat = subprocess.call([file]) File /usr/lib/python2.6/subprocess.py, line 480, in call return Popen(*popenargs, **kwargs).wait() File /usr/lib/python2.6/subprocess.py, line 633, in __init__ errread, errwrite) File /usr/lib/python2.6/subprocess.py, line 1139, in _execute_child raise child_exception OSError: [Errno 26] Text file busy -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/30/10 6:17 PM, rantingrick wrote: Ok, thats swell. But do you have any real examples, links, or some evidence of this? Or are we witnessing more wishful thinking? http://tcl.apache.org/rivet/ http://www.amsn-project.net/ http://thecoccinella.org/ http://personal5.iddeo.es/andresgarci/tclcurl/english/ http://openacs.org/ http://www.aolserver.com/ http://www.macports.org/ http://www.nist.gov/el/msid/expect.cfm http://www.simulistics.com/ http://personal5.iddeo.es/andresgarci/getleft/english/ http://model.com/ http://sqlitestudio.one.pl/index.rvt http://www.speech.kth.se/wavesurfer/ http://www.ellogon.org/ http://moodss.sourceforge.net/ http://www.projectforum.com/ http://www.eggheads.org/ http://brlcad.org/ http://www.muonics.com/ -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2010-12-30 13:04:19 -0500, rantingrick said: On Dec 30, 10:02 am, Kevin Walzer k...@codebykevin.com wrote: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ This library isn't much different from other Python GUI toolkits--it's dependent on underlying, rather large, platform-specific implementations--but it provides an even higher level of abstraction. On the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11, pygtk. In short, it's a wrapper over other wrappers. hmm. And what is Tkinter exactly? And more importantly how is it better than pyGUI (design wise)? And even more importanly, how will it be better in the long run? Is this just more FUD Kevin Gates? I am sorry, are you always an inconsiderate idiot? That is exactly what you are coming across as. -- Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2010-12-30 11:02:46 -0500, rantingrick said: On Dec 30, 9:52 am, Stefan Behnel stefan...@behnel.de wrote: I hope you invested as much time into writing this expose as you did searching the web before writing it. And ditto to you. If you would have followed the thread so far, in my second post i said... However i need to stress that my intention is towards a 100% Python GUI. Not a binding, not a wrapping (except for OS calls!) but a *real* Python GUI. The only thing that i know of at this point is pyGUI although there are probably others.[198:203] Good luck with that. -- Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2010-12-30 18:12:21 -0500, rantingrick said: On Dec 30, 1:51 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: How to add two numbers in C: [...snip code example...] None of the three are exactly clones of each other, but it seems to me that Tcl and Python are quite close in spirit, if not syntax. Yes i'll agree to that if you also agree that Python and Perl are the same. Then i maybe your suggestion holds water, maybe. But you forgot to comment on the other big point which is... What language would you rather spend your time learning if you only had C and Tcl to choose from? If you answer Tcl you are either foolish or just trying to win the argument by playing devils advocate, and in that case you're even more foolish! The moral is that C and Python are far more useful to any programmer than Tcl will ever be -- whether you consider them together or apart does not matter. Tcl is too limited whereas Python and especially C are far more useful in various situations. I'll bite. Exactly how is Tcl too limited in your view? -- Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 6:32 pm, Robert sigz...@gmail.com wrote: Exactly how is Tcl too limited in your view? Well Robert if have explain to you why C and Python make Tcl look limited by comparison then explaining will probably do neither of us any good. But if you think Tcl is so great by all means go spend the next couple of years writing legacy code until you realize one day it was all for nothing. But let's get back on topic here shall we. I have some questions specifically for you Robert... 1. Have you ever used Tkinter? 2. If so, explain what you created with it in detail? 3. What is your opinion of Tkinter as to it's usefulness within the stdlib? 4. How long should we keep Tkinter in the stdlib? 5. Should Python even have a GUI in the stdlib? 6. If Python should have a GUI, then what traits would serve our community best? I will be really surprised if you answer any of these questions. And sorry, but i did not have time to spec out a multiple choice QA for you. So take your time Robert. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: using python ftp
Hello Matt, On 2010-12-23 01:03, Matt Funk wrote: i was wondering whether someone can point me whether the following already exists. I want to connect to a server , download various files (for whose name i want to be able to use a wildcard), and store those files in a given location on the hard drive. If the file already exists i do not want to download it. [...] You might want to check out ftputil: http://ftputil.sschwarzer.net/ http://ftputil.sschwarzer.net/trac/wiki/Documentation Otherwise i was going to do it by hand using ftplib: 1) connect to server, 2) change to directory on server 3) get listing 4) match the file pattern i want to the listing 5) check if file already exists 6) download file if matched and doesn't exist Can anyone offer any advice whether this already done somewhere? ftputil will do most of these tasks easily. For step 4 you probably want to use Python's fnmatch module, see http://docs.python.org/library/fnmatch.html . If you have questions on ftputil, there's also a mailing list: http://ftputil.sschwarzer.net/trac/wiki/MailingList (You need to be subscribed to the list to post, though.) Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Catching user switching and getting current active user from root on linux
In article ff3a2b89-2586-43d2-ae5a-490384687...@32g2000yqz.googlegroups.com, mpnordland mpnordl...@gmail.com wrote: First, to pacify those who hate google groups: What is a good usenet client? trn3.6 ;-) -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Think of it as evolution in action. --Tony Rand -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
For those that are lurking, this might provide a little background: http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong Essentially, there is nothing wrong with Tcl and Tkinter. They are part of a long evolutionary chain of how we got to where we are today. They deserve to be respected for the contributions that they have made. The question now is whether Python needs to evolve its own GUI toolset. Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Thu, Dec 30, 2010 at 12:15 AM, rantingrick rantingr...@gmail.com wrote: However i need to stress that my intention is towards a 100% Python GUI. Not a binding, not a wrapping (except for OS calls!) but a *real* Python GUI. The only thing that i know of at this point is pyGUI although there are probably others. Allowing the average Python programmer the ability to read OS specific calls written in Python would not only benefit their GUI knowledge, but also there knowledge of OS's in general. It's very hard to write a good gui framework, very very few people have managed to do it well. Microsoft, Sun and Google have all had the resources to hire very good developers and designers to dedicate to the task and still haven't managed to do it well. There's not the expertise or the investment in the Python community to build a strong Python GUI solution. From an educational viewpoint I see that there could be value in having a pure Python solution, but in terms of having a GUI solution that people will actually want to use in their apps, I'm dubious that it's achievable. Katie -- CoderStack http://www.coderstack.co.uk/perl-jobs The Software Developer Job Board -- http://mail.python.org/mailman/listinfo/python-list
Management careers.
Big chance in Management careers. Careers recruitment in Management work. http://topcareer.webs.com/executivemanager.htm http://topcareer.webs.com/executivemanager.htm Government Jobs in site lot of opportunities for graduates. http://rojgars1.webs.com/gov.htm http://printmediajobs.webs.com/fl.htm -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2010-12-30 19:43:21 -0500, Gerry Reno said: For those that are lurking, this might provide a little background: http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong Essentially, there is nothing wrong with Tcl and Tkinter. They are part of a long evolutionary chain of how we got to where we are today. They deserve to be respected for the contributions that they have made. The question now is whether Python needs to evolve its own GUI toolset. Regards, Gerry You mean outside of wxPython or PySide/PyQt? I don't see the need really. -- Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2010-12-30 19:46:24 -0500, rantingrick said: On Dec 30, 6:32 pm, Robert sigz...@gmail.com wrote: Exactly how is Tcl too limited in your view? Well Robert if have explain to you why C and Python make Tcl look limited by comparison then explaining will probably do neither of us any good. But if you think Tcl is so great by all means go spend the next couple of years writing legacy code until you realize one day it was all for nothing. You make a big assumption. That I program in Tcl. I do not. I am simply curious why you are being such a non-gentleman. If I was going to program in Tcl, I would use Gnocl (a GTk binding) and not Tk. Tcl and C will get anyone just as far as Python and C or you suck as a programmer. Just to clarify...I like Python. I am learning it at the moment. But let's get back on topic here shall we. I have some questions specifically for you Robert... 1. Have you ever used Tkinter? Yes...nothing big though. 2. If so, explain what you created with it in detail? Simple utilities is all. Simple meaning ~500-1000 LOC. I have done a few of those just to scratch an itch. 3. What is your opinion of Tkinter as to it's usefulness within the stdlib? No, I really don't see the need for it to be in the stdlib but that isn't my call. I am not a huge fan of Tk as it is. 4. How long should we keep Tkinter in the stdlib? See the last answer. I would yank it. 5. Should Python even have a GUI in the stdlib? I would say no but that is my opinion only and it doesn't matter. Python's domain isn't GUI programming so having it readily available on the sidelines would be fine for me. 6. If Python should have a GUI, then what traits would serve our community best? This is a good one. It should be: - cross platform - Pythonic - as native as possible Cross platform and native are hard. Just look at all the work with PyQt/PySide and wxPython. It took them years to get where they are. I will be really surprised if you answer any of these questions. And sorry, but i did not have time to spec out a multiple choice QA for you. So take your time Robert. :) Hey, there you go. At least I have real answers. :-) -- Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: OSError: [Errno 26] Text file busy during subprocess.check_call() :seems os dependent
On Thu, 30 Dec 2010 13:46:35 -0800, harijay wrote: [...] But I get the same OSError: [Errno 26] Text file busy error Everytime I run the same job queue a different part of the job fails. Unfortunately I dont see anybody else reporting this OSError. ANy help in troubleshooting my newbie thread code will be greatly appreciated. Try catching the OSError exception and inspecting the filename attribute. Something like this might help: # Untested def report_error(type, value, traceback): if type is OSError: print value.filename sys.__excepthook__(type, value, traceback) sys.excepthook = report_error -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 6:43 pm, Gerry Reno gr...@verizon.net wrote: For those that are lurking, this might provide a little background: http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong That was a great and thought provoking article Gerry. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Career in IT and management
Latest job listing with IT manager job search and government jobs http://topcareer.webs.com/itmanagement.htm Are you looking for a job in government, this is the right place to start. http://rojgars1.webs.com/gov.htm http://printmediajobs.webs.com/fl.htm -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 7:54 pm, Katie T ka...@coderstack.co.uk wrote: It's very hard to write a good gui framework, very very few people have managed to do it well. This is a very good point Katie. Creating a Python GUI is a huge undertaking and it will take much time to work out the bugs. A truly Pythonic GUI may be (i must admit) a pipe dream at this time. However i know that unless we start thinking about something new right now, it will be two, three, ten years down the road and we will be in the same situation. A lot of folks are probably thinking that since Python3000 is here that Python is up to current technology but i must differ with that opinion. Yes Python3 is much better than the 2.x line however Tkinter and IDLE are so dated and antique that Py3000 is a bit lackluster. Look, when Guido breathed life into Tkinter many years ago he did so with good intentions. I believe at that time (and for a while after) Tkinter was an asset to this community. However, now Tkinter just looks old and dumpy. Actually i would't mind keeping Tkinter and just tweaking it a bit but that is impossible! There will always be a glass ceiling between us and Tcl. We are confined from the Tcl folks and there is nothing we can do about. Tkinter has had a decade to become more relevant in the 21st century however the Tcl folks have failed to deliver. We cannot keep depending on outsiders, we must start the transition to something better. There's not the expertise or the investment in the Python community to build a strong Python GUI solution. From an educational viewpoint I see that there could be value in having a pure Python solution, but in terms of having a GUI solution that people will actually want to use in their apps, I'm dubious that it's achievable. Also a good point Katie. But i think i have just a little more optimism than you :). I will conceded that if we cannot build a truly Pythonic GUI then we must at least pick a GUI that is up to date with Python3000. A good choice might be a limited version of wxPython in the stdlib and a 3rd party extension module available for download. We can use Tkinter as the template. All you need in the stdlib are the same widgets that are in Tkinter now. However unlike Tkinter, now a rich 3rd party module will be available. By doing this we will have removed the glass ceiling, and we did not have to re-invent the wheel to do it. What is your opinion (or anyone) on wxPython? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 8:41 pm, Robert sigz...@gmail.com wrote: On 2010-12-30 19:46:24 -0500, rantingrick said: Just to clarify...I like Python. I am learning it at the moment. Glad to have you aboard Robert! 3. What is your opinion of Tkinter as to it's usefulness within the stdlib? No, I really don't see the need for it to be in the stdlib but that isn't my call. But it is your call Robert. Anyone who writes Python code --whether they be a beginner with no prior programming experience or a fire breathing Python Guru-- has a right to inject their opinion into th community. We really need input from first time users as they carry the very perspective that we have completely lost! 5. Should Python even have a GUI in the stdlib? I would say no but that is my opinion only and it doesn't matter. Python's domain isn't GUI programming so having it readily available on the sidelines would be fine for me. I agree that Python's domain is not specifically GUI programming however to understand why Tkinter and IDLE exists you need to understand what Guido's dream was in the beginning. GvR wanted to bring Programming to everyone (just one of his many heroic goals!). He believed (i think) that GUI programming is very important , and that was 20 years ago!!. So he included Tkinter mainly so new Python programmers could hack away at GUI's with little or no effort. He also created a wonderful IDE for beginners called IDLE. His idea was perfect, however his faith in TclTk was flawed and so we find ourselves in the current situation we have today. With the decay of Tkinter the dream has faded. However we can revive this dream and truly bring Python into the 21st century! 6. If Python should have a GUI, then what traits would serve our community best? This is a good one. It should be: - cross platform - Pythonic - as native as possible Cross platform and native are hard. Just look at all the work with PyQt/PySide and wxPython. It took them years to get where they are. Hmm, wxPython is starting to look like the answer to all our problems. WxPython already has an IDE so there is no need to rewrite IDLE completely. What do we have to loose by integrating wx into the stdlib, really? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/30/2010 10:28 PM, rantingrick wrote: Hmm, wxPython is starting to look like the answer to all our problems. WxPython already has an IDE so there is no need to rewrite IDLE completely. What do we have to loose by integrating wx into the stdlib, really? In the spirit of batteries included, Python needs to have something in the stdlib as far as gui. But it cannot be overwhelming. The problem with wx is that it is BIG. And so if we want something like wx to be in the stdlib then it would have to be refactored so that there was a small basic wx that was part of stdlib and then import wx-the-whole-enchilada if you need heavy gui artillery. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2010-12-30 22:06:57 -0500, rantingrick said: What is your opinion (or anyone) on wxPython? Ok, I am curious again. Have you even tried wxPython or PySide/PyQt? -- Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2010-12-30 22:44:52 -0500, Gerry Reno said: On 12/30/2010 10:28 PM, rantingrick wrote: Hmm, wxPython is starting to look like the answer to all our problems. WxPython already has an IDE so there is no need to rewrite IDLE completely. What do we have to loose by integrating wx into the stdlib, really? In the spirit of batteries included, Python needs to have something in the stdlib as far as gui. But it cannot be overwhelming. The problem with wx is that it is BIG. And so if we want something like wx to be in the stdlib then it would have to be refactored so that there was a small basic wx that was part of stdlib and then import wx-the-whole-enchilada if you need heavy gui artillery. It's BIG. The question really is, do we need a GUI toolkit in the stdlib. I would say no. In wxPython's case it is a no-brainer to install (even as a second package). I am not sure if PySide is that easy but it could be. -- Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 2010-12-30 22:28:39 -0500, rantingrick said: On Dec 30, 8:41 pm, Robert sigz...@gmail.com wrote: On 2010-12-30 19:46:24 -0500, rantingrick said: Just to clarify...I like Python. I am learning it at the moment. Glad to have you aboard Robert! Thanks! 3. What is your opinion of Tkinter as to it's usefulness within the stdlib? No, I really don't see the need for it to be in the stdlib but that isn't my call. But it is your call Robert. Anyone who writes Python code --whether they be a beginner with no prior programming experience or a fire breathing Python Guru-- has a right to inject their opinion into th community. We really need input from first time users as they carry the very perspective that we have completely lost! I speak up. :-) 5. Should Python even have a GUI in the stdlib? I would say no but that is my opinion only and it doesn't matter. Python's domain isn't GUI programming so having it readily available on the sidelines would be fine for me. I agree that Python's domain is not specifically GUI programming however to understand why Tkinter and IDLE exists you need to understand what Guido's dream was in the beginning. GvR wanted to bring Programming to everyone (just one of his many heroic goals!). He believed (i think) that GUI programming is very important , and that was 20 years ago!!. So he included Tkinter mainly so new Python programmers could hack away at GUI's with little or no effort. He also created a wonderful IDE for beginners called IDLE. His idea was perfect, however his faith in TclTk was flawed and so we find ourselves in the current situation we have today. With the decay of Tkinter the dream has faded. However we can revive this dream and truly bring Python into the 21st century! I don't think Tkinter was in there for large programming. Tkinter is crufty and probably should be moved out. For whipping up quick gui things to scratch an itch it is good. I lurk more on the Tcl side of things. When the mention of separating Tcl and Tk development, I fall on the side of separating them. Tcl, like Python should stand on its own. Widget frameworks are extras to me. One way the Tcl community has stagnated has been its insistence on Tk. There was a wxTcl project...it died. That would have been good for the Tcl community. Luckily there is a GTk framework (Gnocl) that is really good. But it still doesn't get the props that it deserves. The second way the Tcl community irks me is the not invented here attitude. I like the syntax of Tcl and I like the community. They are some good folks. Try asking I want to build a Nagios clone in Tcl type question and invariably you get Why? There is already Nagios?. That stems from the glue language roots I think but to me that is the wrong attitude. You want people to take a look at a language (any language), you build stuff with it that people want to use. Ruby would not be as big as it is if Rails hadn't come along. Nuff of that... ;-) 6. If Python should have a GUI, then what traits would serve our community best? This is a good one. It should be: - cross platform - Pythonic - as native as possible Cross platform and native are hard. Just look at all the work with PyQt/PySide and wxPython. It took them years to get where they are. Hmm, wxPython is starting to look like the answer to all our problems. WxPython already has an IDE so there is no need to rewrite IDLE completely. What do we have to loose by integrating wx into the stdlib, really? wxPython is really good. The downside is that is shows (or did show) its C++ roots. Nokia is making a run with PySide (their version of the PyQt framework) and since it has a company behind it might go pretty far. Qt can be used for a lot of problem domains. Anyway, I wasn't meaning to be rough with you. Just trying to figure out where you were coming from. I am acquianted with Kevin Walzer and he is a good guy. -- Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Thu, 30 Dec 2010 23:04:33 -0500, Robert wrote: The second way the Tcl community irks me is the not invented here attitude. I like the syntax of Tcl and I like the community. They are some good folks. Try asking I want to build a Nagios clone in Tcl type question and invariably you get Why? There is already Nagios?. You're the one who wants to re-write Nagios in Tcl, the Tcl community are perfectly happy using the existing Nagios instead of re-inventing the wheel, and you accuse *them* of suffering from NIH syndrome. Oh the irony. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 9:44 pm, Gerry Reno gr...@verizon.net wrote: In the spirit of batteries included, Python needs to have something in the stdlib as far as gui. But it cannot be overwhelming. Agreed! The problem with wx is that it is BIG. And so if we want something like wx to be in the stdlib then it would have to be refactored so that there was a small basic wx that was part of stdlib and then import wx-the-whole-enchilada if you need heavy gui artillery. Exactly! All we need to do is replace the existing Tkinter with a small sub-set of wxPython widgets that mirrors exactly what we have now... Toplevel Label Entry Button Radiobutton Checkbutton Canvas Textbox Listbox Menu Scale Scrollbar ...thats all you need in the std library widget wise. The rest of what makes up wx can exist in the wxPython Extension Library. Python needs this change! We have already made incompatible changes so now is the time to start seriously brainstorming on how we can integrate the beauty, elegance, and feature rich power of wxPython. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 9:51 pm, Robert sigz...@gmail.com wrote: Ok, I am curious again. Have you even tried wxPython or PySide/PyQt? Yes i have used wxPython on a few projects and was very happy with the feature rich nature of it. I found previously (with Tkinter) i would have to build my own compound widgets due to non-existence or just plain poor design. That was not the case in wx as it has more eye candy than i could ever put to good use ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 11:24 pm, rantingrick rantingr...@gmail.com wrote: The problem with wx is that it is BIG. And so if we want something like wx to be in the stdlib then it would have to be refactored so that there was a small basic wx that was part of stdlib and then import wx-the-whole-enchilada if you need heavy gui artillery. Exactly! All we need to do is replace the existing Tkinter with a small sub-set of wxPython widgets that mirrors exactly what we have now... Toplevel Label Entry Button Radiobutton Checkbutton Canvas Textbox Listbox Menu Scale Scrollbar ...thats all you need in the std library widget wise. The rest of what makes up wx can exist in the wxPython Extension Library. Python needs this change! We have already made incompatible changes so now is the time to start seriously brainstorming on how we can integrate the beauty, elegance, and feature rich power of wxPython. I have never, ever, made a GUI that consistent only of those options excep when following a tutorial, sorry. While I won't claim to stand for anyone else, I'm hardly alone, judging by /every application running on my desktop right now/. Well, maybe notepad. Interesting applications require interesting features. Anything you end up writing is going to be at least as complicated as TkInter for the standard library, if not vastly more so, and have all of the same faults you find in TkInter. This would be because such problems are fundamentally inescapable, a simple fact of reality you have yet to even grasp, AFAICT, much yet acknowledge. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 10:04 pm, Robert sigz...@gmail.com wrote: wxPython is really good. The downside is that is shows (or did show) its C++ roots. Well i will admit the api is not as simplistic as Tkinter. However i noticed over time that wx had started adopting a slight Tkinter feel to the API and that is a good thing. So they are coming around. :) Anyway, I wasn't meaning to be rough with you. Just trying to figure out where you were coming from. I am acquianted with Kevin Walzer and he is a good guy. No harm done Robert my skin is far thicker than your average grape. We just ended up on opposite sides of a passionate argument. I hope you stick around with us because I look forward to hearing more of your opinions and ideas. And i agree that Kevin is a great guy! I've never met him but i can tell from his writing style and mannerisms that he is truly an honest and virtuous soul. And i totally understand why he wants to keep Tkinter alive as he and i both have tons of code that depends on Tkinter. I wish we could keep Tkinter forever as it really is a great starter GUI. I wrote my first GUI code with it and fell in love just like with Python! However i know we will always be lacking our full potential with Tkinter as developers and as a community. Sadly i see no other way but to replace it with something more up-to-date. Sometimes we have to take one for the team. What is in our best interest may not necessarily be in the community's best interest. If we *do* replace Tkinter, it will be a very painful adjustment because it has been with us for such a long time. However, just as Py3000 was painful at first, and then started slowly gaining speed into a much better language, i also believe this change will move us forward into an even greater language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 30, 10:41 pm, Adam Skutt ask...@gmail.com wrote: On Dec 30, 11:24 pm, rantingrick rantingr...@gmail.com wrote: Exactly! All we need to do is replace the existing Tkinter with a small sub-set of wxPython widgets that mirrors exactly what we have now... Toplevel Label Entry Button Radiobutton Checkbutton Canvas Textbox Listbox Menu Scale Scrollbar I have never, ever, made a GUI that consistent only of those options excep when following a tutorial, sorry. While I won't claim to stand for anyone else, I'm hardly alone, judging by /every application running on my desktop right now/. Well, maybe notepad. Of course a tiny widget set like this is not going to handle extensive GUI coding, thats a no brainer. But currently that is EXACTLY what we have to work with in the stdlib. Sure you have TIX and a few other extensions but they will never compare to the vast features of wxPython. Have you even aquinted yourself with wxPython Adam? What i (and others) are proposing is to replace the existing Tkinter library with a matching wxPython libray. Then allocate the remaining wxPython library (which is ginormous btw!) into a 3rd party module available for download. My argument is that because wxPython is s feature rich. We will break the glass ceiling that exist now with Tkinter. Interesting applications require interesting features. Anything you end up writing is going to be at least as complicated as TkInter for the standard library, if not vastly more so, Agreed! We need at least the same capability that Tkinter offers in the stdlib. Why would we sacrifice? and have all of the same faults you find in TkInter. Thats not true. Yes all projects have faults of some kind. I am not suggesting that wxPython is some sort of miracle library. However anyone of average intelligence can do a side by side comparison and agree that wx is far superior to TclTk in many, many ways. If you have a valid argument as to how Tkinter is better feel free to share this information with us. This would be because such problems are fundamentally inescapable, a simple fact of reality you have yet to even grasp, AFAICT, much yet acknowledge. Adam, Adam. I feel you are desperately trying to inject negative energy into what is now the very beginnings of a healthy and positive community discussion on the future of Python's GUI library. If you do care about Python's future then you should get involved with this discussion in a positive way. You can disagree with me and still be positive. I wish you would spend more energy bringing forth your own ideas and thoughtful discussion instead of resorting to these wasteful and vengeful tactics. So with that in mind i ask you some direct questions... 1. Do you use Tkinter yourself? 2. Explain some of the applications you have created with Tkinter. 3. How do you feel about Tkinter being in the stdlib? 4. Should Python even include a GUI library? 5. If so, what traits should this library encompass? 6. If you could choose what library do you think would be in the communities best interest? -- http://mail.python.org/mailman/listinfo/python-list
Re: OSError: [Errno 26] Text file busy during subprocess.check_call() :seems os dependent
On Thu, 30 Dec 2010 13:46:35 -0800, harijay wrote: Each Thread receives a dynamically generated shell script from some classes I wrote and then runs the script using subprocess.call([shell_script_file.sh]) But I get the same OSError: [Errno 26] Text file busy error Text file busy aka ETXTBSY occurs if you try to execute a file which is open for write by any process. Be sure to explicitly close() the script before attempting to execute it. Don't rely upon the destructor closing it, as that may be deferred. Also, if you spawn any child processes, ensure that they don't inherit the descriptor being used to write to the script. Ideally, you should set the close-on-exec flag on the descriptor as soon as the file is opened. Using close_fds=True in subprocess.Popen() will solve the issue for processes spawned that way, but you also need to consider subprocesses which may be spawned behind the scenes by library functions. -- http://mail.python.org/mailman/listinfo/python-list
Change in scope of handled exception variable in Python 3?
Hi, I stumbled on a small bug with httplib2 that I reduced to the example below. It seems that with Python 3, when an exception is handled it unbound the previously declared local variable. This did not occurs with Python 2.5. It is a Python 3 feature? I did not find anything in the what's news, but it's hard to search... (notes: I'm using Python 3.1.2) --- def main(): msg = 'a message' try: raise ValueError( 'An error' ) except ValueError as msg: pass return msg main() python localmask.py Traceback (most recent call last): File localmask.py, line 12, in module main() File localmask.py, line 10, in main return msg UnboundLocalError: local variable 'msg' referenced before assignment --- -- http://mail.python.org/mailman/listinfo/python-list
Python3 Web Framework
Hey all... I just started with Python, and I chose Python3 because it seemed a subtle choice as compared to doing Pthon 2.x now and then porting to Python3.x later... I plan to start with Web Development soon... I wanted to know what all web frameworks are available for Python3... I heard the Django is still not compatible with 3.x... Any idea guys? -- http://mail.python.org/mailman/listinfo/python-list
Put up or shut up (Was Re: Tkinter: The good, the bad, and the ugly!)
On 2010-12-30 12:36:05 -0500, rantingrick said: On Dec 30, 9:51 am, Kevin Walzer k...@codebykevin.com wrote: Tcl is not a domain-specific language for creating GUI's. Tcl is a full-featured, general-purpose programming language that is a peer to Python in its capabilities, Anybody can gloat and gush about their favorite programming language however what separates fantasy from reality is evidence of these theories. Or rather, Illusions of grandeur! One: it's delusions of grandeur. and surpasses Python in some respects. The only thing that Tcl has over Python is building Tk GUI's. Please post evidence otherwise if you dare! In the meantime i will not be holding my breath. Two: were you raised in a barn? How the hell did you get so up on yourself that you think this is an okay way to respond to a perfectly civil post? Abusing people's opinions and soldiering around demanding everyone justify themselves to you is a great way to get people to ignore whatever point you were trying to make. From your other posts, I gather that you have a very clear idea of what your ideal Python GUI framework would look like. That puts you in the best possible position to implement it. If you're successful, share it around; if it's good, it will gain traction on its own merit. You're not earning any traction on rhetorical grounds here. -o -- http://mail.python.org/mailman/listinfo/python-list
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Martin v. Löwis mar...@v.loewis.de added the comment: Actually, it looks like PEP 3131 and the Language Reference [1] still disagree. The latter says: identifier ::= id_start id_continue* which should probably be identifier ::= xid_start xid_continue* instead. Interesting. XID_* is being used in the PEP since r57023, whereas the documentation was added in r57824. In any case, this is now fixed in r87575/r87576. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Georg Brandl ge...@python.org added the comment: Hearty +1. I have the hope of putting this in 3.3, and for that I'd like to see how the code matures, which is much easier when in version control. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3232] Wrong str-bytes conversion in Lib/encodings/idna.py
Antoine Pitrou pit...@free.fr added the comment: Arguably, it is not a bug if codec's decode method rejects unicode strings with a TypeError. Agreed, but it would be better if it did so deliberately and explicitly, rather than as a result of a bogus forward-port ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Georg Brandl ge...@python.org added the comment: I think the proposal is that fixing this minefield can wait until Python 3.3 (or even 3.4, or later). That is what I was thinking. (Alex: You might not know that Martin was the main proponent of non-ASCII identifiers, so this assessment should have some weight.) I'm thinking about an approach of a variable representation: one, two, or four bytes, depending on the widest character that appears in the string. I think it can be arranged to make this mostly backwards-compatible with existing APIs, so it doesn't need to wait for py4k, IMO. OTOH, I'm not sure I'll make it for 3.3. That is an interesting idea. I would be interested in helping out when you'll implement it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10794] Infinite recursion while garbage collecting loops indefinitely
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Normally you should never call __del__, OTOH the issue is the same with a class like:: class A: def close(self): self.close() def __del__(self): self.close() The problem is not with _infinite_ recursion, though; a depth of 47 is enough (but 46 won't show the problem):: class A: def __del__(self): self.recurse(47) def recurse(self, n): if n: self.recurse(n-1) else: raise ValueError Hint: PyTrash_UNWIND_LEVEL is defined to 50; I checked that recompiling Python with a different value also changes the necessary recursion depth. There is some nasty interaction between the Trashcan mechanism and resurrected objects stored in deep structures. A list is enough, no need to involve frames and exceptions:: class C: def __del__(self): print ., x = self for i in range(49):# PyTrash_UNWIND_LEVEL-1 x = [x] l = [C()] del l -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10794] Infinite recursion while garbage collecting loops indefinitely
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Precision: with new-styles classes (or py3k) the limit is PyTrash_UNWIND_LEVEL-2. This does not change anything to the problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10796] readline completion flaw
New submission from rheise ralfhe...@freenet.de:
Python's readline library generates out of the choices provided by a custom
completion function the wrong terminal input. Say, the completion function
suggests 'foobar' and 'foobaz' as matching completion strings, readline should
produce the characters 'fooba' to prompt and await further interaction by the
user.
This is the intended behaviour of readline and this works in Python as well.
However this does nod work anymore as soon, as the suggestion
list contains dashes `-' as input argument.
A working as supposed example:
import readline
def complete(text, state):
... if (state == 0):
... return abc
... if (state == 1):
... return ade
... else:
... return None
...
readline.parse_and_bind(Tab: complete)
readline.set_completer(complete)
raw_input()
a
abc ade
a
'a'
remark: I entered a and hit tab. readline produces abc/ade as valid choices,
stopping at the first ambiguous character. Now consider the following example:
import readline
def complete(text, state):
... if (state == 0):
... return a-bc
... if (state == 1):
... return a-de
... else:
... return None
...
readline.parse_and_bind(Tab: complete)
readline.set_completer(complete)
raw_input()
a-a-a-
'a-a-a-'
The intended behaviour is the very same as for the first example. Readline
should produce 'a-' and offer a-bc and a-de as valid choices. Instead it
produces an additional a- for every time I hit tab.
Same for Python3.1:
$ python3.1
Python 3.1.2 (release31-maint, Sep 26 2010, 13:51:01)
[GCC 4.4.5] on linux2
Type help, copyright, credits or license for more information.
import readline
def complete(text, state):
... if (state == 0):
... return a-bc
... if (state == 1):
... return a-de
... else:
... return None
...
readline.parse_and_bind(Tab: complete)
readline.set_completer(complete)
input()
a-a-a-a-a-
'a-a-a-a-a-'
Other programming languages falling back to the GNU C-readline library don't
have this problem. Consider the roughly equivalent example in Perl which works
as expected:
use Term::ReadLine;
sub complete
{
my ($text, $state) = @_;
if ($state == 0)
{
return a-bc;
}
elsif ($state == 1)
{
return a-cd;
}
else
{
return undef;
}
}
my $term = new Term::ReadLine 'sample';
my $attribs = $term-Attribs;
$term-parse_and_bind(Tab: complete);
$attribs-{completion_entry_function} = \complete;
$term-readline();
Running it:
$ perl rl
a-
a-bc a-cd
a-
--
components: Library (Lib)
messages: 124917
nosy: rheise
priority: normal
severity: normal
status: open
title: readline completion flaw
type: behavior
versions: Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10796
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Patrick W. p...@borntolaugh.de added the comment: Nick Coghlan (ncoghlan) at 2010-12-29 08:46 (UTC): No, the context must always be included unless explicitly suppressed. Then there should be some actually working way to suppress it, right? I think the standard behaviour that automatically sets the `__context__` of an exception is fine, especially when thinking about exceptions that get raised inside `except` blocks and are not custom made. However there should be some way to suppress the context in some way. Personally, I would prefer if `raise .. from ..` would set the exception's cause, but would *not* automatically print that cause. But then again, it would be a problem to get the cause afterwards when the program terminated because of that exception. So obviously, in such situations, both the cause and the context of a raised exception cannot be used (because both prints out the full trackback). So we obviously need some new mechanism or syntax to ignore the previous exception. As it seems that the cause has a higher precedence than the context (which is fine as the cause is changeable), using `None` as the cause of an exception would be the best solution in my opinion: try: x / y except ZeroDivisionError as e: raise Exception( 'Invalid value for y' ) from None While it might be difficult as the cause is `None` before and gets set to `None` afterwards, Python is totally able to detect that the value was explicitely set to `None`. Either the raise statement should set some internal flag, or the setter for `__cause__` should just check when it is first written to. If that would be too complicated (although it would be possible and very logically to do it like that), maybe a different syntax would work: try: x / y except ZeroDivisionError as e: raise Exception( 'Invalid value for y' ) instead Something like that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10795] standard library do not use ssl as recommended
Antoine Pitrou pit...@free.fr added the comment: There are open issues for specific modules: #8808 for imaplib, #8809 for smtplib. In 3.2, poplib already has support for SSL contexts, as do ftplib, http.client and nntplib. If I'm missing a module please tell me. -- resolution: - duplicate status: open - closed type: - feature request versions: +Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10786] unittest.TextTextRunner does not respect redirected stderr
Changes by Mark Roddy markro...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file20193/py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10786] unittest.TextTextRunner does not respect redirected stderr
Changes by Mark Roddy markro...@gmail.com: Added file: http://bugs.python.org/file20194/py32.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10786] unittest.TextTextRunner does not respect redirected stderr
Mark Roddy markro...@gmail.com added the comment: All patches change the default value of stream to None in the constructor, and set it to the current to sys.stderr if the argument is None. Unit tests included to check this behavior. Also, the patch against Python 3.1 adds the Test_TextTestRunner test case to the list of tests to be run. Apparently this test case was not being run. -- nosy: +MarkRoddy Added file: http://bugs.python.org/file20195/py31.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10794] Infinite recursion while garbage collecting loops indefinitely
Gregory P. Smith g...@krypto.org added the comment: FWIW, the example pasted in the bug was the smallest one he could come up with. in reality we were never calling .__del__() explicitly. We ran into the problem due to a __del__ method triggering a __getattr__ call and the __getattr__ ending up in infinite recursion because an attribute it accessed internally wasn't defined. That particular bug was fixable by fixing the __getattr__ to not depend on any instance attributes but it is still a problem in Python for the interpreter to get into an infinite loop calling the destructor in that case... -- Added file: http://bugs.python.org/file20196/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10794 ___FWIW, the example pasted in the bug was the smallest one he could come up with.  in reality we were never calling .__del__() explicitly. We ran into the problem due to a __del__ method triggering a __getattr__ call and the __getattr__ ending up in infinite recursion because an attribute it accessed internally wasn#39;t defined.  That particular bug was fixable by fixing the __getattr__ to not depend on any instance attributes but it is still a problem in Python for the interpreter to get into an infinite loop calling the destructor in that case...div br/divdivbr/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10681] PySlice_GetIndices() signature changed
Dave Malcolm dmalc...@redhat.com added the comment: For reference, this seems to affect SWIG, specifically, I'm seeing build failures using: /usr/share/swig/2.0.1/python/pycontainer.swg from swig-2.0.1 See downstream build failure report for znc, which uses swig to generate python 3 bindings: https://bugzilla.redhat.com/show_bug.cgi?id=666429 -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10681 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6632] Include more fullwidth chars in the decimal codec
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I wonder if the issues raised here can be neatly addressed by applying NFKC normalization before string to number conversion. This will convert full-width variants to ASCII and also eliminate digit/decimal differences. For example superscript and subscript variants will be converted to ASCII. Note that NFKC normalization is already applied to identifiers, so its effect should be familiar to users. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6632 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9893] Usefulness of the Misc/Vim/ files?
Éric Araujo mer...@netwok.org added the comment: Alright, let me change my opinion: Let’s replace the Vim files by a README.vim file explaining where to get good helper files (like Misc/README.emacs added in r85927). Then I will learn how to manage my Vim configuration to keep it updated (and adequate for each Python version), and when needed contact the Vim community to request updates. -- stage: - needs patch type: resource usage - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1816] sys.cmd_flags patch
Éric Araujo mer...@netwok.org added the comment: I’ve recently remarked that -i maps to both sys.flags.inspect and sys.flags.interactive. Is this behavior useful? -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: using `None` as the cause of an exception would be the best solution in my opinion: +1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Antoine Pitrou pit...@free.fr added the comment: using `None` as the cause of an exception would be the best solution in my opinion: +1 We are talking about context, not cause. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1284670] Allow to restrict ModuleFinder to get direct dependencies
Éric Araujo mer...@netwok.org added the comment: The depth parameter idea sounds like YAGNI, so let’s stay with a recurse boolean :) -- assignee: - eric.araujo nosy: -BreamoreBoy, misc_from_metz stage: unit test needed - patch review versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1284670 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: The project is now at: https://code.google.com/p/mrab-regex/ Unfortunately it doesn't have the revision history. I don't know why not. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10786] unittest.TextTextRunner does not respect redirected stderr
Michael Foord mich...@voidspace.org.uk added the comment: Committed to py3k in revision 87582. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
