3 ms·

I have my problems with the Python 3 implementation. Unicode is great, but standard library APIs should understand each other without the need to call decode.

I have my problems with the Python 3 implementation. Unicode is great, but standard library APIs should understand each other without the need to call decode. I like the way the change was rolled out, though: 1. Find a defined amount of cruft that needs to be fixed backwards incompatibly, so you do not take 15 years for it or fail completely. Release a new major version. 2. Make one or two minor releases to the older version to ease the upgrade. 3. Then STOP developing the older version, work with the community and perfect the new version to get everyone on board. I think it is the perfect middle ground. If you do this constantly you will not have the need to change everything at once and will also not amass cruft. The problem with the justification of the author for 15 years of Perl 6 development is, that Perl 6 will have issues, too. Are you going to change them all at once again and take another 15 years for Perl 7?

berntb 12y ago
>> Find a defined amount of cruft that needs to be fixed backwards incompatibly, so you do not take 15 years for it or fail completely. Python 3 have some traction, but the project's start wasn't that different compared to Perl 6... :-) >>Perl 6 will have issues, too. Are you going to change them all at once again and take another 15 years for Perl 7? The Perl 5 side has a heavy emphasis on keeping backwards compatibility. You have to declare the newer Perl features to use. I assume a similar path is planned for Perl 6? [Edit: And as cygx pointed out, the grammar for the language is dynamically extensible.]
masklinn 12y ago
> Unicode is great, but standard library APIs should understand each other without the need to call decode. If one "standard library API" generates integers and an other consumes strings, would you expect the second one to take the output of the first one without conversion?
- allendoerfer 12y ago
  No, I would not. To stay with your problematic analogy that differently encoded strings are to each other what integers are to strings: Would you write a function, that takes either a string or an integer and returns therefor either a string or an integer, so you can not feed the output of this first function into a second function, that is often called after the first, but can only take integers? Or would you rather say "Okay, we are working with numbers here, lets just take and return integers in this module."? You can read more about this here: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
cygx 12y ago
The problem with the justification of the author for 15 years of Perl 6 development is, that Perl 6 will have issues, too. Are you going to change them all at once again and take another 15 years for Perl 7? Learning from experience, one of the design goals of Perl6 was the ability gracefully evolve. Thus you get an object system with meta-object protcol, and you can extend the syntax through user-defined grammars. This probably also factored into the decision to have Rakudo support multiple backends.

berntb 12y ago

>> Find a defined amount of cruft that needs to be fixed backwards incompatibly, so you do not take 15 years for it or fail completely. Python 3 have some traction, but the project's start wasn't that different compared to Perl 6... :-) >>Perl 6 will have issues, too. Are you going to change them all at once again and take another 15 years for Perl 7? The Perl 5 side has a heavy emphasis on keeping backwards compatibility. You have to declare the newer Perl features to use. I assume a similar path is planned for Perl 6? [Edit: And as cygx pointed out, the grammar for the language is dynamically extensible.]

masklinn 12y ago

> Unicode is great, but standard library APIs should understand each other without the need to call decode. If one "standard library API" generates integers and an other consumes strings, would you expect the second one to take the output of the first one without conversion?

allendoerfer 12y ago
No, I would not. To stay with your problematic analogy that differently encoded strings are to each other what integers are to strings: Would you write a function, that takes either a string or an integer and returns therefor either a string or an integer, so you can not feed the output of this first function into a second function, that is often called after the first, but can only take integers? Or would you rather say "Okay, we are working with numbers here, lets just take and return integers in this module."? You can read more about this here: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/

cygx 12y ago

The problem with the justification of the author for 15 years of Perl 6 development is, that Perl 6 will have issues, too. Are you going to change them all at once again and take another 15 years for Perl 7? Learning from experience, one of the design goals of Perl6 was the ability gracefully evolve. Thus you get an object system with meta-object protcol, and you can extend the syntax through user-defined grammars. This probably also factored into the decision to have Rakudo support multiple backends.