Posts

Showing posts with the label py3k

Writing for the latest python is FUN.

Image
Writing for the latest python version is just simply... fun. Even the name 'python 3000' or py3k is amusing. It's been a joy over the last week plugging away at a few personal website and game projects using the latest python version. Over the last year I've been involved in upgrading existing code to the latest versions of python... but not really in writing it JUST for the latest versions. No need to consider backwards compatibility problems... older pythons be damned when programming for fun! I'm able to take advantage of the latest python features in deep architectural ways. To fiddle around with the new deep magic python internals. But the new deep magic parts aren't the best bits though... it's all the elegant little improvements that make a difference. It is of great delight finding python 3 compatible modules. It turns out that the modules available for python 3 are often of quite good quality - and well maintained. There's not all that ...

2to3c: an implementation of Python's 2to3 for C code

"2to3c: an implementation of Python's 2to3 for C code" See http://dmalcolm.livejournal.com/3935.html for a description of this tool. It works on C modules. So it should be easier for people to do ports to py3k for their C modules. The 2to3c tool uses Coccinelle for transformations on the C code. This program has been used for linux, and other software... for updating code when their APIs change. The perfect fit for the python C API changes!

Where did the 'new' module go in python 3?

Anyone know where the 'new' module went in python 3? 2to3 can't seem to find 'new', and I can't find anywhere with my favourite search engine either... filed bug at: issue6964 . A complete 2to3 tool should know about all modules that are missing at least. It needs to actually know what to do with those modules, but should be able to at least tell you which modules are missing. I'm not sure how to get a complete top level module list sanely... I guess by scanning the libs directory of python. Or maybe there is a module to find all python modules? Each platform would be slightly different of course... and there'd be differences based on configure. Also some modules have probably stopped importing or compiling at all these days. Then you could just find the intersection and differences with the lovely set module :) # find the difference between the modules. top_level_modules_not_in_3 = set(top_level_modules3series) - set(top_level_modules1_2series) Wel...

py3k(python3) more than one year on - 0.96 % packages supporting py3k.

Python3 was released more than a year ago so far, and the release candidates and beta releases much before then. How successful has the transition been to python3 so far? One way to measure that is to look at how many python packages have been ported to py3k. One way to measure what packages are released is to look at the python package index(aka cheeseshop, aka pypi) . Not all packages ported to python3 are listed on pypi, and not all packages are listed on pypi. Also there are many packages which haven't been updated in a long time. However it is still a pretty good way to get a vague idea of how things are going. 73 packages are listed in the python3 section of pypi, and 7568 packages in total. That's 0.96% of python packages having been ported to python3. Another large project index for python is the pygame.org website. Where there are currently over 2000 projects which use pygame. I think there are 2 projects ported to python3 on there(but I can't find them at t...

python3 C API - simple slicing (sq_slice) gone.

Python3.x silently removed simple slicing support from the C API. The problem is, python3 doesn't give you a warning it won't be used... it compiles fine... just your slicing tests will fail. Since it's not documented anywhere, I will briefly mention a solution. Thanks to Campbell Barton for the idea. You can reuse your old sq_slice function and create a new function in a PyMappingMethods. You can also reuse your sq_length in the MappingMethods directly with no changes. http://docs.python.org/dev/py3k/c-api/typeobj.html#mapping-object-structures mp_subscript is it's name. Here is an example function from pygame.Color where it reuses _color_slice from the old simple slice function. static PyObject * _color_subscript(PyColor* self, PyObject* item) { #if PY_VERSION_HEX if (PyInt_Check(item)) { Py_ssize_t i; i = 0; #else if (PyIndex_Check(item)) { Py_ssize_t i; i = PyNumber_AsSsize_t(item, PyExc_IndexError); #endif if (i == ...

"raise" becomming a function in py3k?

Over on the voidspace blog, there is a little discussion about raising an exception in a lambda. Because raise is a statement, it's kind of a hard thing to do. Raising an exception as an expression that is. Which "raises" the question, why isn't raise a function in py3k? The two suggestions on how to raise in an expression were these: >>> r = lambda: eval(compile("raise RuntimeError", '', 'exec')) >>> r() >>> ctypes.pythonapi.PyErr_SetObject(*map(ctypes.py_object, (e.__class__, e))) Which are kind of both a bit yuk. So maybe raise could be a bit more expressive in py3k?

py3k Decimal?

From the Cobra language, comes the idea of using Decimal numbers as the default. It's 2008, so let's use decimals by default! This is an error that python has... Add 0.1 together ten times, and you do not get 1.0. >>> 1.0 == 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 False Maybe py3k should use Decimals by default instead? Or is this planned already? Python float performance is really bad anyway, so we might as well make it a little more accurate right? Floats are such a cause of errors in code, it'd be nice if math was more accurate by default :) It requires a fair bit of knowledge to understand all the quirks of floats, but less to understand the quirks of decimals. cu.