6 ms·

Can you articulate what you mean by Python 3's "accountant-like seriousness"? Is there more to it than print-as-a-function? I code in both every day and just d

Can you articulate what you mean by Python 3's "accountant-like seriousness"? Is there more to it than print-as-a-function? I code in both every day and just don't see what the fuss is about. To me, they're barely different dialects; more like different accents.

jMyles 11y ago
The many more generator-style iterables give it a strange dramatic tone to me. Also, the type hints syntax looks utterly un-fun.
- msellout 11y ago
  You can ignore the type hints syntax. I plan to. Python 2: map(func, iterable) # returns a list Python 3: map(func, iterable) # returns an iterator list(map(func, iterable)) # returns a list
  - jMyles 11y ago
    > You can ignore the type hints syntax. I plan to. I feel like that will be quite an ear-plugging, eye-covering endeavor. And that's really the point: it has the potential to create a community in which half the people are eyes-closed, ears-plugged. On your second point: Yeah, I don't mind casting things to a list. But it does seem... I guess, dramatic.
    - tedmiston 11y ago
      > And that's really the point: it has the potential to create a community in which half the people are eyes-closed, ears-plugged. This is a big concern of mine as well, both before/after listening to Guido's keynote on Type Hinting at PyCon (https://www.youtube.com/watch?v=2wDvzy6Hgxg https://www.youtube.com/watch?v=2wDvzy6Hgxg). At first I thought type hinting would only really see adoption in performance-oriented sections of code, but I think we're all curious to see what best practices emerge in general, and in the open source side of things. Really the additional robustness it unlocks for IDEs like JetBrains is what got me really excited about type hints in Python.
      - jMyles 11y ago
        > Really the additional robustness it unlocks for IDEs like JetBrains is what got me really excited about type hints in Python. Agreed. But that's only useful if the syntax is non-awful.
    - msellout 11y ago
      It's not technically a cast to a list. It's using the list constructor with the iterator as an argument.
vegabook 11y ago
First of all I don't think the print statement is a small issue. I bet 5% of my code is print statements. I love the print statement's unfussy "can do" mentality. Hey, the whole reason I got into Python was because it was utterly barebones. Print "hello world". that's it. You can almost feel the fun a young GvM might have had making it. Then all this u"xx" stuff on strings. What's that about? I don't care about unicode. 256 ascii characters is fine for me. If I need Unicode I can do it, but I don't need it by default. Iterators instead of ranges. Fine. Why again? To save memory? I've got 32 billion bytes. I don't need it. It's complicating something to please the computer scientists and it's messing with my mind which has far bigger problems to solve, so it's unpragmatic. If I see htop moaning about memory, I can easily change my code. Generally, I just like the 2.0 attitude. It's carefree. It just works. Three is trying too hard. Python is just a tool for me. My really hard problems are my daily battles with nonconvex optimization of vast data sets.
- delluminatus 11y ago
  I think you're confused about the strings. Python 3 uses UTF8 strings by default. The u"xx" syntax is only needed in python 2.x. In Python 3.x it's only supported for backwards compatibility.
  - vegabook 11y ago
    right thanks for clarifying - I wasn't confused until Python 3 made it confusing. EDIT: Ah I remember. In one of my attempts to move to 3 I wrote a few modules which worked with strings, then I had to stick "u"s everywhere when I passed them to my 2 code base.
- tedmiston 11y ago
  > Then all this u"xx" stuff on strings. What's that about? I don't care about unicode. 256 ascii characters is fine for me. If I need Unicode I can do it, but I don't need it by default. I felt this way before I started spending all of my time on web apps. It's reading user input data from some random public source, like Twitter, that forces it upon you. Then, so quickly it became the best practice to "unicode all the things". I think of analogous to how we store timestamps in UTC always.

jMyles 11y ago

The many more generator-style iterables give it a strange dramatic tone to me. Also, the type hints syntax looks utterly un-fun.

msellout 11y ago
You can ignore the type hints syntax. I plan to. Python 2: map(func, iterable) # returns a list Python 3: map(func, iterable) # returns an iterator list(map(func, iterable)) # returns a list
- jMyles 11y ago
  > You can ignore the type hints syntax. I plan to. I feel like that will be quite an ear-plugging, eye-covering endeavor. And that's really the point: it has the potential to create a community in which half the people are eyes-closed, ears-plugged. On your second point: Yeah, I don't mind casting things to a list. But it does seem... I guess, dramatic.
  - tedmiston 11y ago
    > And that's really the point: it has the potential to create a community in which half the people are eyes-closed, ears-plugged. This is a big concern of mine as well, both before/after listening to Guido's keynote on Type Hinting at PyCon (https://www.youtube.com/watch?v=2wDvzy6Hgxg https://www.youtube.com/watch?v=2wDvzy6Hgxg). At first I thought type hinting would only really see adoption in performance-oriented sections of code, but I think we're all curious to see what best practices emerge in general, and in the open source side of things. Really the additional robustness it unlocks for IDEs like JetBrains is what got me really excited about type hints in Python.
    - jMyles 11y ago
      > Really the additional robustness it unlocks for IDEs like JetBrains is what got me really excited about type hints in Python. Agreed. But that's only useful if the syntax is non-awful.
  - msellout 11y ago
    It's not technically a cast to a list. It's using the list constructor with the iterator as an argument.

vegabook 11y ago

First of all I don't think the print statement is a small issue. I bet 5% of my code is print statements. I love the print statement's unfussy "can do" mentality. Hey, the whole reason I got into Python was because it was utterly barebones. Print "hello world". that's it. You can almost feel the fun a young GvM might have had making it. Then all this u"xx" stuff on strings. What's that about? I don't care about unicode. 256 ascii characters is fine for me. If I need Unicode I can do it, but I don't need it by default. Iterators instead of ranges. Fine. Why again? To save memory? I've got 32 billion bytes. I don't need it. It's complicating something to please the computer scientists and it's messing with my mind which has far bigger problems to solve, so it's unpragmatic. If I see htop moaning about memory, I can easily change my code. Generally, I just like the 2.0 attitude. It's carefree. It just works. Three is trying too hard. Python is just a tool for me. My really hard problems are my daily battles with nonconvex optimization of vast data sets.

delluminatus 11y ago
I think you're confused about the strings. Python 3 uses UTF8 strings by default. The u"xx" syntax is only needed in python 2.x. In Python 3.x it's only supported for backwards compatibility.
- vegabook 11y ago
  right thanks for clarifying - I wasn't confused until Python 3 made it confusing. EDIT: Ah I remember. In one of my attempts to move to 3 I wrote a few modules which worked with strings, then I had to stick "u"s everywhere when I passed them to my 2 code base.
tedmiston 11y ago
> Then all this u"xx" stuff on strings. What's that about? I don't care about unicode. 256 ascii characters is fine for me. If I need Unicode I can do it, but I don't need it by default. I felt this way before I started spending all of my time on web apps. It's reading user input data from some random public source, like Twitter, that forces it upon you. Then, so quickly it became the best practice to "unicode all the things". I think of analogous to how we store timestamps in UTC always.