I was just reading Guido’s status update for Python 3000. Though I have yet to go over the PEPs, his blog entry talks about some of the major changes, some of which effect the D-Bus python bindings and Sugar. None of this is worrisome but are things we should keep an eye on while developing.
I’m not sure if the unicode changes will help or hurt us in anyway though I will suspect they will help in that Python will be more unicode friendly.
The inclusion of mutable byte literals however will make it easier to support the array of byte type in D-Bus. We’ve been flailing our arms on this issue and though Simon has come up with an elegant solution in recent releases, it is always nice to have support in the language itself.
Print and Formatting
Printing and formatting seems to be to be the most invasive change though I suspect the conversion tools will take care of this.
The print command now becomes an actual function so we should most likely replace all occurrences of print ‘foo’ to read print(’foo’) which will work in current python and python 3000.
Formatting will be completely different, changing from the ugly % operator to a format method on string classes. While I do agree with the need for this change, we do use this everywhere and there will be no good way to be backwards compatible here. This makes it a bit of a bite the bullet when we move to Python 2.6 sort of thing as Python 2.6 will support the older and newer APIs with the older ones spewing warnings. We may just want to write a utility function for activity authors to use which will shield them from this change.
I kind of wanted to have these when designing the decorator syntax for exported classes. Instead I used metaclasses which means you have to inherit from dbus.service.Object in order to export your object over the bus. This leads us to having to do hacks in order to support multiple inheritance such as the newly added metaclasses for exporting classes which need to inherit from GObjects.
We may wish to explore using class decorators as a more flexible way for exporting objects in the future though there are behavioral questions to work out. For instance what do you do when an internal method such as Introspect is also implemented in the class.
In the future metaclasses will be specified via a class keyword (i.e. metaclass=MyMeta) instead of setting the magic __metaclass__ variable. D-Bus simply will have to switch over and most likely support two releases for a short while.
Python is getting typed…sort of. Methods and functions will be able to specify a type for its parameters and return value. These are only annotations and do not have any meaning to python. For instance:
def foobar(a: Integer, b: Sequence) -> String:
We can however deprecate the in and out signature keywords in D-Bus’ method and signal decorators and use this instead.
Sugar should also use this when we decide to move, to make the code clearer and allow debugging tools to have more context.
I’m sure there are other things that will bite us. I’m going to keep an eye on things and as soon as the alpha comes out start running some test. This is a long way off and with Python 2.6 giving us time to move with a migration path it is even a longer way off though at some point it will cause us pain and should be tracked to minimize the impact.
As it currently stands the Python team expects the alpha to come out some time in August with a goal of releasing Python 3.0 (which is the stable release of Python 3000) about a year later. Some months before Python 3.0 is released, Python 2.6 will be released and will roughly be the same as Python 2.5 plus all of the new bits that will be in Python 3.0, or at least the bits that we need for a orderly migration.
It is my hope that Python 3.0 will make python much cleaner and easy to support in the long run. If it achieves those goals then it is worth a little bit of pain in the short term.
[read this post in: ar de es fr it ja ko pt ru zh-CN