6 ms·

While you may end up being right, Perl6 is a much larger departure from Perl5 (than Python3 is from Python2). Can one even use CPAN with Perl6? Is it even possi

by pyre 12y ago

While you may end up being right, Perl6 is a much larger departure from Perl5 (than Python3 is from Python2). Can one even use CPAN with Perl6? Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time (like all of the PyPI packages that support both Python2 and Python3)?

BuckRogers 12y ago
It is a different departure, and it isn't a 1:1 comparison. That's true. But Python3 is an obvious failure and no one is admitting it, yet. I've seen claims from the core dev team about how Python3 is doing well because it has more downloads from Python.org, which is so stupid I won't even address it. A comparison of PyPI download statistics says it all. Python3 migration had many ridiculous ways of pushing people to migrate. The answer for Python3's adoption was always something new. It reads like the list of reasons for invading Iraq. Originally (and today's) overly optimistic EOL for Python2, then automated code conversion utilities, then porting all the major libraries, then 'six' type libraries to allow an ugly PythonX middle ground, then adding 3.x-only new features as a carrot, now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either. All that said, and I think this is the best-case scenario: Python3 will survive and eventually thrive. It will just be a shadow of Python's former glory. Is that -really- worth forcing unicode handling? For Zeus' sake, I wouldn't think so. This coming from someone who agrees with the change in theory.
- bane 12y ago
  > Is that -really- worth forcing unicode handling? I dunno. I'm new to Python (version 2 so far) and I easily spend 25-50% of my coding time fighting with ascii/unicode issues in Python. I wish Python 2.x just did something smarter. Similar, but not quite as bad, is the need for me to put str() around non-string values in concatenation. Just f'ing doing it for me. I'll write a bunch of code, put together a message in a concatenation only to have it blow up at run-time because of this. sigh I really miss Perl's implicit behaviors sometimes. I dunno, maybe this all is making me a better programmer and person, forcing me to really deal with Unicode now, and breaking me of lots of Perl bad habits. But it's really one of the sucky parts of the language. There's some days, after spending half the day fighting with this issue, that I almost decide to dump the whole thing and switch to Python 3.
  - BuckRogers 12y ago
    The problem is that both support unicode and 2 vs 3 unicode handling are just two different ways to do it. Which places Python3 firmly in the 'technological churn' category, rather than true technical innovation. I'd probably agree 3.x is more Pythonic in this regard, but I think it was an ill-advised move. Plenty of reasoning in my last response as to why. Why not go ahead and use Python3, you may find it works for you. For me, there's a long tail of libraries that don't exist there, and frankly following the core dev teams' example- we should all act in our own best interests. I'm far more productive in 2.x. I may eventually move to 3.x, but it will have to be based on its merits. Rather than dogma, salesmanship or propaganda. Today it isn't even close to 2.x and we're nearing 7 years since 3.0 was released. Unlike most things in life such as updating some software package, the "latest version" of a programming language isn't always in your best interests. I think this is a hard mental barrier to break down, especially people coming into Python now. But I would always recommend learning/using 2.x, not only is it easier to build cool things with it (the whole point), but you have to learn 2.x. You can avoid 3 entirely, without any issue whatsoever.
    - Retra 12y ago
      Are you using Python 2.X because you are maintaining existing code, or because Python 3 is just plain unsuitable for what you're trying to do? I hear a lot of complaints about Python 3, but in my (limited) experience, 3 is better than 2.X in practically every situation I've experienced. But I've never had to maintain anybody's old code in it, either.
    - pyre 12y ago
      > Today it isn't even close to 2.x So are you saying that it's clearly "pulled ahead" in the race? Or that Python 3.x is a significant regression? Your "technological churn" comment makes it seem like you think it's just treading water, which I would interpret to mean a lack of progress vs. a step forward (or back).
  - andreasvc 12y ago
    To avoid str() calls with concatenation, use % formatting: '%s %s' % ('hello', 'world') Avoiding these implicit behaviors helps avoid bugs; it's worth it. I'd recommend going for Python 3 unless there's a specific reason (library) keeping you on 2.
- sago 12y ago
  @bane - can I ask why you don't switch to Python 3?
- nostrademons 12y ago
  FWIW, I just founded a new startup and we're using Python3. No major problems so far, and I find it much more pleasant to work with than Python2.5-2.7 (which I used in my last startup, and at Google). Dictionary comprehensions are great, keyword-only arguments have been necessary in a couple cases, Unicode's not a total mess, I like how the standard library naming & packaging has been cleaned up, and I suspect I'll love asyncio when the time comes to use it. The only library we wanted which doesn't support it is Splunk, and that was Splunk's loss (we just switched to PaperTrail). There's an awful lot of FUD and hate for Python3 on Hacker News, but I've found it's great for a green-field project. And folks with 500KLOC existing systems should know that their technology choices are basically locked in time to when they started the project, anyway.
  - nailer 12y ago
    Man I remember when Splunk were the innovative disrupters. Now they're the ones who won't update their library for the current version of Python.
- lmm 12y ago
  All the talk has felt like giving up right before the finish line to me; it seems like migration was chugging along and then there was this huge backlash just before every distro made 3 the default, which would basically have been mission accomplished. Arch and to a certain extent gentoo were already there. And then suddenly, after quietly going along with it for 5+ years, everyone wanted to throw their toys out of the pram rather than do a little bit more. It's enough to make one think of conspiracies. As far as I can see, python 3 is there now; it's the default on my servers, all the libraries support it, and it's a nicer language to program in. And just as that became true, everyone started losing their minds.
- ptx 12y ago
  > then porting all the major libraries Yup, this was a gradual process, but by now everything I need is ported, even Django. > now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either. It worked on me: When Arch Linux made it the default I figured it was finally time to adopt it for my various everyday utility scripts, which resulted in me successfully pushing for it at work as the implementation language for several projects.
duskwuff 12y ago
> Can one even use CPAN with Perl6? Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time (like all of the PyPI packages that support both Python2 and Python3)? Respectively: Not at all, and not without major contortions. The languages have diverged a lot; even basic tasks like defining a function are not the same.
- ugexe 12y ago
  Respectively: https://github.com/rakudo-p5/v5 https://github.com/rakudo-p5/v5 While not quite the same as what was asked, it's clear that 'not at all' is not an informed answer
  - duskwuff 12y ago
    That module's neat, but CPAN is still out of reach. For one, a lot of important modules in CPAN contain XS components, which don't carry over. Additionally, a lot of the modules that don't use XS are likely to be using unusual features of Perl5 which aren't fully emulated by that shim.
    - ugexe 12y ago
      As its now been pointed out more than once, 'not at all' is not true. I did not claim it could use everything available on CPAN, but was pointing out that you were making a false statement based on, well, i'm not sure what you based your statement on but it was made in such a matter-of-factly way that it needed to be corrected.
    - raiph 12y ago
      Yes. v5, a Perl 5 compiler written in Perl 6, is promising tech with potentially huge long term (10 years) strategic consequences for Perl 5 and Perl. But it's very early days and it correctly handles only the simplest of modules. I'd hazard a guess that currently less than 1% of CPAN modules pass their tests when loaded by v5. But Inline::Perl5 is a completely different animal. It handles modules using XS or whatever fine. See my nearby comments for further details.
raiph 12y ago
> Can one even use CPAN with Perl6? Yes. At a Perl conference in October last year Stefan Seifert decided it was time for him to have a go at something Perl 6 related. He had never written Perl 6 code before, let alone participated in the project, but within 24 hours he had Perl 6 calling Perl 5 calling Python[1]. That was just a few months ago. Now the Inline::Perl5 module[2] allows folk to use Perl 5 modules, even ones that do C level guts poking in to the Perl 5 interpreter, and to pass data back and forth, do callbacks back and forth, handle exceptions raised by Perl 5 in Perl 6 and vice-versa, use Perl 6 to call methods on Perl 5 objects and vice-versa, and use Perl 6 to subclass Perl 5 classes. Thus he's been able to, for example, create apps in Perl 6 using a leading Perl 5 web framework called Catalyst.[3] He's also having fun with calling Python libs from Perl 6.[4] There's a lot more going on related to interop between Perl 6 and Perl 5, and more generally between Perl 6 and other languages, but the above is obviously a biggie. > Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time As is hopefully clear, with Inline::Perl5 there's no need to convert. (Some folk will still want to rewrite some Perl 5 code in to Perl 6, and there are fledgling tools to assist, but they aren't necessary, just a nice option to have.) [1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVMyE7mgkZHunXGw https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM... [2] https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5 [3] http://www.reddit.com/r/perl6/comments/2k6ii8/nines_apw_talk_demonstrating_fully_working/ http://www.reddit.com/r/perl6/comments/2k6ii8/nines_apw_talk... [4] http://www.reddit.com/r/perl6/comments/2n27el/perl6_20141121_cool_just_opened_my_first_qt/ http://www.reddit.com/r/perl6/comments/2n27el/perl6_20141121...

by pyre 12y ago

BuckRogers 12y ago

It is a different departure, and it isn't a 1:1 comparison. That's true. But Python3 is an obvious failure and no one is admitting it, yet. I've seen claims from the core dev team about how Python3 is doing well because it has more downloads from Python.org, which is so stupid I won't even address it. A comparison of PyPI download statistics says it all. Python3 migration had many ridiculous ways of pushing people to migrate. The answer for Python3's adoption was always something new. It reads like the list of reasons for invading Iraq. Originally (and today's) overly optimistic EOL for Python2, then automated code conversion utilities, then porting all the major libraries, then 'six' type libraries to allow an ugly PythonX middle ground, then adding 3.x-only new features as a carrot, now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either. All that said, and I think this is the best-case scenario: Python3 will survive and eventually thrive. It will just be a shadow of Python's former glory. Is that -really- worth forcing unicode handling? For Zeus' sake, I wouldn't think so. This coming from someone who agrees with the change in theory.

bane 12y ago
> Is that -really- worth forcing unicode handling? I dunno. I'm new to Python (version 2 so far) and I easily spend 25-50% of my coding time fighting with ascii/unicode issues in Python. I wish Python 2.x just did something smarter. Similar, but not quite as bad, is the need for me to put str() around non-string values in concatenation. Just f'ing doing it for me. I'll write a bunch of code, put together a message in a concatenation only to have it blow up at run-time because of this. sigh I really miss Perl's implicit behaviors sometimes. I dunno, maybe this all is making me a better programmer and person, forcing me to really deal with Unicode now, and breaking me of lots of Perl bad habits. But it's really one of the sucky parts of the language. There's some days, after spending half the day fighting with this issue, that I almost decide to dump the whole thing and switch to Python 3.
- BuckRogers 12y ago
  The problem is that both support unicode and 2 vs 3 unicode handling are just two different ways to do it. Which places Python3 firmly in the 'technological churn' category, rather than true technical innovation. I'd probably agree 3.x is more Pythonic in this regard, but I think it was an ill-advised move. Plenty of reasoning in my last response as to why. Why not go ahead and use Python3, you may find it works for you. For me, there's a long tail of libraries that don't exist there, and frankly following the core dev teams' example- we should all act in our own best interests. I'm far more productive in 2.x. I may eventually move to 3.x, but it will have to be based on its merits. Rather than dogma, salesmanship or propaganda. Today it isn't even close to 2.x and we're nearing 7 years since 3.0 was released. Unlike most things in life such as updating some software package, the "latest version" of a programming language isn't always in your best interests. I think this is a hard mental barrier to break down, especially people coming into Python now. But I would always recommend learning/using 2.x, not only is it easier to build cool things with it (the whole point), but you have to learn 2.x. You can avoid 3 entirely, without any issue whatsoever.
  - Retra 12y ago
    Are you using Python 2.X because you are maintaining existing code, or because Python 3 is just plain unsuitable for what you're trying to do? I hear a lot of complaints about Python 3, but in my (limited) experience, 3 is better than 2.X in practically every situation I've experienced. But I've never had to maintain anybody's old code in it, either.
  - pyre 12y ago
    > Today it isn't even close to 2.x So are you saying that it's clearly "pulled ahead" in the race? Or that Python 3.x is a significant regression? Your "technological churn" comment makes it seem like you think it's just treading water, which I would interpret to mean a lack of progress vs. a step forward (or back).
- andreasvc 12y ago
  To avoid str() calls with concatenation, use % formatting: '%s %s' % ('hello', 'world') Avoiding these implicit behaviors helps avoid bugs; it's worth it. I'd recommend going for Python 3 unless there's a specific reason (library) keeping you on 2.
sago 12y ago
@bane - can I ask why you don't switch to Python 3?
nostrademons 12y ago
FWIW, I just founded a new startup and we're using Python3. No major problems so far, and I find it much more pleasant to work with than Python2.5-2.7 (which I used in my last startup, and at Google). Dictionary comprehensions are great, keyword-only arguments have been necessary in a couple cases, Unicode's not a total mess, I like how the standard library naming & packaging has been cleaned up, and I suspect I'll love asyncio when the time comes to use it. The only library we wanted which doesn't support it is Splunk, and that was Splunk's loss (we just switched to PaperTrail). There's an awful lot of FUD and hate for Python3 on Hacker News, but I've found it's great for a green-field project. And folks with 500KLOC existing systems should know that their technology choices are basically locked in time to when they started the project, anyway.
- nailer 12y ago
  Man I remember when Splunk were the innovative disrupters. Now they're the ones who won't update their library for the current version of Python.
lmm 12y ago
All the talk has felt like giving up right before the finish line to me; it seems like migration was chugging along and then there was this huge backlash just before every distro made 3 the default, which would basically have been mission accomplished. Arch and to a certain extent gentoo were already there. And then suddenly, after quietly going along with it for 5+ years, everyone wanted to throw their toys out of the pram rather than do a little bit more. It's enough to make one think of conspiracies. As far as I can see, python 3 is there now; it's the default on my servers, all the libraries support it, and it's a nicer language to program in. And just as that became true, everyone started losing their minds.
ptx 12y ago
> then porting all the major libraries Yup, this was a gradual process, but by now everything I need is ported, even Django. > now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either. It worked on me: When Arch Linux made it the default I figured it was finally time to adopt it for my various everyday utility scripts, which resulted in me successfully pushing for it at work as the implementation language for several projects.

duskwuff 12y ago

> Can one even use CPAN with Perl6? Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time (like all of the PyPI packages that support both Python2 and Python3)? Respectively: Not at all, and not without major contortions. The languages have diverged a lot; even basic tasks like defining a function are not the same.

ugexe 12y ago
Respectively: https://github.com/rakudo-p5/v5 https://github.com/rakudo-p5/v5 While not quite the same as what was asked, it's clear that 'not at all' is not an informed answer
- duskwuff 12y ago
  That module's neat, but CPAN is still out of reach. For one, a lot of important modules in CPAN contain XS components, which don't carry over. Additionally, a lot of the modules that don't use XS are likely to be using unusual features of Perl5 which aren't fully emulated by that shim.
  - ugexe 12y ago
    As its now been pointed out more than once, 'not at all' is not true. I did not claim it could use everything available on CPAN, but was pointing out that you were making a false statement based on, well, i'm not sure what you based your statement on but it was made in such a matter-of-factly way that it needed to be corrected.
  - raiph 12y ago
    Yes. v5, a Perl 5 compiler written in Perl 6, is promising tech with potentially huge long term (10 years) strategic consequences for Perl 5 and Perl. But it's very early days and it correctly handles only the simplest of modules. I'd hazard a guess that currently less than 1% of CPAN modules pass their tests when loaded by v5. But Inline::Perl5 is a completely different animal. It handles modules using XS or whatever fine. See my nearby comments for further details.

raiph 12y ago

> Can one even use CPAN with Perl6? Yes. At a Perl conference in October last year Stefan Seifert decided it was time for him to have a go at something Perl 6 related. He had never written Perl 6 code before, let alone participated in the project, but within 24 hours he had Perl 6 calling Perl 5 calling Python[1]. That was just a few months ago. Now the Inline::Perl5 module[2] allows folk to use Perl 5 modules, even ones that do C level guts poking in to the Perl 5 interpreter, and to pass data back and forth, do callbacks back and forth, handle exceptions raised by Perl 5 in Perl 6 and vice-versa, use Perl 6 to call methods on Perl 5 objects and vice-versa, and use Perl 6 to subclass Perl 5 classes. Thus he's been able to, for example, create apps in Perl 6 using a leading Perl 5 web framework called Catalyst.[3] He's also having fun with calling Python libs from Perl 6.[4] There's a lot more going on related to interop between Perl 6 and Perl 5, and more generally between Perl 6 and other languages, but the above is obviously a biggie. > Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time As is hopefully clear, with Inline::Perl5 there's no need to convert. (Some folk will still want to rewrite some Perl 5 code in to Perl 6, and there are fledgling tools to assist, but they aren't necessary, just a nice option to have.) [1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVMyE7mgkZHunXGw https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM... [2] https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5 [3] http://www.reddit.com/r/perl6/comments/2k6ii8/nines_apw_talk_demonstrating_fully_working/ http://www.reddit.com/r/perl6/comments/2k6ii8/nines_apw_talk... [4] http://www.reddit.com/r/perl6/comments/2n27el/perl6_20141121_cool_just_opened_my_first_qt/ http://www.reddit.com/r/perl6/comments/2n27el/perl6_20141121...