Re: [pylons-devel] Re: wsgi server of choice?

[Chris Rossi]

I use nginx+waitress in production.  Except once in a blue moon I've used
gunicorn for something with long persistent connections.  (Streaming music
server, anything that uses socket.io, etc...)

Chris

On Tue, Sep 29, 2015 at 9:35 AM, Bastian Kuberek  wrote:

> Like others, I do also deploy production using Nginx and uWSGI. For
> development I use just waitress or uWSGI, depending on the project and how
> much infrastructure has been built.
>
>
> On Thursday, September 24, 2015 at 12:25:14 PM UTC-4, Chris Withers wrote:
>>
>> Hi All,
>>
>> What's the recommended wsgi server for Pyramid apps nowadays?
>>
>> My go-to would normally be mod_wsgi, but I'm having a hard time getting
>> my head around using that with an environment set up with environment
>> modules .
>>
>> That modules system is causing me plenty of other headaches (IDE
>> integration, etc), but it is what I have to work with, so interested in any
>> recommendations for a wsgi server that would work with that type of
>> environment...
>>
>> cheers,
>>
>> Chris
>>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] limone status

[Chris Rossi]

I had not seen schematics before.  The information on the pypi page does
look promising.  And active is good.  The only reason you might consider
limone at this point, I would think, is if you want to continue using your
Colander schemas instead of writing new schematics models.  Conversion is
probably not too hard, though.

Chris

On Tue, Sep 30, 2014 at 8:59 AM, Guillaume Gauvrit 
wrote:

> Hi,
> thanks for your answer.
>
> I use Colander for a rest api (using Cornice) but this time
> I d'like to consume that API and I will prefer to manipulate objects
> instead of dict and simple types.
>
> I will take a look at schematics which looks like limone and may
> be more alive.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] limone status

[Chris Rossi]

It's dead in that no one is currently using or maintaining it.  It was a
fun hack, but I never really found much use for it myself.  I don't
remember super well, but I think it starts to show its rough edges with
complex schemas with many nested layers, but is really slick for simple,
shallow schemas.

It's open source and there's no reason you couldn't use it if you find it
useful.  I certainly wouldn't object to someone taking it over.

Chris


On Mon, Sep 29, 2014 at 3:49 AM, Guillaume Gauvrit 
wrote:

> Hi,
>
> I currently use colander but, for a new project, I like
> to have Python object instead of dict, the project I found
> via stackoverflow is limone.
>
> https://github.com/chrisrossi/limone
>
> It's not on the Pylon official repository, still in alpha version,
> and have not changed since 3 years. Is it a dead project,
> (I mean not maintained) ? In this case, is there an alternative ?
>
> Thanks for your advice.
>
> Guillaume
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: question about design decision on pyramid's core

[Chris Rossi]

On Wed, Mar 27, 2013 at 1:44 PM, Jonathan Vanasco wrote:

> looking at the source, I see:
>
> * pyramid/chamelon_text.py
> * pyramid/chamelon_zpt.py
> * pyramid/mako_templating.py
>
> was there any reason for these being on the top-level, and not under a
> consolidated namespace like pyramid/templating  , or did this just
> happen randomly ?
>
>
>>> import this

See 5th rule.

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What's the best way to optimize database connections in Pyramid?

[Chris Rossi]

On Mar 13, 4:54 am, Seth  wrote:
> I was advised a while back by someone to throw my MongoDB connection call
> into a pyramid.events.NewRequest subscriber. However, this has proven to be
> a bad idea because the NewRequest subscriber gets called even if the request
> is a static_route request, and since the event.request object in the
> NewRequest subscriber doesn't have a matched_route attribute, there's no
> bullet-proof way to filter those out.
>
> How are other people connecting to a db with high-traffic sites using
> Pyramid and avoiding the static_route re-connection nonsense? Perhaps we
> could request to get a matched_route object on the NewRequest event object?
>
If it were me I would attach a connection factory instead of an open
connection.  The factory would open a connection and stash it on the
request the first time it is invoked and then just return the stashed
connection on subsequent calls.  This preserves the convenience of
your pattern but allows you to only cause a connection to be opened
for requests that need it.

Chris

-- 
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 terminology: "model"->"resource"

[Chris Rossi]

Sold.  +1

Chris

On Thu, Dec 16, 2010 at 11:57 PM, Mark Ramm wrote:

> So, I will confess to being the one who asked for this change, and
> while I'm definitely open to other options, I think resource is a good
> term for items in the graph.  The graph itself I'm not sure what to
> call, but I think model is confusing because it is too easy to confuse
> with a "domain model" or ORM model.
>
> The overloading problem should be taken seriously because most folks
> coming to Pyramid from other python web frameworks, including
> TurboGears, Pylons, Django, and most of the "newish" frameworks will
> have very different ideas of how the "model" works and will
> immediately get confused.  And that's a terrible way to attract new
> users ;)
>
> But it's worse than just overloading -- I think "model" is confusing,
> as is "context" specifically because those terms aren't  descriptive
> of what's happening.
>
> The main reason behind me asking Chris about this is that I can
> imagine writing a simple explanation of the "traversal" model which
> makes sense to a variety of TG, Zope, and even Django users.
>
> It would go something like this:
>
> Pyramid dispatch is based on a two phase system.
>
> The first phase is called Resource Location, and in it we use the URL
> (Universal Resource Locator) to find a resource.  This is done by
> taking items from the path, and looking them up in a set of nested
> dictionaries called the ResourceTree.  You can think of this as
> looking up files and directories in a file system.   You just walk
> down the path elements until you get a file.  That becomes the
> "resource" that we then publish.
>
> Which, naturally brings us to the second phase which we call "Resource
> Publication" uses additional information about the request (request
> method, etc) and the resource to lookup a view callable, and call it,
> passing in the resource we just found.
>
> There are two big advantages to this:
>
> 1) Marketing wise, REST proponents would feel like this framework is a
> natural fit for them
> 2) Reduced learning curve, since folks already know what looking up
> files in a filesystem is and how that maps to URL's.
>
> There are down sides, which chris and many of you have raised, but I
> think we have to do something, because the current terminology is just
> a bit too arcane.
>
> --Mark Ramm
>
> On Thu, Dec 16, 2010 at 9:05 PM, Chris McDonough  wrote:
> > While it seems people generally agree that some change is required here,
> > it also seems there are a good number of people who don't like
> > "resource".  Here are the arguments against it:
> >
> > - we're just switching one overloaded term ("model") for another
> >  ("resource").  Zope people tend to think of static files when they
> >  think of "resource", Pylons folks already have confusion about
> >  "resource" due to map.resource and other usages.
> >
> > - Only the entire url represents a resource. Because
> >  http://example.com/foo/bar  is a valid resource does not mean that
> >  http://example.com/foo is.  Implying each segment is a resource would
> >  be confusing.
> >
> > Alternate suggestions:
> >
> > - "traversal model"
> >
> > - "node"
> >
> > - "atom"
> >
> > - "entity"
> >
> > - "location"
> >
> > - Some derivation of "sitemap"
> >
> > OTOH, none of the alternatives really seem all that attractive to me.
> >
> > The ones that have practical issues:
> >
> > - "traversal model" is awful hard to put into APIs.
> >
> > - "location".. this one is subtle.. traversal nodes
> >  don't actually need to be "locatable" for traversal,
> >  just for the APIs that construct paths and URLs from
> >  them like model_url and model_path (IOW, the concept
> >  of "location" only matters on the way "up" the graph
> >  from a deep node, not downwards during traversal..
> >  neither __name__ nor __parent__ is used during traversal
> >  itself).
> >
> > The ones I don't like because they're meaningless:
> >
> > - "atom"
> >
> > - "entity"
> >
> > - "node"
> >
> > The meaningless ones above aren't disqualified because they're
> > meaningless, though.  I would just rather have something with some sort
> > of meaning.
> >
> > This is why I'd actually still much prefer "resource" despite the chorus
> > of objections.  Here's a list of objections and responses.
> >
> > Objection
> > --
> >
> > - Only the entire url represents a resource. Because
> >  http://example.com/foo/bar  is a valid resource does not mean that
> >  http://example.com/foo is.  Implying each segment is a resource would
> >  be confusing.
> >
> > Response
> > 
> >
> > I'm not sure this is true.  Yes, a particular URL will identify a
> > representation of a particular resource.  But if you use traversal, each
> > of the nodes in the graph is a potential "resource" and can be accessed
> > potentially via some URL.  The graph node exists to be traversed via the
> > path_info portion of a URL and, if your application uses traversal,
> > because of the way travers

Re: pyramid terminology: "model"->"resource"

[Chris Rossi]

On Wed, Dec 15, 2010 at 2:38 PM, reed  wrote:

>
> I am not adverse to renaming, but I think it needs to be definitive
> and concise enough to prevent more questions from arising than it
> would solve. I don't think 'resource' meets those criteria.
>
> I tend to agree with this.  I'll try to brainstorm alternative terminology.
 If we don't come up with something better, I think model is fine.  Resource
is also fine, really, but why change to something that could also be
confusing since it is overloaded?

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To post to this group, send email to pylons-de...@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 paster template renderer globals?

[Chris Rossi]

On Thu, Nov 11, 2010 at 7:51 AM, Wichert Akkerman  wrote:

> On 11/11/10 13:48 , Chris Rossi wrote:
>
>>
>>
>> On Thu, Nov 11, 2010 at 6:40 AM, Wichert Akkerman > <mailto:wich...@wiggy.net>> wrote:
>>
>>On 11/11/10 12:38 , Wichert Akkerman wrote:
>>
>>On 11/11/10 12:05 , Mike Orr wrote:
>>
>>Since HTML is all about hyperlinks, it makes sense to give them
>>special treatment, especially if you're trying to encourage
>>people to
>>always use URL generation rather than literal URLs for
>>internal links,
>>as Pylons does.
>>
>>
>>Stick a py:with="u=request.route_url" at the top of you template
>>if you
>>want brevity?
>>
>>My standard pattern is to expose a 'tools' object to templates
>>which has
>>a number of functions such as route_url, model_url, etc. for use in
>>templates. I've never felt that having to spell >href="${tools.route_url('personal+settings')}">.. is too long
>> or
>>awkward.
>>
>>
>>Relatedly: there are two completely different ways to generate a
>>URL: model based and route based. Your suggestion to use 'url' or
>>'u' would imply a document preference for one of the two, which I do
>>not feel is warranted. As Chris said earlier in this thread both are
>>just as useful and important.
>>
>> FWIW, since we're talking about definitions that are in people's
>> projects (via Paster templates) and not in Pyramid itself, I feel like
>> the stakes are probably lower than they would seem from this discussion.
>>  Couldn't the routes style templates define 'url' and not the traversal
>> style?  Or define 'url' differently based on which style of dispatch is
>> being used?  There aren't any Paster templates for hybrid apps are there?
>>
>
> I'm afraid that will cause confusion: people will have certain expectations
> when they encounter a Pylons 2 app, and it will be odd if 'url' behaves
> differently than they expect in 50% of the applications. A related worry is
> add-ons that may expect 'url' to behave in a certain way and as a result
> only work in 50% of the Pylons 2 projects.
>
> A reusable add on really shouldn't be making assumptions about those
globals, since they are technically speaking application specific.  (If
including them in the Paster template would make it tempting to people to
rely on them in arbitrary other applications, then you have an argument for
not having any render globals defined in the template at all.)  As far as
confusing users, that may be a legitimate concern but I suspect most people
will off working on their own projects and will tend to be using just one
style of dispatch or the other.  For those who do switch around, they can
probably keep track of the context their in and set their expectations
accordingly.

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To post to this group, send email to pylons-de...@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 paster template renderer globals?

[Chris Rossi]

On Thu, Nov 11, 2010 at 6:40 AM, Wichert Akkerman  wrote:

> On 11/11/10 12:38 , Wichert Akkerman wrote:
>
>> On 11/11/10 12:05 , Mike Orr wrote:
>>
>>> Since HTML is all about hyperlinks, it makes sense to give them
>>> special treatment, especially if you're trying to encourage people to
>>> always use URL generation rather than literal URLs for internal links,
>>> as Pylons does.
>>>
>>
>> Stick a py:with="u=request.route_url" at the top of you template if you
>> want brevity?
>>
>> My standard pattern is to expose a 'tools' object to templates which has
>> a number of functions such as route_url, model_url, etc. for use in
>> templates. I've never felt that having to spell > href="${tools.route_url('personal+settings')}">.. is too long or
>> awkward.
>>
>
> Relatedly: there are two completely different ways to generate a URL: model
> based and route based. Your suggestion to use 'url' or 'u' would imply a
> document preference for one of the two, which I do not feel is warranted. As
> Chris said earlier in this thread both are just as useful and important.
>
> FWIW, since we're talking about definitions that are in people's projects
(via Paster templates) and not in Pyramid itself, I feel like the stakes are
probably lower than they would seem from this discussion.  Couldn't the
routes style templates define 'url' and not the traversal style?  Or define
'url' differently based on which style of dispatch is being used?  There
aren't any Paster templates for hybrid apps are there?

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To post to this group, send email to pylons-de...@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: Relying on __del__ for cleanup

[Chris Rossi]

On Sun, Nov 7, 2010 at 5:48 PM, Mike Orr  wrote:

> On Sun, Nov 7, 2010 at 2:11 PM, Marius Gedminas  wrote:
> > (I have to say that document surprised me -- pleasantly -- due to your
> > dedication for user support.  Python 2.4, even!)
>
> 2.4 and 2.5 combatibility will impede the switch to Python 3, as well
> as disallowing 2.6isms which has been the current version of Python
> for over a year. Since Pyramid is  new framework, it should start at
> Python 2.6. There can be one bridge version for existing BFG
> applications.
>
> +1

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To post to this group, send email to pylons-de...@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.