37 karma · joined September 29, 2013
[0]: E.g., 3.3 adds a more efficient encoding for ASCII-subset unicode strings: http://docs.python.org/3/whatsnew/3.3.html#performance-and-r...
Edit: oh hello downvote, I'm glad you think AC is worthless to note.
</sarcasm>. The complaint is about Visual Studio's decision in particular, not the weakness of (some) (old) Win32 APIs.
Do people actually want deeply-nested project hierarchies?
For example, from a real-world, full operating system, the deepest path I can find[0] is in a build directory and 184 characters:
> "./ports/lang/python26/work/Python-2.6.1/portbld.static/build/temp.XXXXXX XXXXX-vHEAD-amd64-2.6/XXXXXX-home/XXXXX.git/src/ports/lang/python26/work/Python-2.6.1/Modules/_multiprocessing"
(Names changed to protect the "innocent.")
[0]:
$ mkfifo ../names
$ find . > ../names &
$ python
>>> with open("../names") as f:
... l = 0
... nm = None
... for n in f.readlines():
... if len(n) > l: l, nm = len(n), n
... print l, nmEdit: doh! Maybe just network.dns.disableIPv6=true solved it...
Alternatively, nocarrier [AT] the domain of the post.
Pros (vs Snakebite):
* C, not Python. More portable to non-Python languages; probably faster
* Speaks v1 of the protocol (AFAIK, nothing else does this except via JNI to hadoop's Java client)
* Kerberos authentication supported (but not datanode tokens or the digest auth they employ)
Cons:
* Sort of abandonware. I don't personally use HDFS anymore, so it has stagnated.
* As an extension of the above, doesn't support the v2 (Protobuf-based) protocol
* C, not Python. All the usual potential issues with C that Python shields you from.