Re: Deprecating logout via GET

[Tim Chase]

On 2020-03-02 18:35, Anna Sidwell wrote:
> Is there any particular reason why it shouldn't look like a button
> instead of a link?

The concern isn't how it looks (with CSS you can make a button look
like a link, or make a link look like a button).

An  does the logout action via a GET (and is the problem
at hand) while a / does the logout action via the
form method and can be either a GET (which would still a problem) or a
POST (the goal).

-tkc





-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200302143452.2e889388%40bigbox.attlocal.net.

Re: Are there use cases for storing null bytes in CharField/TextField?

[Tim Chase]

On 2017-05-15 08:54, Tim Graham wrote:
> Does anyone know of a use case for using null bytes in
> CharField/TextField?

Is this not what BinaryField is for?  It would seem to me that
attempting to store binary NULL bytes in a CharField/TextField should
result in an error condition.

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20170515123050.363a2859%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: add new template tag "age"

[Tim Chase]

On 2015-11-11 14:44, Collin Anderson wrote:
> Also, doing this from the backend seems like sub-par way to do it.
> I would recommend implementing this in javascript, so it can
> auto-update over time if you leave the window open.

It shouldn't be limited to one or the other:  doing it on the
back-end will allow it to correctly reflect the age as of the time
the request was made (and thus be available where JS is
unavailable/disabled).  That field can then be updated client-side
with JS if it's available.

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2015165936.12d82152%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Tim Chase]

On 2015-09-22 07:49, Aymeric Augustin wrote:
> > And for your concern, there will be a MaxLengthValidator added to
> > the validators to validate the users input does not exceed the
> > database backends maximum length just like when you set
> > max_length explicitly.
> 
> This isn’t possible in a project that uses multiple databases, say
> PostgreSQL and Oracle. The form layer cannot say which length is
> correct because it has doesn’t know in what database the data will
> be saved.

Could this be resolved with allowing max_length=None (or some other
atom such as just object() that would have a unique id() that could
be tested with "is") to specify that the back-end uses the max-allowed
value? For Postgres, this would then use VARCHAR() with no limit,
while on MySQL, that could be 255 or whatever.

One could then include a helper function that would use the current
settings to check a string (such as from a form) to ensure that it
doesn't exceed the field's database-specific max-length (or whatever
the specified max-length value is).

-tim




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150922065843.37699cb6%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: A general way to batch SQL queries in Django

[Tim Chase]

On 2015-02-27 06:12, Josh Smeaton wrote:
> The concept of batched SELECT statements doesn't really exist in
> SQL, unless the relations you're selecting have identical column
> types. Example:
> 
> SELECT name, age_in_years FROM person
> UNION ALL
> SELECT item_name, quantity FROM item;
> 
> The UNION here means combine the results of each query into the one
> result set. A query like this probably isn't useful though, because
> you have no way of knowing which row belongs to which relation (or
> model)

For the record, I've done this with

  SELECT 'Person' AS description, name, age_in_years FROM person
  UNION ALL
  SELECT 'Item', item_name, quantity FROM item;

which allows me to distinguish them while gaining everything in one
query/result-set.

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150227112523.487da135%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[Tim Chase]

[slightly reordered]
On 2015-02-04 18:25, Collin Anderson wrote:
> Also, did we decide if the Model-field-layer or Form-field-layer
> would be better?

I think the Form-field layer is definitely the place for it.  If I do

  my_model.my_text_field = " leading and trailing "

I expect that value to make it in there, spaces and all.  But if it
comes from a form, the form-field should default to assuming that
leading/trailing whitespace is an accident.  There have been plenty
of times that I've copied/pasted data and missed that
leading/trailing whitespace was included.  E.g.: copying from Excel
is notoriously bad at including trailing newlines.

> I can't think of many cases where trailing whitespace has been an
> issue for TextFields. Has this been an issue for people? I could
> imagine some people would want a trailing newline on TextFields.

My password-generator/manager can include spaces in passwords which
occasionally come up at the beginning/end of the resulting password.
Since it auto-types the value for me, I don't usually give it a
thought. But it has stung me once or twice when a site has a password
field that eats the whitespace.  Thus stung, I tend to no longer
include spaces in my generated passwords these days.  But again, at
the form-level, a TextInput could strip while a PasswordInput could
retain, and the underlying models.CharField would preserve whatever
the form hands to it.

My $0.01 on the matter,

-tkc


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150204215544.25d97f11%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Tim Chase]

On 2015-02-03 10:31, Aymeric Augustin wrote:
> Your request boils down to "make Django's CSRF protection of HTTPS
> pages vulnerable to MITM attacks" which isn't acceptable.

If you've got a MITM that can intercept HTTPS, is there any reason to
assume they aren't in a position to spoof DNS as well, rendering the
REFERER information immaterial?

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150203061042.35a7ab68%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Status of #15619: logout via POST, but not GET

[Tim Chase]

I've had a couple cases where browser link pre-fetching triggered
an unintended logout from my Django app (I haven't fully tracked down
the exact combination of triggering conditions, but I suspect they
similar to Israel Brewster's CherryPy issue mentioned on
comp.lang.python [1]) and was surprised that Django suffered the same
issue.

Researching, I found https://code.djangoproject.com/ticket/15619
but see that it was last modified ~10mo ago, having been opened ~4yrs
ago.  The current (development HEAD from git) versions of

  django/contrib/auth/views.py:logout()
  django/contrib/auth/__init__.py:logout()

still don't seem to contain any checks to ensure logouts can only
happen via POST rather than GET requests.

Is there any movement forward on resolving this so my browser
doesn't inconveniently boot me from the app when I don't intend to
log out?

-tkc

[1]
https://mail.python.org/pipermail/python-list/2014-December/682106.html






.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20141203160459.1ee6d9f8%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: What are the best reasons for when and why people should use Django?

[Tim Chase]

On 2014-08-10 01:06, Josh Johnson wrote:
> Django documentation is phenomenal,

I second Josh's comment.  I'd naively assumed that all "big Python
web-framework" documentation was as good as Django's.  However, when I
had to do some work on a contract involving CherryPy and
SQLObject...marcy was it a painful wake-up.  Bottle's documentation
was better than CP/SQLObject, but still not up to the high bar set by
Django's.

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20140810150538.7097b91b%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

[Tim Chase]

n 2014-01-20 20:22, Aymeric Augustin wrote:
> The alternative is to modify INSTALLED_APPS to support passing
> arguments to the AppConfig class. But I find it rather ugly.

[I've only been lurking in this thread, so take with a grain of salt;
just throwing it out there to see what sticks]

Would it be possible to do something like

 VALIDATION_APPS = SomeComplexValidatorWithMetadata(
   app1=...,
   app2=...,
   )

 INSTALLED_APPS = VALIDATION_APPS.get_installed_apps()

which would allow a more complex descriptor for validation purposes,
but then also keep things fairly DRY so you don't have apps
duplicated between the two settings and the INSTALLED_APPS remains
backwards compat.

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20140120142752.32aea639%40bigbox.christie.dr.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Tim Chase]

On 2013-10-16 11:10, Javier Guerra Giraldez wrote:
> On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger 
> wrote:
> > However, it does so by blurring the distinction between GET and
> > POST parameters, which like other people here, I find
> > disturbing.
> 
> care to elaborate about that distinction?  both are user-provided
> parameters included in the request.  the only difference i see is
> about encoding.

Because they're sent different ways.  POST variables in the request
body, and GET parameters are in the URL.  But it's possible that a
parameter is provided via *both*, and (as Alex notes) the first
question in such a case is "where does it look first?"

I'm +1 on the eventual removal, possibly with a footnoted function
that lets you request the fallback easily if needed.  It's a
one-liner as Marc details:

  request.GET.get(key, request.POST.get(key))

or

  request.POST.get(key, request.GET.get(key))

depending on the priority you want.

-tkc





-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20131016112949.68b9d342%40bigbox.christie.dr.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Allowing custom attributes in Meta classes

[Tim Chase]

On 2013-09-10 21:05, Russell Keith-Magee wrote:
> So - I think custom Meta options are something that should be
> *possible*. I don't have any particular ideas for how it should be
> implemented, though.

One of the areas I've considered trying this is annotating "private"
information about models.  The models' Manager class(es) could then
grow methods taking context (such as user information, remote IP,
HTTPS status, etc) and return models that have been sanitized based on
what that context permits ("Joe is a manager on-site, so can see the
full credit-card number and social security number", "Pat is a
non-manager employee visiting from on-site, so can only see the last
4 digits of the credit card number & social", "Ellen is an off-site
user and can only see the last 4 digits of her own credit-card &
social but nobody else's").

For implementation, I'd expect to namespace based on the name of the
app implementing the functionality, so you'd have something like

class MyModel(Model):
  class Meta:
...
class MyApp:
  secure_fields = ["cc_num", "ssn"]

The indentation might get just a little unwieldy, but namespacing
helps prevent clashes and sensibly be accessible just by chaining
properties:

  secure_fields = existing_meta.MyApp.secure_fields

My $0.02

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Tim Chase]

On 2013-08-08 09:59, Collin Anderson wrote:
>> I am doing something a little different with my CSRF tokens, and
>> I believe it guards against BREACH.
> 
> Instead of sending the token in the HTTP response, I am using
> javascript to read (and generate if needed) the CSRF token cookie.
> The javascript reads the token from the cookie and adds it as a
> hidden field to any forms that need it on the page.
> 
> This also has two bonus benefits:

but also has the downside that it doesn't work if JS is disabled.
You may or may not care, but it's at least something to consider
(JS-free interactions may come from older devices, or from testing
tools, etc; so I've found enough benefit to code for JS-free and then
add in additional functionality).

-tkc


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Tim Chase]

On 2013-08-06 12:53, Donald Stufft wrote:
> On Aug 6, 2013, at 12:16 PM, Tom Scrace  wrote:
>> On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss
>> wrote:
>> 
>> We plan to take steps to address BREACH in Django itself, but in
>> the meantime we recommend that all users of Django understand
>> this vulnerability and take action if appropriate.
>> 
>> Would randomizing the CSRF token on each request be the correct
>> way to fix this in Django?
> 
> This incurs the cost that every request to Django invalidates all
> existing CSRF tokens (meaning if you start filling out a form, and
> then open another form in a different tab the first form will send
> an error) OR requires you to store a separate CSRF token for each
> request and look up the submitted CSRF token in that set of stored
> tokens.
> 
> There are a few possible solutions each with their own drawbacks.
> Such as secret hiding or disabling compression only for pages that
> have CSRF (or other secret output).

After through the PDF, my understanding that it requires the token
to be constant across all requests.  One might be able to mitigate it
a bit by randomly inserting values into the CSRF token that then get
stripped back out before being checked.  So the actual transmitted
value changes every time (per 3.4 in the PDF), but the server knows
how to strip the random junk back out.  Something like

  # a set of characters known not to be in tokens created
  # by the existing method
  JUNK_TO_STRIP = ' \t'
  JUNK_SET = frozenset(JUNK_TO_STRIP)
  MAX_JUNK_PER_CHAR = 5

  def random_junkify(c, junk=JUNK_TO_STRIP, count=MAX_JUNK_PER_CHAR):
return ''.join(
random.choice(junk)
for _ in range(count)
) + c

  def generate_token():
token = existing_token_generation()
return ''.join(
  random_junkify(c)
  for c in token
  )

  def new_check_token(token):
token = ''.join(c for c in token if c not in JUNK_SET)
return existing_token_check(token)

I'd be interested in others' thoughts on whether this might suffice
to stymie this attack.

-tkc









signature.asc
Description: PGP signature

Re: reconsider re-opening ticket 901

[Tim Chase]

On 2013-05-14 10:43, Alex Ogier wrote:
> What happens in the following case?
> 
> a = A(dict_field={"hello": "world"})
> d = a.dict_field
> a.save()
> a.refresh()
> d["hello"] = "planet"# does this mutate a.dict_field? does the
> answer change if somebody changed the database in between saving
> and refreshing?

I'd expect the same as the stdlib's pickle module:  when you load an
object from a pickled stream (what I'd consider analogous to
the .refresh() topic at hand), you create a new object.  So "d" would
still reference the original dict_field, while the a.dict_field would
contain a new dict object that doesn't contain "hello" as a key.

It is easy to explain, consistent with the stdlib, and unlikely to
harbor strange edge conditions once you understand what it's doing.
It also allows for doing things like

  d = a.dict_field
  a.save()
  # semi-lengthy-process
  a.refresh()
  if a.dict_field != d:
somebody_changed_something_while_we_were_occupied("!!!")

Prudent? Maybe, maybe not.  Believable? sure.  But if "d"
auto-updates upon refresh, there's no easy way to make this test
(short of doing a deep-copy of "d" to preserve it).

I think DB-trumps-local is pretty sensible in both cases you describe
(above, and the OneToOne), that if you reload, you get what the DB
tells you and you're responsible for refreshing any internal
references you have reaching into the object.  As our preschooler has
learned, "you get what you get, and you don't throw a fit." :-)

-tkc




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Tim Chase]

On 2013-05-11 18:36, Anssi Kääriäinen wrote:
> On 12 touko, 02:55, Russell Keith-Magee 
> > What is on the table is essentially adding a refresh() call on an
> > object instance that is an API analog of
> > ".get(id=self.id)"

I guess my minor quibble is about the name itself and possible
clashes with existing fields/methods:

  class MyModelA(Model):
# ...
refresh = BooleanField(...)
# ...
  class MyModelB(Model):
# ...
def refresh(...): do_something_refreshing()
# ...

  a = MyModelA.objects.get(pk=some_id)
  b = MyModelB.objects.get(pk=other_id)
  # ...
  if a.refresh: # legacy code expects a BooleanField
# whoops, what happens here under this proposal?
  if b.refresh(): # legacy code expects local logic, not Django logic
# or what gets called here?

I wouldn't want to see any breakage when upgrading between versions.
I don't have a good proposal, other than perhaps _refresh() or
__refresh__(), or cramming it into Meta (I don't know if that would
even work).

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Tim Chase]

On 2013-03-26 15:54, Michael Manfre wrote:
> On Tue, Mar 26, 2013 at 12:40 PM, Anssi Kääriäinen
> deal with limit/offset. A generic approach would be nice to have,
> but I can't imagine a generic way that would let me generate the
> "SELECT ... FROM (SELECT ROW_NUMBER() OVER (...)) WHERE ..."
> monstrosity with lots of column aliasing that I currently
> construct.

The closest I've come is an ugly nested query using TOP (the TSQL
analog to LIMIT, but as mentioned earlier, there's no OFFSET
counterpart), and inverting the sort conditions:

  -- want sorted by "a asc, b desc, c asc"
  -- assuming LIMIT=10, OFFSET=20
  select *
  from (
   select top 10 -- LIMIT
   *
   from (
select top 30 -- LIMIT+OFFSET=10+20 
*
from tbl
order by a asc, b desc, c asc
) top_half
   order by a desc, b asc, c desc -- note inversion
   ) reversed_top_half
  order by a asc, b desc, c asc

It's been a while since I've done it, so it Works™, but (1) there's
the inevitable fence-posting error I'd have to verify, (2) it involves
sorting, reverse-sorting, then re-sorting (not exactly the speediest
operation), and (3) it's hideous.  It doesn't seem to require the
column-aliasing you mention, and it is a fairly generic approach, but
I can't say I recommend it :-)

-tkc






-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Tim Chase]

On 2013-03-25 22:16, Michael Manfre wrote:
> On Monday, March 25, 2013 6:58:12 AM UTC-4, Tim Chase wrote:
> > I can only speak for testing IN-vs-EXISTS speed on MSSQLServer at 
> > $OLD_JOB, but there it's usually about the same, occasionally
> > with IN winning out. 
> 
> In SQL 2008r2, the optimizer is usually smart enough to end up with
> the same execution plan for IN and EXISTS queries. Historically,
> EXISTS was usually the faster operation for SQL Server and if
> memory serves it had to deal with its ability to bail out of the
> EXISTS query sooner compared to the IN query.

I'd have to go back and re-test 2008r2, as my testing was on 2005
(and earlier). But my testing directly contradicts your
"Historically..." bit, as I DISTINCTly (bad SQL pun intended) remember
being surprised precisely because of what you say: EXISTS should be
able to optimize and bail early.  EXISTS also has some nice features
like the ability to do testing against multiple columns, i.e., you
can't do something like

  select *
  from tbl1
  where (col1, col2) in (
   select a, b
   from tbl2
   )

but that's a simple EXISTS query.

> > MSSQL is a 2nd-class citizen in the Django world, so I'm +1 
> 
> Reasoning like that helps to keep it in its place.

MSSQL's lack of certain core features is what does that.
OFFSET/LIMIT provided by pretty much every other DB vendor?  Use
baroque hacks to get the same functionality.  I seem to recall other
issues, though v2008 seems to have addressed many of them (min date =
1900-01-01 which was an issue when dealing with
historical/genealogical data; seems to be better in 2008)

Either way, if EXISTS in MSSQL is now faster than IN, it just is one
more tally in the "plus" column for why this might be a good idea
(modulo implementation complexities).

-tkc






-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Tim Chase]

On 2013-03-25 03:40, Anssi Kääriäinen wrote:
> I am very likely going to change the ORM to use EXISTS subqueries
> instead of IN subqueries. I know this is a good idea on PostgreSQL
> but I don't have enough experience of other databases to know if
> this is a good idea or not.

I can only speak for testing IN-vs-EXISTS speed on MSSQLServer at
$OLD_JOB, but there it's usually about the same, occasionally with IN
winning out. However, the wins were marginal, and MSSQL is a 2nd-class
citizen in the Django world, so I'm +1 on using EXISTS instead of IN,
if the results are assured to be the same.

However, the query constuction to move the condition into the EXISTS
subclause might be a bit more complex.

-tkc


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Note of thanks to the release-managers

[Tim Chase]

I just read through the novel that is
docs/internals/howto-release-django.txt and I have a new level of
respect for just what happens when a release is made.  That's a LOT
of work.

So thanks to those that wade through the whole process!

-tkc


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

[Tim Chase]

On 08/26/10 13:25, Jeff Balogh wrote:

In our case the pref was accidentally disabled when testing add-ons,
but people do intentionally turn off Referer for privacy reasons.  I
don't know if requiring Referer under https is a good idea.


RFC-2616 makes it pretty clear that one should never require the 
Referer[sic] header as it's optional[1] for the user-agent to 
transmit it and perfectly reasonable for the user to disable it 
regardless of HTTP vs. HTTPS.


-tkc

[1]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.2
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3



--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Invalid SQL generated by objects.all()[:1]?

[Tim Chase]

On 07/15/2010 01:28 PM, Mark Bucciarelli wrote:

not sure why a subselect would ever need an order by anyway.
i'll have to figure out exactly what django operation
generated that sql.


The only time I've needed an ORDER BY in a subselect involved a 
LIMIT/TOP in the subselect


  SELECT ...
  FROM tblFoo
  WHERE StatementID IN (
SELECT
 -- TOP 5 -- SQL Server
 id
FROM tblStatements
ORDER BY StatementDate Desc
LIMIT 5 -- just about everybody else uses LIMIT
)

which has

-tkc

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[Tim Chase]

Your proposal really needs to cater to two different audiences:

1. People who will use the new {% form myform %} where they just want
all the fields rendered without any fuss, much like {{ form }} now.
2. The tweakers that need to control every aspect of the each field
being rendered.


I'd say there's a 3rd subset of folks (Gabriel Hurley and myself 
have voiced advocacy for this camp) who would be interested in a 
middle-road "mostly the default form, only override the behavior 
for fields X & Y".  Andre's proposed {% form myform %}...{% 
endform %} syntax does this nicely, making it cleaner by removing 
the redundancy of referencing the form in each field-modifier and 
without the need to manually render each field.


-tkc



--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[Tim Chase]

On 07/12/2010 07:03 AM, Russell Keith-Magee wrote:

On Mon, Jul 12, 2010 at 5:43 AM, Tim Chase
<django.us...@tim.thechases.com>  wrote:

[please excuse the slight chop-up-and-reordering of your
original into my quoting]


Only if you grant me the same liberty :-)


Fair's only fair :)


and REALLY -1.0e1 on this syntax-soup.  Does this result in
something that looks like the following monstrosity?

  {% form myform field name using autocomplete:"name_autocomplete" field
birthdate using calendar field other_field using
some_other_chrome_or_widget%}


I think some wires have gotten crossed here - this example wouldn't be
legal syntax under what I'm proposing.

Under the scheme I'm proposing:
  * {% form myform %} would render an entire form, and
  * {% form myform field name ... %} would render a *single* field
using the strategy described by the form.


Ah, that does clarify (and minimize my strenuous -1.0 objections 
back to just a -0 "meh")



  {{ myform|as_ul }}


If you dig into the archives, this was proposed (I'm fairly certain
*I* suggested it or supported it at one point); I can't say I can give
a concrete answer as to why the suggestion wasn't adopted. However, in
the context of this proposal, I can give some counterreasons -- more
in a bit.


Okay -- A little improvement on my previously-decaffeinated 
google-fu turned up at least one thread[1]...though as you say, 
your participation in the thread was "Put me down as a +1" 
advocating filters ;-)



  {{ myform|as_ul }}
  {{ myform|use_widget:"birthdate=calendar"|as_ul }}


I think this last example should probably be:

{{ myform.birthdate|chrome:"calendar"|as_ul }}

or even:

{{ myform.birthdate|calendar_chrome|as_ul }}

since this enables you to define chrome as a filter. This bit appeals to me.


But I want a BLUE bikeshed ;-)  Yeah, I'll give you the point 
that your solution looks more elegant for individual field 
rendering, while one of my envisioned use cases was "I want this 
form exactly as it would normally render, only I want to override 
the widget-choice for a particular field".  It's the difference 
between something like


 {{ myform|use_widget:"birthdate=calendar"|as_ul }}

and

 {{ myform.name }}
 {{ myform.favorite_cheese }}
 {{ myform...8 more fields here }}
 {{ myform.birthdate|calendar_chrome }}
 {{ myform...7 more fields here }}

or perhaps a (forgive the pseudo-code template) slightly less 
verbose version:


 {% for field in form.fields %}
  
   {% if field.name == "birthdate" %}
{{ field|calendar_chrome }}
   {% else %}
{{ field }}
   {% endif %}
  
 {% endfor %}


  * The first is stylistic. {{ myform|as_ul }} is certainly elegant;
however, I don't see that {{ myform.birthdate|calendar_chrome|as_ul }}
is equally elegant. Filter syntax requires that you take out all your
whitespace, which just seems messy to me. In a template tag, arguments
are all distinct, ordering is obvious, and when it isn't, you can
introduce syntactic sugar (like "using") to clarify.


The whitespace issue is a grumble for another day (I can't count 
the number of times I've reached to use whitespace for improved 
readability in a filter-chain or template, only to be burned by 
exploding template shrapnel).


However since you're only dealing with one field and controlling 
the rendering yourself (wrapping in  tags), it would be 
reduced to


  {{ myform.birthdate|calendar_chrome }}
  {{ myform.name|auto_suggest:"some_view_name" }}

which isn't quite so bad, IMHO.  Unless the volume of parameters 
to the filter balloons, in which case I can cede you the point. 
For most of what I do, the 0-or-1 parameter case is by far the 
most prevalent.  Individual tweaks such as CSS styles can be done 
by identifying a containing tag:


  
  li#fabulous tr td { background-color: #f0f; }
  
  ...
  {{ myform.birthdate|calendar_chrome }}


so I've not really found myself reaching for attribute tweaks 
inside rendered controls.



  * Secondly, while I can certainly explain from a programmers
perspective as_ul formatting and calendar_chrome are applied as
filters in the order that they are being applied, I can't think of a
good conceptual explanation, suitable for non-programmers, for why
form rendering is a 'filtering' activity.


Filters apply transformations of input to output -- the "lower" 
filter takes the input (as text) and makes it lower-case; the 
$FILTER takes the input and makes it ${FILTER}ed.  The "as_ul" 
filter takes the input form and makes it ified; the 
calendar_chrome filter takes the input field and makes it 
calendar'ified.  I don't see this as a particularly big 
conceptual jump for non-programmers.



  * Lastly, a template tag gives you access to the context, which means
tricks like collating javascript triggers becomes possible. For me,
this is one of the major goals of this refactoring, and it's someth

Re: Proposal: Revised form rendering

[Tim Chase]

On 07/12/2010 08:12 AM, Russell Keith-Magee wrote:

On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson  wrote:

Good proposal overall. One thought I have in order to try and combat
the massive parameter list of {% form %} is to optionally add an
ending tag, as well as sub-tags:

{% form myform %}
{% using birthday=calendar %}
{% renderer "as_ul" %}
{% autocomplete "name_autocomplete" %}
{% doctype xhtml1 %}
{% endform %}


As I commented to Tim; the {% form X field ... %} tag isn't trying to
render the entire form -- it's just rendering a single field


Looking back over the thread, I'm the only Tim, but I don't seem 
to see your response (neither in my email nor via gmane).  If you 
could disinter it from your sent-mail folder and resend, I'd 
appreciate reading your thoughts in reply.


-tkc





--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[Tim Chase]

[please excuse the slight chop-up-and-reordering of your
original into my quoting]

On 07/11/2010 10:36 AM, Russell Keith-Magee wrote:

{% form myform %}


For what my vote may be worth, I'm -0 on this...


{% form myform field birthdate using calendar %}


and -1 on this


{% form myform field birthdate using calendar important %}
{% form myform field name using autocomplete:"name_autocomplete" %}


and REALLY -1.0e1 on this syntax-soup.  Does this result in
something that looks like the following monstrosity?

  {% form myform field name using 
autocomplete:"name_autocomplete" field birthdate using calendar 
field other_field using some_other_chrome_or_widget%}



Putting in a subtle plug for one of my wish-list items, I've
always been curious why form-rendering wasn't implemented as
a filter:

  {{ myform|as_ul }}


These layout schemes can be overridden and customized if you
know what you're doing, but it's not easy to do so.


I've occasionally wished for an as_dl (which would render
labels as  and controls as  elements), and having a
base/ancestor as_* filter object to base it off of would
make this a lot easier.  This would take care of your
issue#1 (more easily extensible renderings).

Under such a scheme, I'd imagine your above examples might
look something like

  {{ myform|as_ul }}
  {{ myform|use_widget:"birthdate=calendar"|as_ul }}

where the use_widget (deep?)copies the input form object,
adjusting its field-widgets per the requested use_widget
modifiers.  It could even be neatly stacked something like
(line-broken for clarity)

  {{ myform
  |use_widget:"birthdate=calendar"
  |use_widget:"name=name_autocomplete"
  |use_widget:"other_field=some_other_chrome_or_widget"
  |as_ul
  }}

For backwards compatibility, the implementations of
Form.as_*() should be able to just look something like

  def as_table(self, ...):
return filters.as_table(self, ...)

I'd suspect this could take care of your issue#2.

However that leaves me with no good answer to

1) your "parameters to chrome" wish (though that might be
possibly incorporated in the use_widget parameters).  I'm
not entirely clear on your chrome ideas, but I like some of
what I read in your novella. :)

2) your "put all JS at the bottom of the page" wish

3) your issue#3 about DOCTYPES, but unless filters were given
access to a rendering context in which some global
DOCTYPE-preference was specified, I haven't liked any of
the solutions I've seen bandied about on this matter
(including a settings.py directive, since I can easily
imagine a single site producing a mix of html4, xhtml
and/or html5).

However I think all 3 of my outliers are somewhat
orthogonal to the rejiggering of form rendering.



- Propagating the 'doctype' kwarg through the existing
form/field/widget infrastructure


I'm +1 on this (or something like it such as request-context
or some other bag-of-attributes that could be useful in
rendering a widget) so that widgets can tweak their
display behavior.

Just my late-afternoon rambling thoughts...

-tkc




--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: a default max_length

[Tim Chase]

> How do you feel about having a default max_length value for a
> models.CharField, so we can use it like:
> class MyModel(models.Model):
> example = models.CharField()
> 
> What are the pros and cons?

I'm pretty -1 against it.

Pros:

+  you get to be lazy in one particular use-case, for whatever 
default is chosen

Cons:

-  that default has to be chosen -- who is to say it should be? 
2?  5?  10?  20?  42?  50?  100?  Every case requires its own 
consideration, and thus it should be specified as a parameter

- it's fairly easy to create your own CharField subclass that 
defaults to whatever you want.  Untested, it would be something like

   MY_ARBITRARY_DEFAULT_LENGTH = 42
   class MyCharField(CharField):
 def __init__(self, *args, **kwargs):
   if 'max_length' not in kwargs:
 kwargs['max_length'] = MY_ARBITRARY_DEFAULT_LENGTH
   super(MyCharField, self).__init__(self, *args, **kwargs)


Since everybody's bikeshed tends to be a slightly different color 
of 42, and it only takes about 6 lines of code to make your own 
shed and paint it, the savings isn't that great to be worth 
putting it in Django core, IMHO.

-tkc



--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Doc building piece missing?

[Tim Chase]

Just noticed this in [1]

--
csrf_tokenś

New in Django 1.1.2:

System Message: WARNING/2 
(/home/djangodocs/en/dev/ref/templates/builtins.txt)

undefined label: releases-1.1.2
--


Looks like some tag/label needs to be created for the doc build 
process to find it.  If this needs a bug report to be filed, I 
can do that too, but it may just be a fast "whoops" fix.  I'm 
guessing it's not the only instance in the docs, but I'd also 
guess that the same fix should solve all of them.

[1]
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#csrf-token

-tim


--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=.

Re: ORM roadmap

[Tim Chase]

> I find an orm usefull for 3 scenarios:
> 1. - simple object retrieval posts.objects.all()
> 2. - performance optimized object retrieval, your raw approach would
> suffice here
> 3. - generating complex queries, and reusing sql components
> When you get to complex data models, Django currently fails on 2 and
> 3.


I'd agree and elaborate on #1, that ORMs are good for simple 
object retrieval, and also for eliminating some of the most 
grievous cross-platform issues.

However, I must disagree on #2 and #3:  I'd never consider the 
*addition* of a generalization-layer (an ORM in this case, but 
the idea is far more broadly applicable) a step towards 
optimization.  Likewise, for my more complex queries, there's no 
good way to  express them efficiently in *any* ORM I've used -- 
many end up either inexpressible, or they involve bringing back 
gobs of data client-side and post-processing it there instead of 
at the server.

I use an ORM for the same reason I use Python:  they make common 
tasks easy.  Using Python/ORM, I can bang out most of what I 
need.  But when I hit a wall (performance or complexity), both 
need to allow be to go *down* a layer (to C or SQL).

So I'd say Django has done a fine job of making the ORM what it 
should be -- an approachable, cross-platform, cross-database 
data-access layer that covers most use-cases and gets out of your 
way when you need it to.

-tkc




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal for 1.2: Dumber email validation

[Tim Chase]

> 1) If we encourage people to write their own regex if they want
> tighter email validation, we run the risk that users will
> inadvertently introduce the same bug that we have just fixed. 

Russell raises my biggest concern with this proposal.  There are 
a lot of smart folks in the Django-Developers end of things that 
can cobble together a pretty legit regexp that covers the 
majority of cases with no horrific DOS cases (e.g. last security 
issue).

I've seen the regexps created by people who don't comprehend them 
and it's UGLY.  This proposal basically throws those people to 
the wolves.

I'd much rather Django provided an email field that got most of 
the way and let regexp-understanding users tweak if needed.  But 
I'd hate to see somebody opening themselves to email addresses like

   bad_stuff()@wherever.space space.&

or

   f...@domain.tld\x0a\0x0dfrom: s...@spammer.spam\x0a\0x0dto: 
s...@spimmer.spim\x0a\x0d\x0a\x0dspam, spam, spam!

which can (without added caution) inject headers into sent-mail.

My initial candidate is ticket #12005, though it merely 
re.VERBOSE's the original and tweaks the domain portion to meet 
an internal need.  Some changes on the stuff before the "@" might 
make it more "relaxed" (if not RFC-compliant-ish) while keeping 
out some of the badness.

-tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Check Constraints for databases that support them

[Tim Chase]

> Is there anyone else interested in this?

yes, I'd be interested in seeing some sort of database-level 
CHECK constraint as part of Django.  I had been sitting on my 
thoughts until I see the GSoC work done on model-validation wend 
its way towards trunk.  My hope had been to see model validation 
incorporate some DB-level CHECK constraints where feasible.

One of the other difficulties involves database expression 
differences.  For the simple cases such as you suggest, it's not 
as bad as they're fairly standard.  However, when functions are 
involved, each DB seems to have its own family of functions. 
E.g. if you want to assert the length of a string is 10 
characters ("len" vs. "strlen"?) or the time is during business 
hours ("hour(fieldname) between 8 and 17"...extracting 
time-portions varies across DB engines).

I currently just add the CHECK constraints manually (well, in 
post-syncdb code).  Having them in a declarative fashion would 
help keep them in the right place.

-tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: USStateField (again)

[Tim Chase]

James Bennett wrote:
> The current proposal is for a "USPostalCodeField" which 
> corresponds to the US Postal Service's list of postal codes:
> 
> http://www.usps.com/ncsc/lookups/abbr_state.txt
> 
> [snip] Based on the various arguments up to this point, it
> seems like no single field is going to make everybody happy,

Internally, I've solved a similar "can't make everybody happy" 
problem with a class factory function that takes the desired set 
of defined data, depending on the project:

   LOWER_48 = [ ... ]
   US_STATES = sorted(# in shuffle AK/HI alphabetically
 LOWER_48 + [
 ('AK', 'Alaska'),
 ('HI', 'Hawaii')
 ],
 key=lambda s: s[1]
 )
   PROTECTORATES = [ ... ]
   MILITARY_DROPS = [ ... ]
   USPS_SERVICE = US_STATES + PROTECTORATES + MILITARY_DROPS

   class BaseStateField(Field):
 allowed_states = US_STATES
 # common logic/code here

   def make_state_field(desired_states=US_STATES):
 class MyStateField(BaseStateField):
   allowed_states = desired_states
 return MyStateField

which can then be used something like

   class MyModel(Model):
 just_48 = make_state_field()(help="Pick a lower48 state")
 all_us = make_state_field(US_STATES)(help="All the US")
 my_random_whims = make_state_field(
   US_STATES + PROTECTORATES)(help="Just what I wanted")

> First, deprecate USStateField immediately. It's not and never has been
> just a list of states, and the implication that the things it lists
> *are* US states seems to offend some people. So kill it, already.

With the above factory solution, one could just define it as

   USStateField = make_state_field(US_STATES + WHATEVER)

to prevent breaking existing code (though I agree the name is a 
bit misleading).  It also allows people to easily make a custom 
state-field with just the states they want:

   OUR_SALES_MARKET = [ ...subset of states here... ]
   SalesStates = make_state_field(OUR_SALES_MARKET)
   class MyModel(Model):
 sale_state = SalesStates(help="I sell stuff here...")

Just a possibility from the trenches here.

-tkc






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: #10355 Add support for email backends

[Tim Chase]

> In terms of the SMTP-specific settings (host, port, username, password  
> and use_tls), I personally feel that those parameters should be in the  
> settings module and not in the code. Although at the moment,  
> django.core.mail will use certain settings if said parameters are left  
> out.

Having email settings defined globally precludes the ability to 
do things like create a web email application for which each user 
has their own email (usually SMTP/IMAP/POP) settings.  While yes, 
I could see having some defaults at the settings.py level, it 
should be possible to override those at the call level.

-tim





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: [GSoC] model validation - update

[Tim Chase]

Honza,

Thanks for all your work on this -- model-validation is something 
I missed when it was removed (well, moved to forms), so you have 
one of my favorite GSoC projects.

> Questions for the community:
> -
> I have been toying with the idea of abstract validating object that
> both Forms and Models would extend. The reason for that is that some
> of the code is shared and could probably be abstracted into a set of
> methods. These abstract objects could later be used for example by
> REST resources or some othe arbitrary code. I will not post my ideas
> on the API since they don't make any sense yet (if they ever will),
> just interested in people's opinions.

I like this idea at some level -- it also opens the door to model 
validators that can implement SQL constraints when creating the 
backend models and perhaps JavaScript constraints on forms.

E.g. it would be nice to have a single PositiveInteger validator 
that you associate once with a model-field, that then 
automatically translates into a "CHECK (fieldname >= 0)" on the 
database, a model-validator on the .save() as well as a 
form-validator for modelform instances (perhaps even with a 
JavaScript client-side validation).  Not all constraints can 
readily be implemented in all 4 locations, but it would be nice 
to have a single source declare "this is a positive integer 
field" and have that automatically enforced at as many levels as 
possible.

(insert random pedantic rant bout "Positive" meaning "> 0" but 
PositiveInteger validations allowing ">= 0", and wishing it were 
a "NonNegativeInteger" validator ;-)


> Tip of the day (vim users today):
> -
> try this in a doctest file:
> 
> :%s/^>>> .*/& # /
> :%s//\=line(".")
> 
> It will append # line number to every line starting with >>> and thus
> enable you to see which test fails.

This can be reduced to

   :g/^>>>/s/$/\=' # '.line('.')

if you prefer it in a one-pass solution (that doesn't eat any 
pre-existing "" in your code). :)

If you want to remove them later, you can use

   :%s/^>>>.*\zs # \d\+$


Thanks again!

-tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Posting to the wrong list (was: Re: Need Django Developer urgent)

[Tim Chase]

> How about:
> 
>   "You're found the wrong list. You're probably looking for django-users
> unless you're interested in the development of the Django framework itself."

+1

[waves hand] This is not the list you are looking for.

-tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: [GSOC] Multiple Database API proposal

[Tim Chase]

> I'm here soliciting feedback on both the API, and any potential hurdles I
> may have missed.

While my vote may mean little, Alex has certainly been active and 
had quality code on the mailing list.  MultiDB has also been a 
frequent issue on the mailing-list, so Alex gets my +1

I'd hope to see "multiple databases" defined a little more 
clearly as discussed in this thread[1].  Whether the SoC project 
address *all* of the facets (wow, lots of work!) or just selects 
certain issues, I'd like to see them addressed in the proposal 
("addressing federation and load-balancing, but not sharding") to 
show that they're being considered during the implementation. 
 From what I gather in the description, Alex is only proposing 
load-balancing.

Depending on which definitions of multidb you plan to address, it 
also impacts areas such as aggregation (performing 
count/summation over shards requires extra consideration) and 
cross-database joining.  In the above thread, Malcolm also raises 
the issue of read/write consistency when doing load-balancing.

-tim

[1]
http://groups.google.com/group/django-users/browse_thread/thread/663046559fd0f9c1/




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: proposal: forloop previous and next

[Tim Chase]

Santiago Perez wrote:
> Hi, I found myself needing to reference the previous or next 
> element of a list within a for loop of a template. I think it
> would be pretty easy to implement the following extra members
> to the forloop context variable:
> 
> + forloop.next_element
> + forloop.next_counter
> + forloop.next_counter0
> + forloop.previous_element  
> + forloop.previous_counter
> + forloop.previous_counter0
> 
> Am I missing some very simple alternative way of doing this?


I've done this in the past with a filter as detailed in this thread:

http://groups.google.com/group/django-users/browse_thread/thread/e9859caad814de7/

I haven't needed the counter because I always have the current
element of the loop and can add/subtract accordingly.

-tim






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Joins and aggregates

[Tim Chase]

>> 1) Prevent joins at the query level. Keep track of the joins
>> that are being used for aggregates, and only allow one join.
>> This would mean killing a lot of queries that work correctly
>> right now, but would prevent the class of invalid queries.
>> 
>> 2) Push aggregates into subqueries. Rather than try to 
>> accomodate aggregates using GROUP BY in the main query, 
>> generate a subquery for each aggregate and join the main 
>> query table onto the aggregate subquery table to provide the
>> annotation.  Obviously, this is going to get very expensive
>> at the query level.
>> 
>> Any opinions? Any other options that I may have missed?

Is there a mid-way point?  It looks like aggregates work
with _one_ join, but not _more_ than one join.  So possibly
use aggregates as they currently stand for the _first_ one,
and then use #2 above (aggregates in subqueries) for
subsequently joined data.  It allows you to maintain the
efficient grouping queries for the common (single-table)
joins, and only invokes the expense of #2 if there's a 2nd
table for aggregation.

I haven't waded into the QSRF+Aggregate code lately, so I
don't know how easy it would be to add in "this is how many
tables we've joined so far" tracking.

-tim






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dropping Python 2.3 compatibility for Django 1.1

[Tim Chase]

James Bennett wrote:
> Apologies for the length of this email,

Thanks, James, for your post-doctoral dissertation on the History 
and Cumulative Predicted Future of Python Versions and Their 
Interrelations With the Django Development Process. :-)  (joking 
aside, it was an appreciated and well-researched post)

For the most part, I give a +1 to James's plan of action.  The 
only item I'd tweak is giving hard cut-off correlations between 
Django versions and Python version.  Just as his Hunt for Red 
October example shows, Python shouldn't be *forcing* Django to 
bump up the supported version number, but rather making 
developers *want* to drop support.

It seems the current catalyst for the "drop 2.3" thread is that 
2.3 has baggage associated with it that keeps Django from 
evolving as rapidly as developers want.  Whether decorator 
syntax, built-in sets, generator syntax, performance issues, bugs 
related to 2.3'ness, testability, or whichever other aspect that 
2.3 lacks, it's putting a drain on developers to be backwards 
compatible.  And from the dialog on this list, there's a clear 
developer *want* to drop 2.3

However, I haven't seen any/much expression of *want* that 2.4 be 
dropped any time in the near future (and there are a much larger 
number of 2.4 deployments).  I wouldn't schedule that "2.4 will 
be dropped in Django 1.3" timetable, but rather a similar lead-up 
process as 2.3 has experienced -- a JKM post of "dropping 2.4 
support.  Discuss" when 2.4 starts causing enough problems to be 
more trouble than it's worth.

So I'm somewhere between -0 and -1 on the voting scale regarding 
forced/long-range Python-version deprecation.  But when a version 
becomes sufficiently dead weight, slowing down Django's progress 
like 2.3 seems to be doing, I'm +0 to +1 on dropping it with one 
Django-version worth of notice.  Once the decision has been made, 
release one last Django version with a "this is the last version 
of Django to support Python version X" notice (judicious timing 
of the discussion-to-drop shortly after an official Django 
release would help).

My 2.8571428571428573e-11 of the $700-billion bailout...

-tim








--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dropping Python 2.3 compatibility for Django 1.1

[Tim Chase]

> I'd like to officially drop Python 2.3 support in Django 1.1.
> Discuss.

+0.5  (not withstanding any panic'ed folks saying "I need 2.3!",
consider it a +1)

I think Debian Stable has moved to 2.4.  All the servers that I
touch currently with 2.3 on them now also have 2.4 on them.

Yay, decorators, generators, and built-in sets!

-tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: "New in development version" equivalent in current docs?

[Tim Chase]

> I'm still coming to grips with Sphinx, but is there any reason that we
> can't just use 1.X or 1.SVN as a version number for the development
> version? That gets around the need to specify the exact version
> number, but keeps it reasonably obvious that it's a development
> version.

If non-digits are allowed, one might even consider something like

   trunk.8123

to indicate that the documentation was added for a feature in 
trunk, r8123 which would help pair documentation with code 
sitting on a developer's machine.

Possible problems (having not tinkered with Sphinx enough to know 
how it works) include:

1) balking at non-digits in a version number

2) if Sphinx builds documentation for each revision it finds, one 
might end up with myriad documentation folders, one for each SVN 
revision in the docs.

Just my $0.02 (though in the current economy, that's pretty 
expensive, but still won't buy you much gasoline ;-)

-tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[Tim Chase]

> I'd trade your controversial part for an alternative: merge mewforms-admin
> back to trunk now.  It's been as 'usable' as old admin for months.  Sure,
> it's got a couple of dozen 'blocking' bugs in the tracker but none of them
> are all that serious.  Current admin, as you note, also has some bugs.
> Trade the existing known-never-going-to-be-fixed current admin bugs for a
> different set of newforms-admin bugs and get on with fixing the second set
> already.  Once on trunk the community's interest will be higher so you'll
> get better feedback on what is and is not really important to users, more
> people who might help out with actual fixes, etc.

+1  as soon as it's deemed that NFA has surpassed oldforms -- as 
measured by bug-free-ness, flexibility of the admin, and general 
consensus of the core developers -- I think merging it into trunk 
will

1) increase visibility by the less-adventurous (read "only as 
adventurous as trunk, not a branch") developers

2) move a step towards Jacob's "let's get on a train" suggestion

3) appease the "we want a 1.0" crowd with notable progress 
towards a 1.0


I'd also add that a public announcement like was done for QSRF 
would help keep it well in the open, rather than a one-line "oh, 
we merged NFA into trunk" added to the backwards-incompat page. 
That way, like with QSRF, folks know there will be a shake-down 
period where a higher volume of bugs will be found/filed and they 
can prepare/test accordingly.


It might also help to have a clear catalog of "1.0 blocking bugs" 
that would prevent a 1.0 release (there might be something in 
Trac that gives this, but my poking didn't find it) so the "we 
want a release" crowd has a tangible list they can be helping with :)

Just my $0.01

-tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[Tim Chase]

>> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
>> rc or two, and then a final release. Features that are done by the
>> dates get released, those that aren't, don't. Make these dates
>> aggressive but not crazy. And -- here's the controversial part -- make
>> newforms-admin an "optional" part. If it's done, awesome; if not,
>> include it in the next release. The current admin has some bugs, yes,
>> but it's usable enough. As long as we advertised that it's on the way
>> out we shouldn't have too much trouble.
>>
>> Thoughts?

-1

I'm not sure blessing it with a number does much but pander to 
folks that are scared to make a tough call:

Use 0.96:  blessed with a magic number, but old and not much like 
1.0 will be

or use Trunk:  suggested (but not  blessed with a number), much 
closer to like 1.0 will be, and still some changes to be expected 
when new-forms hits.

Blessing an interim release means supporting it...namely without 
the features that have been planned for 1.0 and adds confusion as 
to what comprises "Django 1.0"

If Django 1.0 should have NFA and QSR, anything short of that 
should not be called 1.0, IMHO.

Eric Florenzano wrote:
> -0
> 
> I disagree about the newforms-admin part being optional.  Right now
> the admin is great, but it's tightly coupled with the models.  With
> newforms-admin, there's not only a great increase in the power of the
> admin app itself, but it's also a demonstration of best practices for
> creating generic apps with Django.  Also, if a 1.0 got released with
> oldforms-admin, there will be the inevitable media fanfare, so imagine
> the books, tutorials, articles, etc. that will be written which
> referencing the old ways.

I add my support to Eric's reasoning.

-tim





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Aggregation Updates

[Tim Chase]

> To my understanding, a slice isn't automatically a copy - it will be
> in most cases, but there are cases where the bytecode compiler will
> use the original list as an optimization. One example:
> 
>  >>> s = 'abc'
>  >>> t = s[:]
>  >>> s is t
>  True
>
> I'm willing to be corrected here, but my understanding was that for
> loop iteration was one of those optimization cases.

It looks like it's an immutable-optimization from my further 
testing (strings being immutable):

 >>> a = [1,2,3] # use a list (mutable)
 >>> b = a[:]
 >>> a is b
False

 >>> a = (1,2,3)  # use a tuple (immutable)
 >>> b = a[:]
 >>> a is b
True

> necessary for code clarity - I would contend that:
> 
> for x in intial_list[a:b]:
>do stuff
> 
> is easier to read than:
> 
> sub_list = initial_list[a:b]
> for x in sub_list:
>do stuff

in most cases, heartily agreed, so no contention here.

>> Yes, it would be nice if this worked because it's logically
>> true...except that it doesn't work (at least in Postgres and
>> MS-SQL Server):
> 
> Aw...crap. You are, of course, completely correct. I've been spending
> too much time in MySQL of late, and I forgot that this was an
> eccentricity of MySQL.

It's just a shame it's not readily available in other SQL 
flavors, as it bugs me every time I need to add umpteen GROUP BY 
entries just so I can get some values for the SELECT clause.

-tim



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Aggregation Updates

[Tim Chase]

 > * On a similar note, I can see a lot of places where you
 > seem to be copies of lists (or sublists) - this is an
 > expensive operation if you do it a lot, especially since
 > most cases you could get the same effect by keeping the
 > index values and slicing the original list as required.
 > Handling for row[:aggregate_start] seems to be the worst
 > culprit here.

My understanding is that slicing a list produces a new list,
so I'm not sure this is a real gain.  Each object in the
list is only held once (unless copy.deepcopy() is called)
and the new (sub)list merely contains references to those
object-ids, like any other python variable.

 > * Be careful about generating efficient SQL, not just
 > correct SQL. In particular, with the grouping clause:
 > remember that:
 >
 > SELECT author.id, author.name, author.age, COUNT(book.id)
 >   FROM author INNER JOIN book ON author.id=book.author_id
 >   GROUP BY author.id, author.name, author.age;
 >
 > is the same as
 >
 > SELECT author.id, author.name, author.age, COUNT(book.id)
 >   FROM author INNER JOIN book ON author.id=book.author_id
 >   GROUP BY author.id;
 >
 > except that the latter will be much faster because group 
uniqueness is
 > easier to compute.

Yes, it would be nice if this worked because it's logically
true...except that it doesn't work (at least in Postgres and
MS-SQL Server):

   -- issued in psql:
   SELECT s.id, s.statement_dt, count(sli.id)
   FROM mt_statement s
 INNER JOIN mt_statementlineitem sli
 ON sli.statement_id = s.id group by s.id;

   ERROR:  column "s.statement_dt" must appear in the
   GROUP BY clause or be used in an aggregate function

(doing a "SELECT Version()" returns "PostgreSQL 8.1.11 on
i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)")

even though s.id is the primary key for mt2_statement.

I don't have a quick test DB in MySQL or sqlite to test on
hand at the moment.  Perhaps one of them is smarter?

-tim












--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Newbe questions (firebird)

[Tim Chase]

>> The real problem is when I try to access the database. I get
>> stack trace below. It looks like it is trying to use the 
>> LIMIT keyword incorrectly.

As best I can tell, Firebird doesn't support the SELECT ... LIMIT
x OFFSET y" notation, but rather uses "SELECT FIRST x [SKIP y]
..." as detailed here:

http://scott.yang.id.au/2004/01/limit-in-select-statements-in-firebird/

(and I concur on the author's "[Firebird's] documentation is
lacking" as after dilligent seeking on the FB site, I couldn't
find a simple BNF grammer of their SQL flavor)

You'd have to create your own backend that uses this notation for
slicing.  At least FB does have such limit/offset notation,
unlike SQL Server for which it's a pain.

-tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: _QuerySet.first()

[Tim Chase]

> I poked around 'django.db.model.query' this morning and noticed that 
> '_QuerySet' class has 'latest(self, field_name=None)' method. I was 
> wondering if adding 'first(self, field_name=None)' had been considered 
> before.
> 
> It seems that could be a useful shortcut in some instances.

Does this differ from just using a slice does?

   foo = MyModel.objects.all()[0]

which is exactly what what get() does (though IIRC, it also does 
some checks to ensure that one-and-only-one record comes back).

-tim



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Maybe DEBUG=True should only record the last N SQL queries?

[Tim Chase]

> If we want to crash and burn if you use DEBUG=True in
> production we should do that explicitly, not as a side effect
> of another feature. I think there is enough real-world
> evidence that people are being tripped up by this for
> legitimate reasons (running import scripts in development
> mode, for example) that it's worth fixing.

Rather than crashing and burning, perhaps an option to log SQL 
queries to a file instead of memory?

It does lack the ability to query them back easily, but I find 
most of the time I just want to review all the queries that have 
been run and I'd much rather do that in a syntax-aware editor 
like Vim than from a pdb session or trying to dump them cleanly 
over a web connection.  A dump file also has the advantages of 
being easy to spot and identify the problem ("why on earth is 
there a 4-GB queries_executed_since_time_began.sql sucking up my 
disk space?!" vs. the more amorphous "why is Django such a memory 
hog?!").  This also has the advantage that you can log as many 
queries as you have disk-space for, addressing the problem of 
"log N items and item N+1 was the troublemaker".  It can even be 
used with a logrotate sort of cron script to keep them around, 
but zip up older archives.

Sorry if this has already been discussed, but if so, I missed it.

-tim



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Model Inheritance

[Tim Chase]

>> class X(models.Model):
>>  x = models.CharField()
>> 
>> class Y(X):
>>  y = models.CharField()
>> 
>> class Z(X):
>>  z = models.CharField()
>> 
>> produced the tables
>> 
>> x(id, x)
>> y(id, x, y)
>> z(id, x, y, z)
>>
>>  All I need to know is if this is some kind of fall-back till full-
>>  blown model inheritance is implemented, or if this is just a fluke.
> 
> It's a fluke. More information can be obtained from a Google search
> for "Django model inheritance".

If this is a fluke that will eventually be "fixed", will there be 
a way to replicate this sort of behavior (or at least some of the 
side-effects), to get/keep "mix-ins", such as

   class Audited(object):
 user = ForeignKey(User)
 created = DateTime(...)
 updated = DateTime(...)
 def some_method(self): pass

   class MyModel(Model, Audited):
 important = CharField(...)

   :
   :

   m = MyModel.objects.get(id=42)
   m.user = request.user
   m.some_method()

-tim





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---