As someone who has spent over 12 years working with Django, I'd like to
offer an opposite point of view:
I love where Django is headed. I love all of those breaking changes that
have to happen so we're not perpetually stuck with decisions from 2005.
What I truly miss is strong static typing sup
W dniu sobota, 10 sierpnia 2019 18:19:07 UTC+2 użytkownik Uri napisał:
>
> Thanks for your feedback. Eventually I found out that the Django Crispy
> Forms issue was a CSS bug in our CSS code. Anyway not related to Crispy
> Forms, it may take a lot of time and effort to upgrade Django for us, and
>
> We've always considered that implicit queries on attribute access were an
> intractable problem. I said it on stage an DjangoCon US 2013. I'm now
> wondering if I was wrong all along! In an async ORM context, every time we
> traverse a relation, we could create a Future that would execute t
>
> I don't think it makes a significant difference from a readability
> perspective in this example. It does have some advantages, though:
>
> - It could be easier to implement a sync version based on the async one,
> or vice-versa, if each one has its own class. It will probably be more DRY.
W dniu czwartek, 9 maja 2019 22:47:48 UTC+2 użytkownik J. Pic napisał:
>
> I'm a bit confused here, what benefit are you getting from async emails if
> you're already retrying emails in the background in production ?
>
Anything that uses I/O should be async to unblock the worker to process
other
>
> I am also not a fan of the approach, but I did err towards being explicit.
> Jannis suggested what I think might be a nicer approach on Twitter, which
> is to add an async "proxy object" to access methods with, e.g.:
>
> cache.get("foo")
> cache.async.get("foo")
>
> This is still explicit bu
>
> That said, I also think it's important to allow the ORM to support both
> modes in the long term. I truly believe the best way to be able to write
> async code is to _have the choice to write it_, rather than being made to
> all the time; if we make people use a separate, async ORM, then we
>
> I'm not sure but for me the "What is Django" section answers the question.
> For me Django is full of philosophy that seeds a great ecosystem of apps of
> all sorts with a growing user base nonetheless, and a bunch of brilliant
> hackers to look up to and inspire for more. Of course if you'
Hey Andrew,
Great work on the DEP, the task at hand is humongous.
Do you think it's worth it to try and make the ORM async? It contains tons
of magic that is inherently incompatible with explicit I/O that is required
for async/await to work, things like silently fetching relations on first
acc
Sorry for resurrecting but this is still very much a problem. Same person,
same autoresponder.
--
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
o 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@g
W dniu czwartek, 7 grudnia 2017 08:12:52 UTC+1 użytkownik Aymeric Augustin
napisał:
>
> The duration of the deprecation period doesn't make a big difference
> because few people update their code until they have no other choice.
> Keeping deprecated code around longer means it's harder to track
W dniu wtorek, 26 września 2017 14:34:29 UTC+2 użytkownik Jonas H napisał:
>
> Proposal: Support the __html__ method as an alternative/addition to the
> __str__ for turning objects into strings in the template layer.
>
> If this has been discussed before, please point me to it; I couldn't find
>
W dniu poniedziałek, 11 września 2017 05:28:55 UTC+2 użytkownik Nes Dis
napisał:
>
> Thank you all for your very insightful comments. I personally am a big
> user/contributor to the framework myself and would like to see it thrive
> and progress with respect to other competing frameworks.
>
> I
W dniu środa, 16 sierpnia 2017 14:48:54 UTC+2 użytkownik Luke Plant napisał:
>
> I completely agree that visibility of this problem is a major issue, and
> would really welcome work on improving this, especially in DEBUG mode. One
> option might be a method that replaces lazy loads with exception
W dniu piątek, 7 lipca 2017 23:54:07 UTC+2 użytkownik Andrew Godwin napisał:
>
> There is already a run-before constraint you can add to migrations for
> exactly this purpose! It's called "run_before" and is in the same format as
> the dependencies IIRC.
>
The problem with "run before X" is that
W dniu wtorek, 4 lipca 2017 23:49:54 UTC+2 użytkownik Carl Meyer napisał:
>
> On 07/04/2017 07:04 AM, Patryk Zawadzki wrote:
> > Have DB backends understand certain field types expressed as strings
> > ("varchar", "text", "blob", "decima
W dniu piątek, 23 czerwca 2017 21:28:07 UTC+2 użytkownik Andrew Godwin
napisał:
>
>
>>
>> The advantages comes from db type independency, this is true, but in the
>> other side you're including the app layer dependency.
>>
>> Let's imagine that one of builtin field will change it's definition.
W dniu niedziela, 21 maja 2017 01:35:28 UTC+2 użytkownik Ramiro Morales
napisał:
>
> I'm also surprised by your findings. I guess it's something we simply took
> for granted. It's mentioned in the [1]docs and has been so for [2]years.
>
It's not the same case though. Docs say that if `de-at` is
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
W dniu poniedziałek, 20 lutego 2017 11:49:38 UTC+1 użytkownik Markus
Holtermann napisał:
>
> On Thu, Feb 16, 2017 at 03:25:16PM -0800, rap...@makeleaps.com
> wrote:
> >RemoveField('A', 'foo') also references A and foo, but does it reference
> B?
> >if it does, then it' s hard to have optimiza
W dniu wtorek, 14 lutego 2017 16:19:48 UTC+1 użytkownik jp...@yourlabs.org
napisał:
>
> However, there's a third alternative to changing Meta that may be worth
> suggesting: adding a new Field attribute ie. translatable=True, which could
> be default for CharField and TextField perhaps. It might
I think the proposed fields are mostly useful for translation utilities
that modify your schema on the fly. I consider these to be the least clean
solutions as they mean none of the translated fields can be marked as
required. For other solutions (depending on separate tables and
registration)
W dniu poniedziałek, 16 stycznia 2017 18:55:25 UTC+1 użytkownik Martin
Koistinen napisał:
>
> Also, if a developer is experienced/motivated enough to *lower* the hash
> iterations, s/he'll be more likely to also be experienced/motivated enough
> to put other controls in place to compensate.
>
O
Are you sure you need to depend on users "logging in" through an API? Most
authentication methods used in APIs are stateless and there is no explicit
login and logout process. You either include the credentials (be it bearer
token, auth header, custom data or whatever) or not. The credentials ar
To add some context, REPEATABLE READ can break get_or_create among other
things (not sure how many invalid tickets Django gets related to that).
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscri
W dniu piątek, 2 grudnia 2016 12:05:11 UTC+1 użytkownik Mateusz Mikołajczyk
napisał:
>
> What would you say about checking which CRUD operations were executed
> within atomic() call (in order to serialize them and save into a special
> model for databases which don't support this functionality)
I've just hit another problem related to custom fields.
Currently migrations contain information about "rich" fields. If you use a
custom field type, the migration code will currently import your field type
from its Python module. This is highly problematic in case either the code
moves or you lat
10 and am aware of the recent optimisations as I
helped with some of them during previous DUTHs.
Simon
>
> [1] https://github.com/django/django/pull/7468
>
>
> Le dimanche 6 novembre 2016 00:32:04 UTC+1, Marten Kenbeek a écrit :
>
> On Saturday, November 5, 2016 at 4:53:49 P
W dniu sobota, 5 listopada 2016 19:57:38 UTC+1 użytkownik Aymeric Augustin
napisał:
>
> My solution is to throw away and remake all migrations on a regular basis.
> Then I `TRUNCATE TABLE django_migrations` and `django-admin migrate
> --fake`. Obviously this isn’t a great solution.
>
> Since I
W dniu sobota, 5 listopada 2016 18:40:24 UTC+1 użytkownik Shai Berger
napisał:
>
> > 2. Dependency resolution is only stable as long as the migration set is
> > frozen. Sometimes introducing a new migration is enough to break
> existing
> > migrations by causing them to execute in a slightly di
W dniu sobota, 5 listopada 2016 17:30:15 UTC+1 użytkownik Andrew Godwin
napisał:
>
> Hello! I have opinions about this :)
>
>
>> Possible solution (or "how I'd build it today if there was no existing
>> code in Django core"):
>>
>> a. Make migrations part of the project and not individual apps.
W dniu sobota, 5 listopada 2016 13:24:28 UTC+1 użytkownik Jacob Kaplan-Moss
napisał:
>
> Hi all -
>
> DEP 7 proposes a new dependency policy. In a nutshell, the policy is:
> Python packaging is good now. Django can have dependancies.
>
> For full details, please check out the DEP:
> https://gith
Greetings, Jazz Guitarists,
I've briefly talked about this with Markus and he mentioned that the
subject was already brought up by Tyson Clugg but I think it deserves a
proper discussion here.
I'm typing this from the comfort of Django: Under the Hood sprints so
please excuse poor grammar and
pt., 22.01.2016 o 17:44 użytkownik charettes napisał:
> Hi Patryk,
>
>
> > Currently we have Prefetch objects that kind of solve this problem for
> M2M
> > relations but perhaps it would be nice to also be able to use QuerySets
> in
> > select_related() or even in filter(). I don't think Prefetch
Hi,
Currently the way QuerySets work makes it hard to reuse code. Consider an
example where I have template tags to render an author and a book (that in
turn displays author). I don't want my template code to execute any
additional queries per row displayed so I am forced to prefetch everything
up
2015-11-12 17:40 GMT+01:00 Carl Meyer :
> On 11/12/2015 05:48 AM, Patryk Zawadzki wrote:
>> * Setting the target version to a higher value could turn deprecation
>> warnings to exceptions for all features deprecated in the target
>> version and earlier (which could make futu
e?
Cheers,
--
Patryk Zawadzki
I solve problems.
--
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
2015-08-07 16:51 GMT+02:00 Martin Owens :
> Could we use something simple like 'update()' and 'commit()' to which save
> would call both?
Or `.apply()` and `.commit()` not to suggest that the form gets
updated in any way.
--
Patryk Zawadzki
I solve problems.
--
'd end up only having a single
thing to deal with (forms) and would allow existing views to
transparently handle situations where more than one form is needed
(just create a form that consists of two subform fields).
--
Patryk Zawadzki
I solve problems.
--
You received this message because you a
he concept of initial data. I'd like to get rid of that as well
but Russell is not sure whether there are cases that require initial
forms to work correctly.
--
Patryk Zawadzki
I solve problems.
--
You received this message because you are subscribed to the Google Groups
"Django deve
Playground: https://github.com/django/django/pull/4797
--
Patryk Zawadzki
I solve problems.
--
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 e
de an extra hidden field. Honza may
or may not kill me for suggesting that.
For now, I would like to make the formset optional and document the
cases where you need to include it. If included, it would take
precedence to keep the existing deployments working.
Thoughts?
--
Patryk Zawadzki
I
Related
thread:
https://groups.google.com/d/topic/django-developers/9piN0wRFbLs/discussion
--
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-develope
to
trigger MultipleObjectsReturned.
Related pull request: https://github.com/django/django/pull/1139
--
Patryk Zawadzki
I solve problems.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop rece
.
Backward compatibility should not be a concern here as no code should
depend on whatever __repr__ chooses to return.
--
Patryk Zawadzki
I solve problems.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from
bees!
> {% endwith %}
What about:
{% with nonempty my_bonnet.bees as bees %}
{% for bee in bees %}
{{ bee }}
{% endfor %}
{% endwith %}
--
Patryk Zawadzki
I solve problems.
--
You received this message because you are subscribed to the Google Groups
"Django develop
18 maj 2013 18:48, "Anssi Kääriäinen" napisał(a):
> There was very similar discussion recently (maybe in some ticket, I
> don't remember where) about QuerySet.__repr__(). IIRC the conclusion
> was that executing SELECT queries as part of __repr__() is OK.
I've been bitten by that one already. At
ional side effects (like executing a
database query inside __unicode__).
--
Patryk Zawadzki
I solve problems.
--
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, se
ct it only uses the logging
library):
https://github.com/patrys/great-justice
--
Patryk Zawadzki
I solve problems.
--
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@googl
erested in this bug as it couses us quite a headache in the
Satchless project. Being unable to select_related() we currently have
to choose between making an extra query (ouch) and ignoring the ORM
(eww).
Cheers,
¹ https://code.djangoproject.com/ticket/16572
--
Patryk Zawadzki
I solve problems
le possible, it's
not very convenient to dine using a swiss army knife.
--
Patryk Zawadzki
I solve problems.
--
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@goo
h of the ORM API as it makes sense should be supported
by the Document but I really feel these should be designed as separate
object types.
--
Patryk Zawadzki
I solve problems.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To po
ot be backwards compatible for existing
> django applications already using this field in User?
This problem is now more severe due to Facebook returning proxied
e-mail addresses in this format:
apps+111.22.abcdef0123456789abcdef0123456...@proxymail.facebook.com
--
Patry
On Fri, Apr 1, 2011 at 12:01 AM, Luke Plant wrote:
> On 31/03/11 19:35, Patryk Zawadzki wrote:
>> * for 1.4 provide a number of fallback settings that can be used to
>> enable legacy behavior in each of the first three points
> but this is where it falls down, because the devil
g_saved(sender, instance, created, **kwargs):
if not kwargs.get('raw', False):
do_stuff()
--
Patryk Zawadzki
I solve problems.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-de
ferent app authors etc.)
* for 1.4 provide a number of fallback settings that can be used to
enable legacy behavior in each of the first three points
PS: http://code.djangoproject.com/ticket/12772
PPS: Please don't shoot me. :>
--
Patryk Zawadzki
I solve problems.
--
You received this m
On Sat, Oct 2, 2010 at 1:40 PM, Russell Keith-Magee
wrote:
> On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki wrote:
>> Classes that represent real objects have state. Like cars have color,
>> make and registration number, your models have attributes that
>> differentiate th
On Sat, Oct 2, 2010 at 1:05 PM, Patryk Zawadzki wrote:
> But until Joey appears to give you money (...)
s/until/before/
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send em
ey appears to give you money, you see another clerk walk
up to the whiteboard, wipe your data and replace it with John Doe. She
then proceeds to exclaim "Joooy" and walks away. That's what a
stateful view is :)
--
Patryk Zawadzki
--
You received this message because you are subscr
your life hard in wonderful ways
(like "why is __new__ called twice?") and intentionally break best
practices. I'd really prefer to teach people not to stab themselves
instead of forcing everyone to wear a shiny set of armor.
--
Patryk Zawadzki
--
You received this message because y
On Mon, Sep 27, 2010 at 5:46 PM, Luke Plant wrote:
> On Mon, 2010-09-27 at 11:36 +0200, Patryk Zawadzki wrote:
>> With the risk of being ignored once again, I dare to link to a working
>> solution that does not need any changed to the framework itself (other
>> than perhaps
risk of being ignored once again, I dare to link to a working
solution that does not need any changed to the framework itself (other
than perhaps including the factory class):
http://gist.github.com/584106
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google G
one model with the same structure and functionality attached.
As for views I recommend something along the lines of:
url(r'^bar/', include('fooapp.urls'), {'model': Bar}),
url(r'^baz/', include('fooapp.urls'), {'model': Baz}),
--
Patryk Zaw
part is the code)
--
Patryk Zawadzki
--
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
djang
re it does not rely on the Referer header :)
--
Patryk Zawadzki
--
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
dj
On Tue, Sep 7, 2010 at 10:04 PM, Luke Plant wrote:
> On Mon, 2010-09-06 at 22:39 +0200, Patryk Zawadzki wrote:
>> Another approach would be not to use a cookie at all. For each {%
>> csrf_token %} use a slightly modified variant of the above
>> encode_cookie functi
On Mon, Sep 6, 2010 at 7:12 PM, Patryk Zawadzki wrote:
> It would be more useful if you could explicitly
> enter_isolation_block() and leave_isolation_block() as needed
> (currently there is no way to commit the isolating transaction other
> than doing a raw SQL query or acces
On Tue, Sep 7, 2010 at 2:57 PM, David De La Harpe Golden
wrote:
> On 06/09/10 14:29, Patryk Zawadzki wrote:
>> The problem only exists when Django sets isolation level to 1, if you
>> use the deprecated "autocommit" setting, you will not be affected.
> Uh. Is this depr
loated in other
> discussions recently. I'll be sure to raise it at the DjangoCon
> sprints this week as a topic for discussion.
After giving it a second thought on my ride to work I think
request.is_valid() would be just as useful and would not require us
breaching the form/request laye
iew.
See above, I see the value of the error in case of a CSRF attack. In
such cases there will be no valid token present in the payload. My
implementation can however differentiate between a missing token, an
invalid one and one that is simply too old to accept it.
--
Patryk Zawadzk
not really
practical :)
--
Patryk Zawadzki
--
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+uns
On Mon, Sep 6, 2010 at 10:39 PM, Patryk Zawadzki wrote:
> ...
First stab at a patch attached. Did not try to run it yet so it might
contain syntax errors.
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" grou
On Mon, Sep 6, 2010 at 9:11 PM, Patryk Zawadzki wrote:
> Consider the following example. It was based on the code I wrote to
> handle the new Facebook API so it might be a bit of an overkill but it
> shows it's possible. A simpler solution would be to return (TTL + ':'
orm(SecureForm):
foo = forms.CharField()
def my_view(request):
myform = MyForm(request.POST or None, request.FILES or None,
secure=request.validated)
if myform.is_valid():
# ...
pass
return direct_to_template(request, 'my.html', {'for
payload = base64.b64decode(encoded_payload)
data = simplejson.loads(payload)
digest = hmac.new(settings.SECRET_KEY, payload, hashlib.sha256).digest()
if str(digest) != sig:
return None
if data.get('TTL', 0) < time.time():
return None
return data.get(&#x
On Mon, Sep 6, 2010 at 4:47 PM, Robert Gravsjö wrote:
> Patryk Zawadzki skrev 2010-09-06 15.29:
>> The isolating transaction keeps going on until you either (1) commit,
>> (2) rollback or (3) disconnect. Django only commits/rollbacks the
>> transactions it explicitly sta
just a matter
of taking the cookies, replacing the CSRF token cookie with "foo" and
I am free to make any request on the site I want for as long as I
want. Requiring me to send a "Referer" header is a mild inconvenience
at most (just send "https://domain.com/";).
Yo
On Mon, Sep 6, 2010 at 5:56 PM, Patryk Zawadzki wrote:
> In fact current implementation is weaker than the old one. You are now
> depending on the client delivering the challenge and the response,
> both being sent over HTTP. An attacker no longer has to steal a valid
> session
On Mon, Sep 6, 2010 at 5:54 PM, Luke Plant wrote:
> On Mon, 2010-09-06 at 16:42 +0200, Patryk Zawadzki wrote:
>> If you use a separate *secure* cookie for CSRF over SSL then it's not
>> possible to submit data from an unsafe page to a safe processor.
>> Secure cookies ar
On Mon, Sep 6, 2010 at 4:42 PM, Patryk Zawadzki wrote:
> On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant wrote:
>> On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote:
>>> As for the vulnerability -- it's only there if you implement it
>>> yourself. If you send
On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant wrote:
> On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote:
>> As for the vulnerability -- it's only there if you implement it
>> yourself. If you send the initial login form over SSL (we do it this
>> way for various
roduce it with a two-line view
that does a simple SELECT with no transaction middleware involved.
The problem only exists when Django sets isolation level to 1, if you
use the deprecated "autocommit" setting, you will not be affected.
¹ http://initd.org/psycopg/docs/extensions.html#iso
t.
> Do you mean you wanted to set up timeouts for idle database connections?
> I guess, nobody asked this before.
No, I think I stated quite clearly what my proposal was.
http://initd.org/psycopg/docs/extensions.html#isolation-level-constants
--
Patryk Zawadzki
--
You received this
or hours.
BTW: This has nothing to do with Django transactions or TransactionMiddleware.
--
Patryk Zawadzki
--
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 u
On Sun, Sep 5, 2010 at 7:49 PM, Patryk Zawadzki wrote:
> If you really want to use POST in HTTP → HTTPS transitions, introduce
> settings.CSRF_WHATEVER, document it thoroughly and make it default to
> False.
Just for clarity -- when the flag is False and current connection is
secure,
plicitly asked to do so.
If you really want to use POST in HTTP → HTTPS transitions, introduce
settings.CSRF_WHATEVER, document it thoroughly and make it default to
False.
Now everyone is happy :)
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Group
sets isolation level in the connection initialization code.
¹ http://code.djangoproject.com/ticket/13870
--
Patryk Zawadzki
--
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...@g
gt; to think that it is a legitimate bug.
While this is worth to cache, you need to index the cache using a
serialized query, not the model.
It is possible to have a different set of choices for each model
instance (for example applying extra filter using another field's
value).
--
Patryk Zawadz
('some-view', ...)
return method(request, *args, **kwargs)
return decorated
@valid
def A(request):
return render_to_response(...)
@valid
def B(request):
return render_to_response(...)
print 'There you go.'
--
Patryk Zawadzki
--
You received this message
example I'm currently working on an ArchiveView with methods:
* index(self, request)
* details(self, request, year, month, day, id)
* day(self, request, year, month, day)
* week(...)
* month(...)
* year(...)
So you only instantiate one object (telling it which templates to use,
what month format you
hat makes this impossible or very unlikely. If the
> one-instance-per-request solution solves this and saves you from
> typing **kwargs all over the place then it absolutely is better, hands
> down.
See above.
--
Patryk Zawadzki
--
You received this message because you are subscribed to t
't want to pass parameters to methods?
Good thing self is passed implicitly or classes would be
totally useless! ;)
More seriously:
Explicit is better than implicit.
Simple is better than complex.
[...]
If the implementation is hard to explain, it's a bad idea.
--
Patryk Zawadzki
--
a view object per request makes no sense. You should have a
> request object per request. It is largely a result of wanting the
> convenience of being able to write sloppy code that writes all kinds
> of state to self rather than a technical necessity.
You, sir, deserve a beer!
--
Patry
On Thu, Jun 17, 2010 at 2:08 PM, Waldemar Kornewald
wrote:
> On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki wrote:
>> Here's an example of a thread-safe view that works happily with just
>> one instance:
>>
>> 8<
>>
>> class MyView(objec
self.qs = queryset
self.template = template
def __call__(self, request, id):
instance = get_object_or_404(self.qs, id=id)
return direct_to_template(request, self.template, {'object': instance})
# ...
url(r'^foo/(?P\d+)/', MyView(queryset
AwesomeAdd()
foo = aa(3, 5)
8<
Doesn't that scream "WTF"? :)
--
Patryk Zawadzki
--
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...@google
ew derive from HttpRequest?
Would you seriously recommend people to extend "int" when they want to
implement multiplication? :)
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
methods are careless enough to pass self to an
external function, it might result in a steady leak of non-freeable
memory).
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dja
If you don't mind, I'll talk a bit more to myself.
On Tue, Jun 15, 2010 at 3:38 PM, Patryk Zawadzki wrote:
> I really don't think we should add anti-moron filters at the framework
> level past documenting "taking care to ensire immutability of view
> instances"
1 - 100 of 148 matches
Mail list logo
