Re: [pylons-devel] Pylons 1.x maintenance
I'd be happy to add you and another person as release maintainers for Pylons (we could setup a separate pylons-legacy team for you on github with access to appropriate repos as well, or I can just stream-line merging anything one of you r+, whichever works). I assume you will also need release access to dependencies such as Routes, WebError, Paste, and such? I finally just released a new WebError, Routes, and Pylons, and have obviously not had the time to properly devote to legacy maintenance so I'd be thrilled with some active ppl coming on to continue. Cheers, Ben On Mon, Jul 20, 2015 at 1:56 PM, Andrew Shadura and...@shadura.me wrote: Hi, On 20 July 2015 at 22:47, Steve Piercy steve.piercy@gmail.com wrote: To proceed, please contact Ben Bangert directly, as he is the owner of Pylons the web framework, and work out any details. I don't have any say in the matter; I'm just facilitating. https://github.com/bbangert Okay, maybe I should try (again). You are shown as a subscriber with No email as your preference. Would you like me to change that? Other options are All email and Digest. If you want to change it, you must have a Google Account for the address. This is what I wanted, yes, but Google Groups also has ‘subscribe me to the topics I post to’, but it doesn't work :( -- Cheers, Andrew -- 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.
ANN: Beaker 1.6.4 released with important security update
Beaker is a high-level Python library providing caching and sessions for use in web applications. The session implementation comes with crypto-based cookie encryption that support PyCrypto, pycryptopp, and now NSS crypto. Prior to this release, an attacker could possibly determine some content of cookie-based sessions encrypted with PyCrypto due to how the data was encrypted. This flaw did not affect pycryptopp sessions, nor does it allow an attacker to change data as a separate HMAC is used to sign the encrypted payload. Red Hat found and supplied a patch to fix this flaw, thanks! CVE-2012-3458 Fix in beaker: https://github.com/bbangert/beaker/commit/91becae76101cf87ce8cbfabe3af2622fc328fe5 Applying this update will change the hashing of sessions encrypted with PyCrypto, invalidating existing ones. Changelog for this release: * Fix bug with key_length not being coerced to a int for comparison. Patch by Greg Lavallee. * Fix bug with cookie invalidation not clearing the cookie data. Patch by Vasiliy Lozovoy. * Added ability to pass in cookie_path for the Session. Patch by Marcin Kuzminski. * Add NSS crypto support to Beaker. Patch by Miloslav Trmac of Redhat. * Fix security bug with pycrypto not securing data such that an attacker could possibly determine parts of the encrypted payload. Patch by Miloslav Trmac of Redhat. See `CVE-2012-3458 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3458`_. * Add ability to specify schema for database-backed sessions. Patch by Vladimir Tananko. * Fix issue with long key names in memcached backend. Patch by Guillaume Taglang. Cheers, Ben -- 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
On Apr 4, 2011, at 12:37 PM, Chris Withers wrote: Well, what has been happening, certainly from a (relatively) innocent bystanders point of view is that it's all been on -devel up until now. The two lists are meant to be a convenience for users, users, or developers? Both. But obviously some of the developers spend 99% of their life on work, and 1% on developing pyramid. To then say they should also spend their time helping support with such a large community seems a bit crazy given that we aren't full-time open-source dev's on foundation funding or something. So yea, its a lot easier as a developer with limited time that wants to go over dev issues to skip the how do I setup pip on OSX? question, rather than spend that precious time wading through it. I'm not sure if thats elitism, or just basic time management. It feels like time management, and given the large community of users of this open-source project, I am thrilled to see many users step up to help other users get to where they are knowledge-wise. I personally read them both depending on time available on a given day. For users interested in the development issues, it seems easier as well. I mean, if being able to filter on a topic was not useful, surely there'd be no utility in having tags, categories, etc. in the world, eh? ;) As a user and part time developer, I wasn't even aware of the -discuss list until this discussion came up! Yea, bad communication. Again, very sorry we failed to foresee that one. 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. Really? ;-) Sure, we're trying to, thus this post. I suppose I could consider the nuclear option and wipe out the pylons-dev list entirely to force all discussion over to pylons-discuss, then at a later point bring back a development oriented list. But we're all adults, so that seems a bit childish and unnecessary. It would be nice if mail list threads could be 'tagged' or 'categorized' though. With a nicer UI and such a feature, that'd prolly be fairly similar to convore. Hell, it'd help me a ton just to see which libraries people needed help with, as I'm sure ppl that are expert in some libs could spend their time better answering just those questions. So being able to tag a thread 'Pylons 1.0' or 'Pyramid 1.0' or 'SQLAlchemy 0.6 + pyramid_sqla' would make it easy for people to know what the topic involves. Obviously mail lists weren't well designed for 'support' type things, which is why StackOverflow is so popular (which does have those tags!). Which presents another interesting discussion, should we refer people needing help to StackOverflow to see if their problem has a solution there, and if not have it solved there instead of on the mail list? Then we could just nuke pylons-dev, and have a single pylons-discuss where all Pylons Project related topics are discussed, and refer people with more 'support' type questions to StackOverflow. Just a thought. Cheers, Ben -- 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
On Mar 31, 2011, at 7:14 AM, Chris Withers wrote: How about just merging the lists? As far as I know, Google Groups has no 'merge' option. Is there really so much volume as to justify two lists? Well, the -devel is intentionally lower traffic so those more concerned about the development of the framework can easily skip all the support and Q/A type things on the -discuss. 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 Odd, I thought public mail lists that anyone can go to was anti-elitism. At this point though, it's more just a pain that discussions happen randomly on both, and one list has most of the folks on it. I generally got the impression that people who can help would be on both lists, while those just asking questions or for help would stay on -discuss. That was the main reason I asked to retain that, though if merging the two lists was possible (so that everyone would be subscribed to the whole thing), that'd be something worth considering as well. Personally, when I'm mainly interested in looking at development related things, being able to see just that at once is very useful. Of course, it'd also be useful if Mail Lists supported tags/categorization so its easier to filter but ah well. Cheers, Ben -- 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
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. Cheers, Ben -- 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
On Mar 21, 2011, at 11:08 AM, Alice Bevan–McGregor wrote: ±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'd also say that blueprint is more descriptive, of course I think the Rails term for this is also rather good, scaffold/scaffolding. The main advantage of using the existing Rails term would be an automatic recognition in a larger group of people about what it actually is, while the term blueprint is already becoming widely associated with Blueprint the CSS framework. I know quite a few people coming to Python from the Rails world immediately search around looking for where the equivilant 'scaffolding' is for their projects. Cheers, Ben -- 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
On Mar 21, 2011, at 12:29 PM, Mike Orr wrote: 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? flask is introducing blueprints for yet another meaning: http://lucumr.pocoo.org/2011/3/18/flask-at-pycon/ So with the next Flask release we will ship a new concept for modules called “Blueprints”. Essentially what these blueprints will do is capturing construction information. You can then attach these blueprints to applications (even multiple times if you like). They can either extend the application itself or are registered with their own name. So using the term blueprint means we'll have our 'blueprint', flask's 'blueprint', and the css framework 'blueprint'. Let me rephrase, is there any real reason not to use an already widely acknowledged term in the web world that is *known* to mean exactly what we're already referring to? Anyways, a better question is, are people really baffled by the concept of paster templates for template languages? Is that a real problem? I'm just not sure 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. But hey, its a fun bike-shed, eh? :) Cheers, Ben -- 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
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. Cheers, Ben -- 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.
ATTN: Please keep general discussion on pylons-discuss
First, I apologize for failing to catch that the website was unfortunately instructing people to go to pylons-devel to talk about Pyramid and Pylons Project tasks. We really need to keep general discussion type stuff on pylons-discuss. Otherwise we end up with two lists for general discussion, and pylons-devel having both general discussions. I really don't want the list to be fragmented such that people aren't getting the help they could be if they had posted to pylons-discuss. 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. If there's already a discussion on pylons-devel that isn't along these lines, please start responding to it on pylons-discuss and don't continue it on pylons-devel. Odd's are there's more people that will benefit as the pylons-discuss list is substantially larger in membership then the devel one. Again, sorry about the confusion and delay in updating the Pylons Project pages to indicate the appropriate mail list to use. Cheers, Ben -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: How do I combine paster templates?
On Mar 7, 2011, at 3:56 AM, Simon King wrote: It might be worth pointing this out in the docs. http://docs.pylonsproject.org/#support and http://pylonsproject.org/community/get-support only mention the pylons-devel list (as far as I can see, at least). Thanks for pointing that out! We're fixing that asap. :) Cheers, Ben -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: How do I combine paster templates?
On Mar 5, 2011, at 12:34 PM, Sasker wrote: Also, I apologize if I am posting to the wrong group, I wasn't quite sure which group I should be posting to. No worries, this should be posted on the pylons-discuss list. Pylons-devel is for development related to Pylons projects, the Pyramid framework, and infrastructure development. You'll generally recieve more input on issues on the pylons-discuss list as its much larger. Cheers, Ben -- 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
On Mar 3, 2011, at 9:28 AM, Chris McDonough wrote: Sounds like (s)he is blowing off a little steam. All of these points are addressed in http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html . Indeed, my comment is awaiting moderation on the blog, I cited that URL as well. :) Cheers, Ben -- 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
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. 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. Cheers, Ben -- 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
On Feb 24, 2011, at 11:18 AM, Mike Orr wrote: Or rather, it would solve the /index?page=2 problem. It wouldn't solve the /index/page/2 problem, which requires knowledge of a specific router. Yea, I can't say I'm really a fan of that. The whole url's shouldn't change, and here's an arbitrary changing page as /2 will likely change. And really, its a query parameter that you want the second page... so it does seem logical that it'd be the URL's query param... at which point passing in the WebOb request would be sufficient to get the current location *and* generate the appropriate link to the next page. As for handling offset vs using a last key, it might make more sense to make a better API for the object passed in then the sequence slice operation I had imagined earlier. Cheers, Ben -- 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: Raw MySQL with SQLAlchemy using Pyramid framework
On Feb 20, 2011, at 1:58 AM, AwaisMuzaffar wrote: Thanks for the reply guys it has been very informative. My main reason for using raw is that I have spent so much time learning MySQL, to me it seems counter productive to learn SQLALchemy methodologies from scratch. Ok, so maybe manually executing CREATE is not a great idea, but what about performing queries with pure MySQL, is that fine? The main utility I've found in SQLAlchemy is its connection pooling, automatic reconnection, and the fact that dynamically generating queries by concatenating raw SQL inside text strings is pretty horrendous. After using SQLAlchemy for awhile, I've finally gotten to the point where its actually easier for me to now write many SQLAlchemy queries than to use the raw SQL. Of course, as was mentioned, you do need to know the raw SQL to be able to tell SQLAlchemy how to do the right thing anyways. I'd say its worth the hassle of learning the abstraction purely for the ability to easily dynamically generate queries. Concatenating text strings of raw SQL is very error-prone. An example of dynamically generating an SQLAlchemy query in a model instance method: cases = meta.Session.query(cls) if court: cases = cases.filter_by(court_id=court) elif ecf: cases = cases.filter_by(ecf_abbreviation=ecf) cases = cases.filter(cls.filed_on=datetime(2000,1,1)) if judge: cases = cases.filter(cls.id.in_(judge_case_ids(judge))) It's quite easy to dynamically build up the filter conditions, dynamically include additional table joins as needed, etc. Cheers, Ben -- 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: help on webob
On Dec 30, 2010, at 11:29 AM, Gael Pasgrimaud wrote: I've already tried to contribute but my changes was never merged. Maybe you can use this changeset: https://bitbucket.org/gawel/webob/changeset/ed29414cd65b Thanks Gael! I've pulled and merged your test additions. Cheers, Ben -- 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: @view_config and URL dispatch
On Dec 12, 2010, at 10:20 PM, Jerry wrote: but not /with/ the 'name' argument (which gives the same error as that in my previous post) -- views.py @view_config(name='site1_view', route_name='site1', renderer='templates/site1.pt') /views.py Maybe the doc could have made it clearer that view_config() 'name' and 'route_name' arguments can not co-exist (for URL dispatch?). They can coexist, but 'name' is frequently only supplied if traversal is used. When using Routes, name will not be populated so making a view registration that requires 'name' will cause it to not be found during view lookup. Cheers, Ben -- 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
On Nov 24, 2010, at 7:10 PM, Daniel Holth wrote: I recommend the status quo. My reusable pyramid application will not need to import pyramid_sqla. It will: • have its own declarative base • require the user to call ponzi_auth.configure_database(engine) • not use database reflection, and so will not need a configured engine before import (the Session is not used for database reflection) • not use ScopedSession.query_property() • not use the Session at all in the models or use object_session(self) • access the session as a request parameter in views, attached in an INewRequest callback as something like request.db On the other hand, when I configure my engine from the .ini it's just configure_engine(settings['sqlalchemy.url']) So I think the way it works now is fine. Yea, that's just more to document, which maybe is fine. I'm probably not the best opinion on this as my setups are all generally unique. I'd prefer to just document it then have a package, but I do recall there being some benefit to having a place for people to be able to get to the session, or to ensure the engine is configured and bound first. The main advantage to having the package is that since one doesn't need to import anything from their own models during config, reflective tables are easier. As you mention, you don't use table reflection, so maybe this isn't an issue for you. Cheers, Ben -- 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
On Nov 23, 2010, at 7:50 PM, Chris McDonough wrote: I'd suggest instead: newproj/ __init__.py views.py tests.py models.py templates/ mytemplate.pt static/ various static files Such a template might be named pyramid_diy. pyramid_diy would be a template used by folks whom: - already know how to create packages and whom understand that it's possible and trivial to turn a module into a package when such an occasion is required (it needn't be done preemptively for them). - realize that there are not any incontravertable decisions implied by the filesystem layout generated by a paster template. This would essentially just be the pyramid_starter template renamed. It would be the only paster template that ships with Pyramid itself. As Mike mentioned, naming this just pyramid would prolly be fine. There are a few other spurious references to ``views.py`` or ``models.py`` in other places in the Pyramid docs (the templates and resources chapters, for example) but these can be changed to views module/package or models module/package as necessary. I think as long as the name of a module file representing, e.g. views (views.py) is the same as the name of the package directory (views directory with an __init__.py file in it), this is sufficient. Sounds good. I don't think this is useful. A single file app would never live in a package. There's no purpose in providing a template to generate a single-file app. Indeed, strike that. :) Cheers, Ben -- 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
On Nov 23, 2010, at 11:22 PM, Mike Orr wrote: 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. So, my thought was that it'd have a DBSession in it, and the code necessary to setup the DBSession based on the settings, such that you could do: from pyramid_sqla import setup_dbsession # in the config stuff setup_dbsession(config) And that's it, the DB session settings will be read out of the settings with the assumption they start with 'sqlalchemy.'. If you want to change the default: setup_dbsession(config, prefix='sqlalchemy.read.') etc. As soon as that runs, the db engine will be setup. This command should be run at the very very top of the config ASAP, this way when you do add_handler, your handler can go ahead and import models, and even if its using reflection... the db is already setup. I believe this means we can finally have reflective models at module scope in the models.py or models/ package. So initially, pyramid_sqla will be a package that has: A) the db session setup, and a DBSession object ppl import, no more boiler-plate B) a pyramid_sqla project template C) Tutorial docs on using pyramid + sqlalchemy I say initially, because I think there's probably other useful things we can include here relevant specifically for using pyramid + SQLAlchemy that will let people make more assumptions about some basic SQLA things. For example, maybe the setup_dbsession command in the future might trigger an event DBInitialized that other event listeners might be waiting for to do something, etc. 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. Chris said he can handle the default pyramid template, so that will be taken care of. I believe the final we'll go with for the single template included with pyramid will be: 1) It will use modules for views.py/models.py, with some instructions on splitting into package when needed 2) It will include a default 'welcome' template ending in .pt, .mako is also configured 3) No other decisions about ORM/etc. will be made This is just for the template in pyramid. For consistency, all templates for pyramid should have either a views.py or views/ package, and a models.py or models/ package as appropriate. 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. For pyramid_sqla, if the tutorial you're writing is going to have large models where the size of models.py would likely pass 1k of code, the pyramid_sqla template should probably make models a package instead of a models.py. Cheers, Ben -- 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
On Nov 24, 2010, at 10:58 AM, Mike Orr wrote: 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. There's no reason you can't call setup_dbsession in a command line script. Note in my last email I changed the mock signature of the function to take the settings dict specifically so you wouldn't need a config object. The setup_dbsession could also take raw keyword arguments to set up the db session. Call that, and you're good to go with the models. 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? Yep, we can't do everything for everyone, no point trying. When people need crazy customized stuff, they'll have to make their own stuff. No way around that, but I like optimizing for the most common case, which is generally not tons of databases. I'm sure we can work out something somewhat flexible for changing engine bindings to a session on the fly though, like: from pyramid_sqla import set_session_bind set_session_bind(session='read_only', engine='db2') And it'll switch the engine binding for the session for this request. Or we could just provide an easy command that lets the person get the configured engine/session and switch the binding themself, which would prolly be better as that'd let them stick with more SQLAlchemy knowledge, and pyramid_sqla would only be making it easy to register engines/sessions and get to them from anywhere else. 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. Indeed, so I think a simple central point where you setup/register engines/db sessions would still be useful. The functions would work from a settings dict (like when used with a pyramid app), or keyword args. 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(). Yep, taken care of per above. :) Cheers, Ben -- 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
On Nov 24, 2010, at 1:49 PM, Mike Orr wrote: So do we need multiple sessions? I'm not sure we've defined the use cases clearly enough, which runs the risk that we'll make an API that won't be adequate anyway. So I'm inclined to use a single session. We can always add a multisession object later under a different name, and share the default session with it. Indeed, I think to begin with, we can provide a single session you can retrieve with: from pyramid_sqla import get_dbsession DBSession = get_dbsession() When you setup the db sessions with setup_dbsessions, you can provide multiple engine configs if desired, and use get_engine to fetch it by the name you called it. If people are using the same ORM objects to copy data from one db to another, I think they can use a 'bind' argument on the specific calls. Yup, so they would do that themselves after fetching the engine they want. I think that keeps it pretty simple still and obvious that pyramid_sqla isn't doing any magic, its just holding onto the engines that were setup, and can bind an engine to a session during 'setup_dbsessions' if desired (ie, using table reflection which requires them to be bound immediately). I unfortunately won't have time to crank this out before Monday as I'm heading out later today for Thanksgiving. Given what I've said about its proposed API though, maybe a quick prototype for the purposes of the tutorial can be built by someone. Here's a quick Python mockup: http://pastie.org/1324151 I haven't tested it, but it should provide enough guidance to illustrate the concept. In your models at module scope you do: from pyramid_sqla import get_dbsession DBsession = get_dbsession() In your __init__.py to configure: from pyramid_sqla import setup_dbsession # in config, assuming all the SQLA settings are under 'sqlalchemy.' setup_dbsession(settings) That's it, its now ready for use. If you look at the function signature, it provides the option of not immediately binding the engine created to the session if desired. Ie. you're going to call setup_dbsession several times to configure additional engines, perhaps: setup_dbsession(settings, name='read_slave', prefix='sqlalchemy.read.') setup_dbsession(settings, name='write_master', prefix='sqlalchemy.write.', immediate_bind=False) Then its up to the user during runtime to use get_dbengine and re-bind the session during the request if they want to change to the write master, etc. Cheers, Ben -- 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: permissions with handlers
On Nov 20, 2010, at 2:21 AM, Eric Rasmussen wrote:
I completed the wiki tutorial and had no problem setting up
authorization/authentication with config.add_route and the keyword argument
view_permission. However, I'm putting together my own app now using the
Pylons style handlers, and it doesn't seem to act on the permission setting
(although I'm not receiving any errors):
config.add_handler('console', '/console/', 'webapp.handlers:MyHandler',
action='console', permission='edit')
I've also tried the above with view_permission='edit', and I've tried using
each of those keyword arguments in the @action decorator in my handlers.py
file/'console' action as well.
The permission keyword should work fine in the @action decorator, it won't work
in the add_handler call because all additional keyword args to add_handler go
to add_route (and permission is something you want for the add_view which
@action will use).
Cheers,
Ben
--
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.
Routing in Pyramid
After some discussion, it seemed reasonable to also have Pyramid use the new
Routes style syntax for grouping markers (the dynamic bit) in a pattern:
'/articles/{action}/{id}'
As this allows for multiple markers in the same path segment, and provides
leeway for additional functionality like including a regular expression:
'/articles/{action}/{id:\d+}'
I've updated pyramid to now honor this format, and the docs reflect it. As with
Pylons 1.0, the old ':marker' syntax still works but the official documented
style will be with braces.
This helps get pyramid a lot closer to Routes parity which I've considered a
major requirement before larger Pylons 1.0 applications may be able to switch
over. Especially for those using the sub_domains feature of Routes which is
unavailable without a lot of custom stuff in pyramid at the moment.
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.
However, in werkzeug, the function call to customize the conversion occurs
inside the pattern string itself, which I'm really not a fan of, also, you
still have to keep specifying it over and over again for each route. I've been
thinking of implementing it more like this though:
1) You declare converters, and the converter name they should use
2) When writing routes, instead of supplying a regex, if the name is a
converter you've declared, that is used
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}'
And it will use \d+ as the regular expression, and do the int() type conversion
for you. However, you could also register a marker name itself to automatically
have a converter applied. For example, maybe in your application, {id} should
*always* be \d+ and converted to an int(). Why type that over and over again?
with routehelper(config, global_converters=dict(id=converter.Integer())) as r:
r.add_route('articles', '/articles/{id}')
In my experience, lots of people end up repeating themselves a ton as their
marker names frequently require the same regular expression and type coercion.
It'd be nice to have that all taken care of without clouding up the view code.
Any thoughts on converters or being able to register default regular
expressions for route markers?
Cheers,
Ben
--
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
On Nov 19, 2010, at 2:26 PM, Alexandre Conrad wrote:
I don't feel I'd use that very much. It's like having globals set in
your app, you don't really know what's happening (even though the
context manager helps in readability). I'd rather have explicitly
{id:int} so I am sure it is casted to whatever the int named
converter returns. You know what each route does just by looking at
it.
The context manager would be required both to declare what converters are valid
for the scope, but also because this functionality comes from another package
in addition to pyramid you need to do something to get a different object with
add_route/add_handler.
For non-context use, it'd be something like:
r = routehelper(config, converters=dict(int=converter.Integer(),
month=converter.Integer(min=1, max=12))
r.add_handler('articles', '/articles/{action}/{id:int}', handler=)
r.add_handler('month_archives', '/archives/{month:month}'...)
That last line is where people's custom converter names vs the marker names
might get a little odd, which is why I was thinking one could assign a
converter that would be used if the marker name was the same. Otherwise for
clarity you'd prolly have this instead:
r = routehelper(config, converters=dict(int=converter.Integer(),
month_conv=converter.Integer(min=1, max=12))
r.add_handler('month_archives', '/archives/{month:month_conv}'...)
Which I guess is fine, and as you mention it does avoid the ambiguity by making
it explicit that something else is happening with the marker.
I do anticipate ppl using the routehelper as a 'partial', which is why many
like the context manager aspect, like how Routes has a submapper:
http://routes.groovie.org/setting_up.html#submappers
Cheers,
Ben
--
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
On Nov 19, 2010, at 4:12 PM, Chris McDonough wrote:
If there are both regexes and converters, I'd suggest they remain
separate, e.g.:
{month:\d+:month_conv}
Regexes are about matching, converters are about converting.
Since my month converter knows it wants digits, I feel silly being unable to
let it declare that and having to repeat that over and over. While it could be
instead maybe:
{month::month_conv} to indicate I want the regex month_conv has, it seems that
might be easy to goof up and leave off a semi-colon.
For some converters that might have a large regular expression that goes with
it, I fear having to type it a million times along with the converter name in
addition to the marker name. I'd highly prefer to let the converter supply a
regex appropriate, since the converter will fail without an appropriate value
anyways which it supposedly has a clue what would be a valid conversion...
- Ben
--
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
On Nov 19, 2010, at 5:57 PM, Chris McDonough wrote:
AFAICT, matching and conversion are totally separate concepts. Despite
some conversions having a relationship with some matchings, there are
times when you want a match filter without a conversion, and vice
versa. And there are times when you don't want to stop to create a new
converter just to make a matching assertion.
That's true, so declaring a match assertion should prolly always be an option.
On the other hand, the performance freak in me is screaming that we shouldn't
be running all these converter predicates without easily screening out more
cases where the converter shouldn't even bother that a match assertion
could've stopped.
If we consider conversion-marker-in the pattern a must-have (I don't
think it is TBH, because we already have it via custom route
predicates), whatever solution we come up with should take into account
the case of someone just wanting to do an unanticipated matching
(probably via a regex) without stopping to create a converter/matcher
utility.
Actually, routehelper was going to pre-parse the pattern for
conversion-marker-in-pattern and toss in the appropriate marker._regex and then
put a matching predicate for the converter into the route predicates. But
calling more functions for *every single route* when a simple regular
expression bit that was already called to match could've kicked it out.
It's just such horrible inefficiency I could never in good conscious propose
anyone actually use it.
Saying something like:
def month_converter(value):
min = 1
max = 12
value = int(value)
if min = value = max:
return value
r = routehelper(config, converters=dict(int=\d+, month=my_month_converter)
r.add_handler('articles', '/articles/{action}/{id:int}', handler=)
r.add_handler('month_archives', '/archives/{month:month}'...)
Routehelper would then take:
'/articles/{action}/{id:int}'
And turn it int '/articles/{action}/{id:\d+}', and then attach a custom
predicate that will call the int converter. So route helper is merely acting as
a macro system to make doing a bunch of those conversion a simple matter rather
than building up lists of custom predicates (running O(n) with n as the amount
of parts, UGH).
Every little bit at this level will be multiple a ton as the resource macro and
other ppl do things adding a bunch of routes. Adding 2, then 3, then 5 function
calls per missed route is going to be bad bad bad for performance. I really
don't want the routing system to be so horribly inefficient. Maybe a little of
this might be premature optimization, but I've seen a lot of use-cases in the
wild that leads me to believe the way people will actually use it will result
in horrible inefficiencies unless the system can streamline it some.
Sure, every route could have a custom predicate list of a half dozen functions,
multiple that by the amount of routes... and... ugg. I really don't want to
think of the inefficiency we're talking about.
That's really the main reason I'd like a 'converter' to be able to specify a
regex for its part so you didn't have to manually type it over and over again.
I don't want to be typing it over and over again, and its nice to have the
converter specify some basic minimum set of requirements that can be taken care
of in the regex match *before* all the conversion processes actually run.
Cheers,
Ben
--
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)
On Nov 18, 2010, at 11:36 AM, Mike Orr wrote:
BTW, I'm not so sure it's a good idea to allow omitting the slash
before the star.
Unlike segment replacement markers, [the star] does not need to be
preceded by a slash. For example: foo/:baz/:bar*fizzle
I would read that and be confused. How can you have two variables
together without a static character between them, unless the first one
is restricted such as '\d+'?
Yea, its a bit non-intuitive, even if it isn't required (because the default
:baz regex requires a /), I'd hate it if developers in my project started doing
that.
The current version of Routes replaces wildcards with {varname:.*},
which matches all characters including a slash. Additionally,
'path_info' is a magic varname which adjusts the real path_info in the
WSGI environment. This, or something equivalent, will be needed for
delegating to sub-applications.
Yes, prolly a helper function that will take a path_info off matchdict and
fixup the environ for a sub-app dispatch call.
Oh that's right, I forgot there was a routehelper function in the
latest Pylons-dev before Pyramid. But I'm not sure what all its
capabilities are.
Are there any other helpers now or coming, which application
developers will want to know about?
My current plans for additional pyramid_* helper packages that I'd consider
important for Pylons devs:
* pyramid_routehelpers - A package of helpers for map.resource, map.redirect
macro type functionality, also includes sub_domain support, etc.
* pyramid_websec (or somthing like that) - Helpers for CSRF/XSS protection
* pyramid_feeds - Template renderer that provides feed output support, ie
'atom', or 'rss2' and will handle taking a dict like current renderers, but
spit out a feed
* pyramid_paginate - Flexible pagination helper for sequences like the current
paginate
The most important is prolly routehelpers and CSRF helpers, then paginate and
prolly feeds.
Cheers,
Ben
--
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 2 users guide, first draft
On Sep 30, 2010, at 9:43 AM, Mike Orr wrote:
CC'ing pylons-devel because these will be FAQs.
@action
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
@action
TypeError: __init__() takes exactly 1 argument (2 given)
The constructor is called with a request argument:
def __init__(self, request):
self.request = request
And @action is a decorator that requires arguments. Using @action is only
needed if you need to tweak the default's, ie, to limit the calling to a
request_method, or to assign a renderer. If you're doing something like:
config.add_handler('home_page', '/', handler=Home, action='index')
Then you don't need to use @action if its going to return its own Response
object.
So the easy way to think of it, the methods in your handler are all actions
still (just like in a Pylons 1 controller!), *but*, if you need to modify how
the action is called, how the return value of it is handled (ie, using
renderer), or how the action is registered (ie, its name), then you use the
@action decorator to modify those parameters.
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
from pylons.controllers.util import Response
Then return a response object:
def login(self):
login = db.load_form('login.hh')
response = Response(login)
response.content_type = 'application/vnd.mozilla.xul+xml'
return response
There is also a render_template_to_response() function somewhere,
maybe in pylons.templating. It fills a template and creates a response
and returns it.
Yup.
Cheers,
Ben
--
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 2 users guide, first draft
On Sep 25, 2010, at 4:43 AM, Santhosh wrote: I checked the new developing version of pylons .The new version is entirely different from the older version . How can the developers follow this ? .The developers compelled to have change the developed software because if they remain in the older version there may be have no support . I don't understand what you mean by How can the developers follow this?. I posted the entire thread here to try and help any other developers follow it. It's quite different, because the current Pylons 1.0 implementation is more or less frozen, the implementation of most of it can't be changed since so much of it was directly subclassed by developers in their own apps. This style of customization was useful, but led to practical limitations on extensibility, and our own ability to move Pylons forward. Rather than re-inventing a bunch of code all over again, this new version went forward to build on other code to allow the new Pylons to be substantially more extensible, more efficient, and not have developers subclassing objects from Pylons (which limits our ability to make changes to the framework). I don't see what the worry is about remaining on the older version, the Pylons book and the documentation is not going anywhere. The same level of documentation support is going to remain available for Pylons 1.0, as there is a large installed base that most likely isn't transitioning all that quickly. There is no book for the new Pylons paradigms yet, so you'll see a much higher level of 'support' in the way of blog postings, and documentation for 1.0 for some time to come I believe. Cheers, Ben -- 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 2 users guide, first draft
On Sep 20, 2010, at 10:17 PM, Mike Orr wrote: How many full-time staff do you have available for two months? Just converting the hundreds of references to plain text would take hours, plus rewording the hundred-some pages of BFG docs and hundred-some other docs and a few more for SQLAlchemy (or you want to put the entire SQLAlchemy manual in too). The Encyclopedia of Pylons! I don't consider SQLAlchemy to be 'core' to Pylons, the core things are: - Sessions - Caching - Request Object - Response Object - Configuration - Dispatch - Template Rendering - Extensibility Points I really hope it doesn't take hundreds of pages of text to cover those. Hundreds and hundreds of pages and full-time staff are what books are for. If someone feels like that, they should write a book. :) Since many people use relational databases, we'll of course document how to write an app with it, like we do now. Anyways, I'll give it a shot first, and we'll see how it goes. -- 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 2 users guide, first draft
On Sep 19, 2010, at 6:36 PM, Ben Bangert wrote: BTW, for anyone else that just saw this message appear apparently out of the blue, Google Groups does have the full thread but failed to e-mail it out. To catch up, just go to: http://groups.google.com/group/pylons-devel/browse_thread/thread/cf357889d81e37b3 - Ben -- 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 2 users guide, first draft
On Sep 13, 2010, at 12:09 AM, Mike Orr wrote: I'll move some of the background paragraphs into separate pages. But this page will focus on the minimal app. Do you have any sample applications in both Pylons 1 and Pylons 2 that I can include? The more sophistocated one with multiple actions and a redirect may be a start. Not at the moment. Where is pylons.url now? request.url? from pylons.url import route_url Then just, route_url(request, 'route_name', **extra_args). It works largely like the BFG route_url, except honors an additional URL generator option that a route can have. This is how I have a sub-domain setup implemented. I'll prolly have to move route_url elsewhere, as there's a 'url' object hanging out in pylons/__init__.py. That may be too much to manage this phase. But I can link to the manuals. I guess I can make a Makefile that checks out the repositories of all the dependencies, and let Sphinx recursively build all the manuals. It started doing that with BFG and Pylons unexpectedly until I excluded their parent directory in conf.py. Ah, unfortunately that won't be good enough. Chris and I had chatted about trying to do something with Makefiles so that things would be included, but unfortunately this means that the included stuff retains reference to its own docs. This creates a very hacked up reading experience that is not going to be pleasant. I think we need the distinction for the transitional phase. Existing Pylons users need to understand where everything is. So they can find the docstrings in the source code, for one thing. And I, as a reader, would certainly want to know where the different Request methods come from. Otherwise it's too confusing, especially if I'm trying to figure out how Request changed. Well, I guess I just mean that I wouldn't waste the reader's time explaining the history of every object they might want to use, vs just saying, here is where you import the Request from, and then linking to its API docs. Our API docs can mention where it comes from, which methods come from where, etc. There's no reason to bog down the documentation explaining things that the reference API can explain as it documents the objects. This also means that as we document *everything* we expect Pylons users to have, we can include doc strings with Sphinx as needed, and editorialize them ourself as well. Sphinx makes it quite easy to ignore doc strings, or ignore module docs and supply your own. That'd be a good place to add in additional info about what comes from where, etc. If the docs are written with the expectation of a first-time Pylons user, then an existing Pylons user should be helped just as much to see where things are. I don't think de-emphasizing all the packages involved means that someone wouldn't know where something they need to use it. It just means we wouldn't waste the users time explaining the history of XX, or why ZZ was done. Keep the focus on how to do it, where the objects they need to import are, and point them to the reference API for said objects. I plan on adding a Design Defense page similar to what repoze.bfg has, that explains the 'why' of the design decisions in Pylons, so we can avoid repeating explanations throughout the docs, which should keep a tight focus on what the developer needs to know to get going. Then have a section for migrating users that explains what moved where, how to use new features with an existing app using the legacy_view, etc. For example, take sessions, Pylons 2 has an add_sessions that sets them up, and a request.session object they make use of for the session. I would imagine the Sessions section would indicate that you use add_sessions, how to use the request.session object, how to change the configuration options, and then send the user to the Session API docs. The Session API docs would include the complete set of configuration options, include any relevant info on the package (Beaker) that actually implements the sessions, and then have all the relevant module docs someone wanting all the details would need. This keeps the How to use Sessions bit short, concise, and fast for a developer to get going with, and then leaving the Reference API section to fully document the additional configuration options, what objects come from where, what type they are, etc. The existing Pylons user will generally jump straight to the Reference section when they need to know about an object, or its methods, or configuring it since they already know *how to use* it. Alternatively, a documentation style that might be worth trying, is what Mike Bayer has done with the latest version of the SQLAlchemy docs, which I'm kind of liking. That is, we'd have a Pylons Overview chapter, that includes a short bit on how to do all the standard things a Pylons user would want to do. Installation, Hello World, Using Sessions, etc. Each one then links to the full chapter, and the
Re: Pylons 2 users guide, first draft
On Sep 13, 2010, at 11:49 AM, Mike Orr wrote: Can it be made into a request method so you don't have to pass the request object? That would be more OO. Sure, request.url though makes it ambiguous if its the request URL vs a url function. Ian called it request.link in his example app using Routes, so maybe something like that? Or do you have to paste the markup text from the subprojects and convert all autoclass to class by hand? The problem with this is it would gradually drift out of date unless you went through every few months looking for differences between your docs and the originals, which would take a lot of time. Yes, you paste in the ones where appropriate (some of the sub-projects have none, or little docs, so we'd have to write those). This is part of the main issue btw, when we punt on doing it and just tell people to go look at that, and then the docs we pointed them to are incomplete, fail to mention how it applies in the context of the framework, etc. we just fail. Yes, it takes time to document the big picture and its parts effectively, in some cases we can copy/paste or still have Sphinx auto-generate an objects doc from the doc-string still, but in other cases we'll have to fill in gaps. Regardless of how its done, using and documenting Pylons as it consists of other projects requires time to keep the docs up to date as dependencies change. We're not doing anyone a favor by not addressing this issue at the moment. I don't think this means we need to document *all* of every single project, but we need to copy the docs or document anything ourself which we expect a Pylons developer to use that comes with Pylons. Except for BFG, the other dependencies are pretty much 'done' though, their docs aren't changing as they're not really changing anymore. Easy for you maybe. I still have to pour through the Sphinx manual sometimes wishing it would explain more clearly how to do something. If we could sprint together it would be easier. Agreed. I'm inclined to agree with James, that explaining it at a non-Python or non-web-developer level triples the workload. (Once to write the new text, and again to test all the examples on platforms you don't use.) Anyway, once we get the higher-level text squared away, the newbie text will be just a matter of filling in the background. And James' book provides a guide on what the newbie needs explained. Oh, I'd never aim it at a total non-Python or non-webdev. That's what books are for. Pylons documentation is for: 1) How do I do XXX with Pylons? 2) What are all the options to do XXX with Pylons? 3) How do I extend and utilize other web dev patterns with Pylons? These leads to a set of docs that are generally fairly short and concise to go over how to do various things (prolly a Quick Start / Overview), where each section hyperlinks them to the more extensive web dev patterns of that topic, all of which link to the reference docs (which show all the options). Once you know how add_sessions works, there's really no point in wasting space in the narrative docs explaining each option, when just a list of all the options and what they do would work just as well. The latter being the reference API docs. OK, maybe I can outsource that part to you. The first page (Intro) starts to get into that (at least re the changes since Pylons 1), but it just takes so long to write with all the necessary background that I postponed it. Plus, you guys can remember the new practical features better than I can. Sure, sounds good. I don't think I've encountered legacy_view yet. How does it work? There's a legacy pylons template that shows it. It essentially lets you hook up an existing Pylons app with zero changes, and then start adding new handlers with the Configurator. BTW, where is the cache? No where right now. Technically all you need to do is import the cache module from Beaker, set the options, and use @cache_region as desired. I should prolly add a setup function for that on the configurator and an import in Pylons though, as that'll make it feel more cohesive. Will there be an app_globals? I'd also suggest a thread_locals (or app_globals.locals), because uses keep wondering where to put threadlocals and end up reinventing it themselves. Technically, those can be added to the application registry as 'utilities', but it'd make sense maybe to have a config arg that lets you designate some functions that want to setup 'global' type objects, and when configuration is completely done, it'd call those functions and let them set it up. That'd also ensure that they're only setting up the 'app globals' when all the config information is available. I was disconcerted when I looked at the SQLAlchemy docs last week and the entire API section seemed to be missing. I actually thought it was a bug and figured it would come back in a few days. Then I noticed that the API docs were integrated with the
Re: pylons future plans?
On Jun 21, 2009, at 12:40 PM, Iain Duncan wrote: I don't know what Ben has up his sleeve but I think the core is essentially done with 0.9.7. The main incremental changes are on the periphery: improve @validate, replace @beaker_cache, improve the dependency documentation. I had a second job which sucked up all my time, and I'm just now getting back into programming.I expect the other developers have likewise been working on other stuff. Yep, that and wipe out the legacy code, which is actually about 1/3rd of the Pylons 0.9.7 code-base. Thanks Mike. I think for marketing purposes, it's pretty important that this kind of stuff be kept up to date. A lot of people checking Pylons out are going to want to make sure it isn't just going to 'stop' even though the stability is also a huge selling point. Yes, it does become tricky on what to sell in the way of 'new' when the scope of the framework is complete, and its mature. One of the issues is that Pylons itself isn't very plugin-compatible, and even Django's methodology of plugin apps is having issues scaling with conflicting settings.py files and such. Mmm, I was following that on pypefitters and am disappointed that efforts to continue seem to be being abandoned. I sure hope those involved decide it's worthwhile after all. Oh, the effort is still continuing. We're kicking around a new and small little framework called Pypes at the moment, that is designed for pluggable apps, components, etc. from the get-go in a way that scales to large numbers of plug-ins and settings. I believe this would keep with the philosophy of being flexible, while allowing much better re-usability between websites like how the Django apps allow a manner of re-usability. I'll post updates as we make more progress. Cheers, Ben --~--~-~--~~~---~--~~ 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: create_slug helper
On Jun 6, 2009, at 6:17 PM, Domen Kožar wrote: Hey guy, today I threw together this little function helper that I miss a lot in WebHelpers. unidecode module can be obtained from http://code.zemanta.com/tsolc/unidecode/releases/Unidecode-0.04.1.tar.gz Funny, as I was porting my blog from a Rails-based Typo one, to Pylons + MongoDB, I needed a slug generator. The Rails one used a package called stringex which is quite handy for other common slug conversions, and I posted Unideocde to Cheeseshop so its easy_installable. Here's my slugger (urlify), that is ported from the Ruby version, which also uses unidecode in addition to other common replacements for a slug: http://bitbucket.org/bbangert/minger/src/tip/minger/lib/stringex.py It would be handy to perhaps have those functions in WebHelpers, with an optional dependency on Unidecode to use it when available? Cheers, Ben --~--~-~--~~~---~--~~ 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: A Letter to the Authors of Web Authentication Libraries
On May 4, 2009, at 4:48 PM, Mike Lewis wrote: Having passwords encrypted in MD5 sent in plaintext is probably almost worse than just sending them in plaintext. I was about to say something similar, until I read more about Paul's scheme. :) Paul is using a hand-shake method whereby the password MD5 is only transmitted when the user first creates their account, *or* when they change their password. Other than that, the password *nor* the MD5 of the password is every transmitted at all. Instead the system relies on the client processing information, I believe this is an accurate summary: * Server knows MD5 * Client will know MD5 once it hashs the users password on the client- side Server includes in the form, a hidden field containing a timestamp, for use with their password, so client-side Javascript will return as the password value: MD5(timestamp + MD5(password)) Since the server knows the MD5(password) as well, it then does the same calculation, and see if they have the same value. If not, it can generate a new timestamp to ask for on the next request. Obviously, given the weakness of MD5, SHA-1 should be used (or even SHA-256). But other than that, this really does seem *waay* better than transmitting passwords in the clear every single time a user logs in. This way the crypted password is only sent in the clear for new account creation, and password changing (and even then, only the crypted form *never* the clear-text). For better security, the server should also provide a random salt for the original creation as well, such that a plan SHA/MD5 version of *just* the password will never be sent. Once the scheme is updated to SHA-1 or SHA-256, I think it'd be a great alternative to sending passwords in the clear over non-SSL as Paul suggests. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: 0.9.7 docs
On Nov 23, 2008, at 5:18 PM, Eric Ongerth wrote: I would be glad to contribute typo and spelling fixes to the new pylons docs at docs.pylonshq.com. I have been reading through them and I have such volume of small fixes to offer that it would not be most efficient to package them up in email, have someone else read through the correspondence, and so on. So I'm thinking I could help out more directly. So, a few simple steps, you'll want to check out the project and fork it first: 1) Login to bitbucket.org and setup a new account if you don't have one 2) Go to http://www.bitbucket.org/bbangert/pylons/overview/ and click the Fork project button 3) Checkout the your fork of the project 4) Commit your fixes to the docs in your fork This way I can then see that you forked it, and pull your changes from your repo. This is about the easiest way for me to track external changes to the Pylons project (which is where all the docs are, in the pylons/docs/en/ dir). It's also the easiest for me to pull new changes that you make to the docs. If you want to build the docs locally on your machine, make sure you have the latest Sphinx installed: easy_install Sphinx Then cd into the pylons/docs/en/ dir and: make html Which will build the HTML copy in a _build directory that you can take a look at. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Beaker 1.1 Release
Beaker 1.1 has been released. I only mention it here because those upgrading should note that the pickled file format for Beaker has CHANGED. This means that ALL PRIOR BEAKER CACHE FILES SHOULD BE REMOVED AFTER UPGRADING. Otherwise your application will throw errors as it won't find the expected values in the cache. Beaker 1.1 CHANGELOG: * file-based cache will not hold onto cached value once read from file; will create new value if the file is deleted as opposed to re-using what was last read. This allows external removal of files to be used as a cache-invalidation mechanism. * Sending type and other namespace config arguments to cache.get()/ cache.put()/cache.remove_value() is deprecated. The namespace configuration is now preferred at the Cache level, i.e. when you construct a Cache or call cache_manager.get_cache(). This removes the ambiguity of Cache's dictionary interface and has_key() methods, which have no awareness of those arguments. * the expiretime in use is stored in the cache itself, so that it is always available when calling has_key() and other methods. Between this change and the deprecation of 'type', the Cache no longer has any need to store cache configuration in memory per cache key, which in a dynamically-generated key scenario stores an arbitrarily large number of configurations - essentially a memory leak. * memcache caching has been vastly improved, no longer stores a list of all keys, which along the same theme prevented efficient usage for an arbitrarily large number of keys. The keys() method is now unimplemented, and cache.remove() clears the entire memcache cache across all namespaces. This is what the memcache API provides so it's the best we can do. * memcache caching passes along expiretime to the memcached time parameter, so that the cache itself can reduce its size for elements which are expired (memcache seems to manage its size in any case, this is just a hint to improve its operation). * replaced homegrown ThreadLocal implementation with threading.local, falls back to a 2.3 compat one for python2.4 Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Prototype works under Konqueror - jQuery ie - not
On Sep 2, 2008, at 5:24 AM, Bartosz R wrote: Actually, what has been said on the wiki is that Prototype and Scriptaculous are out of date and will not be maintained. It seems though that they are maintained That is referring to the WebHelper functions that use those libraries, not the actual libraries. The WebHelper functions were ported from Rails, and haven't been updated in quite awhile, thus are out of date and will not be maintained. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: 0.9.6.2 mis-packaged?
On Jun 24, 2008, at 11:32 AM, Kyle VanderBeek wrote: I just noticed the same thing happened in the 0.9.5 release of Beaker as well: [EMAIL PROTECTED] devel]$ tar tzf Beaker-0.9.5.tar.gz | grep \\._ Beaker-0.9.5/beaker/.___init__.py Beaker-0.9.5/beaker/._cache.py Beaker-0.9.5/beaker/._container.py Beaker-0.9.5/beaker/ext/.___init__.py Beaker-0.9.5/beaker/ext/._database.py Beaker-0.9.5/beaker/ext/._google.py Beaker-0.9.5/beaker/ext/._memcached.py Beaker-0.9.5/beaker/._middleware.py Beaker-0.9.5/beaker/._session.py Beaker-0.9.5/beaker/._util.py Beaker-0.9.5/._CHANGELOG Beaker-0.9.5/._LICENSE Beaker-0.9.5/._setup.py Beaker-0.9.5/tests/._test_cache.py Beaker-0.9.5/tests/._test_database.py Beaker-0.9.5/tests/._test_memcached.py This looks like some sort of mercurial artifact. How are packages being rolled for release? python setup.py sdist should roll these cleanly without this sort of problem It's actually a Leopard issue. There's a known issue with these _files being packaged in tars on OSX, prior to OSX 10.5, there was an environment flag that fixed the problem by forcing the OSX tar to not include them. It appears that since moving to OSX 10.5, this environment variables no longer works, and these damn files are back again. I'll likely need to move my packaging off to a separate linux host to avoid having these files included in the future. If you're packaging these packages for an OS distro, please feel free to remove them from the package. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Docs docs docs!
I've gotten the basic Sphinx setup working now, and have gotten the
Getting Started doc done. Here's what the Sphinx doc build looks like
so far:
http://docs.pylonshq.com/
I've got most of the module API docs laid out too. I should note that
this doc effort covers a few related packages as well, to update them
with Sphinx restructured text syntax (the previous pudge doc string
syntax breaks in a few places under Sphinx).
If you'd like to get started, here's the steps. First, I've put
together a single script that will create a virtualenv, install
Mercurial into it, grab all the source repo's for core Pylons packages
(pylons, beaker, weberror, webhelpers, routes), and do svn checkouts
of the other core packages (Paste, PasteScript, PasteDeploy, WebOb).
To run it, just use the following command:
curl http://pylonshq.com/download/0.9.7/go-pylons-dev.py | python - --
no-site-packages superdevenv
That will setup the whole thing underneath the directory
'superdevenv', this command does require svn to already be installed,
but doesn't require Mercurial to be installed as that's setup for you
in the directory you choose ('superdevenv' in this example).
To run the Sphinx build locally, first install Sphinx: ./superdevenv/
bin/easy_install -U Sphinx. Then go to superdevenv/pylons/pylons/docs
and type: make html
That should build the HTML source in a _build dir where you can then
browse it.
All the packages will also be setup in develop mode, so you can then
work on docs in various packages so we'll have powerful module API
docs for here:
http://docs.pylonshq.com/modindex.html
Which is helpful because we'll want to cross-link to them frequently
to avoid repetition in the actual docs.
So far, I've gotten some of the TOC filled in, and have setup
placeholders in sections with what I believe should be covered by that
section. I still need to add an Internationalization section as well.
If you'd like to help out, and/or have already stated that, just setup
a dev env like I mention here, find a section of the docs you'd like
to work on, and announce it here so we avoid working on the same
doc. :)Or we could just setup a page on the wiki to track who's
working on which sections.
Cheers,
Ben
smime.p7s
Description: S/MIME cryptographic signature
Re: Docs docs docs!
On Apr 9, 2008, at 6:08 AM, Graham Higgins wrote: I'd like to be involved Great to see you getting back into the docs! I'm assembling the first revision of the Pylons docs that will use Sphinx and be in the Pylons repo so that anyone installing Pylons will have a copy of the docs with them. However, before I can start yanking docs from the wiki that different people wrote, I need to know the license and copyright intention of those who wrote the docs. :) For the others that have expressed interest, I'll need a similar contribution license put together to ensure that I have appropriate rights for distribution of all contributed docs to Pylons as its messy to sort out copyright issues later. I was originally considering the GNU Free Documentation License (GFDL), but some of the criticism of its points seem rather valid, so I'm now looking at the BSD Documentation License as Pylons is entirely MIT licensed (which is essentially identical to the 2-clause BSD license). This is rather important as the GFDL actually has some odd issues when citing code that's covered by a different license from what I can tell. Repoze has a rather nice form put together here: http://repoze.org/contributing.html I'll modify as needed for those wishing to contribute to the Pylons core docs. That work for everyone? Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: pylons's nose plugin configuration file versus hardcoded test.ini
On Mar 28, 2008, at 4:50 PM, Agustin Villena wrote: Therefore, supporting multiple test.ini files (for testing multiple configuration of componentes, like plugins) will not be allowed in the current Pylons? I don't understand what you mean that its not allowed in Pylons. It's in *your* project, *your* files. The default is to use test.ini, but you can change it to use anything you want, Pylons has nothing to do with that except it dropped that default in there to begin with. The Pylons nose plugin specifically takes an ini option that you can provide on your own to nose. --with-pylons=TEST.INI, or whatever one you want to use. The only change I can think of that might make it easier in Pylons is if the test/__init__.py was able to figure out what option you had specified to --with-pylons, though I'm unsure how to get that info at the moment. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: A Buffet replacement
On Mar 4, 2008, at 9:36 PM, Ian Bicking wrote: It's a rendering factory someone wrote. A little like Buffet, except no entry points, no standardized way to instantiate the object, and no particular need to make the render callable have a completely consistent signature. Yet another level of obfuscation and misunderstanding, and yet another thing that will trip up those wanting to try and change how a template language is configured. Putting a 15-line recipe into the pylons template seems really scrappy. All of Pylons is a recipe. It's a recipe to configure Paste, a batch of middleware, and do some dispatching with Routes. The entire thing is no more scrappy than having a render function that uses the template engine. I don't see this MakoRenderer being any less or more scrappy than a basic render function, but at least everyone I showed the render function to is 100% aware of what it does, and how they could change it. While MakoRenderer is another what the heck is this? how come I can't just configure the template engine?. MakeRenderer seems simpler than this, with no recipe stuff stuck in there. I'm baffled that the hundreds of lines of code in the templateproposal, the setuptools entry points, the plugin hooks, the limiting render calls (which prevent you from accessing the Genshi stream object which some ppl want...) is simpler than a 7 line render function. Even with TemplateProposal, 95% of the code I pasted is still needed in pylons.templating because it handles cache functionality and populating the template variables with the Pylons globals. I've written some extensive docs and committed them regarding how to use the render functions and write one: http://pylonshq.com/project/pylonshq/browser/pylons/templating.py Let's ask the Pylons list, whether using this package: http://svn.pythonpaste.org/Paste/TemplateProposal/branches/TemplateProposal-MSO/ Is easier than using the few lines of code needed for the render functions. Also, keep in mind that for someone to even start to override one of the plugins in templateproposal, first you get to explain setuptools entry points, how to extend them, how to register your own, then finally you get to write a render function... ick. The point of Pylons is to try and make things easy through simplicity and elegance, so far Buffet and its abstraction ilk has been the exact opposite. After seeing how simple and short it is to just write a little render function that does *exactly* what you want, its hard to see the advantage in accepting template language limitations and abstractions. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Beaker: 'expiretime' and memcached backend
On Feb 21, 2008, at 2:53 AM, Andrew Stromnov wrote: Is 'expiretime' passed to memcached backend? It seems that 'key:value; pair stays forever in memcached backend The expired time isn't passed to the backends, when Beaker stores a value in any backend, it records the stored time in addition to the value. Then upon retrieval of the value (and its stored time), it does a check against the expiration to see if the value has expired, and recreates it if it has. Until Beaker next accesses and invalidates the value, it will not be removed from the backend. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: AW: Routes 2 spec
On Jan 17, 2008, at 2:19 AM, Andrew Smart wrote: I had some trouble with the HTTP var which has been used to identify the subdomain. In my configuration the subdomain must be retrieved from HTTP_X_FORWARDED_HOST and not from HTTP_HOST. Ian wrote something about egg:PasteDeploy#prefix which I haven't investigated due to time restrictions on my side, but I'm not sure if this would help in the routes area. To make it short: routes just looks at HTTP_HOST, but in a Apache mod_proxy environment the relevant subdomain is not found there but in HTTP_X_FORWARDED_HOST. Ah, indeed, that can be fixed in the current Routes as well. - Ben smime.p7s Description: S/MIME cryptographic signature
Re: Routes 2 spec
On Jan 17, 2008, at 12:21 PM, Mike Orr wrote: Good idea, active and passive routes are easy to explain. Active means participates in matching; passive means the route does nothing unless you invoke it for generation. Should we change .connect to .active or is that too radical? I think .connect is still fine. url_for is currently a function that does several other things in addition to generating the route. E.g., adding the application prefix, doing route memory. It calls m.generate() to do the generation. I'm investigating whether it would be feasable to make 'm' and 'url_for' the same object... but it would mean putting all this extra stuff into 'm' that I'm not sure if it belongs there. It probably doesn't need to be. Though as an implementation detail, and a way to avoid SOP's in Routes, if the url_for object was made by the RouteMap, then the RoutesMiddleware could put the current url_for object into environ. No SOP needed then, and a framework can make a global SOP to the url_for if it wants to (which Pylons likely would). I wasn't planning to support the other dict methods, but maybe we could. If we just say that url_for.routes is a dict of routes by name (as I was planning to implement), that would do the same. Otherwise if we offered .items(), what would the values be? The values would be the Route objects, assuming there is still route objects in Routes 2. I had generally assumed there would be, since there needs to be something to hold onto the various options for each connected route, and how to generate it. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Routes 2 spec
On Jan 15, 2008, at 8:14 AM, Chris AtLee wrote:
I just had a chance to look at the Routes 2 spec, and this was my
first thought as well. Having route names as attributes on the
RouteMap object will be very confusing since the methods used to
manipulate the RouteMap will be indistinguishable from the routes
themselves. RouteMap.add(foobar, ...) or RouteMap.connect(foobar,
...) is clearer. You also risk name conflicts with RouteMap.foobar -
what happens if I want a route called fail or redirect?
Mmm, it's not such a big deal I guess to use connect. The main issue
with the current syntax, as Mike points out, is that the argument's
change positions with named routes right now, so maybe
map.named('name', 'path'...) and all map.named connections require the
Route name to be present. This would at least solve the moving
argument issue with the current map.connect.
I think with respect to the default routes and route minimization,
explicit is better than implicit. If users want
/{controller}/{action}/{id} with defaults and minimization, there
should be three routes defined, for /{controller},
/{controller}/{action} and /{controller}/{action}/{id}. When a
user creates a new project via paste, these routes can be setup for
him.
Definitely, this is why Route minimization is gone entirely from
generation. Your route you name is the only possible route that will
be used for generation when you generate using the name. This is much
more predictable.
I also suggested to Mike having the user make all the minimized Routes.
Cheers,
Ben
smime.p7s
Description: S/MIME cryptographic signature
Re: Cleaning some house of imports and one letters
On Dec 19, 2007, at 8:37 AM, Ian Bicking wrote: My concern here has actually been the reactions I've gotten from people experienced with Python when they first look at Pylons. Several different people have mentioned this -- not as a horrible thing, but as something that stuck out to them, and just seemed to smell a bit off. It's more about the emotional response. Yes, and I think the emotional response does count. It's why many people choose Python over Ruby, the syntax gives them a better emotional response in most cases. import * isn't just about ugly, it's also how easy it is to dive into code you don't know and find your way around. Again, for people experienced with Python but not Pylons this can be a problem. More than one import * in a file is horrible, but that isn't happening -- but just one import * makes it harder to understand a module. It also makes things feel 'magic' since variables just end up there, and many tools that do basic variable checks can't properly account for names landing in a module from a import * statement. As a special case, few people understand what pylons.g is and self-documentation there would be really helpful. When someone mentioned app_locals as a name, that actually made more sense to me than app_globals. But that it is unclear if it's a local or global value is also a sign of some underlying weirdness there. Agreed. pylons.c is just a little odd -- if we could change the render function to just take substitution variables as keyword arguments then I personally would just stop using pylons.c, and probably be happier for it. Right now I guess I have to do variables=dict(...), which isn't horrible but doesn't look pretty for such a common construct. Quite a few people actually want this, also because it forces their templates to fail. Of course, many people absolutely require the current methodology since they setup 'c' options in the BaseController for use in all templates, which is a great and intended use of the global ability to set 'c' options. Whether thats a 'good' usage or not is somewhat more debateable, since in systems where you can't do this, its hardly too crippling to have a function you call that sets up some basic options, which also makes it clearer how those extra options land in the template Besides being hard to understand, they are a pain to debug. That's actually my concern with them. Oh, and they have weird performance characteristics that have frequently caught people. I don't see any way to remove them but we could go back to just thread-locals, and tell people not to use Pylons apps in front of Pylons apps (does anyone actually do this???). We are incurring a lot of complexity with SOP's for a 0.01% use-case here... But short of getting request-local values via a function instead of a proxy, I don't think there's a very good solution. Attaching stuff to the request at least makes them a little clearer, and makes the performance at least slightly clearer (you can do something like c = request.c, and get a bound value for c that isn't a proxy). What makes the performance clearer also, as Max noted, also makes it impossible to import the name directly at a global scope. I'm really not a fan of having to dig into a hierarchy under a 'request' object to get to everything. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Cleaning some house of imports and one letters
On Dec 19, 2007, at 1:32 PM, Mike Orr wrote: from pylons import render, request, response, session Is that a move of pylons.template.render ? Not intentionally, my bad: from pylons.templating import render Should be in there. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Paste project and Pylons
On Dec 12, 2007, at 11:29 PM, Max Ischenko wrote: It's kind of a closed source open source package. It is a brainchild of a single person and seems to remain under full ownership of him, with very little external contributions. Documentation sucks, which is to be expected -- since no one else contributing and Ian knows his code perfectly. Releases are also infrequent which is also understandable. Currently, Phil Jenvey, Clark Evans, and myself all have direct commit access to Paste, PasteScript, and PasteDeploy. We've made quite a few contributions, especially ones that of course benefitted Pylons. Generally, Ian has always been willing to knock out a new release whenever something big enough was waiting in it. He's also accepted submitted patches, as I've also applied to Paste. Right now releases are infrequent because changes are infrequent. It's quite solid and does everything in its scope it was designed to do. It definitely isn't the best way for some things, which is why WebOb, WebError, and WebTest were branched off the code-base and rolled into their own packages. Also, some bits in it are very very difficult if not downright brain-damaging to code-trace, which is part of why I replaced the error documents middleware with a new 20 line version (the old one was over 300 lines or so), that is trivial to follow. So I think after Pylons 0.9.7, the only parts we'll really be using from Paste, is PasteScript and the stuff that allows project templates to be made and projects to be run (paster serve). Though if that's split into a more concise and well documented project, I see no reason we couldn't switch to that. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: template_engine.default considered harmful
On Dec 12, 2007, at 1:42 PM, Mike Orr wrote: Why do you find it difficult to change the default engine, and what would be easier? In a one-engine scenario, you simply change the obvious template_engine argument in the config.init_app() call. In a multi-engine scenario you have to do the list dance, but what would be better? It should prolly be noted that the ini file is for deployment specific settings. Nothing so critical to the apps internal structuring should be in the ini like the template engine to use. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
