On 6/15/06, Nick Maclaren <[EMAIL PROTECTED]
> wrote:
I would do both. It is a lot easier to get something accepted when you have working code. But a PEP to vent possible arguments against the change along with any backwards-compatibility issues will be needed for something as major as changing how math works.
To work directly in Python's repository, yes, checkin privileges are needed. In order to get these, though, you usually either need to have been involved in python-dev for a while and be known to the group or have someone everyone trusts to watch over you as you do your work in a branch.
The C API docs are at http://docs.python.org/ and there are some docs at http://www.python.org/dev/ in terms of intro to how development for Python tends to take place.
-Brett
As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'
of IEEE 754 and (worse) C99. Yes, it's better, but I would like to
make it a LOT better. I already have a more robust version of 2.4.2,
but there are some problems, technical and political. I should
appreciate advice.
1) Should I start off by developing a testing version, to give people
a chance to scream at me, or write a PEP? Because I am no Python
development expert, the former would help to educate me into its
conventions, technical and political.
I would do both. It is a lot easier to get something accepted when you have working code. But a PEP to vent possible arguments against the change along with any backwards-compatibility issues will be needed for something as major as changing how math works.
2) Because some people are dearly attached to the current behaviour,
warts and all, and there is a genuine quandary of whether the 'right'
behaviour is trap-and-diagnose, propagate-NaN or whatever-IEEE-754R-
finally-specifies (let's ignore C99 and Java as beyond redemption),
there might well need to be options. These can obviously be done by
a command-line option, an environment variable or a float method.
There are reasons to disfavour the last, but all are possible. Which
is the most Pythonesque approach?
3) I am rather puzzled by the source control mechanism. Are commit
privileges needed to start a project like this in the main tree?
Note that I am thinking of starting a test subtree only.
To work directly in Python's repository, yes, checkin privileges are needed. In order to get these, though, you usually either need to have been involved in python-dev for a while and be known to the group or have someone everyone trusts to watch over you as you do your work in a branch.
4) Is there a Python hacking document? Specifically, if I want to
add a new method to a built-in type, is there any guide on where to
start?
The C API docs are at http://docs.python.org/ and there are some docs at http://www.python.org/dev/ in terms of intro to how development for Python tends to take place.
-Brett
5) I am NOT offering to write a full floating-point emulator, though
it would be easy enough and could provide repeatable, robust results.
"Easy" does not mean "quick" :-( Maybe when I retire. Incidentally,
experience from times of yore is that emulated floating-point would
be fast enough that few, if any, Python users would notice.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
