Hacker News new | past | comments | ask | show | jobs | submit login

I love Perl [I have been to perl monger meetings and I had to look up how to 'unshift' in python today].

But Python3 is mostly just Python2 with a print function instead of a print keyword. It is occasionally non-trivial to port large existing code bases from Python2 to Python3, but it is practically always trivial for a Python2 programmer to write new code in Python3.

I hope Perl 6 will get its own camel book!




I remember buying the camel book ten years ago, and there was a slim Perl 6 volume next to it - http://shop.oreilly.com/product/9780596007379.do

I imagine its relevance to the Perl 6 that was announced today is next to nil.


The Perl 6 camel book will probably be published like TAOCP. /s?


If it's ever published :)


And stuff like map returning an iterator (instead of a list). Print being a function is the one everybody knows, but this one is the one that is more common for me. That and bytes/Unicode subtleties. Code rarely is much different in substance however.


> it is practically always trivial for a Python2 programmer to write new code in Python3.

Until you need to use some library that doesn't support python3. I think I've made the transition from python3 to python2 more than I have the other way around.


I've been writing forward compatible py2 code for years using the __future__ imports to ensure proper semantics are preserved. When all my external dependencies have py3 support it becomes a breeze to upgrade using 2to3 and the rare occasional manual fixup.


And your tests will validate nothing was broken, right? You have thorough tests?


Not sure why this was downvoted. I'm currently still in Python2 and looking to upgrade to Python3. Having solid automated tests is vital for us to do it confidently.


Probably the snark


But do you have tests for your tests? Assuming tests are written in Python2, gotta make sure they don't start testing the wrong things when you upgrade them...


The way I think of it, the code tests the tests. It's the the same way keys and locks verify each other.

Is there some sort of failure mode you're thinking of where I'd still see all the tests run but the test framework would give false success for something?


That argument is becoming a good way to tell who hasn't actually tried Python 3 lately, or is using out of date libraries.

More and more of the bigger libraries are ported already, and a lot of the others have been replaced by newer libraries that work with Python 3. If the library you're trying to use doesn't support Python 3, it's probably a good indication most people have moved on to something better...


Or until you trip over the API differences between str and bytes in Python 3 that do not exist in Python 2 (because str == bytes in Python 2). Chiefly, printf-style formatting...

  >>> b"%u" % 5
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for %: 'bytes' and 'int'



There's plenty of times it still matters. E.g. data coming in on webserver ->

json.loads(foo) blahblahException foo is bytes not text.

That said I still endorse py3 for new things


Why are you using % at all? It should have been deprecated years ago.


It's not deprecated, though.


Why? What are the benefits? % can have as much information about the string and the arguments as .format, can't it?

If I remember right, % used to be deprecated in Python 3, but was undeprecated again by popular demand.


Why? Maybe it suits his use case better than .format() or whatever.


We detached this comment from https://news.ycombinator.com/item?id=10342663 and marked it off-topic.


The mods are drunk with power!

: )

I commented because I didn't want the top comment to devolve into a Perl v. Python argument because I love both.

Looking at my comment now, it doesn't read as on topic.

Thank you for moderating. HN is my favorite place to read the news!


Thanks for being so nice about it!

What ends up becoming off-topic on HN, btw, is as much about upvotes and replies as it is about the original comment.


Not quite. I recently ported a script from Perl (which I can barely read) to Python (I used to know 2 pretty well) and took the opportunity to see what the differences between 2 and 3 are.

There's a pretty big page of changes, rules for maintaining compatibility and suggestions and it pretty much killed all my enthusiasm.

I'm speaking from memory and might be wrong, but one annoying thing was that I couldn't detect the Python version and print an error message, instead the P2 interpreter would throw an error at runtime when encountering a P3 construct.

There are many nice P3 books and libraries, but 2 vs 3 is still a PITA.


learning Python 3 is easier than reading any Perl...


Learning atomic parts of anything is very easy. Its using those atomic parts to build complex systems that is hard.

If there is a operator in Perl 6, which you don't have in Python- Your options are to rewrite those semantics in Python most of them pretty large, and they won't be easy to read either.

Ease of learning is a irrelevant metric. You can't use a needle to replace a saw, if you do you are only going to end up doing more work.


> Learning atomic parts of anything is very easy. Its using those atomic parts to build complex systems that is hard.

> Ease of learning is a irrelevant metric. You can't use a needle to replace a saw, if you do you are only going to end up doing more work.

I adore the elegance of your wording.


If you learn both by learning from a well-written book, then they are equally easy, though Perl, by its depth, might require a slightly bigger time investment.


I'd love it if there was, I'd love to kick a couple bucks to Randal after hearing he lost his house.


He lost his house? That sucks. Was that related to his felony charges? Like many others here I feel quite an affinity to the Perl community, sad to hear about that.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: