Re: [Python-Dev] Tkinter problem in Python 3
Hi Klaus, Tkinter was renamed as part of the stdlib reorganization (see the PEP 3108 :http://www.python.org/dev/peps/pep-3108/#tkinter-packagefor more details). The 2to3 tool should handle all those changes automatically, by the way. Cheers, Quentin On Sat, Feb 21, 2009 at 11:47 AM, Klaus Müller wrote: > Hi! > I am the lead developer of SimPy (http://simpy.sourceforge.net) . > Currently, I am porting SimPy to Python 3. > > SimPy provides Tk/Tkinter-based GUI and plot facilities. > > I find that "import Tkinter" does not work in Python 3, only "import > tkinter". > > What are the changes for Tkinter under Python 3? > > Thanks for your help! > > Klaus Müller > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/qgallet%40gmail.com > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible bug related with Tkinter ?
While testing the tkFileDialog, I encountered a strange error :
~/dev/trunk$ ./python Lib/lib-tk/tkFileDialog.py
Traceback (most recent call last):
File "Lib/lib-tk/tkFileDialog.py", line 202, in
openfilename=askopenfilename(filetypes=[("all files", "*")])
File "Lib/lib-tk/tkFileDialog.py", line 125, in askopenfilename
return Open(**options).show()
File "/home/quentin/dev/trunk/Lib/lib-tk/tkCommonDialog.py", line 48, in show
s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: expected floating-point number but got "0.0"
Investigating a little, I discovered this is a known issue for some
applications like Pyraf and that the following workaround is effective
: "env LC_NUMERIC=C ./python Lib/lib-tk/tkFileDialog.py".
Looking further, this seems to resolve an atof issue and the fact that
Python assumes a C locale while my Linux box actually uses
fr_FR.UTF-8, but I have a hard time determining if that a Python
issue, a TCL issue or something else.
Has someone already encountered this ?
Quentin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Converting tests to unittest/doctest?
(oops, realized I didn't send it to the list, just to Titus) I remember that it was one of the tasks at the Python Sprint at Google last summer, so I guess this is a good idea (for GHOP, right ?) >From what remains of the spreadsheet used during the Sprint (http://spreadsheets.google.com/ccc?key=pBLWM8elhFAmKbrhhh0ApQA&pli=1), I believe you can add the following tests to your list: test_tokenize test_cProfile test_extcall test_logging test_profile test_thread (and maybe test_pep277 that seems to use both unittest and test.test_support ) HTH, Quentin On Dec 21, 2007 12:05 PM, Titus Brown <[EMAIL PROTECTED]> wrote: > Hi all, > > a bit of grep'ping and personal examination discovered the following > tests in trunk/ that could be converted to unittest or doctests. Any > thoughts, pro or con? > > (I understand from Brett that the goal is to eradicate "old-style" > tests, by which I think he means tests that do not use unittest or > doctest. There are some good reasons to switch to using unittests, not > least of which is that you can use a variety of frameworks (nose, > py.test) to do value-added wrapping and management of such tests.) > > Suggestions for additional things to test or tests to modify, clean up, > or extend and expand are welcome. > > thanks, > --titus > > --- > > test_select > test_contains > test_crypt > test_dbm > test_dummy_threading > test_errno > test_getargs > test_gdbm > test_pep247 > test_strftime > > test_thread > > test_queue > > test_fcntl > > test_format > > test_curses > > test_descr > > test_funcattrs > > test_gdbm > > test_socketserver > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/qgallet%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug Day outcome
Excellent ! When will be the next one ? :-) On Jan 20, 2008 2:14 AM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > Today's bug day was a great success. Experienced people like Georg, > Facundo, and Gregory P. Smith participated, and we also had people who > submitted their first patches, some of which got applied today, too. > Hopefully we'll see those people again. > > As of this writing, 37 issues were closed today, leaving 1300 open. > (I saved a search in Roundup to list the bugs closed today.) > > --amk > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/qgallet%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
On Wed, Feb 20, 2008 at 8:40 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > > What's wrong with the rfe type? Why does it have to be a keyword? > > For one it's the name. Personally I didn't know the meaning of RFE until > I googled it. > I agree, the name is a bit confusing when you're not used to it. Also I find that, by definition, RFE and feature requests are not exactly the same. There's a thin line between a new feature and an enhancement that is supposed to fill a gap/improve things. Should they really be treated the same way ? Quentin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small RFEs and the Bug Tracker
I consider a feature request something like asking a factorial method ( http://bugs.python.org/issue2138). As for the RFE, (from Wikipedia) "while not technically a bug, it is often tracked in the same manner as a bug as it represents a failure to meet expected behavior, or simply out of convenience". But on second thought, I realize I'm really splitting hairs here. It's not worth treating them separately, I'm perfectly fine with the "feature request" type :-) Quentin On Wed, Feb 20, 2008 at 9:36 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I agree, the name is a bit confusing when you're not used to it. > > Renaming it is easy. To the native speakers reading it: What should > it be called? (please try to come up with something shorter than > "request for enhancement") > > > Also I find that, by definition, RFE and feature requests are not > > exactly the same. There's a thin line between a new feature and an > > enhancement that is supposed to fill a gap/improve things. Should they > > really be treated the same way ? > > I don't understand the difference. Can you please explain it? Are there > features that are not enhancements (and if so, why would anybody request > them), or are there enhancements which are not features? Are they > entirely disjoint sets of things? > > Regards, > Martin > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Primer on distributed revision control?
Eric Raymond started a study for this specific matter recently (announced here : http://article.gmane.org/gmane.emacs.devel/85893). Everything is under source control here : http://thyrsus.com/hg/uvc/ HTH, Quentin On Fri, Mar 21, 2008 at 11:17 PM, <[EMAIL PROTECTED]> wrote: > With all these distributed revision control systems now available (bzr, > hg, > darcs, svk, many more), I find I need an introduction to the concepts and > advantages of repository distribution. It seems to me that it has the > potential for leading to anarchy, though I can see how some things would > be > improved (working offline, maintaining local patches). It's not obvious > how > I push changes back upstream. Can someone point me to some useful content > (web pages or books) which will help me wrap my brain around the ideas? > Maybe a compare/contrast of the major players? > > Thanks, > > Skip > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/qgallet%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finishing up PEP 3108
On Thu, May 29, 2008 at 9:12 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > >> The issues related to PEP 3108 now total 14. With the beta >> (supposedly) in a week, I am hoping the last minor details can be >> pulled together or decisions made on what can be postponed and what >> should definitely be considered a release blocker. >> >> Issue 2847 - the aifc module still imports the cl module in 3.0. >> Problem is that the cl module is gone. =) So it seems silly to have >> the imports lying about. This can probably be changed to critical. >> > > It shouldn't be a problem to rip everything cl-related out of aifc. > The question is how useful aifc will be after that ... > Has someone already used that module ? I took a look into it, but I'm a bit confused about the various compression types, case-sensitivity and compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the same encoding ? Can we use the audioop module for ALAW, just like it's already done for ULAW ? [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html Quentin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Finishing up PEP 3108
On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <[EMAIL PROTECTED]> wrote: > > >>Issue 2847 - the aifc module still imports the cl module in 3.0. >>Problem is that the cl module is gone. =) So it seems silly to have >>the imports lying about. This can probably be changed to critical. >> >> >>It shouldn't be a problem to rip everything cl-related out of aifc. >>The question is how useful aifc will be after that ... >> >> >> Has someone already used that module ? I took a look into it, but I'm a >> bit confused about the various compression types, case-sensitivity and >> compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the >> same encoding ? Can we use the audioop module for ALAW, just like it's >> already done for ULAW ? >> > > There is just one alaw I've ever come across (G.711), and the audioop > implementation could be used (audioop's alaw support is younger than the > aifc module, BTW) > > The capitalisation is confusing, but your document [1] says: "Apple > Computer's QuickTime player recognize only the Apple compression types. > Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and > "ulaw" formats and were in use long before Apple introduced the new codes, > QuickTime does not recognize them." > > So this seems just a matter of naming in the AIFC, but not a matter of two > different alaw implementations. > > - Lars > Ok, I'll handle this issue. I'll be using the audioop implementation as a replacement of the SGI compression library. I'll also create a test suite, as Brett mentioned in the bug tracker the module was missing one. Quentin > > [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Finishing up PEP 3108
I've uploaded a patch for the aifc module (http://bugs.python.org/issue2847). I'm still working on the testsuite. Comments are welcome! Quentin On Thu, May 29, 2008 at 5:39 PM, Quentin Gallet-Gilles <[EMAIL PROTECTED]> wrote: > > On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <[EMAIL PROTECTED]> wrote: > >> >> >>>Issue 2847 - the aifc module still imports the cl module in 3.0. >>>Problem is that the cl module is gone. =) So it seems silly to >>> have >>>the imports lying about. This can probably be changed to critical. >>> >>> >>>It shouldn't be a problem to rip everything cl-related out of aifc. >>>The question is how useful aifc will be after that ... >>> >>> >>> Has someone already used that module ? I took a look into it, but I'm a >>> bit confused about the various compression types, case-sensitivity and >>> compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the >>> same encoding ? Can we use the audioop module for ALAW, just like it's >>> already done for ULAW ? >>> >> >> There is just one alaw I've ever come across (G.711), and the audioop >> implementation could be used (audioop's alaw support is younger than the >> aifc module, BTW) >> >> The capitalisation is confusing, but your document [1] says: "Apple >> Computer's QuickTime player recognize only the Apple compression types. >> Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and >> "ulaw" formats and were in use long before Apple introduced the new codes, >> QuickTime does not recognize them." >> >> So this seems just a matter of naming in the AIFC, but not a matter of two >> different alaw implementations. >> >> - Lars >> > > Ok, I'll handle this issue. I'll be using the audioop implementation as a > replacement of the SGI compression library. I'll also create a test suite, > as Brett mentioned in the bug tracker the module was missing one. > > Quentin > > >> >> [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html >> > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] import error in python2.6
Hi Bristow, You didn't provide any broken code that could help us give an explanation. Also this kind of question is best answered on the python-users mailing list. Python-dev is reserved for discussion about the evolution of Python, not its use. Cheers, Quentin On Mon, Jul 21, 2008 at 2:12 PM, Bristow Thankachan < [EMAIL PROTECTED]> wrote: > Hi all, > > During the porting of Zope2, I am stuck with import errors in many modules. > The same code works well in python2.5 and 2.4. Can anybody give the details > of this import error in python2.6 and how to get the error corrected? > > with regards > > Bristow > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/qgallet%40gmail.com > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
