Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #91032 > unrolled thread

Camelot a good tool for me

Back to article view | Back to comp.lang.python

Contents

  Camelot a good tool for me Cecil Westerhof <Cecil@decebal.nl> - 2015-05-22 09:59 +0200
    Re: Camelot a good tool for me Dan Sommers <dan@tombstonezero.net> - 2015-05-22 12:38 +0000
      Re: Camelot a good tool for me Ben Finney <ben+python@benfinney.id.au> - 2015-05-22 23:02 +1000
      Re: Camelot a good tool for me Cecil Westerhof <Cecil@decebal.nl> - 2015-05-22 15:11 +0200
        Re: Camelot a good tool for me Tim Golden <mail@timgolden.me.uk> - 2015-05-22 14:29 +0100
        Re: Camelot a good tool for me Laura Creighton <lac@openend.se> - 2015-05-22 15:57 +0200
        Re: Camelot a good tool for me Lele Gaifax <lele@metapensiero.it> - 2015-05-22 19:24 +0200
        Re: Camelot a good tool for me Chris Angelico <rosuav@gmail.com> - 2015-05-23 03:37 +1000
        Re: Camelot a good tool for me Laura Creighton <lac@openend.se> - 2015-05-22 19:56 +0200
        Re: Camelot a good tool for me Lele Gaifax <lele@metapensiero.it> - 2015-05-22 21:12 +0200
        Re: Camelot a good tool for me Chris Angelico <rosuav@gmail.com> - 2015-05-23 18:59 +1000
        Re: Camelot a good tool for me Lele Gaifax <lele@metapensiero.it> - 2015-05-24 15:15 +0200
    Re: Camelot a good tool for me Laura Creighton <lac@openend.se> - 2015-05-22 15:03 +0200
      Re: Camelot a good tool for me OT beauty of Tk Christian Gollwitzer <auriocus@gmx.de> - 2015-05-22 21:52 +0200
        Re: Camelot a good tool for me OT beauty of Tk Laura Creighton <lac@openend.se> - 2015-05-22 22:13 +0200
    Re: Camelot a good tool for me Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-22 15:24 +0100
    Re: Camelot a good tool for me felix <felix@epepm.cupet.cu> - 2015-05-22 10:50 -0400
    Re: Camelot a good tool for me Tim Chase <python.list@tim.thechases.com> - 2015-05-24 07:05 -0500

#91032 — Camelot a good tool for me

I want to learn a lot of things. For example writing database and
graphical applications. For database I decided on SQLAlchemy and GUI
on Tkinter. In principal I want to write Python 3 applications.

I came across Camelot. As I understand it, this is something to write
graphical database applications fast. It works with Qt, but that
should not be a big problem. It is just to get me started. But it
seems only to work with 2.7 and not 3. Is this true?

Would Camelot be a good tool to get me started, or can I better bite
the bullet and just start with Tkinter and SQLAlchemy?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#91033

On Fri, 22 May 2015 09:59:02 +0200, Cecil Westerhof wrote:

> Would Camelot be a good tool to get me started, or can I better bite
> the bullet and just start with Tkinter and SQLAlchemy?

Bite the bullet and learn SQL.

SQLAlchemy -> Database :: Python -> Assembly Language.

HTH,
Dan

[toc] | [prev] | [next] | [standalone]

#91035

Dan Sommers <dan@tombstonezero.net> writes:

> On Fri, 22 May 2015 09:59:02 +0200, Cecil Westerhof wrote:
>
> > Would Camelot be a good tool to get me started, or can I better bite
> > the bullet and just start with Tkinter and SQLAlchemy?
>
> Bite the bullet and learn SQL.

Good advice in the long term. However, one can't learn *everything* at
once.

Cecil, use SQLAlchemy and you will have a firm foundation that will not
hold you back from learning SQL at some future point; on the other hand,
you will be using a library that makes it *much* more sensible to work
with database structures and queries from yuor Python code.

The same is not necessarily true of a lot of database APIs; they will
frequently simplify to the point of obscuring your understanding of the
database, and learning SQL later is hindered to that extent. SQLAlchemy,
though, does not have that problem.

> SQLAlchemy -> Database :: Python -> Assembly Language.

I think you're making my point for me :-)

-- 
 \       “Philosophy is questions that may never be answered. Religion |
  `\              is answers that may never be questioned.” —anonymous |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#91037

Op Friday 22 May 2015 14:38 CEST schreef Dan Sommers:

> On Fri, 22 May 2015 09:59:02 +0200, Cecil Westerhof wrote:
>
>> Would Camelot be a good tool to get me started, or can I better
>> bite the bullet and just start with Tkinter and SQLAlchemy?
>
> Bite the bullet and learn SQL.

I know SQL. Until now I almost always did everything with SQL. The
problem is that you are expected not to use it. With Python you are
supposed to work with SQLAlchemy and with Java Hibernate.


> SQLAlchemy -> Database :: Python -> Assembly Language.

If I follow your logic, I should stop working with Python and start
using Assembly Language. It is fun, but I prefer other languages.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#91038

On 22/05/2015 14:11, Cecil Westerhof wrote:
> Op Friday 22 May 2015 14:38 CEST schreef Dan Sommers:
> 
>> On Fri, 22 May 2015 09:59:02 +0200, Cecil Westerhof wrote:
>>
>>> Would Camelot be a good tool to get me started, or can I better
>>> bite the bullet and just start with Tkinter and SQLAlchemy?
>>
>> Bite the bullet and learn SQL.
> 
> I know SQL. Until now I almost always did everything with SQL. The
> problem is that you are expected not to use it. With Python you are
> supposed to work with SQLAlchemy and with Java Hibernate.

Not at all. You're supposed to work with whatever is most effective for
yourself and any collaborators you may for the project you're working
on. (And by "effective" I include "giving the most satisfaction").

I use raw SQL most of the time (with a very lightweight wrapper), and
very occasionally I use SQLAlchemy where I find myself re-implementing
it poorly (to coin a phrase). But that's me. And I've been a
professional database developer for 25 years, most of it having nothing
to do with Python.

SQLAlchemy's great; it's worth taking the time to learn how to use it.
But certainly don't feel you *have* to.


TJG

[toc] | [prev] | [next] | [standalone]

#91041

In a message of Fri, 22 May 2015 15:11:03 +0200, Cecil Westerhof writes:
>I know SQL. Until now I almost always did everything with SQL. The
>problem is that you are expected not to use it. With Python you are
>supposed to work with SQLAlchemy and with Java Hibernate.

I think you have got the wrong idea.  Lots of Python programmers use
SQLAlchemy but there is no 'you should use this' about it.  In my
corner of the world, everybody uses SQL.  The great buring questions
are 'MySQL vs PostgreSQL?' and 'Should you ever use SQLite?'
The people who have tried SQLAlchemy really didn't like it, and of course
the people who haven't tried it do what their friends do, as usual.

If you already know SQL get yourself a MySQL server, a SQLite or PostGreSQL
server, depending on what is more like what you are used to.  There are
tons of online tutorials on how to use these.  And if you already know SQL
things will be pretty straight forward for you.

>Cecil Westerhof
>Senior Software Engineer
>LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Laura

[toc] | [prev] | [next] | [standalone]

#91053

Laura Creighton <lac@openend.se> writes:

> In my corner of the world, everybody uses SQL.
> [...]
> The people who have tried SQLAlchemy really didn't like it, and of course
> the people who haven't tried it do what their friends do, as usual.

If these sentences are related, you must live in a very strange corner!

;-)

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#91055

On Sat, May 23, 2015 at 3:24 AM, Lele Gaifax <lele@metapensiero.it> wrote:
> Laura Creighton <lac@openend.se> writes:
>
>> In my corner of the world, everybody uses SQL.
>> [...]
>> The people who have tried SQLAlchemy really didn't like it, and of course
>> the people who haven't tried it do what their friends do, as usual.
>
> If these sentences are related, you must live in a very strange corner!
>
> ;-)

Not sure why. I'm in the same corner, I think - I use SQL, and not
SQLAlchemy if I can help it. I'd much rather just use psycopg2 and do
my own queries. SQLAlchemy has its uses, and it does solve a number of
issues in reasonably clean ways, but I don't like a few of its facets,
including its peculiar way of doing foreign key relationships. (You
put a foreign key in the child, and you put a relationship in the
parent, which feels backwards.) There's a lot of magic going on. When
magic works, it's great; but when anything goes wrong, it's harder to
see what happened. (Also, when does a transaction begin and end? If
you session.commit() in the middle of iterating over a query, will it
break the query? What if you roll back? Can you see, instantly, in
your code?) Even if the ORM layer is practically perfect in every way,
there's still value in learning SQL; for instance, if you drop to a
command-line interpreter like PostgreSQL's psql, or if you switch to
another language, or anything like that, it's helpful to know what's
going on under the covers. And if you have to know SQL anyway, the
advantage of the abstraction layer has to justify the cost of learning
an additional, not a replacement, API.

So, while SQLAlchemy is definitely a lot better than most I've seen,
it's still not really good enough for me to use everywhere. I'm mostly
going to stick to the Python DB API 2.0.

ChrisA

[toc] | [prev] | [next] | [standalone]

#91059

In a message of Fri, 22 May 2015 19:24:30 +0200, Lele Gaifax writes:
>Laura Creighton <lac@openend.se> writes:
>
>> In my corner of the world, everybody uses SQL.
>> [...]
>> The people who have tried SQLAlchemy really didn't like it, and of course
>> the people who haven't tried it do what their friends do, as usual.
>
>If these sentences are related, you must live in a very strange corner!
>
>;-)

>ciao, lele.
>-- 
>nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
>real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
>lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

Just looks like home to me. :)  But explains why, should you ever
want to use SQLALchemy for something you would have to look long and
hard around here to find somebody who uses it -- whereas practically
every bar downtown (near both Chalmers university and a lot of IT jobs)
will find you somebody who knows MySQL.  (They won't all know the
Python interface, though.)  That MySQL was invented in Sweden
probably has a lot to do with this.  But I'm a PostgreSQL partisan,
though these days I am rather more fond of non-relational
databases like MongoDB which I suppose is even ranker heresy. :)

Laura

[toc] | [prev] | [next] | [standalone]

#91063

Chris Angelico <rosuav@gmail.com> writes:

> On Sat, May 23, 2015 at 3:24 AM, Lele Gaifax <lele@metapensiero.it> wrote:
>> Laura Creighton <lac@openend.se> writes:
>>
>>> In my corner of the world, everybody uses SQL.
>>> [...]
>>> The people who have tried SQLAlchemy really didn't like it, and of course
>>> the people who haven't tried it do what their friends do, as usual.
>>
>> If these sentences are related, you must live in a very strange corner!
>>
>> ;-)

> Not sure why. I'm in the same corner, I think - I use SQL, and not
> SQLAlchemy if I can help it. I'd much rather just use psycopg2 and do
> my own queries.

Didn't mean to be so serious, but anyway...

> SQLAlchemy has its uses, and it does solve a number of
> issues in reasonably clean ways, but I don't like a few of its facets,
> including its peculiar way of doing foreign key relationships. (You
> put a foreign key in the child, and you put a relationship in the
> parent, which feels backwards.)

You are conflating two different layers, core and ORM. ORM relationships can
be declared either on the parent or on the child, it's up to your taste.

> There's a lot of magic going on.

Not in my experience, but I started using it long ago, so I'm biased.

> When magic works, it's great; but when anything goes wrong, it's harder to
> see what happened.

The same can be said of almost any upper layer in a software stack.

> Also, when does a transaction begin and end?

When I need transactions (that is, when I'm changing the database) I'm very
picky and use explicit begins, commits and rollbacks, so I don't recall
experiencing that doubt.

> If you session.commit() in the middle of iterating over a query, will it
> break the query? What if you roll back? Can you see, instantly, in your
> code?

Why would you do that? Are you closing your files while you iterate them,
without leaving the loop in some way at the same time?

> Even if the ORM layer is practically perfect in every way,
> there's still value in learning SQL; for instance, if you drop to a
> command-line interpreter like PostgreSQL's psql, or if you switch to
> another language, or anything like that, it's helpful to know what's
> going on under the covers. And if you have to know SQL anyway, the
> advantage of the abstraction layer has to justify the cost of learning
> an additional, not a replacement, API.

No doubt on that. Working with SQLAlchemy is not an alterative to knowing SQL
fairly well. SA does hide "details" (name quoting syntax, to mention one
obvious detail), but does not even try to hide the fact that it's talking SQL
all the way down.

I often have to deal with multiple DB engines at the same time, and being
able to "write" my queries with an abstract syntax is very valuable for me.

> So, while SQLAlchemy is definitely a lot better than most I've seen,
> it's still not really good enough for me to use everywhere. I'm mostly
> going to stick to the Python DB API 2.0.

Again, I fully agree: one should work with whatever tool he feels comfortable
with!

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#91106

On Sat, May 23, 2015 at 5:12 AM, Lele Gaifax <lele@metapensiero.it> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> SQLAlchemy has its uses, and it does solve a number of
>> issues in reasonably clean ways, but I don't like a few of its facets,
>> including its peculiar way of doing foreign key relationships. (You
>> put a foreign key in the child, and you put a relationship in the
>> parent, which feels backwards.)
>
> You are conflating two different layers, core and ORM. ORM relationships can
> be declared either on the parent or on the child, it's up to your taste.

Not sure why that's distinguishable. If I have two tables like this:

Users:
    id sequential primary key
    name text

Tasks
    id sequential primary key
    owner integer
    assignee integer

Both the owner and the assignee refer to the Users table; the owner is
a mandatory connection (every task was created by someone, who
initially owns it), and the assignee is an optional connection (a
newly-created task isn't assigned to anyone). With me so far? Okay.

Now, if I were to represent these tables in SQLAlchemy, obviously I
need to have foreign key relationships encoded in SQLAlchemy. But if
I'm to enforce these relationships on the underlying database, it's
equally obvious that I need foreign key constraints. I would expect
that a relationship encoded in SQLAlchemy should cause the creation of
a constraint in the database. They're fundamentally the same thing.

My point about backwards is that my tables here are declared in a
strict order: parent table, then child table. In the child table, a
constraint is created by saying "references Users", and the Users
table already exists. At no point is there ever a forward reference.
Code would look like this:

create table Users (id serial primary key, name text not null default '');
create table Tasks (id serial primary key, owner integer not null
references Users, assignee integer references Users);

But with SQLAlchemy, you have a tag in the Users table's definition
saying that it has a relationship with Tasks, as well as a foreign key
in Tasks stating the connection to Users. That violates "Define Before
Use", which isn't a strict policy, but it does feel a little bit
"dirty".

>> When magic works, it's great; but when anything goes wrong, it's harder to
>> see what happened.
>
> The same can be said of almost any upper layer in a software stack.

Precisely. All magic has to justify itself. Some can, easily. Some
can't. A lot is in the middle, where it's part of the tradeoffs.

>> Also, when does a transaction begin and end?
>
> When I need transactions (that is, when I'm changing the database) I'm very
> picky and use explicit begins, commits and rollbacks, so I don't recall
> experiencing that doubt.

That's all very well when you write your own code. Now try picking up
someone else's code. Or, for a mid-way concern, try explaining to a
junior developer how to make sure his transactions are right. With
psycopg2, it's easy enough to do this:

with conn, conn.cursor() as cur:
    cur.execute("....")
    cur.execute("....")

When the with block exits, the transaction is either committed (if all
went well) or rolled back (if an exception was raised). It's very
simple, easy to do, and easy to audit ("all SQL queries must be inside
a with block that grants a cursor", and possibly "cursor-granting with
blocks must not be nested").

>> If you session.commit() in the middle of iterating over a query, will it
>> break the query? What if you roll back? Can you see, instantly, in your
>> code?
>
> Why would you do that? Are you closing your files while you iterate them,
> without leaving the loop in some way at the same time?

There's advice out there on the internet that says that committing
periodically in the middle of a big job makes your code run faster.
It's from the PHP + MySQL school of thought, where the assumption is
that finishing is the most important thing, finishing quickly is a
close second, and guaranteeing correctness isn't even on the radar.
Now try coping with code that was written under that model.

Fortunately, I haven't actually seen anything quite like this in
SQLAlchemy. The worst I saw was a case where someone was iterating
over a query and performed another query, which did indeed break the
fetching of results. But the more magic you have, the less obvious
that is.

>> Even if the ORM layer is practically perfect in every way,
>> there's still value in learning SQL; for instance, if you drop to a
>> command-line interpreter like PostgreSQL's psql, or if you switch to
>> another language, or anything like that, it's helpful to know what's
>> going on under the covers. And if you have to know SQL anyway, the
>> advantage of the abstraction layer has to justify the cost of learning
>> an additional, not a replacement, API.
>
> No doubt on that. Working with SQLAlchemy is not an alterative to knowing SQL
> fairly well. SA does hide "details" (name quoting syntax, to mention one
> obvious detail), but does not even try to hide the fact that it's talking SQL
> all the way down.

Yep. SQLAlchemy is miles ahead of some of the things I've worked with.
And I have to say, the declarative style of laying out a table is
excellent. Using psycopg2 or SQLAlchemy is a matter of taste; using
either of the above or DBExpert is a matter of insanity.

> I often have to deal with multiple DB engines at the same time, and being
> able to "write" my queries with an abstract syntax is very valuable for me.

Hmm, I'm not sure there's all that much that this helps with. Thanks
to a consistent PEP 249 API, changing database engines is often just a
matter of changing one import and a connection construction line
(which you'd have to do anyway, given that the credentials will
change). What else is there for SQLAlchemy to paper over? The
differences remain; the common ground is already common.

>> So, while SQLAlchemy is definitely a lot better than most I've seen,
>> it's still not really good enough for me to use everywhere. I'm mostly
>> going to stick to the Python DB API 2.0.
>
> Again, I fully agree: one should work with whatever tool he feels comfortable
> with!

Yep. Both are good enough to use. Personally, I'll use psycopg2, but
if you want to use SQLAlchemy, I won't think you a fool. Same if you
choose Django (I use Flask), etc. They're close enough that
situational differences make all the argument.

Just don't use MySQL if you can help it.

*ducks for cover*

ChrisA

[toc] | [prev] | [next] | [standalone]

#91178

Chris Angelico <rosuav@gmail.com> writes:

> On Sat, May 23, 2015 at 5:12 AM, Lele Gaifax <lele@metapensiero.it> wrote:
>> You are conflating two different layers, core and ORM. ORM relationships can
>> be declared either on the parent or on the child, it's up to your taste.
>
> Not sure why that's distinguishable. If I have two tables like this:
>
> Users:
>     id sequential primary key
>     name text
>
> Tasks
>     id sequential primary key
>     owner integer
>     assignee integer
>
> Both the owner and the assignee refer to the Users table; the owner is
> a mandatory connection (every task was created by someone, who
> initially owns it), and the assignee is an optional connection (a
> newly-created task isn't assigned to anyone). With me so far? Okay.
>
> Now, if I were to represent these tables in SQLAlchemy, obviously I
> need to have foreign key relationships encoded in SQLAlchemy. But if
> I'm to enforce these relationships on the underlying database, it's
> equally obvious that I need foreign key constraints. I would expect
> that a relationship encoded in SQLAlchemy should cause the creation of
> a constraint in the database. They're fundamentally the same thing.

No. A "relationship" is an ORM thingie, and can happily exist without an
underlaying constraint in the database.

> My point about backwards is that my tables here are declared in a
> strict order: parent table, then child table. In the child table, a
> constraint is created by saying "references Users", and the Users
> table already exists. At no point is there ever a forward reference.
> Code would look like this:
>
> create table Users (id serial primary key, name text not null default '');
> create table Tasks (id serial primary key, owner integer not null
> references Users, assignee integer references Users);
>
> But with SQLAlchemy, you have a tag in the Users table's definition
> saying that it has a relationship with Tasks, as well as a foreign key
> in Tasks stating the connection to Users. That violates "Define Before
> Use", which isn't a strict policy, but it does feel a little bit
> "dirty".

As said, that's not how I'd code it, as I'd probably implement those classes
as

class User(Base):
     id = Column(...)
     name = Column(...)

class Task(Base):
     id = Column(...)
     owner_id = Column(...)
     assignee_id = Column(...)

     owned_by = relationship('User', primaryjoin='User.id==Task.owner_id',
                             backref='own_tasks')
     assigned_to = relationship('User', primaryjoin='User.id==Task.assigned_id',
                             backref='assigned_tasks')

>>> When magic works, it's great; but when anything goes wrong, it's harder to
>>> see what happened.
>>
>> The same can be said of almost any upper layer in a software stack.
>
> Precisely. All magic has to justify itself. Some can, easily. Some
> can't. A lot is in the middle, where it's part of the tradeoffs.
>
>>> Also, when does a transaction begin and end?
>>
>> When I need transactions (that is, when I'm changing the database) I'm very
>> picky and use explicit begins, commits and rollbacks, so I don't recall
>> experiencing that doubt.
>
> That's all very well when you write your own code. Now try picking up
> someone else's code. Or, for a mid-way concern, try explaining to a
> junior developer how to make sure his transactions are right. With
> psycopg2, it's easy enough to do this:
>
> with conn, conn.cursor() as cur:
>     cur.execute("....")
>     cur.execute("....")

You're kidding, of course: on SA side you imagine a complex code written by
somebody else, while on the other side a plain sequence of statements. You can
write almost the same code either with SA (which at it's low level has a plain
DBAPI connection):

  http://docs.sqlalchemy.org/en/rel_1_0/core/connections.html#using-transactions

> When the with block exits, the transaction is either committed (if all
> went well) or rolled back (if an exception was raised). It's very
> simple, easy to do, and easy to audit ("all SQL queries must be inside
> a with block that grants a cursor", and possibly "cursor-granting with
> blocks must not be nested").

As you can see, there is almost no difference when using the equivalent SA
idiom.

>
>>> If you session.commit() in the middle of iterating over a query, will it
>>> break the query? What if you roll back? Can you see, instantly, in your
>>> code?
>>
>> Why would you do that? Are you closing your files while you iterate them,
>> without leaving the loop in some way at the same time?
>
> There's advice out there on the internet that says that committing
> periodically in the middle of a big job makes your code run faster.

No, I think you mean "flushing" a session, not committing. And again, that's
usually recommended when using the ORM layer, not at the SQL core we are
talking about here.

> It's from the PHP + MySQL school of thought, where the assumption is
> that finishing is the most important thing, finishing quickly is a
> close second, and guaranteeing correctness isn't even on the radar.
> Now try coping with code that was written under that model.

That's not how I code database-based applications, neither when using plain
DBAPI, nor with SA. I cannot even imagine using such a wierd approach.

> Fortunately, I haven't actually seen anything quite like this in
> SQLAlchemy. The worst I saw was a case where someone was iterating
> over a query and performed another query, which did indeed break the
> fetching of results. But the more magic you have, the less obvious
> that is.

I cannot understand your example: it's not so uncommon the need to perform a
query for each row of a previous one, and it's surely well supported at every
level, in SA.

>> I often have to deal with multiple DB engines at the same time, and being
>> able to "write" my queries with an abstract syntax is very valuable for me.
>
> Hmm, I'm not sure there's all that much that this helps with. Thanks
> to a consistent PEP 249 API, changing database engines is often just a
> matter of changing one import and a connection construction line
> (which you'd have to do anyway, given that the credentials will
> change). What else is there for SQLAlchemy to paper over? The
> differences remain; the common ground is already common.

There are a lot of subtle differences in how SQL is implemented by the various
engines out there. Things like "names quoting", "pagination", "data types",
...

Until you do not need a nice way to write the same thing against different
engines you won't appreciate how nice it is being able to do that :)

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#91036

I don't know anything about Camelot.  Tkinter produces widgets that are
in no way as pretty graphically as is expected nowadays -- or indeed for
at least 15 years.  If this matters to you -- or if you are building for
customers if it matters to them, then Tkinter is not a good choice.

Widget libraries are more different than they are similar. So while
learning one can give you some very basic ideas about how widgets work,
and what a callback is, etc -- it doesn't smooth the learning curve
for learning what it is you eventually want to use all that much.
If you already know where you are heading for, then I would just start
learning that.

That said, most of the code I write for me, has, for the longest time
used Tkinter.  I don't care all that much about the ugliness, and I
can write them quite quickly.  How much this has to do with Tkinter
programs being smaller than similar programs in other systems -- some
gui toolkits are _really_ _really_ verbose -- and how
much this has to do with the fact that I am familar with Tkinter I do
not know.

A final concern is where would you like to run these programs when you
are done writing them.  These days, I want most of the new things I
write for me to run on my 7 inch android tablet, and Tkinter doesn't
run there.  About 6 months ago I started learning kivy and am
using this for widgets now -- and converting some of my old programs
to use kivy. Kivy works with both Python 2 and Python 3, runs on
the desktop as well as in mobile devices, and produces the prettiest
widgets you could ask for.  It's under active development, and comes
with a huge directory of examples showing how to use the various
widgets.

So if you are still shopping for a widget kit, it is worth a look.

Laura

[toc] | [prev] | [next] | [standalone]

#91068 — Re: Camelot a good tool for me OT beauty of Tk

Am 22.05.15 um 15:03 schrieb Laura Creighton:
> I don't know anything about Camelot.  Tkinter produces widgets that are
> in no way as pretty graphically as is expected nowadays -- or indeed for
> at least 15 years.  If this matters to you -- or if you are building for
> customers if it matters to them, then Tkinter is not a good choice.

Tkinter doesn't need to be ugly. At least if you are on Windows or OSX, 
you can make near-native looking programs, if you stick to the simple 
rule to use ttk everywhere and never try to override background colors 
etc. Another important rule is that icons play an important role. A 
decent icon set makes a big difference.

An example of a Tk program on Windows 7 is this:

http://artist.bam.de/en/gallery/screenshots/aRTistDemoversionStarted.jpg

Would you spot that it is not a "native" Windows app? It's raw Tcl/Tk 
rather than Tkinter, but there is no specific reason why it couldn't be 
done in Python/Tkinter. On Linux, yes, the default themes are quite 
ugly. There are some workarounds, like loading the bitmap plastik theme, 
but this is substantially more (configuration) work.

And in the end a decent look needs a decent designer -  where to place 
which widgets, how to set the resizing options, that takes some 
experience to get it right.

	Christian

[toc] | [prev] | [next] | [standalone]

#91071 — Re: Camelot a good tool for me OT beauty of Tk

In a message of Fri, 22 May 2015 21:52:27 +0200, Christian Gollwitzer writes:
>Am 22.05.15 um 15:03 schrieb Laura Creighton:
>> I don't know anything about Camelot.  Tkinter produces widgets that are
>> in no way as pretty graphically as is expected nowadays -- or indeed for
>> at least 15 years.  If this matters to you -- or if you are building for
>> customers if it matters to them, then Tkinter is not a good choice.
>
>Tkinter doesn't need to be ugly. At least if you are on Windows or OSX, 
>you can make near-native looking programs, if you stick to the simple 
>rule to use ttk everywhere and never try to override background colors 
>etc. Another important rule is that icons play an important role. A 
>decent icon set makes a big difference.

I didn't know that.  Thank you.

>Would you spot that it is not a "native" Windows app? It's raw Tcl/Tk 
>rather than Tkinter, but there is no specific reason why it couldn't be 
>done in Python/Tkinter. On Linux, yes, the default themes are quite 
>ugly. There are some workarounds, like loading the bitmap plastik theme, 
>but this is substantially more (configuration) work.

And, of course, I live in the linux world.  I didn't know about
the bitmap plastik theme, either, thank you again.

>
>	Christian

Laura

[toc] | [prev] | [next] | [standalone]

#91042

On 22/05/2015 08:59, Cecil Westerhof wrote:
> I want to learn a lot of things. For example writing database and
> graphical applications. For database I decided on SQLAlchemy and GUI
> on Tkinter. In principal I want to write Python 3 applications.
>
> I came across Camelot. As I understand it, this is something to write
> graphical database applications fast. It works with Qt, but that
> should not be a big problem. It is just to get me started. But it
> seems only to work with 2.7 and not 3. Is this true?
>
> Would Camelot be a good tool to get me started, or can I better bite
> the bullet and just start with Tkinter and SQLAlchemy?
>

As others have already said plain SQL is perfectly adequate in many 
situations.  There are also other ORMs with peewee and ponyORM springing 
straight to my mind, although there's certainly a far longer list.  What 
it gets down to is "horses for courses" and you're the only person who 
(hopefully) knows the course you're running :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#91043

[Multipart message — attachments visible in raw view] — view raw

El 22/05/15 10:24, Mark Lawrence escribió:
> On 22/05/2015 08:59, Cecil Westerhof wrote:
>> I want to learn a lot of things. For example writing database and
>> graphical applications. For database I decided on SQLAlchemy and GUI
>> on Tkinter. In principal I want to write Python 3 applications.
>>
>> I came across Camelot. As I understand it, this is something to write
>> graphical database applications fast. It works with Qt, but that
>> should not be a big problem. It is just to get me started. But it
>> seems only to work with 2.7 and not 3. Is this true?
>>
>> Would Camelot be a good tool to get me started, or can I better bite
>> the bullet and just start with Tkinter and SQLAlchemy?
>>
>
> As others have already said plain SQL is perfectly adequate in many 
> situations.  There are also other ORMs with peewee and ponyORM 
> springing straight to my mind, although there's certainly a far longer 
> list.  What it gets down to is "horses for courses" and you're the 
> only person who (hopefully) knows the course you're running :)
>
I really enjoy Django ORM!

[toc] | [prev] | [next] | [standalone]

#91172

On 2015-05-22 15:03, Laura Creighton wrote:
> I don't know anything about Camelot.

Am I the only one who is disappointed that nobody has claimed
"Camelot...it's only a model"? :-)

-tkc

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web