RetroSearch Browse

Thu Oct 30 21:11:35 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039851.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039851.html below:

[Python-Dev] Looking for master thesis ideas involving Python