Re: nokia pys60 contacts + calendar
Hi, "Programming with Python for Series 60 Platform" http://eugen.leitl.org/Programming_with_Python.pdf "Python for Series 60 Platform - API Reference" PythonForS60_doc_1_3_17.pdf should answer your questions Torsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Programing Art or Science?
Xah Lee wrote: > So, is programing a art or science? is it art or science? I really > need to know. Sience? Almost never. It's handcraft. Seldom, in very rare cases, it's true art for a very limited audience, mostly it's routine, and in many cases it's also idiocy. T.M. -- http://mail.python.org/mailman/listinfo/python-list
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: [email protected] 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
use a file as a database, access rights
Hi, i'd like to write a script that makes use of a database. It would be great if the database would store all its data in a file, that would be great for data exchange. It would also be great if i could use SQL, as i have some experience in that. Also, i NEED access rights to certain parts of the database. Several people should work on it and NEED to have different access rights. Can anybody give me some recommendations on what to use? Thanks for any hints, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: use a file as a database, access rights
Hi, sorry for being unclear and thanks for your answers. Yes, i'd like to use a flat-file database AND access rights. One way i thought of would be to handle the access rights in the script that i write. But to let some other module handle it would also be great. If for example i could embed some SQL database and tell it to store all its tables in ONE FILE it would be quite easy to do. I want to write that application cross-platform, at least Win32 AND Linux. Best regards, Torsten. > Torsten, > > Please explain the environment you are planning to use - Operating > System, whether you have full control of the machine that runs the > database, how many users?. > > If you are using Windows and if your needs are simple, you can use > Access as it has some simple access control that can be setup. > > Also, the part about "database would store all its data in a file" is > not very clear. Are you wanting to use a flat-file database and also > have security implemented in it? If you are on linux/*BSD machine, > consider using a real database. > > Fine access control can be implemented in your application (e.g. only > the creator of a record and his/her superiors can edit it, all others > view it) > > Please send more details to receive useful recommendations. > Thanks, > --Kartic -- http://mail.python.org/mailman/listinfo/python-list
SuSE 9.1: updating to python-2.4
Hi, along with my distribution SuSE 9.1 came python 2.3.3. I'd like to update to 2.4 now, is this an easy thing to do or will lots of installed modules refuse to work then? Is there an easy way to find out what i need to update? Thanks for any hints, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Referenz auf Variable an Funktion Ãbergeben?
Hallo, ich mÃchte eine Funktion schreiben, der ich eine Referenz auf einen String Ãbergeben kann und die dann einige Ãnderungen am String vornimmt. In Perl wÃrde ich also ein \$string Ãbergeben und in der Funktion auf $$string zugreifen. Geht sowas auch in Python? Ich habe von "global" gelesen, das scheint dem was ich suche am nÃchsten zu kommen, allerdings trifft es das Problem auch nicht, da ich von einer Unterfunktion aus eine Unterfunktion aufrufen mÃchte, also tief verschachtelt. Und global greift nach meinem VerstÃndnis auf den ganz globalen Namensraum zu und nicht auf den der aufrufenden Funktion. Geht sowas vielleicht mit weakref? Danke fÃr Tipps, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
reference or pointer to some object?
Hi,
i'd like to pass a reference or a pointer to an object
to a function. The function should then change the
object and the changes should be visible in the calling
function.
In perl this would be something like:
sub func {
$ref = shift;
$$ref += 123; # change
}
$a = 1;
func(\$a);
is something like this possible in python?
The keyword "global" does NOT fit this purpose to
my understanding as it only makes the variables of
the UPPERMOST level visible, not the ones of ONE
calling level above.
Is this somehow possible with weakref?
I don't want to pass the parameter to a function and
then return a changed value.
Is there some other mechanism in python available to
achieve a behaviour like this?
Thanks for any hints,
Torsten.
--
http://mail.python.org/mailman/listinfo/python-list
Re: reference or pointer to some object?
Hi, thank you all for your explanations. I still wonder why a concept like "references" was not implemented in Python. I think it is (even if small) an overhead to wrap an object in a list or a dictionary. Isn't it possible to extend Python in a way to use real references? Or isn't that regarded as necessary? Thanks for any hints, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: reference or pointer to some object?
Hi, > Could you give us a more concrete use case? My suspicion is that > anything complicated enough to be passed to a method to be modified will > probably be more than a simple int, float, str or tuple... In which > case, it will probably have methods to allow you to update it... yes, to be more explicit: I'm quite new to python and i wrote a small function that does a hexdump of a string. That string can be quite large, so i suspected a large overhead when the string would be copied and handed over to the function. But i think my understanding was wrong (though it is not yet clear). If i hand over a large string to a function and the function had the possibility to change it, wouldn't that mean that it is necessary to hand over a _copy_ of the string? Else, how could it be immutable? Thinking about all this i came to the idea "How would i write a function that changes a string with not much overhead?". def func(s): change s in some way, remove all newlines, replace some charaters by others, ... return s s = func(s) This seems to be a way to go, but it becomes messy if i hand over lots of parameters and expect some more return functions. Maybe it is because i did lots of perl programming, but func(\$s) looks easier to me. > In my case, rather than your original example, which you want to look > something like: > > def func(x): > x += 123 > > x = 5 > func(x) > > I'd just write: > > x = 5 > x += 123 You're right, of course. I'm sorry the second example is still a bit constructed, but i came across it by writing the hexdump utility and wanted to reduce overhead. Best regards, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: reference or pointer to some object?
Hi, thank you all for your explanations. That's really great and helps me a lot. Thanks, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Py_Object* Py_BuildValue, Py_INCREF necessary?
Hi, when i write an extension module in C and return a Py_Object* that i've built with Py_BuildValue, do i need to use Py_INCREF on that before i return it to python from my extension module or not? Thanks for hints, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
supplying constants in an extension module
Hi, i write an extension module in C at the moment. I want to define some constants (integer mainly, but maybe also some strings). How do i do that best within this extension module in C? Do i supply them as RO attributes? What's the best way for it? Thanks for hints, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
extension module, thread safety?
Hi, i write an extension module in C at the moment. This module does some work on some own data types that consist of some values. The functions that can change the data are written in C. The question came up if this is by itself thread safe, if some two or more threads try to change these data types, are the C functions by themselves are "atomic" or can they be interrupted be the perl interpreter and then (data types are in some inconsistent half-changed state) another function that works on these data is called? Thanks for hints, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
import hook, overwrite import?
Hi, is there some description available to overwrite the import hook? By googling i found out so far that i need to overwrite __builtins__.__import__ with something else. Can i also do this with a C function that is provided when using an embedded python interpreter? So my own C program provides this and when linking with python.lib the function is overwritten? Or is there some extension hook? Does this also handle "from module import *" not only the normal "import module"? Thanks for any hints, Torsten. -- 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
where's "import" in the C sources?
Hi, i tried to find the file and line in the C sources of python where the command "import" is implemented. Can anybody give me some hint on this? Thanks, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: where's "import" in the C sources?
Hi David, thanks for the explanation. That is very helpful to me. Best regards, Torsten. David Bolen wrote: > Torsten Mohr <[EMAIL PROTECTED]> writes: > >> i tried to find the file and line in the C sources of python >> where the command "import" is implemented. Can anybody give >> me some hint on this? > > Well, there are several levels, depending on what you are looking for. > The literal "import" syntax in a source module is translated by the > Python compiler to various IMPORT_* bytecodes, which are processed in > the main interpreter loop (see ceval.c). > > They all basically bubble down to making use of the builtin __import__ > method, which is obtained from the builtin module defined in > bltinmodule.c. > > That in turn makes use of the import processing module whose code can > be found in import.c - which is the same source that also implements > the "imp" module to provide lower layer access to to the import > internals. > > Now, when it comes to physically loading in a module, Python source > and compiled modules are handled by import (well, not the compiling > part), but dynamically loaded extension modules are OS specific. You > can find the handling of such extension modules in OS-specific source > files dynload_*.c (e.g., dynload_win.c for Windows). > > All of these files can be found in the dist/src/Python directory in > the Python source tree. > > -- David -- http://mail.python.org/mailman/listinfo/python-list
GUI with sophisticated Table support
Hi, i want to write an application where i need a Table to display some values. The table should display a list of objects, so to say, a column for each attribute of the object. I'd also like the user to be able to change the width of each column, like in Excel. I'd prefer to use Tkinter, but i think it can't do all that. Is there a way for Tkinter to handle this? If not, what other GUI can do that? (wxPython?) Thanks for hints, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
build a static executable program with python
Hi, i'd like to build an executable file that is linked with a python library and executes a script via PyRun_SimpleString or similar functions. Is there a static library of python available, so the users don't need to install python? What about DLL modules, do i just need to compile them as a static lib, link them together with my program and call their init function? What about python modules, can i just use a tool like "freeze" or "py2exe" to break up the import hierarchy and call them before my script? Is there some more information about building a static executable available? Thanks for any hints, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUI with sophisticated Table support
Hi, > Do a group-google search for *tkinter table*. That shows up quite a few > hits. thanks for that hint, but nearly every hit shows the Table of contents for Tkinter", which is not what i search for. My question here is rather in detail about Tkinters Table and if it can show resizable columns tho easily display a list of objects. I did not find any help searching for this with google, but i'd really rather like to use Tkinter over wxPython, that's the background of the question. Thanks for your help anyway, sorry if my question was unclear. Best regards, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: build a static executable program with python
Hi, thank you very much for that detailled description. I will try to get as far as i can with this information and get back to you if i have any questions. Thanks a lot, Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: build a static executable program with python
Hi Adal, can you send me your mail address? I think the one in your posting is a spam stopper. Cheers, Torsten. -- 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: [email protected] 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: [email protected] 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: [email protected] 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: [email protected] 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
