nas

I don't see it as mystery as why it happened. Perhaps you are thinking there was some specific trigger for his stepping down. I don't think so. When the language becomes as popular as Python has, the head of the project is going to become a target for a lot of unwanted attention. The "assignment expression" PEP was a good example of that but not the sole cause.

Even if infuriating jerks are 0.1% of the population, when your language has hundreds of thousands of users, you are going to deal with a lot of jerks. Frankly, I'm surprised he lasted as long as he did without going mad or something. I would not wish for any of my friends to be subjected to that kind of attention.

We were very lucky to have him leading the project for so long. Python will survive without a BDFL and I hope he enjoys the vacation.

That's pretty much the main use of the new syntax. When you have a cascade of regexes, it is even better:

  if m := re.match(...):
     ...
  elif m := re.match(...):
     ...

The world is not coming to an end, as some detractors of the PEP might think. The new syntax is a win in a number of cases. Otherwise, you don't need to use it. The concern for abuse is way overblown. I could live without it (voted -1 on the idea originally) but now that it is in, think it is fine.

> The jury is still out on the Python 3 decision, to be honest.

It's not. Python 3 has overtaken 2 and there is no stopping migration to it now. Python 3.7 is a lot better than 2.7. Just on memory use alone, 3.7 is massively better. Sure, there will be some hold outs on 2.7 for a long time. That's fine.

Also, this is not the say that migration from 2 to 3 was handled well. It wasn't. Python 3.0 should have had backwards compatible features like allowing the 'u' string prefix. Indexing byte strings should have returned length one byte strings. Byte strings should have supported at least a minimal amount of %-style formats. Etc.

That has all been mostly resolved and is in the past. Mistakes were made because, shock, the Python core developers are not perfect and didn't foresee all the migration issues. However, there is no way that we are going back and reviving the Python 2.x branch.

I believe Tim Peters was trained as a mathematician. He is good at analyzing algorithms. Often he will post on the Python lists about the subtleties of floating point behavior. As you say, he read a much of recent research on sorting before coming up with TimSort. He special ability I think is making the "engineering" tradeoffs to come up with an algorithm that works well on real-world data.

That was the reason why they didn't make it a language feature in 3.6. However, after some careful consideration (there are some smart people making these optimizations and language spec choices, I trust they are doing the right thing), they decided to have 3.7 guarantee ordering.

After you have used it for a while, it is a great feature. I would now be happy to take a small dict performance hit in order to preserve the ordering guarantee.

It is possible the pickles you are talking about are fermented. They are indeed very different than what you would buy in the store. Other cultures have fermented pickles as well.

Regarding fermented cabbage, the sauerkraut you buy in the grocery store is very far from real fermented sauerkraut as well. It annoys me (maybe my eastern European ancestry surfacing) that they can even label it as such. If you have never had real sauerkraut, you are missing out. The grocery stuff is basically salty and sour cabbage. Tastes horrible.

My grandparents and great-grandparents homesteaded in Saskatchewan. I got to wondering how people in those times and living there did not get scurvy during the winter. I guess part of it was access to fresh meat. However, I know they also ate a lot of sauerkraut and "barrel pickles". The fermentation increases the vitamin C content of the food. I think even when they did not understand scurvy, they knew that eating that kind of food was healthy.

I've been meaning to make my own sauerkraut. It is really not difficult. I need some way to chop the cabbage. My parents have a special slicing machine. I suppose even a knife would do. Then you need some kind of fermentation container. Nothing complicated. The recipe is very simple. My grandmother used X tablespoons of salt per head. I've been using 2.5% salt by weight, which seems to work okay too. I like it to be less salty but still ferment and be safe. If I don't make it, I only get a taste when I visit my parents.

Is this supposed to be a response to the github acquisition? github != git.

The double quotes are the only thing that bother me as well. Double quotes are harder to type (on my keyboards) and look more noisy. All other Black formatting I think I could live with. I suppose I can live with double quotes on strings too but I'm not going to like it. ;-)

Do they have to use the term "cyber"? Sounds like they are old fogeys who are frightened by this new "information superhighway" thing.

Different strokes for different folks, I guess. I listen to and enjoy "The Daily" as well. However, I dislike the "human interest" stories. I would prefer it to be an unemotional summary of the previous days news.

I'm not a robot and I don't hate humans. ;-) However, I feel like those kind of stories can trick you into making illogical decisions. I.e. "think of the children" argument for some new policy. It is a trend in news that I dislike. I think they are trying to make the news more engaging but I think it is leading to poorer decision making.

I store the .kdbx (database) file on a network synced folder (e.g. like dropbox or gdrive). However, I use a "key file" in addition to a password. The key file is not synced and remains on computers that I control. I also have a backup copy on external media.

This is a good point. In the ag business, the dealers of equipment make little to no money actually selling the equipment. They make their profit on selling parts and doing servicing. So, keeping the necessary software tools locked to authorized dealers would be popular with the dealerships. It ensures you have to go to the dealer and not some 3rd party mechanic shop.

As a former farmer (roughly 4000 acres of dryland farming in Canada) and an engineer who also did embedded control system development, I would like to add some of my concerns.

For new ag machinery, embedded control systems are absolutely essential for the machine to do its job. The ECU on the engine is generally reliable and have long life. The other stuff, I'm highly dubious of the long-term maintainability of it. On our farm, we ran a lot of older equipment and did a lot of repairs ourselves. For new equipment, that will be near impossible as the electronic control systems are black boxes. Even the cabling is complicated and is generally not documented. After the machine gets a decade or two old, good luck fixing it.

I suppose you could just drive the machine in the junk pile. However, when a new combine harvester is costing around 3/4 of a million USD, that seems a bit wasteful. I don't know what the solution is though. The farmers buying new equipment don't care so much, their resale value is not suffering too badly. The manufacturers are looking for ways to sell new equipment and adding more features via electronic controls is a relatively cheap way to enhance the product.

Most farmers say they don't want all these new electronics on their machines. When Deere announced their S700 series combines, they had a video bragging about all the new improvements:

https://youtu.be/l5xJOoNyLoU

If you study it, you will notice that most of the new features are due to software changes or to electronic control systems. Little of what the machine actually does to harvest the grain has changed (metal parts, etc). This automation features are nice when they work but are a disaster when something goes wrong. The operator will have trouble to determine what the machine is doing (never mind trying to figure out how to fix it).

However, even though many farmers say they don't want it, the new machines are selling well. So, maybe you could argue the market is working. To me, it feels like there could be some externalization of costs going on. These new machines are very much less valuable as they get older vs the previous era of farm equipment. I guess the same thing has happened to automobiles. You can take a car from the 1940s and fix it up into perfect condition. If you take a 2017 car loaded with electronics, would you have any hope of fixing it to new condition in 50 years from now?

I'm a big supporter of open source software. However, I pay for a copy of Aquamail. I also paid for a version of K9, in order to support the developer. Aquamail is a good product and the developer is continuously improving it. I would hate to live in a world where your only options for email would be to use one of the big providers (gmail, office 365, etc).

BTW, Aquamail is free, just not open source. The free version has a few limitations, I think, like a non-changeable signature.

There are a number of them. Jekyll and Hyde are two of them. Wordpress is a security disaster, IMHO.

Datomic is interesting. It is somewhat similar to object databases like ZODB. I use an object database called Durus (spiritual derivative of ZODB). Both ZODB and Datomic make use of aggressive caching in the application. That is a huge performance boost for applications that do a lot of reading and little writing. ZODB essentially puts the indexes in the application, rather than having the DB layer take care of indexes. Again, I understand this is similar to how Datomic works.

Developing an application on top of ZODB vs on top of an SQL database leads to a very different data model design. You can't just swap one database layer out for the other and expect things to work well. I'm not surprised if a team who is used to developing on top of SQL-like DBs did not have good luck when moving to Datomic. It is just a very different model.

They screwed them up in pretty impressive fashion. Years ago, Google Groups used to be a great interface for searching Usenet archives. Now, it is near useless.

As an example, I wanted to do some research on early language features of Python (e.g. around 1993). The info is in Usenet postings of that time, surely present in Google Groups years ago. Now, I can't find anything useful. A advanced search using dates doesn't return anything. Their user interface is horribly bad compared to what it used to be.

Another example: I did some research on Deep Blue and Deep Thought, after reading Crazy Bird's book. With the old Google Groups, I could follow the discussion of the Deep Blue tournament, in chronological order. There was all sorts of interesting things like computer chess programmers speculating on how Deep Blue worked and people posting analysis of chess positions. All that is now gone or at least not searchable.

So sad that all of this knowledge has apparently disappeared. There was loads of information shared on Usenet and the storage space required to preserve it would be trivial.

For those still running 2.7 because migrating is too hard, consider using my "ppython" version (https://github.com/nascheme/ppython). It is a modified version of 3.6 with extra backwards compatibility features. After running your code through 2to3, it should mostly work with ppython. After fixing all the runtime warnings, your code should work with regular 3.6.

That's one way to avoid Spectre.

It is such an obvious rip-off, I just don't get it. 100% pre-mined. Essentially centrally controlled. Do a little searching on Jeb (remember a business called MtGox?). Mark is made out to be the daemon but look into the history of the site.

Disclaimer: I'm long on Bitcoin as well, longer than I want to be. Bitcoin is hugely overpriced IMHO. The technology has some promise but there are gigantic challenges to overcome. Ripple is a totally different beast, like comparing cats and bananas.

Speaking as someone who grew up on a grain farm and has owned a farm, this is correct. Obviously it is hard to generalize but low or no tillage farming has vastly lower soil erosion compared to conventional or organic tillage practices. For some reason, people have the set idea that organic practice must be good because its what our forefathers did. In reality, little we do regarding farming is actually sustainable. You are hauling tonnes of material away from the field every year. Those things are not going back, whether you are organic or conventional.

Also, it is a matter of relative severity of problems. Soil loss is much worse than depletion of soil nutrients. As said, organic is potentially much worse for soil loss (although different practices like intensive use of cover crops can help).

The big one for me is that LEDE uses a recent kernel. DD-WRT and Tomato use the kernel that was provided by the hardware vendor. They have an easier job to get things running because most hardware vendors have some crazy (perhaps binary only) kernel modules.

When buying hardware, look at the LEDE hardware support list. Recently I have bought a TL-WDR4300 (get right version) and a Buffalo Airstation N600 router. LEDE runs good on these and the router has enough flash and RAM. Running hardware vendor firmware is not good, IMHO.

Pandas is useful and I don't want to bad mouth it as people obviously find it useful. However, it has a complicated API and contains about 200k lines of code. So, it is not a surprise that documentation is a challenge and that there are lot of Stack Overflow questions. For example, figuring out which method result in copies of the data vs new views is hard.

Compare with dlply. It solves a similar problem as pandas does but has a vastly simpler API. To be fair, Pandas does do more but dlply is also more flexible. I looked at implementing something like dlply in Python but you really need to have a lazy evaluation syntax. dlply makes extensive use of this feature of R. As the downside, it can be very confusing to new users as it is hard to debug this lazy evaluation code.

Rather than adopting Pandas to build our product, I built a very minimal version of it (on top of numpy) that only does what we need. That was some extra work but I'm happy I did it as we avoid this huge dependency. I understand quite well my little minimal version does, it is only about 1000 lines of Python code and some tiny C extensions.

That's correct. If something like "six" would have been provided as part of 3.0, things would have went more smoothly. There could have been some language changes in 3.0 to make single-codebase easier. It was only later that the core developers realised that would be the normal way for libraries to support Python 3 (e.g allowing u prefix on strings in 3.x). Quite a bit of time was wasted while this got sorted out. Things are a lot better now. Soon, I think most people will stop worrying about 2.x backwards compatibility.

> Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it.

It seems pretty clear now that 3rd party library developers are going to stop releasing packages that support 2.x and target only 3.x. Isn't that a bigger problem for Python 2.7 hold outs?

Originally, I was not super excited about Python 3. I liked "print" as a keyword. I liked the space efficiency and speed of latin-1 strings by default. I did a lot of network protocol stuff and bytes() was a pain to use. I knew how to use the 'u' prefix to get unicode when I needed. However, after using Python 3 for a few years now, I find Python 2 clumsy. Print as a function is better. Unicode works better. The implementation is just as fast or faster than Python 2 and getting faster every release. If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot.

I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020.

That said, when nearly all of the Python 3rd-party library developers are targeting Python 3, do you really want to be stuck on 2.x? I think that's going to be the ultimate death of new Python 2.x development. The NumPy example seems typical. I.e. the cost of supporting 2.x is very soon not going to be worth it.

It seems clear to me now that there is not going to be a large faction of 3rd party library developers who refuse to move from 2.x. That is unlike Perl 5. As a Python developer, this is very happy result. The 2 to 3 transition was extremely painful but it appears to be mostly behind us now. Having two separate "flavours" of Python (2.x and 3.x) would have been bad.

I don't think anyone is going to pry it from you. If you want to keep using 2.7, go ahead. It's open source so you can even hire someone to keep maintaining it for you.

However, be aware that the vast majority of the people maintaining Python have moved on to 3.x. 2.7.x continues to be maintained because the team believes in giving people a stable platform and a long maintenance window. Long does not mean forever though and most of the people back-porting fixes to 2.7.x will stop by 2020.

So, you should have a plan for that. May give 3.x a spin and see how it works for you. I feel like 3.x adoption is speeding up because people have tried porting their code and decided that "yes, 3.x is better".

This is a key observation. Now apply it to the "eco-friendly" and PoS schemes. The same economics apply. For Bram's coin and PoS systems, the costs spent will rise to equal the block reward. So, you are basically doing something more complicated to end up with the same amount of economic waste. In the proof of space version, maybe you will be building millions of hard drives, running them to failure and then throwing them away.

Consider going to Costco. I think my Dad pays around 500 CAD for his set. They would likely cost more than double at other places. The service at Costco is great as well.

Also, as other people have said, they are expensive because they are technologically advanced and expensive to manufacture. You can build some kind of hearing aid for less than $100 but it will not compare with a $500 one.

Given that Oracle seems to have the midas shit touch (RIP John Dunsworth), does anyone have suggestions on Virtualbox alternatives? VMWare is the obvious one I guess.

It's great that they have released 5.2 and that they are adding new things. Virtualbox is a handy tool for me and I'm just afraid one day soon Oracle will turn it to shit.