I would be happy to revisit that decision which was made 9 years ago. APIs
returning unusual status codes such as 204 are much more common now than
they were then. I can't think of a good reason not to add ~10-15 2-line
classes.
Marc
On 7 April 2017 at 09:37, Brice PARENT wrote:
>
> Le 07/04/17
Hello all,
A recent PR[1] seeks to replace most of the assertRaises() calls in the test-
suite with assertRaisesMessage(). The argument for it is that it then becomes
easier to find the test for some error handling, by grepping the test for the
message text. Also, in some cases, an existing asse
On Fri, Apr 7, 2017 at 9:54 AM, Adam Johnson wrote:
> Personally I'd be in favour of adding such classes. It seems against the
> batteries-included philosophy that Django does not provide all of the
> standard codes as classes. I can never remember which codes correspond to
> which response types,
Hey, it's been a number of years and I'd like to revisit this topic.
I still consider it an anti-pattern to have __repr__ make a call to
self.__unicode__ or self.__str__ as these can (and very often do) refer to
related database objects. The last thing you want to happen while debugging
a crash
Hi Shai,
Without testing for a message, there's also a possibility that the
exception you think you're testing isn't the one the test is actually
raising. I think the readability advantages of including messages in the
tests outweigh the cost of updating tests when a message changes.
On Friday
Hi Tim,
> Without testing for a message, there's also a possibility that the
> exception you think you're testing isn't the one the test is actually
> raising.
If you need to verify the error message for that reason, then the exception is
probably not specific enough. Testing the message, in th
I'd like to support this, I've seen my share of situations such as the one
described by Patryk. Is there something we have been missing ?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from
I agree with Tim. He's also probably the most familiar with the cost of
message changes 😊
On 7 April 2017 at 12:56, Tim Graham wrote:
> Hi Shai,
>
> Without testing for a message, there's also a possibility that the
> exception you think you're testing isn't the one the test is actually
> raisin
That said more structured attributes on exceptions can be useful for Django
users, if you know any obvious places they are missing.
On 7 April 2017 at 13:23, Adam Johnson wrote:
> I agree with Tim. He's also probably the most familiar with the cost of
> message changes 😊
>
> On 7 April 2017 at 1
Patryk, when you say 'revisit', do you have links to the original
discussion/tickets?
I also agree that __repr__ shouldn't be able to trigger extra DB queries in
a standard setup.
On 7 April 2017 at 13:18, wrote:
> I'd like to support this, I've seen my share of situations such as the one
> des
Hello,
This is an idea that came up during the djangocon-europe conference: Add the
ability to install general instrumentation hooks around the database "execute"
and "executemany" calls.
Such hooks would allow all sorts of interesting features. For one, they could
replace the current special-
On Friday 07 April 2017 15:35:55 Adam Johnson wrote:
> Patryk, when you say 'revisit', do you have links to the original
> discussion/tickets?
He was replying to a thread from 2013. You should have the link at the bottom
of every message.
>
> I also agree that __repr__ shouldn't be able to trig
I noticed this on the init
def __init__(self, *args, **kwargs):
# Alias some things as locals to avoid repeat global lookups
cls = self.__class__
maybe you should change it to self.cls??
Try to submit a PR to the open ticket.
segunda-feira, 3 de Abril de 2017 às 21:07:47 UTC+1, Kapil Garg escr
Without diving into implementation details, I recon I've been taught the
same as Shai. An exception type should have only one purpose, thus testing
the type /should/ be sufficient imho. That said, if you want to TDD the
message, you're going to code a test for it, is there really another way ?
;)
The opened ticket is about Model.__str__ method. Should i open a new ticket
for this change ?
As i see in code, self.__class__ is used in a lot of places but will it
effect optimization if we change lookups from self.__class__ to self.cls
Because the methods where class is being used frequently, a
Hi Shai,
On 04/07/2017 06:02 AM, Shai Berger wrote:
> This is an idea that came up during the djangocon-europe conference: Add the
> ability to install general instrumentation hooks around the database
> "execute"
> and "executemany" calls.
>
> Such hooks would allow all sorts of interesting f
Hi All,
Looking at the code snippet, cls is a _local_ variable, not an instance
attribute (self.cls). If we changed it to an instance attribute, it would
lose most of the speed optimization. Also, self.cls would possibly clash
with a field named "cls".
Collin
On Fri, Apr 7, 2017 at 10:33 AM, Ka
On Friday 07 April 2017 17:47:51 Carl Meyer wrote:
> Hi Shai,
>
> On 04/07/2017 06:02 AM, Shai Berger wrote:
> > This is an idea that came up during the djangocon-europe conference: Add
> > the ability to install general instrumentation hooks around the database
> > "execute" and "executemany" cal
On Thu, Apr 6, 2017 at 5:22 PM, James Pic wrote:
> Do I need this to deploy my projects ? No of course, because I use the
> prettiest way hhihihi ;) I'm more than happy to win a debate
>
Please don't do this. This does not make you look like someone who I could
constructively engage with to try
19 matches
Mail list logo
