Re: Avoid unbounded memory consumption when running `manage.py test`

[Matt McClure]

On Thursday, August 1, 2013 3:50:33 AM UTC-4, Florian Apolloner wrote:

> For Python >= 2.7 it should be CPython; for everything below the separate 
> unittest2 repository. 
>

Thanks.

Just closing the loop. Now there's a conversation[1] on python-dev which 
led to an existing ticket[2] that's almost ready for commit to CPython.

[1]: http://thread.gmane.org/gmane.comp.python.devel/140923
[2]: http://bugs.python.org/issue11798

-- 
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.

Change username field widget in AuthenticationForm based on USERNAME_FIELD

[Anders Steinlein]

Hi all,

I have implemented a custom user model that extends AbstractBaseUser, where
an EmailField is set as the USERNAME_FIELD. Logging in with a default auth
login view and AuthenticationForm works nicely, however, the username field
is still a CharField and thus rendered as a regular input field. I'm using
Django 1.6 where I was expecting a type='email' input field.

How about we change the widget of the username field in AuthenticationForms
__init__ method based on USERNAME_FIELD? If yes, would it be too late to
sneak this into 1.6 given the new use of HTML5 input types? I'm happy to
provide a patch.


*Anders Steinlein*
*Eliksir AS*
http://e5r.no

E-post: and...@e5r.no
Mobil: +47 926 13 069
Twitter: @asteinlein

-- 
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.

Use case for #14914 (to_db_python)

[Alejandro Dubrovsky]

Looking around for a way to get the connection on deserialisation, I ran 
into #14914  which was closed 
wontfix 3 years ago with a request for a use case for the change.

Here is my use case:

I'm writing an encrypted char field, with encryption happening at the 
database end (MS-SQL). Decryption looks a bit like this:


OPEN SYMMETRIC KEY keyname
DECRYPTION BY CERTIFICATE somecertificate

SELECT CAST(DECRYPTBYKEY(fieldname) AS VARCHAR(2048))
FROM atable

CLOSE SYMMETRIC KEY keyname


and analogously for the encryption.

The way I thought of doing that was by modifying get_db_prep_value for 
encryption and to_python for decryption, but I ran into the lack of 
connection at the to_python stage, and nothing like to_db_python.
Does this constitute a legitimate use case for to_db_python or is there a 
better way to go about this?
Note: I'd prefer if any discussion would stay away from the validity of 
using DB-based symmetric encryption on specific fields.

In the more general sense, I'd expect the method to be useful for any 
stored-procedure-heavy location where the extracted field has to be 
post-processed by some function that runs on the database to be made sense 
of.

Thanks


-- 
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: [GSoC] Revamping validation framework and merging django-secure once again

[Christopher Medrela]

Unfortunately, I'm a bit late. I didn't suspected that polishing code after
review takes so much time. Lots of my work from last Wednesday was small
improvements, but there are some vital changes:

The API will be consistent with API of logging module or message framework.
Being consistent means that system check framework will be familiar to lots 
of
developers. The change is that every message has its `level` now -- one of
CRITICAL, ERROR, WARNING, INFO or DEBUG integer values. Django users may add
their own levels (like SUPER_CRITICAL) since `level` is an integer.

This change affected output format. All messages are sorted by level (and 
then
by source of problem), so critical errors are first on the list and there 
is no
opportunity to miss an important error in the middle of long list of 
warnings.

There is some stuff that still need to be done as part of reviewing, i. e.
deprecating `BaseCommand.validate` in favour of `check` or adding tests for
`GenericForeignKey`. After finishing polishing I will focus on moving custom
User model checks to auth apps, and then on rewritting admin checks.

Note that there is a lot of discussion on the pull request [1].

[1] https://github.com/django/django/pull/1364

-- 
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.