undefined | Better HN

0 pointsBoppreH11y ago0 comments

It's not possible to determine the language. The extensions are the same and much of the syntax hasn't changed, and many of the backwards-incompatible differences are subtle.

Python2:

    print(1/2 * 1000)    # 0
    print({b'a': 'bytes', u'a': 'text'}[b'a'])  # text
    print(b'A'[0])       # A

Python3:

    print(1/2 * 1000)   # 500
    print({b'a': 'bytes', u'a': 'text'}[b'a'])  # bytes
    print(b'A'[0])       # 65

And the merits of doing a backwards-incompatible version have been discussed to death elsewhere.

0 comments

jimmaswell11y ago

Python3's treatment of integer literals in that case is bad. The first is the behavior that someone used to programming will expect by default, since those are integers. If you want non-integer operations you should have to use a decimal point in the 1 or 2.

BoppreHOP11y ago

I disagree. A strong type system is good, but in this case pragmatism wins the battle. I personally have been bitten innumerous times by bugs where division was rounded down (usually to 0, which is especially destructive).

Most of the numbers I encounter start as integers and most of the calculations I need are floating-point. This language behavior saves me from sprinkling "* 1.0" everywhere on my code, or from introducing extremely subtle bugs.

And the integer division is always there, one character away:

    print(1//2 * 1000)   # 0

jimmaswell11y ago

I just think it's nuts that we're upcasting ints to floats implicitly. Explicitness over implicitness is one of Python's guidelines.

2 more replies

collyw11y ago

Looking at that example, the second one looks more correct to me without thinking about it too much.

But if I was writing it I would space the "1/2" into "1 / 2".

The first says half to me (ok, until I pause and realise it is code I am interpreting), while the second is 1 divided by 2.

heinrich599111y ago

The good thing is that you can get that behavior if you really intend it, just use the // operator. I'm really in favor of this change.

mark-r11y ago

Even better is that // has been available in Python 2 for ages, so you can get used to using it everywhere. Evidently they were anticipating this change.

pekk11y ago

A PEP saying "put a python2 shebang at the top to invoke python2 mode" could make this a solved problem.

im3w1l11y ago

What about

import2.7 modulefoo

BoppreHOP11y ago

It could work, but can you imagine the extra complexity for the interpreter? It would require extensive type conversions every time an object passes the version barrier, and all the Python3 libraries' classes would have to be backported for compatibility.

And it's not just a matter of sacrificing core dev hours for the greater good, the result would be much slower and full of gotchas.

This is a very creative idea, ingenuously simple, but I don't think it would fly.

xioxox11y ago

Unfortunately there's no way in knowing whether a Python 2 string (str, not unicode) originating from the module should be interpreted as a bytes string or text string. Python 2 doesn't have the clean separation between bytes and strings.

Solutions might include adding some sort of hinting to specify the conversion, or add a Python2-like string class to Python 3, which would pollute its purity.

j / k navigate · click thread line to collapse

0 pointsBoppreH11y ago0 comments

It's not possible to determine the language. The extensions are the same and much of the syntax hasn't changed, and many of the backwards-incompatible differences are subtle.

Python2:

    print(1/2 * 1000)    # 0
    print({b'a': 'bytes', u'a': 'text'}[b'a'])  # text
    print(b'A'[0])       # A

Python3:

    print(1/2 * 1000)   # 500
    print({b'a': 'bytes', u'a': 'text'}[b'a'])  # bytes
    print(b'A'[0])       # 65

And the merits of doing a backwards-incompatible version have been discussed to death elsewhere.

0 comments

jimmaswell11y ago

BoppreHOP11y ago

And the integer division is always there, one character away:

    print(1//2 * 1000)   # 0

jimmaswell11y ago

I just think it's nuts that we're upcasting ints to floats implicitly. Explicitness over implicitness is one of Python's guidelines.

2 more replies

collyw11y ago

Looking at that example, the second one looks more correct to me without thinking about it too much.

But if I was writing it I would space the "1/2" into "1 / 2".

The first says half to me (ok, until I pause and realise it is code I am interpreting), while the second is 1 divided by 2.

heinrich599111y ago

The good thing is that you can get that behavior if you really intend it, just use the // operator. I'm really in favor of this change.

mark-r11y ago

Even better is that // has been available in Python 2 for ages, so you can get used to using it everywhere. Evidently they were anticipating this change.

pekk11y ago

A PEP saying "put a python2 shebang at the top to invoke python2 mode" could make this a solved problem.

im3w1l11y ago

What about

import2.7 modulefoo

BoppreHOP11y ago

And it's not just a matter of sacrificing core dev hours for the greater good, the result would be much slower and full of gotchas.

This is a very creative idea, ingenuously simple, but I don't think it would fly.

xioxox11y ago

Solutions might include adding some sort of hinting to specify the conversion, or add a Python2-like string class to Python 3, which would pollute its purity.

j / k navigate · click thread line to collapse