|
Hello everybody, I just like to know what all of you think of adding this functionnality to python language, or any other object oriented language in fact. (English is not my natural language so please e-mail if you can improve this text...) x.( ... ? ... ) could be equivalent to ( ... x ... ) So an _expression_ such as : (1) html.stringtohtml(''.join(a.strip().split('/n')[:-1])).lower() could be replaced with : (2) a.strip().split('/n')[:-1].(''.join(?)).(html.stringtohtml(?)).lower() (in this example html would be a module containing the function stringtohtml) The advantages of such a notation : - The order of operations always follows the (occidental?) reading order, from left to right. (in the formulation (1), we have a mixed of right-to-left reading and left-to-right reading.) - The number of nested levels - limited to 2 levels of parenthesis - does not grow with the number of successive operations (it soon gives problems with formulation (1)). This is a bit like in math you improve readability replacing f(g(h(j(x))) with f o g o h o j (x), except here this would be roughly looking like x.(j).(h).(g).(h) Then you get other advantages : - The growth of complexity in formulation (1) leads to the use of intermediates computations which introduces unusefull intermediates variables (they are just used once) b = a.strip().split('/n')[:-1] c = ''.join(b) d = html.stringtohtml(c).lower() These 3 intermediate variables used to improve readability can introduce bugs : you have to check that b, c and d are not used anywhere else in the code. With notation (2), you minimise the use of unusefull intermediate variables. - Builtins classes do not have to have many mumber fonctions. For example, though string class does not have any member function "tohtml" giving the ability to write s.tohtml() , you can still write s.(html.texttohtml(?)) or simplier s.(texttohtml(?)) after an import html.texttohtml I'd like to have your opinions about that... Daniel Delay. |
-- http://mail.python.org/mailman/listinfo/python-list
