As an experienced developer in Python 2 & 3, I would like to give Python developer team some significant comments.
It is understood that we all want to make Python better, more efficient and more robust to handle the ever growing algorithmic complexities in real life. Thus, for every change you are going to make to the language, I hope you could think over it very carefully. I also understand that different people have different ideas and opinions, sometimes they don't agree with each other, but then you should try to think of how to make a compromise w.r.t the majority, instead of just changing it at your own will.
Regarding the differences between Python 2 & 3, Sebastian Raschka (sebastianraschka.com/Articles/2014_python_2_3_key_diff.html) has given a very comprehensive and in-depth comparison. And I will base my comments on that list of differences:
In general, if you had been cautious enough in making compromises and considerations, I do not think that migrating from Python2 to Python3 should incur that many incompatibilities as what is happening now. To make a programming language better, you developers should be more cohesive and considerate in solving key issues (such as execution speed, multi-core multi-threading (GIL)) rather than enforcing your own preferential style and introduce numerous incompatibilities, and then old codes cannot run, and then efforts are needed to convert old codes into the new format. I do appreciate your efforts in adding new operators such as matrix multiplication '@', but those can be easily added on top of Python2 as well.
At last, I hope the developers can be more coherent in improving Python, only so can we together make Python better!
It is understood that we all want to make Python better, more efficient and more robust to handle the ever growing algorithmic complexities in real life. Thus, for every change you are going to make to the language, I hope you could think over it very carefully. I also understand that different people have different ideas and opinions, sometimes they don't agree with each other, but then you should try to think of how to make a compromise w.r.t the majority, instead of just changing it at your own will.
Regarding the differences between Python 2 & 3, Sebastian Raschka (sebastianraschka.com/Articles/2014_python_2_3_key_diff.html) has given a very comprehensive and in-depth comparison. And I will base my comments on that list of differences:
- The print function. The print statement in Python 2, even though it is not as powerful as the print function in Python3 (Python3 can specify the ending character), it is much more convenient in most cases: programmers do not need to type the (), which involves holding the shift key; for IO direction, ">>fp" is much simpler than typing "file=fp,"; for space ending, "," is much simpler than "end=' ',". Changing the print statement into a function will break compatibility on old codes. So how to incorporate your new idea in print function while preserving the old print statement? Very simple, you keep the print statement and add a printf function which does what Python3 print function do.
- Integer division. I do understand that in Python2 it is very annoying to type "float(a)/b" when you want to get floating-point value out of integer variables a and b. But if you do change that, you should realize that it actually breaks the systematicity of the programming language, i.e., addition, subtraction and multiplication between two integers all give rise to an integer value, so why division is an exception? Also, sometimes when you do need integer division, then you need to type int(a/b) instead. As a compromise, I suggest to use ./ to perform floating point division, it won't cause problems with 5./6 because both (5.)/6 and 5(./)6 will give floating-point values. Furthermore, the // operator in Python2 is redundant with math.floor(). So perhaps you can put all the 3 functions: ceil(), floor(), and round() into global namespace.
- Unicode. I have no objection of changing the default plain string to utf-8, but perhaps you can keep both u'' and b'' for backward compatibility.
- xrange. Beginners tend to use range only in a for loops, e.g., "for i in range(10)". But have you ever considered passing a range list into a function, i.e., I want to get a list [1,2,3,4,5]. Then, compare the two: {Python2 using range(5) and xrange(5)} vs {Python3 using list(range(5)) and range(5)}, which is simpler? I think if you want to highlight the iterator version of range, zip, etc., you may want to consider irange, izip, etc.
(Implementing the __contains__ method for range or xrange is quite straight forward, and thus should not cause any compatibility problem)
- Raising exceptions. Python2 is more robust that it supports both syntax "raise IOError, 'file error'" and "raise IOError('file error')", so why do you change it away? I hardly consider this as an improvement.
- The next() function and .next() method. I do understand that you want to make all builtin class member functions to look consistent, i.e., __func__, so you replaced the A.next() by A.__next__(). This is perfectly okay. But for compatibility, maybe you can create a default .next() method for every class and initialize it to point to .__next__() method. So next(A) or A.next() or A.__next__(), either way works. Btw, A.next() is more readable than A.__next__(), isn't it?
- For-loop variables and the global namespace leak. This is good for some programmers. But in terms of functionality, if I want the last covered item of [func(i) for i in arbituary_iterable], where the last valid element of the arbituary_iterable might not be that easy to get, e.g. arbituary_iterable is an iterator, or func(i) throws exception for some intermediate value i, and I want to know which i causes the exception, then Python2 is still easier.
- Comparing unorderable types. This change is elegant. It can review a lot of potential and silent bugs. And I don't think this will cause a lot of incompatibilities when porting from Python2 to Python3.
- Parsing user inputs via input(). You kind of eliminated the use of automatic type detection in Python2. But in terms of compatibility, I hardly consider this as an improvement. However, you do have a point because an input of '20' can be interpreted as either an integer 20, a floating point value 20.0, or a string u'20'. So as a compromise, I suggest to add an optional option in the input function, e.g., input('enter a number: ', type=int/float/str/auto), similar to the case of of add_argument function in argparse.
- Returning iterable objects instead of lists. As I mentioned previously, sometimes we do need to get the list object instead of the iterator object. Thus, the best solution is to keep both versions instead of performing an explicit list(...) function call. Thus, I would suggest creating both the list version (lrange, lzip, lmap, lfilter) and iterator version (irange, izip, imap, ifilter) and map the default (range, zip, map, filter) to one of these two, typically the list version for compatibility.
- Banker’s Rounding. This change is for convenience only. It is okay. But for compatibility, I would suggest to add a round2int function to explicitly round a value to integer.
In general, if you had been cautious enough in making compromises and considerations, I do not think that migrating from Python2 to Python3 should incur that many incompatibilities as what is happening now. To make a programming language better, you developers should be more cohesive and considerate in solving key issues (such as execution speed, multi-core multi-threading (GIL)) rather than enforcing your own preferential style and introduce numerous incompatibilities, and then old codes cannot run, and then efforts are needed to convert old codes into the new format. I do appreciate your efforts in adding new operators such as matrix multiplication '@', but those can be easily added on top of Python2 as well.
At last, I hope the developers can be more coherent in improving Python, only so can we together make Python better!
