Disqus - Friends of jokull

Re: Major Speed Enhancements in SQLAlchemy 0.4

zzzeek — Wed, 15 Aug 2007 01:45:18 -0000

nah its more like the time has come to clean up a lot of old crap. the mass insert bench was a little bit of a wakeup call. your tests were helpful in identifying some newer code in 0.4 that needed to be simplified.

Re: Major Speed Enhancements in SQLAlchemy 0.4

zzzeek — Fri, 17 Aug 2007 23:38:48 -0000

Tenjin appears to be a native template language, seeing that its available for five different host languages. The catch is, native template languages don't integrate with the host language very well - the best you can do is a "namespace" passed from host environment to template, but any kind of programmatic integration is off the table. Trac switched from native ClearSilver templates to Genshi for the same reason.

Re: Revisiting Storm, SQLAlchemy, and Geniusql

zzzeek — Wed, 26 Dec 2007 17:18:48 -0000

thanks Robert !

Re: Revisiting Storm, SQLAlchemy, and Geniusql

zzzeek — Fri, 28 Dec 2007 00:57:01 -0000

Well, Robert has linked his post to this one pretty prominently and I've also observed that the programming community reads a lot and responds very quickly to new information; this post has had a lot of traffic so I'm pretty satisfied that SQLA's reputation hasn't been ruined or anything like that. Also our existing userbase didn't seem so concerned with the whole thing since the slowness Robert referred to was not something anyone had observed themselves. The various new competition and challenges in recent months have certainly been highly motivating and sqla just gets better and better. The changelog for the upcoming 0.4.2 has some pretty dramatic new feature adds.

Re: Hi, my name is Jesse and I abuse list comprehensions.

zzzeek — Fri, 28 Mar 2008 12:08:39 -0000

not to mention return ','.join(['{{whizbang|%s}}' % v for v in myDict[keyname].values()])

Re: zzzeek : Better Form Generation with Mako and Pylons

zzzeek — Tue, 01 Jul 2008 16:30:10 -0000

shannon -

easy enough to modify the tags to read defaults from a "default_dict" or somesuch attached to c.

you can also use this approach to make higher-level widgets, in the same manner as the low level widgets. that's the whole point !

Also this supports the formencode hierarchies using "." and "[]" syntaxes; that was already built in to the previous validate decorator (since we are still using `FormEncode` almost identically as before).

Re: zzzeek : Better Form Generation with Mako and Pylons

zzzeek — Tue, 01 Jul 2008 17:07:02 -0000

See, i dont want to make a "subclass" in order to create an HTML widget. Just like I dont want to build a picture-drawing robot just to draw a picture :). If I'm creating an HTML component, I want to use HTML; you know what I'm talking about since you used HTML::Mason at some point if I remember correctly.

Re: zzzeek : Better Form Generation with Mako and Pylons

zzzeek — Wed, 02 Jul 2008 17:46:22 -0000

try running the entire example, with Pylons 0.9.7, as is. There's configuration in the config/environment.py to get the custom tags.

Re: Django round 2

zzzeek — Sun, 07 Sep 2008 23:20:56 -0000

web designer doesn't need to learn Python just because there's some python in the template - this is a common overreaction to a problem that doesn't really exist. I wrote an old rant about this here: http://techspot.zzzeek.org/...

Re: zzzeek : Expression Transformations

zzzeek — Sat, 04 Oct 2008 19:33:33 -0000

Nick -

As to the "utility" of the features, the only example I can give is that of the SQLAlchemy ORM's usage of them - the ClauseAdapter feature is intrinsic to much of the ORM's capabilities, and the examples within the post should make that apparent.

As to creating a `cracker_posts` function, you say we "cannot be ignorant of the grandchildren alias". It's true, at some point we are aware of it, however your `cracker_posts` function is not - you've created an abstraction that allows a particular clause construct to be adapted against any compatible selectable. ClauseAdapter takes this a step further as a function that allows any clause construct to be adapted against any compatible selectable. Just as your application finds utility in abstracting one side of the equation, SQLA's ORM finds utility in abstracting the other side of it as well. The example including "aliased=True" illustrates this.

Now, you could say that the entire use case of saying query(Node).join('children', 'children', aliased=True).filter(Node.data=='crackers') is unnecessary, and that the join can be constructed manually. Our users do appreciate that they don't have to construct such a join manually (it was a widely requested feature). The utility of SQLA's clause generation generally becomes apparent the more that nestings and generations are applied to a query, and the alternative manual construction becomes more tedious and verbose.

Re: Sometimes I think validate + formencode is more hassle than it is worth

zzzeek — Tue, 28 Oct 2008 16:21:47 -0000

The "None" thing is one of maybe a few very glaring issues which should be changed. If you look at the source code, the Schema object totally bypasses the validator if the value is None. This is an inconsistency in how the data is handled and it would be nice if Schema/FancyValidator had one single datapath for all values.

Its also confusing to have to integrate composite form elements with variabledecode and it would be nicer for this to be more explicitly integrated.

Beyond that I think the docs just need more real world examples.

Re: Why use a VARCHAR when you can use TEXT?

zzzeek — Tue, 11 Nov 2008 07:09:00 -0000

I can't speak for MySQL and Postgres as authoritatively, but TEXT columns in Oracle and MSSQL have any number of these limitations:

1. can't compare them
2. can't use LIKE on them
3. can't fetch or insert large ones without using a separate cursor
4. can't ORDER BY them
5. client libraries often have limitations being able to stream them efficiently/easily

Even if MySQL/PG is in fact able to index them, you'll still get poorer performance by indexing a column with potentially huge strings in it versus one which is guaranteed to have strings no larger than a fixed size in them. It's also very reasonable to use size-constrained columns in any case for any type of data that is in fact meant to be a short string, like email addresses. Constraints are basically something you should be using as often as possible in SQL.

Re: corte.si - A Farewell to ORMs

zzzeek — Mon, 12 Oct 2009 11:10:52 -0000

nice post. One nit that I'm sure you can predict I'm going to say - SQLAlchemy ORM does not "define the schema" in any way, and is entirely compatible with table reflection. It's only 3rd party extensions like Elixir that have an opinion about schemas, and those can be customized too. In fact if you use the SQLSoup extension, its providing just the "table-oriented statement generation over reflected tables" approach you describe - except its built on top of the ORM.

OK one more nit. If you've upgraded to modern versions of SQLAlchemy, I'm sure you're aware that the Query() object can pretty much formulate any query that the expression language can, in just as an explicit way as the underlying expression language. So again I'm puzzled how it is you ended up fighting with the ORM when these days it is pretty competitive with straight SQL expressions, or why you don't think sessions are useful - I do have some batch scripts that use raw inserts and updates, but boy are they hard to write versus just using instrumented classes that track their own changes.

and of course the usual, if you show me what your performance problem was with the ORM, its likely that its already been solved, or I can show you how to solve it, or its some issue that I'd love to fix, or your app would just require a little expression language goodness to deal with a critical section...doesn't seem like a reason to ditch the whole thing.

and finally thanks for the plug ! :)

Re: corte.si - A Farewell to ORMs

zzzeek — Mon, 12 Oct 2009 12:20:18 -0000

summary: here's a story that has nothing to do with ORMs illustrating bad practices, then I used a crappy ORM some years ago that was awful, therefore ORMs suck. Same argument Neward writes.

Yet somehow people get tons of work done with ORMs every day.

Anyway that post is nearly a year old, so how did it go ?

Re: lxml vs. ElementTree

zzzeek — Thu, 15 Oct 2009 19:54:48 -0000

the big win of lxml is that you can actually get at the DOCTYPE node using the native API. cElementTree has no way of doing this (you have to write a custom subclass using ElementTree). looking at the source you can see it just throws DOCTYPE away. Why this node wouldn't be considered important is beyond me.

my general impression is that lxml is much more actively maintained.

Re: Supporting Python 3 is a Ghetto

zzzeek — Mon, 22 Feb 2010 13:59:42 -0000

a basic "preprocessor" monkeypatch for 2to3:

http://www.sqlalchemy.org/t...

Re: Sphinx + Mercurial = My favorite CMS

zzzeek — Mon, 22 Mar 2010 00:28:45 -0000

For a document-oriented CMS its a great approach. We rolled a similar idea out years ago at MLB - we threw out Teamsite and replaced it with a CVS repository (CVS was state of the art at this time, trust me), and gave the users WinCVS with some Python macros included - the macros, "promote to stage"/"promote to production" would just tag the files with "staging" or "production", and a listener on the server would hit rsync in response to promote the files to the site.

As a side note, that project was the reason I had to learn Python. It's been a long road since then !

Re: Blog II - The Sequel Blog - MyISAM, InnoDB, and PostgreSQL

zzzeek — Mon, 29 Mar 2010 20:32:07 -0000

add some joins and subqueries to your test. then watch Postgresql blow MySQL into dust.

Re: NoSQL panel — Reinout van Rees' website

zzzeek — Wed, 26 May 2010 11:46:38 -0000

Clarification on SQLA's position. The query side of a SQL ORM is not very portable to a NoSQL database (though one can be emulated). The persistence side of the ORM, i.e. unit of work + objects mapped to database structures, is relevant. SQLAlchemy's current plans in this area are at http://www.sqlalchemy.org/t... , the focus is to allow Mapper to be more friendly towards subclassing and therefore being able to provide alternative save/update/delete semantics.

Re: Why Extending Through Subclassing (a framework’s classes) is a Bad Idea

zzzeek — Tue, 19 Oct 2010 09:31:03 -0000

Subclassing is fine as long as you keep it to classes whose sole/primary purpose is to be subclassed, i.e. extension classes, like those of SQLAlchemy, Nose, and Sphinx, as well as "component" classes like Pygment's Lexer classes. But yeah, you don't subclass the object(s) which implement the central processing paradigm of the library - that part should be private since its essentially the "guts" of the tool.

Re: Quick Mako vs. Jinja Speed Test

zzzeek — Fri, 19 Nov 2010 20:48:09 -0000

Nah you win dude, I forgot to upgrade Jinja2 to 2.5.5 ! You're doing the same pessimistic assumption thing as me ;)

Re: Quick Mako vs. Jinja Speed Test

zzzeek — Sun, 21 Nov 2010 17:25:42 -0000

thanks for the compliments Seth !

Re: zzzeek

zzzeek — Mon, 06 Dec 2010 16:51:18 -0000

a Python-based comments engine that essentially clones Disqus would fit the bill - you then use it with whatever static blog thing you want. I think the Disqus "comments for anything" model is pretty awesome, after having written dozens of crappy comment systems of my own in the past.

Re: Python Float Quiz

zzzeek — Sun, 02 Jan 2011 16:15:49 -0000

You'd find the same behavior with SQL NULL, as well as Decimal, where NaN is part of the decimal specification. NaN values all represent "unknown" or "unrepresentable", such as the square root of a negative number, so cannot compare as True. Wikipedia has a good read on it: http://en.wikipedia.org/wik.... So this is nothing specific to Python !

Re: Scientists Aren’t Stupid: Software Is

zzzeek — Fri, 21 Jan 2011 18:46:55 -0000

Nice. Though the original dumdum in question made this blanket pronouncement, "Python is not portable", based on the fact that some libraries need to be installed. This isn't any kind of "I've tried so many times and it keeps breaking", this is, "I don't understand the difference between a language and installing libraries, let me not bother reading any documentation and instead post on a social network to see if someone can fix my problem". His or her experience with Perl, for some reason, was such that they never had to use CPAN, apparently. There's just an appalling lack of curiosity here on the part of someone who is decidedly not a lay-person.