In discussing with chrism and Ian Bicking porting Pyramid to Python 3,
it became clear that we might want to do some other changes at the
same time, enough to warrant a new major version, aka Pyramid 2. I've
outlined the ideas on the following wiki page:
https://github.com/Pylons/pyramid/wiki/P
http://www.plope.com/pyramid_auth_design_api_postmortem
Michael
On Sun, Mar 13, 2011 at 7:29 AM, Mike Orr wrote:
> In discussing with chrism and Ian Bicking porting Pyramid to Python 3,
> it became clear that we might want to do some other changes at the
> same time, enough to warrant a new ma
i like ini files so much better than yaml. i realize it is brainstorming at
this point, but is there any killer feature of yaml or something?
--
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@goog
Howdy!
- Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below.
This is not just a good idea, it's the slaw; with the ratification of
PEP there finally exists a standard protocol for Python 3 support.
- Replace Paste, PasteDeploy, and PasteScript with "something".
- "paste
i like ini files so much better than yaml. i realize it is
brainstorming at this point, but is there any killer feature of yaml or
something?
Consider:
[server:main]
host = 127.0.0.1, ::1
port = 80, 8080
How do you get a list of ports as integers?
server:
host: [127.0.0.1, ::1]
thanks for the info. i guess I'm thinking if you need something to support
such a complex "configuration" that an ini file can't handle it, aren't you
programming at that point and if so, why not use a real programming
language? in java they does this stuff all the time. I know that the line is
On Sun, Mar 13, 2011 at 11:25 AM, Thomas G. Willis wrote:
> thanks for the info. i guess I'm thinking if you need something to support
> such a complex "configuration" that an ini file can't handle it, aren't you
> programming at that point and if so, why not use a real programming
> language? in
On Sun, Mar 13, 2011 at 11:08 AM, Alice Bevan–McGregor
wrote:
> Howdy!
>
>> - Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below.
>
> This is not just a good idea, it's the slaw; with the ratification of PEP
> there finally exists a standard protocol for Python 3 support.
>
>>
Added Marrow to the list. I looked over the components home pages and
had two concerns:
- marrow.server.http is asynchronous. I don't think we want to make
such a large leap from multithreaded to asynchronous in the default
server. People have just gotten used to making their apps thread-safe;
I d
Hello,
On Mar 13, 2011, at 3:29 PM, Mike Orr wrote:
> - Replace the INI file with an YAML file?
YAML is not as good as it can be for config file format:
* It has slow parsers.
* There's risk of bloating YAML file with Python type annotations (tags),
e.g. !!bool, !!python/tuple when deali
On Sun, Mar 13, 2011 at 1:40 PM, Andrey Popp <8may...@gmail.com> wrote:
> Hello,
>
> On Mar 13, 2011, at 3:29 PM, Mike Orr wrote:
>> - Replace the INI file with an YAML file?
>
> YAML is not as good as it can be for config file format:
>
> * It has slow parsers.
>
> * There's risk of bloating YAM
On 2011-03-13, at 5:29 AM, Mike Orr wrote:
> Here's a summary of the ideas on the wiki page:
> ...
> - Possible new names for Paster and its components: glue ("Glue is the new
> Paste!"), Create, Serve, karnak.
Regarding names: A good name is unique enough that blog posts and discussion on
it c
> Added to the list, but can you specify what exactly you want this
> admin interface to do? What does "persistent" and "agnostic" mean in
> an admin interface?
Sorry, I mean persistence-agnostic -- interface should not be targeted to
specific relational databases (like django.contrib.admin do), i
On 2011-3-14 01:53, Thomas G. Willis wrote:
i like ini files so much better than yaml.
Same for me.
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
--
You received this message because you are subscribed t
On 2011-3-14 02:11, Alice Bevan–McGregor wrote:
i like ini files so much better than yaml. i realize it is
brainstorming at this point, but is there any killer feature of yaml
or something?
Consider:
[server:main]
host = 127.0.0.1, ::1
port = 80, 8080
How do you get a list of ports as integer
On Mon, Mar 14, 2011 at 02:03:33PM +0800, Wichert Akkerman wrote:
> On 2011-3-14 01:53, Thomas G. Willis wrote:
> >i like ini files so much better than yaml.
>
> Same for me.
Are we collecting votes here? Because I'd like to add a +1 for INI and
against YAML.
Marius Gedminas
--
This is the Loc
On 2011-03-13 16:50:01 -0400, Mike Orr said:
On Sun, Mar 13, 2011 at 1:40 PM, Andrey Popp
<8may...@gmail.com> wrote:
Hello,
On Mar 13, 2011, at 3:29 PM, Mike Orr wrote:
- Replace the INI file with an YAML file?
YAML is not as good as it can be for config file format:
* It has slow parsers.
On 2011-03-13 16:32:14 -0400, Mike Orr said:
- marrow.server.http is asynchronous. I don't think we want to make
such a large leap from multithreaded to asynchronous in the default
server. People have just gotten used to making their apps thread-safe;
I don't think we want to force them to mak
On 2011-03-13 15:58:20 -0400, Mike Orr said:
On Sun, Mar 13, 2011 at 11:08 AM, Alice Bevan–McGregor
wrote:
* marrow.wsgi.objects (WebOb) request/response/exceptions
These are fully WebOb compatible? WebOb has become essentially the only
multi-framework Request/Response, so I dont' want to i
Just a quick note, I've managed to convince GitHub to grant me the
marrow account name (which was previously parked), so urls starting
with:
https://github.com/pulp/
Should now reference:
https://github.com/marrow/
Thank you,
— Alice.
--
You received this message because you are s
Just my quick 2c:
YAML vs. INI? Just use Python.
Why depend on another component and parser (think: user debugging of
configuration errors with mis-typed config files).
Why fuss over "how does this support lists" and other similar issues?
And, for me, the most important issue is that when I se
Migration to Python 3 aside (which has to happen, sooner or later) my
concern here is that moving to Pyramid 2 so quickly is a bit premature
given the paint is barely dry on Pyramid 1.
Should we not wait until there are some actual projects built with
Pyramid, and we get feedback from real world u
Personally, I vote against YAML if that means yet another dependency to
Pyramid. INI works fine if you have only or mostly scalar types, json is
ugly and pure Python code should work too, however I believe importing a
config module would bring a lot of grief and dependency on globals, so
it s
On Mon, Mar 14, 2011 at 12:37 PM, danjac...@gmail.com
wrote:
> Migration to Python 3 aside (which has to happen, sooner or later) my
> concern here is that moving to Pyramid 2 so quickly is a bit premature
> given the paint is barely dry on Pyramid 1.
We aren't moving quickly but just capturing p
IMO the only thing we need for configuration is a 100% compatible, no extra
features version of Paster that is easier to read and extend, and that runs
on Python 3.2. Call it 'baster'. It will understand Paster entry points,
paste deploy .ini files and be able to 'baster serve'. The templating
feat
Speaking of asynchronous... what is the future of WSGI regarding
asynchronous serving? With websockets (or whatever the standard will
emerge out of it) coming fully supported in the next generation of
browsers (what, within a year? two?), is this even a possibility for
WSGI and with that Pyra
There has been an ongoing discussion between the WSGI developers and
Twisted about how to be more compatible. The upshot is that
asynchronous servers need some kind of token in the output stream that
means "I'm not ready; come back later." Other middlewares would have
to pass this token through unc
As far as I know there are at least two (major) db systems that support
asynchronicity, PostgreSQL via psycopg2 and MongoDB via pymongo, and
that's good. If WSGI is capable of being asynchronous (I'm not very
familiar with the internals of the protocol), even if that only requires
the ready s
Yes on the naming.
Please be careful not to use a single generic name like "glue"
"marrow" and others... As developers and users, we are completely
dependent on search engine results, and guess what there are already
valid prior use for these words...
I already have to search for "pylons pyramid
What Pyramid really needs is more female contributors ;).
That said, I thought that this would be an appropriate place to notify the
community that the ball is rolling on revamping PasteScript/PasteDeploy.
Whit Morriss and I have created three repos on GitHub entitled
HTTPPaste(standalone http web
On Mar 15, 2011, at 5:27 PM, Joe Dallago wrote:
> What Pyramid really needs is more female contributors ;).
Working on that, its actually part of the reason for having an explicit Code of
Conduct for the community. Pylons has historically had rather good diversity in
contributors both in geogra
WSGIServe will replace 'paster serve'. I will definitely look into removing
the Nagle algorithm. Seems as though we have an opportunity to really
improve the speed of paste.
On Mar 15, 2011 9:14 PM, "Ben Bangert" wrote:
On Mar 15, 2011, at 5:27 PM, Joe Dallago wrote:
> What Pyramid really nee
On Mar 15, 2011, at 6:43 PM, Joe Dallago wrote:
> WSGIServe will replace 'paster serve'. I will definitely look into removing
> the Nagle algorithm. Seems as though we have an opportunity to really
> improve the speed of paste.
Without Nagles algorithm, it's pretty close to CherryPy's, which
That's awesome news. Isn't there also a grab bag of wsgi utils/middleware in
there somewhere? I know some are now in stand alone packages but things like
paste.proxy I wasn't aware of being in other projects.
--
You received this message because you are subscribed to the Google Groups
"pylons
On 2011-03-15 18:43:31 -0700, Joe Dallago said:
WSGIServe will replace 'paster serve'.
For the love of humanity, anyone writing a new web server, or
performing substantial work to modernize an existing one, needs to read
O'Reilly's "HTTP: The Definitive Guide"[1], James Marshall's "HTTP Made
Please be careful not to use a single generic name like "glue" "marrow"
and others... As developers and users, we are completely dependent on
search engine results, and guess what there are already valid prior use
for these words...
Despite WebCore being, unbeknownst to me at the time, a compo
[Cross posted between the source of the discussion and the Web-SIG for
additional discussion there.]
On 2011-03-15 14:54:18 -0700, Mike Orr said:
There has been an ongoing discussion between the WSGI developers and
Twisted about how to be more compatible. The upshot is that
asynchronous serve
Proposal: import eventlet
Done! Invented in 1963, coroutines let me use WSGI asynchronously without
rewriting anything. What could be sweeter?
--
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@goo
On 2011-03-24 13:59:16 -0700, Daniel Holth said:
Proposal: import eventlet
Done! Invented in 1963, coroutines let me use WSGI asynchronously
without rewriting anything. What could be sweeter?
Cross-platform, cross-implementation. (Both re: the greenlet C extension.)
Python 3 support, esp. n
None of those points say anything about a perfect implementation of
coroutines (I heard lua has the best ones) versus callback-style or some
other more-stackful-style of asynchronicity. On the other hand for example
I'm sure there is a lot of Twisted code that doesn't need to be rewritten. I
ju
40 matches
Mail list logo
