Python 3.4 Beta 1 Released (opens in new tab)

Slash for Scala is not used by default though for path joining, but it can be by adding an implicit function:

  implicit def slash(str: String) = new { def /(joinStr: String) = str + java.io.File.separatorChar + joinStr} 

  val joinedStr = "abc"/"def"/"ghi"
  > joinedStr : java.lang.String = abc/def/ghi

#< Redirect STDIN

#> Redirect STDOUT

#>> Append to STDOUT

#&& Create an AND list

#!! Create an OR list

http://stackoverflow.com/questions/12772605/scala-shell-comm...

http://alvinalexander.com/scala/scala-execute-exec-external-...

I didn't really understand the attraction of an OO filesystem API until I actually used it in anger and realised how handy it was that all the relevant functions were on the object I was messing with, instead of arbitrarily divided between the "os" and "os.path" modules.

Some (hopefully constructive) suggestions for the pathlib API:

- Python 3 dicts ditched .iterkeys(), .itervalues() and .iteritems(); why does pathlib use the clumsy .iterdir() when it could just be called .children?

- Like many Python programmers (I assume), I'm more familiar with POSIX command-line tools than I am with POSIX APIs. Command-line tools generally have an option to control whether they dereference symlinks (cp -L, find -L, etc) rather than having a separate. parallel tool that does the same thing. I think it would be neater if .lstat() and .lchmod() were removed in favour of a "follow_symlinks" parameter to .stat() and .chmod() (and .is_dir() and .touch() and .owner(), and, and, and..)

- If you're going to have convenience functions that pick out interesting bits from the .stat() return value, I would find .size() far more practical than .is_socket()

[1]: http://twistedmatrix.com/documents/current/api/twisted.pytho...

[1] https://pypi.python.org/pypi/path.py/1.2

I certainly understand it can be somewhat tedious to convert legacy projects -- I've had to do it a few times myself -- but for any new dev, I'd highly recommend using Python3.

It's come to the point that Python3 is the assumed default for any new project - If someone wants to use Py2 for a project, they better have a compelling reason.. Almost every library we'd want uses Py3, or there's an alternative that does (such as PIL->Pillow).

I find it rather annoying when I go back to a Python2 project and have to constantly jump through hoops to avoid what I know are solved problems :/

Admittedly, my experiences (like yours) are anecdotal - But to answer your question, from what I've seen, Python3 is used in production quite a bit.

Going back to 2 is kind of a bummer when you add up all the little niceties you get with 3(.3): unicode native strings, smarter import system, yield from, keyword-only arguments... at least those were the features I used. It has some other stuff that I never got around to touching.

So 2014 really looks like Python 3 mass adoption.

I think everyone is expecting a really long tail to the transition, but we'll get there eventually.

"Debug tool for Python injecting memory allocation faults to simulate a low memory system to test how your application handles MemoryError exceptions."

http://www.python.org/dev/peps/pep-3156/

"The event loop is the place where most interoperability occurs. It should be easy for (Python 3.3 ports of) frameworks like Twisted, Tornado, or even gevents to either adapt the default event loop implementation to their needs using a lightweight adapter or proxy, or to replace the default event loop implementation with an adaptation of their own event loop implementation. (Some frameworks, like Twisted, have multiple event loop implementations. This should not be a problem since these all have the same interface.)"