why does php have a standard SQL module and Python doesn't !?
Hi, I thought I would quickly write a "SELECT * FROM ... " line in python ... ... but then I was suprised to find that the only "official" web page I found was mainly linking to the PEP on HOW the DB API2.0 should look like. Then there is a choice of maybe ten modules which more or less all claim to implement 99% of that PEP. What is the best (easiest ! quickest !) way to get started doing some SQL in Python ? (I have mySQL running on a Linux box in our Lab and would like to access it from Windows (or MacOSX) on some other machine also in the same subnet) Sebastian Haase UCSF -- http://mail.python.org/mailman/listinfo/python-list
Re: why does php have a standard SQL module and Python doesn't !?
This was my point though: I found the *description* - but no wordon WHICH implementation to get WHERE ? Don't get me wrong - I like Python and I will stick to it for some time to come ... but WHY are the places to get those SQL implementations not better marked: Just try to google for "python sql" and you get here: http://sourceforge.net/projects/pysqldb/ (then this like to home page (http://pysqldb.sourceforge.net/) is COMPLETELY EMPTY ) the next number of hits seem to be completely random. Even if you google for: python mysql you get to http://sourceforge.net/projects/mysql-python where the linked "home page" says: ** OBSOLETE Python Interface to MySQL ** Please try to understand what I'm saying here: This is essentially a proof the there is no (one) good place to go for SQL & Python. Instead it looked really scary to me! How could I have known that "MySQLdb" is the keyword to google for !? It would be nice, if those projects would reference back to "http://www.python.org/topics/database/modules.html"; just to give some assurance that one is not totally off ... Thanks, Sebastian -- http://mail.python.org/mailman/listinfo/python-list
Re: why does php have a standard SQL module and Python doesn't !?
OK, point taken - maybe what threw me off was the simple fact that there CAN be NO "ONE standard/default SQL package". As a newbie in sql I was hoping to find something like e.g. the socket module (one size fits all) So: Maybe this could be explained on the "Database Modules" page. (and again: just being on sourceforge doesn't mean a project is still being developped - for all one call tell from the first look, they could be abandoned - hint: have a better homepage !!) Thanks, Sebastian -- http://mail.python.org/mailman/listinfo/python-list
Re: OpenGL
Does that mean PyOpenGL is based on ctypes ? I thought is was using SWIG ? And on that note: I have some (old) SWIG typemaps for numarray arrays that I'm using for many years. I was always wondering how difficult it would be for me to add them into PyOpenGL ? So far I'm just using my own (one !) OpenGL function with that typemap to draw 6 vertices in a vector linestrip. But I would like to not have to resort to "string conversion" when for example drawing 2D typemaps... Anyway, thanks a lot for PytOpenGL - my program (image analysis platform and microscope control) would not be possible without it. Sebastian Haase -- http://mail.python.org/mailman/listinfo/python-list
how to create a movie ?
Hi, I have a series of images (either from numarray or from PIL) After googling if read something about pyMedia... Can I create an AVI movie from my images with that ? How about quicktime ? Thanks, Sebastian Haase -- http://mail.python.org/mailman/listinfo/python-list
Python 3000 deat !? Is true division ever coming ?
Hi, Is it true that that "Python 3000" is dead ? Honestly I think that e.g. changing 5/2 to be 2.5 (instead of 2) would just break to much code :-( On the otherhand I'm using Python as "Matlab replacement" and would generally like 5/2 ==2.5 So, I was contemplating to default all my modules/scripts to start with "from __future__ import division" but if it is never coming (in this decade, that is) then it would be a waste of time just confuse everybody !! Thanks, Sebastian Haase -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 deat !? Is true division ever coming ?
Thanks for the replies, But to point out what the subject of this thread is (sorry for the typo ;-) : There is a PEP (proposal 238) to change Python so that 5/2 WOULD do the true division -- and obviously break lots of code. Just type this in your python interpeter: >>> from __future__ import division >>> 5/2 2.5 I'm not asking why it _doen't_ work like Matlab. I'm wondering what the chances are that what Rocco Moretti is referring to (http://www.python.org/doc/2.2.3/whatsnew/node7.html) is really planned to be persued... I don't think "Because this change might break code, it's being introduced very gradually. Python 2.2 begins the transition, but the switch won't be complete until Python 3.0." says enough. Should I start using "from __future__ import division" in my modules ? I fear that it might make my code "unreadable" (people would not expect this when reading somewhere in the middle of the module !!!) Thanks, Sebastian Haase -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 deat !? Is true division ever coming ?
Thank you very much, Magnus ! This is the answer I had been waiting for: > A problem as I see it today, is that this behaviour is > not actively encouraged. The tutorial, which is maintained > and updated, still describes old style classes, and the > old division behaviour. My main point was/is: why is there not more discussion about "true division" !!? Just like the second answer to my posting clearly showed: PEOPLE THINK TRUE DIVISION IS "ONLY IN MATLAB" !! As you pointed out: the "true division" part of "Python3000" might be one of the "scariest" and should therefore be pointed out already in the tutorial !! (It would look quite ugly to newcomers, though) Having said that: I would vote against EVER introducing true division as default - because it will just PISS too many (long time python) people OFF. ;-) Thanks, Sebastian Haase Magnus Lycka wrote: > [EMAIL PROTECTED] wrote: > > Hi, > > Is it true that that "Python 3000" is dead ? > > I think you should view Python 3000 as a metaphor for > "Python as it would look if we didn't have to care about > backward compatibility". > > Before this name appeared, Guido used to talk about > Python 3.0 as a version where bad things in Python could > go away, but it seems many people got worried about that, > assuming that Python 3.0 would happen soon and cause a lot > of changes in already written code. Thus the less scary > label Python 3000. There has never been any concrete plans > as far as I know to actually release a real software product > called Python 3000. It's rather a long term design target > for Python. > > A lot of these language changes can be introduced step > be step. A new feature can be introduced first as an > experimental feature, accessible via "from __future__ > import XYZ", in the next minor release, it might be > enabled by default. If a feature or module is going away, > the first step is to document it as deprecated. The next > minor release will issue a PendingDeprecationWarning, and > the minor release after that will issue a DeprecationWarning > and the next minor release (2.4 -> 2.5 etc) will remove > the feature. This will give developers a period of many > years to adapt from the time the feature is documented as > deprecated until maintenace ends for the last Python where > the deprecated feature works. > > For an example of such a transition plan, see > http://www.python.org/peps/pep-0352.html > > Changing the behaviour of int/int is worse, since there > is no obvious way for Python to determine whether the > programmer expects an int result, a float result or either. > Also, the typical consequence of this change is not that > code breaks with a big bang, but rather that it produces > somewhat different results. That means that a bug due to > this feature change might go unnoticed for a long time, > and cause a lot of problems. Imagine some kind of system > that calculates how much pension you'll get when you > retire, based on your monthly payments. A bug caused by > changed division behaviour might have serious consequences. > > It seems reasonable to wait until the next major release, > 3.0, before this feature is introduced. In the mean time > it seems that the strategy should be to encourage people > to adopt the new behaviour in all new code, i.e. to use > "from __future__ import division" and to explicitly use > interger division a//b when this is needed. > > In the same way, people should be encouraged to always > use new style classes, "class X(object):" in new code, > since old style classes are going away, and they behave > differently in some ways. > > A problem as I see it today, is that this behaviour is > not actively encouraged. The tutorial, which is maintained > and updated, still describes old style classes, and the > old division behaviour. > > http://docs.python.org/dev/tut/node5.html#SECTION00511 > http://docs.python.org/dev/tut/node11.html#SECTION001130 > > I don't see any reason to use old style classes in new code, > so I think all "class X:" should be changed to > "class X(object):", but I can understand that it would be > confusing to explain the use of "from __future__ import division" > before we introduce simple arithmetics. Still, we should > get this message through! > > As it is now, when people aren't actively moving their code > towards this expected change, the impact of such a change > would be almost as strong as if this "from __future_..." > feature didn't exist. > > So, if I finally try to answer your question: Float division > will hardly be enabled by default until most Python programmers > have adopted the feature, i.e. enabled it through the > __future__ switch and started to use // when they want floor > division. > > This will hardly happen until it's documented as the way people > should do it. Perhaps a start could be a FutureProofPython page > in the Python wiki, with suggested coding guidelines. -- http://mail.python.org/mailman/listinfo
PyOpenGL without SetupTools
Hi, I am distributing a package with a precompiled collection of modules and packages useful for Python based medical/biological/astronomical image analysis and algorithm development. (Codename: Priithon). For Priithon I put all modules/packages in a simple / single directory (tree) including one starting batch/script file. This script sets up PYTHONPATH to find modules at this place. It works fine for Windows,Linux and Mac-OSX. Now I want to upgrade everything to Python 2.5 and thought it might be time get PyOpengl version 3 (aka. pyOpengl-ctypes). The problem at hand is now that PyOpenGL uses "all this setup-tools machinery" just to initialize the formathandlers for the different ways to deal with arrays. (I really need only numpy support !) This is done via the pkg_resources mechanism called "entry_points". Can I include a simple non-system-install of pkg_resources that makes at least the entry_point stuff work ? Where do I put pyOpenGL's "entry_points.txt" file ? Thanks, Sebastian Haase MDC Berlin -- http://mail.python.org/mailman/listinfo/python-list
Re: PyOpenGL without SetupTools
Are there PyOpenGL 2.0 (I guess 2.0.1.09 is goood) binaries available
for Python 2.5 ? Anywhere ?
Thanks for the reply
-Sebastian Haase
On Oct 1, 11:49 am, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Oct 1, 4:04 am, [EMAIL PROTECTED] wrote:
>
>
>
> > Hi,
> > I am distributing a package with a precompiled collection of modules
> > and packages useful for Python based medical/biological/astronomical
> > image analysis and algorithm development. (Codename: Priithon).
> > For Priithon I put all modules/packages in a simple / single directory
> > (tree) including one starting batch/script file. This script sets up
> > PYTHONPATH to find modules at this place.
> > It works fine for Windows,Linux and Mac-OSX.
>
> > Now I want to upgrade everything to Python 2.5 and thought it might
> > be time get PyOpengl version 3 (aka. pyOpengl-ctypes).
>
> > The problem at hand is now that PyOpenGL uses "all this setup-tools
> > machinery" just to initialize the formathandlers for the different
> > ways to deal with arrays. (I really need only numpy support !)
> > This is done via the pkg_resources mechanism called "entry_points".
>
> > Can I include a simple non-system-install of pkg_resources that makes
> > at least the entry_point stuff work ? Where do I put pyOpenGL's
> > "entry_points.txt" file ?
>
> The simple answer is "don't bother with PyOpenGL-ctypes if you don't
> have to". Besides the hassles with binary packaging, it's quite a bit
> slower then PyOpenGL 2.0.
>
> Anyways, when I saw that I couldn't easily figure out how to register
> a setuptools package by hand (the point you seem to be at now), I
> resorted to using the same hack that setuptools uses to register its
> packages. Setuptools puts a pth file, something like
> "ezsetup_.pth", in the site-packages directory. The file has a
> couple lines of Python code that mark the start and end of the eggs on
> sys.path; then they call setuptools to postprocess and register the
> eggs.
>
> What I did was to duplicate the effect of these lines in my main
> script. I don't have it in front of me, but it was something along
> these lines:
>
> sys.__eggindex = len(sys.path)
> sys.path.append("OpenGL-cytpes-3.0.0a7-whatever.egg")
> setuptools.register_packages()
>
> I copied the OpenGL egg to my distro directory, and it worked.
>
> Another possibility is to do it the "setuptools" way: by not packaging
> PyOpenGL 3.0 at all, and instead marking it as a dependency. Then,
> setuptools will helpfully download it for the user. (Personally, I
> hate that scripts can recklessly download and install stuff into your
> site packages without even asking; seems like a possible security hole
> as well.) But it's an option.
>
> Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
How popular is Django ?
Hi! I was surprised when I did a google-groups search for python, ( http://groups.google.com/groups/search?q=python&qt_s=Search+Groups ) it shows these groups: comp.lang.python with about 11000 users, and second, Django users Discussion group for Django users. Django is a high-level Python Web ... with 6500 members I cannot believe that django is *that* popular ... where am I going wrong ? Cheers, Sebastian Haase -- http://mail.python.org/mailman/listinfo/python-list
where is pkg_resources (setuptools) looking for entry_points.txt
Hi, I'm trying to use an egg packages (pyOpenGL) as a "normal package" (by unzipping the egg into a directory). Generally this seems to work fine, except one init-step is missing. >From setuptools I got the pkg_resources.py file. But now the package is not properly initialized, because iter_entry_points() in pkg_resources does not find the corresponding entry_points.txt file needed to setup some intial configuration... (array handlers for pyOpenGL) Is there a default directory name or an environment variably or maybe the (ominous? ) __main__.__require variable that I can use to have the entry_points text read ? (I would even be willing to "manually" load the entry_points.txt file and feed it into some pkg_resources related variable to make it happy [before I import my package] ) Thanks, Sebastian Haase -- http://mail.python.org/mailman/listinfo/python-list
pickle: 32bit vs 64bit
Hi, I have ordered a new Athlon64 PC running linux x86_64. I'm using Pyro to communicate between python programs running on different machines. I know that, because Pyro's communication is based on pickle, that the different machines have to run the same Python (major) version: that is, it did not work after I just upgraded ONE machine from Py2.2 to Py2.4. How will this be when all machines run Python2.4, but one will be compiled as a 64bit application, the others 32bit ? (If it works for 2.4, will it still work for Python2.5, where lists can be larger than 2GB ONLY on 64bit-Python ? [of course I mean the case where the lists are actually (much) shorter than 2GB !!] ) Thanks, Sebastian Haase -- http://mail.python.org/mailman/listinfo/python-list
