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.
