It is notable that if the number of items is a secret (say, you don't
want to reveal how many sales items you have), just having information
about sequential numbers is bad. In that case you should use UUID,
which the documentation could point out.
On Wed, Apr 6, 2016 at 4:35 AM, Josh Smeaton wro
I like the idea of addressing the OWASP top 10. Further, I think the advice
of obscuring keys is wrong. The problem is actually addressed in the OWASP
Top 10[0]
*4 Insecure Direct Object References:*
A direct object reference occurs when a developer exposes a reference to an
internal implementa
>From a Trac ticket [0]: "Using incremental URLs (i.e. /comment/1 is the
first comment and /comment/2 is the second comment, respectively for base
64 or other counting systems) is highly dangerous for private information.
You could simply get all of the, say, private comments by accessing all
Any thoughts about whether or not to make similar simplifications to
URLValidator? There's an old ticket to add a DomainNameValidator [0] which
may or may not be worth moving forward with based on the decision.
[0] https://code.djangoproject.com/ticket/18119
On Saturday, April 2, 2016 at 3:05:1
I'm not sure when it changed, but decimal.Decimal(some_float) was also an
error in 2.4 and 2.6 at least. I'm seeing that it works in 2.7, 3.3, 3.4,
3.5, so it's probably a recent decision, looking up the rationale for that
could be relevant
On Tue, Apr 5, 2016 at 3:30 PM, Aymeric Augustin <
aymeri
Small corrections:
About 1) — actually decimal.Decimal() was an error Python 3.0 and 3.1.
About 2) — I mixed up two options for the factory to build decimals from floats:
- the decimal.Decimal.from_float class method — which I assume uses the global
context
- the decimal.Context..create_decimal
I have three ideas about this.
1) In my opinion, assigning a float to a decimal field is a programming error.
Sadly Python doesn’t raise an exception in that case.
>>> decimal.Decimal(2.15)
Decimal('2.149911182158029987476766109466552734375')
So Django has to support it as well.
2)
On 5 April 2016 at 14:49, Tim Graham wrote:
> The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest with
> ties going to nearest even integer). There's a proposal to change this to
> cast floats to string and then use ROUND_HALF_UP to match the value of
> strings [0][1]. Do you h
If you assign a float with more decimal places than a DecimalField field
supports to that field, the value may round differently than if you assign
the same value as a string. For example:
class Invoice(models.Model):
gross = models.DecimalField(max_digits=10, decimal_places=1)
invoice.gros
See the discussion on the pull request:
https://github.com/django/django/pull/6416
Aymeric says, "The GCBV API is already widely criticized for being too
complicated. I think that adding one method to save one line of code is a
bad trade-off. I'm -1."
On Sunday, April 3, 2016 at 3:35:26 PM UTC
Adding dependencies would definitely be a huge step forward. I think
Django doesn't have them because pip wasn't as awesome as it is today
back in the early days, but nowadays it would definitely make sense.
That would mean a bit more work for distribution package maintainers
but if we can start co
11 matches
Mail list logo
