[Python-Dev] Looking for master thesis ideas involving Python
Brett C.
bac at OCF.Berkeley.EDU
Thu Oct 30 21:11:35 EST 2003
Martin v. Löwis wrote:
> Brett C. wrote:
>
>>> - floating point: provide IEEE-794 (or some such) in a portable
>>> yet efficient way
>>
>>
>>
>> You mean like how we have longs? So code up in C our own way of
>> storing 794 independent of the CPU?
>
>
> Not longs, but floats. And you would not attempt to store it independent
> of the CPU, but instead, you would make as much use of the CPU as
> possible, and only implement things in C that the CPU gets wrong. The
> portion of emulation would vary from CPU to CPU.
>
OK, so in other words play cleanup for how the CPU handles floating
point by having custom code that deals with its mix-ups.
> As a starting point, you might look at the Java strictfpu mode (which
> got only added after the initial Java release). Java 1.0 was where
> Python is today: expose whatever the platform provides. In Java, they
> have the much stronger desire to provide bit-for-bit reproducability
> on all systems, so they added strictfpu as a trade-off of performance
> vs. write-once-run-anywhere.
>
Remembrances of Tim mentioning FPU exceptions start to flood back into
my mind. =)
>>> - deterministic finalization: provide a way to get objects destroyed
>>> implicitly at certain points in control flow; a use case would be
>>> thread-safety/critical regions
>>
>>
>>
>> I think you get what you mean by this, but I am not totally sure since
>> I can't come up with a use beyond threads killing themselves properly
>> when the whole program is shutting down.
>
>
> Not at all. In Python, you currently do
>
> def bump_counter(self):
> self.mutex.acquire()
> try:
> self.counter = self.counter+1
> more_actions()
> finally:
> self.mutex.release()
>
> In C++, you do
>
> void bump_counter(){
> MutexAcquistion acquire(this);
> this->counter+=1;
> more_actions();
> }
>
> I.e. you can acquire the mutex at the beginning (as a local object),
> and it gets destroyed automatically at the end of the function. So
> they have the "resource acquisition is construction, resource release
> is destruction" design pattern. This is very powerful and convenient,
> and works almost in CPython, but not in Python - as there is no
> uarantee when objects get destroyed.
>
Ah, OK.
>> Have no clue what this is since I don't know C#. Almost sounds like
>> Michael's def func() [] proposal at the method level. Or just a lot
>> of descriptors. =)
>
>
> Yes, the func()[] proposal might do most of it. However, I'm uncertain
> whether it puts in place all pieces of the puzzle - one would actually
> have to try to use that stuff to see whether it really works
> sufficiently. You would have to set goals first (what is it supposed to
> do), and then investigate, whether these things can actually be done
> with it. As I said: static, class, synchronized, final methods might
> all be candidates; perhaps along with some of the .NET features, like
> security evidence check (caller must have permission to write files
> in order to call this method), webmethod (method is automagically
> exposed as a SOAP/XML-RPC method), etc.
>
I remember that static and classmethod were reasons cited why the
func()[] proposal was desired. It's an idea.
-Brett
More information about the Python-Dev
mailing list