Re: Re : Validate that IntegerField is a valid Signed value

[Cal Leeming [Simplicity Media Ltd]]

Hey Mathieu,

Thanks for taking the time to reply. I'm starting to see now why the core
devs are reluctant to modify IntegerField.

I'm wondering if maybe Django should have a SignedIntegerField and
UnsignedIntegerField as part of the core (for those that wish to have
enforced 32-bit integers), with the same INT_MIN and INT_MAX from limits.h (
http://en.wikipedia.org/wiki/Limits.h). But there again, would this be
considered un-pythonic or against the ethics of Django?

I guess really it should be up to MySQL to have strict mode by default. But,
as this is unlikely to happen, could we perhaps consider having a commented
out entry in the settings.py file that allows you to set strict mode for all
SQL connections? Or, perhaps a documentation change, which explains easily
to the user how to do it (Kinda like the storage_engine thing on
http://docs.djangoproject.com/en/dev/ref/databases/#creating-your-tables ) .

Let me know your thoughts :)

Cal


On Sat, Apr 30, 2011 at 6:32 PM, Mathieu AGOPIAN
wrote:

> Hello,
>
> I'm afraid there isn't such a thing as "a valid signed value", if we're
> still talking about "size wise".
>
> For django (python), the integer you gave in the ticket is perfectly valid.
> Here's a way for you to check that :
> >>> s = '351760125423456632454565345363453423453465345453'
> >>> int(s)
> 351760125423456632454565345363453423453465345453L
>
> And indeed, an IntegerField validates that the content of the field can be
> converted to an int this way (check django/forms/fields.py line 230).
>
> So definitely, as Alex pointed, this is an issue on MySQL's side, not
> Django's.
> I believe this can't (shan't?) be fixed at Django's level, as there's no
> "size" limitation for the IntegerField, as you would have on a CharField
> with the *max_length* attribute.
>
> And no, limiting the length of the string won't work, as "2147483647" isn't
> the same length as "-2147483647", but is the same length as "99" (if
> we're taking the example of 2^32-1 as the max SIGNED INT value).
>
> my two cents ;)
>
> --
> 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.
>

-- 
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 : Validate that IntegerField is a valid Signed value

[Mathieu AGOPIAN]

Hello,

I'm afraid there isn't such a thing as "a valid signed value", if we're 
still talking about "size wise".

For django (python), the integer you gave in the ticket is perfectly valid. 
Here's a way for you to check that :
>>> s = '351760125423456632454565345363453423453465345453'
>>> int(s)
351760125423456632454565345363453423453465345453L

And indeed, an IntegerField validates that the content of the field can be 
converted to an int this way (check django/forms/fields.py line 230).

So definitely, as Alex pointed, this is an issue on MySQL's side, not 
Django's.
I believe this can't (shan't?) be fixed at Django's level, as there's no 
"size" limitation for the IntegerField, as you would have on a CharField 
with the *max_length* attribute.

And no, limiting the length of the string won't work, as "2147483647" isn't 
the same length as "-2147483647", but is the same length as "99" (if 
we're taking the example of 2^32-1 as the max SIGNED INT value).

my two cents ;)

-- 
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 : Validate that IntegerField is a valid Signed value

[Mathieu AGOPIAN]

Hello,

I'm afraid there isn't such a thing as "a valid signed value", if we're 
still talking about "size wise".

For django (python), the integer you gave in the ticket is perfectly valid. 
Here's a way for you to check that :
>>> s = '351760125423456632454565345363453423453465345453'
>>> int(s)
351760125423456632454565345363453423453465345453L

And indeed, an IntegerField validates that the content of the field can be 
converted to an int this way (check django/forms/fields.py line 230).

So definitely, as Alex pointed, this is an issue on MySQL's side, not 
Django's.
I believe this can't (shan't?) be fixed at Django's level, as there's no 
"size" limitation for the IntegerField, as you would have on a CharField 
with the *max_length* attribute.

And no, limiting the length of the string won't work, as "2147483647" isn't 
the same length as "-2147483647", but is the same length as "99" (if 
we're taking the example of 2^32-1 as the max SIGNED INT value).

my two cents ;)

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

Validate that IntegerField is a valid Signed value

[Cal Leeming [Simplicity Media Ltd]]

http://code.djangoproject.com/ticket/15923#comment:13

Currently, Django doesn't validate if a value on an IntegerField is indeed a
valid signed value.

Could someone please confirm (in others such as CharField) if value
validation is left for the database to decide (for example, string length,
encoding type etc), or is this validated within Django?

If it's validated within Django, then surely we should also be validating
IntegerField as well? If it's not, then I apologise.

Cal

-- 
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: [5-for-1] Review request

[Aymeric Augustin]

Hello,

I would like a core dev's opinion on #11555.

The tickets I reviewed are listed here: http://myks.org/stuff/django_5-for-1.txt

Thanks,

-- 
Aymeric Augustin.

-- 
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: Feature request: log capture during testing

[sebastien piquemal]

Have you tried Nose ?
http://somethingaboutorange.com/mrl/projects/nose/1.0.0/
https://github.com/jbalogh/django-nose/commits/master
I think it captures the logs quite well ...

On Apr 29, 10:20 pm, Jody McIntyre  wrote:
> Now that Django has logging support using the Python logging module,
> it would be nice if the unit testing framework included the ability to
> capture logs, similarly to the mail.outbox functionality.
>
> I am aware of the log_capture decorator in the testfixtures package,
> and we are using it for some tests.  Unfortunately, it doesn't
> correctly capture anything that's been changed by a filter, since it
> installs itself as a handler without preserving filters attached to
> existing handlers.  It would be great if Django could do better!
>
> Cheers,
> Jody

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