On 2011-3-17 15:59, Dylan Jay wrote:
So I think it's compelling to describe traversal in the manual as an
advanced routing feature and make it more clear exactly what scenarios
traversal is good for and why it's a great solution for those. I don't
think that means moving traversal to the back bec
On 05/03/2011, at 7:00 AM, Mike Orr wrote:
On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis
wrote:
I mentioned "unless there are new magical docs", because I think 99%
of the problems with pyramid right now are the docs. They're hard
to
sift through (rather dense) and easy to miss things in
On 04/03/2011 20:03, Mike Orr wrote:
I'll be at the Pyramid sprint but I don't know what I'll be doing.
I would like to learn Git and Pyramid-at-Github if somebody would like
to do a mini crash course.
Me too please!
I'm currently petrified of all things git and could use some hand
holding.
Yeah like i said it's not a big deal for me, I would like it, but not doing
it is obviously not preventing me from using pyramid to do some really cool
stuff on GAE, and quickly.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to thi
By that I meant, following a previous post I made, to possibly create
new comer guides, opinionated guides, etc... to fill the missing gap.
I don't think the current docs need to track down those requests, they
are not perfect but they are great.
Another point is complaint about pyramid needing mo
On Fri, 2011-03-04 at 16:38 -0500, Reed L O'Brien wrote:
> On Mar 4, 2011, at 3:42 PM, Blaise Laflamme wrote:
>
> > That said we definitely need to communicate the right message, provide
> > the right level of documentation for the targeted audience, have a
> > better way to expose tools and contr
On Fri, 2011-03-04 at 13:35 -0800, Rocky Burt wrote:
> I would be +1 on splitting this up to pyramid_chameleon and
> pyramid_mako. But that's almost certainly because I have no use for
> either of those templating languages and for my specific work they
> sort of feel like bloating pyramid core.
>
On Mar 4, 2011, at 3:42 PM, Blaise Laflamme wrote:
> That said we definitely need to communicate the right message, provide
> the right level of documentation for the targeted audience, have a
> better way to expose tools and contributions, etc...
Who is the targeted audience? Currently it seems
I would be +1 on splitting this up to pyramid_chameleon and pyramid_mako.
But that's almost certainly because I have no use for either of those
templating languages and for my specific work they sort of feel like
bloating pyramid core.
That being said, their presence doesn't cause any real pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2011 03:36 PM, Blake Hyde wrote:
> On Fri, Mar 4, 2011 at 3:25 PM, Mike Orr wrote:
>> On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde wrote:
>>> On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote:
I have a friend who is a marketer and supports
On 3/4/11 12:03 PM, Mike Orr wrote:
I'll be at the Pyramid sprint but I don't know what I'll be doing.
I would like to learn Git and Pyramid-at-Github if somebody would like
to do a mini crash course.
I'm no git guru, but I've been using it pretty heavily for the last 6
months and would be ha
Well... same for me, I got a lot of clients work to complete and I've
done my best trying to put everything in place to have something
cohesive. I also got help from multiple people for different tasks and
I'm grateful for every contribution.
That said we definitely need to communicate the right m
On Fri, Mar 4, 2011 at 3:25 PM, Mike Orr wrote:
> On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde wrote:
>> On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote:
>>> I have a friend who is a marketer and supports the Pylons Project, but
>>> he's kind of gotten burned out on Python as a whole for various
>
On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde wrote:
> On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote:
>> I have a friend who is a marketer and supports the Pylons Project, but
>> he's kind of gotten burned out on Python as a whole for various
>> reasons so he can't quite be a full marketing adviso
On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote:
> I have a friend who is a marketer and supports the Pylons Project, but
> he's kind of gotten burned out on Python as a whole for various
> reasons so he can't quite be a full marketing advisor. Is there anyone
> else with marketing-type experience
I'll be at the Pyramid sprint but I don't know what I'll be doing.
I would like to learn Git and Pyramid-at-Github if somebody would like
to do a mini crash course.
On Fri, Mar 4, 2011 at 11:38 AM, Blaise Laflamme wrote:
> I'm up too
>
> On Mar 3, 8:09 pm, Carlos de la Guardia
> wrote:
>> Guys,
On Fri, 2011-03-04 at 12:00 -0800, Mike Orr wrote:
> On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis wrote:
> >>I mentioned "unless there are new magical docs", because I think 99%
> >> of the problems with pyramid right now are the docs. They're hard to
> >> sift through (rather dense) and easy to
On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis wrote:
>>I mentioned "unless there are new magical docs", because I think 99%
>> of the problems with pyramid right now are the docs. They're hard to
>> sift through (rather dense) and easy to miss things in. Meanwhile,
>> docs for projects like Djan
On Fri, Mar 4, 2011 at 12:11 AM, mjmein wrote:
> One also just needs to define what the ultimate goal is:
>
> Is it to compete with Django/Rails? In that case I agree that alot of
> work needs
> to be done on simplifying and removing options. The power of Django/
> Rails are that
> they provide on
Could you put this in the Pyramid issue tracker?
On Fri, 2011-03-04 at 14:28 -0500, Daniel Holth wrote:
> My wishlist for the manual:
>
> 1. searching for request.response_headers should pull up
> request.response_headerlist
> 2. glossary for 'Configurator' etc. should link to function signatures
I'm up too
On Mar 3, 8:09 pm, Carlos de la Guardia
wrote:
> Guys,
>
> I'll be at PyCon and would like to sprint on this. Maybe a tutorial
> with code. Anyone?
>
> Carlos de la Guardia
>
>
>
> On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough wrote:
> > On Thu, 2011-03-03 at 17:57 -0600, Joe Dallag
My wishlist for the manual:
1. searching for request.response_headers should pull up
request.response_headerlist
2. glossary for 'Configurator' etc. should link to function signatures
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to t
On Fri, Mar 4, 2011 at 9:39 AM, Chris McDonough wrote:
> Of these, the only ones to very easily *not* install would be Mako,
> Chameleon, PasteScript, Paste, and PasteDeploy. The others are core
> dependencies that really can't very easily be externalized.
>
> Doing that would take us down to 13
On Fri, Mar 4, 2011 at 12:11 AM, Chris McDonough wrote:
> So we should reorganize by moving chapters of the documentation around?
Maybe if we just rename the Pyramid manual to the Pyramid Reference
Manual it will set readers' expectations appropriately. I'm not sure
if there's anything that needs
I'm not really complaining as deploying with all the dependencies to ae is a
one time config thing for now. Just putting my "+" in there as i think it
would be nice to deploy with the bare minimum when you are deploying to
environments that have hard limits on things like file count and startup
Pasta is delicious. Choice is here to stay.
I think frustrated people tend to overestimate the cost of reading a
600-page book (the documentation) or installing 17 dependencies
(automatically). It will pay off to understand the tools you are using over
the lifetime of a significant application;
Sorry to jump in here at the end, but just wanted to put a word in.
The extra dependencies are due to the fact that pyramid integrates a lot of
other very good packages. This IS a GOOD thing, not bad. It makes pyramid
better and those other packages better because there are more "stakeholders"
in
On Mar 4, 2011, at 12:39 PM, Chris McDonough wrote:
> On Fri, 2011-03-04 at 04:43 -0800, Andrey Petrov wrote:
>> Re: Excessive dependencies.
>
>
> Of these, the only ones to very easily *not* install would be Mako,
> Chameleon, PasteScript, Paste, and PasteDeploy. The others are core
> dependen
On Fri, 2011-03-04 at 04:43 -0800, Andrey Petrov wrote:
> Re: Excessive dependencies.
>
>
> Right now when you 'pip install pyramid' on a fresh environment, you
> get 18 packages installed:
>
>
> Chameleon, Mako, MarkupSafe, Paste, PasteDeploy, PasteScript, WebOb,
> pyramid, repoze.lru, transla
For the record, Bottle takes this tact. It's full feature set actually
depends on many, many packages (many more than Pyramid does). But it
ships as a single file with no dependencies.
I'm not a huge fan of this. Maybe it's a successful marketing gimmick
but it doesn't actually reduce any compl
that's not a bad idea. I'm using pyramid on app engine, and don't need
chameleon, but if I don't push chameleon up to the cloud the app fails to
load last time I tried it.
of course defining the bare minimum would probably be a challenge. :)
--
You received this message because you are subscr
On Thu, 2011-03-03 at 19:09 -0600, Carlos de la Guardia wrote:
> Guys,
>
> I'll be at PyCon and would like to sprint on this. Maybe a tutorial
> with code. Anyone?
I'd be up for that, although I'm also slated to help port WebOb to Py3k.
>
> Carlos de la Guardia
>
> On Thu, Mar 3, 2011 at 6:08
Guys,
I'll be at PyCon and would like to sprint on this. Maybe a tutorial
with code. Anyone?
Carlos de la Guardia
On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough wrote:
> On Thu, 2011-03-03 at 17:57 -0600, Joe Dallago wrote:
>> So the thing we can carry away from this discussion is that we shou
The tyranny of choice study gets thrown around a lot, but when there
are familiar options it's less of a problem.
And there's the opposite problem, not enough choices also presents
problems. I can't find the study, but notice all the different kinds
of spaghetti sauce in the isle at the supermar
Psychologists have done a significant amount of research documenting the
"tyranny of choice" and famously served samples of exotic jams "when choice
is demotivating" (
http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf). At
least for jam, 6 choices is OK, while 30 choices are demoti
I think the problem lies in the fact people think pyramid provides
rails and it's actually not the case. Not that pyramid should not
provide higher level tools but at this stage it's not pyramid goal. I
also think pyramid should be used for multiple higher level frameworks
with their own opinions,
Re: Excessive dependencies.
Right now when you 'pip install pyramid' on a fresh environment, you get 18
packages installed:
Chameleon, Mako, MarkupSafe, Paste, PasteDeploy, PasteScript, WebOb,
pyramid, repoze.lru, translationstring, venusian, zope.component,
zope.configuration, zope.deprecatio
Am 04.03.2011 09:11 schrieb mjmein:
In my mind we still need something that works on Django level, with
more constraints imposed, but I am expecting that the new version of
TurboGears based on Pyramid would address that.
That's also my understanding.
Our experience with the TG project is also
One also just needs to define what the ultimate goal is:
Is it to compete with Django/Rails? In that case I agree that alot of
work needs
to be done on simplifying and removing options. The power of Django/
Rails are that
they provide one way of doing things that works in the most cases. The
probl
On Thu, 2011-03-03 at 23:42 -0800, Peter Alexis wrote:
> >I mentioned "unless there are new magical docs", because I think 99%
> > of the problems with pyramid right now are the docs. They're hard to
> > sift through (rather dense) and easy to miss things in. Meanwhile,
> > docs for projects like
>I mentioned "unless there are new magical docs", because I think 99%
> of the problems with pyramid right now are the docs. They're hard to
> sift through (rather dense) and easy to miss things in. Meanwhile,
> docs for projects like Django and Rails are really light and breezy...
> and link to
I think the criticisms in the post -- and their defense here -- are
really important. I've had the same struggles.
While many are not technically valid , they appear to be so because of
the documentation and positioning of pyramid.
Pyramid is really powerful framework, but its also quite low-lev
On Thu, Mar 3, 2011 at 23:27, Mike Orr wrote:
> It's absolutely a legitimate point, and it's what I've been concerned
> about for the past several months. It's why I'm writing the Pyramid
> Migration Guide and Akhet (the successor to pyramid_sqla) -- both to
> be released hopefully by PyCon.
Hi
Hi :)
Well, I'm pretty sure that the pylonsproject ecosystem would love to
have more and more people who identifies with the ideas of the
project.
I mean, it doesn't need to be a 100% match, but there's have to have some.
Seriously, just because you didn't feel at home it doesn't mean you
can sta
On Thu, 2011-03-03 at 17:57 -0600, Joe Dallago wrote:
> So the thing we can carry away from this discussion is that we should
> improve Pyramid's "new user" experience, with tutorials and perhaps
> some defaults for basic functionality.
"We hold these truths to be self evident..."
- C
>
> On T
So the thing we can carry away from this discussion is that we should
improve Pyramid's "new user" experience, with tutorials and perhaps
some defaults for basic functionality.
On Thu, Mar 3, 2011 at 4:27 PM, Mike Orr wrote:
> On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com
> wrote:
>> I'm
On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com
wrote:
> I'm not sure the OP is trolling, it comes across as frustration.
It's absolutely a legitimate point, and it's what I've been concerned
about for the past several months. It's why I'm writing the Pyramid
Migration Guide and Akhet (the
On 3/3/11 10:59 AM, Stephen Lacy wrote:
Yeah, but encapsulation (a well-written API) and dependencies are
totally orthogonal.
One could write a dependency-less framework that provided sensible,
minimal, yet functional components, and *still* provided a really clean
API and way for developers to
On Thu, 2011-03-03 at 10:59 -0800, Stephen Lacy wrote:
> Yeah, but encapsulation (a well-written API) and dependencies are
> totally orthogonal.
>
> One could write a dependency-less framework that provided sensible,
> minimal, yet functional components, and *still* provided a really
> clean API
On Thu, 2011-03-03 at 18:22 +, danjac...@gmail.com wrote:
> I'm not sure the OP is trolling, it comes across as frustration. While
> some of the things he points out are unfair and suggest unfamiliarity
> with certain aspects of the framework, there are some valid points in
> here as well:
>
>
Yeah, but encapsulation (a well-written API) and dependencies are totally
orthogonal.
One could write a dependency-less framework that provided sensible, minimal,
yet functional components, and *still* provided a really clean API and way
for developers to hook in external implementations.
Lines l
Essentially what I am giving is a real world example of the concept of
encapsulation, which is something that every programmer should value.*
On Thu, Mar 3, 2011 at 12:43 PM, Joe Dallago wrote:
> I just thought that I would chime in and say that the
> "dependency-heavy" model that Pyramid uses is
I just thought that I would chime in and say that the
"dependency-heavy" model that Pyramid uses is not a new one. Look at
Linux, arguably the largest open source project in existence right
now, it is hard to find a package that doesn't have 10 dependencies.
Linux does this b/c it is efficient, an
On Thu, 2011-03-03 at 09:39 -0800, Stephen Lacy wrote:
> Okay, chiming in here. :) Yeah, this is my post. I've been pretty
> quiet here.
>
> Sorry for the somewhat negative tone, as you can imagine, the post was
> written after spending several hours digging through a very large
> amount of th
I'm not sure the OP is trolling, it comes across as frustration. While
some of the things he points out are unfair and suggest unfamiliarity
with certain aspects of the framework, there are some valid points in
here as well:
1. The usage of traversal vs dispatch. It's unclear even to those
quite f
On Thu, 2011-03-03 at 09:31 -0800, Ben Bangert wrote:
> On Mar 3, 2011, at 9:28 AM, Chris McDonough wrote:
>
> > Sounds like (s)he is blowing off a little steam. All of these points
> > are addressed in
> > http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html .
>
> Indeed, my co
Okay, chiming in here. :) Yeah, this is my post. I've been pretty quiet
here.
Sorry for the somewhat negative tone, as you can imagine, the post was
written after spending several hours digging through a very large amount of
the Pyramid source code trying to figure out the answer to what seemed
On Mar 3, 2011, at 9:28 AM, Chris McDonough wrote:
> Sounds like (s)he is blowing off a little steam. All of these points
> are addressed in
> http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html .
Indeed, my comment is awaiting moderation on the blog, I cited that URL as
well.
I suggest to rename this thread "Some trolls about Pyramid"
--
Gael
On Thu, Mar 3, 2011 at 6:54 AM, Peter Alexis wrote:
> Just happened to see a blog about Pyramid,
>
> http://slacy.com/blog/2011/02/why-im-unhappy-with-the-pyramid-web-framework/
>
> --
> You received this message because you are
On Thu, 2011-03-03 at 03:54 -0800, Peter Alexis wrote:
> Just happened to see a blog about Pyramid,
>
> http://slacy.com/blog/2011/02/why-im-unhappy-with-the-pyramid-web-framework/
Sounds like (s)he is blowing off a little steam. All of these points
are addressed in
http://docs.pylonsproject.org
Just happened to see a blog about Pyramid,
http://slacy.com/blog/2011/02/why-im-unhappy-with-the-pyramid-web-framework/
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsub
61 matches
Mail list logo
