ffaure@bigSPAMGAMOUT
RH 7.1/Fail upgradin
Hi,

I did read the archives, and also find that others failed
installing Python2 through RPMs because of failed dependencies
(Personally, I need to do this because Zope 2.4 requires Python2.):

EXHIBIT A
-------------------------------------------------------
# ldconfig -v | grep cry
libcrypt.so.1 -> libcrypt-2.2.2.so
libcrypto.so.1 -> libcrypto.so.0.9.6
libk5crypto.so.3 -> libk5crypto.so.3.0

# ldconfig -v | grep ssl
libkssl.so.2 -> libkssl.so.2.0.0
libssl.so.1 -> libssl.so.0.9.6

# rpm -Uvh --test python2-2.1-6.i386.rpm
error: failed dependencies:
libcrypto.so.0.9.6 is needed by python2-2.1-6
libssl.so.0.9.6 is needed by python2-2.1-6

FWIW, I also added a symlink between /usr/lib/libssl.so.0.9.6 and
/lib/libssl.so.9.6, and ran ldconfig to update its cache, with no
change.

EXHIBIT B
-------------------------------------------------------
Next, someone in this ng suggested adding openssl95a because it would
install symlinks libssl.so.0 and libcrypto.so.0... The python2 RPM
still complains:

# rpm -Uvh openssl095a-0.9.5a-9.i386.rpm

# ldconfig -v | grep ssl
libssl.so.0 -> libssl.so.0.9.5a
libkssl.so.2 -> libkssl.so.2.0.0
libssl.so.1 -> libssl.so.0.9.6

# ldconfig -v | grep cry
libcrypt.so.1 -> libcrypt-2.2.2.so
libcrypto.so.0 -> libcrypto.so.0.9.5a
libcrypto.so.1 -> libcrypto.so.0.9.6
libk5crypto.so.3 -> libk5crypto.so.3.0

# rpm -Uvh --test python2-2.1-6.i386.rpm
error: failed dependencies:
libcrypto.so.0.9.6 is needed by python2-2.1-6
libssl.so.0.9.6 is needed by python2-2.1-6

QUESTION
------------------------------
=> Since this kind of thing happens every so often with RPM, does
anyone know where it comes from? There has to be a logical explanation
for this behavior, especially since it occurs on a clean and recently
installed host.
If the RPM database knows that a given library is available, and ld
also knows about it through its cache, what can possibly keep an RPM
complaining?

=> I see that python2-2.1-6.i386.rpm installs /usr/bin/python2 and
/usr/bin/python2.1 instead of plain "python", which I assume Zope
expects.
Can I just create a symlink from python2 to python with no
side-effects for older applications that expect to work with python1?

Puzzled
FF.




Ype Kingma <ykingma@
Re: Performance of l


Chris,
you wrote:
>
> Hi all,
>
> I just took another look at:
>
> http://musi-cal.mojam.com/~skip/python/fastpython.html
>
> specifically, the loops section:
>
> """
> Loops
>
> Python supports a couple of looping constructs. The for statement is
> most commonly used. It loops over the elements of a sequence, assigning
> each to the loop
> variable. If the body of your loop is simple, the interpreter overhead
> of the for loop itself can be a substantial amount of the overhead. This
> is where the map
> function is handy. You can think of map as a for moved into C code. The
> only restriction is that the "loop body" of map must be a function call.
>
> Here's a straightforward example. Instead of looping over a list of
> words and converting them to upper case:
>
> newlist = []
> for word in list:
> newlist.append(word.upper())
>
> you can use map to push the loop from the interpreter into compiled C
> code:
>
> import string
> newlist = map(string.upper, list)
>
> List comprehensions were added to Python in version 2.0 as well. They
> provide a syntactically more compact way of writing the above for loop:
>
> newlist = [s.upper() for s in list]
>
> It's not really any faster than the for loop version, however.
> """
>

For larger lists you might find that using append in the loop takes
quadratic time and that the list comprehension allows the new list to be constructed in linear time.

> my question is: Why not? I like list comprehensions a lot, and they
> would seem to offer a way to get optimization over a for loop, much like
> map does, but apparently not. If map can do the loop in C, why can't a
> list comprehension?

Pass.

> In general, I like list comprehensions because they make Python a more
> "sequence oriented" language: When programming, it is very common to
> store a sequence of data of some type, and more often than not, do
> something with that whole sequence, rather than individual elements of
> that sequence. All that looping just to do the same thing to all the
> elements really clutters up the logic of the code. map and list
> comprehensions really help (as will element-wise operators, if we ever
> get them). However, it seems to me that sequence-oriented structures
> could really provide a performance benifit as well, but Python has not
> gotten there yet. I think a big stumbling block is that Python has no
> concept of the "homogenous" sequence. There are modules that provide
> such a thing (Numeric, array), and indeed, the string type is a
> homogenous sequence, but Python itself does not understand this concept,
> so that if a map or list comprehesion is using a homogenous list, it
> still has to check the type of every element as it goes through the
> list. For example:
>
> [2*a for a in list]
>
> If the interpreter could just check once what the type of all the
> elements of list were, it would only have to figure out what 2*a meant
> once, and it could whip through the list very quickly. Indeed, if you
> do:
>
> [2*a for a in a_string]
>
> The string is a homogenous sequence by definition (once you check that
> it is a string), but the interpreter has no understanding of this
> concept.
>
> NOTE: I fully understand that adding a concept like this allows for a
> whole set of optimizations that COULD be done, but someone would have to
> get around to doing it, which would be a whole lot of work, and might
> never happen. That's not a reason not to do it. First of all, the
> framework has to be in place for this kind of optimization before anyone
> can even start writing the code, and even if there are no optimizations
> ever built into the interpreter, the concept of a homogenous sequence
> would be very useful for extension writers. A number of times I have
> written an extension that needed a list if which all the elements where
> the same type. I had to put a type check inside my loop, which clutters
> up the code, and slows things down some. If I'm working with numvers, I
> use NumPy, but that's not always possible.
>
> As for what might get added, I'm imagining that it should be possible to
> automatically maintain a "homogeous" flag on a sequence: for an
> imputable sequence it would get set when it was built. For a mutable
> sequence, each time an element is added, a type check could be done, and
> the homogenous flag turned off if the type didn't match. (turning it
> back on when that item was removed would probably not be worth it).
> Ideally, there would be a way for the programmer to define what was
> meant by homogenous (i.e.: a NumPy array of doubles, or any Numpy array)
> This would be trickier, but when in doubt, the homogenous flag would
> just be turned off, and we'd be back where we started.
>
> Even if no changes were made to the list type, the concept could be put
> in place, and then existing homogenous sequences could be used more
> optimally.

This might work for sequences containing standard types. Instances of user
classes, however, may be changed while executing the loop over the sequence.
That means that the method that would be determined once to be executed
on all elements would not be the correct one for all elements accessed in
the loop.

Have fun,
Ype




"Rob Brown-Bayliss"
Re: PyGTK - 1.5.2 no
In article
,
"Adam 'Vonlia' Seyfarth" wrote:

> unalias-ing it, they worked, and it is cool! I would rather use
> Python2.1 if I can, but I don't use it's features, so I don't care much.
> But, do other people use PyGTK with 2.1?

Hi, I did this just yesterday.

You need to put your link back so the system thinks python2.1 is python,
then recompile your pygtk (and any other modules you want).




"Rob Brown-Bayliss"
Re: appropriate grap
In article , "Pete Shinners"
wrote:

> if you decide to go with pygame, i'd be glad to help out :] but don't
> let that rule out pyopengl first, especially the higher level object
> stuff that mike mentioned in an earlier post.

Has anyone used pygame embeded in a pygnome window (prefer glade setup)?

I am just starting on a project, and thought about useing the gnome
canvas widget, but as the project evolves (it's not a game as such) the
mixing of sound to the actions in the window could be useful.

--

Rob Brown-Bayliss
---======o======---




claird@starbase.neos
Re: Widget tooltips
In article <9n5ihb$1ikk$1@mail1.wg.waii.com>,
Martin Franklin wrote:
>Joăo Alfredo wrote:
>
>> Hi all,
>>
>> Does Tkinter supports widget tooltips?? If yes, how??
>
>
>The Pmw extensions do have balloon help.... check the vaults
.
.
.
You can also code tooltips in "pure" Tk. http://mini.net/tcl/tooltips > has pointers.
--

Cameron Laird
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html




"Neil Hodgson" <nhod
Re: COM/CORBA/DCOP (
Alex Martelli:

> I didn't mean to imply it had to be symmetric -- as long as the
> Automation protocols are respected from both sides, you may
> indeed be able to save some part of the marshaling overhead by
> this means. But you did say you can write automation code
> for BOTH client and server (check above, it's still quoted),
> and I'm still saying you can only do that if you write both
> sides -- in which case it WOULD be faster to use custom.

We are still disagreeing. I can independently write server code that does
not marshal, and you can independently write client code that does not
marshal. What is your definition of "marshal"? Mine does not include calling
a method, instead requiring a conversion process that moves, copies or
transforms the set of arguments into a different form.

In automation, much code uses a generic interpretive marshaller based on
typeinfo that does transform the argument set into another form. This code
is quite slow. Performance can be increased by writing your own specific
marshalling code or by not performing marshalling.

> No way, the Automation reference is adamant about it: Invoke
> *MUST* return DISP_E_MEMBERNOTFOUND if it's called with a
> dispatch-id that is not valid for this object -- it's NOT
> allowed to crash or return other random HRESULT's.

I don't believe this, callers must provide valid arguments. An incorrect
dispid is the same as passing an invalid pointer as pDispParams. Reference
please.

Neil






Marcin 'Qrczak' Kowa
Re: Performance of l
Wed, 05 Sep 2001 11:12:44 -0700, Chris Barker pisze:

> I think a big stumbling block is that Python has no concept of the
> "homogenous" sequence.

Do you mean a smart Python compiler/interpreter which tries to optimize
sequence operations in existing programs, on the assumption that many
will be homogeneous?

Or do you mean library support for explicit handling of homogeneous
sequences?


In the first case I think it's very hard, nearly impossible, because
of the mutable nature of Python. For example even if an implementation
knew that all elements of a list are the same class, mapping 2*x+1
through the list without method lookup on each element would need to
ensure that:

- The * operation yields the same class for all arguments, so +
doesn't need to be looked up in different classes.

- * and + aren't redefined in the class during the loop.


In the second case in alpha versions of Python you can already try
to map seq[0].__class__.__add__ instead of +, but I don't know if it
would be faster. It would check the type instead of method lookup.

--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK




John Hunter <jdhunte
Re: reading floats f
>>>>> "Pete" == Pete Shinners writes:

Pete> John Hunter wrote:
>> I have a file of ascii data arranged as a matrix of floats, eg
>> 0.3125 0.9418 1.2843 0.924516 0.92855 0.3125 0.6593 1.2843
>> 0.900514 0.900914 0.1667 0.9757 1.5611 0.893318 0.893699 I want
>> to read this data and process it a line at a time This works:
>> fh = open(dataDir + 'freqs_and_amps.dat') for line in
>> fh.readlines(): line = re.sub('^[ ]+', '', line) x = map(float,
>> re.split('[\r\n\t ]+', line[0:len(line)-1]))


Pete> strings already have a split() method that will split the
Pete> string based on whitespace. no need to bring RE into the mix
Pete> for this.

Thanks for the response.

How about this: is this the best way to print a row of floats to a
file?

x = (1.0, 2.0, 3.0, 4.0)
fOut.write( string.join( map( str, x ) ) + '\n' )

Thanks,
John Hunter




Roman Suzi <rnd@oneg
self-inheritance...
Interestingly enough, it works as expected:

>>> class Dolly:
... def a(s): pass
...
>>> class Dolly(Dolly):
... def b(s): pass
...
>>> a = Dolly()
>>> a.
a.__class__( a.__doc__ a.__module__ a.a( a.b(

Are there any means first Dolly-class could use to
intervene into inheritance mechanism and spoil
it?

Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd@onego.ru _/
_/ Wednesday, September 05, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "... Clinton sandwich: $5 of baloney and $20 in taxes" _/






Charles <charles@a3a
SocketServer
Hello
Anybody know where ca i find a good tutorial or
examples to create a Socket Server ?

Regards
Charles