Michael,
You're offer to collaborate is wonderful; your instance on a real
specification before integration is perfectly reasonable.
I do see the primary distinction between the SQL-API project and
SQLAlchemy as one about specification vs implementation. While the
users of SA are those building
Just out of interest,
This SQL-API sounds remarkably similar to ROE in smalltalk. Did you guys
get any inspiration from this particular project ?
regards,
Huy
A few months past, Ian Bicking (of SQLObject fame) presented an idea for
a SQL-API which would overlap significantly with SQLAlchemy.
Michael Bayer wrote:
lets collaborate, but lets come up with some semblance of a real spec
first. this before cracking open SQLAlchemy which in any case would
only be one particular implementation of many possible ones, and
shouldnt have to change its filestructure and release schedule around
Clark C. Evans wrote:
[cut short - sorry]
How does this impact SQLAlchemy? Well, frankly, it need not if you so
choose. However, I think it would be a huge boon to SQLAlchemy if you
all wanted to play along. Assuming that the project was bootstrapped
from some of your existing modules:
-
Hi Clark,
Let me start by saying that I appreciate your efforts to bring the
conversation back to things that can be done together. You started off
with the suggestion of building up a new SQL-API, and then migrated
toward using the SQLAlchemy code as a starting point.
I see where Jonathan is co
lets collaborate, but lets come up with some semblance of a real spec
first. this before cracking open SQLAlchemy which in any case would
only be one particular implementation of many possible ones, and
shouldnt have to change its filestructure and release schedule around
just to meet a p
Uncle! Uncle!
I think this conversation has come to a close. The SQLAPI project
is based on the premise that a layer between DB-API and a full ORM would
be useful; and more specifically, that this separate layer should be a
distinct project with its own trunk and release schedule.
I've had a t
On 5/10/06, Clark C. Evans <[EMAIL PROTECTED]> wrote:
On Wed, May 10, 2006 at 04:00:01PM -0600, Jonathan Ellis wrote:| There are any number of projects that can provide warm fuzzy learning| experiences, but given limited funds, it only makes sense to give| priority to ones that will benefit other P
On Wed, May 10, 2006 at 04:00:01PM -0600, Jonathan Ellis wrote:
| There are any number of projects that can provide warm fuzzy learning
| experiences, but given limited funds, it only makes sense to give
| priority to ones that will benefit other Python developers as well.
You dramatically unders
On 5/10/06, Clark C. Evans <[EMAIL PROTECTED]> wrote:
On Wed, May 10, 2006 at 12:35:04PM -0600, Jonathan Ellis wrote:| "Hey guys, you have a working codebase that does everything we need, but| some of us have a severe case of NIH and would rather you spend a huge
| amount of effort conforming to ou
On Wed, May 10, 2006 at 05:45:11PM -0400, Michael Bayer wrote:
| no, thats not good enough, the mechanism by which SQLAlchemy
| generates the SQL can also be totally separated from the constructs.
| the constructs dont know anything about their own compilation. you
| might talk about one or
On May 10, 2006, at 4:18 PM, Clark C. Evans wrote:
| This is complicated by the fact that SQLAlchemy's SQL construction
| facilities are highly tuned at this point and have a lot of subtle
| features that are not only difficult to implement, but are also very
| critical, for reasons that may no
On Wed, May 10, 2006 at 01:41:23PM -0700, Ed Suominen wrote:
| So why is it unrealistic to imagine that these lower-level capabilities
| of SQLAlchemy, which are already in place, working, and wonderfully
| documented, could be adopted as the universal solution you're looking
| for? If there's some
> - defining an exception hierarchy corresponding with the
>SQL-92 and SQL-99 specifications.
Unless I misunderstand it, I don't see a great value in this one.
There's already an exception hierarchy which is defined by DBAPI2,
and is (kind of) supported by implementations. The support in SQ
On 5/10/06, Ed Suominen <[EMAIL PROTECTED]> wrote:
Ian, you might be interested to know that I only use the lower-levelselect, update, etc. capabilities of SQLAlchemy and have no currentplans to use the mappers. I have a lot of SQL experience and justhaven't found that higher level of abstraction u
Ian, you might be interested to know that I only use the lower-level
select, update, etc. capabilities of SQLAlchemy and have no current
plans to use the mappers. I have a lot of SQL experience and just
haven't found that higher level of abstraction useful in my
applications. However, I do find SQL
Ed Suominen wrote:
The question I would ask is this: What does SQLAlchemy lack that is
sought in this proposed SQL-API, and how much demand is there for that
functionality?
It's not what SQLAlchemy lacks, it's what it has. It's too much all at
once. It's scope does not fit what I want, and I
On Wed, May 10, 2006 at 01:01:51PM -0400, Michael Bayer wrote:
| Im not really sure what "duplicating effort" you have made, perhaps
| you could show me some examplesi havent heard anything about the
| current userbase having to "duplicate" parts of SA at all
I'm not a current user of SA,
On Wed, May 10, 2006 at 01:02:36PM -0700, Ed Suominen wrote:
| The question I would ask is this: What does SQLAlchemy lack that is
| sought in this proposed SQL-API, and how much demand is there for that
| functionality?
I, unfortunately, confounded two issues here. One of them is the
concrete wo
On Wed, May 10, 2006 at 12:35:04PM -0600, Jonathan Ellis wrote:
| "Hey guys, you have a working codebase that does everything we need, but
| some of us have a severe case of NIH and would rather you spend a huge
| amount of effort conforming to our (vapor) api rather than build on yours."
Ok. Can
Jonathan Ellis wrote:
> "Hey guys, you have a working codebase that does everything we need,
> but some of us have a severe case of NIH and would rather you spend
> a huge amount of effort conforming to our (vapor) api rather than
> build on yours."
>
> Honestly that is how SQL-API comes across
"Hey guys, you have a working codebase that does everything we need, but some of us have a severe case of NIH and would rather you spend a huge amount of effort conforming to our (vapor) api rather than build on yours."
Honestly that is how SQL-API comes across to me.
Michael Bayer wrote:
But if the PEP-making process is interested in what SQLAlchemy does and
how it does it, then show me what list to sign up on; while I have a
lot of trouble following the typical "PEP-oriented" discussion, I can
certainly offer my thoughts.
Probably the most appropriate
On May 10, 2006, at 1:01 PM, Michael Bayer wrote:
its main goal is to provide Python with a very powerful, stable and
useable "results-based" SQL toolset, giving it a great advantage
over other development platforms that threaten its relevance.
clarification: giving *Python* an advantage
Hi Clark -
Im not really sure what "duplicating effort" you have made, perhaps
you could show me some examplesi havent heard anything about the
current userbase having to "duplicate" parts of SA at all; just
people building new things on top of it (like ActiveMapper, SQLSoup
and Pocoo
25 matches
Mail list logo
