Another solution: assuming as the article claims that GHash grew to it's current size because it had 0% fees. Other pools can respond by lowering their fees or introduce negative ones. I.e. they pay miners to join the pool. Or have fees but introduce a lottery system that randomly overpays members.
I have problems with the way this is worded as well. I don't think Python 3.x was a mistake. I think the mistake is continuing to develop it in parallel with 2.x with no definitive end of life for 2.x is the mistake.
No, I disagree. So many programs rely on further support for Python 2. When you would end the life of Python 2, I myself would think, if I have to make a switch, should I switch to a more reliable codebase??? (Ruby, maybe -- I don't know enough about Ruby, but I would have a look on it)
The reliability is one of Pythons strength and one of the reasons I use it. Take away the reliability and you will loose a lot. You will loose also many friends (like myself).
There was a blog post recently and stated an other option: Bring Py2 and Py3 nearer together to make the switch easier -- than more people would willingly move.
Some obstacles for moving where removed -- but a little late (e.g. the u"-Syntax was used many times in Py2 (at least outside english speaking countries or where localization is a topic) -- but abandoned in Py3. That was not necessary, but blocked an easy migration, because there are so many positions the code can be in. Now Py3 also supports the syntax and just ignores it ... why was that option not taken in the first place???) and not all. As much I know, there are still major differences when programming C extension libraries .... that makes porting existing libraries unnecessary troublesome.
Such things where not recognized early enough and still hamper adoption of Py3. Remove the blocks and you will gain more ground!
Setting an end of life for Python 2 would be the forcing function needed to ensure Python 3 is reliable and the migration path is clear. Knowing the end is coming would drive us (the community) together to discuss and resolve these issues.
I for one never even considered that C extensions would be a serious road block. Which is obvious now that you mention it. And my main point, I've never bothered to research moving to Python 3 because there's no sense of urgency.
If Guido set a date, say Jan 1st 2015, it would remove allot of the apathy we're currently seeing.
Even than, I doubt that it would be helpful, since still so many C extensions are just not available in Python 3. I also don't think that it is a problem of apathy, but of wrong initial planning. With better initial compatibility, a bigger momentum could be reached. Now the decisive point is over and we will have to live long with both versions around (even when Guido sets a date).
Only thing that could really help, I think, would be a really big improvement in Python 3 that makes it more attractive to move, but that could also widen the gap between the two.
The main intent of the search is to retrieve a list of urls that the site crawled for a given subdomain, domain or tld. So for now you can do that using reversed url notation. Which I admit is not very intuitive.
We're toying with the idea of implementing some sort of wild card that way we can present the urls in natural order. Something like *.google.com to retrieve all urls under google. But we wanted to judge the level of interest first. After all "done" is better than "perfect".
I think it's just that the site converts unicode urls for display purposes. If you click on one of the links with "@" in it, you'll see the real url in url encoded format
