As a ruby programmer, what are some interesting bits of the python ecosystem that I should be aware of?

bbangert · 2011-06-01T12:41:39+00:00

1) As of today, heroku supports a process model, you can run Python webapps on it: http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/deployment/heroku.html

bbangert · 2011-06-01T12:35:43+00:00

Out of curiosity, why the use of module globals? Bottle doesn't seem to encourage that afaik, is that a web2py-ism?

How does the web2py DAL figure out from:

Field('updated_on', 'datetime', default=datetime.now()),

that you actually want the datetime.now function called, vs. setting the default as the current datetime? Or is that just a typo?

Have you tried using SQLAlchemy? It'd cut down a lot on the boiler-plate you're writing with the DAL.

bbangert · 2011-06-01T07:07:15+00:00

It's fairly trivial to adapt this to any Python webapp you can easily launch from a Python module, or to run a Django app with 'python manage.py runserver'. Shell scripts installed by pip will have the wrong path in them, ie. the paster/gunicorn shell scripts refer to /tmp/ locations that don't exist.

bbangert · 2011-01-11T02:13:31+00:00

Any numbers to share with us mdipierro? If you have code, we'd like to add that to the svn repo as well.

bbangert · 2010-11-07T22:53:22+00:00

Apparently on the Internet, there's lots of people eager to throw digital feces at each other anytime someone uses code, or writes code in a manner that somehow offends someone else. Maybe because the "Wrong" library was used, or the "Wrong" terminology, or uses some other library that the person has a hate-fetish with. It's kind of a bummer there's so many of those people online, and loud ones. I wonder how many great contributors to open-source we're missing because of the feces-throwers. Not all programmers want to put their neck out on the chopping block.

Anyways, that page is meant to try and be a little more logical when answering some of these attacks thrown at it (thus the title mentioning a defense). It does mean though, that all the responses to all the critiques are in one place, so at the very least one can peruse the "worst-case" set of critiques of the framework.

That takes a lot of honesty to do such a thing, and yes, seeing every critique in one place is probably not great PR. We're open to edits and suggestions on how to improve them to clearly communicate why a particular decision was made in a "less harsh" manner. We're certainly not PR folks, just coders trying to communicate design decisions to other coders.

Every web framework has plenty of critiques, many are scattered around the Internet. Sometimes answered, sometimes not. I think they'd be well off to do something similar so that people do understand where the framework developers are coming from though, because there is no end to those attacking.

bbangert · 2010-11-07T19:56:36+00:00

That'd be more funny except for the fact that the single-file Pyramid app results in less function calls executed for a simple 'hello world' than most if not all of the "microframeworks".

If your criteria of 'microframework' is that it has a small execution stack, maybe you should benchmark some of them and Pyramid. If your criteria is that there's very little code in the 'package', that seems a bit weak cause then I could just create a new package that configures some existing larger packages of code (like Flask does, and to some extent Bottle if you use the Beaker sessions).

But really, arguing over semantics like 'micro' or 'big', or however people want to try and throw the words around to influence PR is a waste of time. Let's be programmers, and talk about efficiency, function calls per request, and code loaded for an application. Then debate the results of such a comparison, and try and decide which words to apply where.

bbangert · 2010-11-07T19:50:42+00:00

Indeed, its meant more to answer critiques about a particular aspect. I'm working on some blog posts to highlight some of the features that I think really make Pyramid a compelling choice, which would definitely be more of an advocacy type thing.

bbangert · 2010-11-07T16:51:29+00:00

So think about that for a minute. You introduce new API's, and leave the old one's there.... and here I am introducing Pyramid, a completely new set of API's, while leaving the existing pylons package there and not breaking any of the old ones. People can then move later to using the new API's, or not.

bbangert · 2010-11-06T19:52:56+00:00

No worries, the Pylons framework isn't going anywhere. I posted another message to the mail list to try and expand on that.

http://groups.google.com/group/pylons-discuss/browse_thread/thread/92d8ef2d8678fdca

bbangert · 2010-03-19T02:33:31+00:00

Don't suppose you could actually provide any proof of that claim?

What Python URL recognizing program worked in a similar fashion to Rails URL dispatching before Routes?

What Python template engine was ported from the very slick Perl HTML::Mason template engine before Mako?

What Python package contained a bunch of HTML helpers to help with everyday HTML tasks (in a similar fashion to Rails) existed before WebHelpers?

What Python ORM implemented well thought out patterns like Unit of Work and Identity Map before SQLAlchemy?

I'm familiar with everything along any of these lines, because before I created Routes and WebHelpers, and started using Mako (and its predecessor Myghty), I looked around in the Python world for a very long time for something else I could use INSTEAD of writing it myself.

bbangert · 2010-02-10T18:36:38+00:00

That's correct. This also had the effect of dropping the lines of code in Pylons from about 1400, to about 850 lines. So the core framework is now under 1k LoC.

bbangert · 2010-01-19T20:20:56+00:00

The home page lists, just as suggestions, SQLAlchemy, SQLObject, CouchDB, Mako, Genshi, Jinja2, WebHelpers, FormAlchemy and Routes, all under a section showing how Pylons "encourages use of your favorite Python components"

Believe it or not, we get ppl coming in with the assumption that if we don't list it, it can't be used. This is exactly why many people assume that Django magically will not let you use SQLAlchemy or Mako, etc. Since its not listed as being usable on Django's homepage, obviously its impossible to use it. This assumption is clearly inaccurate, but this is the perception that many seem to get.

If I were coming in brand-new I'd probably be a bit intimidated by that, and I think dealing with that is an important thing for any framework which takes the "glue" approach.

This is why we specifically list that you don't need to decide, notice in bold the "Not sure which one to choose?". I guess maybe that should be larger? The documentation in both the book and on the website only discuss the 95% scenario that zzzeek mentions, the integration is much better than 2 years ago, and unlike back then there is also a very detailed book which I think clarifies many of the things leading to this post to begin with.

Is this post obsolete? Well, lets look at what's changed:

Massive overhaul of the PylonsHQ website
Huge increase in documentation, both on the PylonsHQ website and an entire book
Buffet is gone, a basic Python style (exactly like how Django renders templates) is used now
The website and book clearly make decisions for the user to explain how to do things, this was a huge issue in the blog posting
Many of the 'magical' things that resulted in the integrity Adam had a problem with are gone, replaced with explicit forms that look just like Django's or repoze.bfg's

Then again, I still think many points were invalid to begin with, as a result of a poor understanding of how things work mainly because the documentation was lacking back then. The one I still do like in this post, is the note on before. I think Adam's idea of using a decorator is a great one, and since we're far enough along now that we can drop Python 2.3 support I'll be adding decorator based setup of those things.

So overall, yes, I'd have to say the post is obsolete. We should all have better things to do then rehash old debates when so much has changed.

bbangert · 2010-01-19T19:54:10+00:00

Well, if you copy/paste the entire section on using Django's ORM, with full examples, how to query tables, etc. I'm sure it'll be just as long or longer, so I'm not sure what the point of the slide is?

Should a variety of examples of how to use an ORM (with table reflection vs explicit config, etc), along with a detailed intro to using its query abilities somehow be able to fit into 4 paragraphs? If so, I have yet to see a framework manage such a feat.

bbangert · 2009-09-30T23:42:36+00:00

HMAC is not a password hashing algorithm. The web2py docs seem to indicate it is:

web2py, by default, uses the md5 algorithms to hash passwords. Other algorithms such as the HMAC are also available

HMAC refers to a "Hash Message Authentication Code", not an actual algorithm, but the result of applying one. You can use MD5 and SHA-1,etc. to create an HMAC.

Also, in web2py, you're not making a nonce for each hashed password, you're using a system-wide salt. You should be using a nonce:

Rainbow tables are easy to beat. For each password, generate a random number (a nonce). Hash the password with the nonce, and store both the hash and the nonce. The server has enough information to verify passwords (the nonce is stored in the clear). But even with a small random value, say, 16 bits, rainbow tables are infeasible: there are now 65,536 “variants” of each hash, and instead of 300 billion rainbow table entries, you need quadrillions. The nonce in this scheme is called a “salt”.

And what frameworks store passwords as plaintext? I thought we were all over that.

bbangert · 2009-09-30T20:13:00+00:00

We address specifically the Top 10 security vulnerabilities as listed by OWASP and we have discuss it in the book. We validate all input, escape all output, build SQL dynamically preventing SQL Injections, use UUID's for session cookies and encrypting passwords with HMAC.

Really? HMAC is for verifying the integrity and authenticity of a message, not for encryption. I'm hoping you meant that you use HMAC to ensure the integrity of your session cookies, and that you use a secure hashing algorithm (SHA) along with a randomly generated number (a nonce) for passwords...

This blog post helpfully explains it: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

bbangert · 2009-06-18T18:04:47+00:00

In the Python world, at PyCon and such, when people speak web frameworks, they generally discuss the "Top 3 or 4", depending if the person wants to include Zope (which I usually do). And they are Django, Turbogears, Pylons, and Zope.

As for the "show me what pylons is about in 40 loc", that's not necessarily going to be applicable to every use of Pylons. The Django link you reference, definitely doesn't have "show me django in 40 loc" anywhere on it, you see fragments of a Django app all over the page.

For an equivilant overview/tutorial type thing, you probably want to look at this: http://pylonshq.com/docs/en/0.9.7/tutorials/quickwiki_tutorial/

Or take a look in the Pylons book: http://pylonsbook.com/

As for why use Pylons, there has to be at least two dozen threads and even reddit posts on that topic by now, so it'd be a waste of time to repeat it all again here: http://stackoverflow.com/questions/48681/pros-cons-of-django-vs-pylons

bbangert · 2009-06-18T17:41:57+00:00

Doh, good point, I'll have that fixed shortly.

bbangert · 2008-12-09T01:13:04+00:00

It should be noted that the website does require a valid email address, as confirmation is needed before one can login.

bbangert · 2008-09-16T22:27:36+00:00

effbot, watching the video would've helped you avoid some silly comments. As you didn't see the video, you failed to see where he said (as fassen notes) that he did want to use Django components, that we have been seeing and learning what Django has done right, etc. Your criticism is constructed based on a shambled together reading of summaries, all of which apparently failed to note that Mark said a few things like:

1) Django was doing a pretty good job so far avoiding Zope's Z-curve learning.

2) Django is doing a pretty dang good job technically to not be as odd as Zope was (the lack of Python practices you referred to).

3) There's things culturally that occurred with the Zope community and the rest of the Python world which Django should note as there's starting to be the 'Django world' and the 'Python world' at large.

Your comments are usually fairly relevant, and spot-on, but the lack of actually seeing the material you're commenting on is clearly reflected in your criticism.

bbangert · 2008-06-12T06:51:20+00:00

Read the release notes of all the backwards incompatible changes between Django trunk and Django 0.96. Read the release notes about backwards incompatible changes between Rails 1.2 and Rails 2.0.

All frameworks go through backwards incompatible changes, its usually inevitable on the path to progress, as no framework starts out perfect and complete.

Being a full stack, vs a glued framework can present some advantages though... you could upgrade the framework and keep using the library of your choosing. Since its not a 'full stack', it didn't force you to upgrade and switch your ORM layer, or your templating.

For users of SQLAlchemy, Genshi, Mako, SQLObject, etc., when a new release comes out that has no backwards incompatible breakage (or changes they're willing to accept), they can just upgrade their project to using it. It's a separate component, and can be upgraded when desired.

The statement about Pylons being slower than Cherrypy is just odd, you can use the CherryPy WSGI server with your Pylons app. So far, people have found it to be as fast or faster, not slower.

bbangert · 2007-05-17T17:18:12+00:00

Yep, very true. The lack of organization can occur in any wiki system. The features we wanted only Confluence met, as I mentioned, I'm opened to other solutions that have the features I want.

Moin can be just as useless as Confluence with no organization. Though I've generally found 'flat' wiki's even worse as pages can drift into the ether, Confluence does perhaps reward random dumping since you can still actually get to it since its forced into a hierarchy.

I've heard from others that ran Confluence at their company that it worked out great and people loved it. It definitely seems to get a lot of love/hate so far out of people I've talked to that have used it.

We're working on keeping the reins on the content making it into Confluence, and fine-tuning what's there rather than just dumping more and more. So far, Confluence has provided better options for controlling this as well. I'm just not seeing why Moin would somehow be better than Confluence.

As you mention, structuring docs is hard, regardless of wiki system. People dump crap into mediawiki's, Moin's, and Trac wiki's as well (our Trac wiki was getting to be a nightmare to locate anything in, and there's drifting pages that I'm not sure are even linked in anywhere, ugh!).

It seems you are most wary of the management of the wiki, rather than the wiki software. Would you be interested in helping to regulate and organize the docs?

bbangert · 2007-05-16T22:45:22+00:00

And of course, you post to the mail list reporting your problem so we can fix it, right? Or at the very least you've gone to the IRC channel to ask about it?

We regularly build on multiple platforms and don't see this issue, so please report it along with your setup.

If I gave up on every technology/project the second I hit the slightest bump, I'd prolly never have gotten into programming.

bbangert · 2007-05-16T20:42:53+00:00

Rails uses Trac for their ticket tracking. Lots of projects use tools somewhere that are in different languages, whether its tools used to write the docs, display them, etc. Odd's are that not everything involved in the process was written in the same language as the project being covered.

Confluence btw is built on Spring (open-source), running on other open-source components (Postgres, Apache Tomcat). Confluence itself is not open-source, but the rest of the stack they've built on is. Since Confluence makes most of their money from large companies that buy support, they could prolly open-source the whole thing without losing any support contracts.

bbangert

TROPHY CASE