Hi Neil,<br><br>I've been fairly quiet on the Python-dev front for a while -- mainly because I use Python every day and it almost always works. However, as someone who regularly writes small C extension modules and types, I would certainly add a vote for sacrificing any vestiges of backward compatibility in order to rationalize the PyObject structure. The relative short-term pain of forward porting my code base is far offset by the long-term gains of having a legacy-free and streamlined structure. Put another way, forward porting code is less work than continuing to write code long-term against the current model.
<br><br>Two important disclaimers: 1) For my purposes, I don't need code that runs on both Python pre-3k and post-3k without change. 2) I have the ability and means to forward port my code and the necessary third-party extensions that I'll need. Many other developers and users will not have this luxury.
<br><br>-Kevin<br><br><br><div><span class="gmail_quote">On 3/21/06, <b class="gmail_sendername">Neil Schemenauer</b> <<a href="mailto:nas@arctrix.com">nas@arctrix.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Mar 21, 2006 at 05:01:31PM +0100, Thomas Wouters wrote:<br>> I would like Pythonic code to be usable in both 2.x (where x is,<br>> say, 6 or higher) and 3.0, but 3.0 shouldn't need to worry too<br>> much about it.
<br><br>The other question I haven't seen much discussion about is C API<br>changes. Are we hoping that people can port extension modules with<br>little effort or are we going to be doing lots of cleanup?<br><br>Some possible areas of cleanup:
<br><br> * Use unions for PyObject structure (allowing strict aliasing<br> by the compiler).<br><br> * Move GC attributes into the PyObject structure (e.g. similar<br> to how ob_size works).<br><br> * Rethink weakref implementation (not sure about details but
<br> maybe we can do better).<br><br> * Rationalize method structures (e.g. sq_concat and sq_repeat<br> could go away since we can use nb_add and nb_multiply).<br><br> * Rationalize finalizer behavior (e.g
. get rid of __del__<br> methods in favor of guardians?).<br><br> * Make it easier to write simple extension types. For example,<br> there could be standard tp_clear and tp_traverse methods that<br> could work if the object is simply an array of PyObject pointers.
<br><br> * Do we still need tp_print and tp_repr?<br><br> * Register instead of stack based VM?<br><br><br>One part of me hopes that we could do a lot of cleanup in these<br>areas. Another part is concerned about badly breaking the huge
<br>number of extensions out there (a major reason for Python's success,<br>IMO). In any case, I hope an important objective of P3K will be to<br>make writing extensions even easier.<br><br> Neil<br>_______________________________________________
<br>Python-3000 mailing list<br><a href="mailto:Python-3000@python.org">Python-3000@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/python-3000">http://mail.python.org/mailman/listinfo/python-3000</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/jacobs%40bioinformed.com">http://mail.python.org/mailman/options/python-3000/jacobs%40bioinformed.com</a><br></blockquote></div><br>