Re: Importing all SQLAlchemy Models (question about the Cookbook article)
I think you'll need to supply some code for us to see what is wrong. On Mon, Nov 28, 2011 at 6:10 PM, Ryan ryan.mckil...@gmail.com wrote: http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/sqla.html I'm trying to follow the instructions under the Importing all SQLAlchemy Models heading. As ridiculous as this sounds, I got it working immeadiately (when I started my app in a pshell, 'model' was available in the global namespace), then shuffled around some of the lines in my __init__.py's main() function and haven't been able to get it working again. Anyone else had success/failure with this approach? Any example code/apps beyond what's in the cookbook? -- You received this message because you are subscribed to the Google Groups pylons-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-devel/-/x7uxH6uh-FcJ. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid for Humans tutorial at Plone Conf...any reviewers?
I don't know how much constructive criticism I will be able to contribute, but I would like to read it. On Wed, Oct 26, 2011 at 9:01 AM, Blaise Laflamme bla...@laflamme.orgwrote: Hi paul, I'm also interested in reading your material. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-devel/-/nTdKfhKKHdIJ. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: How to run the paste server process as a daemon?
paste serve development.ini --daemon. You can also see its other options by typing paster serve development.ini --help. On Mon, Oct 24, 2011 at 3:02 PM, Raviteja Dodda raviteja2...@gmail.comwrote: Hi, How to run the paste server process as a daemon? -Ravi -- You received this message because you are subscribed to the Google Groups pylons-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-devel/-/Zb3qdkNEwygJ. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: How to run the paste server process as a daemon?
Yah, the correct way to do that is 'paster serve development.ini --reload --daemon'. If your developing, you probably don't want to run it as a daemon, as you won't be able to see the output of the server, and if you are running it in production, you probably wouldn't want the server to reload each time the code changes(b/c realistically it shouldn't). So I would recommend using each of those two flags separate of one another. On Mon, Oct 24, 2011 at 3:06 PM, ravi teja raviteja2...@gmail.com wrote: I used to do like this: paster serve development.ini --reload I wanted to know if there is another way On 25-Oct-2011, at 1:34 AM, Joe Dallago wrote: paster* serve On Mon, Oct 24, 2011 at 3:04 PM, Joe Dallago jd.dall...@gmail.com wrote: paste serve development.ini --daemon. You can also see its other options by typing paster serve development.ini --help. On Mon, Oct 24, 2011 at 3:02 PM, Raviteja Dodda raviteja2...@gmail.comwrote: Hi, How to run the paste server process as a daemon? -Ravi -- You received this message because you are subscribed to the Google Groups pylons-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-devel/-/Zb3qdkNEwygJ. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: How to run the paste server process as a daemon?
Yah supervisor is a better option for production. On Mon, Oct 24, 2011 at 3:21 PM, Joe Dallago jd.dall...@gmail.com wrote: Yah, the correct way to do that is 'paster serve development.ini --reload --daemon'. If your developing, you probably don't want to run it as a daemon, as you won't be able to see the output of the server, and if you are running it in production, you probably wouldn't want the server to reload each time the code changes(b/c realistically it shouldn't). So I would recommend using each of those two flags separate of one another. On Mon, Oct 24, 2011 at 3:06 PM, ravi teja raviteja2...@gmail.com wrote: I used to do like this: paster serve development.ini --reload I wanted to know if there is another way On 25-Oct-2011, at 1:34 AM, Joe Dallago wrote: paster* serve On Mon, Oct 24, 2011 at 3:04 PM, Joe Dallago jd.dall...@gmail.comwrote: paste serve development.ini --daemon. You can also see its other options by typing paster serve development.ini --help. On Mon, Oct 24, 2011 at 3:02 PM, Raviteja Dodda raviteja2...@gmail.comwrote: Hi, How to run the paste server process as a daemon? -Ravi -- You received this message because you are subscribed to the Google Groups pylons-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-devel/-/Zb3qdkNEwygJ. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: [Pyramid] How to do testing _with_ sqlalchemy?
I would have to agree with Carsten, that I think the problem lies with the
DBSession object. If you are simply creating your session with
sessionmaker(), it will return a new session each time. Try using
scoped_session()http://www.sqlalchemy.org/docs/orm/session.html#sqlalchemy.orm.scoped_sessionand
see if that fixes your problems immediately. Here is another example
of
a good way of doing handler/view testing
https://github.com/jayd3e/StudentUnderground/blob/master/studentunderground/tests/test_handlers.py.
In my example I completely abstract the process of setting up a database
into an initialize_db() function that takes an engine as an argument. That
way you tests and your actual application can use the same machinery in
order to setup an identical Session object. This is how a lot of people
around here do it, and it works out really nicely.
On Mon, Jul 25, 2011 at 5:17 AM, Carsten Senger sen...@rehfisch.de wrote:
--On Donnerstag, Juli 21, 2011 05:50:12 -0700 Whitiz schugsc...@gmail.com
wrote:
import unittest
from pyramid.config import Configurator
from pyramid import testing
from tutorial.models import MyModel, DBSession, Base
import transaction
def _initTestingDB():
print initTestingDB
from sqlalchemy import create_engine
engine = create_engine('sqlite://')
DBSession.configure(bind=**engine)
Base.metadata.bind = engine
Base.metadata.drop_all(engine)
Base.metadata.create_all(**engine)
create_models(DBSession)
return DBSession
Here you return DBSession, which may be a sessionmaker object.
def create_models(dbSession):
session = dbSession()
model = MyModel(name=u'root', value=55)
session.add(model)
session.flush()
transaction.commit()
There you create a new 'session' object from your DBSession
factory. But _initTestingDB() returns the DBSession object, not
this 'session' object.
def clear_models(dbSession):
session = dbSession()
old_object = session.query(MyModel)
session.delete(old_object)
session.flush()
transaction.commit()
print clear_models
The transaction is probably the transaction used by repoze.tm[2]. Not sure
how that works in tests.
class TestMyView(unittest.TestCase):
def setUp(self):
self.config = testing.setUp()
self.dbSession=_initTestingDB(**)
def tearDown(self):
testing.tearDown()
clear_models(self.dbSession)
print rollback
self.dbSession.rollback()
As said self.dbSession is not the session you used in create_models().
Sqlalchemy has a neat receipt how to set up an extra session to roll back
to
in tests: http://www.sqlalchemy.org/**docs/orm/session.html#joining-**
a-session-into-an-external-**transactionhttp://www.sqlalchemy.org/docs/orm/session.html#joining-a-session-into-an-external-transaction
In a project where I implemented that pattern I had to replace the scoped
session with
a normal session to make it work:
https://bitbucket.org/liqd/**adhocracy/src/93d614ae2fb5/**
adhocracy/tests/__init__.pyhttps://bitbucket.org/liqd/adhocracy/src/93d614ae2fb5/adhocracy/tests/__init__.py
..Carsten
--
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 unsubscribe from this group, send email to pylons-devel+unsubscribe@**
googlegroups.com pylons-devel%2bunsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/**
group/pylons-devel?hl=enhttp://groups.google.com/group/pylons-devel?hl=en
.
--
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 unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Adding abort and redirect to Pyramid
Haven't read this whole thread. I just wanted to say that although I personally will continue to use the old style of http.exceptions, I think this addition will help people coming from other frameworks, as the redirect and abort keywords are commonplace for such methods on other frameworks. On Thu, May 26, 2011 at 1:08 PM, Mike Orr sluggos...@gmail.com wrote: On Thu, May 26, 2011 at 6:15 AM, Daniel Holth dho...@gmail.com wrote: 'return' makes sense because views return a response. Whether the response has an error code of 200, 301 or 5xx is a separate concern. Of course exceptions make sense too. This only became an issue because HTTPException happens to be a WSGi application so it looks like a view return value. It would have been better if it were just an Exception subclass so there would be no question they should be raised and caught. In fact, I'm not even sure the body and headers of the HTTPException should be honored; it's really the job of the framework to decide how to display HTTP errors (possibly using a plugin such as an error-view to customize it). in Pylons, if the StatusCodeRedirect middleware is active, it makes a subrequest. If it's not active, something in Pylons or Paste generates a plain error message including the title, description, and (in debug mode) the exception's 'message' argument. It's certainly not the responsibility of the code that discovers an inconsistency necessitating a 4xx or 5xx error to style it: the error is rarely the main purpose of the function; it's just something the function wants to get rid of as quickly as possible. If the view really wants to RETURN a 4xx or 5xx condition, it can set 'request.response_status_int' the normal way rather than invoking HTTPException. Or it can instantiate the exception and pass it to an application-making function that would turn it into a WSGI application (something like the HTTPException constructor), and return that. -- Mike Orr sluggos...@gmail.com -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
hallo
there is a pill http://ennevia.com/sales.htm -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: GSoC, Python 3 dependencies, Paste
I also plan on helping port Pyramid to Python 3 as my GSOC project. You can check out my application on my blog(jayd3e.com) for more details. As far as Paste goes, it has unofficially been decided that we will be going with an entirely separate HTTP server, as opposed to isolating 'paster serve'. I know a few people are in favor of using a wsgi server called WiseGuy( https://github.com/wsgicabal/wiseguy), there a variety of others as well though. 'Paster create' is currently being isolated by someone afaik, forget who. I personally think that you should choose to port Pyramid as your project, because we could always use more help for that effort. On Apr 4, 2011 11:19 AM, Juliusz Gonera jgon...@gmail.com wrote: Hi, I thought that it will be easier if I just post here instead of trying to catch someone on IRC. I have quite a few questions regarding GSoC. First of all, I'm not quite sure if I should propose the specific project or it should be given to me by one of the mentors. I was thinking about porting the necessary packages to Python 3, but I guess it could be too much for a single project (or maybe not?). Because of that I though about concentrating on Paste issue. I don't know if any decision has been made (whether to update Paste, rewrite create and serve or use something else, e.g. Marrow) and I'm almost sure I'm not the one to make such decisions. However, I have to put something more detailed in the application form. Regarding Paste and comments on https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm: 1. YAML vs INI - is there any decision? 2. Is marrow.script not being argparse-compatible a big issue? Wouldn't it be easy to fix? 3. The same goes for marrow.server.http being asynchronous. As long as it was multithreaded too I don't know how this could be a problem (but maybe I don't know enough). And according to the readme on github ( https://github.com/marrow/marrow.server.http), multi-threading is on the todo list: threaded — Enable multi-threading. This is currently unimplemented pending support up-stream in marrow.server and defaults to False. 4. I'm uncomfortable with the direction of these libs personally. They seem to be more researchy than practical in lots of cases. Could somebody elaborate? I'm not trying to question anything, I don't know that much, I would just like to know what is wrong with Marrow. 5. If adapting and improving Marrow is not an option, then what should I do if I want to work on porting Pyramid to Python 3? On IRC Blaise Laflamme suggested CherryPy. What do you think? I thought that this is more development related so I'm posting to devel. Let me know if I was wrong. Regards, -- Juliusz Gonera http://juliuszgonera.com/ -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Terminology Change - Template to Skeleton
Haha Daniel, I honestly didn't realize this would become such a big topic of conversation, seeing as it isn't really that important of an issue. I just wanted to make sure that there was some distinction between the two entities in the docs, b/c I remember this being an issue as a beginner. It became even more of a problem, when I went to IRC to ask questions, and confusion arrose over which 'template' I was talking about. I think 'scaffold' is the term that has been collectively accepted by the web development community, so I plan on using that. On Mon, Mar 21, 2011 at 9:38 PM, Daniel Holth dho...@gmail.com wrote: Joe, I enjoy posting to mailing lists but as far as I'm concerned you may change the name of things without asking in the future. I have already read the docs and would probably never notice. Daniel -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Terminology Change - Template to Skeleton
This issue has been previously discussed, I just wanted to make sure that everyone agrees. At the moment the docs refer to paster templates and renderered templates(mako, chameleon, jinja) using the same name. I propose that we change the official nomenclature used to describe paster templates to skeleton, and leave the word template to describe rendered templates. Any objections? I will start going through the docs as soon as I get the ok from everyone. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: GSOC status
A paste wishlist would be great. I talked to a GSOC representative at PyCon, and it seems that the Pylons Project has not yet registered as a mentoring organization, just fyi. On Thu, Mar 17, 2011 at 2:36 PM, Mike Orr sluggos...@gmail.com wrote: No objections, although it's too early to commit to specific GSOC project yet. I was going to say that somebody just announced a project to revamp PasteScript/PasteDeploy, but it looks like that somebody is you. So maybe some of that could come under GSOC. BTW, I'm going to post a wishlist of features for paster create and application templates. First Chris has to register Pylons as a subproject of Python's GSOC, I'm not sure if that's been done yet. Then here's the timeline: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/timeline So prospective students discuss projects with mentoring organizations until March 27, then students apply March 28-April 8, and then mentoring organizations review the proposals until April 22. On Thu, Mar 17, 2011 at 10:50 AM, Joe Dallago jd.dall...@gmail.com wrote: I too would like to participate in GSOC. I have spoken to Whit Morris, and he has has agreed to sponsor me. I was thinking that re-factoring Paste(serve and create) could be my project. Any objections? -- Mike Orr sluggos...@gmail.com -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: New project . Pylons or Pyramid
begin* On Fri, Mar 4, 2011 at 11:07 AM, Joe Dallago jd.dall...@gmail.com wrote: Go with Pyramid. You have to think about your application 2-3 years down the road. You might be fine writing it in Pylons now, but as people start to convert, support will being to dwindle. On Thu, Mar 3, 2011 at 9:10 PM, Ravi ravi.gidw...@gmail.com wrote: Hi Group: I have started a new web based project and it is in its early stage. So with pylons merging with pyramids, I have two questions: 1) do you all suggest starting with Pyramids ? Or shall I wait for some more months ? 2) Are there any DO/DON'T that I should follow for make sure I have easy migration from pylons 1.0 to pyramid. -- About my web application: 1) Web based application. 2) Currently using Jinja2 template engine. 3) Will use session, cache. 4) Most of the data will be fetched using a REST based APIs which are not part of this application. 5) Will need to support a user base of atleast 100,000 users. 6) Will have usual registration/profile kind of forms and validations and may be few more forms. -- I have already seen the pylons FAQ ( http://docs.pylonsproject.org/faq/pyramid.html#should-i-port-my-pylons-1-0-project-to-pyramid), but will like hear from you all. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
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 jd.dall...@gmail.com wrote: 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, and it means that code doesn't have to be duplicated. It is also important to note that it is also the model that Python excels at(easy imports, packages and module organization is easy, etc.). The dependency-heavy model actually makes learning more efficient in the long term as well, b/c if one module fails, then you don't have to ditch the whole system. For example(this example is somewhat from my experience with the cakephp framework), lets say you reach a point in an application where the framework itself is limiting your progress. Let's say that you need row-level permissions and the default auth helper doesn't do this. If the entire framework is tied together, then you would have to deal with either having to manipulate some of the source code(which could possibly be changed in future updates) or scrap the whole thing. With Pyramid, a failure in a specific module simply means you ditch that ONE module and sub in another. It is also important to note that if Pyramid itself becomes obsolete in 5-10 years, as Pylons did, then at least you can carry over your knowledge of SQLAlchemy, paster, deform, etc. to the next framework. Essentially what I giving a world world example of the concept of encapsulation, that is something that every programmer should value. On Thu, Mar 3, 2011 at 12:24 PM, Chris McDonough chr...@plope.com wrote: 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 the Pyramid source code trying to figure out the answer to what seemed to be a very simple question. Yes, I could have asked here, or on #pylons, and maybe I should have. But, at the same time, I think that read and understand the source is an important aspect of a good framework, and that's what I was most frustrated about. We've all been there, no worries. - C -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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 unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
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 sluggos...@gmail.com wrote: On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com 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 successor to pyramid_sqla) -- both to be released hopefully by PyCon. Stephan comes from a new user's perspective with a Django background. As such, there will be more users like this, and if we can give them specific documentation and examples addressing their concerns, it will help the works-out-of-the-box issue. If we want to attract new users, we must do this. That doesn't mean the Pyramid core developers have to do all the work. It's a great opportunity for add-on products made by others with more time on their hands. The Pyramid manual is essentially a reference guide, so it documents all the alternatives in detail. That's necessary, but it's not the same as a tutorial. And people have such different backgrounds that several focused tutorials would be better than one. I'm writing a migration guide for Pylons users. Stephan's post makes me think a migration guide for Django users would be helpful. I don't know enough about Django to write this myself. Obviously we can't write guides for every single framework, but Pylons covers a variety of WSGI developers who know something about Pylons, and Django covers another large set that's unique enough to require its own guide. Zope/BFG people seem to find the Pyramid manual sufficient, so that's covered. The answers to Stephan's concerns fall into roughly three categories: - Intentional design decisions; i.e., goals for Pyramid. - Tradeoffs we had to make given those decisions. - The historical legacy of BFG, and the desire not to break backward compatibility. Pyramid's design is heavily shaped by things that Pylons/TurboGears didn't have and their developers wanted. BFG did have these so we took them, and along came everything else BFG had. Things that Pylons specifically wanted were: events, a complete reference manual, eliminating the magic globals [1], better unit testing (which views-returning-a-dict provides), interfaces, a larger developer-base, and maybe other things I'm forgetting. Traversal, ZODB, and built-in auth that's simpler than repoze.who/what were minor desires that essentially came for free. [1] Pyramid threadlocals are similar to Pylons magic globals, but the rest of the framework has been designed not to require them (the threadlocals). The BFG developers make a compelling case that traversal and interfaces are useful, especially for certain kinds of applications. That having these available is a good thing, even for those who don't use them, because it provides a migration path to use them later if they become important someday. Traversal is particularly suited to CMS sites where editor-users can attach a page to any URL, arbitrarily nested. Routes doesn't do this; Routes depends on path variables being in fixed URL positions. Interfaces I only understand superficially, but I have a gut feeling they will be more widely used as more people get comfortable with them. Previously interfaces were available only in Zope and BFG. Zope is a very specialized environment, BFG somewhat less so, but Pyramid makes interfaces accessible to the masses (i.e., general Python-web developers). Pyramid and WebHelpers have borrowed some features from Django, but certain aspects of Django are decidedly non-features in Pyramid/Pylons/TurboGears, and have been for five years. The Pylons Project believes in using third-party packages whenever feasable, and in spinning off packages that can be used outside the frameworks. Of course there are disadvantages to this as well as advantages. If a third-party library becomes unmaintained or has version skew (i.e., its latest version has incompatible changes), it adversely affects the framework until we reconcile the two or switch to another library. Likewise, sometimes the framework needs to switch to a better library, and users have to adjust their applications. But overall we're glad that users and framework developers can switch libraries as they see fit, and that we can use the latest gee-whiz library as soon as it's available. The other main non-feature of Django is the tight binding between the ORM and the rest of the framework. That may work well for some Django applications, but it's just not something the Pylons Project believes in. The complexity of the Pyramid source is another issue. You're right that interfaces make the source more complex, and it's especially
