Coexistence of Python 2.x and 3.x on same OS
Has there been any official software that allows both the Python 2.x and 3.x releases to coexist on the same OS so that the end-user can easily switch between them when invoking Python scripts after each has been installed to their own directories/folders ? I know of some unoffical solutions, but they require lots of tweaks. Given the vagaries of the different OSs on which Python can run I am hoping for some offical solution which will work on any of the most popular OSs ( Windows, Linux, Mac ). The situation is so confusing on Windows, where the file associations, registry entries, and other internal software which allows a given Python release to work properly when invoking Python is so complicated, that I have given up on trying to install more than one Python release and finding a relaible, foolproof way of switching between them. So although I would like to use the latest 3.x series on Windows I have decide to stick with the latest 2.x series instead because much software using Python does not support 3.x yet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Coexistence of Python 2.x and 3.x on same OS
On 9/30/2012 3:38 PM, Andrew Berg wrote: On 2012.09.30 14:14, Edward Diener wrote: The situation is so confusing on Windows, where the file associations, registry entries, and other internal software which allows a given Python release to work properly when invoking Python is so complicated, that I have given up on trying to install more than one Python release and finding a relaible, foolproof way of switching between them. So although I would like to use the latest 3.x series on Windows I have decide to stick with the latest 2.x series instead because much software using Python does not support 3.x yet. http://www.python.org/dev/peps/pep-0397/ Unix-based OSes should already obey the shebang line, and on Windows, there's py.exe in 3.3 that will launch the intended version based on that shebang line. The problem with that is that one has to already being using 3.3 to use this facility. I was hoping for a solution which was backwards compatible with Python 2.x. My thought is a program distributed by Python which finds the versions of Python on an OS, lets the end-user choose which version should be invoked when Python is invoked, and does whatever is necessary to make that version the default version. While I was using the alpha/beta versions of 3.3, I had no problems invoking either 3.2 or 3.3 with the shebang line on Windows. That does not solve the problem for Python 2.x distributions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Coexistence of Python 2.x and 3.x on same OS
On 10/1/2012 1:32 PM, Dennis Lee Bieber wrote: On Sun, 30 Sep 2012 23:06:04 -0400, Edward Diener declaimed the following in gmane.comp.python.general: My thought is a program distributed by Python which finds the versions of Python on an OS, lets the end-user choose which version should be invoked when Python is invoked, and does whatever is necessary to make that version the default version. Which wouldn't be usable on any system that has to boot/process unattended, and run's Python scripts for configuration set-up. I can understand that but my use of Python on Windows is not that case. I simply want to be able to choose which version of Python runs when it is invoked, when I have multiple versions installed. Surely that is a very common case for end-users running 'python' or invoking some script which is associated with python. Making a version "default" pretty much means being able to rewrite the PATH environment variable... And I've seen too many messes made by some software already (including once having two generations of Python showing up in one PATH!) The PATH environment is constantly changing whether in Linux or Windows. Claiming that this is too dangerous" is silly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Coexistence of Python 2.x and 3.x on same OS
On 10/1/2012 12:02 PM, Alister wrote: On Sun, 30 Sep 2012 15:14:17 -0400, Edward Diener wrote: Has there been any official software that allows both the Python 2.x and 3.x releases to coexist on the same OS so that the end-user can easily switch between them when invoking Python scripts after each has been installed to their own directories/folders ? I know of some unoffical solutions, but they require lots of tweaks. Given the vagaries of the different OSs on which Python can run I am hoping for some offical solution which will work on any of the most popular OSs ( Windows, Linux, Mac ). The situation is so confusing on Windows, where the file associations, registry entries, and other internal software which allows a given Python release to work properly when invoking Python is so complicated, that I have given up on trying to install more than one Python release and finding a relaible, foolproof way of switching between them. So although I would like to use the latest 3.x series on Windows I have decide to stick with the latest 2.x series instead because much software using Python does not support 3.x yet. on my fedora system it was a simple matter of:- #> yum install python3 to use python 3 i specify it in my shebang line #!/usr/bun/env python3 Simple Not sure about Windoze though (Although from memory the install asks where to install so should not be a major issue) Windows installs of Python do not distinguish releases by Pythonx(.x) but just install different versions of Python in different directories. However one can make links to the different versions based on their release numbers, and that would allow a shebang line work if it was supported. -- http://mail.python.org/mailman/listinfo/python-list
Re: Coexistence of Python 2.x and 3.x on same OS
On 9/30/2012 3:38 PM, Andrew Berg wrote: On 2012.09.30 14:14, Edward Diener wrote: The situation is so confusing on Windows, where the file associations, registry entries, and other internal software which allows a given Python release to work properly when invoking Python is so complicated, that I have given up on trying to install more than one Python release and finding a relaible, foolproof way of switching between them. So although I would like to use the latest 3.x series on Windows I have decide to stick with the latest 2.x series instead because much software using Python does not support 3.x yet. http://www.python.org/dev/peps/pep-0397/ Unix-based OSes should already obey the shebang line, and on Windows, there's py.exe in 3.3 that will launch the intended version based on that shebang line. While I was using the alpha/beta versions of 3.3, I had no problems invoking either 3.2 or 3.3 with the shebang line on Windows. Thanks ! I will get this and hopefully it will do what I want. -- http://mail.python.org/mailman/listinfo/python-list
Re: Coexistence of Python 2.x and 3.x on same OS
On 10/5/2012 5:32 PM, Dennis Lee Bieber wrote: On Fri, 05 Oct 2012 08:15:30 -0400, Edward Diener declaimed the following in gmane.comp.python.general: Windows installs of Python do not distinguish releases by Pythonx(.x) but just install different versions of Python in different directories. Really? E:\Python27>dir Volume in drive E is Data Volume Serial Number is 2626-D991 Directory of E:\Python27 08/28/2012 05:32 PM . 08/28/2012 05:32 PM .. 08/28/2012 02:11 PM DLLs 08/28/2012 05:43 PM Doc 08/28/2012 02:11 PM include 08/31/2012 04:58 PM Lib 08/28/2012 02:11 PM libs 08/28/2012 02:15 PM 108,255 matplotlib-wininst.log 08/28/2012 02:18 PM 4,169 MySQL-python-wininst.log 08/28/2012 02:15 PM98,498 numpy-wininst.log 08/28/2012 02:20 PM17,816 PIL-wininst.log 08/28/2012 03:29 PM 1,572 PyOpenGL-accelerate-wininst.log 08/28/2012 03:38 PM 3,009 pyserial-wininst.log 06/24/2011 12:38 PM27,136 python.exe 06/24/2011 12:38 PM27,136 python2.7.exe 06/24/2011 12:38 PM27,136 python2.exe 08/28/2012 05:32 PM90,943 PythonCard-wininst.log 06/24/2011 12:38 PM27,136 pythonw.exe 06/24/2011 12:38 PM27,136 pythonw2.7.exe 06/24/2011 12:38 PM27,136 pythonw2.exe That's, as you say, ActievState. The normal Python installer does not create a python2.7.exe etc. But of course I can create any links I want, so that's not really the problem. The major difficulty is that prior to invoking either "python" directly or a script with a normal Python file association, I want to be able to specify which version of Python should be invoked as the default without having to specifically invoke a partiocular version by typing 'python2.7 ...' or 'python3.3 ...' etc. 08/28/2012 02:15 PM 196,096 Removematplotlib.exe 08/28/2012 02:18 PM 196,096 RemoveMySQL-python.exe 08/28/2012 02:15 PM 196,096 Removenumpy.exe 08/28/2012 02:20 PM 196,096 RemovePIL.exe 08/28/2012 03:29 PM 196,096 RemovePyOpenGL-accelerate.exe 08/28/2012 03:38 PM 196,096 Removepyserial.exe 08/28/2012 05:32 PM61,440 RemovePythonCard.exe 08/28/2012 02:20 PM 196,096 Removereportlab.exe 08/28/2012 02:19 PM 196,096 Removescipy.exe 08/28/2012 05:29 PM 196,096 RemoveWConio.exe 08/28/2012 02:20 PM40,362 reportlab-wininst.log 08/28/2012 02:19 PM 159,420 scipy-wininst.log 08/28/2012 05:32 PM Scripts 08/28/2012 02:11 PM tcl 08/28/2012 02:11 PM Tools 11/28/2007 04:32 PM 258,352 unicows.dll 06/24/2011 12:38 PM49,664 w9xpopen.exe 08/28/2012 05:29 PM 891 WConio-wininst.log 28 File(s) 2,822,071 bytes 10 Dir(s) 148,557,684,736 bytes free E:\Python27> That's what was set up by a recent ActiveState installer (well, recent for me -- I'd still been using 2.5 three months ago) Yes, it IS in a version numbered directory, but there are copies of the executable named as plain python, pythonX, and pythonX.Y E:\Python27>cd %homepath% E:\UserData\Wulfraed\My Documents>python ActivePython 2.7.2.5 (ActiveState Software Inc.) based on Python 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. ^Z E:\UserData\Wulfraed\My Documents>python2.7 ActivePython 2.7.2.5 (ActiveState Software Inc.) based on Python 2.7.2 (default, Jun 24 2011, 12:21:10) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. Granted, one would need to have each installation directory in the PATH, ordered such that the preferred version would be found first when using just "python". There is much more than just the PATH needed to change to have a different Python be the default. File associations also. I thnk there are more things too, but I know it has always been difficult on Windows to easily change which distribution is called when "python" is executed or some Python file association is executed. I welcome the new Python launcher for Windows mentioned but have not had a chance to use it and see how it works yet. I will try it this weekend and hopefully it will work well to solve the problem of having multiple Python installations installed on Windows at the same time, and being able to easily specify the one I want invoked. -- http://mail.python.org/mailman/listinfo/python-list
Switching between Python releases under Windows
I have multiple versions of Python installed under Vista. Is there any easy way of switching between them so that invoking python and file associations for Python extensions files work automatically ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 3 on Windows
On 8/2/2016 8:11 AM, Uri Even-Chen wrote: Hi, I want to install Python 3 on Windows, but I also need Python 2 for Google App Engine SDK. When I type a name of a Python file in command line, I want it to run with Python 3. However, I checked with "print 3/5" and it printed 0 - Python 2. I have the latest versions of Python installed - python-2.7.12.msi and python-3.5.2.exe python --version Python 2.7.12 assoc .py .py=Python.File ftype Python.File Python.File="C:\Python27\python.exe" "%1" %* By the way, it there a way to print the Python version from Python? Use the Python Launcher for Windows. -- https://mail.python.org/mailman/listinfo/python-list
Name of IDLE on Linux
What is the name of the IDLE program on Linux and where is it installed in a normal Linux distribution ? I have installed all the Python 2.3.5 RPMs on my Fedora 3 system but I have no idea where they are installed or what IDLE is called. I lloked in the Python web pages to try to find a list of the files in the various installations, but was unable to find the information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Name of IDLE on Linux
Jim Benson wrote: On Sat, 2 Apr 2005, Edward Diener wrote: What is the name of the IDLE program on Linux and where is it installed in a normal Linux distribution ? I have installed all the Python 2.3.5 RPMs on my Fedora 3 system but I have no idea where they are installed or what IDLE is called. I lloked in the Python web pages to try to find a list of the files in the various installations, but was unable to find the information. Try idle (all lower case). On my RH-9 system it is in /usr/local/bin Thanks. The system came with Python and the development libraries but not with the latest installation and tools. Once I was able to install all the latest Python RPM for Fedora 3, 'idle' showed up. Now all I have to do is find everything else, including the latest documentation files. It is a pity the Python Linux binary installations do not create folders on the desktop or in the Gnome menu system with links to the Python to the documentation and a readme telling me what executables were installed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Name of IDLE on Linux
Thomas Rast wrote: > Edward Diener <[EMAIL PROTECTED]> writes: > >> It is a pity the Python Linux binary installations do not >> create folders on the desktop or in the Gnome menu system with links >> to the Python to the documentation and a readme telling me what >> executables were installed. > > Imagine they did, and the other 1392 packages (on my system) too :-) I can understand that . But I would rather have links somewhere than not know what it was a particular package does and how to use it. As a relative Linux newbie, I have found it disconcerting to have things installed on my system when I first booted the system or when I install new packages or upgrade existing ones, and not know what these packages are used for. One can always delete links, and they are cheap, so I would rather have too much to begin with than too little. > > Documentation usually resides in /usr/share/doc/, > /usr/share/doc/packages/ or similiar. You're on an RPM-based > system, so > > $ rpm -ql > > lists all files belonging to that package. You should have little > trouble spotting the documentation files there. Thanks. That does help. -- http://mail.python.org/mailman/listinfo/python-list
Installing Python 2.4 on Linux
I can install Python 2.4 on the Fedora 3 Linux system, but after I do a number of Linux utilities and commands, like yum, stop working because they were dependent on the Python 2.3 installation. What happens is that Python 2.4 replaces the /usr/bin/python module with the Python 2.4 version. If I replace /usr/bin/python with the Python 2.3 version executable, which is still on my system, that all the aforesaid modules depend on, they start working again, but I can no longer execute modules, like IDLE, which was part of my Python 2.4 distribution. What is the solution to this ? The operating system was installed with Python 2.3 and the development libraries but no tools, doc, or otherwise. I have installed Python 2.4 with all the RPMs and copied down the Python 2.4 documentation to my machine ( since python24-docs.rpm gives one very little ). I would naturally like to use Python 2.4 without killing all the commands that depend on Python 2.3. No doubt these commands have their modules in the site libraries for Python 2.3. Of course I would love to update these dependencies to use Python 2.4 but newer RPMs for these commands do not exist. I do not know whether this is a Python problem or a Fedora 3 problem but I thought I would ask here first and see if anybody else had the same problem. I imagine the problem might exist on other Linux systems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 2.4 on Linux
Marcin Stêpnicki wrote: > Dnia Tue, 05 Apr 2005 21:21:37 +0000, Edward Diener napisal(a): > >> I can install Python 2.4 on the Fedora 3 Linux system, but after I >> do a number of Linux utilities and commands, like yum, stop working >> because they were dependent on the Python 2.3 installation. What >> happens is that Python 2.4 replaces the /usr/bin/python module with >> the Python 2.4 version. If I replace /usr/bin/python with the Python >> 2.3 version executable, which is still on my system, that all the >> aforesaid modules depend on, they start working again, but I can no >> longer execute modules, like IDLE, which was part of my Python 2.4 >> distribution. >> >> What is the solution to this ? The operating system was installed >> with Python 2.3 and the development libraries but no tools, doc, or >> otherwise. I have installed Python 2.4 with all the RPMs and copied >> down the Python 2.4 documentation to my machine ( since >> python24-docs.rpm gives one very little ). I would naturally like to >> use Python 2.4 without killing all the commands that depend on >> Python 2.3. No doubt these commands have their modules in the site >> libraries for Python 2.3. Of course I would love to update these >> dependencies to use Python 2.4 but newer RPMs for these commands do >> not exist. >> >> I do not know whether this is a Python problem or a Fedora 3 problem >> but I thought I would ask here first and see if anybody else had the >> same problem. I imagine the problem might exist on other Linux >> systems. > > It's rather Fedora related, I have Python 2.2, 2.3 and 2.4 on my > Ubuntu box and they seem to coexist without problems. > > If you can afford breaking package dependencies a bit, save a copy of > python2.3 binary somewhere and recreate it after installing Python > 2.4 After I installed Python 2.4, the Python 2.3 executable still existed on the system. So the only difference which occurred is that the Python 2.4 installation copied to the /usr/bin/python executable the /usr/bin/python2.4 executable ( it would seem more understandable that /usr/bin/python be a link instead ). So there is really no need to recreate it. Essentially the two versions co-exist on the system but only one can be /usr/bin/python and therefore executed when a Python script is is used as a command. >, OR make a symbolic link /usr/bin/python to /usr/bin/python2.3 > and use /usr/bin/python2.4 explicitely when you want to use the newer > version. Yes, this is the right solution. I am so used to just executing a Python script that I forgot that I could just say 'python2.4 ascript.py'. > You may also try to link modules from > /usr/lib/python2.3/site-packages to /usr/lib/python2.4/site-packages > (all or just few of them) - most should be upwards compatible. By link do you simply mean moving the unique modules in the site packages from the python2.3 directory to the python2.4 site-packages directory, or is there something else I must do to see if they work ? > It may > make Fedora utilities work again (you haven't provided error > messages, so it's hard to tell) even with Python 2.4. The errors when executed from the command line, when python2.4 is python, involved not being able to find modules, no doubt because they were not in the python2.4 site-packages subdirectory. When python2.3 is python, the modules are found and everything works. Maybe it is just a matter of moving of copying these modules on over and seeing if that fixes things. Do site-packages have to "register" themselves in any way during setup ? I do not think so, but I may be wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 2.4 on Linux
David Fraser wrote: Edward Diener wrote: I can install Python 2.4 on the Fedora 3 Linux system, but after I do a number of Linux utilities and commands, like yum, stop working because they were dependent on the Python 2.3 installation. What happens is that Python 2.4 replaces the /usr/bin/python module with the Python 2.4 version. If I replace /usr/bin/python with the Python 2.3 version executable, which is still on my system, that all the aforesaid modules depend on, they start working again, but I can no longer execute modules, like IDLE, which was part of my Python 2.4 distribution. What is the solution to this ? The operating system was installed with Python 2.3 and the development libraries but no tools, doc, or otherwise. I have installed Python 2.4 with all the RPMs and copied down the Python 2.4 documentation to my machine ( since python24-docs.rpm gives one very little ). I would naturally like to use Python 2.4 without killing all the commands that depend on Python 2.3. No doubt these commands have their modules in the site libraries for Python 2.3. Of course I would love to update these dependencies to use Python 2.4 but newer RPMs for these commands do not exist. I do not know whether this is a Python problem or a Fedora 3 problem but I thought I would ask here first and see if anybody else had the same problem. I imagine the problem might exist on other Linux systems. Actually the Fedora RPMS supplied on the Python website are fine: http://www.python.org/2.4.1/rpms.html Quoting from that page: # Q) Is it safe to install these RPMs on a Red Hat system? Will they over-write the system python and cause problems with other Red Hat applications that expect a different version of Python? # A) The RPMs that start with "python2.4" are built to not interfere with the system Python. They install as "/usr/bin/python2.4" and will not conflict with the system Python unless you are running on a system that ships the a version of Python which has the same major/minor number. To invoke the interpreter with these packages, you will explicitly have to run "python2.4". Note that all Python RPMs provided by Python.org and Red Hat provide a "/usr/bin/python2.4" (or similar, with major/minor number), even if they also provide "/usr/bin/python". So, yes, it should be safe. Note that you may need to build and install a second copy of any packages which you need access to with the supplemental version of Python. You can build packages of these files for the Python 2.4 interpreters for packages which use Distutils, by using the command "python2.4 setup.py bdist_rpm". This is by far the preferred way to install a different version of Python to the default version provided with a distribution, as you don't then conflict with packages that require the default version. I do have a separate package installed for Python2.4 and it coexists with Python2.3. The real problem is that a great number of other packages, which are initially part of the system, depend on Python2.3 so I must leave /usr/bin/python as Python2.3. I do not know of a way to reinstall these other packages to use Python2.4 instead. Does the line above, "python2.4 setup.py bdist_rpm" mean that I am supposed to run this against each of these other package's rpm files and substitute for "bdist_rpm" the name of the rpm file ? Also, it is better to do it like this using real packages than to rename files manually. I have used the above successfully on Fedora Core 3 (and other similar versions on other distro versions), if it doesn't work for you there is a source RPM available to rebuild from Is "bdist_rpm" the source rpm for these packages which currently depend on Python2.3 ? Further help getting my Fedora 3 packages which depend on Python2.3 to use Python2.4 would be appreciated. -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 2.4 on Linux
John Ridley wrote: --- Edward Diener <[EMAIL PROTECTED]> wrote: [snip] I do not know whether this is a Python problem or a Fedora 3 problem but I thought I would ask here first and see if anybody else had the same problem. I imagine the problem might exist on other Linux systems. On my Mandrake 10.1 system I have the default python 2.3 installation plus a separate python 2.4 installation which I compiled from source. There are two executables (python2.3 and python2.4) in /usr/bin, plus a hard-link (from python2.4) named python. If necessary, I could switch back to the default setup by replacing the hard-link with one from python2.3 - so the system would then have its preferred python version and I could selectively run python2.4 whenever appropriate. So far, Mandrake has not complained about using python 2.4 exclusively, so I might try removing the old installation eventually. (Then again, it's always handy to keep it for compatibility testing). I need python to be python2.3 else many utilities no longer work. The problem is then using IDLE and pydoc for Python2.4 since neither are .py scripts and need python to be a link to python2.4 and not python2.3. I guess the solution is to write a script a shell script which links python to python2.4, run IDLE let's say, then link back to python2.3. However while I am doing this, other system facilities which depend on python to be python2.3 will be dead. -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 2.4 on Linux
Joseph Garvin wrote: Another solution is to just install 2.4 and then make an alias for yum='/usr/bin/python2.3 yum' or whatever the path is :) If it were just 'yum' under Fedora 3, I could probably do that but looking at the dependencies on the python2.3 package in Synaptic there must be about 50 other packages mentioned. Which one of these specifically use python2.3 to execute their .py scripts and which ones just use python2.3 shared libraries is another matter which will take much work to discover. But thanks for your suggestion nonetheless. Edward Diener wrote: I can install Python 2.4 on the Fedora 3 Linux system, but after I do a number of Linux utilities and commands, like yum, stop working because they were dependent on the Python 2.3 installation. What happens is that Python 2.4 replaces the /usr/bin/python module with the Python 2.4 version. If I replace /usr/bin/python with the Python 2.3 version executable, which is still on my system, that all the aforesaid modules depend on, they start working again, but I can no longer execute modules, like IDLE, which was part of my Python 2.4 distribution. What is the solution to this ? The operating system was installed with Python 2.3 and the development libraries but no tools, doc, or otherwise. I have installed Python 2.4 with all the RPMs and copied down the Python 2.4 documentation to my machine ( since python24-docs.rpm gives one very little ). I would naturally like to use Python 2.4 without killing all the commands that depend on Python 2.3. No doubt these commands have their modules in the site libraries for Python 2.3. Of course I would love to update these dependencies to use Python 2.4 but newer RPMs for these commands do not exist. I do not know whether this is a Python problem or a Fedora 3 problem but I thought I would ask here first and see if anybody else had the same problem. I imagine the problem might exist on other Linux systems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 2.4 on Linux
John Ridley wrote: * Edward Diener wrote: I need python to be python2.3 else many utilities no longer work. Then leave your 2.3 installation exactly as it is (so that python is a link to python2.3) and run python2.4 where needed. To specifically use python 2.4 to run IDLE, simply type in a shell: [user]$ python2.4 /usr/bin/idle Alternatively, create your own (executable) idle or pydoc with a shebang that points permanently at python2.4. For example: file: $HOME/bin/idle2.4 --- #!/usr/bin/python2.4 from idlelib.PyShell import main if __name__ == '__main__': main() --- Then if $HOME/bin is on your PATH, you can simply run: idle2.4 This change worked. Thanks ! The problem is then using IDLE and pydoc for Python2.4 since neither are .py scripts Really?! What are they on Fedora, then? I realized they are links to the respective idle2.4.py and pydoc2.4.py scripts. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.4.1 install broke RedHat 9 printconf-backend
BrianS wrote: > Hi, > > I'm trying to learn Python and wanted to play with Tkinter. I > couldn't get it to work so I figured it would help if I installed the > newest verison of Python. I downloaded the source, compiled it and > installed it. No problem. The next time I booted my machine I the > following errors when it tried to start CUPS: > > Traceback (most recent call last): > File "/usr/sbin/printconf-backend", line 6, in ? > import backend > File "/usr/share/printconf/util/backend.py", line 37, in ? > import cups_import > File "/usr/share/printconf/util/cups_import.py", line 7, in ? > from printconf_conf import * > File "/usr/share/printconf/util/printconf_conf.py", line 83, in ? > from xml.utils import qp_xml > ImportError: No module named utils > > It seems that the xml package have been changed. My problem is that I > don't know enough Python to fix it properly. The old verison of > Python was 2.2.2 and the > version I just installed is 2.4.1. This is on a Dell Inspiron 8500 > running Red Hat 9. > > Anyone have any ideas? Thanks in advance. Change the /usr/bin/python link from python2.4 to whatever version of python exe it used to point to, probably python2.2 in your case. The Python2.4 install does not overwrite any of your python2.2 files, it just changes the python link. > Brian -- http://mail.python.org/mailman/listinfo/python-list
Python launcher options
The Python launcher in Windows is a neat tool for running multiple versions of Python 2 and Python 3 at different times. It allows as options the ability to specify the latest version of either Python 2 or Python 3 defaulting to the 64-bit version if both exist, or a specific 32-bit or 64-bit version of Python 2 or Python 3. What is missing is the ability to specify the latest 32-bit version of Python 2 or Python 3. The equivalent syntax would be '-2-32' or '-3-32'. Is there some reason why this option has been disallowed ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python launcher options
On 1/9/2016 11:03 AM, Tim Golden wrote: On 06/01/2016 00:48, Edward Diener wrote: The Python launcher in Windows is a neat tool for running multiple versions of Python 2 and Python 3 at different times. It allows as options the ability to specify the latest version of either Python 2 or Python 3 defaulting to the 64-bit version if both exist, or a specific 32-bit or 64-bit version of Python 2 or Python 3. What is missing is the ability to specify the latest 32-bit version of Python 2 or Python 3. The equivalent syntax would be '-2-32' or '-3-32'. Is there some reason why this option has been disallowed ? As far as I can remember, it's not so much a question of "disallowed" as just "not thought of by anyone". If you wanted this to go anywhere, could I suggest you create an issue on the Python issue tracker: http://bugs.python.org and mark it as "Windows" in the [Components] field (that makes sure that some relevant people get to see it). It's got a much better chance of achieving traction if you can actually provide a code patch to implement the behaviour. Failing that, at least make a good case which might convince one of the developers that it would it be worth their while implementing the change. I have tried to register with the link above so I can an issue with the Python Issue tracker but all attempts fail with: "Failed issue tracker submission An unexpected error occurred during the processing of your message. The tracker administrator is being notified." -- https://mail.python.org/mailman/listinfo/python-list
Re: Python launcher options
On 1/10/2016 6:38 AM, Tim Golden wrote: On 10/01/2016 05:18, Edward Diener wrote: On 1/9/2016 11:03 AM, Tim Golden wrote: On 06/01/2016 00:48, Edward Diener wrote: The Python launcher in Windows is a neat tool for running multiple versions of Python 2 and Python 3 at different times. It allows as options the ability to specify the latest version of either Python 2 or Python 3 defaulting to the 64-bit version if both exist, or a specific 32-bit or 64-bit version of Python 2 or Python 3. What is missing is the ability to specify the latest 32-bit version of Python 2 or Python 3. The equivalent syntax would be '-2-32' or '-3-32'. Is there some reason why this option has been disallowed ? As far as I can remember, it's not so much a question of "disallowed" as just "not thought of by anyone". If you wanted this to go anywhere, could I suggest you create an issue on the Python issue tracker: http://bugs.python.org and mark it as "Windows" in the [Components] field (that makes sure that some relevant people get to see it). It's got a much better chance of achieving traction if you can actually provide a code patch to implement the behaviour. Failing that, at least make a good case which might convince one of the developers that it would it be worth their while implementing the change. I have tried to register with the link above so I can an issue with the Python Issue tracker but all attempts fail with: "Failed issue tracker submission An unexpected error occurred during the processing of your message. The tracker administrator is being notified." Hmmm. Thanks for making the effort -- and for reporting back. I've just successfully registered a (dummy) account there, so it's possible that there was a temporary glitch. If you wouldn't mind trying once more, that would be helpful. If not, I can create the issue on your behalf, and inform the tracker admins. I tried again only to run into the exact same problem. I don't know what it means that I am not being allowed to register for the Python bug tracker. Needless to say the obscure error message is not telling me anything. Of course as a programmer who uses Python I would like to find out why I am not able to register. But in the meantime if you could create the issue on my behalf it would be appreciated. Thanks ! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python launcher options
On 1/10/2016 6:38 AM, Tim Golden wrote: On 10/01/2016 05:18, Edward Diener wrote: On 1/9/2016 11:03 AM, Tim Golden wrote: On 06/01/2016 00:48, Edward Diener wrote: The Python launcher in Windows is a neat tool for running multiple versions of Python 2 and Python 3 at different times. It allows as options the ability to specify the latest version of either Python 2 or Python 3 defaulting to the 64-bit version if both exist, or a specific 32-bit or 64-bit version of Python 2 or Python 3. What is missing is the ability to specify the latest 32-bit version of Python 2 or Python 3. The equivalent syntax would be '-2-32' or '-3-32'. Is there some reason why this option has been disallowed ? As far as I can remember, it's not so much a question of "disallowed" as just "not thought of by anyone". If you wanted this to go anywhere, could I suggest you create an issue on the Python issue tracker: http://bugs.python.org and mark it as "Windows" in the [Components] field (that makes sure that some relevant people get to see it). It's got a much better chance of achieving traction if you can actually provide a code patch to implement the behaviour. Failing that, at least make a good case which might convince one of the developers that it would it be worth their while implementing the change. I have tried to register with the link above so I can an issue with the Python Issue tracker but all attempts fail with: "Failed issue tracker submission An unexpected error occurred during the processing of your message. The tracker administrator is being notified." Hmmm. Thanks for making the effort -- and for reporting back. I've just successfully registered a (dummy) account there, so it's possible that there was a temporary glitch. If you wouldn't mind trying once more, that would be helpful. If not, I can create the issue on your behalf, and inform the tracker admins. I was finally able to register so I will report this issue on the Python issue tracker myself. -- https://mail.python.org/mailman/listinfo/python-list
Controlling py.exe launcher on Windows
I am trying to control the default version of the py.exe launcher on Windows. I have the Python 2.7.8 and 3.4.1 installed with both the 32 bit and 64 bit versions, all in different directories. I assume that .py and .pyw files are associated with the py.exe launcher. I am trying to control which version starts through a py.ini file in the same directory as the py.exe file in the 3.4.1 version last installed. If I specify in the [defaults] section of py.ini: python=3.4 then launching py.exe will show: Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:45:13) [MSC v.1600 64 bit (AM D64)] on win32 If I specify: python=3.4-32 then launching py.exe will show: Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win 32 Is it really true that I cannot specify the 32 bit version in the .ini file or am I doing something wrong here ? -- https://mail.python.org/mailman/listinfo/python-list
Python 3.4.1 install does not create a file association for .py files on Windows
I install Python 3.4.1 64-bit on Windows. After the install I type: assoc .py and I get back: File association not found for extension .py Why does not the Python install to associate extension .py with the Python Launcher for Windows ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.4.1 install does not create a file association for .py files on Windows
On 8/5/2014 6:16 PM, Terry Reedy wrote: On 8/5/2014 3:36 PM, Edward Diener wrote: I install Python 3.4.1 64-bit on Windows. After the install I type: I have done the same, on Win 7, but I had previous installs going back 3 years on this machine. assoc .py and I get back: File association not found for extension .py I get C:\Users\Terry>assoc .py .py=Python.File C:\Users\Terry>assoc .pyw .pyw=Python.NoConFile C:\Users\Terry>assoc .pyo .pyo=Python.CompiledFile C:\Users\Terry>assoc .pyc .pyc=Python.CompiledFile None of this specifies the program, which is currently Python Launcher for Windows (console). (See Control Panel / Default Programs / Set Associations.) Why does not the Python install to associate extension .py with the Python Launcher for Windows ? Somewhere during the install, there is a checkbox or something about grabbing file associations or about making the install the default version. I do not remember. I uninstalled all my Python versions and then re-installed each one. Now the correct file association has been made. Something was fouled up in the installation process which is now fixed. -- https://mail.python.org/mailman/listinfo/python-list
Re: Controlling py.exe launcher on Windows
On 8/5/2014 1:27 PM, Edward Diener wrote: I am trying to control the default version of the py.exe launcher on Windows. I have the Python 2.7.8 and 3.4.1 installed with both the 32 bit and 64 bit versions, all in different directories. I assume that .py and .pyw files are associated with the py.exe launcher. I am trying to control which version starts through a py.ini file in the same directory as the py.exe file in the 3.4.1 version last installed. If I specify in the [defaults] section of py.ini: python=3.4 then launching py.exe will show: Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:45:13) [MSC v.1600 64 bit (AM D64)] on win32 If I specify: python=3.4-32 then launching py.exe will show: Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win 32 Is it really true that I cannot specify the 32 bit version in the .ini file or am I doing something wrong here ? After uninstalling my Python versions and re-installing them, everything works properly and I can control the version which py.exe starts from the py.ini file. -- https://mail.python.org/mailman/listinfo/python-list
Getting the home directory in Python and a bug in os.path.expanduser
What is the generic operating system way of getting the home directory ?
I am guessing it is os.path.expanduser("~"). Is there a better way or an
alternate way ?
If it is as I surmise, the aforementioned expanduser("~") of os.path
seems incorrect to me under Windows. The document says:
"On Windows, only "~" is supported; it is replaced by the environment
variable HOME or by a combination of HOMEDRIVE and HOMEPATH."
But HOME is never the home directory for Windows, only the combination
of HOMEDRIVE and HOMEPATH is valid, which is always set. If MSYS is
installed under Windows, where HOME must be set to the MSYS home
directory for a given user in order to emulate Linux/Unix, attempting to
use os.path.expanduser("~") will incorrectly return the MSYS home
directory for a given user rather than the Windows home directory for
the logged in user. So I think the os.path.expanduser("~") works
incorrectly in this case and needs to be fixed, else you are telling
users never to use MSYS under Windows.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Getting the home directory in Python and a bug in os.path.expanduser
Josiah Carlson wrote:
> Edward Diener wrote:
>> What is the generic operating system way of getting the home directory ?
>>
>> I am guessing it is os.path.expanduser("~"). Is there a better way or
>> an alternate way ?
>>
>> If it is as I surmise, the aforementioned expanduser("~") of os.path
>> seems incorrect to me under Windows. The document says:
>>
>> "On Windows, only "~" is supported; it is replaced by the environment
>> variable HOME or by a combination of HOMEDRIVE and HOMEPATH."
>>
>> But HOME is never the home directory for Windows, only the combination
>> of HOMEDRIVE and HOMEPATH is valid, which is always set. If MSYS is
>> installed under Windows, where HOME must be set to the MSYS home
>> directory for a given user in order to emulate Linux/Unix, attempting
>> to use os.path.expanduser("~") will incorrectly return the MSYS home
>> directory for a given user rather than the Windows home directory for
>> the logged in user. So I think the os.path.expanduser("~") works
>> incorrectly in this case and needs to be fixed, else you are telling
>> users never to use MSYS under Windows.
>
> Some people have "sane" values for HOME on Windows.
And some people use Linux/Unix emulation software on Windows where HOME
has nothing to do with the Windows home directory, but everything to do
with the emulation's notion of a "home" directory. In fact Microsoft may
well have anticipated this by automatically generating HOMEDRIVE and
HOMEPATH based on the user's home directory when he logs on.
> That's the only
> reason why it was included in expanduser(). The current trunk version
> of ntpath offers HOME, USERPROFILE or HOMEDRIVE+HOMEPATH, as well as the
> expansion of ~/extra/stuff .
There is no problem checking the other values but on Windows
HOMEDRIVE+HOMEPATH should always be first, USERPROFILE should be second
if either HOMEDRIVE or HOMEPATH does not exist ( which is extremely
unlikely), and finally HOME should only be used if the others fail. I
will even go for USERPROFILE coming before the check for HOMEDRIVE and
HOMEPATH, although I think it is wrong because the notion of a "home"
directory on Windows may not stay tied to a user profile ( in fact they
may be already different on Vista, which I do not have, for all I know
). But at least USERPROFILE is generated by Windows, like HOMEDRIVE and
HOMEPARTH.
Using HOME as the first option on Windows is definitely wrong,
especially for the reason I pointed out, that Linux/Unix emulation
systems on Windows have the user set HOME to the emulation's "home"
directory, and that is definitely not the Windows "home" directory. HOME
is of course perfectly viable in the Linux/Unix world.
Probably most reliable on Windows is a Windows API function, if it
exists, for getting the home directory, as opposed to using environment
variables, but I can not find any Windows API for it at present.
>
> If you would like to get rid of Python's support of HOME, please post a
> bug report or feature request on the sourceforge tracker.
I realized I could post a bug report after I posted my OP, so I
subsequently posted a bug report on the sourceforge tracker. I do not
need a new feature, but only to have the current feature, which is
expanduser, work correctly on Windows. It is currently a serious problem
for Window's users, who have Linux/Unix emulation software on their
syetem, running a Python script which correctly uses expanduser to get
the Windows home directory and ends up with the wrong location.
Thank you for responding. I hope Python will fix this problem.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Getting the home directory in Python and a bug in os.path.expanduser
Neil Hodgson wrote: > Edward Diener: > >> Probably most reliable on Windows is a Windows API function, if it >> exists, for getting the home directory, as opposed to using >> environment variables, but I can not find any Windows API for it at >> present. > >Look at SHGetFolderPath(CSIDL_PROFILE, ...) for Windows Me/2000 or > later. CSIDL_APPDATA is probably a better idea than CSIDL_PROFILE (its > equivalent to "%USERPROFILE%\Application Data" and roams) but > %USERPROFILE% (CSIDL_PROFILE) is compatible with previous Python behaviour. > http://msdn2.microsoft.com/en-us/library/ms647764.aspx Thanks, that looks good. For Windows Vista one should evidently use SHGetKnownFolderPath(FOLDERID_Profile,...) instead. -- http://mail.python.org/mailman/listinfo/python-list
Difference between import in script and from interpreter
In a python script a: from xxx.yyy.zzz import aaa fails with the message: "ImportError: No module named xxx.yyy.zzz" but from within the python interpreter the same line succeeds. What would be the causes of that ? From within the python interpreter I have looked at sys.path and xxx.yyy.zzz is definitely in the path ( off of site-packages ). So I am not sure why this is failing within the python script. -- http://mail.python.org/mailman/listinfo/python-list
Different python versions confusion under Windows Vista x64
In Windows Vista x64 I have installed python 2.6 64-bit version and python 3.1 64-bit version to separate folders. Within the command interpreter I add python 2.6 to the PATH. In the command interpreter, When I type python somescript.py with an import sys print (sys.version) in the script, it shows: 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit (AMD64)] In the command interpreter if I type 'python' I see: Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Does anybody have any ideas why this is happening ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Different python versions confusion under Windows Vista x64
On 7/19/2010 9:15 AM, Alf P. Steinbach /Usenet wrote: * Edward Diener, on 19.07.2010 14:53: In Windows Vista x64 I have installed python 2.6 64-bit version and python 3.1 64-bit version to separate folders. Within the command interpreter I add python 2.6 to the PATH. In the command interpreter, When I type python somescript.py with an import sys print (sys.version) in the script, it shows: 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit (AMD64)] In the command interpreter if I type 'python' I see: Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Does anybody have any ideas why this is happening ? At a guess your description of what's happening is not entirely accurate. Although it could be, since Windows moves in mysterious ways. Please try the following commands in sequence, with no other commands: python -V echo %path% ftype python.file python somescript.py Then right-click the command interpreter's title bar to get edit menu. /Mark/ the text of your commands and results. Then /copy/ it to the clipboard (note: you can't use [Ctrl C] here, use the edit menu or just press Enter). Then post the commands and results here, /paste/ them into your message (e.g. [Ctrl V]). And then, if you haven't already figured it out, somebody probably will. :-) I figured out the cause. One of the Python scripts started with: #!Path/to/Python31Executable which evidently caused python 3.1 to be called to run that script. I am not sure that script was run via an 'import' statement, as opposed to a 'python someScript.py' within another script, but I suspect the latter. -- http://mail.python.org/mailman/listinfo/python-list
Re: Different python versions confusion under Windows Vista x64
On 7/19/2010 5:45 PM, Edward Diener wrote: On 7/19/2010 9:15 AM, Alf P. Steinbach /Usenet wrote: * Edward Diener, on 19.07.2010 14:53: In Windows Vista x64 I have installed python 2.6 64-bit version and python 3.1 64-bit version to separate folders. Within the command interpreter I add python 2.6 to the PATH. In the command interpreter, When I type python somescript.py with an import sys print (sys.version) in the script, it shows: 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit (AMD64)] In the command interpreter if I type 'python' I see: Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Does anybody have any ideas why this is happening ? At a guess your description of what's happening is not entirely accurate. Although it could be, since Windows moves in mysterious ways. Please try the following commands in sequence, with no other commands: python -V echo %path% ftype python.file python somescript.py Then right-click the command interpreter's title bar to get edit menu. /Mark/ the text of your commands and results. Then /copy/ it to the clipboard (note: you can't use [Ctrl C] here, use the edit menu or just press Enter). Then post the commands and results here, /paste/ them into your message (e.g. [Ctrl V]). And then, if you haven't already figured it out, somebody probably will. :-) I figured out the cause. One of the Python scripts started with: #!Path/to/Python31Executable which evidently caused python 3.1 to be called to run that script. I am not sure that script was run via an 'import' statement, as opposed to a 'python someScript.py' within another script, but I suspect the latter. No, this is incorrect. The cause had nothing to do with the above. It was because .py files were associated with the 3.1 version of Python, no Python folder was in the PATH, and a Pyhton script invoked python passing it a .py file. So even though the initial command specified the 2.6 version of Python on a script, subsequent scripts were run using Python 3.1. I since changed the association of .py files to the 2.6 version of Python and everything works correctly. -- http://mail.python.org/mailman/listinfo/python-list
Multiple versions of Python coexisting in the same OS
Are there any documents about multiple versionsof Python coexisting in the same OS ( Windows in my case ) and what pitfalls to look out for ? I have already run into a number of them. I installed Python 2.7 and 3.1.2 into completely folders, but immediately ran into serious problems executing a Python script. The first problem is that just invoking Python will start whichever version is first in the PATH, and this is true from the command line or internally in a Python script. The second problem is that invoking a script ( some xxx.py ) will start whichever version of Python is associated with the .py extension. The third problem is if some software expects its scripts, which it puts in some Python subdirectory to be in the PATH. There may be other considerations but overall having to versions coexisting has turned out to be a big headache involving both changes in the PATH and in the .py association. Does anybody know of other things to look out for ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/24/2010 6:25 AM, Mark Lawrence wrote: On 24/07/2010 04:17, Edward Diener wrote: Are there any documents about multiple versionsof Python coexisting in the same OS ( Windows in my case ) and what pitfalls to look out for ? I have already run into a number of them. I installed Python 2.7 and 3.1.2 into completely folders, but immediately ran into serious problems executing a Python script. The first problem is that just invoking Python will start whichever version is first in the PATH, and this is true from the command line or internally in a Python script. The second problem is that invoking a script ( some xxx.py ) will start whichever version of Python is associated with the .py extension. The third problem is if some software expects its scripts, which it puts in some Python subdirectory to be in the PATH. There may be other considerations but overall having to versions coexisting has turned out to be a big headache involving both changes in the PATH and in the .py association. Does anybody know of other things to look out for ? I found this only yesterday and found it extremely helpful, find the post by Gabriel Genellina. http://www.eggheadcafe.com/software/aspnet/35716114/maintain-2-versions-of-py.aspx I found the solutions too exotic for actual use, and completely ineffectual for the cases I originally cited. The people in that thread seem to have completely forgotten that Python can be invoked externally and internally both through executing 'python(w) xxx' and through executing a file with the file extension(s) associated with Python. They seem to have forgotten this can be within scripts or any other program using Python, both written by themselves and by others, and not just by their typing 'python(w) xxx' somewhere. Their solutions seem to believe that only they will externally be i9nvoking Python and only for their own written scripts, as opposed to the many libraries using Python as well as the Python distribution itself. The best solution is some program which changes the PATH and the Python file type associations depending on which version of Python one wants to use on one's own system when more than one Python version must coexist with others. I will probably write such a program for myself. Are the .py and .pyc extensions the only ones which are associated with Python or are there others, for a normal Python installation in Windows ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/24/2010 6:25 AM, Mark Lawrence wrote: On 24/07/2010 04:17, Edward Diener wrote: Are there any documents about multiple versionsof Python coexisting in the same OS ( Windows in my case ) and what pitfalls to look out for ? I have already run into a number of them. I installed Python 2.7 and 3.1.2 into completely folders, but immediately ran into serious problems executing a Python script. The first problem is that just invoking Python will start whichever version is first in the PATH, and this is true from the command line or internally in a Python script. The second problem is that invoking a script ( some xxx.py ) will start whichever version of Python is associated with the .py extension. The third problem is if some software expects its scripts, which it puts in some Python subdirectory to be in the PATH. There may be other considerations but overall having to versions coexisting has turned out to be a big headache involving both changes in the PATH and in the .py association. Does anybody know of other things to look out for ? I found this only yesterday and found it extremely helpful, find the post by Gabriel Genellina. http://www.eggheadcafe.com/software/aspnet/35716114/maintain-2-versions-of-py.aspx I found the solutions too exotic for actual use, and completely ineffectual for the cases I originally cited. The people in that thread seem to have completely forgotten that Python can be invoked externally and internally both through executing 'python(w) xxx' and through executing a file with the file extension(s) associated with Python. They seem to have forgotten this can be within scripts or any other program using Python, both written by themselves and by others, and not just by their typing 'python(w) xxx' somewhere. Their solutions seem to believe that only they will externally be i9nvoking Python and only for their own written scripts, as opposed to the many libraries using Python as well as the Python distribution itself. The best solution is some program which changes the PATH and the Python file type associations depending on which version of Python one wants to use on one's own system when more than one Python version must coexist with others. I will probably write such a program for myself. Are the .py and .pyc extensions the only ones which are associated with Python or are there others, for a normal Python installation in Windows ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 6:07 AM, Gelonida wrote: Hi Edward, On 07/25/2010 04:40 AM, Edward Diener wrote: I found the solutions too exotic for actual use, and completely ineffectual for the cases I originally cited. The people in that thread seem to have completely forgotten that Python can be invoked externally and internally both through executing 'python(w) xxx' and through executing a file with the file extension(s) associated with Python. They seem to have forgotten this can be within scripts or any other program using Python, both written by themselves and by others, and not just by their typing 'python(w) xxx' somewhere. Their solutions seem to believe that only they will externally be i9nvoking Python and only for their own written scripts, as opposed to the many libraries using Python as well as the Python distribution itself. The best solution is some program which changes the PATH and the Python file type associations depending on which version of Python one wants to use on one's own system when more than one Python version must coexist with others. I will probably write such a program for myself. Hi Edward, changing the path and is perfect for people who use consoles. (under linux there's virtuelenv for his and it's great) changing the file association is perfect for people who'd know at which time they want to use which version of python. The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. The usecase, that I'm nore aware of however is somethig like having some scripts / directories, that should use one version of python and others that shoud use another. In unix you do this normally with the 'shebang line' ( e.g. #!/usr/bin/env/python2.6 ) There the windows solution could be something like a small 'pystarter' program, which would decide depending on the file's location / the file's first line which python should be started. This does not work when Python is invoked internally via a file association. That was the point of my saying that the simple solutions do not work. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 2:20 AM, Steven D'Aprano wrote: On Sat, 24 Jul 2010 22:03:48 -0700, Chris Rebert wrote: Are the .py and .pyc extensions the only ones which are associated with Python or are there others, for a normal Python installation in Windows ? There's also .pyw Also .pyo .py = Python source code, usually associated with command line Python .pyc = Python byte code .pyo = Python optimized byte code .pyw = is Windows only, and shouldn't open a console window. Thanks ! I had forgotten about .pyo and .pyw under Windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 1:51 PM, Joel Goldstick wrote: Edward Diener wrote: Are there any documents about multiple versionsof Python coexisting in the same OS ( Windows in my case ) and what pitfalls to look out for ? I have already run into a number of them. I installed Python 2.7 and 3.1.2 into completely folders, but immediately ran into serious problems executing a Python script. The first problem is that just invoking Python will start whichever version is first in the PATH, and this is true from the command line or internally in a Python script. The second problem is that invoking a script ( some xxx.py ) will start whichever version of Python is associated with the .py extension. The third problem is if some software expects its scripts, which it puts in some Python subdirectory to be in the PATH. There may be other considerations but overall having to versions coexisting has turned out to be a big headache involving both changes in the PATH and in the .py association. Does anybody know of other things to look out for ? There is this: http://pypi.python.org/pypi/virtualenv It appears to be only for Linux. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 10:03 AM, Thomas Jollans wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. Whether it is badly written or not in your opinion it is legal and happens all the time. Are you going to refuse to use any script, no matter for what library or for what purpose, that internally invokes Python either through a 'python' command or through a file with a Python extension ? And how would you find out if a script did this or not ? Are going to search every script in every distribution and library to determine if it does this ? And when you find out a script does this, what will you do ? Be real. saying you do not like scripts that internally invoke Python does not solve anything if you have multiple coexisting versions of Python installed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 10:31 AM, News123 wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: On 7/25/2010 6:07 AM, Gelonida wrote: There the windows solution could be something like a small 'pystarter' program, which would decide depending on the file's location / the file's first line which python should be started. This does not work when Python is invoked internally via a file association. That was the point of my saying that the simple solutions do not work. I'm not sure I understand. The ida is of course, that the file association would point to the pystarter and that pystarter would depending on directory / first line of the script identify the correct executable to be started with. Perhaps you could once more explain, what your intended solution would be. How does a 'pystarter' program know where the file's location is which is being invoked ? As to the first file line this is completely unrealistic. What are you going to do, alter the first file line of every script in a Python distribution and every script in every library installed in a Python distribution ? Sorry, but a less intrusive solution is much better and much less of a headache to say the least. My intended solution would be a simple program which understands where each co-existing Python distribution is installed on a system and what the "name" of that distribution is. Then you tell the program which Python distribution should be the current one by its "name", the current one meaning the distribution which you want to be invoked at any given time. The program then changes the PATH so that any references to the Python directory and its subdirectories point to the "name" Python directory tree, and changes the file associations so that the "name" Python executables handle the Python associations. This does have the weakness that I can not use more than one Python distribution while Python is executing scripts. But I can personally live with that since I have never encountered a situation where I must use more than one Python distribution at the same time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 3:32 PM, Thomas Jollans wrote: On 07/25/2010 09:19 PM, Edward Diener wrote: On 7/25/2010 10:03 AM, Thomas Jollans wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. Whether it is badly written or not in your opinion it is legal and happens all the time. Are you going to refuse to use any script, no matter for what library or for what purpose, that internally invokes Python either through a 'python' command or through a file with a Python extension ? And how would you find out if a script did this or not ? Are going to search every script in every distribution and library to determine if it does this ? And when you find out a script does this, what will you do ? Be real. saying you do not like scripts that internally invoke Python does not solve anything if you have multiple coexisting versions of Python installed. I doubt many scripts do it. The fact of the matter is: many systems have multiple Python versions installed in parallel, and it probably will break somewhere, which will get noticed, and probably fixed. If a script uses sys.executable instead of "python", there is no problem, at all. What a script uses to internally invoke Python I can not control. My solution seeks to be non-intrusive and lets me run a particular version of Python, among the co-existing versions installed, at any given time. I believe that is the best I can do. I neither can control, nor do I want to control, all of the Python scripts installed on my system, nor can I worry how they may internally invoke Python. But I do want to be able to say, at any given time, that when I run Python a particular version, amidst the co-existing ones on my system, needs to be executed and therafter all internally executed modules use that version. Trying to make rules for scripts, such as telling scripts they must use sys.executable, is pursuing an imaginary solution that can not work unless one is theoretically willing to manually inspect and change all Python scripts in some way. To me any intrusive changes to actual scripts is no solution at all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 3:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of "python", there is no problem, at all. It's true that sys.executable is the best way if you have to start a new Python interpreter. However sys.executable may not be set for NT services. So there may be a problem after all. Once you start instrusively changing scripts to find a solution to multiple versions of Python co-existing in one system, you are heading down a path of endless problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 4:22 PM, News123 wrote: On 07/25/2010 09:33 PM, Edward Diener wrote: On 7/25/2010 10:31 AM, News123 wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: On 7/25/2010 6:07 AM, Gelonida wrote: How does a 'pystarter' program know where the file's location is which is being invoked ? the file's location would be somewhere in sys.argv probably in sys.argv[1]. converting it to an abs path would return a directory which the python file belongs to. As to the first file line this is completely unrealistic. What are you going to do, alter the first file line of every script in a Python distribution and every script in every library installed in a Python distribution ? Sorry, but a less intrusive solution is much better and much less of a headache to say the least. Well I would at least do it for all of my self written scripts. It could allow a soft transition from 2.6 to 2.7 to 3.0 without having to upgrade all scripts at the same time. Intrusively changing scripts is a path to Python hell. My intended solution would be a simple program which understands where each co-existing Python distribution is installed on a system and what the "name" of that distribution is. Then you tell the program which Python distribution should be the current one by its "name", the current one meaning the distribution which you want to be invoked at any given time. The program then changes the PATH so that any references to the Python directory and its subdirectories point to the "name" Python directory tree, and changes the file associations so that the "name" Python executables handle the Python associations. This does have the weakness that I can not use more than one Python distribution while Python is executing scripts. But I can personally live with that since I have never encountered a situation where I must use more than one Python distribution at the same time. I guess it's rather difficult to find a solution which suits all. The above minor weakness, that you mention would be a killer for me. Currently I'm looking for solutions, where I can start python scripts requireing different python versions at the same time. If you need that, then of course my intended solution would not work. Currently I'm staring the scripts manually from two different cmd line windows with a different path name and an explicit python call, If you start scripts and point to a specific version of Python, this works in my solution also. But if an internal call to Python exists thwre is always a problem. Thus my idea of having a pystarter with a config file mentioning which directories (tools) should use which python executable Well, good luck ! I don;t know how this is resolved for you when some scripts executes 'python xxx yyy' or 'someScript.py yyy'. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 4:26 PM, News123 wrote: On 07/25/2010 10:18 PM, Thomas Jollans wrote: On 07/25/2010 10:04 PM, News123 wrote: sOn 07/25/2010 09:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of "python", there is no problem, at all. sys.executable will not work with scripts converted with py2exe, as sys.executable will not be the executable of the python interpreter, but with the main executable's name. Well, but a script converted with py2exe can't really ever assume that there is a Python interpreter, at all. true :-) However, why I thought about this is, that I write sometimes python code, which tries to call other python files. later on for distribution I use py2exe. Therefore I use wrapper functions, which will work in either case. The wrapper could use sys.executable in 'python mode' and had to call the exe file in 'py2exe mode' You can control what you do but how are you going to control what any givemn script does ? Attempting to intrusively change potentially every script in a distribution in any way is a path to Python hell IMO. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 5:57 PM, Thomas Jollans wrote: On 07/25/2010 11:10 PM, Edward Diener wrote: On 7/25/2010 3:39 PM, Christian Heimes wrote: Am 25.07.2010 21:32, schrieb Thomas Jollans: If a script uses sys.executable instead of "python", there is no problem, at all. It's true that sys.executable is the best way if you have to start a new Python interpreter. However sys.executable may not be set for NT services. So there may be a problem after all. Once you start instrusively changing scripts to find a solution to multiple versions of Python co-existing in one system, you are heading down a path of endless problems. What exactly is it that you're afraid to change? I do not want to intrusively change any script that has been installed as part of Python. I shouldn't even have to know about the code in these scripts other than what good documentation tells me in how to use them. That's not to say having source is worthless. I am just not going to change source to get a version of Python to work properly when I have 2 or more versions installed in their own separate folders. The standard library? There's certainly no need to change that in any way! So if a standard library module ( or distributed library ) executes a call internally to 'python xxx yyy' or executes a call internally to 'someScript.py yyy', you're fine with multiple co-existing versions of Python on your system ? Because under Windows the first call will look for the python.exe first found in the PATH while the second call will find the python.exe associated with the .py extension. And it does not matter in either case what version of the multiple installed versions of Python which are on my system is currently executing that script. And please don't say that there is some sort of guarantee that no library or installation would invoke Python in such a way as opposed to the normal 'import AScript.py' method of using functionality in Python scripts. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 8:41 PM, Steven D'Aprano wrote: On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote: On 7/25/2010 10:03 AM, Thomas Jollans wrote: On 07/25/2010 02:46 PM, Edward Diener wrote: The problem with this is that you forget that a script can invoke Python internally. So whether one uses the console or file association method of invoking Python externally, any already written script can use either internally. Maybe it's just me, but I think that a script that does this is quite simply badly written: it *will* break on systems that have multiple Python versions. Whether it is badly written or not in your opinion it is legal and happens all the time. Yes, people write poorly written, buggy scripts all the time. Just because code is legal syntax doesn't mean it does what is intended, or that what is intended is sensible. If you have multiple versions of Python installed, and you call "python somescript.py" without knowing *which* Python will be called, it is neither sensible nor does it do what you intend. End of story. Somebody is supplying you with a Python script and internally invoking Python again. But that somebody does not have to be myself. I am neither buying "End of story" nor that invoking Python internally is an error. But if you believe it to be then you can root out all such Python code, or correct it as you like. Even with co-existing versions of Python installed I have better things to do with my time and therefore will pursue a solution that will work for me in the face of such code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiple versions of Python coexisting in the same OS
On 7/25/2010 10:42 PM, David Robinow wrote: On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener wrote: On 7/25/2010 5:57 PM, Thomas Jollans wrote: So if a standard library module ( or distributed library ) executes a call internally to 'python xxx yyy' or executes a call internally to 'someScript.py yyy', you're fine with multiple co-existing versions of Python on your system ? Because under Windows the first call will look for the python.exe first found in the PATH while the second call will find the python.exe associated with the .py extension. And it does not matter in either case what version of the multiple installed versions of Python which are on my system is currently executing that script. And please don't say that there is some sort of guarantee that no library or installation would invoke Python in such a way as opposed to the normal 'import AScript.py' method of using functionality in Python scripts. Edward, I'm having a really hard time understanding your problem. Could you give an example of some real code that is causing you difficulty? I start a Python script for version X by going to X's root directory and invoking 'python someScript.py' from the command line. Does that not sound reasonable ? In SomeScript.py there is an internal call to 'python someOtherScript.y someParameters'. But the call invokes another version of Python because it is that version which is in the PATH. Or in SomeScript.py there is an internal call to 'someOtherScript.py someParameters'. But the call invokes another version of Python because the .py extension is associated with a different version. My solution is that I will write some code which sets a particular version of Python as the current version for a particular time, meaning that version will be in the PATH and associated with Python extensions. The way I do not have to worry when I externally invoke Python from the command line that internal calls are going to some other version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is python not written in C++ ?
On 8/2/2010 5:42 PM, Mark Lawrence wrote: On 02/08/2010 00:08, candide wrote: Python is an object oriented langage (OOL). The Python main implementation is written in pure and "old" C90. Is it for historical reasons? C is not an OOL and C++ strongly is. I wonder if it wouldn't be more suitable to implement an OOL with another one. Has it ever been planned to rewrite in C++ the historical implementation (of course in an object oriented design) ? I can't understand why any serious programmer mentions C++. As soon as I read it, I have to rush either to the kitchen to find a bowl to throw up in, or head for the toilet so I can talk to the great white telephone. It must be because we can not be as phenomenally intelligent as you evidently are from your comment. -- http://mail.python.org/mailman/listinfo/python-list
Python component model
The definition of a component model I use below is a class which allows properties, methods, and events in a structured way which can be recognized, usually through some form of introspection outside of that class. This structured way allows visual tools to host components, and allows programmers to build applications and libraries visually in a RAD environment. The Java language has JavaBeans as its component model which allows Java applications to be built in a visual RAD way. Microsoft's .Net has a component model built-in to its .Net class libraries as well as supported by CLR which allows .Net applications to be built visually using components created in any .Net supported language. With Python things are different. There is no single component model which allows Python developers to build components which will be used and recognized by the various RAD Python tools on the market. Instead a developer must create a slightly different set of Python classes for each RAD Python tool. This is the situation despite Python's having easily as much functionality, if not much more, as Java or .Net languages such as C#, VB, or C++/CLI for creating components, and for allowing visual tools to introspect the properties, methods, and events of Python classes. I believe that Python should have a common components model for all RAD development environments, as that would allow the Python programmer to create a set of classes representing components which would work in any environment. I want to immediately point out that components do not simply mean visual GUI components but what may be even more important, non-visual components. Having used RAD development environments to create applications, I have found such environments almost always much better than coding complex interactions manually, and I believe that visual development environments are almost a necessity in today's world of large-scale, multi-tier, and enterprise applications. Has there ever been, or is there presently anybody, in the Python developer community who sees the same need and is working toward that goal of a common component model in Python, blessed and encouraged by those who maintain the Python language and standard modules themselves ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
[EMAIL PROTECTED] wrote: > Edward> The definition of a component model I use below is a class which > Edward> allows properties, methods, and events in a structured way which > Edward> can be recognized, usually through some form of introspection > Edward> outside of that class. This structured way allows visual tools > Edward> to host components, and allows programmers to build applications > Edward> and libraries visually in a RAD environment. > > ... > Edward> I believe that Python should have a common components model for > Edward> all RAD development environments, as that would allow the Python > Edward> programmer to create a set of classes representing components > Edward> which would work in any environment. > > Having never used java or .NET I'm not sure what you're looking for. Does > Python's current introspection not work? Is it someone too unstructured > (whatever "structured" means)? Can you give a simple example? In the typical RAD development environment, a particular component model allows one to drop components, which are classes corresponding to a particular inner representation which tells the development environment what are the "properties" and "events" of that component, and subsequently set "properties" for that component and add handlers for its "events" visually. Subsequently When the components are instantiated at run-time, the particular "properties" are automagically set and the particular "events" are automagically tied to event handlers in other classes ( usually a window, or form, although it can be in any other class which can handle events ). How this "automagically" is done depends on the visual development environment. I find it very neat that I, the end-user of the component, does not have to write the boiler-plate code to set "properties" and hook up "events" and can do this visually. I realize that others may find this unimportant. But in a visual environment where not only non-viusual components are involved, but also visual GUI components are, this also allows the visual look of a particular window ( form or screen if you like ) to be composed automatically. At the same time hooking non-visual components automagically at design time so that they are connected at run-time to event handlers is also very nice. In order to make such a system work, the visual RAD environment needs to know what in a class makes it a component, and what in that components specifies the "properties" and "events" for which it will automagically setup the correct "code" which works at run-time. Without a component model to tell it these things, it can not work to produce the boiler-plate code necessary to set "properties" and hook event handlers to an event. In JavaBeans, for Java, and the System.ComponentModel namespace, as well as properties, delegates, and events in .Net, there exists a common component model which defines, in these environments, what a components is so that the visual RAD development can do its magic. I realize that many Python programmers don't see the necessity for having a RAD visual devlopment environment doing for them what they can do by hand in their Python code, particularly in the constructor to classes. But there are people who have used such a RAD model, particularly when setting up a GUI application or Web application, who appreciate the ease of use of such a RAD visual environment, especially in the area of dropping visual controls on a window and having that window appear at run-time with the particular look which they have visually setup at design time. But even beyond the more common visual setup of a window or web page, a visual RAD environment allows the end-user programmer to visually create boiler-plate code for setting the "properties" and "events" of non-visual classes, which make up the greater part of the internal logic of any given program. More importantly a common component model, which works in any language's visual RAD environment, enables the development and re-use of components which are as easily used as dropping that component from a component palette onto a visual container, usually a representation of a run-time window, and setting it's "properties" and/or "events". The visual manipulation of components does not preclude making manipulations at run-time through code also if necessary, and all visual environements allow the setting of "properties" and "events" at run-time also in the usual way. If one has used Borland's Delphi or C++ Builder IDEs, or Sun's NetBeans or IBM's Eclipse for Java, or Microsoft's Visual Studio for .Net, one knows what I mean as far as a visual RAD environment. All of these are made possible by a common component model which different development environments can use. There's nothing wrong with Python's introspection. In fact Python's facilities in this area and its support for metadata are stronger than
Re: Python component model
Echo wrote: > On 10/9/06, Edward Diener No Spam <[EMAIL PROTECTED]> > wrote: >> The definition of a component model I use below is a class which allows >> properties, methods, and events in a structured way which can be >> recognized, usually through some form of introspection outside of that >> class. This structured way allows visual tools to host components, and >> allows programmers to build applications and libraries visually in a RAD >> environment. >> >> The Java language has JavaBeans as its component model which allows Java >> applications to be built in a visual RAD way. Microsoft's .Net has a >> component model built-in to its .Net class libraries as well as >> supported by CLR which allows .Net applications to be built visually >> using components created in any .Net supported language. >> >> With Python things are different. There is no single component model >> which allows Python developers to build components which will be used >> and recognized by the various RAD Python tools on the market. Instead a >> developer must create a slightly different set of Python classes for >> each RAD Python tool. This is the situation despite Python's having >> easily as much functionality, if not much more, as Java or .Net >> languages such as C#, VB, or C++/CLI for creating components, and for >> allowing visual tools to introspect the properties, methods, and events >> of Python classes. >> >> I believe that Python should have a common components model for all RAD >> development environments, as that would allow the Python programmer to >> create a set of classes representing components which would work in any >> environment. I want to immediately point out that components do not >> simply mean visual GUI components but what may be even more important, >> non-visual components. Having used RAD development environments to >> create applications, I have found such environments almost always much >> better than coding complex interactions manually, and I believe that >> visual development environments are almost a necessity in today's world >> of large-scale, multi-tier, and enterprise applications. >> >> Has there ever been, or is there presently anybody, in the Python >> developer community who sees the same need and is working toward that >> goal of a common component model in Python, blessed and encouraged by >> those who maintain the Python language and standard modules themselves ? >> -- >> http://mail.python.org/mailman/listinfo/python-list >> > > > If you are talking about about creating a GUI and having be able to > run using different GUI libraries like Tkinter, wxPython, wxgtk, ect. > You could look into Dabo(http://dabodev.com/). It is designed so that > you can design your GUI and have it run with what ever GUI library you > want(only wxPython is supported at the moment. And I think that > Tkinter works somewhat.) It's not just for GUI controls that a component model exists in the other environments I mentioned. Non-GUI components are intrinsically as important, if not more so, to a component model architecture. Also, quite honestly, I think a component model would have to be specified by the core Python developers instead of retrofitted against the popular GUI environments for Python which currently exist. Also I admit I am no fan of wx-you-name-it, whose "event" model especially I find way too limiting and ineffective in relation to the entire area of component-based programming and events. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Chaz Ginger wrote: > Edward Diener No Spam wrote: >> [EMAIL PROTECTED] wrote: >>> Edward> The definition of a component model I use below is a class >>> which >>> Edward> allows properties, methods, and events in a structured way >>> which >>> Edward> can be recognized, usually through some form of introspection >>> Edward> outside of that class. This structured way allows visual >>> tools >>> Edward> to host components, and allows programmers to build >>> applications >>> Edward> and libraries visually in a RAD environment. >>> >>> ... >>> Edward> I believe that Python should have a common components >>> model for >>> Edward> all RAD development environments, as that would allow the >>> Python >>> Edward> programmer to create a set of classes representing components >>> Edward> which would work in any environment. >>> >>> Having never used java or .NET I'm not sure what you're looking for. >>> Does >>> Python's current introspection not work? Is it someone too unstructured >>> (whatever "structured" means)? Can you give a simple example? >> In the typical RAD development environment, a particular component model >> allows one to drop components, which are classes corresponding to a >> particular inner representation which tells the development environment >> what are the "properties" and "events" of that component, and >> subsequently set "properties" for that component and add handlers for >> its "events" visually. snip... >> > > Why not propose something. That is the easiest way to get things moving. How does one do that ? Propose something here on this NG or is there some other official way ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Robert Kern wrote: > Edward Diener No Spam wrote: > >> There's nothing wrong with Python's introspection. In fact Python's >> facilities in this area and its support for metadata are stronger than >> any of these other languages ! However there is no common component >> model which specifies that X is a "property" or Y is an "event" of a >> Python class which can be visually manipulated at design-time and >> automagically set at run-time, so that any given Python RAD visual >> environment will treat a Python class, specified as a component, in >> exactly the same way. Also in these other languages, a component is >> different from a class in that a component is recognized in a >> particular way, often so that the component can interact if necessary >> with its container and/or visual site. > > You'll definitely want to take a look at Enthought's Traits (disclaimer: > I work for Enthought). I'm supposed to be on vacation now, so I'm not > going to give you the full rundown of Traits and Traits UI, so I'm > simply going to point you to the page we have about it: > > http://code.enthought.com/traits/ It looks as if traits is an attempt to create a "property" in the component terminology which I originally specified. I will take a look at it. > > You can talk to the rest of the Enthought crew on the enthought-dev > mailing list if you have any questions: > > https://mail.enthought.com/mailman/listinfo/enthought-dev Already subscribed. Thanks ! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
goon wrote: >> or IBM's Eclipse for Java > > Or Eclipse for Python using PyDev? [0] Those are very nice features but there is no re-usable Python bean support like there is a Java bean. That was my initial point. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Michael wrote: > Edward Diener No Spam wrote: > >> Has there ever been, or is there presently anybody, in the Python >> developer community who sees the same need and is working toward that >> goal of a common component model in Python, blessed and encouraged by >> those who maintain the Python language and standard modules themselves ? > > Someone aiming towards a standard to /replace/ everyone else's? That > presupposes a level of arrogance that seems unusual in the python world. > (whilst everyone's proud of their own code and they _generally_ respect > other people's even if it's not their cup of tea). The reason I would like to see a standard component model for Python is so 3rd party developers could create their classes to conform to this model and work in any RAD IDE environment which adapts it. That's the way JavaBeans work, that the way Borland's VCL component model works, and that's the way .Net works. When there are many different component models, the 3rd party developer must adapt their components to each model for a particular environment. But far be it from me to want to replace everybody else's model . By your reasoning above, standardizing anything in software is an arrogant proposition. Whereas I look at standardization, when it is well done, as a boon to programmers. > > The WSGI standard could be a form of component model, and has gone through > the PEP process so that might match your criterion. I do not know what it is but I will look it up. > As for component > models, they do exist. > > Our component model on the Kamaelia project [1] is one that's heavily > designed around the idea of composition and independent execution of > components and message passing (message passing maps to events for some > sorts of message), >[1] http://kamaelia.sourceforge.net/Home I will look at kamaelia. Thanks ! > > I wouldn't think of proposing it as the single standard to rule them all > though, for the simple reason every approach has its own strengths. (We do > find the approach extremely useful though) > > If you want a quick example of the core ideas, a tutorial aimed around > building a massively simplified core is here: >http://kamaelia.sourceforge.net/MiniAxon/ > > If you want to see a substantial example, you can look here: >* http://tinyurl.com/oqjfb - whiteboarding with audio where every client > is a server. The entire resulting system is also a component. > > For something more simplistic: >* http://kamaelia.sourceforge.net/Examples/SimplestPresentationTool.html > > Something halfway in terms of complexity (a PVR for transcoding everything > broadcast on digital TV): >* http://tinyurl.com/lvygq > (OK, you need to add more channels, but you'd need more CPU's too) > > We also have tools for introspecting a running system, and also a visual > composition tool (called Compose) [2] for creating simple systems > graphically, and that, as you say, handles a significant chunk of > dreariness. Suggestions on improving the model and composition tool are > very welcome, code is even more welcome :) > >[2] Sample system created with the newest version of Compose: > http://tinyurl.com/numwk >Compose is also a Kamaelia system, and can be found here: > http://tinyurl.com/p7z76 >(bulk of the wiring up is in the bottom of the file - this is an >interesting example because of the use of Pygame and Tk for different >parts of the interface where appropriate) > > > However, off the top of my head, you should also look at Zope's component > model, Trac's component model, Twisted's model & PEAK, and any proposal > to say "this is the solution", needs to be compelling for all of these > projects. A standard component model could be used as a base for other more advanced needs. Most of those mentioned above seem to involve web application frameworks whereas my idea of a component model just assumes the paradigms of properties, methods, and events which may allow re-usable components at a base level in any environment. A particular implementation is certainly allowed to build a more complicated idea of a component, through inheritance, from a base level component, and this is in fact the way that most components work in current component model environments I have mentioned. For instance in .Net a control is a component with other added qualities. So while one could build components which are not controls, it is necessary to add functionality to the base level idea of a component in order to create a control. > > Note, they do change where there's a benefit - twisted adopted some > int
Re: Python component model
Nick Vatamaniuc wrote: > Edward Diener No Spam wrote: >> Michael wrote: > > Python does not _need_ a component model just as you don't _need_ a RAD > IDE tool to write Python code. The reason for having a component model > or a RAD IDE tool is to avoid writing a lot of boiler plate code. > Python is terse enough that boiler plate code is not needed, just type > what you need into an editor. It seems that you talk about Python but > you are still thinking in Java or C++. A RAD IDE tool to hook up components into an application or library ( module in Python ) has nothing to do with terseness and everything to do with ease of programming. All you are saying is that you don't have a need for this, but perhaps others do. I don't mind others saying they have no need or seeing no benefit. But if you have ever used a visual design-time environment for creating applications you might feel differently. "Thinking in Java or C++" as opposed to Python does not mean anything to me as a general statement. I am well aware of the difference between statically and dynamically typed languages but why this should have anything to do with RAD programming is beyond me. Do you care to elucidate this distinction ? > > At the same time one could claim that Python already has certain > policies that makes it seem as if it has a component model. Take a look > at the "magic methods". For example if a class has a __len__ method, it > is possible to use the len() function on an instance of that class. If > a class has the __getitem__ then indexing can be used on that class's > insance. Then Python has properties (see > http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html). Just by > inspecting the object one can tell a great deal about them (even read > the documentation if needed, by using the __doc__ attribute). What > other standards would you propose for the core language? Python has great facilities for a component model, much better than the other languages I use regularly ( C++, C#, Java ). I am not arguing against that. A component model for RAD tools allows the tool to expose properties and events to the end-user at design time so that at run-time the properties and events are automatically setup once an object is instantiated. The essence of a component model for RAD programming is how one specifies properties and events for a class to be manipulated by the RAD tool at design time. Another obvious part of the component model is how one specifies that the properties and events one sets up at design-time are serialized so that at run-time they are properly set. A final element of a component model is the ability of a component to interact with the environment in which it exists at design time, through property editors, and at run-time, the latter being obviously more important for visual controls than non-visual components. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Rubin wrote: > "Nick Vatamaniuc" <[EMAIL PROTECTED]> writes: >> Python does not _need_ a component model just as you don't _need_ a RAD >> IDE tool to write Python code. The reason for having a component model >> or a RAD IDE tool is to avoid writing a lot of boiler plate code. > > It's also so that applications written in differing languages can call > each other. That's a possible reason, but with JavaBeans and EJBs for Java there is just a single language and I am sure there are many Java programmers who enjoy using Eclipse, NetBeans, or JBuilder to name a few RAD IDEs which allow them to create their applications using a design-time visual environment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Diez B. Roggisch wrote: > Paul Rubin schrieb: >> "Nick Vatamaniuc" <[EMAIL PROTECTED]> writes: >>> Python does not _need_ a component model just as you don't _need_ a RAD >>> IDE tool to write Python code. The reason for having a component model >>> or a RAD IDE tool is to avoid writing a lot of boiler plate code. >> >> It's also so that applications written in differing languages can call >> each other. > > Nope. Things like CORBA and COM do have that property, but e.g. the Java > beans spec has only a meaning inside the VM. Not sure about .NET, but I > can imagine there it's the same thing. > > All the languages he mentioned are statically typed, or the component > models themselves are. So the component model is basically needed (as > others also mentioned) to glue things together, to dynamize that - > whereas python is dynamic on the first hand, and actually lacks static > typing to infer component properties... While I understand dynamic typing, I still think it is possible to create attributes in a Python component model which could tell a RAD tool what type the attribute will encompass for the purpose of properties and events. Obviously a "name, type" tuple, among other possible information would have to be used. But given Python's amazingly flexible type and introspection system, this should be possible. Of course I am not trying to change the nature of normal Python attributes per se at all, and one of the most important things in a property-method-event component model is to be able to specify properties that are distinct from just normal object data members. So one of the most important things in a Python component model would be the ability to tag component properties as totally distinct from normal Python class attributes or property attributes. Given that Python already has new-style class properties, maybe another name for the component properties I envision is needed to avoid confusion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Steve Holden wrote: > Diez B. Roggisch wrote: > [...] >>> Just the same, one can use IronPython to call components written in >>> other languages. And, I believe, vice versa. >> >> >> Sure, as I can do it in jython. But the key point is: can your ordinary >> python-object be published as a component? At least for jython I can >> say "no", you will have to subclass an already existing >> java-object/interface. And I have difficulties imagining that it is any >> different in .NET - because I've read statements that claimed that the >> structure of the VM/runtime is orientied towards single-inheritance >> statically typed languages as C#/java. >> > The answer to this question is currently beyond me. Maybe someone who > knows more about IronPython can elucidate. I do know (as you probably do > also) that Python generates code for the .NET CLR, however. I am not sure about current IronPython functionality but the end result is that one should be able to create .Net components and classes using Python with IronPython just as one does in C#, C++/CLI, or VB .NET. But this is not creating a component model for Python except in the .Net environment, which essentially means Windows unless IronPython will work under Mono, and Microsoft does not kill Mono. I don't think all those "ifs" is something a Python programmer wants to deal with in possible RAD component development. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: > Nick Vatamaniuc wrote: > >> At the same time one could claim that Python already has certain >> policies that makes it seem as if it has a component model. > > every Python object surely qualifies as a component, for any non-myopic > definition of that word, and everything inside a Python program is an > object. so yes, Python has a component model, and Python programmers > are using that model all over the place. > > what might be missing is support for publishing additional metadata > using a standardized vocabulary, and a way to access that data with- > out having to actually create the object. > > implementing this using existing mechanisms is trivial (as the endless > stream of interface/component/adapter/trait implementations have shown > us); coming up with a good-enough-to-be-useful-for-enough-people > vocabulary is a lot harder. There's no doubt that Python's excellent introspection mechanism allows an outside RAD-like tool to inspect the workings of any Python object. But that does not make it a component model in my original use of the term on this thread. A RAD tool needs to know what properties and events within a class can be manipulated visually, and it needs to be able to serialize those properties and events so that they are set at run-time automatically once an object is created. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Michael Sparks wrote: > Edward Diener No Spam wrote: >> Michael wrote: >>> Edward Diener No Spam wrote: >>> >>>> Has there ever been, or is there presently anybody, in the Python >>>> developer community who sees the same need and is working toward that >>>> goal of a common component model in Python, blessed and encouraged by >>>> those who maintain the Python language and standard modules themselves ? >>> Someone aiming towards a standard to /replace/ everyone else's? That >>> presupposes a level of arrogance that seems unusual in the python world. >>> (whilst everyone's proud of their own code and they _generally_ respect >>> other people's even if it's not their cup of tea). >> The reason I would like to see a standard component model for Python is >> so 3rd party developers could create their classes to conform to this >> model and work in any RAD IDE environment which adapts it. That's the >> way JavaBeans work, that the way Borland's VCL component model works, >> and that's the way .Net works. When there are many different component >> models, the 3rd party developer must adapt their components to each >> model for a particular environment. >> >> But far be it from me to want to replace everybody else's model . > > Well that's the thing you *do* want since you want the previous > paragraph ;-) > (Or at least a way to adapt component models.) I was being funny above. Yes I would like to establish a basic component model for RAD development in Python. But surely it need not replace all others but could serve at least as a base class for other derived models for various environments. That way a developer writing a Python component could have it work in these environments as a simple component and more complex components, tailored to that environment could be created as necessary through inheritance. > >> By your reasoning above, standardizing anything in software is an >> arrogant proposition. Whereas I look at standardization, when it is well >> done, as a boon to programmers. > > OK, maybe I was being a bit strong - I was merely thinking "lots of > people have something like this already, and I've not seen anyone push > their model as THE model", (even if lots of people like *their* model > :-) > > However, I was also being a bit tongue in cheek, though I should have > said unreasonable, not arrogant: >"...all progress depends on the unreasonable man." -- Bernard Shaw. Bravo, Shaw. Of course by unreasonable I assume Shaw meant those using imagination and inspiration along with logic and reason. > > What could have some mileage though is proposing a standard way for > these component models to interoperate. What that would look like > (given the wildly different models :), is another matter and an > exercise for the interested reader ;-) > >>> The WSGI standard could be a form of component model, and has gone through >>> the PEP process so that might match your criterion. >> I do not know what it is but I will look it up. > > NB, I'm using component model in it's loosest form there. > >>> As for component >>> models, they do exist. >>> >>> Our component model on the Kamaelia project [1] is one that's heavily >>> designed around the idea of composition and independent execution of >>> components and message passing (message passing maps to events for some >>> sorts of message), >>>[1] http://kamaelia.sourceforge.net/Home >> I will look at kamaelia. Thanks ! > > You're welcome. Any deficiencies or improvements or suggestions you've > got would be very welcome (I can see some which we're planning on > addressing at some point, but fresh critical eyes are always welcome). > >>> However, off the top of my head, you should also look at Zope's component >>> model, Trac's component model, Twisted's model & PEAK, and any proposal >>> to say "this is the solution", needs to be compelling for all of these >>> projects. >> A standard component model could be used as a base for other more >> advanced needs. Most of those mentioned above seem to involve web >> application frameworks whereas my idea of a component model just assumes >> the paradigms of properties, methods, and events which may allow >> re-usable components at a base level in any environment. > > They do, however in particular, Trac's model whilst web oriented > strikes me personally as interesting and PEAK's is applicable, as I > understa
Re: Python component model
Richard Brodie wrote: > "Edward Diener No Spam" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >> "Thinking in Java or C++" as opposed to Python does not mean anything to me >> as a general >> statement. I am well aware of the difference between statically and >> dynamically typed >> languages but why this should have anything to do with RAD programming is >> beyond me. Do >> you care to elucidate this distinction ? > > I think this blog entry http://osteele.com/archives/2004/11/ides > provides some insight into the point of view expressed. I think that one can easily be both, someone who is good at using a language and someone who is good at using a visual tool. The dichotomy presented in the article exists only for a small number of people. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: > "Edward Diener No Spam" wrote: > >> A RAD IDE tool to hook up components into an application or library ( >> module in Python ) has nothing to do with terseness and everything to do >> with ease of programming. > > python already has excellent and ridiculously easy-to-program ways to hook > things up. after all, hooking things up is what python programmers tend to > do, > most of their time. I agree. > > if you want better support for more precise hooking, post some examples. I want a design-time environment to hook up my objects in a visual way. I think it is easier than doing it manually, even in Python. > >> All you are saying is that you don't have a need for this, but perhaps >> others do. > > handwavy references to what "other may need" is another thing you should > avoid if you want your Python change proposal to be successful. I did not say what "others may need". -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Diez B. Roggisch wrote: >> While I understand dynamic typing, I still think it is possible to >> create attributes in a Python component model which could tell a RAD >> tool what type the attribute will encompass for the purpose of >> properties and events. Obviously a "name, type" tuple, among other >> possible information would have to be used. But given Python's amazingly >> flexible type and introspection system, this should be possible. > > The amazing flexibility stems from the fact that it is _runtime_. This is > _exactly_ the difference between static and dynamic typing. > > If a static analysis (_not_ importing the module, which can trigger > arbitrary code being run!!!) is supposed to deliver the component > architecture, you are either introducing static typing, or get into the > danger of lose coupling between declaration and implementation, rendering > the whole thing pretty useless. Yes, I am suggesting static typing functionality for a subset of Python attributes. How this can be done I am still investigating on my own. > > Of course, with a bit of discipline, you can create such a introspection > facility that offers its properties after a mere import, see ZOPE > interfaces for example. > > But in the end, it boils down to declaring stuff for that purpose alone, and > introducing static typing, whereas other languages declare typing for their > own needs, and add the component model upon that. > > And then you lose a _lot_ of what python makes powerful, for a very doubtful > benefit IMHO. Adding a feature, such as static typing functionality for the situation of doing visual RAD programming, does not "lose a _lot_ of what makes python powerful". My idea of adding static typing is not an attempt to change the language but rather to develop Python classes which encapsulate the idea of a variable and a type for the purposes of emulating component properties and component events. If a language addition is needed instead I will investigate how to propose it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Tim Chase wrote:
>> There's no doubt that Python's excellent introspection mechanism
>> allows an outside RAD-like tool to inspect the workings of any Python
>> object. But that does not make it a component model in my original use
>> of the term on this thread. A RAD tool needs to know what properties
>> and events within a class can be manipulated visually, and it needs to
>> be able to serialize those properties and events so that they are set
>> at run-time automatically once an object is created.
>
> A little visual inspection of some objects:
>
> [EMAIL PROTECTED]:~$ python
> Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
> [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class Person(object):
> ... def __init__(self, name, age=None):
> ... self.name = name
> ... self.age = age
> ... def whoami(self):
> ... if self.age is not None:
> ...return "%s (%i)" % (
> ...self.name,
> ...self.age)
> ... return self.name
> ...
> >>> p = Person("Sandy")
> >>> [s for s in dir(p) if not s.startswith('_') and
> callable(eval('p.%s' % s))]
> ['whoami']
> >>> [s for s in dir(p) if not s.startswith('_') and not
> callable(eval('p.%s' % s))]
> ['age', 'name']
>
> Thus, you have the ability to find an object's methods/events (things
> that are callable()), and its properties (things that are not
> callable()). Any "RAD" tool that wants can pull these properties, just
> as my command-line RAD tool can ;)
Not all attributes are component properties in typical Visual RAD tool.
In most visual RAD tools which I have used a component property is a
publicly exposed type/name which may or may not have the backing of an
actual data member and does have a function to get the type's value if
the property is readable and does have a function associated with it to
set the type's value if the property is writable. This is very close to
the class properties in Python. The difference is that normally a type
must be associated with a property whereas in Python, as I understand
it, the type of a class property is unknown.
Furthermore by a component event I do not mean methods on the event
creator's side but rather an event source. This would look something
like a tuple of callable functions of a particular signature to which an
event sink could add an event handler so that when a particular event
occurred on the event source the event handlers added to the event
source would each be called.
>
> As for serializing them,
>
> >>> import shelve
> >>> d = shelve.open('tmp/stuff.shlv')
> >>> d['person'] = p
> >>> p = 'hello'
> >>> p
> 'hello'
> >>> p = d['person']
> >>> p.whoami()
> 'Sandy'
> >>> p.age = 42
> >>> p.whoami()
> 'Sandy (42)'
> >>> d['person'] = p
> >>> d.close()
> >>> p = 'hello2'
> >>> p
> 'hello2'
> >>> d = shelve.open('tmp/stuff.shlv')
> >>> p = d['person']
> >>> p.whoami()
> 'Sandy (42)'
>
> which seems to work fine for me. This can be used for creating all
> sorts of flavors of objects at design time, storing them, and then
> restoring them at runtime.
I realize that Python has excellent abilities in all these areas,
including serialization. But a component model for serialization must
not only have the ability of serializing and deserializing all of the
component's data, as well as any base classes, it must also have a means
of allowing the class itself to specify which data needs to be
serialized and which not, as well as allow for the class to seriliaze
all or part of its own data.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: > Edward Diener No Spam wrote: > >> There's no doubt that Python's excellent introspection mechanism allows >> an outside RAD-like tool to inspect the workings of any Python object. >> But that does not make it a component model in my original use of the >> term on this thread. A RAD tool needs to know what properties and events >> within a class can be manipulated visually, and it needs to be able to >> serialize those properties and events so that they are set at run-time >> automatically once an object is created. > > external serialization was not part of your original definition. Well, knock me over. > > I think you have to be a *lot* more concrete here. repeatedly referring to > "some kind of hypothetical property (that isn't a property)" and "some kind > of hypothetical event (that isn't a public method)" and "some kind of hypo- > thetical RAD tool" won't get you anywhere. My OP was just to query whether a component model existed for Python, like JavaBeans for Java or .Net for C#, C++/CLI etc. After that came suggestions of what I thought such a component model was about, which I thought I answered generally. Not you want details. No doubt next will come a demand for code. OK, here is my idea of what such a component model envisages as a list of items. After this, unless I get some intelligent comments from people who might be interested in what I envision, or something very similar, I will be off to investigate it myself rather than do battle with the horde of people who will just tell me that Python, being a great language, does not need what I have suggested. 1) Component property: This is a glorified attribute with a type that can either be specified in a "static" manner, or always be discovered dynamically, or have converters back and forth between a string and the actual value represented by the component property. A component property has a getter function to retrieve the value if it is readable and a setter function to set the value if it is writable. It must be either readable or writable or both. A component property is not any Python class attribute since a component has the right to specify only certain values as manipulatable in a design-time RAD environment. 2) Component event: This is an type which encapsulates an array, or a list of callable objects with the same function signature, along with the functionality to add and remove elements from the array, as well as cycle through the array calling the callable objects as a particular event is triggered. A component event is an event source for a particular event. Component events have to be dicoverable by the Visual RAD system so that an object's appropriate event handler, an event sink, can be hooked to the component event itself, an event source, through a design time interface which propagates the connection at run-time. 3: Component serialization: A component which has its properties and events set by a visual design-time RAD environment needs to be serialized at design time and deserialized at run-time. This can be a default serialization of all component properties and events, or the component itself can participate in the serilization effort either wholly or partly. 4) Custom property and component editors: A component editor can present a property editor or an editor for an entire component which the visual design-time RAD environment can use to allow the programmer end-user of the component to set or get component property values. Normally a design time environment will present default property editors for each component property type, but a component can override this. 5) Custom type converters: A component should be able to specify a custom converter for any property to convert, in both directions or either direction, between the property's string value as seen by a property editor and the actual value of the component property's type. This is the general gist of those things which are needed in a visual Design-time RAD environment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Paul Boddie wrote: > [EMAIL PROTECTED] wrote: >> Edward> My OP was just to query whether a component model existed for >> Edward> Python, like JavaBeans for Java or .Net for C#, C++/CLI >> Edward> etc. >> >> For those of us who've never used Java, .Net or C++/CLI, a more concrete >> description of what you were after from the beginning would have been >> helpful. > >>From vague recollections of the original Java Beans technology, the > primary "innovation" was to have getProperty and setProperty methods, > along with things like isCapability and hasProperty, if I remember > correctly. None of this was really shocking to anyone using Python, > mostly because Python had __getattr__ and __setattr__ even back then > for customising real property/attribute access, and Python's run-time > introspection capabilities were superior to Java's (and probably still > are). There is no argument on my part that Python's introspection and metadata capabilities are superior to Java, as well as its potential attribute as component property model. In the theoretical Python model I proposed, the designer of the component must have the ability to specify which of the component's attributes are properties and how this is controlled ( via __getattr__ and __setattr__ ? descriptors as someone else suggested ? other ideas ? ). Merely saying that all of an object's attributes are component properties for the purposes of a visual RAD designer can not be correct. I actually think that Java's notion of preoperties in JavaBeans, which are just getter and setter functions with a particular naming convention, determined by Java as a default, or through an associated BeanInfo class, is rather klutzy and much prefer that of .Net or Borland's VCL where a particular language construct is used for properties instead. Of course with Python's superior metadata abilities, a particular new language construct shouldn't be necessary. > > The other innovation was the introduction of standard interfaces for > listening to and dispatching events, where you implement some listener > interface and respond to events in order to "care about" those events. > I don't recall any particularly good mechanisms for connecting beans to > each other in order to fire off events, although the beanbox (or > whatever the graphical tool originally promoted was called) and/or the > IDE is supposed to help you with that part of the work. The beanbox did nothing to help setup events, event sources, or event listeners. It just presented a graphical example of a visual RAD tool which could tie event sources to event listeners. It is onerous in JavaBeans to connect event sources to event listeners, and takes a good deal of manual coding although doing it is easy to understand. > > The groovy 1990s API 1997. Again Borland's VCL or .Net have much better solutions for events but again require language constructs which Python ought not need given its strong metadata possibilities to supply a component event model. > is actually viewable in various places; here, for > example: > > http://www.doc.ic.ac.uk/~jpc1/linux/bdk-doc-1.0/apis.html The BDK is no longer supported in the latest version of Java and JavaBeans. Instead there is a Bean Builder at https://bean-builder.dev.java.net/ . > > Despite the supposedly exciting advances heralded by Java Beans, a > large part of the technology was just codifying existing practices and > techniques, but it could be argued that such techniques have been > superseded by signal/slot mechanisms and more advanced event > architectures (pioneered by frameworks like Qt and since adopted by > Gtk, I believe). I agree and I would want to have a component event model for Python that is much superior to the JavaBeans event model in ease of use. A much better ideal for component properties and component events is presented by .Net, where there are actual language keywords which perform the magic. I would guess that Qt and Gtk also follow a better ease of use path, perhaps with macros in C++. But Python should be able to do as good or better than any of these environments. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
fumanchu wrote:
> Edward Diener No Spam wrote:
>> OK, here is my idea of what such a component model envisages as a list
>> of items. After this, unless I get some intelligent comments from people
>> who might be interested in what I envision, or something very similar, I
>> will be off to investigate it myself rather than do battle with the
>> horde of people who will just tell me that Python, being a great
>> language, does not need what I have suggested.
>
> [This quote hacked up by me:]
>> 1) Component property: This is a glorified attribute with a type that
>> a) can be specified in a "static" manner, or discovered dynamically,
>> b) has converters between a string and the actual value
>> c) has a getter function to retrieve the value if it is readable and a
>> setter function to set the value if it is writable.
>> d) be either readable or writable or both.
>> e) not any Python class attribute since a component has the right
>> to specify only certain values as manipulatable in a design-time
>> RAD environment.
>
> Whenever you say "glorified attribute", your first thought should be
> "Python descriptor" (but not your last--it's not a cure-all). They are
> able to do all of (a, b, c, d, e) which I marked in your text above.
> For example, here's a descriptor for
> attributes-you-want-to-persist-in-a-database from my ORM, Dejavu (see
> http://projects.amor.org/dejavu/browser/trunk/units.py#l290):
>
>
> class UnitProperty(object):
> """Data descriptor for Unit data which will persist in storage."""
>
> def __init__(self, type=unicode, index=False, hints=None, key=None,
> default=None):
> self.type = type
> self.index = index
> if hints is None: hints = {}
> self.hints = hints
> self.key = key
> self.default = default
>
> def __get__(self, unit, unitclass=None):
> if unit is None:
> # When calling on the class instead of an instance...
> return self
> else:
> return unit._properties[self.key]
>
> def __set__(self, unit, value):
> if self.coerce:
> value = self.coerce(unit, value)
> oldvalue = unit._properties[self.key]
> if oldvalue != value:
> unit._properties[self.key] = value
>
> def coerce(self, unit, value):
> if value is not None and not isinstance(value, self.type):
> # Try to cast the value to self.type.
> try:
> value = self.type(value)
> except Exception, x:
> x.args += (value, type(value))
> raise
> return value
>
> def __delete__(self, unit):
> raise AttributeError("Unit Properties may not be deleted.")
>
>> a) can be specified in a "static" manner, or discovered dynamically,
>
> The "component model" can either scan a class for instances of
> UnitProperty or keep a registry of them in the class or elsewhere (via
> a metaclass + add_property functions).
>
>> b) has converters between a string and the actual value
>
> Note the "coerce" function above. Something similar could be done for
> serialization (which I can prove in my case because I use UnitProperty
> to help produce SQL ;) but you could just as easily pickle
> unit._properties and be done with it.
>
>> c) has a getter function to retrieve the value if it is readable and a
>> setter function to set the value if it is writable.
>> d) be either readable or writable or both.
>
> Descriptors that only have __get__ are read-only; if they have __set__
> they are read-write.
>
>> e) not any Python class attribute since a component has the right
>> to specify only certain values as manipulatable in a design-time
>> RAD environment.
>
> Right. Descriptors allow the creator of a class to use "normal"
> attributes (including functions) which don't participate in the
> component model.
>
>> 2) Component event: This is an type which encapsulates an array, or a
>> list of callable objects with the same function signature, along with
>> the functionality to add and remove elements from the array, as well as
>> cycle through the array calling the callable objects as a particular
>> event is triggered. A component event is an event source for a
>> particular event. Component events have to be dicoverable by the Visual
>> RAD system so that an object's appropriate event handler, an event sink,
>> can be hooked to the component event its
Re: Python component model
Kay Schluehr wrote: > fumanchu wrote: > >>> 4) Custom property and component editors: A component editor can present >>> a property editor or an editor for an entire component which the visual >>> design-time RAD environment can use to allow the programmer end-user of >>> the component to set or get component property values. Normally a design >>> time environment will present default property editors for each >>> component property type, but a component can override this. >> This is the hard part. I believe Dabo has done some work in this space, >> but this is where the tight coupling comes in between code and tool, a >> coupling which Python has traditionally resisted. > > I do think it's just about presenting component properties and their > types / value ranges. I do think this can be easily achieved using > decorators that might also add the right kind of token for > introspection purposes to the function/method attributes. Descriptors > i.e. customized binding semantics might cover one aspect of > componentization but as I understood Edward he asked for uniform > declarative semantics. Uniform in the sense that a visual RAD tool introspecting a Python class would be able to say that s type X is a component property and type Y is a component event, and everything is is just normal Python code which the RAD tool can ignore. > Components in this sense are just specialized > objects such as TestCase classes in the PyUnit framework. Totally agreed. But the common functionality they add is valuable to visual RAD tools. > What I still > do not understand is the reference to "many RAD" tools which is > completely hypothetical to me. You are right that I should not have mentioned this without experience with the many Python tools, notable Python web page development environments, which are out there. > The portability of components across > different GUI designers for the same underlying toolkit is a quite > speculative future requirement to say the least. It's been a success in the Java world with JavaBeans and EJBs within environments like Eclipse, NetBeans, JBuilder, and others; and its been a success in the .Net world with .Net components within Visual Studio, Borland Development Studio, and potentially others, so ideally it could be a success in the Python world. I believe the only knock against Python, as opposed to Java or .Net, is that it does not present enough ease of use environments to creating large scale applications, whether Linux, Windows, or Web applications. I believe part of that reason is because Python developers who, whether they wanted to distribute their classes for free or want to sell them for a profit, are presented with endless technologies built with Python, each one demanding a slightly different approach to class reusability, are reticent to develop their ideas for many different environments. Wanting a common PME component model is a way of saying that Python class developers can develop their classes as components and at least at the base level can expect them to work flawlessly in any Python environment. I am NOT against a particular environment building further requirements on top of a common Python component model, and in fact would expect it in many cases. But given inheritance in OOP, and in Python of course, this might be as easy for me as deriving a new class from my particular base class component for a particular visual RAD development environment, adding the extra function needed onto my derived class, and away we go. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Fredrik Lundh wrote: > fumanchu wrote: > >>> 4) Custom property and component editors: A component editor can present >>> a property editor or an editor for an entire component which the visual >>> design-time RAD environment can use to allow the programmer end-user of >>> the component to set or get component property values. Normally a design >>> time environment will present default property editors for each >>> component property type, but a component can override this. >> >> This is the hard part. I believe Dabo has done some work in this space, >> but this is where the tight coupling comes in between code and tool, a >> coupling which Python has traditionally resisted. > > that's not that hard on a pure technical level; even a "basic" tool > like IDLE can hook itself into an executing Python process. once you're > hooked up, you can inspect and modify most about everything. > > for example, doing remote tweaking of live Tkinter widget trees is > pretty straight-forward. > > coming up with a good way to capture the modifications, and use them in > your actual application, is a bit harder. do you really want to replace > plain old source code with some kind of more or less obscure resource > files? The Visual Studio RAD IDE environment actually modifies source code constructors, via an InitializeComponent() function called from it, in order to set properties and events in components. It does mark the function as such with comments in the source code. OTOH Borland's VCL uses the resource file technique you scorn above, linking in the code via resources and automatically updating a component's properties and events from base class components constructors. I believe Java's JVM automatically deserializes .ser files at run-time saved by a RAD designer in order to set properties and events on an object of a class. There are obviously numerous techniques, so one should theoretically work well with Python. > > and designing a metadata vocabulary that's powerful enough to be useful > for more than just one or a few target domains might be really hard. That's the are I am most interested in. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Peter Wang wrote: > Edward Diener wrote: >> It looks as if traits is an attempt to create a "property" in the >> component terminology which I originally specified. I will take a look >> at it. > > Traits is frighteningly similar to the requirements that you laid out > in your post (the example for Skip), including delegates! I would like > to point out, however, that traits is a *general* component framework > for python that facilitates implementing the observer pattern and a > higher level of introspection. It can be used to build applications > that have no visual interfaces at all, but wish to benefit from the > "reactive programming" style that componentized, event-based > programming encourages. (induces?) Thanks for the explanation. I was too quick in seeing Traits as only a version of properties without realizing that it included much more. > > Traits UI, which Robert only alluded to, is actually very much the sort > of RAD environment you have described. It builds upon the component > model, and uses introspection to automagically create nice widgets for > your model, but adds mechanisms for specifying controllers, customizing > behavior, and generically composing complicated forms from simpler > ones. There is even a visual "builder" tool for it called VET that > closely resembles Delphi/C++ Builder. (The VET itself is, of course, > written using Traits UI.) I have downloaded both Traits and Traits UI and will look at both. > > Envisage, the plugin application framework, can use the traits > component models and the TraitsUI interfaces to roll out very dynamic > applications, whose underlying models are all live components that can > be scripted, twiddled with from an embedded Python shell, etc. > >> Already subscribed. Thanks ! > > Please contribute ideas or ask conceptual questions! It would be easier for me if you could get an NG somewhere for Enthought, perhaps on GMane, since I always find mailing lists much more clunky than a good NG. But that is up to Enthought. > > Oh, and disclaimer: I also work at enthought. :) That's fine. It is the ideas about a PME component model for Python in which I was interested, no matter where it originates. Thanks for the encouraging reply. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
Kay Schluehr wrote: > val bykoski wrote: >> Peter Wang wrote: >>> Edward, >>> >>> This isn't in response to any specific one of the 100+ posts on this >>> thread, but I justed wanted to encourage you to continue your >>> investigation into Python component models and maybe looking for some >>> common ground between them. Frequently the individual developers are >>> too heads-down on working on their own things to do a broad survey, so >>> I think this would be very useful indeed. >>> >>> I wouldn't have felt it necessary to post this except for the large >>> number of posts along the lines of "foo.dict is introspective enough >>> for me!". I think you might have an easier time evangelizing the >>> principle of component-oriented programming (or "event-based", or >>> "reactive", or whatever) if you separated it from the notions of RAD UI >>> development. There is a very large difference between writing >>> components and writing objects, and it seems that most people arguing >>> "python doesn't need components" don't see this distinction. >>> >>> For me, it's the difference between writing "live" objects and "dead" >>> objects. Live objects not only encapsulate implementations of an >>> interface with some state, but they also encapsulate handling of >>> events, i.e. responses to changes in their environment. Dead objects >>> have methods but there has to be a function somewhere that knows which >>> dead object to call with what parameters at exactly the right time. >>> (The only mechanism for managing this complexity is to create ever more >>> functions at ever higher levels of abstraction, or to have a >>> proliferation of nebulously-defined "manager" objects.) IMHO once you >>> cross this chasm and are able to model your problem domain with live >>> objects that go off and automatically respond to the runtime >>> environment and Do the Right Thing, it's very hard to go back to a dead >>> object mindset. I can understand, however, that until one makes this >>> leap, it might seem like an academic and useless distinction. >>> >>> -peter >>> >> Excellent post, Peter. Thanks for great clarification. Looking from a >> physicist' perspective, im always trying to compare/evaluate languages >> from "the physical reality/dynamics" angle. So, the run-time >> space/dynamics is the only one that matches the natural "always-runtime" >> objects - atoms, molecules, EM fields, biological cells(?). It is the >> *reactive* world with event/forces-driven dynamics. Seemingly, there is >> nothing beyond that, including biology. > > A more conventional notion is that of static/dynamic properties of a > language. Component models that guarantee certain properties at compile > time are easily checked for consistency but to many programmers ( I > guess most of the programmers who attend to this list ) they are > inflexible: you might change or adapt your components according to > events, switch between entities, enable dynamic configuration etc. This > can be achieved in C++, Java etc. as well but not without pain. Having "static" properties and events is necessary for visual RAD programming environments, where connections are being setup between events and event handlers, and properties are being initialized, at design time. This does not preclude the normal "dynamic" attributes of Python. However if Python programmers reject such visual RAD programming environments as having any value, then they probably won't be interested in a common component model for them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lead Software Engineer
Emma wrote: > Successful candidates meet the following requirements: > · A burning desire to build rock-solid apps that people will be > unable > to live without I use to have a burning desire to cleverly answer questionnaires for companies which either don't exist or, if they do, don't tell you who they are, where they are located, or what they are offering, but I gave it up in infancy. -- http://mail.python.org/mailman/listinfo/python-list
