Re: from __future__ import annotations bug?
Should mention this also affects Protocol[Buzz]
On Fri, Jun 30, 2023, 5:35 PM Joseph Garvin wrote:
> ```
> from __future__ import annotations
> from typing import Generic, TypeVar
>
> T = TypeVar("T")
> class Foo(Generic[T]): ...
> class Bar(Foo[Buzz]): ... # NameError here
> class Buzz: ...
> ```
>
> This will error, despite the __future__ import, because cpython is trying
> to look up Buzz before it's defined, even though we have supposedly
> prevented annotations from being processed. I realize that Class[Args] is
> allowed in that area in general and isn't always type annotation related,
> but does this mean that even with PEP 649 that forward references will
> still be needed?
>
--
https://mail.python.org/mailman/listinfo/python-list
from __future__ import annotations bug?
```
from __future__ import annotations
from typing import Generic, TypeVar
T = TypeVar("T")
class Foo(Generic[T]): ...
class Bar(Foo[Buzz]): ... # NameError here
class Buzz: ...
```
This will error, despite the __future__ import, because cpython is trying
to look up Buzz before it's defined, even though we have supposedly
prevented annotations from being processed. I realize that Class[Args] is
allowed in that area in general and isn't always type annotation related,
but does this mean that even with PEP 649 that forward references will
still be needed?
--
https://mail.python.org/mailman/listinfo/python-list
bug?: python-config --ldflags gives incorrect output
On the latest stable ubuntu: $ python-config --ldflags -L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm -lpython2.6 In case the user is statically linking, I believe the -lpython2.6 should go before the other -l's. Also, -lz is missing so whenever you try to link against python you get tons of errors about missing PyZlib references. Am I right in thinking these are bugs? -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Thu, Jun 4, 2009 at 2:35 PM, Thomas Heller wrote: > [Please keep the discussion on the list] > > All in all, as I said, IMO it is too complicated to figure out the binary > layout of the C++ objects (without using a C++ compiler), also there are > quite some Python packages for accessing them. Requiring that the C++ compiler used to make the dll's/so's to be the same one Python is compiled with wouldn't be too burdensome would it? Because then you could have it run a bunch of configure tests to determine information exposing the layout. I don't know if everything is testable, but you can for example (I learned this from the object model book btw) write a C++ program that determines whether the virtual function table is stored at the beginning or the end of an object by comparing the address of an object with a virtual function to the address of its first data member. If they're different, it's because the vptr is stored there, otherwise it's on the end (theoretically it could be in the middle but there's no reason for compiler writers to do that). cpptypes could then use information generated by tests like this that are run when the interpreter is compiled. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using C++ and ctypes together: a vast conspiracy? ;)
On Thu, Jun 4, 2009 at 3:23 PM, Brian wrote: > What is the goal of this conversation that goes above and beyond what > Boost.Python + pygccxml achieve? I can't speak for others but the reason I was asking is because it's nice to be able to define bindings from within python. At a minimum, compiling bindings means a little extra complexity to address with whatever build tools you're using. -- http://mail.python.org/mailman/listinfo/python-list
Using C++ and ctypes together: a vast conspiracy? ;)
So I was curious whether it's possible to use the ctypes module with C++ and if so how difficult it is. I figure in principal it's possible if ctypes knows about each compiler's name mangling scheme. So I searched for "ctypes c++" on Google. The third link will be "Using ctypes to Wrap C++ Libraries". If you follow the link, it's broken. If you view the cache of the link, it's someone pointing to another blog, retrograde-orbit.blogspot.com, saying they discovered a way to do it easily. If you follow that link, you get taken a page does not exist error. Clearly there's some way to use ctypes with C++ and there's a vast conspiracy preventing it from reaching the masses ;) What's even stranger is that this link, despite being broken, has seemingly been near the top of google's results for these terms for a couple weeks (that's when I last tried), as if there were some underground group of rebels trying to hint the truth to us... ;) More seriously -- how difficult is it to use ctypes instead of saying, boost::python, and why isn't this in a FAQ somewhere? ;) -- http://mail.python.org/mailman/listinfo/python-list
optparse question, passing unknown flags to subprocess
I'm working on a python script that takes several command line flags, currently parsed by hand. I'd like to change the script to parse them with OptionParser from the optparse module. However, currently the script invokes a subprocess, and any flags the script doesn't understand it assumes are meant to be passed to the subprocess. But if I switch to using OptionParser, any options I haven't added to my parser will cause an error, instead of it ignoring those and letting me pass them onto the subprocess. What's the best/most-pythonic way to handle this? I could subclass OptionParser and override its exit() and error() methods as suggested by the docs (http://www.python.org/doc/2.4/lib/optparse-how-optik-handles-errors.html) and have them do nothing, but there are some errors I probably don't want to ignore (like if the user tries to pass a string to a known flag that takes an int). -- http://mail.python.org/mailman/listinfo/python-list
Re: Painful?: Using the ast module for metaprogramming
On Mon, Apr 6, 2009 at 1:33 AM, "Martin v. Löwis" wrote: >> -If I have the source to a single function definition and I pass it to >> ast.parse, I get back an ast.Module. Why not an ast.FunctionDef? > > Because it is easier for processing if you always get the same type of > result. Typically, you don't know what's in the source code, so you > need to parse, then inspect. I see. True I'm guessing for the applications for which the module was originally intended. In a metaprogramming context you usually know though. >> -An ast.Name always has an ast.Load or ast.Store "context" associated >> with it. This is a bit odd, since based on the actual context (what >> the parent of the ast.Name node is) it is always clear whether the >> variable needs to be loaded or stored > > It simplifies the interpretation/compilation of the code, by removing > the need to go up in the tree. Notice that just looking at the parent > node would not be sufficient... I see how it avoids needing to look at the parent node in general, but if we were compiling by recursively descending through the AST, then we would know whether Name's would be loads or stores by the time we got to them (we would already had to have visited an encompassing assignment or expression) -- except in the case of your a = b = c expression, which I'm curious how Python handles. The natural answer is for assignment to be an expression (so b = c returns the new value of b). But Python doesn't do that, so then I'd expect we'd have some third ast.LoadAndStore() option for b, but examining ast.parse's behavior it looks like it chooses Store... >> -Why can't orelse for ast.If and ast.While default to empty []? > > You want to store None? That would be a type error; orelse is > specified as "stmt*". So it must be a list. A list is actually what I want, an empty one. The problem is that ast.While and ast.If's constructors default to the opposite, orelse=None. Same with keywords and args for ast.Call. Admittedly, adding orelse=[] to the constructor calls isn't terribly burdensome, but it does make already obfuscated looking AST mangling code even worse. >> -Why can't I eval a functiondef to get back a function object? > > Because a definition is not an expression. You can only eval > expressions. I understand that if function definitions were expressions, because of the whitespace syntax there wouldn't be a way to express an assignment to such an expression. But, why would it be problematic to let them be expressions anyway? >> -The module provides no means to convert an AST back into source code, >> which would be nice for debugging. > > See Demo/parser/unparse.py Thanks :) >> -It would be nice if decorators were passed a function's AST instead >> of a function object. > > How could this possibly work? If you run from a pyc file, there will > be no AST available to pass. I hadn't thought about bytecode compilation. In addition to the other suggestions you would have to change it to preserve an AST. Regards, Joe -- http://mail.python.org/mailman/listinfo/python-list
Painful?: Using the ast module for metaprogramming
I decided to try using the ast module to see how difficult or not it was to use for metaprogramming. So I tried writing a decorator that would perform a simple transformation of a function's code. It was certainly not as easy as I had guessed, but I did succeed so it's not impossible. The issues I encountered might suggest changes to the ast module, but since this is my first time messing with it I think it's equally likely I'm just ignorant of the best way to handle them. Questions: -If I have the source to a single function definition and I pass it to ast.parse, I get back an ast.Module. Why not an ast.FunctionDef? -An ast.Name always has an ast.Load or ast.Store "context" associated with it. This is a bit odd, since based on the actual context (what the parent of the ast.Name node is) it is always clear whether the variable needs to be loaded or stored -- loaded when the node is the child of an expression and stored when the node is the target of an assignment. Is there some weird corner case that necessitates this redundancy? It adds a lot of noise when you're trying to interpret trees, and the ast.Load and ast.Store objects themselves don't seem to contain any data. -Why can't orelse for ast.If and ast.While default to empty []? If you make an ast.While object by hand but don't specify that orelse is empty, you get an error when later trying to compile it. This seems silly since by default not specifying an else in code results in the ast module generating a node with orelse=[]. -Why can't keywords and args for ast.Call default to empty []? Same problem as with orelse. -Why can't I eval a functiondef to get back a function object? As it stands, I have to work around this by giving the functiondef a unique name, exec'ing the AST, and then doing a lookup in locals[] to get the resulting function object. This is a nasty hack. -The provided NodeTransformer class is useful, but provides no way (that I can see) to replace a single statement with multiple statements, because multiple statements would constitute multiple nodes. To work around this, I take the code I want to swap in, and wrap it in a "while 1:" block with a break at the end to ensure it only runs once and doesn't loop. Again, a kludge. -The module provides no means to convert an AST back into source code, which would be nice for debugging. -It would be nice if decorators were passed a function's AST instead of a function object. As it is I have to use inspect.getsource to retrieve the source for the function in question, and then use ast.parse, which is a bit inefficient because the cpython parser has to already have done this once before. Again, it feels like a hack. Making decorators take AST's would obviously be a compatibility breaking change, since you'd then have to compile them before returning, so alternatively you could have "ast decorators" that would use a different prefix symbol in place of @, or you could change it so that decorators got passed the AST but the AST had a __call__ method that would cause the AST to parse itself and become the resulting function object in place and then execute itself, so until the first time it was called it was an AST but after that was a function object (it would 'lazily' become a function). I think that wouldn't break most code. I have some ideas for what an easier API would look like but I want to be sure these are real issues first and not just me doing it wrong ;) Regards, Joe -- http://mail.python.org/mailman/listinfo/python-list
Re: Generators vs. Functions?
Wolfgang Keller wrote: >If this is actually also true in the general case, and not due to eventual >non-representativeness of the test mentioned above, is it simply due to a >less-than-optimum implementation of generators in the current Pyython >interpreter and thus likely to change in the future or is this a matter of >principle and will consequently remain like this forever? > > I am not a CPython or PyPy hacker, but I would guess that it will always be slower as a matter of principal. When resuming a generator you have to resetup the state the function was in when it was last called, which I think should always be more costly than calling the function with a clean state. Someone want to correct me? Whether or not the difference is that significant though I am unsure. It may be small enough that for most applications no one cares. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessing next/prev element while for looping
Steven D'Aprano wrote: >On Sun, 18 Dec 2005 23:36:29 +1100, Steven D'Aprano wrote: > > > >>Python lists aren't linked lists? They are arrays. >> >> > >[slaps head for the stupid typo] >That should have been a full stop, not question mark. Python lists are not >linked lists, period. > > > > All the more inexcusable then, because it's even easier to find the next/previous element in an array! ;) Thanks all, Bas/Bangt's solutions are very elegant =) -- http://mail.python.org/mailman/listinfo/python-list
Accessing next/prev element while for looping
When I first came to Python I did a lot of C style loops like this: for i in range(len(myarray)): print myarray[i] Obviously the more pythonic way is: for i in my array: print i The python way is much more succinct. But a lot of times I'll be looping through something, and if a certain condition is met, need to access the previous or the next element in the array before continuing iterating. I don't see any elegant way to do this other than to switch back to the C style loop and refer to myarray[i-1] and myarray[i+1], which seems incredibly silly given that python lists under the hood are linked lists, presumably having previous/next pointers although I haven't looked at the interpeter source. I could also enumerate: for i, j in enumerate(myarray): print myarray[i], j # Prints each element twice And this way I can keep referring to j instead of myarray[i], but I'm still forced to use myarray[i-1] and myarray[i+1] to refer to the previous and next elements. Being able to do j.prev, j.next seems more intuitive. Is there some other builtin somewhere that provides better functionality that I'm missing? -- http://mail.python.org/mailman/listinfo/python-list
Re: user-defined operators: a very modest proposal
Tom Anderson wrote: >Jeff Epler's proposal to use unicode operators would synergise most >excellently with this, allowing python to finally reach, and even surpass, >the level of expressiveness found in languages such as perl, APL and >INTERCAL. > >tom > > > What do you mean by unicode operators? Link? -- http://mail.python.org/mailman/listinfo/python-list
Re: SuSe 10.0 missing Idle
Steve wrote: >Hello, > >Hopefully this is not to of topic. I just installed SuSe 10.0 > and although python installed but no Idle. I can't seem to find it in >the list of available packages either. I was wondering if someone might >steer me in the right direction. I've just started learning python and >would really like to get Idle back or failing that a reccommendation of >another IDE for python? > >Thanks in Advance >Steve > > SuSE probably has a seperate package, something like python-tk, that will install IDLE. Look for that, some distros don't like to install idle by default because it also means installing the Tk toolkit that it uses. -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
Paul Rubin wrote: >Cliff Wells <[EMAIL PROTECTED]> writes: > > >>It didn't say what they left PHP, Perl and Python for (if you are to >>even believe their findings). >> >>PHP has been losing programmers in droves... to Ruby on Rails, but I'm >>not sure how that is bad news for scripting-language fans. >> >> > >That's the second time in one or two days that I've heard Ruby on >Rails mentioned. Can anyone here post a paragraph or two description? >I sort of know what Ruby is, a very OOP-ified Perl-resemblant >language, that's also implemented only as an interpreter. I can't see >punting Python for it. > > www.google.com -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN : dxPython 0.3.0
Atila Olah wrote: >In my opinion, you shoud make an (100%) English version of the site, if >you want more developers to join worldwide. > > > Isn't there some sort of Python directx thingy already? Surprised. -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
[EMAIL PROTECTED] wrote: >I've heard 2 people complain that word 'global' is confusing. > >Perhaps 'modulescope' or 'module' would be better? > >Am I the first peope to have thought of this and suggested it? > >Is this a candidate for Python 3000 yet? > >Chris > > > Hmm.. instead of 'global', how about 'outside' ? It seems a bit more intuitive to me because it suggests that you mean, "the variable defined outside this scope" or outside any nestedness. But then again it could be confused to mean "just one scope above this one" which isn't necessarily module scope (nested functions, etc.)... still, might be less confusing than 'global'. Another alternative to having to say "global var" would be to use some sort of indicator that you want the global with each usage, like, "global.var" or "outside.var" -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Programming Contest
Someone correct me if I'm wrong -- but isn't this the Shortest Path problem? I don't foresee anyone getting a more efficient solution than what they can find in hundreds of algorithms textbooks. If this is indeed the case it should just come down to whoever can pull the narliest tricks to create a fast python implementation of the algorithm. Brian Quinlan wrote: >I've decided that it would be be fun to host a weekly Python programming >contest. The focus will be on algorithms that require a bit of thought >to design but not much code to implement. > >I'm doing to judge the solutions based on execution speed. It sucks but >that is the easiest important consideration to objectively measure. I'll >also indicated which solutions I think are good examples of Python >design. Hopefully, people's solutions can provide a resource for people >looking for best practice examples and also for people looking for >performance ideas. > >You can find the first problem here: >http://www.sweetapp.com/pycontest/contest1 > >I'm always looking for feedback, so let me know what you think or if you >have any ideas for future problems. > >Cheers, >Brian > > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting from Python 2.3 to 2.4
Anand wrote: >Hi > > Are there any tools that would help in porting code from >Pyton 2.3 to 2.4 ? I have gone through the whatsnew documents >and created a document comparing Python 2.4 to 2.3. But so far >has not been able to find any tool that will signal code in >Python 2.3 that can cause errors in Python 2.4 . > >rgds > >-Anand > > > All 2.x versions are backwards compatible. Porting just means taking advantage of new features. Unless you've been naughty and are accessing private methods in stdlib, you're probably fine. -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficiently Split A List of Tuples
Peter Hansen wrote: >(I believe this is something Guido considers an "abuse of *args", but I >just consider it an elegant use of zip() considering how the language >defines *args. YMMV] > >-Peter > > An abuse?! That's one of the most useful things to do with it. It's transpose. -- http://mail.python.org/mailman/listinfo/python-list
Re: Any Lua Coders About?
Wendell III wrote: >Hey, > >I'm looking for a few good Lua guys with some IM network experience. >Anyone around fit that criteria? > >Bestest, >-Wendell > > I'd say it's a no brainer to try lua's mailing list ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating anonymous functions using eval
Robert Kern wrote: >Not everyone is reading this list in a conveniently threaded >form > > Why not? Just about every modern newsgroup reader and e-mail app has a threaded view option. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Everyone complaining about Eclipse in this thread needs to go try 3.1. The interface is much much much more responsive. Also, everyone keeps discussing Eclipse as something that gives Java a leg up on Python. *Ahem* PyDev :) Which you should also give another try if you haven't in a few versions. Easiest way to get a GUI debugger for python. My only misgiving with Eclipse now is that I think development of plugins for it is always going to be slower than for Emacs and other editors because they have to be written in Java. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for everything?
Mike Meyer wrote: >You wind up >having to invoke the function through your data object, and then pass >the data object in - sort of as an explicit "self". > > > Yeah, and us pythonists hate explicit self! ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for everything?
Larry Bates wrote: >poorly. When new version of Python ships, you just learn what is new. >If you try to keep up with C, C++, Visual Basic, ... it gets to be >impossible. > >Hope information helps. > >Larry Bates > > > Huh? Part of C++'s problem is that it takes too long for obvious good stuff to get into the language. It stays the same for years at a crack inbetween the committees approving stuff. Python in contrast can see a release every few months. Python is a moving target. C++ is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Favorite non-python language trick?
Claudio Grondi wrote: >>And you can do block comments with --[[ and ---]]. >> >> > >I am very happy not to have such "tricks" in Python. > >Any other (useful) suggestions? > >Claudio > > I'm glad and all that not everyone shares my enthusiasm over Lua's trick, and I'm glad that C/C++ can do it, but the original issue was non-python language tricks in general. Lets keep the thread on track. So far we've got lisp macros and a thousand response's to the lua trick. Anyone else have any actual non-python language tricks they like? Yeesh. >"Joseph Garvin" <[EMAIL PROTECTED]> schrieb im Newsbeitrag >news:[EMAIL PROTECTED] > > >>As someone who learned C first, when I came to Python everytime I read >>about a new feature it was like, "Whoa! I can do that?!" Slicing, dir(), >>getattr/setattr, the % operator, all of this was very different from C. >> >>I'm curious -- what is everyone's favorite trick from a non-python >>language? And -- why isn't it in Python? >> >>Here's my current candidate: >> >>So the other day I was looking at the language Lua. In Lua, you make a >>line a comment with two dashes: >> >>-- hey, this is a comment. >> >>And you can do block comments with --[[ and ---]]. >> >>--[[ >>hey >>this >>is >>a >>big >>comment >>--]] >> >>This syntax lets you do a nifty trick, where you can add or subtract a >>third dash to change whether or not code runs: >> >>--This code won't run because it's in a comment block >>--[[ >>print(10) >>--]] >> >>--This code will, because the first two dashes make the rest a comment, >>breaking the block >>---[[ >>print(10) >>--]] >> >>So you can change whether or not code is commented out just by adding a >>dash. This is much nicer than in C or Python having to get rid of """ or >>/* and */. Of course, the IDE can compensate. But it's still neat :) >> >> > > > > -- http://mail.python.org/mailman/listinfo/python-list
Favorite non-python language trick?
As someone who learned C first, when I came to Python everytime I read about a new feature it was like, "Whoa! I can do that?!" Slicing, dir(), getattr/setattr, the % operator, all of this was very different from C. I'm curious -- what is everyone's favorite trick from a non-python language? And -- why isn't it in Python? Here's my current candidate: So the other day I was looking at the language Lua. In Lua, you make a line a comment with two dashes: -- hey, this is a comment. And you can do block comments with --[[ and ---]]. --[[ hey this is a big comment --]] This syntax lets you do a nifty trick, where you can add or subtract a third dash to change whether or not code runs: --This code won't run because it's in a comment block --[[ print(10) --]] --This code will, because the first two dashes make the rest a comment, breaking the block ---[[ print(10) --]] So you can change whether or not code is commented out just by adding a dash. This is much nicer than in C or Python having to get rid of """ or /* and */. Of course, the IDE can compensate. But it's still neat :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Loop until condition is true
Peter Otten wrote:
>I found 136 occurrences of "do {" versus 754 of "while (" and 1224 of "for
>(" in the Python 2.4 source, so using these rough estimates do-while still
>qualifies as "rarely used".
>
>Peter
>
>
>
That's 136 times you'd have to use an ugly hack instead. I definitely
wouldn't mind an until or do/while.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Safe eval, or how to get list from string
[EMAIL PROTECTED] wrote: >>http://twistedmatrix.com/users/moshez/unrepr.py >>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/364469 >> >> > >Thanks, this helps - but I was looking at using no additional modules, >or using something that came bundled in with python 2.3 > >I just discovered mx.Tools.NewBuiltins > >It has something called "reval" looks that would fit my needs >perfectly. > >Details: >http://www.faqts.com/knowledge_base/view.phtml/aid/4550/fid/538 > > > If I remember correctly reval and it's brothers were deemed insecure, are no longer developed, and are present only for sake of backwards compatibility. See the global module index entry on it. -- http://mail.python.org/mailman/listinfo/python-list
Re: How "return" no return ?
Ximo wrote: >Hello, I want that the return sentence don't return anything, how can I do >it?. If i do only return it returns None, and pass don't run too. > >Can anyone help me?, thanks. >XIMO > > > > Returning None is the same as returning nothing. What exactly are you trying to do? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Args By Reference
ncf wrote: >Hello all, I was wondering if there was any way to pass arguments >(integer and such) by reference (address of), rather than by value. > >Many thanks in advance. > >-Wes > > > All mutable types in python are passed by reference automatically. -- http://mail.python.org/mailman/listinfo/python-list
Re: Solipsis: Python-powered Metaverse
Terry Reedy wrote: >Today I followed a link to an interesting Python application I have not >seen mentioned here before: http://solipsis.netofpeers.net/wiki/HomePage/. > >"A peer-to-peer system for a massively multi-participant virtual world " > >It is a France Telecom R&D project, LGPL licenced, still in alpha, built on >Python, Twisted, WxPthon, PIL, and probably other components actual or >considered. The new Node software, rewritten with Twisted, was released >yesterday. > >Terry J. Reedy > > > I was looking at this earlier today because I was curious how they were going to handle performance concerns (both due to Python and bandwidth). I'm having trouble understanding all of the details -- what is the significance of the use of a torus for the world space? Does this somehow help in the computation of the convex hull? -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 2.4 on Linux
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 :) 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
