3 ms·

That's not merging - that's just killing Pylons. Ughh... The lesson for the future: when it comes to tech, stick with the leader. I didn't go Django route beca

That's not merging - that's just killing Pylons. Ughh... The lesson for the future: when it comes to tech, stick with the leader. I didn't go Django route because it felt clunky and bloated compared to more elegant and flexible Pylons, but I guess it was a huge mistake. Pylons decided to "collapse" itself in favor of even more (!) elegance (like someone needed that), and a year worth of work is now based on something "in maintenance mode", while Django is still around. Tip: looking for a Python web framework? Django. Why? It will be there tomorrow.

windle 16y ago
I'm sorry you feel that way, as the developer of Pylons, I really don't look at this as killing Pylons anymore than the lack of any new functionality has killed Pylons 1.0 in the past 6 months. Pylons 1.0 has been in maintenance mode already (effectively), 1.0 was in fact nothing more than a few tweaks on 0.9.7, ie. maintenance release with a 1.0 version number and finally killing a few deprecated things. The FAQ explains why when attempting to extend Pylons for new functionality, I hit a dead-end: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-code-base http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just... Finding a path forward for extensibility that didn't hit this forking problem: http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-and-forking/ http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-... was a very major concern of mine. I think this will address that, and when Django makes the changes necessary to remove the forking problem I won't be at all surprised if it requires porting your apps...
- d0mine 16y ago
  Why Pyramid is not called Pylons 2?
  - windle 16y ago
    We had originally considered calling it p2, unfortunately that would've sort of bound the package name to sound kind of odd when someday we get to Pylons 3. Also, given the amount of new code to merge in, and then slowly deprecate the old code in the pylons package... it seemed more convenient to use a new name. This also means that no one installing the 'pylons' package will have to worry about someday installing a version that deprecated things their old pylons app needed. Using pyramid means that you can use the new, along with the old one, at the same time, without worrying about version conflicts in the package.
zzzeek 16y ago
This is not at all an apt comparison. With Django, you're buying into its templating, routing system, its ORM, its view/controller paradigm, its central app configuration, its core request delivery system, whatever it does for caching/sessions, and all the admin stuff. With Pylons, you've bought into some choice of templating (usually Mako), routing system (Routes), some choice of ORM (usually SQLAlchemy), its view/controller paradigm, its central app configuration, its core request delivery system (Paste, PasteScript, etc.), caching/sessions (Beaker), and it doesn't come with any admin stuff. Pylons' change to Pyramid most certainly does not replace that whole stack. It replaces exactly two of those components, the view/controller paradigm and central app configuration. All the things that don't change at all are: templating, ORM, routing, Paste/Pastescript, caching/sessions still on Beaker. So this nothing at all like moving to an entirely new framework, Mako/SQLAlchemy/Beaker aren't going anywhere. edit: the routing changes a bit, but its an improved and higher performing package with mostly complete feature parity. I'm looking forward to using it.
- ubernostrum 16y ago
  Nit-pick: with Django, you're buying into an HTTP request/response interface and a system for mapping URLs to callables which obey that interface. Everything else is optional. (and you know this)
  - zzzeek 16y ago
    yes, but I'm sure you understand the point, that the Django stack is "batteries included" whereas Pylons is not.

windle 16y ago

I'm sorry you feel that way, as the developer of Pylons, I really don't look at this as killing Pylons anymore than the lack of any new functionality has killed Pylons 1.0 in the past 6 months. Pylons 1.0 has been in maintenance mode already (effectively), 1.0 was in fact nothing more than a few tweaks on 0.9.7, ie. maintenance release with a 1.0 version number and finally killing a few deprecated things. The FAQ explains why when attempting to extend Pylons for new functionality, I hit a dead-end: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-code-base http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just... Finding a path forward for extensibility that didn't hit this forking problem: http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-and-forking/ http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-... was a very major concern of mine. I think this will address that, and when Django makes the changes necessary to remove the forking problem I won't be at all surprised if it requires porting your apps...

d0mine 16y ago
Why Pyramid is not called Pylons 2?
- windle 16y ago
  We had originally considered calling it p2, unfortunately that would've sort of bound the package name to sound kind of odd when someday we get to Pylons 3. Also, given the amount of new code to merge in, and then slowly deprecate the old code in the pylons package... it seemed more convenient to use a new name. This also means that no one installing the 'pylons' package will have to worry about someday installing a version that deprecated things their old pylons app needed. Using pyramid means that you can use the new, along with the old one, at the same time, without worrying about version conflicts in the package.

zzzeek 16y ago

This is not at all an apt comparison. With Django, you're buying into its templating, routing system, its ORM, its view/controller paradigm, its central app configuration, its core request delivery system, whatever it does for caching/sessions, and all the admin stuff. With Pylons, you've bought into some choice of templating (usually Mako), routing system (Routes), some choice of ORM (usually SQLAlchemy), its view/controller paradigm, its central app configuration, its core request delivery system (Paste, PasteScript, etc.), caching/sessions (Beaker), and it doesn't come with any admin stuff. Pylons' change to Pyramid most certainly does not replace that whole stack. It replaces exactly two of those components, the view/controller paradigm and central app configuration. All the things that don't change at all are: templating, ORM, routing, Paste/Pastescript, caching/sessions still on Beaker. So this nothing at all like moving to an entirely new framework, Mako/SQLAlchemy/Beaker aren't going anywhere. edit: the routing changes a bit, but its an improved and higher performing package with mostly complete feature parity. I'm looking forward to using it.

ubernostrum 16y ago
Nit-pick: with Django, you're buying into an HTTP request/response interface and a system for mapping URLs to callables which obey that interface. Everything else is optional. (and you know this)
- zzzeek 16y ago
  yes, but I'm sure you understand the point, that the Django stack is "batteries included" whereas Pylons is not.