Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pylons & repoze.bfg Merge

groups.google.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Pylons & repoze.bfg Merge

#21

Post by mdda »

windle wrote: post #19
old-gregg wrote: post #16

Earlier quoted context omitted.

:-) I guess I'll have to copy&paste to support my argument. A link isn't good enough: Due to the use of sub-classing, extensive, sometimes confusing, use of Stacked Object Proxy globals, and issues with configuration organization As an active Pylons user I never, ever heard of these issues in Pylons circles. Translation: nobody asked for these improvements. Statements like "sometimes confusing" aren't doing it. When?…

Many people loved "from pylons import config", until it didn't work, which frequently happened anytime someone wanted to use something from a Pylons app in a command line script (which seems to be pretty often). I do have a few minor clean-ups that help slightly with that stuff which I'll likely put out a Pylons 1.0.1 to address. > Let me make this clear: do I believe Pylons could be better? Yes I do. Do I think kill…

This is the first post in the thread that makes me feel good about what's happened - perhaps this approach should have been the lead story, rather than what appeared to be "If you're using Pylons then say goodbye to all the cool developers - they've found something else new and shiny to work on".

( I've been watching this thread with keen interest - having chosen Pylons (vs Django, and RoR) about two months ago. )

Re: Pylons & repoze.bfg Merge

#22

Post by jacobian »

windle wrote: post #20
jacobian wrote: post #17

This looks like good news to me: I've noticed that Pylons and Repoze shared a lot of common ground. Ben and Chris are seriously smart dudes, and I'm excited to see what they come up with when they put their heads together. I am a bit surprised though by the way that this was done. As an outsider, it sounds to me like this decision was made among the lead developers of each framework privately, developed in private, a…

Before this, there were several efforts and results of those efforts to combine code in common and share more. First, we had an informal set of talks that resulted in a 'pipefitters' type mail list where people sounded ideas around on how to build our stacks on more common components. Second, there was an effort on a code-branch called 'marco', that was to be a common set of code for a bunch of the underlying configu…

Thanks, Ben. I knew there had to be previous discussion that I was missing. Again congrats - this looks like a good thing to me, at least.

Re: Pylons & repoze.bfg Merge

#23

Post by d0mine »

windle wrote: post #11
old-gregg wrote: post #8

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…

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 exp…

Why Pyramid is not called Pylons 2?

Re: Pylons & repoze.bfg Merge

#24

Post by windle »

d0mine wrote: post #23
windle wrote: post #11

Earlier quoted context omitted.

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 exp…

Why Pyramid is not called Pylons 2?

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.

Re: Pylons & repoze.bfg Merge

#25

Post by ubernostrum »

zzzeek wrote: post #14
old-gregg wrote: post #8

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…

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/c…

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)

Re: Pylons & repoze.bfg Merge

#26

Post by beza1e1 »

windle wrote: post #20
jacobian wrote: post #17

This looks like good news to me: I've noticed that Pylons and Repoze shared a lot of common ground. Ben and Chris are seriously smart dudes, and I'm excited to see what they come up with when they put their heads together. I am a bit surprised though by the way that this was done. As an outsider, it sounds to me like this decision was made among the lead developers of each framework privately, developed in private, a…

Before this, there were several efforts and results of those efforts to combine code in common and share more. First, we had an informal set of talks that resulted in a 'pipefitters' type mail list where people sounded ideas around on how to build our stacks on more common components. Second, there was an effort on a code-branch called 'marco', that was to be a common set of code for a bunch of the underlying configu…

This sounds more like "Ben left Pylons to fork BFG"

Re: Pylons & repoze.bfg Merge

#27

Post by zzzeek »

ubernostrum wrote: post #25
zzzeek wrote: post #14

Earlier quoted context omitted.

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/c…

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)

yes, but I'm sure you understand the point, that the Django stack is "batteries included" whereas Pylons is not.

Re: Pylons & repoze.bfg Merge

#28

Post by windle »

beza1e1 wrote: post #26
windle wrote: post #20

Earlier quoted context omitted.

Before this, there were several efforts and results of those efforts to combine code in common and share more. First, we had an informal set of talks that resulted in a 'pipefitters' type mail list where people sounded ideas around on how to build our stacks on more common components. Second, there was an effort on a code-branch called 'marco', that was to be a common set of code for a bunch of the underlying configu…

This sounds more like "Ben left Pylons to fork BFG"

As mentioned below, there's no "leaving" involved. The pylons code-base has been maintained for several years with little in the way of new features, just bug fixes, some minor clean-ups, and security fixes. That isn't changing... so there's nothing 'different' for the pylons code-base involved.

I'm confused where this notion of leaving pylons comes from, when nothing is changing with it.

Re: Pylons & repoze.bfg Merge

#29

Post by jtchang »

If anyone happens to be in the bay area and is interested in a meetup to sit down and learn repoze.bfg and the differences between pylons let me know. I think it would helpful to get a bunch of us Pylons users together and talk about it.

Re: Pylons & repoze.bfg Merge

#30

Post by mdda »

windle wrote: post #28
beza1e1 wrote: post #26

Earlier quoted context omitted.

This sounds more like "Ben left Pylons to fork BFG"

As mentioned below, there's no "leaving" involved. The pylons code-base has been maintained for several years with little in the way of new features, just bug fixes, some minor clean-ups, and security fixes. That isn't changing... so there's nothing 'different' for the pylons code-base involved. I'm confused where this notion of leaving pylons comes from, when nothing is changing with it.

Last week I bought a top-of-the-range camera from Nikon. Excellent camera in every way : Great purchase.

This week, Nikon has discontinued the camera, and has announced that there's going to be a new range, even better, coming along soon.

Do I now love my camera as much as I used to?

Rationally, my opinion shouldn't have changed. But I sure wish that I had known that my investment in the previous product was a dead-end.

Post reply on HN