Re: [pylons-devel] Setting translogger format via ini

[Mike Orr]

Here's the code. You can see it's short and simple; half the code is
just to make it more configurable. Usage:

pyramid_includes = accesslog

# Settings, all optional
access.format = {response.status_int} {request.method} {request.path_qs}
access.ignore =  /fanstatic /_debug_toolbar
access.ignore_usual = true



On Thu, Mar 10, 2016 at 6:46 PM, Mike Orr <sluggos...@gmail.com> wrote:
> On Thu, Mar 10, 2016 at 3:32 AM, Zsolt Ero <zsolt@gmail.com> wrote:
>> Hi,
>>
>> My first mailing list post, as this really puzzles me. I'd like to use a
>> short format for displaying HTTP requests in development mode.
>>
>> Before, I used to have this snippet in my Pyramid app's __init__.py:
>>
>> from paste.translogger import TransLogger
>> format = '%(status)s %(REQUEST_METHOD)s %(REQUEST_URI)s'
>> app = TransLogger(app, format=format)
>> return app
>>
>>
>> I'd like to turn this into using an .ini file, however, I cannot specify the
>> format, as the .ini file syntax needs some kind of escaping, which I cannot
>> figure out.
>>
>> Here is a try on setting translogger format via .ini file:
>>
>> [filter:translogger]
>> use = egg:Paste#translogger
>> setup_console_handler = False
>> format = %%(status)s %%(REQUEST_METHOD)s %%(REQUEST_URI)s
>>
>>
>>
>> It results in an error:
>>
>> ConfigParser.InterpolationMissingOptionError: Error in file
>> .../development.ini: Bad value substitution:
>>  section: [filter:translogger]
>>  option : format
>>  key : status
>>  rawval : %%(status)s
>>
>>
>> What is the right escaping method to set translogger's format via .ini file?
>>
>> Or if it's not possible to escape it, then I don't get it. Why does
>> translogger has a format option, if you cannot actually enter anything there
>> via ini?
>>
>> Alembic, for example supports escaping perfectly fine, for example:
>>
>> file_template =
>> %%(year)d_%%(month).2d_%%(day).2d_%%(hour).2d_%%(minute).2d_%%(second).2d_%%(rev)s
>>
>>
>> Here is this 4 year old issue in PasteDeploy, I think it's related:
>>
>> https://bitbucket.org/ianb/pastedeploy/issues/11/there-is-no-way-to-escape-character-in-the
>>
>> Any ideas how to solve this?
>
> I didn't like using middleware so I made a Pyramid tween that logs
> requests. I don't have the code with me but I can get it tomorrow.
> After calling the applicaiton I make a log message based on the
> response and request. I probably bypassed the % parsing problem by
> using str.format instead, so that I could override the format. My
> logger is called 'access'.
>
>
> --
> Mike Orr <sluggos...@gmail.com>



-- 
Mike Orr <sluggos...@gmail.com>

-- 
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 https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.
import logging

from pyramid.settings import asbool, aslist

FORMAT = "{response.status_int} {request.method} {request.path_qs}"
IGNORE_USUAL = [
"/_debug_toolbar",
"/favicon.ico",
"/robots.txt",
"/static",
"/w3c",
]

def includeme(config):
settings = config.registry.settings
if asbool(settings.get("access.enabled", True)):
config.add_tween("accesslog.accesslog_tween_factory")

def accesslog_tween_factory(handler, registry):
settings = registry.settings
log = logging.getLogger("access")
fmt = settings.get("access.format", FORMAT)
ignore = aslist(settings.get("access.ignore", []))
if asbool(settings.get("access.ignore_usual", True)):
ignore.extend(IGNORE_USUAL)
log.debug("Enabling access log ({}).".format(__name__))
if ignore:
log.debug("Ignoring prefixes: {}".format(ignore))
def accesslog_tween(request):
response = handler(request)   # Raises exceptions.
for prefix in ignore:
if request.path.startswith(prefix):
break
else:
msg = fmt.format(request=request, response=response)
log.info(msg)
return response
return accesslog_tween

Re: [pylons-devel] Adding custom properties to the request, or how is the request meant to be used?

[Mike Orr]

The request is for anything you need. Some frameworks pass a request
and response to the view and have other global objects and things, but
Pyramid tends to use the request to put all that stuff in one place.
Even semi-exceptions like 'context' that can be received separately
are also in the request. So I would do likewise, starting with
database connections.

In one application I have SQLAlchemy sessions to three databases, the
underlying engines to them, a Redis connection pool, an ldap3 pool,
things from tweens, and maybe other things. I tried different
strategies like add_request_method, a request subclass, and
pyramid_services. I ended up using a request subclass just because it
was easier to manage all those things together rather than piecemeal,
If I had only one or two I'd use add_request_method. And I use reify
as much as feasable.

Global things used across all requests can go into 'registry' or
'registry.settings', or you can use pyramid_services or the registry
interface API. Things like engines and connection pools are global and
thread-save so you can use them directly, although I ultimately found
it more convenient to make reified request properties that shadow
them. SQLAlchemy sessions have to be created for each request, so I
use reified properties for those, getting the engine from the
registry.

The features example you cited has an object that knows about the
features. But aren't boolean features ultimiately controlled by
configuration settings to enable them? You may be able to just use the
settings, or define your own settings, and then you wouldn't have to
make custom request properties.


On Fri, Jan 29, 2016 at 4:35 AM, Torsten Irländer <tors...@irlaender.de> wrote:
> Hi all,
>
> The request is  available almost everywhere is a pyramid application. This
> makes it seductive to use the request to pack many more properties to the
> request und (mis?)use it as a carrier for some kind of "dependency
> injection".
>
> I already added the current DB connection (which seems to be a widley used
> pattern) to it, and some other small thing. But I am wondering how the
> request is meant to be used. Is it OK to use the request for such things? I
> tend to say that adding more and more properties to the request (even if
> they are related to the request) is some kind of misuse and not intended by
> the developers.
>
> What do you think?
>
> For those who are interested in some background of this question: This
> questions arised when talking about how to implement Feature Toggles. See
> https://github.com/ringo-framework/ringo/issues/6
>
> best regards,
> Torsten
>
>
> --
> 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 https://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/d/optout.



-- 
Mike Orr <sluggos...@gmail.com>

-- 
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 https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Best Practices with ORM use

[Mike Orr]

On Fri, Jan 8, 2016 at 12:55 AM, Torsten Irländer  wrote:
> But I wasn't aware of that
> this
> could be a topic for a talk. Actually I thought this is kind of a hack but
> is
> seems to be not bad :D.

Organizing business logic has been a perennial issue for Pyramid and
Pylons developers forever. I started with high-level class methods and
instance methods in the ORM classes (depending on whether it's
operating on a single record or querying multiple ones), but I did all
the updating in the views. That led to two problems: the model modules
became large and cumbersome, and the views had so many unrelated
things intertwined. For the model problem I first extracted the
searching routines to separate classes in the model (SomethingQuery
classes).

Another thing I've long disliked was mixing presentation code and data
code in the views (Pylons controllers). The only choice was to put
formatting code in the Mako templates, and then if there's an
exception the traceback was often too generic and wouldn't tell you
where, or in the views with other stuff. Again I went maximum-template
approach, then minimum-template (a la mustache), then in between.

Later I was inspired by Mike Merickel's pyramid_services and the
Model-View-Presenter [1] paradigm. I tried pyramid_services but
couldn't find a good reason for adding the complication of the
registry class-matching stuff. So I ended up making my own service
classes that the views instantiate directly. The services handle
business logic, and the views focus mostly on Pyramid interaction
(form input, rendering variables).

I try to keep Pyramid-specific and presentation-specific things out of
the services, with three minor exceptions. One, services have a
'from_request' class method that extracts their data from the request
(e.g., database sessions using reified properties, engines using
"global" registry attributes). Two, they sometimes raise an
HTTPException if the caller would just do that anyway. I figure unit
tests can deal with an HTTPException as easily as some other
exception. Three, I sometimes have model methods or service methods
return a presentation-friendly value (JSONable dict, formatted string)
to avoid duplication and put the formatter close to the data fields.

[1] https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter

-- 
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 https://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-devel] Re: ZODB News

[Mike Orr]

On Tue, Sep 29, 2015 at 6:40 AM, Bastian Kuberek <bkube...@gmail.com> wrote:
> Could you please provide some brief reasoning on why ZODB is so brilliant? I
> have learned about it a few years ago when getting into pyramid but I have
> never used or seen it being used. I would love to get some insight on why I
> would use it and what would be a good use case to use it.

I haven't used ZODB but I've used Durus, which is a simpler database
following the same concept. An object database allows you to store
hierarchical Python data structures naturally: objects containing
objects, and dicts containing dicts of objects. You don't have to
shoehorn them into unpythonic relational tables or key-value stores or
use a complicated ORM. You just open the database and get the root
object, which behaves like a dict, and everything is under it
following keys and subkeys. Pyramid's Traversal mechanism is designed
for it, where the tree is the actual database structure and each node
(aka context) is an object in the database.

The main difference between ZODB and Durus as I understand it is ZODB
has a thread-safe layer while Durus is for single-threaded programs
(or with user-managed synchronization). This simplifies the code
significantly. So I'll describe Durus which I know, but I think ZODB
works similarly.

In Durus the root object is a PersistentDict. You can put ordinary
Python items into it, and they'll all be pickled with the dict. So
later if you ask for one item, it has to unpickle the whole dict to
retrieve it or check if it exists. But if you have a class that
subclasses Persistent, and you create an instance and put it into the
dict, then it will be pickled separately, so that when you ask for it
again the database only has to unpickle one object. So intelligently
using the database revolves around deciding which levels of nested
objects to make Persistent. It comes with PersistentDict,
PersistentList, and PersistentHash classes. A persistent dict or list
pickles all nonpersistent items and stores references to the
persistent items. A PersistentHash is like a dict but it pickles the
nonpersistent items in buckets of 16 (or whichever scale you choose).
My application had three kinds of data (three subdicts), and the
largest one had 5000 objects, each with fifty attributes and a list of
large strings. I had to do a lot of searching through the objects as
well as retrieving individual ones. I compared the performance between
several persistence levels, and found that PersistentHash used less
memory and was faster than using either persisent objects or a regular
dict, at least for that dataset.

The database is append-only for reliability, has commit/rollback, and
you can undo the last several transactions. There's a pack routine to
rebuld the database squeezing out versions of things.

I liked being able to store hierarchical data simply without having to
translate it into SQL data types and relationships and deal with a
complex ORM. But it has tradeoffs which are inherent in the database
design. I hated SQL because it's such an ancient clunky syntax, but
after I put my Durus database into production I realized that I missed
writing one-line queries. In SQL you can just write ten words to count
all the rows where some condition exists, or display the records in a
grid. In Durus you have to write a Python program to do a 'for' loop
through the database. That got annoying for ad-hoc queries.

Another issue is that the hierarchical model works better for 1:many
relationships than many:many. In an object database you embed objects
in their natural parents, and then query them as
``root[parent][child]``. But if you have an address that's used in two
places, you can't embed it in both places without duplicating it. So
you have to embed a reference to it, and then manually follow the
reference.

A third issue is that its append-only mode is unsuitable for counters
or frequent field updates. Even the littlest field change requires
repickling the entire record. Actually, PostgreSQL works like that too
because it stores records as immutable tuples, but PostgresQL reuses
space from deleted tuples, while Durus just appends until you pack.
Redis is probably the most useful for counters and updating timestamps
because it can change memory in place.

So it all comes down to the nature of your data and what you want to
do with it, whether a SQL database or object database or key-value
database is the most suitable for it.

-- 
Mike Orr <sluggos...@gmail.com>

-- 
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] AuthTktAuthenticationPolicy's auth_tkt

[Mike Orr]

On Fri, Jul 10, 2015 at 7:12 PM, Andrew Burnett
andrewjburn...@gmail.com wrote:
 I apologize in advance if 1) This is not the proper place to be asking such
 a question 2) My understand of authentication is so lackluster that my
 question is irrelevant to begin with. Having said that, I will ask away:

 I was hoping to use one of Pyramid's built in authentication policies
 (AuthTktAuthenticationPolicy) within my application. From what I understand,
 through the use of this remember() function I can obtain a set of Set-Cookie
 headers to be set on my response and returned so that my browser will follow
 suit and authentication will be taken care of when accessing my application
 via said web browser.

 My issue is that I'm using Pyramid as the backend of a mobile application
 native to iOS. So, I would like to leverage AuthTktAuthentication policy if
 possible, but return the appropriate cookie (Or cookies? Do I need more than
 one? Because more than one cookie is provided by
 pyramid.security.remember()) in the JSON body of my response. For example,
 I'd like to return {auth_tkt: -with the auth_tkt's value here-}.
 Is is possible to obtain the actual value of the auth_tkt cookie/s provided
 in the response.headers? Is this not how I should be going about this?

 I realize the cookies can be read from the client side by accessing the
 approproate authorization headers, but I'd like to explicitly send the
 auth_tkt via a JSON body if possible. Thanks.

If IOS supports cookies AuthTktAuthenticationPolicy would be the
easiest way to go. Otherwise you'd have to write an authentication
policy or see if you can use AuthTktAuthenticationPolicy ignoring the
cookie stuff it does.

If you look at pyramid/authentication.py you'll see that
RemoteUserAuthenticationPolicy and SessionAuthenticationPolicy are
very small and simple, so that's the minimum you have to do.
RemoteUserAuthenticationPolicy gets the authenticated user from an
external authenticator [1], while SessionAuthenticationPolicy stores
the user ID in an externally-manged session. Both of them return no
headers for .remember() and .forget() because they don't have to set
any headers.

In these cases the user ID is the auth token and you don't need to
sign or encrypt it because it never goes back to the client. (With
SessionAuthenticaticationPolicy the session ID goes back to the
client, but that's the session manager's responsibility.) But with
AuthTktAuthenticationPolicy and your JSONAuthenticationPolicy, the
ID does go back to the client so it has to be encrypted. Therefore,
what you want is the part of AuthTktCookieHelper that generates and
verifies the token, and you don't want the part that converts it to a
cookie. I don't know offhand if you can subclass AuthTktCookieHelper
and just bypass the cookie stuff, or if you'd have to reimplement it.
You'd also have to think about how to get the token in and out of the
JSON request/response. You might put it on a request attribute and let
some view code put it in the JSON response. Going the other way seems
trickier because authentication occurs before the view code, so you'd
have to deserialize the JSON early to get the token, which means you'd
have to handle invalid JSON or wrong content type at that point.
Perhaps you could do something analogous: deserialize the JSON object
and put it on a request attribute, and the view code can look for it
there rather than deserializing the body again. This assumes that
**ALL** requests are JSON.   (Fire alarm in my apartment, gotta go...)

[1] If you're wondering why the method is called
unauthenticated_userid, it's to bridge the API semantics between
REMOTE_USER which is always authenticated, and Pyamid which needs both
an authenticated and an unauthenticated userid.

-- 
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] Announcing Montague: replace INI with YAML, JSON, etc

[Mike Orr]

On Tue, Jun 23, 2015 at 12:55 PM, Jon Rosebaugh j...@inklesspen.com wrote:
 Around last December, I got annoyed with the way PasteDeploy combines the
 INI file parsing with the WSGI object loading. INI files are awfully clumsy
 and there are many alternatives that offer features such as lists and nested
 dicts, but as long as WSGI object loading was done through PasteDeploy,
 Pyramid could not easily take advantage of these config formats.

 (Of course, I could write my own bin script to launch my Pyramid app using
 my WSGI server of choice, loading config from a JSON file, but this doesn't
 let me take advantage of the Pyramid tools such as pshell or pviews.)

 This kind of flexible configuration is particularly important as Docker and
 similar tools become more popular for deploying apps. My Postgres database
 may change IP from deployment to deployment, but the correct IP is always
 available in environment variables. Of course, I can pull values from
 environment variables in my Python code, but I have to special case that
 everywhere that config settings might get loaded. Montague provides a
 solution to this through montague_mako, which renders a Mako template with
 environment variables into a config file of any kind.

 Montague also provides full PasteDeploy backwards compatibility (through an
 optional package). I'll be honest, figuring out how to do this sanely is
 what took the bulk of the time.

 I wrote a blog post about Montague here, which includes a demo loading a
 WSGI app, middleware, and server from a TOML file:
 https://metaclassical.com/announcing-montague-the-new-way-to-configure-python-applications/

I found an issue with TOML files. It says you can't have a dot in a
key name, but some consumers look for dotted keys
(pyramid.reload_templates, debugtoolbar.enabled). Can those
settings not be used without postprocessing the settings?

-- 
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] Announcing Montague: replace INI with YAML, JSON, etc

[Mike Orr]

 I've encountered one particular difficulty with pshell and other Pyramid
 scripts: Montague allows a config file to have more than one logging config,
 which means I've combined development.ini and production.ini into a single
 config.toml. pserve lets you specify which app and server to load (while
 pshell does not, except with the PasteDeploy #app syntax), but none of the
 scripts have a --logging-config argument.

 It seems to me that it would be good for the p*scripts to standardize on one
 particular way to specify the app, server, and logging config to load from
 the config files. Would anyone be opposed to a pull request making these
 changes?

I also have sometimes wanted to separate the logging configuration
from the rest of the file. The logging configuration is very verbose
with multiple stanzas and many lines, and sometimes I have several
files that differ in only one or two settings but the same logging
configuration. I also have multiple developers with their own file in
the version-control system, and often they all have the same logging
or would like me to manage the default logging options. Whenever I
change a default setting I have to replicate it in several files, and
that includes logging changes.

I also found that launching the application under uwsgi doesn't
configure the logging automatically. That's done by Waitress or
PasteDeploy Server or something like that, something that uwsgi
bypasses. Uwsgi has a '--paste-logger' option that's supposed to
configure a logging INI file, but it has never worked for me. So I've
defined a 'logging' key in my application, and if it's not empty, the
settings processor called by the main function calls FileConfig on the
file named in the value. Under Uwsgi the value is just %(__file__)s
or such, but this also allows me to use a different logging file under
Waitress if I want to.

-- 
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] Announcing Montague: replace INI with YAML, JSON, etc

[Mike Orr]

On Tue, Jun 23, 2015 at 12:55 PM, Jon Rosebaugh j...@inklesspen.com wrote:
 Around last December, I got annoyed with the way PasteDeploy combines the
 INI file parsing with the WSGI object loading. INI files are awfully clumsy
 and there are many alternatives that offer features such as lists and nested
 dicts, but as long as WSGI object loading was done through PasteDeploy,
 Pyramid could not easily take advantage of these config formats.

Hey, I was just thinking that last week, that maybe it would be worth
switching to YAML or JSON config files. I thought I would have to
write the glue code myself. I have a validator that I call from my
main function that validates the settings and converts their types. I
want any invalid settings to raise an exception at startup, not when
they're used in some obscure request. I've also got a fair amount of
list parsing and nested data structures and extra INI sections. It
takes a significant amount of code and deciding how to express these
in a setting or a section and write unit tests for them. I've found a
section works for something dict-like, and dotted key names can be
used for nested dicts or objects, but it's more cumbersome than
expressing them directly in YAML or JSON. I also have to create a
ConfigParser myself to read the section, and set the 'here' or
'__file__' key if I need them. Thanks for publishing Montague; I'll
try it out.

-- 
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: Pyramid Design Question

[Mike Orr]

On Mon, Sep 2, 2013 at 8:42 PM, Michael Zhang m...@solumtech.com wrote:

 Hi guys,

 My name is Michael Zhang, and I am very new to Pyramid. I have a quick
 question in designing a large web application backend, and hope the
 community can help me out. I really appreciate your help. It helps me to
 learn and get my job done.

 My question is simple: what are some good strategies in organizing common
 methods or classes for operations that we might constantly use in our
 applications? For example, if we have a method to collect all the comments
 belonging to a blog post, where we should put this method/class in our
 application in a clear and organized fashion? To us, there are potentially
 two choices:

 Choice A. We can define our model Blog, and inside Blog, we can define a
 method like getAllComments.

 Choice B. We can separately define BlogCRUD class, that has methods to get
 all comments.


Choice B sounds too pedantic and Javaesque. There's no reason you *can't*
put methods like this in your models. However, you may choose to keep them
separate for convenience. I'm actually deciding that right now as I port a
Pylons application that has all queries in high-level model methods.  I got
tired of mixing these kinds of queries with model instance methods (e.g.,
to format a field or group of fields). Then I realized I could put those
high-level methods in the resource tree, and that would separate them from
both the model modules and the view modules.  That partly depends on
whether you want to have a resource tree, whether you want to use
traversal, and whether you'll have access control lists.  To me it seems to
come down to application size: the resource tree is nice in large
application, but overkill in small ones.

The main separation I make in my applications is between the model and
everything else; i.e., the model can't depend on or import other parts of
the application, so that it can be used standalone or with another
framework/user interface. So I have an 'init_models(engine)' function that
sets the engine, and if I needed to pass any INI settings I would pass them
as individual arguments to that function.

-- 
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/groups/opt_out.

Re: Wanted: HTML tag generator for WebHelpers2

[Mike Orr]

On Wed, Jul 3, 2013 at 10:21 PM, Tres Seaver tsea...@palladion.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 07/03/2013 11:12 PM, Mike Orr wrote:

 The thing is, WebHelpers has always tried to avoid dependencies so
 that it can be used in the widest variety of use cases. It now
 depends on MarkupSafe because that's a small best-of-breed security
 enhancement. And I found some hidden dependencies on Pylons and
 Routes that I've now eradicated.

 FWIW, MarkupSafe is deliberately incompatible with Python 3.2:  the
 maintainer is stonewalling a trivial pull request restoring compatibility
 to leverage its users to drop 3.2 and adopt 3.3:

   https://github.com/mitsuhiko/markupsafe/pull/13

 For my money, that zeroes out any best of breed stamp it might
 otherwise have.  YMMV, of course.

Mike, how are you handling smart escaping without MarkupSafe in Mako
on 3.2? Are you falling back to the pre-MarkupSafe code?

-- 
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/groups/opt_out.

Re: Wanted: HTML tag generator for WebHelpers2

[Mike Orr]

On Wed, Jul 3, 2013 at 11:09 AM, Jason McKellar ja...@deadtreepages.com wrote:
 On Tue, Jul 2, 2013 at 12:46 PM, Mike Orr sluggos...@gmail.com wrote:
 Maybe I should just ask the list: is lxml suitable as a tag generator
 for webhelpers2.html? Or is it too big for a general-purpose library,
 not everyone of which will be generating HTML.

 I may be in the minority about dependencies, but I really don't mind have
 extra dependencies if they are the right tool. It doesn't hurt that I use
 lxml in most of my Pyramid applications anyway.

The thing is, WebHelpers has always tried to avoid dependencies so
that it can be used in the widest variety of use cases. It now depends
on MarkupSafe because that's a small best-of-breed security
enhancement. And I found some hidden dependencies on Pylons and Routes
that I've now eradicated.

Lxml to me seems large, whether that's accurate or not. And
WebHelpers' need is just for a small thing, and it would use only 5%
of lxml's features.  I may make an HTML class with a basic Python back
end, and a subclass that uses lxml if available.

Did I really put this on pylons-devel? I meant to put it on
pylons-discuss, but I just typed pylons and let it autocomplete,
forgetting that pylons-devel existed.

--
Mike Orr sluggos...@gmail.com

-- 
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/groups/opt_out.

Re: Wanted: HTML tag generator for WebHelpers2

[Mike Orr]

On Mon, Jul 1, 2013 at 11:48 PM, Wichert Akkerman wich...@wiggy.net wrote:

 On Jun 28, 2013, at 23:04 , Mike Orr sluggos...@gmail.com wrote:

 I'm thinking about rewriting the low-level HTML tag generator in
 WebHelpers2, and wondering if there's an existing library that would be
 worth using in this HTML 5/Python 2.6+ world.


 In rare situations where I can't use a template library I use lxml's
 E-factory to build HTML: http://lxml.de/tutorial.html#the-e-factory (or
 http://lxml.de/lxmlhtml.html#creating-html-with-the-e-factory ).

I thought about lxml but I think it's too big a dependency, especially
with its C dependencies.

-- 
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/groups/opt_out.

Re: Wanted: HTML tag generator for WebHelpers2

[Mike Orr]

On Tue, Jul 2, 2013 at 12:46 AM, Mike Orr sluggos...@gmail.com wrote:
 On Mon, Jul 1, 2013 at 11:48 PM, Wichert Akkerman wich...@wiggy.net wrote:

 On Jun 28, 2013, at 23:04 , Mike Orr sluggos...@gmail.com wrote:

 I'm thinking about rewriting the low-level HTML tag generator in
 WebHelpers2, and wondering if there's an existing library that would be
 worth using in this HTML 5/Python 2.6+ world.


 In rare situations where I can't use a template library I use lxml's
 E-factory to build HTML: http://lxml.de/tutorial.html#the-e-factory (or
 http://lxml.de/lxmlhtml.html#creating-html-with-the-e-factory ).

 I thought about lxml but I think it's too big a dependency, especially
 with its C dependencies.

Maybe I should just ask the list: is lxml suitable as a tag generator
for webhelpers2.html? Or is it too big for a general-purpose library,
not everyone of which will be generating HTML.


--
Mike Orr sluggos...@gmail.com

-- 
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/groups/opt_out.

Wanted: HTML tag generator for WebHelpers2

[Mike Orr]

I'm thinking about rewriting the low-level HTML tag generator in
WebHelpers2, and wondering if there's an existing library that would be
worth using in this HTML 5/Python 2.6+ world. Something to reimplement the
low-level make_tag function:

make_tag(a, Click here, href=foo.html)  =
a href=foo.htmlClick here./a

The stdlib seems to only have ElementTree, which is overkill and not that
suited to making individual tags in isolation. The libraries on PyPI seem
to be very old, older than the WebHelpers implementation. So I'm looking
for something that's:

- In the stdlib, or small and with no esoteric dependencies.
- Fast.
- Without ancient HTML 4/3 clutter.
- Compatible with MarkupSafe and the ''.__html__()`` protocol.

Other desirable features:

- Knows about HTML 5's empty tags, boolean attributes, data attributes, etc.
- Can set characteristics at the class level, and is subclassable.
- Has a Tag class or equivalent for lazy stringification. This would allow
you to build up the attributes piecemeal, pass the tag to a template, and
it would stringify itself when str() or .__html__() is called.  Possibly
caching the string.

Is there a library that does this or should I write it myself?

I'd also like feedback on another idea. I'm thinking about adding arguments
to build up the class attribute and style attribute piecemeal:

make_tag(..., classes=[foo, bar])  = ' ... class=foo bar'

make_tag(..., styles=[margin:0, padding: 1ex]) = '...
style=margin:0; padding: 1ex)

Would this be useful to others? Would the names collide with any other
potential attributes? (I don't think so since HTML doesn't define styles
and classes, and is unlikely to because of user confusion.) Is there a
better API? Are there any other attributes where this would be useful on?

Are there any other syntactic sugar patterns that would be helpful in a
Javascript-rich or HTML 5 application?

-- 
Mike Orr sluggos...@gmail.com

-- 
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/groups/opt_out.

Re: Wanted: HTML tag generator for WebHelpers2

[Mike Orr]

Version b3 converts arguments like data_a_b to data-a-b. It's not in
PyPI (I must have forgotten that step) but it's in the source. Version b4
will probably be out this weekend, with at least 'classes' and 'styles',
because I need that for a project.

There was some discussion about whether there is ever any use case to *not*
convert underscores; i.e., whether it needs to be switchable outside the
specific case of data_ - data-. I don't think so because the HTML spec
seems to say that only hyphens are valid in attribute names.



On Fri, Jun 28, 2013 at 2:31 PM, Jonathan Vanasco jonat...@findmeon.comwrote:



 On Friday, June 28, 2013 5:04:08 PM UTC-4, Mike Orr wrote:


 Are there any other syntactic sugar patterns that would be helpful in a
 Javascript-rich or HTML 5 application?


 you should support html5 custom data attributes , the *data-** syntax.

 ie:
 a href=http://example.com; data-a=1 data-b-a=2Link to
 Example.com/a

 you can have one (or more) dashes in them, so I'm not sure how you could
 pass them in , other than as a dict

 make_tag(... attrs={ 'data-a' :1 , 'data-b-a':2 }... )
 make_tag(... data_attrs={ 'data-a' :1 , 'data-b-a':2 }... )
 make_tag(... data_attrs={ 'a' :1 , 'b-a':2 }... )

 personally i would prefer one of the first two options; i'm only bringing
 up the last one to note my disapproval of it.

 --
 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/groups/opt_out.






-- 
Mike Orr sluggos...@gmail.com

-- 
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/groups/opt_out.

Re: question about design decision on pyramid's core

[Mike Orr]

I don't know officially, but Chameleon was added a lot earlier and the code
may be inherited from BFG. Mako was added for the Pylons integration
because Chameleon would have been too big a change for them. At the time it
was thought that these would be the built-in template engines and others
would be third-party. Since then mcdonc has talked about spinning those off
too, as pyramid_chameleon and pyramid_mako, but that hasn't happened yet.


On Wed, Mar 27, 2013 at 10:44 AM, Jonathan Vanasco jonat...@findmeon.comwrote:

 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 ?

 --
 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.





-- 
Mike Orr sluggos...@gmail.com

-- 
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: Sites using Pyramid Pyramid Advocacy

[Mike Orr]

On Fri, Oct 26, 2012 at 1:35 PM, Iain Duncan iainduncanli...@gmail.com wrote:


 What is the objective?  To promote Pyramid or to promote third parties
 using Pyramid?  If the former then having a well-curated list of showcase
 examples seems best.  If the later then there may be an argument for opening
 it up to make it easy for people to submit their own sites.  It's possible
 to do both but probably not in the same place.


 For me personally, the objective is to be able to show people and clients
 that Pyramid is used extensively in real world applications. In that sense,
 I agree some curation is probably necessary, as on the SQLAlchemy page. But
 I think it also helps just to have a really big list, much like Plone does.

Well. different people are looking for different things. Some people
want to see big names and high-traffic sites. Others want to see
really extensive sites doing a lot of things. Others want to see a
large number of sites. Others want to see a wide variety of innovative
features in the sites. The latter includes those who aren't using
Pyramid yet and want to see what it can do, and also those who are
using Pyramid and looking for ideas for their own sites.

-- 
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.

Re: suggestion for scaffolds

[Mike Orr]

On Fri, Feb 3, 2012 at 9:28 AM, Jonathan Vanasco jonat...@findmeon.com wrote:
 2. migrate all the /static/ items to /static/pyramid/

 it's too cluttered and slightly intimidating , and when you're playing
 around... i want to clean out those files but I don't want to lose
 them (yet).

+1

I usually delete them immediately, but when I started I was reluctant
to because I didn't know which ones I might want to use or refer to.

-- 
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.

Re: Logging configuration

[Mike Orr]

On Fri, Oct 21, 2011 at 5:51 AM, Chris McDonough chr...@plope.com wrote:
 On Fri, 2011-10-21 at 02:50 -0700, Mattias wrote:
 I am setting up a little test application using pylons and pyramids, I
 am currently using mod_wsgi under apache2 as the server. So far
 everything works perfectly except my logging. I have tried to change
 the

 On the page 
 http://docs.pylonsproject.org/projects/pyramid/1.2/narr/logging.html
 is says This chapter assumes you’ve used a scaffold to create a
 project which contains development.ini and production.ini files which
 help configure logging. All of the scaffolds which ship along with
 Pyramid do this.

 Later on it says The paster serve command calls the
 logging.fileConfig function using the specified ini file if it
 contains a [loggers] section (all of the scaffold-generated .ini files
 do). logging.fileConfig reads the logging configuration from the ini
 file upon which paster serve was invoked.

 I use paster in my wsgi file, http://pastie.org/2734261, but I know
 you can also use paster as the server.

 Will the automatic logging configuration only work if I am using
 paster as the server?

 In short, yes.  But technically, paster is not the server.  paster
 serve *runs* a server, but it is not a server.  Automatic logging
 configuration takes place when you use paster serve.  If you don't use
 paster serve, it doesnt happen.

paster serve does the equivalent of:

import logging.config
logging.config.fileConfig(INI_FILE)

You can put that in your startup code somewhere.

Python 2.7 also has a new 'dictConfig' function that takes a nested
dict structure instead of a filename, if you find that more
convenient.

-- 
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.

Re: Adding abort and redirect to Pyramid

[Mike Orr]

On Wed, Jun 1, 2011 at 11:39 PM, Chris McDonough chr...@plope.com wrote:
 #1 is important so that you can cut through multiple function calls
 if
 you discover an error condition.
     Use case 1: a support method/function for several handlers
 discovers a required query parameter is missing. The application's
 forms and links would never produce such a request, so we presume the
 request is illegitimate and abort 400.

 The folks I've talked to on the don't turn HTTPExceptions into
 responses by default side of the debate argue that both use cases above
 are poor coding practices because only view code (code that is
 contacted only because a view was matched, as opposed to random things
 that that view may call into) has enough information to be able to
 return a sensible response.  They further argue that since it's so easy
 to turn on the feature, allowing folks that don't share their opinion
 to do it, Pyramid shouldn't do it by default.  Just FYI, that's the
 other side of the argument.

OK, but there's such a thing as view support methods, code that's
common to several views so it doesn't have to be repeated in all of
them. That's the only place where I'd use this.  For instance:

class MyHandler(object):
def my_view(self):
params = self.request.params
self._process_id(params.get(id))

# Private methods
def _process_id(self, id_str):
if id_str is None or not id_str.isdigit():
abort(400, query param 'id' missing)
id = str(id)
self.record = model.Something.get(id)
if self.record is None:
abort(404, that Something does not exist)

-- 
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.

Re: Adding abort and redirect to Pyramid

[Mike Orr]

On Tue, May 31, 2011 at 11:21 PM, Alexandre Conrad
alexandre.con...@gmail.com wrote:
 Hi,

 This post totally went over my head and there's a lot to read which I
 don't feel like doing right now, so I'll just give my 2 cent straight
 away (and if it was already addressed, reply already addressed, and
 I will dig into the thread's archives):

 2011/5/15 Chris McDonough chr...@plope.com:
    def aview(request):
        abort(401)

    def aview(request):
        redirect('http://example.com')

 What I *really* didn't like with Pylons abort() and redirect() was the
 fact that that these functions were stopping the code flow without a
 return statement.

We could just make abort() and redirect() helper functions that return
an exception, which the user would then raise. The priority for me is:

1. Make HTTPExceptions raisable by default.

2. Add a helper to construct a redirect:

redirect(location, **kw)   =  HTTPFound(location=location, **kw)

3. Add a helper to construct an abort:

abort(N, message=None, **kw)   =
httpexception_by_number(status=N, message=message, **kw)

4. Make abort() and redirect() raise their result rather than returning it.


#1 is important so that you can cut through multiple function calls if
you discover an error condition.
Use case 1: a support method/function for several handlers
discovers a required query parameter is missing. The application's
forms and links would never produce such a request, so we presume the
request is illegitimate and abort 400.
Use case 2: a support method/function discovers that a required
support file is missing, an authentication server is unreachable, etc.
This is a webmaster/sysadmin error so we abort 500.

#2 is important because HTTPFound is not very self-documenting, and we
shouldn't have to specify the location by keyword argument since it's
the entire purpose of the call.

#3 is useful but perhaps not necessary. It's convenient but not
necessary self-documenting because you have to memorize all the
numbers. It's also helpful to have a message as a positional argument.
This would be added to the error message. This has been proven useful
in Pylons. A further enhancement would be to have both a secure and an
insecure message. The secure message would appear in the default error
screen, while the insecure message would be included in the sysadmin's
error report.

#4 is minimally useful. They do have the significant downside of
looking like returning function calls when they actually change the
program flow. It would be fine if they simply return the error and the
user raise it explicitly.
raise redirect(location)
raise abort(N, message=None)

Or they could be capitalized to appear more like class constructors:
raise Redirect(location)
raise Abort(N, message=None)

-- 
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.

Re: Adding abort and redirect to Pyramid

[Mike Orr]

On Tue, May 31, 2011 at 12:55 PM, Chris McDonough chr...@plope.com wrote:
 - We will disuse the classes from webob.exc because, although they
  advertise themselves as Response objects, they really very badly
  want to be used as WSGI applications rather than plain response
  objects.

Aren't all Response objects WSGI applications? I thought that was part
of the API, that they could serialize themselves.

 - pyramid.response.Response will now be a *subclass* of
  webob.response.Response (rather than an alias) which will
  both inherit from Exception (so it can be raised) and will provide
  the pyramid.interfaces.IExceptionResponse interface.

Can't anything be raised regardless of whether it inherits from
Exception? (And for new-style classes, if the Python version is recent
enough.) I think Pylons' abort() raises HTTPException subclasses,
doesn't it?

So I don't see how these new exception classes will be different from
the old ones except for a new parent and interface, which doesn't
really affect the user.

 After the above steps are taken, raise
 pyramid.response.HTTPUnauthorized(...) from within view code (or
 event handler code) will generate a 401 response code with a default
 body out-of-the-box.  It will mean (probably more controversially)
 raise Response('OK') will generate a 200 response code with the body
 OK.

It may be an unorthodox way to return but it's probably better to just
allow it than to take steps to prevent it. I could see how it could be
a feature in a few cases.  And again, Python doesn't seem to be
overly concerned with what you raise. The move against string
exceptions was to make sure you provided the actual class in the
'except' clause rather than comparing by equality.

-- 
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.

Re: Adding abort and redirect to Pyramid

[Mike Orr]

On Sun, May 15, 2011 at 11:27 PM, Chris McDonough chr...@plope.com wrote:
 I've created a branch named httpexception-utils on GitHub which
 contains an implementation of redirect and abort for Pyramid that
 act like their Pylons brethren.

 In short, the abort feature is used like this:

    from pryamid.httpexceptions import abort

    def aview(request):
        abort(401)

 This will perform the same job as what used to be necessary as:

    def aview(request):
        return HTTPUnauthorized()

 The redirect feature is used like this:

    from pryamid.httpexceptions import redirect

    def aview(request):
        redirect('http://example.com')

 This will perform the same job as what used to be necessary as:

    def aview(request):
        return HTTPFound(location='http://example.com')

 In addition, any HTTP exception (an exception imported from
 pyramid.httpexceptions) can now be raised rather than returned.  The
 object raised will be used as a response.

 Here's the branch:

 https://github.com/Pylons/pyramid/tree/httpexception-utils

 Here's the commit which added the feature:

 https://github.com/Pylons/pyramid/commit/1ffb8e3cc21603b29ccd78152f82cca7f61a09b1

 It'd be nice to get some feedback from existing Pylons users to see if
 the implementations of these features are good enough; it'd also be
 nice to hear dissenting opinions with reasons for dissent if folks
 believe this feature should not be added to Pyramid.

Raising HTTP exceptions should definitely be added to Pyramid. It's
silly for an application to have to add an exception view that just
returns the exception: it feels kludgy, it's not what views are for,
and it adds to the overhead. Why can't the code that invokes the view
just have an 'except HTTPException:'?  If the user really wants to
register an exception view in order to display a fancy-dancy page,
that's another thing.  It seems like Pyramid should be able to
accommodate both.

HTTP errors *are* exceptions. If you call a support method and it
discovers that a required query parameter is missing, what's it
supposed to do? The request can't continue, so it might as well kill
it right there. That's directly akin to a ZeroDivisionError. 'raise'
has two advantages. One, it shortcuts the call stack so you don't have
to return some dummy value, or define another exception just to catch
it later. Two, 'raise' is a Python keyword so it's syntax-highlighted
and users should be expecting it.

abort() and redirect() are not necessarily the most intuitive but I
can't think of any better API for them. I did use them a lot in Pylons
and I miss them a bit in Pyramid.  They do have the disadvantage that
they look like normal returning function calls instead of having that
'raise' keyword. 'redirect' is particularly useful because it's not
intuitive that 'HTTPFound' means I'm doing a redirect. If you see it
often you get used to it, but otherwise it's like, Oh, nice, it found
something. That doesn't tell me what it's going to do with it. I
think that's a shortcoming of the HTTP status: it should have been
called 'Redirect' rather than 'Found'.

BTW, I mentioned a few days ago that my application is displaying a
blank page when I return HTTPNotFound or HTTPBadRequest, so something
is missing somewhere. The HTTP status is right but the body is empty,
no Not Found or anything.

-- 
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.

Re: Pyramid 2 Brainstorm Marrow

[Mike Orr]

On Thu, May 26, 2011 at 3:39 PM, Alice Bevan–McGregor
al...@gothcandy.com wrote:
 Unfortunately, the majority of the Marrow projects that could
 benefit Pyramid would require core changes, thus a fork and a number of
 branches to explore the options, not just add-on packages or adaptive
 HOWTOs.

In that case, what might be better than a HOWTO is an outline of how
the packages could be integrated. I.e., which specific parts of
Pyramid would interface with which parts of the Marrow suite. If you
need help analyzing the Pyramid side, i may be able to help with that
; i.e., looking under the surface in Pyramid and what design
requirements it has at that particular point.

-- 
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.

Re: Pyramid 2 Brainstorm Marrow

[Mike Orr]

 under the HTTP/1.1 implementation. The underlying
 stack also has full support for a worker thread pool (using Futures) and
 multi-processing. Both of these details are handled for you by the web
 server; if you enable a thread pool, communication is still handled using
 async, but the WSGI application is executed in a thread. This allows you to
 tune a deployment for your requirements. Development or io-bound? Run a base
 server. CPU-bound? Run a threaded server. Need to scale? Add
 multi-processing to either of those.

 I'll mention it again, since this point is very important: the underlying
 server being async has ZERO impact on your own applications. It's not like I
 magically monkeypatched async support in everywhere; no, instead, only the
 core reactor for I/O (which makes sense) is async.  The HTTP protocol
 implementation plugged into marrow.server either runs the WSGI application
 inline (which blocks other requests if not fast enough) or in a thread pool,
 your choice.  (Choice is good!  I have an RPC service running in pure async
 mode that can handle ~6KRsec; threading slows it down!)

If you can put this in a Pyramid/Marrow HOWTO, it would make users
more comfortable about trying it.

Most Pyramid/Pylons users come from a multithreaded background. They
either know or have learned how to make their views thread-safe. Many
have not used async servers and don't know how to make their views
async-safe. Normally it involves using special database libraries,
socket wrappers (if the view itself is invoking web services or doing
RPC etc), and also thinking about what else might be an intolerable
blockage (e.g., parsing or producing a multigigabyte file).

You say that Marrow users don't have to worry about any of these. In
that case, please explain in the HOWTO how to configure Pyramid/Marrow
for the various modes, the actual effect of typical blocking
constructs (SQLAlchemy, web services, etc) on the various modes, and
how Marrow's thread pool compares to PasteHTTPServer's thread pool.
Explaining it in the terminology that Pyramid and Pylons users are
familiar with will go a long way in making users more willing to try
Marrow, and the Pyramid developers more willing to consider Marrow.

 Proper releases of marrow packages require 100% unit test coverage,
 documentation, and multiple working examples.

In that case, suitable documentation may already be written. You'd
just need to paste some paragraphs into a HOWTO  and reword it a bit
so that users can see how THIS [what I'm familar with in Pyramid]
corresponds to THAT [something new in Marrow]. The correspondence may
seem obvious to you, but not necessarily to users. And users may not
be willing to spend time figuring out what the correspondence is;
they'll just move on to another library.

 One of the easiest ways to examine these libraries are via the example code
 [2][3], and through the code for the libraries themselves.  Additionally,
 you'll have to dig into a fork [4] to see demonstrations of WSGI1
 compatibility in marrow.server.http.  The adapter [5] is simple, and likely
 incomplete, but functional.

I'm probably sounding redundant here, but only those who are
especially motivated to use Marrow will follow all those references
and figure out the correspondence between those examples and Pyramid.
Others will move on unless there's a Pyramid-specific HOWTO. Of
course, it may not be worth your while to write such a thing,
depending on how important Pyramid is to you. But if you seriously
want to spread Marrow adoption and/or Pyramid is important to you, it
would be worth your while.

-- 
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.

Re: route_url _query None value behavior

[Mike Orr]

webhelpers.util.update_params deletes any parameter with a value of
None. Mako templates converts None values to ''. Having None convert
to None is almost never useful in query parameters, while having
integers and other types converted to strings is useful. So that all
argues for trapping None and either converting it to '' or deleting
the parameter.

On Sat, May 21, 2011 at 7:39 PM, Chris McDonough chr...@plope.com wrote:
 Don't think this is really right if you consider the desire to be able
 to pass integers (like 0), which others have requested before.

 What precedent is there to passing the value None being converted to
 empty string?

 - C

 On Sat, 2011-05-21 at 18:35 -0700, Jerry wrote:
 Google group messes with the formatting, which should have been --

 else:
     if v.__class__ is unicode:
         v = v.encode('utf-8')
     if v:
         v = quote_plus(str(v))
         result += '%s%s=%s' % (prefix, k, v)
     else:
         result += '%s%s=' % (prefix, k)

 Jerry

 On May 22, 9:32 am, Jerry jerryji1...@gmail.com wrote:
  Hi,
 
  Pyramid's route_url/route_path behavior with None _query terms doesn't
  seem very canonical to me --
 
  (Pdb) request.route_path('home', _query=[('q', None)])
  '/home?q=None'
 
  Omitting value is more like it --
 
  (Pdb) request.route_path('home', _query=[('q', '')])
  '/home?q='
 
  so is omitting both --
 
  (Pdb) request.route_path('home', _query=[('q', [])])
  '/home?'
 
  Chris and other Pyramid maintainers: would you consider adding this
  simple check to urlencode() in pyramid/encode.py ? --
 
   89     for (k, v) in query:
   90         if k.__class__ is unicode:
   91             k = k.encode('utf-8')
   92         k = quote_plus(str(k))
   93         if hasattr(v, '__iter__'):
   94             for x in v:
   95                 if x.__class__ is unicode:
   96                     x = x.encode('utf-8')
   97                 x = quote_plus(str(x))
   98                 result += '%s%s=%s' % (prefix, k, x)
   99                 prefix = ''
  100         else:
  101             if v.__class__ is unicode:
  102                 v = v.encode('utf-8')
                     if v:
  103                 v = quote_plus(str(v))
  104                 result += '%s%s=%s' % (prefix, k, v)
                     else:
                         result += '%s%s=' % (prefix, k)
  105         prefix = ''
 
  Thanks.
 
  Jerry



 --
 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.





-- 
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.

Re: GSoC, Python 3 dependencies, Paste

[Mike Orr]

On Thu, Apr 7, 2011 at 7:58 AM, Juliusz Gonera jgon...@gmail.com wrote:

 OK, it took me some time but I finally wrote the application:
 http://blog.juliuszgonera.com/wp-content/uploads/2011/04/gsoc-pyramid.pdf

 I'm not sure if I should put something more in milestones. PSF wiki
 (http://wiki.python.org/moin/SummerOfCode/Application) suggests listing
 week-by-week work plan, but I'm not sure it's suitable for this project. I
 guess many things can change, but if a week-by-week work plan is recommended
 I can prepare a draft. On the other hand side, their own application
 template lists only those 3 milestones (start, midterm, final).

Week by week is probably not realistic because you don't know how long
each part will take, and the tasks probably won't fall on week
boundaries. Still, if you can identify a sequence of steps that must
be taken for each milestone, you can estimate the number of days for
each step. E.g., write tests for this subpackage, that subpackage,
etc. Leave at least the last week of each milestone free for
contingencies.

 Also, I'd like you to comment on the packages chosen by me to be ported (too
 little / too much work?)

My main concern about all the applications is that I'm not sure we can
accurately predict that this far in advance how long each package will
take and their relative importance. (I'm only talking about
applications related to porting to Python 3/unit testing; I'm not sure
if there are any applications outside that.) That partly depends on
what all the GSOC students and other developers do over the summer.
What I'm saying is that while we can make tentative student-to-package
assignments up front, I think we'll need the flexibility to
re-evaluate this midterm-ish. Just to discuss between the
students/mentors/group leader whether the second-half assignments
still make sense or whether a student may want to change packages.
Because the ultimate goal is to run Pyramid on Python 3, and we need
to avoid giving one package too much attention and another package too
little.

For instance, most of the applications are focused heavily on Ian's
packages (Paste, WebOb, WebError, etc.) This may be appropriate for
not; I'm not sure; ChrisM would have a better handle on that. But we
can't have two students working on the same package, or rigidly focus
on a few packages that turn out to be too easy or too marginal (e.g.,
10% of the problem). That's where I think flexibility comes in. It
would reassure me if applications indicate whether students are
willing to consider working on other packages if it seems appropriate
at the time, and perhaps list alternate packages that they'd be most
(or least) interested in working on.

The other thing I'd like to see in all the applications is a more
specific indication of the person's Python programming experience.
E.g., what kinds of packages or programs you've worked on, the kinds
of Python complexity involved in that, etc. Writing unit tests
probably requires just basic Python experience, but porting may
involve more depending on the package. For instance, I have a solid
background with (Mako-style) templating, database models, URL dispatch
and tag builders, but not much with the Zope-style interfaces or
traversal. So I'm fine with anything database-y but if it involves ZCA
or garbage collection or packet tracing, I'd probably want to call in
the experts. Anyway, it helps to know up front what kinds of tasks a
student can jump right into and what kinds would be more difficult.

-- 
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.

Re: ATTN: Please keep general discussion on pylons-discuss

[Mike Orr]

On Thu, Mar 31, 2011 at 7:14 AM, Chris Withers ch...@simplistix.co.uk wrote:
 On 15/03/2011 20:01, Ben Bangert wrote:

 Here's a quick way to know which one to post to:
 pylons-devel
 - Discussion about development of pylons project libraries such as
 pylons/pyramid/etc.

 pylons-discuss
 - General discussion about best practices of development, asking for help,
 etc.

 How about just merging the lists?

 Is there really so much volume as to justify two lists?
 Having a -devel and -discuss list always feels like elitism to me, in that
 the people who can actually help hang out on -devel, and the people who need
 it on -discuss :-S

That sounds more like a prejudice than anything that's happening on
the lists. It happens on lists that have hundreds of messages a day
like Debian, but those groups also have more developers so some of
them remain on the user list.

The two lists are meant to be a convenience for users, so that those
who don't care about minor/theoretical development discussions and
trivial This page on the website doesn't work or You forgot to
change the version number in this place can skip it. All the
developers are on the -discuss list and answer questions there. But
sometimes when I have too much mail, I don't read messages based on
their subject lines. That would happen with either one list or two.

We did take usage questions on -devel in the alpha days of Pyramid, to
prevent Pyramid questions from confusing Pylons users. That's where
all the confusion between the lists came from. That's over now.

-- 
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.

Re: Form handling in Pyramid

[Mike Orr]

On Tue, Mar 29, 2011 at 4:06 AM, karantan karan...@gmail.com wrote:
 Hi,

 So is there any news if pyramid will have anything like from
 pylons.decorators import validate? i tried to use formencode but it's
 not so easy to implement in pyramid. i will try formish next and i
 hope i'll have more success with it...

Have you tried pyramid_simpeform? It's a different interface than
@validate but it seems to be becoming the most common on on Pyramid.

-- 
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.

Re: Terminology Change - Template to Skeleton

[Mike Orr]

On Wed, Mar 23, 2011 at 3:31 PM, Philip Jenvey pjen...@underboss.org wrote:

 On Mar 22, 2011, at 7:14 PM, Mike Orr wrote:

 On Tue, Mar 22, 2011 at 6:46 PM, Ben Bangert b...@groovie.org wrote:


 We sure can! In fact, several of us have the commit rights needed. :)

 Deprecating the old one is definitely an option.

 That's a good idea. Just updating the output would avoid the
 confusion. I wouldn't deprecate -t though (even if you deprecate the
 long form --template), because many people are used to typing it and
 it would be annoying to get deprecation warnings all the time.

 FYI you'd only get the warnings in = Python 2.6. As of 2.7/3.2, 
 DeprecationWarnings are hidden by default.

 I'd actually want an annoying warning shown the user at some point, but just 
 not immediately. I'd make it a PendingDeprecationWarning (hidden everywhere 
 by default) for a while.

-t doesn't have to mean anything, it's just an option letter.
paster create -t rolls off the fingers after you've typed it often
enough. It can be kept as an alias for paster create -s.  (Or -b.)

-- 
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.

Re: Terminology Change - Template to Skeleton

[Mike Orr]

On Tue, Mar 22, 2011 at 10:07 AM, Eric Lemoine
eric.lemo...@camptocamp.com wrote:
 $ paster create --list-templates
 Available templates:
  basic_package:          A basic setuptools-enabled package
  paste_deploy:           A web application deployed through paste.deploy
  pylons:                 Pylons application template
  pylons_minimal:         Pylons minimal application template
  pyramid_alchemy:        pyramid SQLAlchemy project using traversal
  pyramid_routesalchemy:  pyramid SQLAlchemy project using url
 dispatch (no traversal)
  pyramid_starter:        pyramid starter project
  pyramid_zodb:           pyramid ZODB starter project

 So, so long that Pyramid is based on Paste for templates, introducing
 a new term might be confusing to people.

We can use [other word] throughout, we just have to remember to
mention that paster create calls it a template, both when first
introducing the word and when directly referring to the command and
its output.

The sooner we can replace paster create  with something that doesn't
use the word template, the better. I think it's pretty clear that
it's not worth making significant changes to PasteScript because it's
a namespace package under Paste, and Paste is the package that's least
useful.

 I honestly didn't realize this would become such a big
topic of conversation

It may require a historical view to understand this. From the late 90s
till 2005, every Python framework was unique and non-interpoerable
with any other. This was widely seen as intolerable so WSGI was
created. Paste was the concrete manifestation of WSGI (meaning, it
provided tools to choose a WSGI app and server and connect them, and
building blocks for WSGI frameworks. Paste was the only concrete
unifying factor among all these frameworks that gradually moved
together; even those that didn't merge or didn't use Paste directly.

Paste itself provides only mini-frameworks. Pylons was the first Paste
framework to include a real template engine. Thus the ambiguity
started between application templates and template files. But
because Paste was the only unifying factor between these frameworks
that were trying to become un-fragmented, there was little interest in
changing anything about Paste that might harm the fragile unity.

What's different now is that, seven years later, framework
consolidation is well established, most of the useful parts of Paste
have been spun off into separate packages with non-Paste identities,
the remaining parts of Paste are stagnating and people have not rushed
to take over its maintenance, and the frameworks have become more
assertive, Let's make some changes.  So therefore, a move to rename
application template is viable now in a way that it wasn't before.

Just this week I decided to rename application template in my Akhet
manual because the term was just too cumbersome,  but I never thought
the Pyramid docs would be amenable to doing that. And then a few days
later you say you do want to change the Pyramid docs. So it's an idea
that's gaining momentum, and that's why the big discussion broke out.

-- 
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.

Re: Terminology Change - Template to Skeleton

[Mike Orr]

On Tue, Mar 22, 2011 at 6:46 PM, Ben Bangert b...@groovie.org wrote:
 On Mar 22, 2011, at 6:30 PM, Michael Merickel wrote:

 I'd imagine we can update Paste to support an alias for templates?

 paster create --list-scaffolding
 paster create --scaffold pyramid_starter
 paster create -s pyramid_routesalchemy

 Maybe the actual templates commands could even be hidden from the help and 
 simply supported if ran with a deprecation warning.

 Just throwing it out there, as I'm sure it's more complicated than that. A 
 lot of the templating code for Paste is kind of scary.

 We sure can! In fact, several of us have the commit rights needed. :)

 Deprecating the old one is definitely an option.

That's a good idea. Just updating the output would avoid the
confusion. I wouldn't deprecate -t though (even if you deprecate the
long form --template), because many people are used to typing it and
it would be annoying to get deprecation warnings all the time.

-- 
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.

Re: WebHelpers conflict #63 and #59

[Mike Orr]

I changed the .__slice__ to .__getitem__. This passes the tests in the
SQLAlchemy and sliceable cases. I think it will let some non-sliceable
cases through which would cause the original Sprox error, but i don't
think there's anything we can do about that because we can't check
whether .__getitem__ accepts a slice without calling it and guessing
what the exception means, and calling it may cause side effects (like
a db query).

So if y'all can make sure you're satisfied with it, I'll release beta
2 in a day or two.

-- 
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.

Re: WebHelpers conflict #63 and #59

[Mike Orr]

Update: I found a way to check for the exact exception reported, which
was common to the Sprox failure and other unsliceable failures
(TypeError: unhashable type). So I can at least raise the
incompatible message so users will know what's going on.

On Tue, Mar 22, 2011 at 10:21 PM, Mike Orr sluggos...@gmail.com wrote:
 I changed the .__slice__ to .__getitem__. This passes the tests in the
 SQLAlchemy and sliceable cases. I think it will let some non-sliceable
 cases through which would cause the original Sprox error, but i don't
 think there's anything we can do about that because we can't check
 whether .__getitem__ accepts a slice without calling it and guessing
 what the exception means, and calling it may cause side effects (like
 a db query).

 So if y'all can make sure you're satisfied with it, I'll release beta
 2 in a day or two.

 --
 Mike Orr sluggos...@gmail.com




-- 
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.

Re: Terminology Change - Template to Skeleton

[Mike Orr]

On Sun, Mar 20, 2011 at 8:12 PM, Joe Dallago jd.dall...@gmail.com wrote:
 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.

Yes. I already did that in the Akhet manual but I had to introduce it
with template and use template in the PyPI description for ppl who
might not recognize it. The sooner we can get away from template
completely, the better.

-- 
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.

Re: WebHelpers conflict #63 and #59

[Mike Orr]

On Mon, Mar 21, 2011 at 9:05 AM, Marius Gedminas mar...@gedmin.as wrote:
 I'll just add a note that defining __getslice__ is not necessary to support
 slicing (in fact it's been deprecated since Python 2.0).  The modern way
 is to have your __getitem__ check if the argument passed to it is an
 instance of the builtin `slice` type.

 (You probably knew that already, but your wording above is a bit ambiguous.)

No, I didn't know that. I've never dealt with slices, just individual items.

Actually, I don't know if I can check for that. I can check for the
presence of a method, but not its semantics. Unless I call the method
and see what it does with a slice, but that would be silly and
potentially disruptive.

 Incidentally, what's that '__slice__' thing you're checking for in
 https://bitbucket.org/bbangert/webhelpers/changeset/556b55e75dd6#chg_webhelpers/paginate.py_newline215
 ?  docs.python.org has no knowledge of it.

Oh, that should be .__getslice__ . Maybe that's causing some of the
SQLAlchemy complications (but not all of them).

-- 
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.

Re: Terminology Change - Template to Skeleton

[Mike Orr]

On Mon, Mar 21, 2011 at 12:09 PM, Stephen Lacy slacy+perso...@slacy.com wrote:
 Why not just cut to the chase and call them examples.
 They can then be fully fledged working applications, and users can be
 advised to copy them to their own directory structures before continuing.
  That's probably what everybody does anyway, right?

No, because the project name and package name is built into the
structure, so reusing an existing app would mean making a lot of
fundamental changes to it.

-- 
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.

Re: Terminology Change - Template to Skeleton

[Mike Orr]

On Mon, Mar 21, 2011 at 11:08 AM, Alice Bevan–McGregor
al...@gothcandy.com wrote:
 On 2011-03-20 23:23:02 -0700, Mike Orr said:

 On Sun, Mar 20, 2011 at 8:12 PM, Joe Dallago jd.dall...@gmail.com wrote:

 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.

 Yes. I already did that in the Akhet manual but I had to introduce it
 with template and use template in the PyPI description for ppl who
 might not recognize it. The sooner we can get away from template
 completely, the better.

 --
 Mike Orr sluggos...@gmail.com

 ±0 — skeleton describes what it is less than, say, blueprint.  A Linux
 /etc/skel is static, for one.  Blueprints often reference other blueprints,
 too.

I like the word blueprint better than skeleton, actually. I would have
suggested it but you had already taken the name. I don't think we can
use your implementation classes directly, because they make a several
fundamental changes compared to PasteDeploy/PasteScript that I don't
think Pyramid is ready to commit to at this point. Such as using
alacarte, being another namespaced package, adding several
dependencies, etc.  I've heard your packages are also Python 3-only? I
think what we'll probably do is make a new implementation of Paste*
but keep the features and API mostly the same, at least that's what a
few developers are working on. Would you mind if we use the term
blueprint in this paster create replacement?

-- 
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.

Re: Terminology Change - Template to Skeleton

[Mike Orr]

On Mon, Mar 21, 2011 at 12:44 PM, Ben Bangert b...@groovie.org wrote:
 I've been doing Pylons for a long time, and we generally do say 'paster 
 templates' and no one thus far has ever gotten confused afaik.

Template has been a problem for years. Even if people can figure it
out, it's cumbersome to write in documentation and tutorials where you
have to explain that a template (skeleton) is not a template (file)
although some of its files are templates. And the phrase application
template is long and cumbersome when you have to repeat it many
times.

-- 
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.

Re: Terminology Change - Template to Skeleton

[Mike Orr]

On Mon, Mar 21, 2011 at 2:05 PM, Ben Bangert b...@groovie.org wrote:
 On Mar 21, 2011, at 1:48 PM, Mike Orr wrote:

 Template has been a problem for years. Even if people can figure it
 out, it's cumbersome to write in documentation and tutorials where you
 have to explain that a template (skeleton) is not a template (file)
 although some of its files are templates. And the phrase application
 template is long and cumbersome when you have to repeat it many
 times.

 Ah, good point. I guess I'm too used to explaining things in person. ;)

 So any reason it *shouldnt* be called 'scaffolding' given its already a well 
 known name that people already associate with this exact thing? I mean, I can 
 see how 'blueprint' can technically be a more accurate term, but existing 
 re-use of the name and lack of anyone already associating it with this seems 
 like a point against it.

'Skeleton' is a long-established term in Unix where it refers to the
files initially copied to a newly-created home directory. That's an
exact analogue of what we're doing.

Scaffold or Scaffolding would be OK too, although I'd prefer the
shorter Scaffold. Scaffolding connotes the ad-hoc process of
constructing it individually for each building, while Scaffold
sounds like a product that remains the same over many uses, which is
how an app template works.

There's also that word Fixture that some people call a class that
acts as a framework for unittests.

-- 
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.

Re: WebHelpers conflict #63 and #59

[Mike Orr]

On Sun, Mar 20, 2011 at 6:38 AM, Wichert Akkerman wich...@wiggy.net wrote:
 New issue 63: Regression: paginate loads whole table when given
 SqlAlchemy object


 Yaiks - that change will effectively kill any site which does pagination
 over a large SQL table, so reverting it would be a good start. I don't see
 why the original line would raise that TypeError though. Did the bug
 submitter contribute a test to demonstrate that? It looks like he is
 strangely behaving collection type.

I reverted the patch in 556b55e75dd6, and implemented Marcin
Kuzminski's slice test posted to the bug report. Can somebody try
checking out WebHelpers dev and make sure it works in your
application, especially if you have some large tables to try it
against? I'll release 1.3b2 in a day or two after people have had time
to test it.

 
(https://bitbucket.org/bbangert/webhelpers/issue/59/webhelperspaginate-error-line-434)

Sprox objects appear to be unsliceable and therefore incompatible with
paginate. I also discovered that SQLAlchemy queries and selects also
don't have .__getslice__, but that's OK because their wrapper class
emulates it. So i had to move the slice check below the SQLAlchemy
check.

I wrote some unittests for various collection types, and discovered
there seems to be a bug with SQLAlchemy select objects.

 
https://bitbucket.org/bbangert/webhelpers/issue/64/paginate-sqlalchemy-select-test-fails

The wrapper's .__len__ returns the query's rowcount directly, which is
-1, which makes Python choke because len() isn't supposed to return a
negative number. The test is commented out but is
tests/test_paginate.py#TestSQLAlchemyCollectionTypes.test_sqlalchemy_select
. Christoph, can you try the test and see if the wrapper is buggy or
the test is wrong? I don't know how long it's been this way; maybe
nobody uses paginate with select.

https://bitbucket.org/bbangert/webhelpers/issue/64/paginate-sqlalchemy-select-test-fails

In the long term I think paginate should be refactored to eliminate
the pseudo-list layer. It makes it hard to tell what the backend is
doing, and how Python's special methods are interacting with it, and
how the collection's special methods may be complicating it further.
I'd like to replace the list-like wrappers with straightforward helper
classes that do their business directly and return a Page or the data
to construct a Page. The Page could remain a list subclass but it
would be fully static, not collection-aware. Furthermore I'd like
users to be able to provide their own helper classes for third-party
collection types. There have been patches to add PyMongo, CouchDB, and
now Sprox to paginate, but we can't add everything. Better to go with
autonomous helper classes. But this is a longer-term project, it's not
something I can do right now. Christoph, what do you think?

https://bitbucket.org/bbangert/webhelpers/issue/65/refactor-paginates-pseudo-lists

-- 
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.

Re: GSOC status

[Mike Orr]

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.

Re: GSOC status

[Mike Orr]

I started a list of potential GSOC projects.
https://github.com/Pylons/pyramid/wiki/Gsoc2011

I'm not sure how many ppl have write access to the wiki, but I'll add
anything I see mentioned on the list or that somebody emails me.

On Wed, Mar 16, 2011 at 12:51 PM, Chris McDonough chr...@plope.com wrote:
 Hi folks,

 I've been talking to folks for the last couple of weeks and it seems
 like we have at least four people (not including myself) who are willing
 to act in some measure as a GSOC mentor for the Pylons Project.

 We still need to set concrete goals of our students.  I'll try to work
 up some of that next week.

 If any potential students see this who are interested, in general, in
 participating in a Pylons/Pyramid-themed GSOC process, could you respond
 on the list and provide us with an idea of what you're interested in and
 your general skill level with Python and Pylons/Pyramid?


-- 
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.

Re: Pyramid 2 ideas

[Mike Orr]

There has been an ongoing discussion between the WSGI developers and
Twisted about how to be more compatible. The upshot is that
asynchronous servers need some kind of token in the output stream that
means I'm not ready; come back later. Other middlewares would have
to pass this token through unchanged. And of course, the application
would have to use non-blocking libraries such as non-blocking database
executors. I'm not sure if ordinary file access is blocking enough
to require that too.

The upshot has been that Twisted runs WSGI applications in a thread
anyway because it can't be sure they won't block. And there hasn't
been enough interest from WSGI developers to actually pursue using it
with asynchronous servers.

I think Python has a future object now which standardizes Twisted's
Deferred and the equivalent in other asynchronous servers. So that's a
start.

On Tue, Mar 15, 2011 at 2:05 PM, Vlad K. v...@haronmedia.com wrote:

 Speaking of asynchronous... what is the future of WSGI regarding
 asynchronous serving? With websockets (or whatever the standard will emerge
 out of it) coming fully supported in the next generation of browsers (what,
 within a year? two?), is this even a possibility for WSGI and with that
 Pyramid? Returning iterators as response objects? Gevent integration?


 .oO V Oo.


 --
 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.





-- 
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.

Pyramid 2 ideas

[Mike Orr]

In discussing with chrism and Ian Bicking porting Pyramid to Python 3,
it became clear that we might want to do some other changes at the
same time, enough to warrant a new major version, aka Pyramid 2. I've
outlined the ideas on the following wiki page:
https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm

These are just some ideas for discussion; we're not committing to any
of them at this point. If you have other ideas let's get them on the
list. Part of the reason for doing this is to determine which projects
we might want to offer to Google Summer of Code students.
Here's a summary of the ideas on the wiki page:

- Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below.
- Replace Paste, PasteDeploy, and PasteScript with something.
- paster create can be extracted to a new utility, either a
top-level script or a subcommand.
  The code could do with some modernization.
- paster create can likewise be extracted to a new utility.
- Rename application templates to application skeletons to avoid
confusion with file templates.
- Possible new names for Paster and its components: glue (Glue is the
new Paste!), Create, Serve, karnak.
- Extract PasteDeploy, loadapp, loadserver, BetterConfigParser; refine
code and give better names.
- Replace the INI file with an YAML file?
- Remove formal dependencies on Chameleon, Mako, and PasteDeploy in
Pyramid. Some of these are more properly dependencies of the specific
applications which are using them.

-- 
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.

Re: Pyramid 2 ideas

[Mike Orr]

On Sun, Mar 13, 2011 at 11:25 AM, Thomas G. Willis tom.wil...@gmail.com wrote:
 thanks for the info. i guess I'm thinking if you need something to support
 such a complex configuration that an ini file can't handle it, aren't you
 programming at that point and if so, why not use a real programming
 language? in java they does this stuff all the time. I know that the line is
 pretty blurry between code and configuration, but my guide has always been
 if it's versioned in your vc repo, it's code.
 just thinking out loud, but I like the simplicity of an INI other than that,
 python makes a nice dsl for that kind of stuff too, one of the few things I
 like about django is the settings.py(hate the import magic though)

There's nothing fatal about INI but it has three limitations:

- Can't express types other than strings. Can't express dicts/lists.
External routines have to parse these (asbool,
sqlalchemy.engine_from_config).

- Rigid two-level structure, can't express hierarchies.

- It's not really a multi-language standard as it claims to be: there
is no formal definition of which characters are allowed. I was
surprised when Paste started using keys containing ':'.

- Sucky ConfigParser (although it's improved in Python 2.7/3.2)

Its main advantages are:

- Less verbose than a Python module of scalar assignments, where you
have to quote the strings and can't have sections (unless you use
classes for them, but then you have the class keyword).

- Easier for sysadmins who don't know Python to maintain the file;
they don't have to learn Python quoting rules.

There's a feeling among some developers and many (but not all) users
that INI's disadvantages may be outweighing its advantages. YAML can
express all the things ppl wish the config file had. It can also
express a full ZCA configuration, which would allow the same file to
do app configuration, logging, and component configuration without
using ZCML.  That's what Marco was, a YAML-based version of
PasteDeploy. Its development was halted but parts of it could be
revived for a new tool.

-- 
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.

Re: Pyramid 2 ideas

[Mike Orr]

On Sun, Mar 13, 2011 at 11:08 AM, Alice Bevan–McGregor
al...@gothcandy.com wrote:
 Howdy!

 - Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below.

 This is not just a good idea, it's the slaw; with the ratification of PEP
  there finally exists a standard protocol for Python 3 support.

 - Replace Paste, PasteDeploy, and PasteScript with something.
 - paster create can be extracted to a new utility, either a
 top-level script or a subcommand.
  The code could do with some modernization.
 - Rename application templates to application skeletons to avoid
 confusion with file templates.
 - Possible new names for Paster and its components: glue (Glue is the
 new Paste!), Create, Serve, karnak.
 - Extract PasteDeploy, loadapp, loadserver, BetterConfigParser; refine
 code and give better names.
 - Replace the INI file with an YAML file?

 Marrow is my namespaced meta-framework rewrite of Paste, WebOb, and other
 utilities.

I'll add it to the list. Although I'm hoping to move away from
namespace packages, as Paste as done. They have already caused
practical problems in that you can't install part of a namespace
package as OS packages and part as virtualenv packages. We can't get
away from Zope's namespace package but I think we can avoid it where
it's unnecessary. Nevertheless I'll add Marrow to the list in case it
turns out to be the best meta-framework otherwise.


 * marrow.wsgi.objects (WebOb) request/response/exceptions

These are fully WebOb compatible? WebOb has become essentially the
only multi-framework Request/Response, so I dont' want to interfere
with it becoming a standard. It's easier to program in WebOb than raw
WSGI.

 - Remove formal dependencies on Chameleon, Mako, and PasteDeploy in
 Pyramid. Some of these are more properly dependencies of the specific
 applications which are using them.

 There exists a package called alacarte which offers a back-end agnostic
 templating interface.  It already supports Mako, Jinja2, and a handful of
 others, including serialization formats like JSON, Bencode, and YAML.  It
 was built to replace the ancient (and crufty) TurboGears 1 buffet API.

Does it require an entry point for each templage engine as Buffet
does? That's what we ultimately removed from Pylons because it was a
level of indirection and complexity that wasn't really necessary.

-- 
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.

Re: CSRF protection and session factories

[Mike Orr]

On Wed, Mar 9, 2011 at 11:24 AM, Stephen Lacy slacy+perso...@slacy.com wrote:
 In my form handling view, I'm using code that looks like this:

     if not request.session.csrf_valid(request.POST['csrft']):
         return HTTPInternalServerError()

This is popular but I'd use HTTPBadRequest (400). It's a client error
if the token is incorrect, not a server error. Otherwise it gives the
impression that a bug made the server crash, and the server logs will
say that too so you can't count how many hack attempts vs genuine
errors you got.

-- 
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.

Re: Some thoughts about Pyramid

[Mike Orr]

On Fri, Mar 4, 2011 at 12:11 AM, Chris McDonough chr...@plope.com 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 to change in the manual.

-- 
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.

Re: Some thoughts about Pyramid

[Mike Orr]

On Fri, Mar 4, 2011 at 9:39 AM, Chris McDonough chr...@plope.com 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 dependencies.  We could indeed make
 pyramid_chameleon and pyramid_mako and pyramid_paste packages to
 restore the functionality for users of those dependencies.

 Would that actually service any particular goal?  Would having fewer
 rails in the core actually make anybody happier?

I was -1 on splitting them but as I thought about it more I'm +0.
There's a benefit in distinguishing more between what Pyramid itself
needs and what the application templates need. If somebody is never
going to use Chameleon or Mako, or they detest PasteDeploy, why
install them? Especially if it causes problems in space-constrained
deployments. The user can't nullify a dependency without changing
other packages' setup.py files, and excluding packages manually that
then get re-added whenever somebody runs python setup.py install
because they think it will just bring the app up to date seems wrong.

If we do split them off, we should probably add a paragraph to the
templates' documentation saying this template uses X which provides
X, or all templates distributed with Pyramid depend on X which
provides X. That will keep people fully informed about what decisions
the templates are making for them, and what leeway they have to choose
alternatives.

-- 
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.

Re: Some thoughts about Pyramid

[Mike Orr]

On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis palexis2...@gmail.com 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 Django and Rails are really light and breezy...
 and link to the more-in-depth specialized docs and api docs.

 I feel more or less same, 'coz I was finding much difficulty in
 understanding the framwork from the document. Escpecially, the
 registration, configuration, the Z* things etc...
 The framework is so powerful, but lack of clean medium to get into it
 causing people to take U turn. It would be much better if we can re-
 arrange/modify the documents in a way to take out Z* things, traversal
 and all complex topics to 'Advance' section seperately.

This is where Pyramid's multiple goals come into play. The BFG-ish
users say that Traversal was immediately understandable to them and
they could apply it right away, while they find URL Dispatch
cumbersome.

ZCML configuration was moved to the back of the manual for exactly the
reason you describe, because it was a stumbling block for the large
number of Pylons users who were about to come, and the BFG users knew
where to find it in the back of the manual. I'd support moving
Traversal to the back except I think there'd be more resistance to
doing that than there was for ZCML. Traversal is central to an
application if you're using it, whereas ZCML is just zis
configuration format, y'know. [voice of Zaphod Beeblebrox's
psychiatrist]

-- 
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.

Re: Some thoughts about Pyramid

[Mike Orr]

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 bla...@laflamme.org wrote:
 I'm up too

 On Mar 3, 8:09 pm, Carlos de la Guardia carlos.delaguar...@gmail.com
 wrote:
 Guys,

 I'll be at PyCon and would like to sprint on this. Maybe a tutorial
 with code. Anyone?
-- 
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.

Re: Some thoughts about Pyramid

[Mike Orr]

On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde syr...@gmail.com wrote:
 On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr sluggos...@gmail.com 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 who would like to stand up?


 I'm generally a lurker, and am currently overwhelmed with other
 projects, but I do have some suggestions in this area and would be
 glad to help contribute to marketing efforts as time allows.

Will you be at PyCon?

There will undoubtedly be Pyramid/WSGI related Open Spaces every day
at the conference; or at least there have been the past two years. So
for those who can't attend the sprints, please stop by an open space
and say hi.

-- 
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.

pylons-discuss and pylons-devel

[Mike Orr]

On Thu, Mar 3, 2011 at 11:44 AM, Mike Orr sluggos...@gmail.com wrote:
 On Thu, Mar 3, 2011 at 1:03 AM, drebbin dirkyd...@gmx.net wrote:
 Hi all,
 I am joining this community because of an interest in Pyramid -- about which
 I had posted an issue in the pylons-devel list. Now I notice that that list
 is only scarcely visited, contrary to this list, and am a bit confused.
 Where shall I post n00b questions of a seasoned programmer ;) ?

 Now that Pyramid 1.0 is released, this is the place for Pyramid
 questions. In alpha development we were using pylons-devel to avoid
 confusing those who were new to Pylons 1 and couldn't tell the
 difference between Pylons questions and Pyramid questions. Now that
 Pyramid is properly documented and supported, that issue has gone
 away.

Here's generally what pylons-discuss and pylons-devel are for.

pylons-discuss:

- Questions from users at all levels, from newbie to advanced, on both
Pyramid and Pylons 1. Including usage questions about their
dependencies and libraries commonly used with them, and general web
development questions encountered when using Pyramid or Pylons.

- Changes in the frameworks that affect the application API or
performance, especially those that raise backward-compatibility
issues.

- (In Pyramid's case, the changes were so large and it was unstable
for so many months, that an overview was posted to pylons-discuss, but
not every detail while it was unstable.)

pylons-devel:

- Discussions that only framework developers care about. This list
mainly exists so that those who don't care about internal framework
issues (i.e., regular application developers) can avoid subscribing to
it.

- Topics include implementation details, minor bug reports, trivial
information, wild-eyed proposals that may not be approved (or that you
want to refine and bake before announcing to the userbase), etc.

-- 
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.

Re: Some thoughts about Pyramid

[Mike Orr]

 it. But
eventually I realized that Quixote just didn't have certain features I
needed, and I switched to Pylons.

Re auth, there is some ambiguity because some people are recommending
the built-in auth while others are using repoze.who/what. Generally,
the built-in auth is simpler, and not being middleware makes it more
straightforward.  But repoze.who has more authentication mechanisms
out of the box. Eventually there will be patterns for combining the
two, or a simpler successor to repoze.who that's aware of the built-in
auth will emerge.

The Pyramid manual and the migration guide are necessarily geared
toward the majority users who come from a BFG or Pylons background.
Those users are comfortable with Paste and have been using it for five
years, so that's what the standard application templates recommend.
There have been calls over the years to replace Paster, but no clear
idea on what to replace it with, or assurance that anything else would
be sufficiently better. Paste's creator, Ian Bicking, has been
spinning off packages out of Paste (WebOb, WebError), and expects that
eventually all of Paste will be spun off or left to die. But there has
been little effort to replace PasteDeploy or PasteScript because they
basically work.

-- 
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.

Re: pyramid_tm 0.1 released

[Mike Orr]

On Sun, Feb 27, 2011 at 10:28 PM, Chris Withers ch...@simplistix.co.uk wrote:
 On 26/02/2011 10:18, Wichert Akkerman wrote:

 We had a mini-discussion on this topic on irc this week. The only
 difference between the two is that repoze.tm2 uses middleware, while
 pyramid_tm uses pyramid events.

 Personally I am a bit worried about a trend to move away from reusable
 WSGI middleware to pyramid-specific approaches, especially when there
 appears to be no functional benefit.

 Indeed. Thanks for the clarification, I'll definitely stick with repoze.tm2
 then.

I haven't looked at pyramid_tm closely enough to tell whether it'll
work for pyramid_sqla, but the fact remains that WSGI is a clunky
protocol for services, and a non-middleware solution would be welcome.
The protocol is good for web servers and non-data services like error
handlers, but it forces a distortion in libraries that share data with
the application because you can't just call things directly, you have
to shoehorn the data into one dict or the HTTP headers, and any
interaction in views has to be via callback objects in the dict. It's
ironic that Jim Fulton used to complain that using middleware for data
services was an abuse of the protocol and framework/application
developers ignored him, but now after five years of use framework
developers are coming to the same conclusion for a different reason:
the WSGI protocol is just too artificial and rigid to use for data
services. You see that especially in repoze.who/what, which are overly
complex partly because of their middleware nature, and to an extent
Routes too.  Generic reusable code is a good thing but it doesn't have
to be middleware. The various form libraries are reusable but they
aren't middleware.

-- 
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.

Re: paginator/batcher for use with Pyramid

[Mike Orr]

Paginate works with Pyramid, with the caveat that if you use the
Page.pager() method, you have to pass a custom URL generator to the
constructor as described on the webhelpers.paginate page.

I'm working on a variation that won't have this restriction.

On Thu, Feb 24, 2011 at 7:03 AM, Renato Pereira
renato.ppon...@gmail.com wrote:
 Hi Chris,

 I don't know if is recommended, but I use webhelpers[1]. It's pretty
 easy to use. =]


 [1] http://webhelpers.groovie.org/

 On 02/24/2011 08:38 AM, Chris Withers wrote:
 Hi All,

 What's the recommended paginator/batcher for use with Pyramid?

 cheers,

 Chris


 --

 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

 Renato de Pontes Pereira
  - Membro opensuse - http://en.opensuse.org/User:Renatopp
  - http://renatopp.wordpress.com
  - @renatopp - twitter
  - renatopp - irc

 --
 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.





-- 
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.

Re: paginator/batcher for use with Pyramid

[Mike Orr]

On Thu, Feb 24, 2011 at 10:57 AM, Ben Bangert b...@groovie.org wrote:
 On Feb 24, 2011, at 9:43 AM, Gael Pasgrimaud wrote:

 On Thu, Feb 24, 2011 at 6:37 PM, Mike Orr sluggos...@gmail.com wrote:
 Paginate works with Pyramid, with the caveat that if you use the
 Page.pager() method, you have to pass a custom URL generator to the
 constructor as described on the webhelpers.paginate page.


 Can't we have a default pyramid generator (and well, webob based
 frameworks) in WebHelpers who use the request.path to generate the url
 ?

 So you can use Page.pager(request=request)

 Yep, that was the thought for the next iteration.

That's something I hadn't seen, passing a (WebOb-compatible) request
to the pager method rather than to the constructor. That might be a
solution.

 Also, to require the object being paginated to support the Python sequence 
 API, so that the hacky code that tries to deal with various SQLA things isn't 
 needed. Ie, there'd be some sequence wrappers for SQLA query objects vs. a 
 bunch of if/else code toggling it inside the paginator.

I still need to see a more concrete version of what you're thinking
of. The paginator already treats the collection as a sequence as much
as possible.

Also, you were talking about a way to fetch one more record than
required, and using the extra primary key as the starting point for
the next page to avoid the OFFSET clause which is inefficient (because
it has to cycle through all the records before this page). I tried to
do this but I don't see how it would work.

1) We can't figure out which record number we're on without cycling
through the previous records, because it changes depending on the
WHERE clauses.

2) The user would have to pass in the name of the primary key field.

3) You'd have to transmit the last primary key to the next request as
a query param.

2 and 3 are doable, but I don't see how to do 1 without passing a
bunch of state variables to the next page, and the pager may go out of
kilter if these aren't calculated correctly for the receiving page.

-- 
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.

Re: paginator/batcher for use with Pyramid

[Mike Orr]

On Thu, Feb 24, 2011 at 2:20 PM, Chris Withers ch...@simplistix.co.uk wrote:
 On 24/02/2011 19:10, Mike Orr wrote:

 On Thu, Feb 24, 2011 at 6:37 PM, Mike Orrsluggos...@gmail.com  wrote:

 Paginate works with Pyramid, with the caveat that if you use the
 Page.pager() method, you have to pass a custom URL generator to the
 constructor as described on the webhelpers.paginate page.

 Okay, I take it the examples that are out there for this still hold true?

The Pyramid example I mentioned in an earlier thread (about a month
ago) should work. I don't have the syntax in front of me. You have to
create a function that returns the correct URL when called like this:

func(page=4)  =  /url/for/myarticle?page=4

 So you can use Page.pager(request=request)

 Yep, that was the thought for the next iteration.

 That's something I hadn't seen, passing a (WebOb-compatible) request
 to the pager method rather than to the constructor. That might be a
 solution.

 Does that work now or is it something for the future?

Future. The 'request' arg isn't recognized at present.

 What if the primary key is not numeric?

That doesn't matter.

 to avoid the OFFSET clause which is inefficient (because
 it has to cycle through all the records before this page).

 This I don't follow, lack of relational knowledge.
 I presume you mean the OFFSET is slow on the server?

That's what Ben says. But it's what everybody has been doing, and it's
not slow in my applications.  (MySQL, with a high-grade CPU and plenty
of memory)

 1) We can't figure out which record number we're on without cycling
 through the previous records, because it changes depending on the
 WHERE clauses.

 I don't follow this, can you give a simple example?

Say you have a hundred records numbered 1 to 100, and you're paging
ten at a time. Page 3 is records 20-39, and the number of skipped
records (the OFFSET) is 20 (#1-19).

But if you add arbitrary conditions, like show only records that were
modified on a Thursday and have an address (a relation to another
table), then the offset size will probably be less than 20. But how
much less we don't know unless we run the complete query. So if you
click on a page link

/article?page=4last=39

That 'last' doesn't really tell you anything because you still have to
run the whole query to figure out which relative record number you're
at.  (Otherwise ``page.first_item`` and ``page.last_item`` would be
unknown, and you wouldn't be able to say Showing records 29-39 of
100.)

The only way around that is to pass several more pieces of state data
in the query string, and that's where I worry about miscalculating or
the pages getting out of kilter.

 2) The user would have to pass in the name of the primary key field.

 To where?

To the Page constructor. It has to know which field to look at to
determine what the last primary key value was.

 Now, anyway, back to the problem at hand for me.
 As it happens, I am looking to paginate the results fairly simple SA query:

 session.query(MyModel)

 What's the most efficient way I can do that with currently available
 software?

 What version of webhelpers should I use? Are there any changes to the query
 I should make to make it more efficient?

Just follow the WebHelpers instructions, and define a URL generator
callback to pass.

WebHelpers 1.2 is the current version and has been stable since last August.

The current code uses OFFSET, but there's no way around that at the
moment. And we're not sure if a more efficient algorithm is feasable
anyway. At least for SQL databases. CouchDB may have its own special
features.

-- 
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.

Re: paginator/batcher for use with Pyramid

[Mike Orr]

On Thu, Feb 24, 2011 at 4:20 PM, Mike Orr sluggos...@gmail.com wrote:
 2) The user would have to pass in the name of the primary key field.

 To where?

 To the Page constructor. It has to know which field to look at to
 determine what the last primary key value was.

Er, it would have to do that if the proposed algorithm is implemented.
Currently there is no primary key arg.

-- 
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.

Global variables

[Mike Orr]

On Wed, Feb 9, 2011 at 2:46 PM, Tres Seaver tsea...@palladion.com wrote:
 One bit I noticed: In
 https://bytebucket.org/sluggo/pyramid-docs/wiki/html/migration.html#app-globals-and-cache,
 you state::

  You can also use ordinary module globals or class attributes,
  provided you don’t run multiple instances of Pyramid applications in
  the same process. (Pyramid does not encourage multiple applications
  per process anyway. Instead Pyramid recommends its extensibility
  features such as its Zope Component Architecture, which allow you to
  write pieces of code to interfaces and plug them into a single
  application.)

 Pyramid actually goes out of its way to make running multiple apps in
 the same process work:  in fact, it uses the ZCA in a way which means
 that registrations made in one app's configurator won't interfere with
 those made in another app's configurator.  Perhaps the docs need to show
 an example of such a setup, but it is quite supported.

 Some of us *do* write apps that expect to be extended / reconfigured via
 the ZCA registry, but Pyramid itself doesn't mandate that (or even
 document it all that well).  If such an app uses the global ZCA APIs,
 it won't benefit from Pyramid's segregated registries, but that is no
 different from use of any other global (module- or class-scope
 variables, etc.)

I just got back from my trip. So what's the official recommendation
for arbitrary global variables? I just wrote what I thought would be
safe. But people have their database connections and other things
they'll have to put somewhere. Should I say to put them all in the
registry? Under Settings? As module globals?

If they do want to put something into the registry, what's the syntax?
Can you just assign an attribute in 'registry'?

-- 
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.

Pyramid Migration Guide, first draft

[Mike Orr]

Here's the first draft of my Pyramid Migration Guide. It's an
introduction to Pyramid for Pylons 1 users, comparing the two
frameworks feature by feature. This is a first draft so it may  have
inaccuracies people will report in the next few days. And a few
sections at the end aren't written yet. But for what it is, it can
serve as an introduction to the Pyramid manual if you're finding the
vocabulary confusing or the details overwhelmingly many.

It focuses on the pyramid_sqla application template in the
pyramid_sqla package, which is the most Pylons-like template.

I'll be out of town next week (Mon-Fri) and I may leave my computer at
home, so if I don't reply for a few days that's why.

Finished sections: vocabulary, Paster, INI file, models, view
handlers, routing (and a minimal overview of traversal), request
object, templates, static files, session (flash messages and secure
forms), webhelpers, shell, deployment.

Not yet written: testing, forms, authorization, other Pyramid features
(overview of events, hooks, extending/ZCA, ZCML). There's an
internationalization section but I don't know enough about the topic
to write it myself.

Online version:
https://bytebucket.org/sluggo/pyramid-docs/wiki/html/migration.html
Sphinx source:  https://bitbucket.org/sluggo/pyramid-docs/src

This is part of my Pyramid Supplemental Docs project. It will
eventually be on github and in the Pyramid docs, but first I wanted to
get it written.

Replies to pylons-devel if it's a minor bug report or comment or
Pyramid usage issue, or to pylons-discuss if you think it's important
to all Pylons users.

-- 
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.

Re: Pyramid 1.0b3 released...

[Mike Orr]

On Fri, Jan 28, 2011 at 10:52 AM, Christoph Zwerschke c...@online.de wrote:
 Am 28.01.2011 17:51 schrieb Mike Orr:

 On Fri, Jan 28, 2011 at 8:13 AM, Chris McDonoughchr...@plope.com  wrote:

 - Paster templates and tutorials now use tabs instead of spaces in their
  HTML templates.

 Tabs??? Hasn't everybody switched to spaces instead of hard tabs in
 Python programming? Most people's editors are set to four-space tabs.

 He was talking about HTML templates, not Python code. For HTML, tabs make
 some sense, as the page size gets a bit smaller.

Well, eliminating all non-functional whitespace would make the page
size even smaller. I'm just concerned that it'll make the pages
inconvenient to edit. (Must use tabs here to avoid inconsistency, but
not in other files.)

I did notice an extreme vacuuming of whitespace in pylons.css. And it
defines styles for all sorts of obscure tags that seem to be already
the default and don't make much difference. And also, it was
referencing Google fonts for some reason, which which was causing a
slight rendering delay on my system. It didn't seem to use the Google
fonts but it was causing a slight rendering delay, so I took the font
line out for pyramid_sqla but left the rest of the file. I'm not sure
that stylesheet is a useful basis for a user application (I want my
h3 font size exactly 1.25em, and I must have these specific fonts),
but if it supports the default page and I don't have anything
particular that would be better, I figured might as well leave it in.

-- 
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.

Re: Form handling in Pyramid

[Mike Orr]

How does Pyramid handle HTTP method tunneling? Where the formal method
is POST and the actual method is in a '_method' param? it's not really
a form library issue because you'd want it uniform across all
libraries. How does Pylons do it? Is it in WebOb? Is it something we
need to add?

-- 
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.

Re: Form handling in Pyramid

[Mike Orr]

On Fri, Jan 21, 2011 at 11:55 AM, Mike Orr sluggos...@gmail.com wrote:
 How does Pyramid handle HTTP method tunneling? Where the formal method
 is POST and the actual method is in a '_method' param? it's not really
 a form library issue because you'd want it uniform across all
 libraries. How does Pylons do it?

Pylons does it in the Routes middleware
(routes.middleware.RoutesMiddleware). There's a constructor arg
'use_method_override', default true.

-- 
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.

Re: Form handling in Pyramid

[Mike Orr]

On Fri, Jan 21, 2011 at 12:38 PM, Chris McDonough chr...@plope.com wrote:
 On Fri, 2011-01-21 at 12:30 -0800, Mike Orr wrote:
 On Fri, Jan 21, 2011 at 12:15 PM, Chris McDonough chr...@plope.com wrote:
  config.add_view(some_method)
  config.add_view(some_method_PUT, request_method='PUT')
  config.add_view(some_method_PUT, request_method='POST',
  request_param=_method=PUT)
 
  True, I guess we handle it already by default, so unless there's some
  usage pattern I don't understand (likely), we don't really need to argue
  about supporting it or not.

 We at least need to document it as a FAQ, and mention it in the
 routing section and view section.

 It could and probably should be a cookbook entry.

 This syntax does make the routes less straightforward (they show the
 low-level details rather than the high-level intention). If the
 application is expecting both tunneled PUT and direct PUT, it will
 have to accomodate both possibilities. And views will also have to
 handle tunneled PUT themselves because it won't be converted.
 (Although that could be done in the view handler .__init__, but that's
 kind of a band-aid approach because it covers only the views and not
 the routes.)

 What is the distinction you're trying to make between PUT and
 tunneled PUT?  Are you saying that a view should return something
 different to a browser client than to a non-browser client based on
 whether the _method param exists?

I'm saying that a PUT-capable client will send a real PUT, while a
browser will send a tunneled PUT.  The difference may come down to
whether Javascript is enabled in the browser thus allowing an Ajax
request, with a fallback using an HTML form for non-Javascript
browsers. If the view and routing are expecting only one kind of PUT,
they may mishandle the other kind. It's easier to just convert the
request than to explain the problem to application developers.

-- 
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.

Re: Pyramid 1.0a10 released

[Mike Orr]

On Thu, Jan 20, 2011 at 2:49 PM, Wichert Akkerman wich...@wiggy.net wrote:
 On 2011-1-20 19:49, Mike Orr wrote:

 On Thu, Jan 20, 2011 at 2:43 AM, Eric Lemoine
 eric.lemo...@camptocamp.com  wrote:

 On Thu, Jan 20, 2011 at 11:02 AM, Wichert Akkermanwich...@wiggy.net
  wrote:

 Does pyramid_sqla have any documentation? I couldn't find anything on
 pypi
 or pylonsproject.org.

 It's linked onhttp://pypi.python.org/pypi/pyramid_sqla/0.1.

 https://bytebucket.org/sluggo/pyramid_sqla/wiki/html/index.html

 Bitbucket doesn't have a good place for documentation so I put it in
 the project wiki. Static files in the wiki have this different URL
 (bytebucket.org). I may set up a site on docs.python.org at some
 point.

 Could you turn it into sphinx docs so it can be added to pylonsproject.org
 along with the other docs? That would make the package and its documentation
 more accessible.

It is Sphinx docs. I just haven't gotten the hang of Git yet.

-- 
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.

Re: Pyramid 1.0a10 released

[Mike Orr]

On Tue, Jan 18, 2011 at 12:33 PM, Chris McDonough chr...@plope.com wrote:
 Pyramid 1.0a10 has been released.

 - The add_handler method of the Configurator has been
  externalized.  When you upgrade to Pyramid 1.0a10,
  the add_handler method will stop working.  To make it
  work again, add a dependency named pyramid_handlers
  to your Pyramid application's setup.py install_requires
  list, or install pyramid_handlers by hand.  Then follow
  the instructions described at
  http://docs.pylonsproject.org/projects/pyramid_handlers/dev/#setup

  Once this step is accomplished, config.add_handler will
  work again.

Released pyramid_sqla 0.2 to reflect this.

Applications made with pyramid_sqla 0.1 will not work with 1.0a10
until you apply this change.

-- 
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.

Form handling in Pyramid

[Mike Orr]

 approach with @validate even for
non-REST forms. I think it would be best to support both approaches,
two-view and one-view.

One thing I was concerned about in pyramid_simpleform
(http://packages.python.org/pyramid_simpleform/) is that the view
handler has the form view and submission view that look almost the
same. It's like one could go to either URL? What's the purpose of
this, and how does it handle the case of failed validation?

Anyway, if you have any ideas on what should be in the Pyramid-Pylons
form howto (which will probably be the Pyramid form howto too, since
there isn't one of those I could find), now's the time to speak up.

-- 
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.

Pyramid for Pylons users guide

[Mike Orr]

Hi all, I'm starting an article on Pyramid for Pylons 1 users,
focusing on the differences between the frameworks and how to do
familiar things in Pyramid. It'll also cover add-on stuff like forms
and auth, or at least list the alternatives available.

I'm wondering if there are any particular questions people would like
included. If so, please email them to me.

-- 
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.

Re: Serving static index.html from /

[Mike Orr]

On Wed, Jan 5, 2011 at 10:23 AM, Dominik d.roettsc...@gmail.com wrote:
 Hi Chris,

 We have a cookbook in the works that describes how to do something
 like this.  Here's a sneak peek:

 http://plope.com/static/pyramid_cookbook/static.html#root-relative-cu...

 Yes, thanks - I found something similar in the Serving Static Assets
 documentation [1]. However, if I understood correctly, this still
 wouldn't help for the standard case of responding to request to /
 with the static index.html, like apache does for example for
 index.htm(l)/php/cgi etc. Any ideas?

 The whole static stuff seems very hacky for me, examples:
 1) from the same page: [1] The special name *subpath above is used by
 the pyramid.view.static view callable to signify the path of the file
 relative to the directory you’re serving.
 2) The special purpose of the name attribute of the static view.
 3) The double meaning of add_static_view depending on the first
 parameter (i.e. in the external host case)

 I wish this would be cleaned up some day, more consistent and more
 intuitive to understand.

I'm testing an application template that serves static files from /
and has a SQLAlchemy configuration (coming soon). This is working for
me:

from pyramid.view import static

# Set up routes and views
config.add_handler('home', '/', '{{package}}.handlers:MainHandler',
   action='index')
config.add_handler('main', '/{action}', '{{package}}.handlers:MainHandler',
path_info=r'/(?!favicon\.ico|robots\.txt|w3c)')
config.add_route('static', '/*subpath', static('{{package}}:static'))

The first line is a regular home route for /.

The second line handles /{action}, but it has to exclude top-level
static files which would be mistaken for actions. (The path_info regex
doesn't match /favicon.ico, /robots.txt, or /w3c.)

The third line is a catchall route for all other URLs, which goes to
the static directory. The static() function creates a static view. But
Chris has said this will disable traversal, so I need to make a route
predicate function so that the route matches only if the file exists.
But if you don't need traversal, you can use this as-is.

-- 
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-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.

Testing an application template

[Mike Orr]

Chris, How do you test an application template in Pyramid? You said
you had unit tests for them, which I didn't think was feasable. But I
don't see any test module that does it, not test_paster or
test_testing or test_scripting which seemed closest. But I do see
several premade applications in the tests directory, which don't seem
to have their own tests. Are these apps for other tests to use?

-- 
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-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 1.0a8 released

[Mike Orr]

On Thu, Dec 30, 2010 at 9:17 AM, Seth seedifferen...@gmail.com wrote:
 Thanks for all the input and I suppose Marius' answer is the most
 straightforward solution. Perhaps I was expecting something a little more
 like Mike's category style implementation, b

Credit to Eli Collins for the implementation.

 but I can see how that could
 become too much complexity for too little value.
 With regards to the peek_flash method: If one is using a templating system
 that allows python code in the template logic, this would likely be
 unnecessary; but for templates that only give you basic stuff like loops,
 tests, and prints, the peek method is needed for truth testing and multiple
 non-loop prints (i.e. printing different key/value pairs as in Marius'
 example).

My first reaction is it's inefficient, but that's just because of the
WebHelpers situation. In Pyramid it's a just a session.get(KEY, []).
In WebHelpers it creates a list of Message instances. (The messages
are stored as a tuple in the session, because Eli said object
unpickling may be unreliable in edge cases.)


-- 
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-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 1.0a8 released

[Mike Orr]

On Wed, Dec 29, 2010 at 1:28 PM, Marius Gedminas mar...@gedmin.as wrote:
 On Wed, Dec 29, 2010 at 10:56:29AM -0800, Seth wrote:
 The docs say that messages don't have to be strings, so you can do
 exactly that, if you push dicts like this:

  request.session.flash(dict(message='Hello!', queue='welcome')).

 Or you could push tuples.  Or a custom subclass of unicode with a
 'css_class' attribute -- just make sure it's pickleable.

Hi there. I wrote the flash code for WebHelpers, then somebody (I
can't remember who) asked for categories and we expanded it, then I
adapted it forPyramid's central session object, and Chris modified it
to the current version. It has multiple queues because the WebHelpers
concept of multiple Flash objects is non-viable with the flash
integrated into he session. I initially kept categories, but then
Chris and I decided to drop them because queues cover almost the same
purpose. The only thing you can't do without categories is to mix them
(i.e., display an INFO then DEBUG then ERROR then INFO, in whatever
order the messages were pushed). It seemed unlikely people would want
to do that anyway for web display; rather they'd want to show all the
errors first, then the infos, then the debugs, which you can do with
multiple queues.

The messages are intended to be strings, but this is not enforced. I
couldn't think of any specific use case for non-string messages, but
users always come up with unanticipated uses so I didn't want to
prevent those. (Queue names have to be strings because they're
concatenated to a constant string to create a session key.)

If there's a need for additional features, we can consider adding
them. I'm not sure what Seth is asking. a method which returns *any*
flash message from any queue. So you want the messages returned in
creation order tagged with their queue name? This would be the same as
categories which I described above, which is not implemented because
it seemed like too much complexity for too little value. It sounds
like Marius' suggestion is a suitable workaround, using one queue and
pushing an object that contains both a message and a category. I think
you can build a higher-level API to make that convenient. If you need
some kind of helper method or something in the core, let us know and
we'll consider it.

PS. Chris added the '.peek_flashes' method. I didn't see the use for
it, but again it's there for unanticipated use cases. I usually do if
peek_flashes; for msg in pop_flashes as % messages =
request.session.pop_flashes() %  %if messages: .

-- 
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-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.

route_url and query params

[Mike Orr]

request.route_url() doesn't convert extra args to query params. Is
this intentional? If so, it's another difference from pylons.url().

$ paster pshell development.ini Zzz
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type help for more information. root is the Pyramid app root object.
 req = pyramid.threadlocal.get_current_request()
 req.route_url(main, action=pony)
'http://localhost/pony'
 req.route_url(main, action=pony, horn=1)
'http://localhost/pony'
 req.route_url(main, action=pony, horn=1)
'http://localhost/pony'

-- 
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-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: Pylons , Pyramid which is better

[Mike Orr]

On Tue, Dec 28, 2010 at 10:33 AM, AbdAllah Ahmed
abdallah.a7...@gmail.com wrote:
 Hi, I Asked this qeustion before in StackOverFlow but i'm still
 missed :

 Now there is Pylons 1.0  and Pyramid alpha release  and TurboGear will
 be apart of Pylons

 Will Pylons Continue after the final release of pyramid 1 or not ? ,

Pyramid is the new name for Pylons 2. Pylons 1 will have bugfixes and
security fixes and some feature backports from Pyramid, but whether it
will add features depends on if somebody wants to do the work.

The Pylons, BFG, and TurboGears projects have merged under the name
the Pylons project. The codebase comes from BFG with Pylons and TG
features added on.

 whcih is better ? , what are the differences ?

That's a long answer. Pyramid has a more flexible architecture, but
it's still in alpha and it's definitely a transition for Pylons users.
There is not yet a point-by-point comparison between the two. Look
over the pylons-devel and pylons-discuss archive and the main
differences will emerge. (Keep in mind that messages in early November
were from when Pyramid was brand new, so some of the things said about
it are either out of date or inaccurate.)

-- 
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-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 1.0a8 released

[Mike Orr]

On Tue, Dec 28, 2010 at 2:48 PM, Seth seedifferen...@gmail.com wrote:
 Chris,
 My apologies, the 2nd issue was because I took
 out config.begin()/config.end() from my unittest setUp/tearDown methods
 because I thought they were no longer required. Adding them back causes the
 tests to pass.

I thought they were obsolete too, but the application templates still
have them in the tests. So are they obsolete or not?

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

[Mike Orr]

On Fri, Dec 17, 2010 at 10:09 AM, Christoph Zwerschke c...@online.de wrote:
 Am 17.12.2010 15:42 schrieb Graham Higgins:

 For example, model graph (used in the Pyramid docs) suffers from
 the same difficulty as does little baby. It unnecessarily
 complicates the narrative with a tautological conceptual entity.

 This btw is another reason why I don't like the term model. Some people
 seem to use it for the whole graph or database scheme, others seem to use it
 for a single node or entity.

That's another issue. :) To me and MVC, the model is the entire
structure of domain logic. To Django, GAE and Simpycity, it's a class
representing a table. Pyramid has veered toward the latter with
models.py. But when we considered changing it tomodel as Pylons
does, it became clear that symmetry with handlers.py, views.py,
and templates --all plural -- was more important than defining what
exactly is encompassed in a single model.

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

[Mike Orr]

By the way, I earlier suggested reorganizing the manual to put the URL
Dispatch chapter first and then the Traversal and Hybrid chapters.
Putting Traversal first is a significant stumbling block for those who
aren't used to it. The outline I suggested is here:

http://groups.google.com/group/pylons-devel/browse_thread/thread/51ad2c8713924798/b0f1c3e93ba0b571

I also think the Unix example has to go. Don't focus on what the dumb
Unix user doesn't know. Just say, We look up things like a filesystem
does, so when we specify /a/b/c, it consults the root directory to
find a, then it sees that a is a directory so it consults it to
find b, then it does the same with b to find c. AFAIK the Unix,
Mac, and Windows filesystems all work like this.

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

[Mike Orr]

On Thu, Dec 16, 2010 at 8:57 PM, Mark Ramm mark.mchristen...@gmail.com wrote:
 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.

+1 for Resource Tree. That's also more understandable than directed
acyclic graph, which sounds like mysterious Computer Science mumbo
jumbo.   Everybody understands a directory tree, and most people
understand nested dicts.

 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.

+0

-- 
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-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.

Static files

[Mike Orr]

How can I serve static files without using the /static prefix? Most of
my files are in images/, stylesheets/, and javascripts/ directories
which can go under /static if necessary, but favicon.ico, robots.txt,
and w3c (for machine-readable privacy policy) can't.

config.add_static_view(static, inews:static/;)
config.add_static_view(favicon.ico, inews:static/favicon.ico;)

This seems to ignore the latter, and I get 404 Not Found
predicate mismatch for view function MyHandler at 0x9a31454.

config.add_static_view(static, inews:static/;)
config.add_static_view(/favicon.ico, inews:static/favicon.ico;)

What I'd really like to do is have a static overlay over / after the
other handlers have failed to match. In production I'll be serving the
static files by Apache anyway, but in development I need the
application to serve them.

config.add_static_view(, inews:static/;, context=NotFound)

This doesn't work, same error as above.

I could do it outside Pyramid in a development.ini pipeline, but then
what good is add_static_view?

-- 
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-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 project templates

[Mike Orr]

There are a few limitations with putting the dbsession and initialize
function in a  package:

1) The model is no longer autonomous. A Pylons model can be imported
and used on its own, even if the rest of the application or Pylons has
some error that makes it unusable. A db utility can simply create an
engine, pass it to init_model(), and not worry about anything else.

2) If people have multiple databases, they may want to bind certain
tables to certain databases in the Session. In Pylons they can modify
init_model() to take two engines and configure the session. In Pyramid
they'll have to copy the pyramid_sqla code into their application and
modify it. This is not insurmountable, and anyone who's using multiple
databases should be prepared to do this, I'm just pointing out it's a
limitation. AFAIK, you can't just add binds to a session while leaving
the existing binds in place, you have to pass a dict of all the
bindings. Likewise, we could allow multiple prefixes in
initialize_sql() which could create multiple engines, but then what
would we do with the engines?

3) There are really several ways to structure large apps with multiple
databases, such as multiple session objects as Ben last  described. I
don't think we can adequately prepare for all of them, because I for
one can't predict what they all will be. So maybe we should just
handle the simple case, and tell the user to make a Pylons-like
structure if they have a complex case.

4) Standalone utilities may want to pass an engine to initialize_sql()
rather than creating a fake settings dict. We can handle this by
checking if the first arg is inherited from sqlalchemy.Connection,
otherwise assume it's a settings dict. An  alternative would be to
have multiple initialize functions for different situations, although
I can't think of a good name for init_for_engine().

-- 
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-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: URL dispatch vs traversal

[Mike Orr]

On Tue, Nov 23, 2010 at 8:00 PM, Chris McDonough chr...@plope.com wrote:
 On Tue, 2010-11-23 at 19:35 -0800, Mike Orr wrote:
 I wonder if it would be clearer to to put the URL Dispatch chapter
 before Context Finding and Traversal in the manual. URL Dispatch seems
 to be simpler, and it doesn't require learning about the root object,
 context object, and context finding only to learn you won't be using
 them. It seems like URL Dispatch can be presented in a way that people
 will see immediately if they're not using it, without having to pore
 through the abstract concepts of context finding and view lookup.
 Then if they want to use traversal or learn about these objects, they
 can learn about them afterward, otherwise they can skip those two
 chapters.

 I sympathize with this, and I think we can probably organize it better.
 Casey Duncan is currently working on editing the book as a for-pay sort
 of thing.  I'm hoping he'll come up with some concrete suggestions as to
 how to reorganize things, but maybe I can put a bug in his ear along the
 lines of your suggestion.

 FTR, it would be more technically accurate to say that users *will* be
 using a root object, a context object, and context finding when he uses
 URL dispatch, but he can mostly ignore their existence.  URL dispatch
 literally is a context finding mechanism.  This is why the docs are
 organized as they are now.

 OTOH, users do indeed need to know about view lookup even if they only
 use URL dispatch.  A matched route doesn't always imply the lookup of
 one single canonical view.  For example, if a route matches, it might go
 to one view if the request method is POST, another if the request method
 is GET.

OK, I think we can handle this in a short paragraph at the beginning
of the URL Dispatch chapter. Just quickly explain in passing what
these are and that the'll be covered more in depth in the following
chapters.  Currently the Context Finding and View Lookup chapter and
the Traversal chapter are the most confusing parts of the manual to
Pylons users; they make the framework seem foreign and hard to grasp.
You have to make your way through nine dense paragraphs and a section
on which mechanism to use, and then if you start reading the traversal
chapter anyway it gets hard to follow with all these new concepts. I
think traversal fans can skim over the URL dispatch chapter easier
than people coming from a Routes background can skim over the two
other chapters.


-- 
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-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 project templates

[Mike Orr]

By the way, with the extensive reorganization of application templates
proposed including restructuring the SQLAlchemy support, it puts me
and Eric pretty much on hold for writing tutorials and demos, which I
was planning to work on over the next five days. (Because I'm snowed
in in Seattle plus the Thanksgiving holiday.)

So it would be nice if we could decide the API quickly and get a draft
implementation of 'pyramid' and 'pyramid_sqla' out, and then worry
about getting the manual and tests caught up. That way we can do our
work while the latter is being done.

-- 
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-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 project templates

[Mike Orr]

On Tue, Nov 23, 2010 at 9:33 PM, Chris McDonough chr...@plope.com wrote:
 On Wed, 2010-11-24 at 00:30 -0500, Chris McDonough wrote:
 On Tue, 2010-11-23 at 21:24 -0800, Mike Orr wrote:
  By the way, with the extensive reorganization of application templates
  proposed including restructuring the SQLAlchemy support, it puts me
  and Eric pretty much on hold for writing tutorials and demos, which I
  was planning to work on over the next five days. (Because I'm snowed
  in in Seattle plus the Thanksgiving holiday.)
 
  So it would be nice if we could decide the API quickly and get a draft
  implementation of 'pyramid' and 'pyramid_sqla' out, and then worry
  about getting the manual and tests caught up. That way we can do our
  work while the latter is being done.

 Maybe you could write pyramid_sqla?  I have no desire to keep imposing
 my own will on this set of choices, but whatever gets created needs a
 champion and maintainer.

 There's no API that I know of, unless you mean something in the
 pyramid_sqla package itself.  But you can invent it rather than waiting
 for it to be invented.

I can't read Ben's mind. I need to know what he expects it to contain.
If we're just talking a Session and Base object and initialize_sql(),
that's almost too little to justify a package.

Likewise, I can make a 'pyramid' template, but I'd rather have you and
Ben and me agree whether it's modules or packages, whether it will
include a starter view and welcome-page template, and what the
template language should be. These are central decisions that Pyramid
as a whole is committing to; we have to make sure all the main
developers are comfortable with the decision. Otherwise (A) developers
will be unhappy, or (B) we may end up reversing the decision and that
has cascading impacts on the docs/tutorials/tests as you've said.

I don't mind maintaining templates, but I'm less enthusiastic about
writing the associated tests and updates to the manual that you
mandate for core contributions. That's why I prefer to make my stuff
outside the core for now. Plus I'm still a bit scared of git; e.g.,
when to create branches because it seems more branch-oriented than
Mercurial, and I don't want to end up creating branches for myself
that are effectively clutter to other people.

 BTW, I see no chance of coming up with a frozen-in-time paster template
 spec that is static and unchanging.  I've been changing docs based on
 required changes to paster templates for years.

Changes happen, but Ben usually comes up with excellent structures
that fit a lot of use cases and don't need much changing later. He
just takes a while to explain enough of his ideas to make spec from.

-- 
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-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: Routing in Pyramid

[Mike Orr]

On Fri, Nov 19, 2010 at 1:38 PM, Ben Bangert b...@groovie.org wrote:
 Next on my list is pyramid_routehelper, which will try to complete the 
 routing functionality and even top what Routes provides. An idea I've been 
 toying with since seeing it in werkzeug's routes, is the concept of 
 converters... as I'm really not a fan of int(..) all over to convert things 
 from the URL... over.. and... over... again.

A converter sounds like a validator, which suggests FormEncode. Does
Pyramid have any built-in infrastructure for validators? Requiring
FormEncode would anger some people, but using different validator
libraries in different parts of the application would also be bad.

It seems like Pyramid should have a generic validator feature akin
to its component feature. Because validation/conversion comes up in
forms, INI files, and now URL parsing.

 So, assuming we have a converter called converter.Integer, that supplies a 
 regular expression of \d+, and you've named it 'int', you could use it like 
 this:
 '/articles/{id:int}'

It does get tiring to put \d+ all over the place, and can be less
readable with less obvious regexes. I define a NUMERIC regex in my
apps, for use with the Routes 'requirements' dict.

The main goal is to keep configuration together rather than scattered.
Right now there's three places for dispatch/view configuration: in the
config.add_handler() call, and in the view method and its decorators.
Routes has a problem in that if you restrict a route to POST, it
doesn't really restrict the action, and you can't see in the action
code that the route is POST-only (or that the restriction is not
actually there, oops!). Conversely, if you restrict the action to
POST-only and a GET request is routed to it anyway, the user will get
an error rather than Routes being able to look for a more appropriate
action.

Likewise, it's the view that needs the variable to be a certain type,
but the type is specified in the routing, so those two things are
separate, and the same problem can occur when the view thinks the
route is doing something but the route is actually doing something
different.

As for contexts, I don't really understand them yet, nor factories or
root contexts or content managers, so I'm not sure how they are
factors.

 like how Routes has a submapper:
http://routes.groovie.org/setting_up.html#submappers

Submappers are a new feature in Pylons 1.0, and they make a lot of
configuration easier, but most people aren't familiar with them enough
yet to realize their potential. It would be great if Pyramid has a
similar feature. It could also help with the resource route issue:
some kind of helper for that combined with a submapper.

-- 
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-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: Status of Pyramid (angling for a beta)

[Mike Orr]

On Thu, Nov 18, 2010 at 12:27 PM, Chris McDonough chr...@plope.com wrote:
 We need it to be able to match even when there is not necessarily a
 slash at the end of the URL pattern before the stararg starts (IOW, we
 need *fizzle to potentially become () if the path is /foo/baz/bar for
 the pattern foo/:baz/:buz*fizzle).  This is how it's implemented and
 we count on this for *traverse behavior.

So...

/foo/b/c/la/la  =  buz=c, fizzle=(la, la)

/foo/b/c=  buz=c, fizzle=()

/foo/b/c/   = buz=c, fizzle=()

fooa/b/cd   = buz=cd, fizzle=()

?

Routes considered the short URL (#2) an instance of minimization,
which led to ambiguities if it accidentally matched an unrelated URL
the programmer didn't intend. So the current Routes requires two
routes for this:

/foo/:baz/:buz , fizzle=
/foo/{baz}/{buz}/{fizzle:.*}

These would both go to the same action.

Anyway, there may be problems with unintended minimization, especially
with a general route like:

/:action*fizzle

Or:

/section1/:action*fizzle

So I request /help/faq or /help.  Oh darn it, I meant that to go
to my /help or /help/:section route, not the /:action{fizzle}
route.

-- 
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-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: Status of Pyramid (angling for a beta)

[Mike Orr]

On Wed, Nov 17, 2010 at 7:10 PM, Chris McDonough chr...@plope.com wrote:
 - The pylons_* paster templates erroneously used the ``{squiggly}``
  routing syntax as the pattern supplied to ``add_route``.  This style
  of routing is not supported.  They were replaced with ``:colon`` style
  route patterns.

Is the {varname} syntax not going to be added then? Routes switched
from :varname to {varname} because it allowed us to deprecate
another syntax structure :(group_route), which was used when the
varname was followed by a letter/number/underscore -- something that
would be interpreted as part of the varname. If it's not added, we'll
have to tell people to go back to the colon syntax after telling them
the braces syntax is superior and making them switch to 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-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: Want to contribute - looking for task

[Mike Orr]

On Mon, Nov 15, 2010 at 2:31 AM, Alex Abushkevich
a.abushkev...@gmail.com wrote:
 Hello,

 I want to contribute to the project. Are there any not urgent
 programming tasks to do? (Simple-medium complexity)

Thanks for the offer. At this point, we've had several offers of help
and not enough intermediate-level tasks identified. The best thing
would be to practice with the development version (Pyramid), and
report any bugs you find (in the Pyramid bug tracker) and holes in the
documentation. The knowledge you gain will be useful in training other
users later, and will prepare you for programming tasks as they are
identified.

Ben, what do you think about creating a separate Pyramid wiki space on
Confluence, and with a list of volunteers and volunteer to-do tasks?
People will also be coming up with cookbook recipes, and it would be
better to put those in a separate space than to mix them in with the
Pylons Cookbook and confusing people about what works with which
version. Or does Github have an equivalent wiki?

One thing that's needed is a Git howto for Mercurial users. I found
one going the other way (at the Mercurial site), but it would still be
easier with examples of updating to a specific version, how to
understand the differences in branching so you don't create unintended
branches, etc.

-- 
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-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: Want to contribute - looking for task

[Mike Orr]

On Mon, Nov 15, 2010 at 2:01 PM, blaf blaise.lafla...@gmail.com wrote:
 as a new comer to git (coming from mercurial) I found github help very
 easy and simple to use and understand http://help.github.com/

I'll take a look. I'm still in the dark on parts of Git's
functionality, which has kept me from making a fork yet.

 I definitely need help on different upcoming tasks of the new web site
 and your request is relevant. I'm currently collecting ideas and
 features for the new site and you're welcome to edit those pages.
 There is a contributor page where people can add themselves and we'll
 try to dispatch based on interests and skills. We also can post
 recipes or other relevant content there until we have the new site in
 place.

You're talking about the PylonsHQ site? Where are those ideas being
collected, or where would somebody look who wants to be involved?

-- 
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-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 application templates

[Mike Orr]

On Wed, Nov 10, 2010 at 11:11 PM, Alexandre Conrad
alexandre.con...@gmail.com wrote:
 Hey Mike,

 I agree with you that having questions would be nice. And for people
 not liking the questions, maybe we could have them answered
 automatically by passing options such as --with-sqla --with-zodb
 --with-mako --with-urldispatch, ... Just an idea.

The question prompts are provided by paster create. Supposedly you
can pass variables at the end of the command line to pre-answer them
but it hasn't worked for me.

How do conditionals hinder application maintenance? Or should we just
say that since it hasn't been a problem for Pylons maintainers, that
level of complexity is OK. But if it gets much more complex it could
be too much. E.g., ZODB should only need a couple of if's, but auth
could require several if's and be too complex for the same template.

BTW, how would you make a template that handles both SQLAlchemy and
ZODB? Pylons puts the model definitions and init_model() in
'.__init__', and the Session and Base in 'meta' so they can be
imported into everything without circular imports. but where would
ZODB go? Or does it not really need a model but just a short
initialization function?

 We could also have just a bare bone Pyramid app with no template
 engine an no sqla/zodb. Such a setup could be for a webservice app
 that only returns JSON data, no HTML.

That sounds like a job for pylons_minimal. You'd still have the
distinction of URL dispatch vs traversal. This seems to be the most
fundamental choice people make when they choose an application style.
(Well, that and ZCML.)

-- 
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-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?

[Mike Orr]

On Thu, Nov 11, 2010 at 12:58 AM, Wichert Akkerman wich...@wiggy.net wrote:
 On 11/11/10 09:30 , Mike Orr wrote:

 Could we name it 'u' and pretend that Pylons always had it? 'url' does
 tend to conflict with local variables and I usually use 'u' for the
 local variable in that case, so this would just reverse the practice.
 And it would look OK next to 'c' and 'h'.

 For readability sake I would object to that. One-letter names are confusing
 to new people, and very likely to conflict with temporary variables.

This is one of those cases where purity interferes with practicality.
It's only three one-letter variables to learn, and they're widely used
all over templates so they'll seem like just part of the syntax. And
if you only have a 79-character line and you want to put the entire
expression or tag on one line, it gets difficult when the boilerplate
code extends to nine characters; that's over a tenth of the space just
for one of them.

  1  2  3
4  5  6  7
1234567890123456789012345678901234567890123456789012345678901234567890123456789

More details a href=${u('record',
id=c.incident_id)}stronghere/strong/a.

More details a href=${route_url('record',
id=c.incident_id)}stronghere/strong/a.

More details ${h.link_to(here, u(record, id=c.incident_id))}.

More details ${h.link_to(here, route_url(record, id=c.incident_id))}.

Click a href=${u('record', id=c.incident_id)}yes/a or a
href=${u('record', id=c.incident_id)
no/a to cast your vote.

Click a href=${rouute_url('record', id=c.incident_id)}yes/a or
a href=${route_url('record', id=c.other_id)no/a to cast your vote.

Click ${h.link_to(yes, u(record, id=c.incident_id))} or
${h.link_to(no, u(record, id=c.incident_id)}
to cast your vote.

Click ${h.link_to(yes, route_url(record, id=c.incident_id))} or
${h.link_to(no, route_url(record, id=c.incident_id)} to cast your vote.

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.

-- 
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-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?

[Mike Orr]

I guess ${route_url()} is no longer or worse than ${h.url_for()},
which is what Pylons had before url(). And url() has always had a
problem in being the same as a previously-popular local variable.

It would still be nice to put 'u' as a commented default, so that
users can just uncomment it if they want it.

-- 
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-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?

[Mike Orr]

On Thu, Nov 11, 2010 at 8:26 AM, Mike Orr sluggos...@gmail.com wrote:
 I guess ${route_url()} is no longer or worse than ${h.url_for()},
 which is what Pylons had before url(). And url() has always had a
 problem in being the same as a previously-popular local variable.

 It would still be nice to put 'u' as a commented default, so that
 users can just uncomment it if they want it.

So in the morning light (Pacific time zone), I reverse my position.
route_url() is fine.

And if we put the subscriber in the application template, we can draw
attention to it in the docs and give some examples of how to modify
it. In Pylons the corresponding function is in pylons.templating
itself, and overrriding it requires reimplementing the render_mako()
function, which is significantly more obscure/advanced than just
overriding the variable-injection function. So it would be an
improvement over Pylons.

-- 
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-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 application templates

[Mike Orr]

On Thu, Nov 11, 2010 at 2:29 AM, Michael Haubenwallner
michael.haubenwall...@gmail.com wrote:
 On Nov 11, 8:11 am, Alexandre Conrad alexandre.con...@gmail.com
 wrote:
 Hey Mike,

 I agree with you that having questions would be nice. And for people
 not liking the questions, maybe we could have them answered
 automatically by passing options such as --with-sqla --with-zodb
 --with-mako --with-urldispatch, ... Just an idea.

 We could also have just a bare bone Pyramid app with no template
 engine an no sqla/zodb. Such a setup could be for a webservice app
 that only returns JSON data, no HTML.


 +1 (for exact the usecase)

'pyramid_webservice'?  Or rename 'pylons_minimal' to
'pyramid_minimal'? (There is also a 'pyramid_starter' for traversal
style.)


 --
 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.





-- 
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-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: Any sample applications for Pyramid?

[Mike Orr]

On Thu, Nov 11, 2010 at 9:02 AM, Gael Pasgrimaud g...@gawel.org wrote:
 Hi,

 On Thu, Nov 11, 2010 at 12:17 PM, Gopalakrishnan Subramani
 gopalakrishnan.subram...@gmail.com wrote:
 Do you have any sample application using Pyramid, Sqlalchemy, Mako and
 Authentication and Authorization?

Not yet that I know of, but there will be in the near future.

 I have done sites using Pylons and looking forward to learn Pyramid
 and convert the pylons sites to Pyramid.


 I don't understand why you want to do that. As I understand Pyramid is
 not Pylons but Pyramid will become Pylons2.
 Why do you want to spend time to switch your application now ? I'm
 sure that it will be easy to switch a pylons application in the futur.

It depends on whether they're doing it mainly to learn Pyramid (and
don't mind that some of the documentation and convenience functions
are unfinished), or whether they're doing it because they think they
should upgrade their application now.

The OP sounds like he mainly wants to learn Pyramid, and porting a
familiar application allows you to experience the exact differences
between Pylons and Pyramid, which will be a useful skill the future.
it may also be easier to port a familiar application than to write a
new one from scratch, if the application is not too large and complex.

But if somebody is doing it because they think they should upgrade
their applications now, no. Wait till Pyramid is released, or at least
a beta. Then there will be better application templates and tutorials
to help you, and the list will be more able to answer your questions.

-- 
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-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?

[Mike Orr]

 attribute.

-- 
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-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?

[Mike Orr]

On Wed, Nov 10, 2010 at 9:08 PM, Chris McDonough chr...@plope.com wrote:
 On Wed, 2010-11-10 at 19:26 -0800, Mike Orr wrote:
 'c', 'h', and 'url' are most important.

 Thanks, that's what I figured.  Most folks on IRC agree (at least they
 said c and h are probably non-negotiable).

'c' is still useful even with the dict-return style, because you can
set things in .__init__ for the site template, or other things you
don't want to clutter every return value with. (Especially things that
are HTML-only, for views that do double-duty as both HTML output and
JSON output).

-- 
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-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: Is there Pyramid documentation for offline use?

[Mike Orr]

On Mon, Nov 8, 2010 at 11:29 AM, Gael Pasgrimaud g...@gawel.org wrote:
 Hi,

 On Mon, Nov 8, 2010 at 8:20 PM, Rob Smallshire rob...@smallshire.org.uk 
 wrote:
 Hello,

 Is the documentation for Pyramid available for download in a form
 suitable for offline reading, such as in a zip archive of the HTML or
 PDF?

 The best I've found so far is to download the web site with,

    wget --convert-links --mirror -e robots=off 
 http://docs.pylonshq.com/pyramid/dev/

 which works fine for me, but seems like a roundabout solution.


 Look like the source (including sphinx docs) is on github:
 https://github.com/Pylons/pyramid/tree/master/docs/

 Good luck with Pyramid!

Ben, a pregenerated PDF is needed.

I tried to build a PDF myself but I only got half the pages, errors
about missing *.sty files, and some literal layout code (TeX or ps?)
in the first few pages. The full book with API appendices is 650 pages
or so, so it'll take a lot of paper. Ben said, Not printing two or
three versions of this will justify the price of an iPod. :) Although
I would prob'ly get a Kindle instead, due to its easier-to-read
screen.

-- 
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-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: Is there Pyramid documentation for offline use?

[Mike Orr]

On Tue, Nov 9, 2010 at 9:59 AM, Chris McDonough chr...@plope.com wrote:
 On Mon, 2010-11-08 at 12:42 -0800, Mike Orr wrote:
 
  Look like the source (including sphinx docs) is on github:
  https://github.com/Pylons/pyramid/tree/master/docs/
 
  Good luck with Pyramid!

 Ben, a pregenerated PDF is needed.

 I've just generated a PDF and an epub file:

 http://static.repoze.org/pyramid-1.0a2.pdf

I just realized I made a mistake in this version. I noticed the wiki
tutorial last night (chapter 33) and asked Chris to retitle the
chapter so that Pylons users would find it. But it's actually based on
the older pyramid_routesalchemy template rather than on
pylons_sqla. So it shows URL dispatch and SQLAlchemy, but not view
handlers and @action, which is what Ben is recommending going forward.
So don't be misled by the title; the tutorial is not completely
up-to-date yet although I assume it works.

-- 
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-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.