Re: When will Windows Installers for Python 3.4 be available?

Hi,

TL;DR: Patch improving int performance submitted; requesting permission and 
time to work in further improvement with decimals.

On Wednesday 02 April 2014 16:12:50 Shai Berger wrote:
> 
> On Monday 31 March 2014 23:09:24 Anthony Tuininga wrote:
> > I am hoping to have a new release made sometime next week at the latest.
> 
> I am still working on a smail performance-improvement patch.

This patch is now pull request #6. It fixes a funny situation: without the 
patch, cx_Oracle will only process ints as C ints if the column is defined so 
that all values fit in an int -- and a 32-bit int. This means NUMBER(n) with 
n<10. However, the common definition of columns is intended to be able to hold 
all ints -- and is, therefore, NUMBER(11). When cx_Oracle sees that, it turns 
the numbers into Python strings and tells Python to parse them into Python 
ints.

The suggested fix uses a fast way to check the number of digits in actually 
returned values, and also takes the size of the C "long" type into effect -- 
and so, on today's common 64-bit servers, all NUMBER(11) values can be handled 
without going through strings.

However, this is still not satisfactory for me. My main motivation, as I've 
mentioned before, is improving the Django/Oracle combination; and it is very 
hard for Django to enjoy this improvement, because, in its role as framework, 
it needs to support Decimals. In practice, this means using numbersAsStrings, 
which nullifies the effect of the fix.

Currently, cx_Oracle supports Decimals as input, but not as output -- if 
numbersAsStrings is off, it returns Python floats, which are much less precise. 
However, Decimals and floats are not interchangeable -- if cx_Oracle suddenly 
starts to return Decimals where it currently returns floats, user code will 
break. 

But I still want a way to handle Decimals, without the performance 
implications of numbersAsStrings. The ideas I currently have are to add flags 
to control the reutned type of decimal fields: decimalsAsDecimals would be 
nice, but even decimalsAsStrings (preserve current behavior, but only where 
there is nothing better to do) will be a great help.

(On second though, decimalsAsDecimals sounds a little funny; it should 
probably be named decimalsAsFloats, and default to True for the time being).

I am willing to work on the required patches, but I would like to have enough 
time to include them in the upcoming version.

Thanks,
	Shai.

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR