Re: GSoC, Python 3 dependencies, Paste
I also plan on helping port Pyramid to Python 3 as my GSOC project. You can check out my application on my blog(jayd3e.com) for more details. As far as Paste goes, it has unofficially been decided that we will be going with an entirely separate HTTP server, as opposed to isolating 'paster serve'. I know a few people are in favor of using a wsgi server called WiseGuy( https://github.com/wsgicabal/wiseguy), there a variety of others as well though. 'Paster create' is currently being isolated by someone afaik, forget who. I personally think that you should choose to port Pyramid as your project, because we could always use more help for that effort. On Apr 4, 2011 11:19 AM, Juliusz Gonera jgon...@gmail.com wrote: Hi, I thought that it will be easier if I just post here instead of trying to catch someone on IRC. I have quite a few questions regarding GSoC. First of all, I'm not quite sure if I should propose the specific project or it should be given to me by one of the mentors. I was thinking about porting the necessary packages to Python 3, but I guess it could be too much for a single project (or maybe not?). Because of that I though about concentrating on Paste issue. I don't know if any decision has been made (whether to update Paste, rewrite create and serve or use something else, e.g. Marrow) and I'm almost sure I'm not the one to make such decisions. However, I have to put something more detailed in the application form. Regarding Paste and comments on https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm: 1. YAML vs INI - is there any decision? 2. Is marrow.script not being argparse-compatible a big issue? Wouldn't it be easy to fix? 3. The same goes for marrow.server.http being asynchronous. As long as it was multithreaded too I don't know how this could be a problem (but maybe I don't know enough). And according to the readme on github ( https://github.com/marrow/marrow.server.http), multi-threading is on the todo list: threaded — Enable multi-threading. This is currently unimplemented pending support up-stream in marrow.server and defaults to False. 4. I'm uncomfortable with the direction of these libs personally. They seem to be more researchy than practical in lots of cases. Could somebody elaborate? I'm not trying to question anything, I don't know that much, I would just like to know what is wrong with Marrow. 5. If adapting and improving Marrow is not an option, then what should I do if I want to work on porting Pyramid to Python 3? On IRC Blaise Laflamme suggested CherryPy. What do you think? I thought that this is more development related so I'm posting to devel. Let me know if I was wrong. Regards, -- Juliusz Gonera http://juliuszgonera.com/ -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: GSoC, Python 3 dependencies, Paste
IIRC Pyramid doesn't really depend on Paste in any important way. You could
just try to get it working under CherryPy, uWSGI or wsgiref for example, and
get the configuration dictionary some other way besides having Paste parse
.ini into {}.
I hope Ian's Web Application Format proposal gets specified. Then I can just
follow the specification and choose between potential Paste Deploy
replacements based on some other criteria than 'is a mandatory Pyramid
dependency'.
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: GSoC, Python 3 dependencies, Paste
On Mon, 2011-04-04 at 10:52 -0700, Alice Bevan–McGregor wrote: Regarding Paste and comments on https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm: 1. YAML vs INI - is there any decision? There isn't any particular reason not to go with both, INI for backwards compatibility (using similar logic to YAML's parsing of lists, numbers, etc., and YAML for the future. YAML's native rich structures are just too handy, and if you know JSON, you can write YAML. I'll be rolling that into marrow.config. 2. Is marrow.script not being argparse-compatible a big issue? Wouldn't it be easy to fix? marrow.script was designed to be explicitly argparse/optparse/getopt incompatible. Paste Script's wrapping of optparse made things more complicated, not easier. Unless, of course, someone can come up with an _excellent_ reason why marrow.script should be rewritten to utilize argparse. Marrow.script, OTOH, wraps nothing. It's a direct command line - argspec converter and help text generator. The ease of just throwing a function or class at marrow.script (new or existing!) is highly desirable. 3. The same goes for marrow.server.http being asynchronous. As long as it was multithreaded too I don't know how this could be a problem (but maybe I don't know enough). And according to the readme on github (https://github.com/marrow/marrow.server.http), multi-threading is on the todo list: threaded — Enable multi-threading. This is currently unimplemented pending support up-stream in marrow.server and defaults to False. Seems I need to fix that reference. Threading is supported (now that it's supported in marrow.server) using a Futures-based thread pool. The underlying server being async has never been a bad thing in any of the benchmarking I've done, including C10K and 12KR/sec concurrency and speed benchmarks, even with the thread pool enabled. 4. I'm uncomfortable with the direction of these libs personally. They seem to be more researchy than practical in lots of cases. Could somebody elaborate? I'm not trying to question anything, I don't know that much, I would just like to know what is wrong with Marrow. Same! :D Just because the packages take a distinctly different approach to some things than Paste/WebOb/Django/pkgname here doesn't make them bad, unusable, or unstable. In fact, for PyPi releases, the packages require 100% unit test coverage, full documentation, and 2.6+/3.1+ polygot compatibility; that already makes them somewhat better than (some of) the alternatives. I think researchy describes some of the marrow stuff pretty well (that doesn't imply bad, unusable or unstable, it just implies opinionatedness that is outside the current mainstream). For example, in this message you've quoted use of a futures-based asynchronous server that says it implements WSGI 2.0, but WSGI 2.0 does not yet exist in any ratified form. I don't see WSGI 2.0 draft compatibility as a goal that we need to explore under GSOC. I think it's great you're pushing the envelope, but we really just need some very simple things that are well behind any of the curves you're at the front of. In the meantime, I don't much care if we get a PasteDeploy replacement that works under Python 3.X for GSOC. Pyramid apps don't strictly require PasteDeploy, they can be run without any declarative configuration. I also don't care much if we don't get a PasteScript replacement for GSOC either. Having a command line wrapper that does a bunch of stuff is handy but not required to make things run. We actually really just need some bits of Paste itself (the FileApp app, StaticURLParser, some of the auth_tkt bits) to work in order to reach a reasonable goal for 3.X compat. After that, we can think about how we'd like to wrap it up nicely for usage. I see the PasteScript/PasteDeploy stuff as a sort of last-resort project for GSOC, because it's pretty gratuituous until we get all the other dependencies ported. I'm already using marrow.tags (and the widgeting it provides), marrow.script, and marrow.blueprint in a number of projects, all with great success. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: GSoC, Python 3 dependencies, Paste
On 2011-04-04 11:31:15 -0700, Chris McDonough said: I think researchy describes some of the marrow stuff pretty well (that doesn't imply bad, unusable or unstable, it just implies opinionatedness that is outside the current mainstream). For example, in this message you've quoted use of a futures-based asynchronous server that says it implements WSGI 2.0, but WSGI 2.0 does not yet exist in any ratified form. I don't see WSGI 2.0 draft compatibility as a goal that we need to explore under GSOC. I think it's great you're pushing the envelope, but we really just need some very simple things that are well behind any of the curves you're at the front of. I agree with regards to m.s.http; it was originally developed as a 'proof of concept' server to be developed in parallel with my rewritten PEP 444. However, making it speak PEP 333(3) is relatively trivial. At the grossest level (callable syntax), you use the following p-code decorator: def make_pep444(fn): def inner(environ): def start(status, headers): start.status = status start.headers = headers body = fn(environ, start) return start.status, start.headers, body return inner In the meantime, I don't much care if we get a PasteDeploy replacement that works under Python 3.X for GSOC. Pyramid apps don't strictly require PasteDeploy, they can be run without any declarative configuration. I also don't care much if we don't get a PasteScript replacement for GSOC either. Having a command line wrapper that does a bunch of stuff is handy but not required to make things run. They remain nice goals, however +1 on pairing down to the minimum. — Alice. -- 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 31/03/2011 18:58, Mike Orr wrote: On Thu, Mar 31, 2011 at 7:14 AM, Chris Withersch...@simplistix.co.uk wrote: On 15/03/2011 20:01, Ben Bangert wrote: Here's a quick way to know which one to post to: pylons-devel - Discussion about development of pylons project libraries such as pylons/pyramid/etc. pylons-discuss - General discussion about best practices of development, asking for help, etc. How about just merging the lists? Is there really so much volume as to justify two lists? Having a -devel and -discuss list always feels like elitism to me, in that the people who can actually help hang out on -devel, and the people who need it on -discuss :-S That sounds more like a prejudice than anything that's happening on the lists. 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? so that those who don't care about minor/theoretical development discussions and trivial This page on the website doesn't work Surely that actually belongs on -devel? (or would you advocate a third -website list ;-) ) change the version number in this place can skip it. All the developers are on the -discuss list and answer questions there. As a user and part time developer, I wasn't even aware of the -discuss list until this discussion came up! 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? ;-) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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: GSoC, Python 3 dependencies, Paste
On Mon, 2011-04-04 at 18:05 +0200, Juliusz Gonera wrote: Hi, I thought that it will be easier if I just post here instead of trying to catch someone on IRC. I have quite a few questions regarding GSoC. First of all, I'm not quite sure if I should propose the specific project or it should be given to me by one of the mentors. I was thinking about porting the necessary packages to Python 3, but I guess it could be too much for a single project (or maybe not?). I think asking a single student to port everything is too much. At this point, I think there's an opportunity to get two students working on the porting effort. Because of that I though about concentrating on Paste issue. I don't know if any decision has been made (whether to update Paste, rewrite create and serve or use something else, e.g. Marrow) and I'm almost sure I'm not the one to make such decisions. However, I have to put something more detailed in the application form. To be honest, I'm not sure we can manage paste replacement as a GSOC project, especially from scratch. Paste is relatively large, and encompasses many things. Furthermore, we actually use very little of Paste in Pyramid. Pyramid will happily run without PasteDeploy or PasteScript, so porting either is not a hot issue for Python 3 compatibility in the short term. Pyramid won't run without some things from the Paste package proper (namely its static file application named StaticURLParser, and some auth_tkt components). These will need to be replaced in order to run on Python 3. But it's a *lot* easier just to cut and paste and fix these specific components than it is to port the entirety of Paste, so I'd suggest we just do that. I think we should hold off on passing judgment on replacing Paste until after GSOC, when we know that we can run some form of Pyramid (albeit without PasteDeploy or PasteScript support) successfully. Regarding Paste and comments on https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm: 1. YAML vs INI - is there any decision? 2. Is marrow.script not being argparse-compatible a big issue? Wouldn't it be easy to fix? 3. The same goes for marrow.server.http being asynchronous. As long as it was multithreaded too I don't know how this could be a problem (but maybe I don't know enough). And according to the readme on github (https://github.com/marrow/marrow.server.http), multi-threading is on the todo list: threaded — Enable multi-threading. This is currently unimplemented pending support up-stream in marrow.server and defaults to False. 4. I'm uncomfortable with the direction of these libs personally. They seem to be more researchy than practical in lots of cases. Could somebody elaborate? I'm not trying to question anything, I don't know that much, I would just like to know what is wrong with Marrow. 5. If adapting and improving Marrow is not an option, then what should I do if I want to work on porting Pyramid to Python 3? On IRC Blaise Laflamme suggested CherryPy. What do you think? I thought that this is more development related so I'm posting to devel. Let me know if I was wrong. I think all the above stuff is probably too hard to tackle under GSOC. I suspect we should just get the bare minimum ported and see where we are. There is a list of dependencies on the https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm page that indicates the packages that need porting. I'd suggest that creating a proposal to port some of those would be best-received. - C Regards, -- Juliusz Gonera http://juliuszgonera.com/ -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
