How to upload a file
Hallöchen! I'm skimming through the various recipies for uploading a file via HTTP. Unfortunately, all of them are awkward but also rather old. (See for example http://stackoverflow.com/questions/68477/send-file-using-post-from-a-python-script) In my module, I do my HTTP request like this: opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookielib.CookieJar())) opener.open(url, urllib.urlencode(data, doseq=True)) Well, and now I'd also like to include a file upload to the POST data. The solution should use urllib2, otherwise I'd have to change most of my existing code. If you now say "Torsten, unfortunately it *is* so complicated" I'll jump through the hoops, but I'd love to hear that with Python 2.6.5 there's an easier way. ;-) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- http://mail.python.org/mailman/listinfo/python-list
Path-like objects in the standard library
Hallöchen! Path-like objects are accepted by all path-processing functions in the standard library since Python 3.6. Unfortunately, this is not made explicit everywhere. In particular, if I pass a Path in the first argument of subprocess.run, do I use an implementation detail of CPython? Because on https://docs.python.org/3.6/library/subprocess.html, only for the cwd argument the acceptance of Paths is stated explicitly. The same goes for all functions in the shutil module. https://docs.python.org/3.6/library/shutil.html does not mention the path-like protocol anywhere, but the CPython modules seem to accept them anyway. Regards, Torsten. -- Torsten Bronger -- https://mail.python.org/mailman/listinfo/python-list
Re: ncurses programming
Hallöchen! "ncf" <[EMAIL PROTECTED]> writes: > [...] > > Py Docs: http://docs.python.org/lib/module-curses.html This document suggests that Python+ncurses won't work on windows. What's the reason for this? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: ncurses programming
Hallöchen! Grant Edwards <[EMAIL PROTECTED]> writes: > On 2005-09-26, Mike Meyer <[EMAIL PROTECTED]> wrote: > [...] >>>> Py Docs: http://docs.python.org/lib/module-curses.html >>> >>> This document suggests that Python+ncurses won't work on windows. >>> What's the reason for this? >> >> Could it be that ncurses doesn't work on Windows? At least, it >> didn't last time I looked. There was a curses library for >> Windows, but you'll have to google for it. > > I think there used to be something called pdcurses that > supposedly worked under windows. Wouldn't http://gnuwin32.sourceforge.net/packages/ncurses.htm be a good starting point? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: help w/ simple GPIB prog.
Hallöchen! "whoopsi" <[EMAIL PROTECTED]> writes: >Could someone give me some simple commands for communicating with > GPIB devices. If you find a file called visa32.dll on your system, you can just use <http://pyvisa.sourceforge.net>. NI ships this file bundled with their GPIB hardware, and you can download the latest version from <http://ni.com/visa>. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
Hallöchen! Paul Rubin <http://[EMAIL PROTECTED]> writes: > Michael Ekstrand <[EMAIL PROTECTED]> writes: >> >>> 2) Keybindings in a web application >> >> Not sure here, but JavaScript may be able to do something to >> accomplish some of this. A web-delivered XUL app can definitely >> do this. But that's pushing the limits of what can be considered >> a web application. > > All this extreme use of JS misses the point, it's client side > programming all over again, not really what most of us think of as > a web interface which puts all the hair on the server side. If > you want to program on the client, why not use a reasonable > language like Python instead of a monstrosity like JS? Because everybody is capable of running a JS engine, even on computers on which you don't have rights to install something. (Not that I like those JS ideas though ...) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs Ruby
Hallöchen! "Harald Armin Massa" <[EMAIL PROTECTED]> writes: > Casey, > >> I have heard, but have not been able to verify that if a program is >> about >> 10,000 lines in C++ >> it is about >> 5,000 lines in Java >> and it is about >> 3,000 lines in Python (Ruby to?) > > BTW: it is normally only 50 lines in Perl. Not that you could read > it, though At least they could form a heart. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Problem with subprocess.call and cp
Hallöchen! The following code from subprocess import call call(['cp', 'subdir/*.jpg', 'othersubdir/']) yields cp: call of stat for "subdir/*.jpg" not possible: File or directory not found (This may not be the real error message since it's back-translated from German.) I could use shell=True, however, what's going wrong here? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Unbound names in __del__
Hallöchen!
Peter Hansen <[EMAIL PROTECTED]> writes:
> Torsten Bronger wrote:
>
>> Peter Hansen <[EMAIL PROTECTED]> writes:
>>
>>> What's your use case for del?
>>
>> Every instance represents a "session" to a measurement instrument.
>> After the instance is deleted, the session should be closed to free
>> resources.
>
> You mean like GPIB devices?
Yes.
> We've written a lot of software that talks to instruments, as well
> as pumps, motors, and sensors of all kinds. I haven't even needed
> to "free resources", other than by closing a serial port, for
> example. [...]
I've just finished a thin-wrappers implementation of VISA in Python,
see <http://pyvisa.sf.net/>. It calls functions in a proprietary
VISA DLL/SO. The next step is to build a simple-to-use OO layer on
top of it. Therefore, we don't communicate with the device
directly, but via sessions (=handles) within the DLL.
These sessions should be freed when the object instance representing
the device is destroyed by Python. Using the __del__ method is the
natural choice for this in my opinion.
> [...] I'd recommend pretending __del__ does not exist and
> restructuring your system to close these sessions explicitly,
> under your direct control, at the appropriate point. This has
> worked very well for us so far.
I'd find this quite sad because so far it's drop-dead simple to use
the OO layer, and I may even convince our in-house HT Basic fans of
Python:
keithley = GpibInstrument(14)
keithley.write("*IDN?")
print keithley.read()
A keithley.close() would be a wart in my opinion; instead I want to
hide the whole session thing from the programmer. Besides, I
haven't yet given up the hope that the issues with __del__ can be
tackled.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list
Re: Unbound names in __del__
Hallöchen!
Peter Hansen <[EMAIL PROTECTED]> writes:
> Torsten Bronger wrote:
>
>> keithley = GpibInstrument(14)
>> keithley.write("*IDN?")
>> print keithley.read()
>>
>> A keithley.close() would be a wart in my opinion; instead I want
>> to hide the whole session thing from the programmer. Besides, I
>> haven't yet given up the hope that the issues with __del__ can be
>> tackled.
>
> At least one alternative comes to mind. Have the GpibInstrument
> class (or its module) register an atexit() method, and have the
> constructor for that class track all instances. On shutdown, the
> atexit method goes through all instruments that are still open and
> issues the .close() requests, or whatever you do in the __del__
> now.
However, this doesn't close sessions while the program is running.
If the programmer has the above code in a function which is called
repeatedly, he may run into trouble. IIRC my current VISA DLL has
only 256 session slots.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list
Re: Unbound names in __del__
Hallöchen! "Terry Reedy" <[EMAIL PROTECTED]> writes: > "Torsten Bronger" <[EMAIL PROTECTED]> wrote: > > [...] > >> However, this doesn't close sessions while the program is >> running. If the programmer has the above code in a function >> which is called repeatedly, he may run into trouble. IIRC my >> current VISA DLL has only 256 session slots. > > Deleting during a run is a different issue from deleting during > program shutdown, which is where you started us. Well, I talked about shutdown in the OP because only *then* I had experienced problems. Cleaning up is important in every phase of the program, though. > [...] So an explicit close is the only dependable > cross-implementation method that I know of. I agree, but I could live with the little danger of a Python implementation that frees so slowly that the DLL runs out of handles. One could add a close() method for emergency use. However, this __del__ thingy is so damn tempting ... ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Favorite non-python language trick?
Hallöchen!
Jeffrey Maitland <[EMAIL PROTECTED]> writes:
> [...]
>
> {
> for(int i = 0; i < 100; i++){
> //do stuff
> }
> }
>
> wrapping the for loop in { } makes the i a local variable
It's local anyway.
> and then you can use it again in the code if not you will get a
> variable already defined error.
Only in compilers created by this infamous company.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list
distutils: Every file doubled in binary distri
Hallöchen! I have a very simple package structure with one directory denoting a package (with __init__.py file of course). In my setup.py I write ... packages=['my_package'] ... Then I call "python setup.py bdist_dumb" on ym Linux box. The resulting tar ball contains every file twice, e.g. ./usr/lib/python2.3/site-packages/my_package/my_module.py ./usr/lib/python2.3/site-packages/my_module.py Why is this? (The source distri doesn't show this effect.) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: distutils: Every file doubled in binary distri
Hallöchen! Ingrid Bronger <[EMAIL PROTECTED]> writes: > [...] > > Then I call "python setup.py bdist_dumb" on ym Linux box. The > resulting tar ball contains every file twice, e.g. > > ./usr/lib/python2.3/site-packages/my_package/my_module.py > ./usr/lib/python2.3/site-packages/my_module.py > > Why is this? (The source distri doesn't show this effect.) Forget it, false alert. It was probably obsolete rubbish of earlier calls in build/. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Favorite non-python language trick?
Hallöchen! Terry Hancock <[EMAIL PROTECTED]> writes: > [...] > > BASIC did it that way, IIRC. Right. > [...] > > I don't think Python's use of "==" has *ever* helped me find a > bug, it just creates them. I really think "=" ought to be > accepted as well, and "==" deprecated. However, then you must forbid a=b=1 for assigning to two variables at the same time. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
ANN: PyVISA 0.9 (first public release)
Hallöchen! At http://pyvisa.sourceforge.net you can find information about the PyVISA package. It realises Python bindings for the VISA library functions, which enables you to control measurement devices via Python. Yesterday I released version 0.9. I tried to provide it with good documentation. It works very nicely with the GPIB in our lab, however, I haven't yet received feedback from others, so I leave it in beta status and with a version number < 1. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGTK or wxPython (not a flame war) on Windows
Hallöchen! Marek Kubica <[EMAIL PROTECTED]> writes: > Hello! > >> AFAIK PyGTK doesn't look native on Win as well, but I don't care. > > [...] The native look and feel is not as good as the look and feel > of wx but still really _much_ better than older versions of GTK. Is PyGTK more Pythonic by the way? I had a look at wxPython yesterday and didn't like that it has been brought into the Python world nearly unchanged. You can see its non-Python origin clearly. How does PyGTK feel in this respect? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGTK or wxPython (not a flame war) on Windows
Hallöchen! Marek Kubica <[EMAIL PROTECTED]> writes: > [...] > > I have started GUIs in Python with wx, but after a short time I > was annoyed how many things were buggy. I don't know why, but I > fell from one bug to the other while programming one application. I'm very suprised. wxPython is still that buggy? I read reports from 2000 about such observations, but they tried wxPython in a non-standard way, and the project has had 5 years to become more stable after all. Besides, wxPython prepares for being included into the standard distribution. What did you do? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGTK or wxPython (not a flame war) on Windows
Hallöchen! Bryan <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> Besides, wxPython prepares for being included into the standard >> distribution. > > wow, i've never heard this said so explicitly. is there a > reference link backing up this statement? i really really hope > this is true. i'm very much in favor to see wx included in the > standard distrubution. As far as i know, there is nothing official. But I've read several times that it's the most likely candidate for a seconds GUI system for being included. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Wheel-reinvention with Python (was: Ten Essential Development Practices)
Hallöchen! Michael Hoffman <[EMAIL PROTECTED]> writes: > Dark Cowherd wrote: > >> GUI, Web development, Application Framework - it is shambles. > > Yeah, I agree. When I finally make that GUI application I still > don't know whether I am going to use wx or PyGTK. I agree, too, although I can only talk about GUI toolkits. At first one thinks "well, perfect, I have the choice between four great GUI systems". However, except for very special demands, there is no clear winner. You start learning one, and immediately wonder whether the other might be better. Although it sounds paradoxical, this can be quite frustrating. After all, most of us don't have the energy or motivation to test all candidates thoroughly. Besides, development resources are shared between all projects. This is especially sad with regard to IDEs. There are even more IDEs/dialog editors/widget builders than Toolkits, none of them being mature. >> Is there some place to discuss topics like this? Is this the right place? > > Sure, although you might want to start a new thread. ;) At least a new subject ... Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Calvin Spealman <[EMAIL PROTECTED]> writes: > The choice is GUI toolkits is largely seperate from > Python. Consider that they are just bindings to libraries that are > developed completely seperate of the language. GUI is should be > seperate from the language, and thus not bound to same > expectations and desires as elements of the language itself. I disagree. A modern language must provide a convenient and well-embedded way to write GUI applications. This is not a sign of decadence, but a very good promotional argument. Delphi and first and foremost VB are extremely popular, and it's sad to see that Python could get a lot more of the cake if the efforts for IDEs and toolkits were somewhat streamlined. Besides, all other already good aspects of Python wouldn't suffer at all. Tkinter fits into Python very well and it is very easily (if not trivially) accessible for users of our applications. People complain about non-native look-and-feel on Windows, but sorry, I simply find it unacceptably ugly on all platforms. Don't misunderstand me: I don't like neat GUI effects just for the sake of it but Tkinter makes an outdated impression on the end-user. I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. PyGTK and PyQt may have their own advantages and disadvantages. However, in my opinion we don't need yet another binding so thin that C or C++ is shining through, but a modern replacement for Tkinter with its Pythonic way of thinking. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Peter Decker <[EMAIL PROTECTED]> writes: > On 7/30/05, Torsten Bronger <[EMAIL PROTECTED]> wrote: > >> I've been having a closer look at wxPython which is not Pythonic >> at all and bad documented. Probably I'll use it nevertheless. >> PyGTK and PyQt may have their own advantages and disadvantages. >> >> However, in my opinion we don't need yet another binding so thin >> that C or C++ is shining through, but a modern replacement for >> Tkinter with its Pythonic way of thinking. > > I had the exact same impression when I started working with > wxPython: [...] I then discovered Dabo (http://dabodev.com), which > is a full application framework, but whose UI layer is a very > Pythonic wrapper around wxPython. I've created several apps now > using Dabo, even though I haven't even looked at the data > connectivity aspects of it; the UI code works fine without it. I'm aware of it (and there is Wax and maybe a third one). Actually it illustrates my point quite well: These projects are small and instable (Dabo has a developer basis of very few people, Wax has only one); they are even worse documented; they add another layer which slows down and requires the end-user to install another package; they force you to test even more GUI approaches. ==> They contribute heavily to Dark Cowherd's observation that "it is shambles". Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! [EMAIL PROTECTED] (phil hunt) writes: > [...] > > How about sometihing with the same API as Tkinter (so no need to > relearn), but which looks prettier? Would that fix your gripes? I haven't learned Tkinter. Well, I programed toy applications with different toolkits (including Tkinter) and tried to make a rather competent decision, that's all. So for me, it needn't be like Tkinter. The three most important attributes for me are Pythonic, modern (both nice-looking and comprehensive), and non-niche. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Peter Decker <[EMAIL PROTECTED]> writes: > On 7/30/05, Torsten Bronger <[EMAIL PROTECTED]> wrote: > >> I'm aware of it (and there is Wax and maybe a third one). >> Actually it illustrates my point quite well: These projects are >> small and instable (Dabo has a developer basis of very few >> people, Wax has only one); they are even worse documented; they >> add another layer which slows down and requires the end-user to >> install another package; they force you to test even more GUI >> approaches. > > Well, wxPython itself is largely the work of a single person, but > I doubt that many consider that a reason to avoid it. But the developer and contributor base is much larger, so the project has reached the critical mass. > As far as your comment about 'slowing down' the app, I've found > that Dabo and pure-wxPython apps run indistinguishably. Perhaps > there are some microseconds of extra processing, but I sure > haven't noticed it. And I don't think that the comment about > installing another package is fair; *anything* outside of the > standard distribution requires that, and Dabo is no more difficult > than copying to site-packages. I didn't want to say that Dabo is bad. I just wanted to point out that its presence (and the presence of comparable projects) doesn't ease the IMO unfortunate situation with GUI toolkits for Python. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Peter Decker <[EMAIL PROTECTED]> writes: > On 7/30/05, Torsten Bronger <[EMAIL PROTECTED]> wrote: > >> [...] >> >> I didn't want to say that Dabo is bad. I just wanted to point >> out that its presence (and the presence of comparable projects) >> doesn't ease the IMO unfortunate situation with GUI toolkits for >> Python. > > Perhaps, but I see it differently, since Dabo doesn't attempt to > add a new toolkit. Well, effectively, it does so because from the human point of view, the programming interface is what you have to deal with. > [...] Dabo is giving me the best of both worlds: a Pythonic > language, and great-looking GUI apps. So I feel that it is > improving the situation with GUI toolkits for Python in that it is > allowing me to use the best toolkit without having to write > un-Pythonic code. You found a solution for you, which is a good thing. I don't want to rule out to use Dabo myself. But in my institute I'd like to present Python as a viable alternative to Delphi. In order to convince people who are used to a homogeneous rock-solid system, you must present something equivalent. Of course an open-source project can never be as homogeneous, but I can't make the whole team switch to a niche project, ignoring all other GUI alternatives about which you can even buy books in German! They'll think "strange, that Python" (or maybe "strange that Torsten" ;). > It would be great if the wxPython folks would adopt Dabo, and > eventually integrate it so that there is but a single, Pythonic > way of working with wxPython, Yes indeed. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> Calvin Spealman <[EMAIL PROTECTED]> writes: >> >>> The choice is GUI toolkits is largely seperate from >>> Python. Consider that they are just bindings to libraries that >>> are developed completely seperate of the language. GUI is should >>> be seperate from the language, and thus not bound to same >>> expectations and desires as elements of the language itself. >> >> I disagree. A modern language must provide a convenient and >> well-embedded way to write GUI applications. > > [...] > > The tools for writing GUI applications belong in a library, not > the langauge. None of us has talked about changing syntax. However, the standard library is part of the language unless you're really very petty. >> This is not a sign of decadence, but a very good promotional >> argument. > > But it's not required for the language to succeed. Today it is (except for very special-purpose languages). > C and C++ are both doing very well without your a well-embedded > way to write GUI applications. I don't think that much money is made with new C programs. Almost all money with C++ is made with VC which has been having a GUI toolkit in its standard library right from the beginning. And most money is made with VB AFAIK. > However, you can get compilers for both that come bundled with a > good GUI library. Could it be that that's what you really want - > someone to distribute Python bundled with an enterprise-class GUI > library and IDE? Well, a nice thing to have, but besides my point. We do have a standard library with a robust GUI package, and a standard distribution with a so-called IDE. What I really want is a better GUI included into the standard library. >> However, in my opinion we don't need yet another binding so thin >> that C or C++ is shining through, but a modern replacement for >> Tkinter with its Pythonic way of thinking. > > I don't particularly like Tkinter, but it seems to me that it's > pretty much won. It seems to be installed on every desktop > platform along with Python. That means that if I want to > distribute GUI apps, I'm going to cause the least headache for my > end users by writing them in Tkinter. A "replacement for Tkinter" would have the same properties, otherwise it wouldn't be a replacement. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! [EMAIL PROTECTED] (phil hunt) writes: > On Sat, 30 Jul 2005 16:51:13 +0200, Torsten Bronger <[EMAIL PROTECTED]> wrote: > >> [EMAIL PROTECTED] (phil hunt) writes: >> >>> [...] >>> >>> How about sometihing with the same API as Tkinter (so no need to >>> relearn), but which looks prettier? Would that fix your gripes? >> >> I haven't learned Tkinter. > > [...] > > Not that I'm a particular fan of it, it's just I like > standardisation, because then you get network effects. Me too. Therefore I'd like to see a new toolkit in the standard library to see a new network growing. You mustn't do something like this too often of course but I think in this case it would be the right time. >> So for me, it needn't be like Tkinter. The three most important >> attributes for me are Pythonic, modern (both nice-looking and >> comprehensive), and non-niche. > > What you say Pythonic, what do you mean? And how do you rate > Tkinter, PyGtk, PyQt/PyKDE, wxWindows for "Pythonicness"? I don't like to set arguments to -1 or NULL, but to None. I'd like to have extensive support for keyword arguments. I don't like mucking about with ID values. Partly this is cosmetical but partly it's a rich source of errors. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Cliff Wells <[EMAIL PROTECTED]> writes: > [...] > > The least headache for end users comes from properly packaging your > application. End users shouldn't need to worry about installing third > party packages (or even Python for that matter). Tools such as py2exe > and Inno installer make this pretty simple on Windows, and py2app on > OS/X accomplishes the same. Does py2exe work for all GUI libraries? It'll highly probably work with Tkinter, and I've read that it also works with pyGTK, but does it also work with wxPython or PyQt? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Paul Rubin <http://[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> Does py2exe work for all GUI libraries? > > No, it's Windows-only. However, OS'es and GUI libraries are different axes in the space of possibilities. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Paul Rubin <http://[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >>>> Does py2exe work for all GUI libraries? >>> >>> No, it's Windows-only. >> >> However, OS'es and GUI libraries are different axes in the space >> of possibilities. > > I'm not sure what you mean. I didn't ask "does it work with OSX" but "does it work with wxPython or PyQt". py2exe only creates Windows files, that's right, but why is this important here? Be that as it may, some Google postings suggest that it works at least with wxPython. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Terry Hancock <[EMAIL PROTECTED]> writes: > On Saturday 30 July 2005 01:54 am, Torsten Bronger wrote: > >> Calvin Spealman <[EMAIL PROTECTED]> writes: >> >>> The choice is GUI toolkits is largely seperate from >>> Python. Consider that they are just bindings to libraries that >>> are developed completely seperate of the language. GUI is should >>> be seperate from the language, and thus not bound to same >>> expectations and desires as elements of the language itself. >> >> I disagree. A modern language must provide a convenient and >> well-embedded way to write GUI applications. > > I know I'm diving into this conversation late, and I haven't read > the whole thread, but has someone yet mentioned the "anygui" > project? This has stalled, but it was IMHO a good idea. I don't know exactly why this project died, but I'd start with a Pythonic variant of wxPython. I've read many discussions about the people who didn't like the wxPython's C++ style, so there are chances to get fellow developers and users. You must reach the critical mass quickly in order to get a survivable project, and being not too far away from an existing one is a good stating point. Possibly Dabo manages such a thing. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Paul Rubin <http://[EMAIL PROTECTED]> writes: > Ed Leafe <[EMAIL PROTECTED]> writes: > >> But since UIs are incredibly complex beasts, we've chosen to >> tackle one at a time, and after looking at them all and >> considering different issues, we chose wxPython as the best >> toolkit for creating platform-independent apps. > > How on earth did you decide that, since tkinter actually runs out > of the box when you install Python on most platforms, and wxPython > doesn't? I can't really understand your hostility towards non-Tkinter toolkits. In the case of wxPython, it's part of SUSE, which is probably also true for Fedora and Mandriva. Installing is as easy as selecting a checkbox. This covers a very great deal of Linux users. On Windows you have to call an exe file. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> [...] >> >> None of us has talked about changing syntax. However, the >> standard library is part of the language unless you're really >> very petty. > > Or you use different Python implementations. There are four > different Python implementations in the world. Not everything in > the CPYthon standard library runs in all of them. Or are you going > to claim that someone usin Jython isn't using Python because they > can't use the full standard library? Well, in a way, they aren't using Python indeed. For example, most Python books tell only partly the truth in this case. > [...] > >>>> This is not a sign of decadence, but a very good promotional >>>> argument. >>> >>> But it's not required for the language to succeed. >> >> Today it is (except for very special-purpose languages). > > To put this differently, it's required if you want to succeed as a > language for the specific purpose of creating GUI > applications. I'd agree to that. But there are *lots* of other > application areas around, so limiting your definition of "success" > to that one field is very short-sighted. You have to take into account not only the number of application areas, but also their respective importance. I'm interested in a language with a big community. This is my definition of success. It has to do with the functionality I can expect (more contributors can create more modules and documentation) and with future-proofness. GUI applications seem to be the most attractive application type. This is not only true for commercial programming. When I look at the most agile projects on Sourceforge, almost all of them have a GUI. Therefore, GUI-aware languages attract much larger user bases, and so they cater my definition of being successful. > [...] By which measure C is still immensely popular, because of > the large number of older applications that are written in it that > are available - Python being one such. Legacy code is not a sign of success IMO because it implies a difficult future. > [...] I'd say Python has succeeded as a web development language, > and as a systems scripting language - and I've certainly missed > some. I don't think that Python should rely on these old strongholds. In the biggest bookstore of our region, there is one book about Zope but a whole bookself about PHP. And I've never used consciously a Python system script in contrast to dozens of Perl scripts. In contrast to PHP or Perl, I consider Python a general-purpose language. There is its future in my opinion. However, this area is much tougher, and you need a good GUI approach there. > [...] > >>> [...] Could it be that that's what you really want - someone to >>> distribute Python bundled with an enterprise-class GUI library >>> and IDE? >> >> Well, a nice thing to have, but besides my point. > > Then you seem to have missed some of your own points. C++ > succeeded without having a standard GUI library. You claimed that > that success was because of a single distribution that included > the things you are looking for. Why can't the same thing work for > Python? I just didn't say that it couldn't work. But I don't think it'll happen, that's all. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Cliff Wells <[EMAIL PROTECTED]> writes: > [...] > > Well, I think this exposes one of the more interesting sides of > open source software in general. For better or worse, you get > choices. If you don't like choice, you won't like open source. On the other hand, the GUI package bundled with Python is a regular decision of some sort of committee. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Paul Rubin <http://[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> I can't really understand your hostility towards non-Tkinter >> toolkits. In the case of wxPython, it's part of SUSE, which is >> probably also true for Fedora and Mandriva. Installing is as >> easy as selecting a checkbox. This covers a very great deal of >> Linux users. On Windows you have to call an exe file. > > No it's not on Fedora, at least FC3. It may not be on a DVD but the RPMs are avaiable where Fedora should look for them. > I had huge trouble trying to build it and gave up. It's perfectly okay if you are used to build everything yourself but this is a quite untypical approach. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Cliff Wells <[EMAIL PROTECTED]> writes: > On Sun, 2005-07-31 at 23:46 +0200, Torsten Bronger wrote: > >> Cliff Wells <[EMAIL PROTECTED]> writes: >> >>> [...] >>> >>> Well, I think this exposes one of the more interesting sides of >>> open source software in general. For better or worse, you get >>> choices. If you don't like choice, you won't like open source. >> >> On the other hand, the GUI package bundled with Python is a >> regular decision of some sort of committee. > > No, it's a decision made by Guido some years ago that remains in > place because it's more pain to remove than to simple leave there. http://wiki.python.org/moin/TkInter suggests that it's a more or less regular decision. > Besides, define "bundled with". Described in the standard library documentation. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> [...] >> >> I'm interested in a language with a big community. This is my >> definition of success. [...] >> >> GUI applications seem to be the most attractive application type. >> This is not only true for commercial programming. When I look at >> the most agile projects on Sourceforge, almost all of them have a >> GUI. > > Why restrict yourself to agile projects? Because such projects attract the greatest number of developers, many of them being amongst the most diligent developers, too. I expect this to have a positive influence of the language. > [...] > > I won't argue that most of the projects on Sourceforge have GUIs - > that's certainly true. I will argue that most of the projects are > done in languages that aren't what you call GUI-aware. Yes, this is what I meant with "legacy code". C and C++ are actually special-purpose. They are good for controlling a computer but not for implementing an idea. Their current vitality on almost all software areas arise from the fact that they had been extremely successful before Java, C#, and VB came into play. Invented today, they would be niche languages. However, even C++ is really successful only when used as a GUI-aware dialect. Additionally, Python does not have this legacy bonus. >> Therefore, GUI-aware languages attract much larger user bases, >> and so they cater my definition of being successful. > > Since you haven't stated what that definition is, I can't really say > anything about this. Yes, I did. > [...] > >> Legacy code is not a sign of success IMO because it implies a >> difficult future. > > So you're saying that Python, Perl, Linux, the various BSD > et. al. will have a difficult future? [...] No. All I said was that if a language's "success" relies almost exclusively on the heavy presence of legacy code, its future is difficult. I see this for C and C++ excluding VC++. They will always be there, but "cool new things" will be made available firstly (or only) for Java, C#, Python etc. > [...] > > Or maybe you could switch to Jython, and just use swing? Actually I'm very happy with CPython. Besides, I don't like the Java world. When I left C++ last winter, I dithered between C#, Ruby, and Python. BTW this thread was extremely interesting for me. I've learnt a lot. (Unfortunately, two weeks ago I opted for wxPython, after a long and tough time of thorough pondering, and today this thread informed be about progress on the Tk front. *cry* ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Cliff Wells <[EMAIL PROTECTED]> writes: > On Tue, 2005-08-02 at 09:45 +0200, Torsten Bronger wrote: > >> Yes, this is what I meant with "legacy code". C and C++ are >> actually special-purpose. They are good for controlling a >> computer but not for implementing an idea. Their current >> vitality on almost all software areas arise from the fact that >> they had been extremely successful before Java, C#, and VB came >> into play. > > Unfortunately your assertion is patently false. C and C++ are > very much general-purpose languages. This is true in the sense that you can realise an arbitrary program with them, and you can use the full power of the computer. But in my opinion the era of such programming is over. Already today but even more in the future programs of all kind are coded in the higher-level languages (including VC++), limiting C(++) to the field of system programming. Probably quibbling, but this is how I meant it. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> [...] >> >> Because such projects attract the greatest number of developers, >> many of them being amongst the most diligent developers, too. I >> expect this to have a positive influence of the language. > > You didn't answer the question about how you define agile > project. Please do so if you expect a comment on this. Projects with a high Sourceforge activity index. > [...] > >> Yes, this is what I meant with "legacy code". C and C++ are >> actually special-purpose. They are good for controlling a >> computer but not for implementing an idea. Their current >> vitality on almost all software areas arise from the fact that >> they had been extremely successful before Java, C#, and VB came >> into play. Invented today, they would be niche languages. > > This is patently absurd. C and C++ were born as general-purpose > languages. Changing the environment around them isn't going to > change that. In 1955 people would have told you that Fortran is general-purpose. It's not the case any more. > [...] > >>>> Legacy code is not a sign of success IMO because it implies a >>>> difficult future. >>> >>> So you're saying that Python, Perl, Linux, the various BSD >>> et. al. will have a difficult future? [...] >> >> No. All I said was that if a language's "success" relies almost >> exclusively on the heavy presence of legacy code, its future is >> difficult. I see this for C and C++ excluding VC++. > > Well, you lumped all C/C++ code a legacy code. No because ... > [...] > > You can't have it both ways. Either C/C++ is all legacy code, or > it's not. ... is wrong in my opinion. Why should this be? > [...] > > I think you need to come out from behind your Windows box for a > while. But you did read my headers? ;-) > There are *lots* of applications areas that don't need GUIs, > and don't run on Windows. This becomes a discussion about estimates we both don't know exactly, and weight differently, so I'll leave it here. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Mike Meyer <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> Mike Meyer <[EMAIL PROTECTED]> writes: >> >>> Torsten Bronger <[EMAIL PROTECTED]> writes: >>> >>> [...] >>> >>> You didn't answer the question about how you define agile >>> project. Please do so if you expect a comment on this. >> >> Projects with a high Sourceforge activity index. > > That doesn't seem to match the common defintion of "agile" when it > comes to programming. Then again, you have a habit of using words > to mean whatever you want, without much reference to how they're > used by the rest of the industry. I'm not part of the industry. Sorry, but now the arguments are getting destructive. Agile programming is a fixed phase, which I've never used. (And which makes no sense in this discussion.) > [...] > > Sorry, but you're wrong. FORTRAN is very much a general purpose > language. [...] It's not about the potential use of a language, but its actual use. > [...] > >>> You can't have it both ways. Either C/C++ is all legacy code, or >>> it's not. >> >> ... is wrong in my opinion. Why should this be? > > Because any given proposition is either true or false. If I say "most people are right-handed", then this means neither that all people are right-handed nor that none is. > [...] > >>> There are *lots* of applications areas that don't need GUIs, and >>> don't run on Windows. >> >> This becomes a discussion about estimates we both don't know >> exactly, and weight differently, so I'll leave it here. > > No, it's not a discussion about estimates. The average household > in a G8 country has more computers that don't run Windows - and in > fact don't have GUIs at all - than otherwise. [...] However, it's about the types of software which is being produced today. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > On Thu, 04 Aug 2005 00:53:28 -0400, Mike Meyer <[EMAIL PROTECTED]> declaimed > the following in comp.lang.python: > >> No, it's not a discussion about estimates. The average household >> in a G8 country has more computers that don't run Windows - and >> in fact don't have GUIs at all - than otherwise. This is a fact >> of life. >> > Maybe one needs to have an itemization to understand? > > Digital clocks, Digital watches, cellphones, digital > radio/TV tuners, DVD and CD players, Microwave ovens, VCRs, > printers, the more modern monitors with on-screen menus... (my > dozen or so amateur, MURS, GMRS, FRS radios), cordless telephones, > my heater thermostat, answering machine, pedometer... I did understand, however, my MP3 player makes one whole "computer" in Mike's statistics but it contains at most 5000 lines of own code. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen!
Mike Meyer <[EMAIL PROTECTED]> writes:
> Torsten Bronger <[EMAIL PROTECTED]> writes:
>
>> Mike Meyer <[EMAIL PROTECTED]> writes:
>>
>>> Torsten Bronger <[EMAIL PROTECTED]> writes:
>>>
>>>> Mike Meyer <[EMAIL PROTECTED]> writes:
>>>>
>>>>> Torsten Bronger <[EMAIL PROTECTED]> writes:
>>>>>
>>>>> [...] You didn't answer the question about how you define
>>>>> agile project. Please do so if you expect a comment on this.
>>>>
>>>> Projects with a high Sourceforge activity index.
>>>
>>> That doesn't seem to match the common defintion of "agile" when
>>> it comes to programming. Then again, you have a habit of using
>>> words to mean whatever you want, without much reference to how
>>> they're used by the rest of the industry.
>>
>> I'm not part of the industry.
>
> That's no excuse for not learning the terminology, or at least
> avoiding using phrases which already have a common meaning.
Granted, I didn't pay enough attention to the fact that for industry
people "agile" has a much stronger connotation. Nevertheless, it's
an ordinary English word, too, so that's no excuse for not trying to
understand what I *mean*. Since nobody has any chance to see which
programming strategy the projects uses, you must deliberatly
misunderstand me for assuming that I meant "agile programming".
> [...]
>
> [...] The difference is ther are a lot of other choices, so it
> gets chosen less often. But I note that at least one of the 155
> projects on SourceForge that list FORTRAN as a language is a GUI
> application for Windows.
I see no difference to special-purpose language then.
> [...]
>
> [...] Just like some C/C++ applications are legacy code, and some
> aren't. Which contradicts your earlier assertion that C/C++
> applications were all legacy code.
Reference?
> [...]
>
> Earlier, you said you wanted a popular language because they get
> cool features faster. You hold up two proprietary VC++ (which is
> just an development environment) and VB as "popular" languages. If
> you've been watching software development long enough, you'd
> realize that "cool things" usually come from open source projects
> first.
That's right (or rather, I believe you). I just want to use a
popular langauge amongst the ones that have free success ("free" in
the sense of Free Software).
I used VB and VC++ for my assertion -- that you don't share -- that
GUI abilities are the only way to get much popularity, which is in
my opinion necessary for "cool things". If you say it's not
sufficient, okay.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen!
Mike Meyer <[EMAIL PROTECTED]> writes:
> Torsten Bronger <[EMAIL PROTECTED]> writes:
>
>> [...]
>
> I notice that the Wikipedia doesn't have a definition for "special
> purpose language", instead preferring the phrase "Domain Specific
> Langauge". That matches the definition that agrees with what I
> think is common usage, which is:
>
> Trade some of the flexibility of a general purpose language
> for capabilities that are more tailored to a specific task
>
> Fortran certainly meets the requirements the wikipedia has for
> being a general purpose language.
As does TeX. I don't think that this adds anything to the
argumentation.
>>> [...] Just like some C/C++ applications are legacy code, and some
>>> aren't. Which contradicts your earlier assertion that C/C++
>>> applications were all legacy code.
>>
>> Reference?
>
> See http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/c52d3c17f1ea9ec5/d2013c3f1eef49b9?q=wheel+reinvention&rnum=1#d2013c3f1eef49b9
>>, where you dismiss all C applications a legacy code.
This URL points to an article by Paul McNett.
Probably you mean
>>> [...] By which measure C is still immensely popular, because of
>>> the large number of older applications that are written in it
>>> that are available - Python being one such.
>
> Legacy code is not a sign of success IMO because it implies a
> difficult future.
Calling "older applications" "legacy code" is very different from
calling C/C++ a legacy code language.
> [...]
>
>> [...] I just want to use a popular langauge amongst the ones
>> that have free success ("free" in the sense of Free Software).
>
> These leaves me with three questions for you:
>
> Is there a free language you consider successful?
Before the quibbling starts again: What do you mean with "free
language"? For me, that's every language that I can use using
exclusively Free Software tools.
> [...]
>
> Are there any free language that have the GUI/IDE toolkit you
> want?
I don't know. I haven't seen it yet. Maybe Eclipse + SWT?
> Have you noticed that languages with really cool features aren't
> very popular?
This is probably true, but "really cool features" tend to become
"exotic features". I don't need them, neither the masses. A good
GUI toolkit is a nice "cool thing" to have.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Hallöchen! "Terry Reedy" <[EMAIL PROTECTED]> writes: > [...] Consider > > Hypothesis 1: someone learned Python and Tkinter, felt > dissatisfied with Tkinter, went searching the universe for an > alternative, found GTK, and wrote PyGTK, perhaps learning C in the > process. > > Hypothesis 2: a C-programmer who is a satisfied user of GTK (on > *nix, presumably) learns Python. "Neat, but I also want to keep > using GTK." Which he can because it is relatively easy. > > Repeat H1 and H2 for every wrapping. You believe in H1. I > suspect H2 is more often true, but admit I have no data. It is probably H2 (otherwise the reluctance to learn GTK so thoroughly would be too great) but with the important addition that the creator of PyGTK felt the general dissatisfaction with Tkinter. Getting users is a very very important motivation for a developer after all. >> That by itself says the stdlib is lacking. > > I have an alternate interpretation. There is a Python wrapping > for as many C libraries as there are because Python is neat and > wrapping is fairly easy and the rewards great. Yes, absolutely; but for the core functionality (which must contain a good GUI toolkit in my opinion) you should have more that just a "binding". Instead, it should be well-embedded into the standard library and the language. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -- (just) a successful experiment?
Hallöchen! Robert Kern <[EMAIL PROTECTED]> writes: > [...] > > What I'm trying to say is that posting to c.l.py is absolutely > ineffective in achieving that goal. Code attracts people that like > to code. Tedious, repetitive c.l.py threads attract people that > like to write tedious, repetitive c.l.py threads. Although I mostly agree with you, I must also say that it can be a significant motivation for a developer to see that his project is urgently needed and that he can expect a quite big user base and early fellow developers. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Spaces and tabs again
Hallöchen! [EMAIL PROTECTED] writes: > [...] I know that some people likes tabs, and other people likes > spaces, so probably a single standard cannot be enforced, but I > think the python compiler must generate an error (and stop > compiling) when the sourcecode of a module contains both spaces > and tabs to indent the lines of code (and comments lines too?). I think the interpreter option -tt does this but I've never used it. I agree that mixing spaces and tabs is a bad thing. Unfortunately, my default Emacs configuration did so, whyever. I changed it a couple of days ago. However, the PEP 8 strongly dicourages it anyway. Tschö, Torsten -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Really virtual properties
Hallöchen! When I use properties in new style classes, I usually pass get/set methods to property(), like this: x = property(get_x) If I overwrite get_x in a derived class, any access to x still calls the base get_x() method. Is there a way to get the child's get_x() method called instead? (I found the possibility of using an intermediate method _get_x which calls get_x but that's ugly.) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type
Hallöchen! "Terry Reedy" <[EMAIL PROTECTED]> writes: > "Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message > news:[EMAIL PROTECTED] > >> "Terry Reedy" <[EMAIL PROTECTED]> writes: >> >>> Str.find is redundant with the Pythonic exception-raising >>> str.index and I think it should be removed in Py3. >> >> I like having it available so you don't have to clutter your code >> with try/except if the substring isn't there. But it should not >> return a valid integer index. > > The try/except pattern is a pretty basic part of Python's design. > One could say the same about clutter for *every* function or > method that raises an exception on invalid input. Should more or > even all be duplicated? Why just this one? Granted, try/except can be used for deliberate case discrimination (which may even happen in the standard library in many places), however, it is only the second most elegant method -- the most elegant being "if". Where "if" does the job, it should be prefered in my opinion. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for lambda - 'def' as an expression?
Hallöchen! "talin at acm dot org" <[EMAIL PROTECTED]> writes: > [...] > > Anyway, here's an example, then, of how 'def' could be used: > > add = def( a, b ): >return a + b I'm really not an expert in functional programming, so I wonder what's the difference between "add = def" (assumed that it worked) and "def add"? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: End or Identify (EOI) character ?
Hallöchen! Donn Cave <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, > "Terry Reedy" <[EMAIL PROTECTED]> wrote: > >> "Madhusudan Singh" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>> I was wondering how does one detect the above character. It is >>> returned by an instrument I am controlling via GPIB. >> >> [...] > > Which begs the question, what is the ASCII number of the > character? I was curious enough to feed GPIB and EOI into > a search engine, and from what I got back, I believe it is > not a character, but rather a hardware line that may be > asserted or not. Right. Well, sometimes there are "termination characters" that denote the end of a message sent from the intrument to the computer and vice versa, see <http://pyvisa.sourceforge.net/pyvisa/node17.html>. They are not EOI though but \r or \n. Besides, normally you work on an abstraction level where you don't worry about the EOI line or any termination characters. For example, you work with <http://pyvisa.sourceforge.net>. ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Appeal for python developers
HallÃchen! BOOGIEMAN <[EMAIL PROTECTED]> writes: > Please include "goto" command in future python realeses I know > that proffesional programers doesn't like to use it, but for me as > newbie it's too hard to get used replacing it with "while", "def" > or other commands Accordings to Stroustrup's C++ book, the only good reason for goto statements in a language is to have it in computer-generated code. I don't know whether programs generate Python, but I *think* that even there "goto" can be avoided very easily. Anyway, at our institute we control devices with HT Basic, and my collegues have used lots of gotos, so I can understand that avoiding them is somewhat inconvenient at the beginning. However, it's still very easy to learn. Most gotos are disguised function calls, so just copy the code in a "def". And loops can be translated to "while"s almost trivially. After a couple of days, it'll be even simpler than before. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Appeal for python developers (THIS IS A TROLL)
HallÃchen! Dave Reed <[EMAIL PROTECTED]> writes: > On Saturday 05 March 2005 09:34, Thomas RÃsner aka TRauMa wrote: > >> [...] >> >> Technically, as a newbie you shouldn't know about GOTO at all. So >> you're more a "Tainted by previous spaghetti code practices"-guy >> than newbie. > > Or more likely a troll. Google for: > > Boogieman yahoo troll > > and you'll see this isn't the only place he/she does this sort of > thing. And this makes a troll? TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Generating data types automatically
HallÃchen!
I have to generate a lot of data types (for ctypes by the way). An
example is
ViUInt32 = u_long
ViPUInt32 = POINTER(ViUInt32)
ViAUInt32 = ViPUInt32
Therefore, I defined functions that should make my life easier:
def generate_type_dublett(visa_type, ctypes_type):
visa_type_name = visa_type.__name__
exec visa_type_name + "=" + ctypes_type.__name__
exec "ViP" + visa_type_name[2:] + "=POINTER(" + visa_type_name + ")"
def generate_type_triplett(visa_type, ctypes_type):
generate_type_dublett(visa_type, ctypes_type)
visa_type_name = visa_type.__name__
exec "ViA" + visa_type_name[2:] + "=" + "ViP" + visa_type_name[2:]
generate_type_triplett(ViUInt32, c_ulong)
However, this doesn't work, probably because the defined type exist
only locally within the function.
What is a better (and working) method for this task?
Thank you!
TschÃ,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list
Re: Generating data types automatically
HallÃchen!
Torsten Bronger <[EMAIL PROTECTED]> writes:
> I have to generate a lot of data types (for ctypes by the way).
> An example is
>
> ViUInt32 = u_long
> ViPUInt32 = POINTER(ViUInt32)
> ViAUInt32 = ViPUInt32
>
> Therefore, I defined functions that should make my life easier:
>
> [...]
>
> However, this doesn't work, probably because the defined type
> exist only locally within the function.
Okay this works:
def generate_type_dublett(visa_type, ctypes_type):
return visa_type + "=" + ctypes_type + ";" + \
"ViP" + visa_type[2:] + "=POINTER(" + visa_type + ")"
def generate_type_triplett(visa_type, ctypes_type):
return generate_type_dublett(visa_type, ctypes_type) + ";" + \
"ViA" + visa_type[2:] + "=" + "ViP" + visa_type[2:]
exec generate_type_triplett("ViUInt32", "c_ulong" )
...
Not very beautiful, though.
TschÃ,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list
Re: Generating data types automatically
HallÃchen! Thomas Heller <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> I have to generate a lot of data types (for ctypes by the way). >> An example is >> >> ViUInt32 = u_long >> ViPUInt32 = POINTER(ViUInt32) >> ViAUInt32 = ViPUInt32 >> >> [...] > > Others have answered your question already, but I would like to > note one thing: The POINTER() function caches its results, so you > could (and should, imo) write 'POINTER(ViUInt32)' instead > everywhere in your code. Calling POINTER(ViUInt32) *allways* > returns the same type. Actually I don't think that we will use them (ViP...) at all, since we'll make use of "byref" whereever they occur in an args list. But they are in the spec that we try to mimic, and as long as I don't know for sure that nobody uses them, they don't hurt. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
HallÃchen! Fernando <[EMAIL PROTECTED]> writes: > [...] > > [...] Python is going the C++ way: piling feature upon feature, > adding bells and whistles while ignoring or damaging its core > design. I'm new to Python, but I while I skimmed through the "What's new?" of recent versions, I saw the same unfortunate development. Moreover, I dislike the fact that new features are implemented partly in the interpreter and partly in Python itself. It reminds me of TeX/LaTeX, where the enormous flexibility of TeX is used to let it change itself in order to become a LaTeX compiler. However, the underlying constructs are utterly ugly, as are some of Python's features (e.g. __getattr__ and such, and descriptors, in order to get nice class properties). > The new 'perlified' syntax for decorators, Python lost its innocence here: The first really special character, disturbing the former syntax style. Not important, but irritating. > the new static type bonds What is meant by that? > [...] What used to be a cool language will soon be an interpreted > C/C++ without any redeeming value. A real pity... I don't think so, there will be always an enormous difference. But Python seems a little bit chaotic. I looked for a new language for my hobby programming. I used to use Turbo Pascal for 10 years and then C++ for 6 years. A couple of weeks ago, I narrowed my decision to C#, Ruby, and Python. At the moment, I want to go with Python, but you can definitely see that it's the oldest one: Many parts of its syntax are awkward and look like patchwork. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
HallÃchen! Steven Bethard <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> the underlying constructs are utterly ugly, as are some of >> Python's features (e.g. __getattr__ and such, and decorators, in >> order to get nice class properties). > > What do you find ugly about __getattr__? [First, I wanted to say "descriptors" instead of "decorators" (I superseded my post).] The goal is to trigger function calls when attributes are accessed. This is called properties in C# (and maybe in Ruby, too). Python now also has this concept. What I find ugly is that it is not a syntax element. It looks artificially added to the language. In C#, the "set" and "get" methods form with its attribute a syntactic unity. Everything is together, and no "property" function is necessary. >> I looked for a new language for my hobby programming. > > [snip] > >> I want to go with Python, but you can definitely see that it's >> the oldest one: Many parts of its syntax are awkward and look >> like patchwork. > > Interesting. I've never thought that. What parts strike you as > "patchwork"? Well, with a little bit of experience in the field of programming languages, you can see which elements had been added later (ie years after Python's creation). Properties surely would have looked *very* different 15 years ago. There would be keywords for static and class methods, no distinction between Unicode and non-Unicode, and probably no multiple inheritance (which seem to have caused a lot of trouble recently), and no __new__. At first, I was very pleased by Python's syntax (and still I am). Then, after two weeks, I learned about descriptors and metaclasses and such and understood nothing (for the first time in syntax I felt totally lost). The reason why I stay with Python is (apart from the indenting syntax, huge community, and equally huge library) my feeling that the Python developers what to unify the language, even by dropping features. The current snapshot is a transitional Python and thus with some double features. The numerical types and two kinds of classes are examples. I'm very surprised about this, because Python is a production language, but I'm happy, too. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
HallÃchen! "Serge Orlov" <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >>> Interesting. I've never thought that. What parts strike you as >>> "patchwork"? >> >> Well, with a little bit of experience in the field of programming >> languages, you can see which elements had been added later (ie >> years after Python's creation). Properties surely would have >> looked *very* different 15 years ago. >> >> There would be keywords for static and class methods, no >> distinction between Unicode and non-Unicode > > You couldn't do that 15 years ago because there were no Unicode > that time. I've never said that Guido was just too stupid at that time. I only said "but you can definitely see that it's the oldest one". In other words, a Ruby six years older than the real one would have the same problem. And who knows how C# looks like in 10 years. But I want to program now, and this is the current situation in my opinion. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
HallÃchen! [EMAIL PROTECTED] (Paul Boddie) writes: > Torsten Bronger <[EMAIL PROTECTED]> wrote: > >> At first, I was very pleased by Python's syntax (and still I am). >> Then, after two weeks, I learned about descriptors and >> metaclasses and such and understood nothing (for the first time >> in syntax I felt totally lost). > > Well, I've been using Python for almost ten years, and I've > managed to deliberately ignore descriptors and metaclasses quite > successfully. I get the impression that descriptors in particular > are a detail of the low-level implementation that get a > disproportionate level of coverage because of the "hack value" > they can provide (albeit with seemingly inappropriate application > to certain problem areas). I have exactly the same impression, but for me it's the reason why I feel uncomfortable with them. For example, I fear that a skilled package writer could create a module with surprising behaviour by using the magic of these constructs. I don't know Python well enough to get more specific, but flexibility almost always make confusing situations for non-hackers possible. I know that such magic is inavoidable with dynamic languages, but descriptors will be used almost exclusively for properties, and therefore I think it would have been better to hard-wire properties in the interpreter rather than pollute the language with this sort of proto-properties (aka descriptors). TeX is extremely dynamic. It can modify its own scanner in order to become an XML parser or AFM (Adobe font metrics) reader. This is highly confusing for all but those five or six people on this planet who speak TeX fluently. Since I saw raw TeX, I dislike "proto-syntaxes" (or meta-syntaxes if you wish). TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
HallÃchen! Ville Vainio <[EMAIL PROTECTED]> writes: >>>>>> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> writes: > > >>> There would be keywords for static and class methods, no > >>> distinction between Unicode and non-Unicode > > >> You couldn't do that 15 years ago because there were no Unicode > >> that time. > > Torsten> I've never said that Guido was just too stupid at that > Torsten> time. I only said "but you can definitely see that it's > Torsten> the oldest one". In other words, a Ruby six years older > Torsten> than the real one would have the same problem. And who > Torsten> knows how C# looks like in 10 years. > > http://c2.com/cgi/wiki?PythonVsRuby > > seems to suggest that Python has better Unicode support than Ruby. True. When you google for it, you read "Japanese hate Unicode". :-/ Well, then this is an invalid example. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
HallÃchen! "news.sydney.pipenetworks.com" <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> [...] >> >> I have exactly the same impression, but for me it's the reason >> why I feel uncomfortable with them. For example, I fear that a >> skilled package writer could create a module with surprising >> behaviour by using the magic of these constructs. I don't know >> Python well enough to get more specific, but flexibility almost >> always make confusing situations for non-hackers possible. > > In that case I wouldn't worry about the magic which can be done in > python but the magic which can be done in C (which many modules > are written in). The magic in Python must allow the magic in C. > Sometimes I think people complain just to complain. It's interesting though that the concerns I mentioned have influenced so many language designs, isn't it? Look, you may weight the pros and cons differently from me, that's perfectly okay. But don't tell me my thoughts were invalid. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
multiple import of a load of variables
HallÃchen! I have a file that looks a little bit like a C header file with a long list of variables (actually constants) definitions, e.g. VI_ATTR_TIMO = 0x54378 ... Actually I need this in a couple of low-level modules that are imported into the main module, and in the main module itself. They may be also used in the programs that import the main module. Probably it doesn't mean a significant loss of performance anyway since all of it is done only at startup, but I wonder whether it's better to keep everything that depends on this "header" file together so that it must be looked over by Python only once. Is this correct, or is there some sort of implicit optimisation that makes both variants almost equivalent? TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: multiple import of a load of variables
HallÃchen! "Fuzzyman" <[EMAIL PROTECTED]> writes: > [...] > > I'm not entirely clear what you are trying to do The following: "variables.py" looks like this a = 1 b = 2 Then I have helper_a.py, helper_b.py, and helper_c.py which begin with from variables import * And finally, my_module.py starts with from variables import * from helper_a.py import * from helper_c.py import * from helper_c.py import * Now imagine that variables.py contained not only two but hundreds of variables. Is this then still the most effective approach? > *but* - if you import the same module in several places (per > interpreter instance of course) the import will only be done > *once*. The other import statments just make that namespace > available from the namespace that does the import. Even if I use "from"? TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is a JIT compiler faster than a byte-compiler
HallÃchen! "dodoo" <[EMAIL PROTECTED]> writes: > http://www-900.ibm.com/developerworks/cn/linux/sdk/python/charm-28/index_eng.shtml I can't reach it. Is there an alternative URL? TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
HallÃchen! Daniel Silva <[EMAIL PROTECTED]> writes: > Shriram Krishnamurthi has just announced the following elsewhere; it might > be of interest to c.l.s, c.l.f, and c.l.p: > http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html > > > The Fate Of LAMBDA in PLT Scheme v300 > or > Lambda the Ultimate Design Flaw > > About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp > hackers who missed them from their past experience. To this > collection, Scheme added a lexically-scoped, properly-functioning > LAMBDA. But, despite of the PR value of anything with Guy > Steele's name associated with it, we think these features should > be cut from PLT Scheme v300. > > [...] The whole text seems to be a variant of <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: goto statement
HallÃchen! Maxim Kasimov <[EMAIL PROTECTED]> writes: > [...] > > WOW, just greate! ... but i'd like to relax at some more > interesting way than to comment each of rows Then just use a good editor. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python does *SLICING* the way it does??
HallÃchen! [EMAIL PROTECTED] (Nick Efford) writes: > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Many people I know ask why Python does slicing the way it does. > >> Can anyone /please/ give me a good defense/justification??? > >> I'm referring to why mystring[:4] gives me elements 0, 1, 2 and 3 >> but *NOT* mystring[4] (5th element). > > mystring[:4] can be read as "the first four characters of > mystring". If it included mystring[4], you'd have to read it as > "the first five characters of mystring", which wouldn't match the > appearance of '4' in the slice. > > [...] > > It all makes perfect sense when you look at it this way! Well, also in my experience every variant has its warts. You'll never avoid the "i+1" or "i-1" expressions in your indices or loops (or your mind ;). It's interesting to muse about a language that starts at "1" for all arrays and strings, as some more or less obsolete languages do. I think this is more intuitive, since most people (including mathematicians) start counting at "1". The reason for starting at "0" is easier memory address calculation, so nothing for really high level languages. But most programmers are used to do it the Python (and most other languages) way, so this opportunity has been missed for good. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python does *SLICING* the way it does??
HallÃchen! Antoon Pardon <[EMAIL PROTECTED]> writes: > Op 2005-04-20, Torsten Bronger schreef <[EMAIL PROTECTED]>: > >> [...] >> >> It's interesting to muse about a language that starts at "1" for >> all arrays and strings, as some more or less obsolete languages >> do. I think this is more intuitive, since most people (including >> mathematicians) start counting at "1". The reason for starting >> at "0" is easier memory address calculation, so nothing for >> really high level languages. > > Personnaly I would like to have the choice. Sometimes I prefer to > start at 0, sometimes at 1 and other times at -13 or +7. In HTBasic you have the choice between 0 and 1; there is a global source code directive for it. However, hardly anybody really wants to use HTBasic. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python does *SLICING* the way it does??
HallÃchen! Bernhard Herzog <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >> It's interesting to muse about a language that starts at "1" for >> all arrays and strings, as some more or less obsolete languages >> do. I think this is more intuitive, since most people (including >> mathematicians) start counting at "1". The reason for starting >> at "0" is easier memory address calculation, so nothing for >> really high level languages. > > There are very good reasons for half-open intervals and starting > at 0 apart from memory organization. Dijkstra explained this > quite well in > http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF I see only one argument there: "Inclusion of the upper bound would then force the latter to be unnatural by the time the sequence has shrunk to the empty one." While this surely is unaesthetical, I don't think that one should optimise syntax according to this very special case. Besides, no language I know of has probems with negative values. Well, and the argument for "0" derives from that, according to Dijkstra. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python does *SLICING* the way it does??
HallÃchen! Bernhard Herzog <[EMAIL PROTECTED]> writes: > Torsten Bronger <[EMAIL PROTECTED]> writes: > >>> http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF >> >> I see only one argument there: "Inclusion of the upper bound >> would then force the latter to be unnatural by the time the >> sequence has shrunk to the empty one." [...] > > The other main argument for startig at 0 is that if you do not > include the upper bound and start at 1 then the indices i of a > sequence of N values are 1 <= i < N + 1 which is not as nice as 0 > <= i < N. opportunity for an off by one error. The alternative is starting with 1 and using "lower <= i <= upper". (Dijkstra's second choice.) > Then there's also that, starting at 0, "an element's ordinal > (subscript) equals the number of elements preceding it in the > sequence." Granted, but you trade such elegancies for other uglinesses. A couple of times I changed the lower limit of some data structure from 0 to 1 or vice versa, and ended up exchanging a "+1" here for a "-1" there. It's a matter of what you are accustomed to, I suspect. We (programmers) think with the 0-notation, but non-spoiled minds probably not. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
ANN: JuliaBase -- LIMS for specimen-based research published as open source
We are proud to announce that our in-house samples database solution is now published as open source software (AGPL). It is a Python/Django-based framework for creating Web databases for samples. So far, it is used successfully by four in-house departments. For all the details and a demo, visit <http://www.juliabase.org>. The highlights include: - maximal flexibility for being adapted perfectly to your production and measurement setups, and to your workflows; (that's the reason why it is a programming framework rather than a turnkey application) - keeps track of samples across sample splits - support for pre-evaluating raw data and creating plots - arbitrarily complex searches made easy, e.g. “find all samples with infrared measurements, deposited together with a sample on glass substrate with a conductivity greater than 10^-6 S/cm; oh yes, and only from this year and made by John” - export to spreadsheets - automatic lab notebooks - server interaction with other programs through an HTTP/JSON interface JuliaBase's sources include an "example institute" that programmers can use as a starting point. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
Hallöchen! Alan Bawden writes: > [...] > > You lost me right here. If list equality is determined by > comparing lists element-by-element, and the second element of old > is _not_ equal to the second element of data, then why should old > and data be equal? I think Python first tests for identity, and falls back to equality (or the other way round). This behaviour is questionable in my opinion. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
Hallöchen! Torsten Bronger writes: > Alan Bawden writes: > >> [...] >> >> You lost me right here. If list equality is determined by >> comparing lists element-by-element, and the second element of old >> is _not_ equal to the second element of data, then why should old >> and data be equal? > > I think Python first tests for identity, and falls back to > equality (or the other way round). This behaviour is questionable > in my opinion. See also https://mail.python.org/pipermail/python-bugs-list/2006-August/035010.html Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Hallöchen! Larry Martell writes: > On Fri, Jul 18, 2014 at 8:19 AM, Grant Edwards > wrote: > >> But, I do know that a decent, civilized person just doesn't make >> insulting comments like that about somebody else's work even if >> it is true (which I very much doubt). > > Now, _that's_ funny. This is the internet. If you can't stand the > heat get out of the kitchen. Now, _that's_ funny. This is the internet. If you can't stand people who can't stand the heat get out of the kitchen. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Hallöchen! Matthias Kaeppler <[EMAIL PROTECTED]> writes: > [...] > > Another thing which is really bugging me about this whole > dynamically typing thing is that it seems very error prone to me: > > foo = "some string!" > > # ... > > if (something_fubar): >fo = "another string" > > Oops, the last 'o' slipped, now we have a different object and the > interpreter will happily continue executing the flawed program. > > I really see issues with this, can anyone comment on this who has > been working with Python more than just a day (like me)? There are even a couple of further checks which don't happen (explicitly) in a dynamic language like Python, and which do happen in most statically typed languages like C++. And yes, they are a source of programming mistakes. However, in everyday programming you don't feel this. I don't make more difficult-to-find mistakes in Python than I used to make in my C++ code. But what you do feel is the additional freedom that the dynamic approach gives to you. Basically it's a matter of taste and purpose whether you want to be controlled heavily or not. Python is particularly liberal, which I appreciate very much. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Binary representation of floating point numbers
Hallöchen! Sorry for the late response, but the subject didn't catch my attention ... Mike Meyer <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > >> In float mode, the instrument returns a sequence of bits that are >> exactly the ieee754 number in the case of floats, or just the >> flags in the case of flags. PyVisa, when set to float mode, will >> convert everything to float, because it is unaware apriori that >> one of the fields returned is actually intended to be used as >> binary flags. > > You need to get PyVisa to return strings of bytes to you. PyVISA does so when calling the read_raw() method. > [...] > > Struct is the right tool for the job. Exactly. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
PIL: match for ImageMagick's display -ping
Hallöchen! I have to extract the dimensions of many bitmap files. An old Bash script did it with ImageMagick's "display -ping ...". "-ping" means that it extracts the image dimensions efficiently. I suspect it simply doesn't read the image itself. Now the Bash script has been transformed into Python+PIL. Is there a way to get the dimensions equally efficient here, or does the PIL even do this optimisation implicitly since I never access the image bitmap itself? ceter Thank you! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646 (See http://ime.webhop.org for Jabber, MSN, etc.) -- http://mail.python.org/mailman/listinfo/python-list
PIL: match for ImageMagick's display -ping
Hallöchen! I have to extract the dimensions of many bitmap files. An old Bash script did it with ImageMagick's "display -ping ...". "-ping" means that it extracts the image dimensions efficiently. I suspect it simply doesn't read the image itself. Now the Bash script has been transformed into Python+PIL. Is there a way to get the dimensions equally efficient here, or does the PIL even do this optimisation implicitly since I never access the image bitmap itself? Thank you! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646 (See http://ime.webhop.org for Jabber, MSN, etc.) -- http://mail.python.org/mailman/listinfo/python-list
ANN: PyVISA 1.1 -- GPIB, USB, RS232 instrument control
Hallöchen! At http://pyvisa.sourceforge.net you can find information about the PyVISA package. It realises Python bindings for the VISA library functions, which enables you to control GPIB, USB, and RS232-serial measurement devices via Python. Yesterday I released version 1.1, which works much better together with older VISA implementations. Moreover, we finally have reports from Linux users. They successfully used PyVISA with Linux + NI/Tektronix GPIB hardware. Tschö, Torsten. F'up to comp.lang.python -- Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646 (See http://ime.webhop.org for Jabber, MSN, etc.) -- http://mail.python.org/mailman/listinfo/python-list
ANN: PyVISA 1.0 -- GPIB, USB, RS232 instrument control
Hallöchen! At http://pyvisa.sourceforge.net you can find information about the PyVISA package. It realises Python bindings for the VISA library functions, which enables you to control GPIB, USB, and RS232-serial measurement devices via Python. Today I released version 1.0. If you have v0.9.7 of last september already, you needn't download it because it contains only minor improvements in the documentation. However, since I've received a couple of positive reports about successful use of PyVISA (and no negatives), I finally dare to jump to 1.0 and declare it stable. Tschö, Torsten. F'up to comp.lang.python -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Installing packages in /usr/local
Hallöchen! I use the Suse 10.0 RPM of Python 2.4. Unfortunately, it doesn't seem to look for packages in /usr/local because "prefix" and "exec_prefix" in site.py are the same (namely usr/). I have my own packages in /usr/local/lib/python/site-packages. (Due to easier backup, I don't want to change that.) What is the best way to make Python look there? I tried PYTHONPATH but I had trouble with a Python cron job which didn't have the proper environment. I could edit site.py manually, however, I wonder whether there is a cleaner way? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Evil, evil wxPython (and a glimmer of hope)
Hallöchen! "Fuzzyman" <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > >> [EMAIL PROTECTED] wrote: >> >> [...] >> >> Ok, after brief eyeballing & experimenting, it appears that Wax >> is just what I was looking for. The code is simple, concise and >> trivially understandable, the level of wrapping seems about >> right, and examples are helpful. >> >> [...] > > That's good news. I'm about to start using Wax on a couple of > small(ish) projects - so it's nice to know about other users. Has Wax exceeded the critical mass so that one can be quite certain that it will still be maintained, say, next year? (Sincere question since I don't know.) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! Roy Smith <[EMAIL PROTECTED]> writes: > [...] > > It's been a while since I've dabbled in lisp, but my recollection > is that the plethora of different implementations has also meant > that portability is a fantasy. > > I dread the day that competing Python implementations spring up. Even worse: In one of them Microsoft is involved. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > Alexander Schmolck a écrit : > >> Bruno Desthuilliers <[EMAIL PROTECTED]> writes: >> >>> [...] >>> >>> It's not a "scripting" language, and it's not interpreted. >> >> Of course it is. What do you think happens to the bytecode? > > Ok, then what do you think happens to 'machine' code ? > > "interpreted" usually means "no compilation, all parsing etc > redone at each execution", which is not the case with a > bytecode/vm based implementation. That sounds like an implementation feature rather than a language feature. Besides, it's not a very sensible distinction in my opinion. Much better is to think about the structure of the interpreting machine. I'm not a CS person (only a physicist) but if you *need* a bytecode interpreter on top of the CPU interpretation, it's an interpreted language to me. I've had such a discussion about TeX already, and my personal conclusion was that you can defend almost any opinion in that area. However, one should ensure that the definitions make a pragmatic and useful distinction. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen!
bruno at modulix <[EMAIL PROTECTED]> writes:
> Torsten Bronger wrote:
>
>> [...]
>>
>> I've had such a discussion about TeX already, and my personal
>> conclusion was that you can defend almost any opinion in that
>> area. However, one should ensure that the definitions make a
>> pragmatic and useful distinction.
>
> The only pragmatic and useful distinction I can see here is
> between languages that have to re-parse the whole source for each
> and every executions ('interpreted') and languages that don't.
Well, I think that it's fair to say that there are by principle deep
run time differences between CPython and, say, a typical
C++-compiled program. Your definition would not reproduce that. I
think it's also fair to say that these differences should be known
if somebody tries to find the best tool for a job. After all, they
include advantages, too.
My definiton would be that an interpreted language has in its
typical implementation an interpreting layer necessary for typical
hardware. Of couse, now we could discuss what is "typical",
however, in practice one would know it, I think. In case of Python:
CPython and all important modern processors.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! Carl Friedrich Bolz <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> [...] >> >> My definiton would be that an interpreted language has in its >> typical implementation an interpreting layer necessary for >> typical hardware. Of couse, now we could discuss what is >> "typical", however, in practice one would know it, I think. In >> case of Python: CPython and all important modern processors. > > Well, if we take any modern Intel/AMD chip (which could be > described as "typical), a C++ program would fit the "interpreted" > definition, since the processor does not execute the machine code > directly but rather breaks it down into smaller microcode > instruction -- a process that could be described as intepretation. This is an interpreting layer within the hardware, not necessary for it. > Another problem with the definition: what would you call a C++ > program that is running on top of an emulator? Compiled. I said "necessary for typical hardware". > [...] I think that the disctinction between "interpreted" and > "compiled" (whatever both means) is really just not sensible at > all. The question is whether such features have to be considered when choosing the right tool for a task. I think, yes. Whereas C is very close to the fastest code you can get because it works very closely to how the machine itself works, Python can well be one or one and a half orders of magnitude farther away. No problem since you can get the best of both worlds but: You must be aware of it. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! [EMAIL PROTECTED] (Cameron Laird) writes: > In article <[EMAIL PROTECTED]>, I wondered: > >> [...] Do you truly believe that fewer people would use Python if >> its execution were faster? > > I think I can answer my own question: yes. Since posting, I came > across a different follow-up where Alexander explains that he sees > healthy elements of the Python ethos--focus on a reliable, widely- > used library, willingness to make Python-C partnerships, and so > on--as results at least in part of early acceptance of Python as > intrinsically slow. That's too interesting an argument for me to > respond without more thought. I was rather stunned, too, when I read his line of thought. Nevertheless, I think it's not pointless, albeit formulated in an awkward way. Of course, Python has not been deliberately slowed down. I don't know how strong the effect is that a language design which doesn't allow for (easy to implement) fast execution speed makes you write cleaner code, however, I must say that I feel so, too. When I came from C++ to Python I had to find my Pythonic style, and part of it was that I threw away those ubiquitous little optimisations and concentrated on formulating my idea in a clear and expressive way. By the way, this is my main concern about optional static typing: It may change the target group, i.e. it may move Python closer to those applications where speed really matters, which again would have an effect on what will be considered Pythonic. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! Peter Mayne <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> My definiton would be that an interpreted language has in its >> typical implementation an interpreting layer necessary for typical >> hardware. Of couse, now we could discuss what is "typical", >> however, in practice one would know it, I think. In case of Python: >> CPython and all important modern processors. > > In a previous century, I used something called UCSD Pascal, which at > the time was a typical implementation of Pascal. Not "a" typical implementation but "its". > [...] > > And, as someone in this thread has pointed out, it is likely that > your important modern (x86) processor is not natively executing > your x86 code, and indeed meets your definition of having "in its > typical implementation an interpreting layer necessary for typical > hardware". Only if you deliberately misunderstand me. > Another example: is Java the bytecode, which is compiled from Java > the language, interpreted or not? Even when the HotSpot JIT cuts > in? It is partly interpreted and partly compiled. That's why it's faster than Python. > [...] > > Personally, in practice I don't care, so don't ask me. Ponder on > getting angels to dance on the head of a pin before you worry > about whether the dance can be interpreted or not. I agree that the term "interpreted" is bad Python advocacy because its implications are often misunderstood. However, I think that it's fair to make a distiction between compiled and interpreted languages because it may affect one's decision for one or the other. Although I'm surely not ingenious, I can make this distinction. The reason why Python is slower than C is because there is an interpreting layer that C doesn't have. And the reason for this is that Python's nature is incompatible with today's CPUs (which was a deliberate and advantageous design decision). I'm sure that a willing CS person could define this more clearly. Anyway, if we drop "scripting" and drop "interpreted", what do you want to tell people asking why Python is so slow? Because it is dynamic? ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Wed, 22 Feb 2006 10:15:21 +0100, Torsten Bronger wrote: > >>> And, as someone in this thread has pointed out, it is likely >>> that your important modern (x86) processor is not natively >>> executing your x86 code, and indeed meets your definition of >>> having "in its typical implementation an interpreting layer >>> necessary for typical hardware". >> >> Only if you deliberately misunderstand me. > > If the words you choose to use have implications which you failed > to realise before saying them, don't blame the reader for spotting > those implications. To me it sounds like "Some hardware is harder than other". >>> Another example: is Java the bytecode, which is compiled from >>> Java the language, interpreted or not? Even when the HotSpot JIT >>> cuts in? >> >> It is partly interpreted and partly compiled. That's why it's >> faster than Python. > > But Python is partly interpreted and partly compiled too It's byte-compiled for a VM, that's not the same, and you know it. Sorry but I think we've exchanged all arguments that are important. Any further comment from me would be redundant, so I leave it. > [...] > >> [...] However, I think that it's fair to make a distiction >> between compiled and interpreted languages because it may affect >> one's decision for one or the other. [...] > > Would you rather use a blindingly fast interpreted language, or a > slow-as-continental drift compiled one? > > This isn't a rhetorical question. [example] > > I'm sure that's hardly the only example of a speedy interpreted > language beating a glacial compiled one. I agree that the distinction between interpreted and compiled languages is not as clear as between positiv and negative numbers, however, neither anybody has claimed that so far, nor it is necessary. It must be *practical*, i.e. a useful rule of thumb for decision making. If you really know all implications (pros and cons) of interpreted languages, it's are very useful rule in my opinion. > [...] > > But seriously... why not tell them the truth? Python is slower > than some other languages because optimization for execution speed > has not been the primary focus of Python's development. If you > tell them that Python is slow because it is interpreted, they will > believe that Python will always be slow. I don't think that "Python's developers don't focus primarily on speed" sounds better than "Python is interpreted". Both suggests that you must circumvent problems with Python's execution speed (we all know that this works and how) because you can't count on language improvements. Even worse, evading "interpreted" may sound like an euphemism and as if you want to hide unloved implementation features, depending on your audience. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Wed, 22 Feb 2006 10:15:21 +0100, Torsten Bronger wrote: > >>> And, as someone in this thread has pointed out, it is likely >>> that your important modern (x86) processor is not natively >>> executing your x86 code, and indeed meets your definition of >>> having "in its typical implementation an interpreting layer >>> necessary for typical hardware". >> >> Only if you deliberately misunderstand me. > > If the words you choose to use have implications which you failed > to realise before saying them, don't blame the reader for spotting > those implications. To me it sounds like "Some hardware is harder than other". >>> Another example: is Java the bytecode, which is compiled from >>> Java the language, interpreted or not? Even when the HotSpot JIT >>> cuts in? >> >> It is partly interpreted and partly compiled. That's why it's >> faster than Python. > > But Python is partly interpreted and partly compiled too It's byte-compiled for a VM, that's not the same, and you know it. Sorry but I think we've exchanged all arguments that are important. Any further comment from me would be redundant, so I leave it. > [...] > >> [...] However, I think that it's fair to make a distiction >> between compiled and interpreted languages because it may affect >> one's decision for one or the other. [...] > > Would you rather use a blindingly fast interpreted language, or a > slow-as-continental drift compiled one? > > This isn't a rhetorical question. [example] > > I'm sure that's hardly the only example of a speedy interpreted > language beating a glacial compiled one. I agree that the distinction between interpreted and compiled languages is not as clear as between positiv and negative numbers, however, neither anybody has claimed that so far, nor it is necessary. It must be *practical*, i.e. a useful rule of thumb for decision making. If you really know all implications (pros and cons) of interpreted languages, it's are very useful rule in my opinion. > [...] > > But seriously... why not tell them the truth? Python is slower > than some other languages because optimization for execution speed > has not been the primary focus of Python's development. If you > tell them that Python is slow because it is interpreted, they will > believe that Python will always be slow. I don't think that "Python's developers don't focus primarily on speed" sounds better than "Python is interpreted". Both suggests that you must circumvent problems with Python's execution speed (we all know that this works and how) because you can't count on language improvements. Even worse, evading "interpreted" may sound like an euphemism and as if you want to hide unloved implementation features, depending on your audience. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! "Paul Boddie" <[EMAIL PROTECTED]> writes: > Kay Schluehr wrote: > >> I would say yes, it is still "proper Python" in that each RPython >> program is also a CPython program. > > I suppose it depends on which direction you're coming from, in > that many Python programs just wouldn't be able to run in > RPython. But then I can understand the convenience of having a > subset of Python that is executable by CPython, but which can also > be inspected and processed for other purposes, and whose programs > maintain their semantics in both situations. I'm still afraid of the following scenario: Eventually, people might regard "RPython plus type declarations" (or something similar) as first-class Python because it's faster and runs on more implementations, so they try to stick to it. So effectively you would have changed Python. Maybe I misunderstood something because I could not follow all of Kay's text but I think one should not change Python or create a look-alike to allow for better implementations. The language should fit my brain rather than an implementation. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! Peter Mayne <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >>>>> Another example: is Java the bytecode, which is compiled from >>>>> Java the language, interpreted or not? Even when the HotSpot >>>>> JIT cuts in? >>>> >>>> It is partly interpreted and partly compiled. That's why it's >>>> faster than Python. >>> >>> But Python is partly interpreted and partly compiled too >> >> It's byte-compiled for a VM, that's not the same, and you know >> it. > > Do you mean that Python is byte-compiled for a VM, and not Java, > or vice-versa? I mean "Python is byte-compiled for a VM". >> I agree that the distinction between interpreted and compiled >> languages is not as clear as between positiv and negative >> numbers, however, neither anybody has claimed that so far, nor it >> is necessary. It must be *practical*, i.e. a useful rule of >> thumb for decision making. If you really know all implications >> (pros and cons) of interpreted languages, it's are very useful >> rule in my opinion. > > So what kind of practical decisions are you trying to make? Which language should I use for my project. > What kind of implications are useful to you? Speed, ease of programming, necessity to learn/use a secondary language, issues with distributing, portability. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Hallöchen! "Kay Schluehr" <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> [...] >> >> I'm still afraid of the following scenario: Eventually, people >> might regard "RPython plus type declarations" (or something >> similar) as first-class Python because it's faster and runs on >> more implementations, so they try to stick to it. So effectively >> you would have changed Python. > > I wonder why you believe that it would run on more platforms? I meant the following: RPython programs will run on all Python implementations, *plus* the environments where only RPython is possible. > This assertion is justifiable with regard of tiny target hardware > - but else? I do think that "RPython++" could be a viable > replacement for C as a systems programming language BECAUSE it is > connected closely to Python. Ah, okay. This was a vision that I didn't understand from previous postings. > [...] > >> Maybe I misunderstood something because I could not follow all of >> Kay's text but I think one should not change Python or create a >> look-alike to allow for better implementations. The language >> should fit my brain rather than an implementation. > > It should first of all fit the diversity of a programmers needs. C > was never considered as a hostile brother of Python so why should > it be Pythons own son? Because I think it would be tempting to add all necessary declations in order to make one's code working with the fastest Python implementation available. After all, mostly we know the types, although currently we don't declare them. It's a purely psychological issue: People want to create "valueable" code, pythonistas even more so, ignoring that eventually it may turn out that this was not a good idea. Current Python *forces* us to keep the code as flexible as possible. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Python as an extension language
Hallöchen! I'd like to use Python as an extension language for a C++ program. I.e., the user starts my program and gives a python script, either by file name or via stdin. The python script triggers a couple of function calls within the C++ program, and afterwards my program exits. I already know how to do that in principle. My only concern is distributing the thing, especially for the Windows platform. Is it possible to create a bundle of my program and a light-weight Python interpreter, so that installation is easy and disk usage relatively small? The Python scripts are not supposed to import modules after all, at least not explicitly. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as an extension language
Hallöchen! Sybren Stuvel <[EMAIL PROTECTED]> writes: > Torsten Bronger enlightened us with: > >> I already know how to do that in principle. My only concern is >> distributing the thing, especially for the Windows platform. > > Check out distutils and py2exe. I know that py2exe can convert a Python script into an EXE file, however, I have no Python script. I only have C++ source code, and I'd like to avoid saying, "well, please install my little EXE and this 10MB Python MSI for scripting it". Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why I chose Python over Ruby
Hallöchen! Marcin Mielżyński <[EMAIL PROTECTED]> writes: > Roy Smith wrote: > >> In article <[EMAIL PROTECTED]>, >> Bil Kleb <[EMAIL PROTECTED]> wrote: >> >>> The parensless calls also allow one to write beautiful DSLs with >>> Ruby. >> >> What's a DSL? > > Domain Specific Language. It is easy to tweak Rubys syntax and > semantics into something that looks like another language designed > for a specific task. Yes, however, this is also true for Python in my opinion. It boils down to a matter of taste. I deliberately left C++ one year ago. I looked at various alternatives. After a short time I concentrated on Ruby v. Python. I read a lot of language comparisons (with both biases). Well, my conclusion was: All "this language has this, and this language has that" is pretty pointless because both languages are very similar and equally sophisticated. I found the appearance of Python code more appealing, that was all. The "fits my brain" argument is much more useful than all discussions about things like continuatons or multiple inheritance. The actual reason to choose Python was its set of tools, modules, and Usenet participants. I don't want to do something manually in Ruby which I could have had ready-for-use in Python just for infinitesimally nicer syntax. Probably I'm just too old for language adventures. Ruby might be good enough for me in three years but I want to have the full fun now. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why I chose Python over Ruby
Hallöchen! Xavier Morel <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> Yes, however, this is also true for Python in my opinion. > > Ruby's ability to generate DSLs is an order of magnitude better > than Python's at least. If good DSL includes morphing into another language, this may be true. However, I think that a good DSL just solves the problem well, even if it still looks like the original by and large. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Graphing Utilities.
HallÃchen! Fernando Perez <[EMAIL PROTECTED]> writes: > [...] > > And I'd also second the matplotlib suggestion, to which I've by > now fully switched after years of faithful gnuplot usage. > Matplotlib is very good, has an active development community, and > it is designed from the ground up not only as a library for > rendering plots to screen/disk, but also for embedding into guis > (with support for Tk, WX, GTK, QT and FLTK). Why not for Gnuplot, by the way? On sceen, matplotlib looks extremely good, however, I still need Gnuplot for the hardcopy version[*]. It *seems* to me that the programming interfaces are quite different, so a Gnuplot backend for matplotlib would be helpful for me. TschÃ, Torsten. [*] because of the "pslatex" backend, which means that the plot is typeset by the same LaTeX run as your document --> consistent fonts, TeX-quality formulae -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Graphing Utilities.
HallÃchen!
Bill Mill <[EMAIL PROTECTED]> writes:
> On 5/11/05, Torsten Bronger <[EMAIL PROTECTED]> wrote:
>
>> Fernando Perez <[EMAIL PROTECTED]> writes:
>>
>>> [...]
>>>
>>> [...] Matplotlib is very good, has an active development
>>> community, and it is designed from the ground up not only as a
>>> library for rendering plots to screen/disk, but also for
>>> embedding into guis (with support for Tk, WX, GTK, QT and FLTK).
>>
>> Why not for Gnuplot, by the way?
>>
>> On sceen, matplotlib looks extremely good, however, I still need
>> Gnuplot for the hardcopy version[*]. It *seems* to me that the
>> programming interfaces are quite different, so a Gnuplot backend
>> for matplotlib would be helpful for me.
>
> By hardcopy version, I assume you mean Postscript?
Not really. Gnuplot's output is LaTeX with a couple of native
Postscript directives inbetween. It's inluded into my document with
"\input plot.plt" rather than "\includegraphics{plot.eps}".
I mentioned the advantages of this approach in the footnote:
> [...]
>
>> [*] because of the "pslatex" backend, which means that the plot
>> is typeset by the same LaTeX run as your document --> consistent
>> fonts, TeX-quality formulae
TschÃ,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Graphing Utilities.
HallÃchen! Robert Kern <[EMAIL PROTECTED]> writes: > [...] > > A pslatex backend certainly would be interesting. A Gnuplot > backend would probably not be feasible. Does it expose its raw > drawing operations? Probably not raw enough, but I don't know how basic matplotlib wants it to be. You could switch the axes off and draw everything as lines using plot coordinates, but I don't know how sensible this would be. On the other hand, the "pslatex" output of Gnuplot is one of the very few things that hold me there. If matplotlib produced something equivalent, (at least) I wouldn't call for a Gnuplot backend anymore. TschÃ, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
