copyright straw

I was just reading about Ted Nelson, who still believes he is locked in an epic struggle with the web. Is it possible to be locked in an epic struggle if your opponent doesn't even notice?

Anyway, I came to this site after reading my favorite philosophy-disguised-as-humor site, and I thought that some other people should see these things juxtaposed.

Mr. Nelson: (whose work I am citing in a manner I am sure he would not approve of)

Most people don't understand the copyright law and how much it restricts re-use of content. No other system allows such re-use and is legal.

Others are trying to break the law, hoping that copyright will become permanently unenforceable. Ethical issues aside, this is probably a mistake. They do not recognize the determination and resources of the publishing and film industries. The large fines and occasional imprisonment of violators are likely to be only the beginning.

Still others are trying to change the copyright law, which is now the same in most countries (the Berne convention). Good luck, but change is not likely.

We work within the law. With the transcopyright system we offer the only legal, honest, daylight method of making on-line content reusable in new ways. Transcopyright is a permission system (or license) which lawyers agree is probably legal in all countries.

Mr. Holkins:

Digital delivery, man. It just freaks these people out.

Imagine that you had to go to a well every time you wanted water. Then, somebody figured out a way to get the water to come out right inside your house! I don't blame them for being scared. Progress is a bitch.

Plumbing can only remain a crime for so long while people still get thirsty.

A More Focused Proposal

As AMK has recently proposed, I think that the Python team should be focusing more on the standard library. However, I refrain from posting on python-dev to this effect any more because all I've had to contribute to the discussion is directionless whining. I consider it a given, however, that the standard library has reached a near-toxic level of bit-rot, although I rarely examine that assumption, although nits periodically come up that reinforce this impression, I hadn't ever thought of a nice "poster child", an issue with the stdlib that reflects the nature of the systematic problem.

The other day, when trying to hunt down a bug in my own code, I found a perfect example of this, though, and I think it should be a point of reflection for the Python team. Let me dress up this next point a bit, for emphasis:

The standard library does not provide a functioning debugger.

But what about pdb.py, you might ask? Well, pdb:

1. occasionally blows past breakpoints due to .pyc/.py/sys.path disagreements about pathnames
2. has no way of saving a set of breakpoints across invocations from within the debugger
3. integration with Emacs support does not work with python packages
4. doesn't allow you to view the stack when breaking inside a generator
5. provides no support for remote debugging or IDEs

There are probably even more issues than this, but I generally use a set of hacks included with Twisted and Twisted's Emacs support to work around these deficiencies.

These are also problems with basic functionality. There are other things I think a Python debugger should be able to do, for example, "fix and continue", which even environments working with a far less flexible language (for example, Microsoft Visual C++) manage to do.

So, I will focus on this point, for future discussion of Python development, to avoid unproductive discussion of differences of style and taste. I think we should all be able to agree that the Python debugger should not be broken in basic ways, such as missing breakpoints, and should work with all aspects of the language, including generators and list comprehensions.