8 ms·

> six is non-optional for writing code for Python 2 and 3 I maintain a Python 2 & 3 compatible project that has no external dependencies.

eikenberry 7y ago
Same here, though mine is a small project. I'd guess six probably becomes more useful when you starting hitting certain features/areas of the language. I'd be curious about what things make six start being useful.
dpkp 7y ago
have you written your own 2/3 compatibility layer? I can't imagine writing anything large without six... fwiw, six can easily be vendored into a project to avoid the technical external dependency. that is how we manage it for kafka-python.
- jteppinette 7y ago
  No compatibility layer. Its really not bad. there are a few modules that are simply at different locations but have the same API if PY3: from http import client as httplib else: import httplib constants PY3 = sys.version_info >= (3, 0) PY2 = sys.version_info < (3, 0) PY26 = sys.version_info >= (2, 6) and sys.version_info < (2, 7) is string isinstance(<maybe_string>, basestring if PY2 else str) using different classes # Python 2.6 doesn't properly UTF-8 encode syslog messages, so it needs # to be performed in a custom formatter. formatter_class = UnicodeLoggingFormatter if PY26 else logging.Formatter
- X-Istence 7y ago
  You don't need all of six in most cases. You just need a couple of different functions. As the maintainer of WebOb/Pyramid/Waitress we have a compat module that contains all of the changes/renames/functions to help with the Python2/3 compatibility and all tests run across both platforms. Are the functions borrowed heavily from six? Yes, but we don't need to vendor all of six.
mehrdadn 7y ago
I do similarly as you (maintain 2/3 code without dependencies) but every time I have to do string encoding/decoding it kills me to find a way that half works, and I don't have a ready solution in my mind for these that doesn't break half the time. How do you handle non-ASCII in a compatible manner? Like Unicode stdio? Unicode file paths? Unicode sys.argv? string_escape/unicode_escape? I feel like Python 3 completely wrecked strings instead of making them better.
- jteppinette 7y ago
  You have to invest some time in understanding how strings (byte strings and unicode) work in Python. I put this off for way too long. After A TON OF PAIN I decided to put the time in to watch the talk "Pragmatic Unicode, or, How do I stop the pain?"[0] by Ned Batchelder and it all just clicked. Now, I make unicode sandwiches like a boss. [0] https://youtu.be/sgHbC6udIqc https://youtu.be/sgHbC6udIqc
  - dataflow 7y ago
    Uhm I think you misunderstood the problem. I already understand Unicode, and I can handle Unicode just fine as far as the facilities are there, in both Python 2 and Python 3 -- individually. The places where I have trouble are (1) where either or both languages do something nonsensical, (2) where the facilities just don't seem to be there (sys.argv?), (3) where there are bugs (try writing binary to stdout with IDLE open), or (4) where there seems no reasonable way to write code that behaves correctly in both languages without making your own little translation layer. Like as an example for #1, "a".encode('unicode_escape') == b'a' makes no sense. Why should escaping a string suddenly turn it into bytes? I never even specified an encoding for those bytes. And similarly why should "a".decode('unicode_escape') be an error? It makes perfect sense. What they did looked nice in theory (no implicit conversions between bytes and strings etc.) but IMHO they practically completely wrecked strings in Python 3.
    - dataflow 7y ago
      Also, I think the facilities are lacking for case-insensitive comparisons in Python 2, so I guess this is one thing they improved. Still don't know how to do it "correctly" when writing Python 2-compatible code.
333c 7y ago
Seconding this, I contribute to (and recently became a maintainer of) a relatively popular package that supports Python 2 and 3. We have 3 dependencies, and none of them are six. To be fair, one of our three dependencies does in fact depend on six, but we don't use six anywhere in our code. This dependency of ours is used only in one specific area of the codebase, and in fact I (the person who added the dependency) wish that we didn't have to use it at all.

eikenberry 7y ago

Same here, though mine is a small project. I'd guess six probably becomes more useful when you starting hitting certain features/areas of the language. I'd be curious about what things make six start being useful.

dpkp 7y ago

have you written your own 2/3 compatibility layer? I can't imagine writing anything large without six... fwiw, six can easily be vendored into a project to avoid the technical external dependency. that is how we manage it for kafka-python.

jteppinette 7y ago
No compatibility layer. Its really not bad. there are a few modules that are simply at different locations but have the same API if PY3: from http import client as httplib else: import httplib constants PY3 = sys.version_info >= (3, 0) PY2 = sys.version_info < (3, 0) PY26 = sys.version_info >= (2, 6) and sys.version_info < (2, 7) is string isinstance(<maybe_string>, basestring if PY2 else str) using different classes # Python 2.6 doesn't properly UTF-8 encode syslog messages, so it needs # to be performed in a custom formatter. formatter_class = UnicodeLoggingFormatter if PY26 else logging.Formatter
X-Istence 7y ago
You don't need all of six in most cases. You just need a couple of different functions. As the maintainer of WebOb/Pyramid/Waitress we have a compat module that contains all of the changes/renames/functions to help with the Python2/3 compatibility and all tests run across both platforms. Are the functions borrowed heavily from six? Yes, but we don't need to vendor all of six.

mehrdadn 7y ago

I do similarly as you (maintain 2/3 code without dependencies) but every time I have to do string encoding/decoding it kills me to find a way that half works, and I don't have a ready solution in my mind for these that doesn't break half the time. How do you handle non-ASCII in a compatible manner? Like Unicode stdio? Unicode file paths? Unicode sys.argv? string_escape/unicode_escape? I feel like Python 3 completely wrecked strings instead of making them better.

jteppinette 7y ago
You have to invest some time in understanding how strings (byte strings and unicode) work in Python. I put this off for way too long. After A TON OF PAIN I decided to put the time in to watch the talk "Pragmatic Unicode, or, How do I stop the pain?"[0] by Ned Batchelder and it all just clicked. Now, I make unicode sandwiches like a boss. [0] https://youtu.be/sgHbC6udIqc https://youtu.be/sgHbC6udIqc
- dataflow 7y ago
  Uhm I think you misunderstood the problem. I already understand Unicode, and I can handle Unicode just fine as far as the facilities are there, in both Python 2 and Python 3 -- individually. The places where I have trouble are (1) where either or both languages do something nonsensical, (2) where the facilities just don't seem to be there (sys.argv?), (3) where there are bugs (try writing binary to stdout with IDLE open), or (4) where there seems no reasonable way to write code that behaves correctly in both languages without making your own little translation layer. Like as an example for #1, "a".encode('unicode_escape') == b'a' makes no sense. Why should escaping a string suddenly turn it into bytes? I never even specified an encoding for those bytes. And similarly why should "a".decode('unicode_escape') be an error? It makes perfect sense. What they did looked nice in theory (no implicit conversions between bytes and strings etc.) but IMHO they practically completely wrecked strings in Python 3.
  - dataflow 7y ago
    Also, I think the facilities are lacking for case-insensitive comparisons in Python 2, so I guess this is one thing they improved. Still don't know how to do it "correctly" when writing Python 2-compatible code.

333c 7y ago

Seconding this, I contribute to (and recently became a maintainer of) a relatively popular package that supports Python 2 and 3. We have 3 dependencies, and none of them are six. To be fair, one of our three dependencies does in fact depend on six, but we don't use six anywhere in our code. This dependency of ours is used only in one specific area of the codebase, and in fact I (the person who added the dependency) wish that we didn't have to use it at all.