>> However, I did notice that the regexp for pruning out comments is
>> a bit lax, as it misses the event where a comment-marker is in a
>> string:
>>
>> insert into app_tbl (column_name) values ('has--dashes');
>>
>> chokes. Granted, it's a tad pathological and fairly obvious to
>> catch that something has gone wonky, but it would be best to
>> avoid if possible.
>
> True.
>
> Patches not in Trac have very little chance of being remembered. :-)
Your wish is my command (okay, maybe not *any wish...but this
one...). Ticket #4680. There are some test cases described in
the case, but not coded. I found a small bug in my regexp when
one line had two comments in it (from one pathological case to
another), so it now uses the non-greedy version of the "*" in the
regexp. The current version passes all the tests I threw at it.
>> It also saves you from re-compiling the regexp for every file.
>> Not a huge savings, but just a general nicity. :)
>
> Well, your optimisation is actually a degradation of performance in the
> common case (the common case being no initial SQL files), since we're
> nitpicking. :-)
>
> Current code doesn't build the reg-exp unless it's needed. Of course,
> the difference is so small as to be essentially zero between the two
> cases.
Ah yes...those cases where O(n) beats O(1) :)
Perhaps I should change it to
comment_re = None
for sql_file in sql_files:
comment_re = comment_re or re.compile(...)
to only compile once, yet not compile at all if there are no
initial-sql files...in case those couple precious milliseconds
must be saved ;) j/k
Thanks for considering it,
-tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
