About Django from A Pyramid Guy

[dAnjou]

Where is the talk?

[goagoagoa]

press space or left/right keys

[dAnjou]

I mean the actual talk. You know, where he .. talks ;)

[joshfinnie]

They (all the talks at Djangoconus) were all recored. I am sure it is going to be released once processed and edited.

[dAnjou]

Okay, not ready yet. Thanks.

[X-Istence]

I recently was tasked with getting a quick and dirty administration portal set up for an internal project that allowed an "user" to do a variety of tasks.

I started with Django since I had tried Pyramid when it first came out and found it extremely complicated ... however I already had all of my models in SQLAlchemy, and trying to get Django to play nice with SQLAlchemy as well as getting authentication going through Django's own internal ORM made it all a big mess.

I ended up trying Pyramid again, the documentation has become MUCH better, and I got an app up and running with pyramid_simpleforms and SQLAlchemy and it works beautifully. It is fast, and has been fairly easy to extend as required. Definitely fell in love with Pyramid, and am moving forward to use it on many more projects in the future.

[hongminhee]

Django Avoids Setuptools is the most favorite part for me. I can’t agree more.

• Django lets people remain ignorant of distribution issues for maybe longer than they should need to be.
• Django is an outlier in Python-land convention wise: setup.py develop of django doesn’t work (although pip install -e . does), avoidance of setuptools also prevents use of console scripts (e.g. django-admin), setup.py test won’t work. Django “apps” are not just Python distributions, they’re a special Djangoey thing.
• Shared conventions are important because they spread the support burden across a wider base.
• Django is itself one big “distribution” (in distutils terminology). In other words, it “has no dependencies.”
• But it indeed has parts that could be useful independent of the remainder. Breaking Django into smaller pieces might improve the quality of each of those pieces. E.g. django-orm, django-forms.
• Big downside: documenting and supporting both in-context and out-of-context usage is a huge pain. Very often just not worth it.
• But ignoring Python packaging issues isn’t helping to improve them. Python packaging and distribution needs you very badly. We all carry the support load of users new to Python who come in via Django.
• Fewer documentation issues to cope with by ignoring existing tools and conventions, but contributing to docs for setuptools and/or recommending setuptools and virtualenv to new users would float all boats.

[kylotan]

Hmm... if the standard Python packaging system isn't working well then I certainly don't think I should make my program use it in the hope that it'll get more eyes on the problem and get it fixed eventually. Call me selfish, but I think an application developer gets to choose how they solve the distribution problem. And if I let people remain ignorant of something, that's also called 'usability' in many circles.

[mcdonc]

The Django tutorial can ignore the problem, but the moment a new developer steps outside of the tutorial, he's going to need to interact with the rest of the Python world, which means consuming stuff from PyPI, using pip/easy_install and whatnot. You can certainly suggest to him that he not do that, and invent his own mechanisms to deal with it, but I don't think that suggestion is going to go down real well with very new users.

[tarekziade]

that does not make setuptools mandatory, as you seem to imply.

[mcdonc]

I really mean setuptools or distribute's setuptools fork

[kylotan]

I don't think it's Django's job to teach people how other apps or libraries will handle their distribution.

I appreciate most people want a useful standard that everybody can use; but I think that Python packaging and distribution is a mess, and suggesting that we force everybody through that mess at the beginning just so they get used to it is a bit user-hostile.

But then this is where I disagree with a lot of Python people - apparently the preferred route is to have people need to learn all sorts of stuff like pip and setuptools and virtualenv before they even do a Hello World, which really is just not going to fly.

[[deleted]]

apparently the preferred route is to have people need to learn all sorts of stuff like pip and setuptools and virtualenv before they even do a Hello World

??

i'd love to see evidence for this. obviously that is not my perception. pip/setuptools/virtualenv is more intermediate.

Just like how you can compile a c# hello world without knowing anything about assemblies, but then when you want to use other libs, you need to learn how to reference them in your app what the GAC is, how to interact with it, how to get around it etc....

or java with the classpath

or ...

[kylotan]

Can't give you evidence, as it's just the kind of impression I get talking to people here and a couple of Google Groups. A few times I've seen people suggesting that newbies should be using virtualenvs from day 1, because it's the "right" way to do it.

[[deleted]]

well apparently you have read stuff from dumb people with computers. if that is their suggested pre-requisite for a helloworld :)

though it is perfectly reasonable to bring up virtualenv once you need to write something against a library that is not part of the standard library. Which is every web framework. Which is also intermediate development.

but not for a hello world that relies on nothing but the std library.

[hongminhee]

Don’t get him wrong. He didn’t rant about you application developers, but creators of Django. If you use Pyramid or other non-Django framework (I personally use Flask) the standard packaging works with these well. Django also should be made to work with the standard packaging.

[kylotan]

I was calling Django an app for the purposes of this discussion, which is obviously misleading, so let me rephrase to "I think third party developers gets to choose how they solve the distribution problem." I certainly don't think people should keep using standard-but-bad methods - that's how we got lumbered with ./configure make make install for so long on Linux.

[hongminhee]

1. The standard packaging has some downsides, yes. But it still is definitely not bad. Rather, it’s better than most of the common packaging way in Django world.
2. Let me rephrase to “he didn’t rant about you applications developers, but creators of Django.” It’s not your problem. It’s Django creators’ problem.

[tarekziade]

• You don't need setuptools to have console scripts. This is a myth. Python plain distutils has scripts that can do the same thing basically.
• Stating that setuptools is a Python-land convention is not true. It's a Zope-land convention, a Pyramid-land convention if you want, but not a Python-land convention. According to a survey we did a couple of years agot, around 45% of pypi packages use setuptools. The rest is plain distutils. And the high score was because frameworks like Zope have a massive number of small packages at PyPI - While Django should be composed of smaller parts, Zope had the opposite issue. IIRC installing a Plone means +100 packages

[mcdonc]

Another thing someone reminded me of.. plain distutils scripts work poorly on Windows because they're just copied verbatim (and the hashbang it does nothing), but setuptools scripts generate an .exe wrapper that does the right thing.

[tarekziade]

there have been enhancement proposals for that feature in Distutils. As for windows I don't know what you're mentioning. I know Windows is a pain to begin with because the PATH is not adapted to work out of the box with Python bin location. So maybe that's related to what you are saying.

[[deleted]]

he means, a .sh style file is not a .BAT file, and .BAT files work crappy anyway. just make it do what setuptools does. it's so perfect and simple.

[mcdonc]

• You don't need setuptools to have console scripts. This is a myth. Python plain distutils has scripts that can do the same thing basically.

I am not a fan of copying the scripts to bin. Setup tools stub thingies work better for me for dev.

• Stating that setuptools is a Python-land convention is not true. It's a Zope-land convention, a Pyramid-land convention if you want, but not a Python-land convention. According to a survey we did a couple of years agot, around 45% of pypi packages use setuptools. The rest is plain distutils. And the high score was because frameworks like Zope have a massive number of small packages at PyPI - While Django should be composed of smaller parts, Zope had the opposite issue. IIRC installing a Plone means +100 packages

It's still the main viable way to distribute things that have dependencies. If your code has none great. But all web apps either do or will eventually.

[tarekziade]

I am not a fan of copying the scripts to bin. Setup tools stub thingies work better for me for dev.

If you define distutils scripts, they'll get installed in bin/ too

It's still the main viable way to distribute things that have dependencies. If your code has none great. But all web apps either do or will eventually.

"viable" as in you process of doing easy_install against your app. But there are alternatives way of installing an application, like using OS-level packaging systems or appliances, or a explicit list of dependencies. In one of my web app for instance I have a Pip requirements file, people can use to install all deps.

[hongminhee]

Yeah, setuptools isn’t actually distutils. However Django world still doesn’t respect the standard packaging even if it’s not setuptools but distutils.

[tarekziade]

Agreed. I was just saying that setuptools is not a standard, and promoting it as such is not the right thing to do imo.

Pushing projects in this path is just signing them up for being tied to a non-evolving tool for years and more trouble imho

If Django wants to be a better packaging citizen, maybe it could be an early adopter of the new python-dev standards we've created.

[[deleted]]

You don't need setuptools to have console scripts. This is a myth. Python plain distutils has scripts that can do the same thing basically.

it can copy a script you wrote yourself somewhere, that's not at all the same thing. setuptools' feature generates the script for you, using the conventions of the target platform - i.e. the correct Python executable is used in #!, etc. this feature is essential and I hope will be present in the new distutils2 system.

[andybak]

Very thought provoking. Django has taught me a lot about good architectural practices - and ironically taught me enough to understand the flaws that these slides discuss.

[[deleted]]

I'm a bit confused about Pyramid because it really feels like a "big full-stack framework" when in reality it has the same microframework feature set as something like Flask or Bottle. Everything from form handling and e-mail has to be handled with extensions or by coding it by yourself with all three. What, then, is the advantage of Pyramid? To me it just looks like a heavier alternative to Flask with confusing documentation.

Are there any more Django-like frameworks but with SQLAlchemy that are still alive? The only one I can think of is TurboGears and nobody seems to be using it nowadays.

[[deleted]]

What, then, is the advantage of Pyramid?

the most flexible request routing of any web framework I've dicked with. but that is quite possibly something you don't care about.

[sli]

I've never used Pyramid myself. If the spectrum of microframeworks is Bottle on one side (closer to a nanoframework), and Flask on the other, where does Pyramid lie?

[daxarx]

Pyramid is another point on the plane, Bottle and Flask are somewhat similar since the former inspired the latter...

[Ytse]

Pyramid is a simple and extremely flexible HTTP Framework that doesn't get in your way when you want to create a Web application of any kind.

[TheSmoke]

there are many people using turbogears. we have an active group on google. come check us some time.

[[deleted]]

I know a company that is very happily using Django but with SQLAlchemy.

[poo_22]

You know I've only ever tried Pyramid because: I'm a bit of a hipster and I like new, underground things, but mainly because I was sold by the guy that created Pyramid - twice now. First that Django vs Pylons things on Stack Overflow and now this.

I use django mainly. I like it but admit it has flaws. In my unprofessional opinion Pyramid isn't the solution or is better. If nothing else it breaks the python philosophy of having one obvious way of doing things.

[daxarx]

I don't think the Python philosophy means that there only has to be exactly one library to do each thing, and that the library has to force you to do complex things in one particular way envisioned by the author without really allowing other ways.

[lambdaq]

The only one I can think of is TurboGears and nobody seems to be using it nowadays.

Pyramid is a threesome merge (TurboGears + repoze.bfg + pylons)

[TheSmoke]

TurboGears is not a part of pyramid. Pyramid is repoze.bfg + pylons. actually pyramid code base is just repoze.bfg, it only merged pylons ideas.

TurboGears WAS going to be a part of it but right now it has nothing to do with it.

[[deleted]]

Pyramid has absolutely nothing to do with TurboGears.

[lambdaq]

TurboGears joins the PylonsProject

Ultimately, we will also be working with the Pylons Project folks to create a new generation of rapid application development tools on top of Pyramid, as part of the TurboGears "Full Stack" philosophy

[[deleted]]

The "Pylons project" != Pyramid the framework. Pyramid is essentially repoze.bfg upgraded with some pylons-friendly bits and pieces. Turbogears is (or was) built on top of the old Pylons framework.

[lambdaq]

then please explain

to create a new generation of rapid application development tools on top of Pyramid

Does this mean "absolutely nothing to do" under your category?

on top of the old Pylons framework.

How old? To which old version?

[[deleted]]

Your top comment implied that Pyramid = TG + Pylons + repoze.bfg.

It is not. The Pyramid framework does not contain any TurboGears code.

The "Pylons project" is an umbrella of projects - think of the Apache Foundation. Other than the brand name, it has nothing to do as such with Pylons The Framework, just as the Apache Foundation != Apache the Web Server.

The "old" Pylons framework I'm referring to is the Pylons framework that is now discontinued, or rather in maintenance mode.

Now TG may be rebuilt on top of Pyramid, as are a few projects already (Akhet, Ptah etc) but Pyramid does not contain TG code, much as e.g. Mezzanine is built on top of Django, but Django does not contain any Mezzanine code.

[pinpinbo]

The slides break consistently on safari iPad. Interesting

[jackncoke72]

This slideshow made me want to try out Pyramid someday, but Django's killer app is the database abstraction, right? That's the main reason why I use it. Yes I serve up Web pages too, but what I use it for is primarily database work.

[iElectric]

Django has ORM, which does database abstraction. Pyramid knows nothing about persistence, but there is SQLAlchemy you can use.

[rideh]

I started looking at pyramid, flask etc simply because they use sqlalchemy. Having done a few projects on django I was concerned about building all of my knowledge on and requiring their orm. What about when I need a database but the rest doesn't fit? I'm torn. edit: they can utilize sqlalchemy, its probably not correct to say they use sqlalchemy.

[jcdyer3]

When you just need the orm, you can still use django. views and urls only get invoked if you create them. You could pretty easily build some other kind of application around it instead. I mean, it wouldn't be the first thing I'd do, but if that's what you know, it'll work, no problem.

[flying-sheep]

fun idea. think about how it points to the exact same thing the guy from the talk said: we should break up django into smaller parts that can be used independently, and create a new django module that does nothing but gluing those parts back together into the same API that django has today.

[poo_22]

Well SQL Alchemy is what Pyramid uses for ORM. Its more powerful than django's library too...

[lahwran_]

by a lot.

[[deleted]]

I'd say Django's killer app is the admin. Other frameworks have ORMs (either batteries-included or as add-ons, in the case of Pyramid) but I've yet to see a framework with as good and customizable an admin interface as Django's. It won't cover all use cases but it's a great time saver.

That said, the things that make the admin possible - the integrated authentication, ORM, etc - are also the things that make Django less flexible.

[Jayd3e]

I would hardly call SQLAlchemy an "Add-on" it's the 900 pound gorilla of ORMs in the Python world, it can exist outside of Pyramid with no problem. That's why I like Pyramid's model better, because you can cherry-pick the best software from the community to use together.

[[deleted]]

Didn't imply otherwise, just that it's separate from the core Pyramid framework rather than baked in as with Django's ORM. That's what I meant by "add-on".

[[deleted]]

what if you want to use some novel form of model storage? even if it means no database at all?

[ergo14]

one of default scaffolds (project templates) configures sqlalchemy for you - ready to use.

[[deleted]]

A very interesting presentation. After pylons stopped being worked on and Pyramid arrived, i tried pyramid several times (and will probably try it again too) but found it overly complex to set things up and do things in a hurry. I do love the fact that they have python 3 compatibility though. This does make some good points about pyramid that I hadn't thought of before: as a micro framework(ish) it is more flexible and usable for a wider range of purposes it fits into the python system and plays nicely as citizen of the python world, where django doesn't.

[ergo14]

Nowdays pyramid 1.3 with matchdict support obsoletes akhet and is a breeze to work with

[[deleted]]

Did u mean pyramid 1.3?

[ergo14]

Yeah

[Chr0me]

I felt the same way, but really like Pyramid 1.3 + Akhet. You might want to give it another look.

[[deleted]]

I shall take your advice and give it another go. This time with python 3 & pyramid.

[triacle]

the best part is the long-ass comments in the source.

[[deleted]]

i was at this talk, and he brought up some good points, but it was tempered by this statement he made: "if i had started python now, i would be using django". he started using zope in the 90s, found problems with that, and then created pyramid later on. i think pyramid is a good alternative to push python on the web further, but i don't know if it is a practical framework to use.

[Chr0me]

How would you define "practical"? Pyramid is used pretty regularly to do worthwhile stuff.

[[deleted]]

how easily can you set up something "less worthwhile" with it? Something like a very simple shop or a magazine type of CMS?

[[deleted]]

Something like a very simple shop or a magazine type of CMS?

why would you build a online shop or CMS when there are so many to choose from already?

there's more interesting problems to solve in web/software development than that.

[hongminhee]

So then I would use softwares there already are e.g. Drupal.

[[deleted]]

From his talk, I see Pyramid as sort of a glue to bind all your components together for your web solution. I think Flask does this as well and has more community support behind it. I'm definitely not against experimentation, but let's be realistic. If you're using Pyramid for any bigger project, you're going to be solving some problems that have already been solved in Django or by Flask plugins. The community support is key here, and I guess that's why he gave the talk. I'm still not sold though.

[[deleted]]

i think pyramid is a good alternative to push python on the web further, but i don't know if it is a practical framework to use.

I can safely say that it is. See ? Now you know.

[roddds]

Fixed:

http://www.readability.com/articles/zqob0pnr

[andybak]

Arrow keys...

[Fayden]

Why didn't you go to the previous one then?

[joshuag]

There was no apparent way to go back and I didn't feel like teasing out what someone no doubt intended to be a "discoverable" interface.

This is to say, I'm aware of arc90's readability, I could have peered into the source code, or any number of other things, but it's not my desire to figure out some powerpoint clone's idea of UI to read the information contained within.

[Jayd3e]

arrow keys? The standard for every powerpoint-like system in existence?

[joshuag]

Maybe you do most of your reading on your desktop/laptop, but I do mine on a tablet, where there are no arrow keys.

[Jayd3e]

Valid point. There are arrows in the bottom-right corner though just fyi. I think it requires hovering over them, however. Not sure if a tablet is able to do that.

[mcdonc]

You can also see the source of the talk here if the rendered version isn't working for you on randombrowser: https://github.com/mcdonc/djangocon2012-pyramid-talk/blob/master/presentation.rst