E pur si muove

Resuming an scp file transfer

Thursday, August 20, 2009

Sometimes you have to transfer data over dodgy links. And when you're transferring a large file this can hurt when it fails. So as explained elsewhere rsync can safe the day:

$ scp host:remote_file local_file
# now interrupt and resume with
$ rsync --partial --progress --rsh=ssh host:remote_file local_file

You need rsync on the remote server for this however. But usually that's not too much of a hurdle.

Should bare except statements be allowed in the Python stdlib?

Thursday, August 13, 2009

Firstly to clarify the terminology, this is bare except statement:


And this is a non-bare except statement, but bear in mind the type of the exception that is caught can be anything:

except Exception:

The point is that both fragments are a catch-all exception handler, only the second is slightly more better/restrictive since it won't catch a SystemExit exception for example (which you rarely want to catch). This is obviously discussed before and even made it to a (rejected) PEP.

So I'm tempted to say that the stdlib should not use bare except statements. If you need to catch more then Exception they can always catch BaseException. However grepping the stdlib reveals 384 cases of bare except statements, to be fair many of these are in test cases but still.

The one that hurt me today was in socketserver.BaseServer.handle_request, now I have to re-write the .handle_error() function to call sys.exc_info() and check that it's a subclass of Exception before handling the error normally. That's not nice.


Tuesday, August 04, 2009

I've spent the last 2 days trying to get a stack trace from a crashing python extension module in windows. And I still haven't figured it out. That's sooo very motivating.

Give me GNU/Linux any day.

cifs why don't you follow unix conventions?

Monday, August 03, 2009

Often it's nice to just have conventions and gentleman's agreements. But then sometimes someone doesn't and the harm is done, it's too hard to reverse.

NFS has introduced the de-facto standard of using "<host>:<path>" for the defice of a remote mount. Yes this break because you can have ":" in a filename, but in practice it works.


But somehow cifs (formerly smbfs), decided that adhering to the windows syntax was more important then adhering to the unix standard, never mind that it's a filesystem implementation for unix-like systems. So the remote mountpoint for a cifs filesystem is "//<host>/<path>". Yes, this breaks too, you could start any path with "//". But it's just plain annoying when trying to figure out if a filesystem is remote or not.


Subscribe to: Posts (Atom)