Re: Ideas for a new DEP on long-term Django API compatibility

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

Re: Django LTS support time

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

Re: Django Async DEP

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

Re: Django Async DEP

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

Re: Django Async DEP

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

Re: Django Async DEP

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

Re: Django Async DEP

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

Re: Django Async DEP

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

Re: Django Async DEP

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

Re: BitBounce Spam Replies From the Mailing List

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

Re: Proposal to re-open #27017 (updating only dirty fields in save())

ibe 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 https://groups.google.com/group/django-developers. > To view this

Re: Improving Backward Compatibility

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

Re: Templates: __html__ method support

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 >

Re: Having a MongoDB connector for Django

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

Re: Automatic prefetching in querysets

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

Re: About migrations

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

Re: About migrations

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

Re: About migrations

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.

Re: Missing support for gettext fallback translations

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

Re: Making __repr__ safe by default

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

Re: Some thoughts about improving migration squashing

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

Re: Model translation and meta options

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

Re: Model translation and meta options

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)

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: user_login_failed and user_logged_in signals sent at different levels

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

Re: changing the default MySQL isolation level to READ COMMITTED

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

Re: two-phase commit / distributed transaction

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)

Re: Rethinking migrations

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

Re: Rethinking migrations

I run a mix of 1.9 and 1.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, Nov

Re: Rethinking migrations

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

Re: Rethinking migrations

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

Re: Rethinking migrations

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

Re: RFC: DEP 7 - dependency policy

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

Rethinking migrations

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

Re: Making QuerySets composable

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

Making QuerySets composable

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

Re: Feature proposal: Target API version

2015-11-12 17:40 GMT+01:00 Carl Meyer <c...@oddbird.net>: > 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 earli

Feature proposal: Target API version

, -- 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-developer

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

2015-08-07 16:51 GMT+02:00 Martin Owens <docto...@gmail.com>: > 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 proble

Re: Making management forms for formsets optional

d mean that we'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 messa

Re: Making management forms for formsets optional

as bound forms don't have the 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 "

Re: Making management forms for formsets optional

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

Making management forms for formsets optional

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 solve

Re: Why apps have to have unique names? [related with subapps and name collision]

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

Make sure QuerySet.get() does not fetch more rows than it absolutely needs

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 receiving e

Re: Making __repr__ safe by default

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 this grou

Re: Not calling things twice in templates

else %} > No 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 Goog

Re: Making __repr__ safe by default

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

Making __repr__ safe by default

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, sen

Re: #10863 - Email full stack traces (feedback please!)

orting to any rich formatting (in fact 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, sen

#16572 — looking for directions

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

Re: NoSQL support

a knife. While 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@googl

Re: NoSQL support

them. Of course as much 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&

Re: EmailField max_length of 75 characters should be 256 acccording to RFC 5321

hy it might not 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

Re: Proposal: make 1.4 more explicit

On Fri, Apr 1, 2011 at 12:01 AM, Luke Plant <l.plant...@cantab.net> 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 wher

Re: ./manage.py loaddata calls .save() on all models... should it?

_something_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 e

Proposal: make 1.4 more explicit

rent 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 message bec

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 1:40 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: >> Classes that represent real objects have state. Like cars have color, >> make and registration number,

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 1:05 PM, Patryk Zawadzki <pat...@pld-linux.org> 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

Re: #6735 -- Class based generic views: call for comment

But until Joey 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

Re: #6735 -- Class based generic views: call for comment

e out of __init__. Workarounds are not trivial, can make 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. -- Patr

Re: proposal for lazy foreignkeys

On Mon, Sep 27, 2010 at 5:46 PM, Luke Plant <l.plant...@cantab.net> 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 (

Re: proposal for lazy foreignkeys

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 Groups

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

ate more than 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 Zawadzki -- You received this message because yo

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

but the only interesting 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

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

ke sure 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 em

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On Tue, Sep 7, 2010 at 10:04 PM, Luke Plant <l.plant...@cantab.net> 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 >

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 7:12 PM, Patryk Zawadzki <pat...@pld-linux.org> 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 doi

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Tue, Sep 7, 2010 at 2:57 PM, David De La Harpe Golden <david.delaharpe.gol...@ichec.ie> 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,

Re: CSRF and Forms

that has been floated 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/requ

Re: CSRF and Forms

e 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 Zawadzki -- You received this message because you a

Re: #13870: Correctly handling database isolation (in PostgreSQL)

ction for each select is 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

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On Mon, Sep 6, 2010 at 10:39 PM, Patryk Zawadzki <pat...@pld-linux.org> 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 "Dja

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On Mon, Sep 6, 2010 at 9:11 PM, Patryk Zawadzki <pat...@pld-linux.org> 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

CSRF and Forms

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', {'form': myform}) -- Patryk Zawadzki -- You received this

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

ngs.SECRET_KEY, payload, hashlib.sha256).digest() if str(digest) != sig: return None if data.get('TTL', 0) < time.time(): return None return data.get('token', None) -- Patryk Zawadzki -- You received this message because you are subscribed to the Google Groups

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 4:47 PM, Robert Gravsjö <rob...@blogg.se> 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 >> transa

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

ust 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/;). Your only rep

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On Mon, Sep 6, 2010 at 5:56 PM, Patryk Zawadzki <pat...@pld-linux.org> 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 t

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On Mon, Sep 6, 2010 at 5:54 PM, Luke Plant <l.plant...@cantab.net> 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 process

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On Mon, Sep 6, 2010 at 4:42 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: > On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant <l.plant...@cantab.net> wrote: >> On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote: >>> As for the vulnerability -- it's only there if

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant <l.plant...@cantab.net> 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 th

Re: #13870: Correctly handling database isolation (in PostgreSQL)

" and I can reproduce 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/e

Re: #13870: Correctly handling database isolation (in PostgreSQL)

does not terminate it. > 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 -- Y

Re: #13870: Correctly handling database isolation (in PostgreSQL)

in transaction" for 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..

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

unless explicitly 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 Goog

#13870: Correctly handling database isolation (in PostgreSQL)

onnection 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...@googlegroups.com. To unsubscrib

Re: contrib.admin:list_editable - ForeignKey Performance is O(m*n)?

or IRC, I am starting > 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). -

Re: Suggestion of exception Http301 add as new feature

return redirect('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 mess

Re: Class based generic views in 1.3?

ing it which templates to use, what month format you prefer etc.) and bind its methods to various URLs. -- 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...@goo

Re: Class based generic views in 1.3?

possible 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 the Goog

Re: Class based generic views in 1.3?

you don'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 -- Y

Re: Class based generic views in 1.3?

; Having 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! --

Re: Class based generic views in 1.3?

On Thu, Jun 17, 2010 at 2:08 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: >> Here's an example of a thread-safe view that works happily with just >> one instance: >> >>

Re: Class based generic views in 1.3?

'bar.html'): 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=Foo.objects.all

Re: Class based generic views in 1.3?

someAdd() 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...@googlegroups.com. To unsub

Re: Class based generic views in 1.3?

ethods 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 django

Re: Class based generic views in 1.3?

If you don't mind, I'll talk a bit more to myself. On Tue, Jun 15, 2010 at 3:38 PM, Patryk Zawadzki <pat...@pld-linux.org> 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 > in

Re: Class based generic views in 1.3?

ead-unsafe code without using classes: req = None def greet(self, request): global req req = request # ... return HttpResponse('Hi %s' % req.POST.get('hello', '')) or even: def greet(self, request): greet.foo = request # ... return HttpResponse('Hi %s' % greet.foo.POST.g

Re: Class based generic views in 1.3?

On Fri, Jun 11, 2010 at 7:34 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: > Maybe something simpler? Actually you might want to have a couple of instances with different __init__ params: 8< from threading import local, Thread class View(object): _child = loca

  1   2   >