Jesse Noller

Check here for an overview of the site redesign by the person who made it happen: http://jessenoller.com/blog/2012/11/28/the-great-python-org-redesign Great stuff.

Speaking for direct personal experience: the Python community is amazingly generous. In some ways, more generous and giving and understandable than any other community I've been part of. Of course, I'm grossly biased[1], and have been very lucky[2] [1] http://jessenoller.com/2011/07/28/thank-you-the-impossibility-of-its-g… [2] https://www.youtube.com/watch?feature=player_detailpage&v=yflKOoAo…

There's also "Good to Great Python Reads": http://jessenoller.com/good-to-great-python-reads/

I don't know about Ruby, but in Python, the GIL is there to protect the interpreter from complicated locking and memory management overhead that thread-safety would require of it: http://mail.python.org/pipermail/python-3000/2007-May/007414.html @jessenoller has a great summary of concurrency in Python: http://jessenoller.com/2009/02/01/python-threads-and-the-global-interp… The two worlds seem very similar.

Drat. I do agree with the analysis you posted on your site [1] that it only will affect early-adopters/language geeks and is probably for the best for the python community at large. But two years is a darn long time in the technology world. It looks like it will be up to the library/framework builders to keep the python hype/momentum going while the language maintainers are playing grown-up and being responsible. [1] for everyone else's sake: http://jessenoller.com/2009/11/09/pep-3003-python-language-moratorium-…

You are welcome. Actually, the inclusion of your processing module in 2.6/3.0 is an excellent example of a non-core developer getting code into the Python distribution. Your blog postings on the process (especially http://jessenoller.com/2009/01/28/multiprocessing-in-hindsight/) really show how challenging it is to add something to a system that big (and ported to so many platforms). I appreciate the work you've put into processing (and one of these days I'll get around to using it). Overall, the Python community strikes me as a bunch of really pragmatic, low-key people who have learned the hard lessons in the trenches of software engineering. To me, this is almost more important than the details of the language.

Dan, even using english as a first language - I have a difficult time articulating this subject. 1. English English is the more topic subject dividing engineers and programmer's from reaching their potential. These are people who are already on their path and passionate about growing themselves into programmers. Can you imagine how we can help them? Their potential if they have localized documentation? A story of disadvantage - imagine having an issue and being powerless to articulate yourself to a predominately english-speaking world of engineers. What about their hearts, their passions? And this is effective, safe. Helps people. Constructive. This is great news man. Now you see where I'm going? 2. The PC troll issue I feel tempted to blurt out every emotion. But when a particular group is mentioned - we have to make everyone happy? Why is pycon code of conduct pulled off geekfeminism.org (http://jessenoller.com/blog/2012/12/7/the-code-of-conduct). This is sensitivity not to woman, but I feel it's creating a culture of hysteria. Truly, I do not believe woman in the first world (I'm sorry if this offends people) are at risk of rape or sexual harassment at conferences. Most conferences do not have codes of conduct that state this because it makes you ask, "Why?". Do these people ever go outside, to starbucks, etc? Do they live in a Chapel away from vulgar language and stringent political correctness? I'm deeply sorry to offend anyone here. But how do you even get to…

Even in the context of slacking off, it is something that individuals might enjoy. When an individual imagines slacking off, their imagination might conjure a game of ping-pong or a cheeky 4pm beer. Whenever I hear the word burnout, I think of serious mental health and relationship problems, with a whiff of divorce and depression. Like, I'm reminded of this blog post: http://jessenoller.com/blog/2015/9/27/a-lot-happens

> At PyCon US/EuroPython everybody pays by default and the money goes towards financial aid so as many people as possible can attend. As a speaker, you can also apply for finaid of course. Just to add on — here's the rationale behind it: http://jessenoller.com/blog/2011/05/25/pycon-everybody-pays

Url changed from http://jessenoller.com/blog/2008/01/14/truecrypt-explained-in-python, which points to this.

Back in 2009, Jesse Noller wrote about his experiences with PEP-370 and seems to have felt that it is an improvement on the status-quo and a complement to virtualenv but not a replacement: http://jessenoller.com/blog/2009/07/19/pep-370-per-user-site-packages-…

Everybody who has ever spoken at PyCon for one (and volunteers as well): http://jessenoller.com/blog/2011/05/25/pycon-everybody-pays It looks like the OP is an established consultant/teacher, so he probably only goes to conferences that invite him to speak (and my guess is, from what I have heard about you tptacek, that you are in the same boat), so he may be unfamiliar with the practice. But for us peons, with little to no name recognition, conference papers and talks can be a big resume booster, so it's not out of the question to pay-to-speak (you still have to go through the proposal process though). In my old industry, this was standard practice, and because almost everyone had their conference registration and travel paid for by their employer, it wasn't a huge deal.

In Python 2.x there was a module for Berkley DB which is removed in Python 3 (bsddb module). I'm curious that since Berkley DB has always had a strong copyright license and it was not PSFL, how things worked legally. There is no mention in the docs[1] that if you use an import bsddb in your code you have to make it open-source. When they decided to remove it there was no mention of the license, just difficulty of maintenance[2]. So, was it possible to use Berkley DB without releasing your code as open-source before this change or was it because no one thought it was necessary to mention it in the docs? [1] http://docs.python.org/2/library/bsddb.html [2] http://jessenoller.com/2008/09/04/stirred-up-dem-bees-should-bsddb-be-…

Jesse was launching this at PyCon last week. It's a simple appliance NAS server that your normal, every day end users save files to via CIFS or NFS. It just happens to back onto the cloud. I.e: a secretary saves files to their D: drive, and it's in the cloud. And when you run out of disk space, you buy more from your cloud provider and suddenly there's another 10TB on your D: drive. I find this very neat as it brings cloud benefits (around reliability and expansion) to real people, using crappy early 2000s desktop apps - ie, most people using computers. Jesse's blog port on the launch: http://jessenoller.com/2010/02/09/say-hello-nasuni-launches-today/

You're asking a bit more than is answered directly here, but it may help, if you haven't seen it yet (skip to the middle of the page): http://jessenoller.com/2009/02/01/python-threads-and-the-global-interp…

This ends up needing to be posted in every Stackless discussion: Stackless DOES NOTHING ABOUT THE GIL! Stackless is not about concurrency. It's about implementing coroutines. It's a really easy mistake to make. Lots of people think Stackless threadlets look like Erlang processes, but instead, they look more like regular Python generators (although they're admittedly much cooler). To complicate matters, people sometimes actually do use the fact that you can pickle threadlets, send them across the wire, and resume them on another thread/process/machine to implement some form of concurrency, but this does not mean that Stackless gets around the GIL in any way vanilla CPython can't. To explain more about Stackless, I'll refer you to Jesse Noller's recent post on the subject: http://jessenoller.com/2009/02/23/stackless-you-got-your-coroutines-in…

I haven't studied it deeply, but a breadcrumb would be that cooperative threads (green threads) are equivalent to coroutines. Ok it looks like current techniques are stackless runtimes and compiling coroutines to stackless continuations: https://en.wikipedia.org/wiki/Stackless_Python https://stackless.readthedocs.io/en/v3.6.4-slp/library/stackless/stack… http://jessenoller.com/blog/2009/02/23/stackless-you-got-your-coroutin… https://engagedscholarship.csuohio.edu/cgi/viewcontent.cgi?referer=&am… https://pdfs.semanticscholar.org/b9aa/49e4b7a00e6c9f0d8c18ba9240c1223b… https://www.osnews.com/story/9822/protothreads-extremely-lightweight-s… This looks like a rare gem, although I just started reading it: https://cs.indiana.edu/~dfried/dfried/mex.pdf I grew up with the cooperative multithreading of classic Mac OS and was really shocked when I first saw Javascript back in the 90s and it had no notion of it (because it didn't have generators). That sent us down the callback hell evolutionary dead end, through promises/futures and finally to async/await where we are now. That could have been largely avoided if we had listened to programming language experts!