Re: Multi-DB support within transaction middleware
Before voting for more magic to the transaction middleware, I'd vote to remove it altogether. Explicit is surely better than implicit in this case. The admin already uses commit_on_success, etc. On Oct 18, 1:22 pm, David Winterbottom wrote: > The current implementation of django.middleware.TransactionMiddleware does > not create a transaction for each database, only the default one > defined by DEFAULT_DB_ALIAS > -https://code.djangoproject.com/browser/django/trunk/django/db/utils.py. > Shouldn't the middleware manage a transaction for each database defined in > the DATABASES setting? > > I discovered this while debugging some caching issues with the johnnycache > library, which saves cached querysets when committing. In my case, all > requests to databases other than default were not being cached. > > Happy to supply a patch and tests if this is sensible. > -- > *Dr. David Winterbottom* > Head of Programming > > Tangent Labs > 84-86 Great Portland Street > London W1W 7NR > England, UK -- 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.
Feature proposal: models.CALL_DELETE or effective equivalent
It's quite a common practice to customize a model's delete method. This normally leads to the recommended practice of "just loop through instances and delete each in lieu of using QuerySet.delete". That works well, within limited context. However, when you've got a model that's high up in the food chain (e.g. Tenant) with more than a few foreign keys pointing to it, having to override Tenant.delete to account for each of it's dependents that have custom delete methods leads to tight coupling. Furthermore, pointing foreign keys to out-of- band models like User leads to more bad practices, like monkey patching. My proposal is to add a new on_delete=models.SET-ish feature (or a new kwarg altogether) which would, when specified, cause the parent object's delete to loop through an iterator of the related instances and call the delete method on each for me. I wouldn't think that a transaction would need to be applied in-place, as the docs could merely mention the warning about multiple queries, inferring the need for a transaction (leaving flexibility). table = models.ForeignKey(Restaurant, on_delete=models.CALL_DELETE) or table = models.ForeignKey(Restaurant, bulk_delete=False) I prefer the former to the latter. -- 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 proposal: models.CALL_DELETE or effective equivalent
My "table" typo was intended to be the "restaurant" of a Table model (it's late :) -- 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 proposal: models.CALL_DELETE or effective equivalent
Adrian, My apologies, what I'm meaning is: on deletion of the restaurant, rather than issuing a bulk SQL deletion of the Table instances, call the delete method for each. -- 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 proposal: models.CALL_DELETE or effective equivalent
Did my last post answer the question you had, Adrian? -- 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 proposal: models.CALL_DELETE or effective equivalent
> Or is your main objection having to branch against the specific Simply put, there should be an *optional* way to ensure a model's *explicitly* defined delete behavior is honored without having to write hacks, signals, and/or patches of any kind (ie, make it DRY, and therefore less error-prone). This seems like common sense, so I really don't know how much more I can clarify the topic. -- 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 proposal: models.CALL_DELETE or effective equivalent
On Dec 4, 10:46 pm, Justin Holmes wrote: > "hacks, signals, and/or patches" > > One of these things is not like the other While I agree that signals allow for neat decoupling, they aren't as DRY or quick as a simple field kwarg. Imagine you have 8 models that have custom delete methods. Which is easier: A) avstracting the functionality of each of the 8 delete methods into helper functions and writing signals for all 8, or B) typing on_delete=CALL_DELETE? How will this question be answered, objectively? -- 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 proposal: models.CALL_DELETE or effective equivalent
Hi Carl, Thanks for the reply. My guess is that adding a new, optional Meta argument, (e.g. ``call_delete_on_fk_delete = True``) would be much simpler to implement. I used ``on_delete`` to make it easy to understand what I'm asking for, though if it is possible to achieve this way, I'd be willing to work in that direction. On Dec 5, 8:58 am, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/05/2011 08:31 AM, Yo-Yo Ma wrote: > > > While I agree that signals allow for neat decoupling, they aren't as > > DRY or quick as a simple field kwarg. Imagine you have 8 models that > > have custom delete methods. Which is easier: A) avstracting the > > functionality of each of the 8 delete methods into helper functions > > and writing signals for all 8, or B) typing on_delete=CALL_DELETE? How > > will this question be answered, objectively? > > Clearly the latter. But "what is easier to type" is not, of course, the > only relevant consideration. A couple notes: > > 1. Implementing the proposed on_delete handler would require a major > reworking of how on_delete handlers function. Currently, they allow for > modifying the list of objects to be deleted, but not changing how the > delete actually happens. To make the latter possible, while still doing > things correctly w.r.t. deletion ordering in the presence of FKs, etc, > would be far from a trivial patch. > > 2. The proposal would have abysmal performance characteristics on a > large delete. Thus, it would have to come with big red warnings in the > docs. I'm generally averse to adding features that require big red > warnings in the docs. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAk7c6ioACgkQ8W4rlRKtE2d2mgCgq0bOAHbMj4b9qbAeeeTi9VUx > PFYAoNiYP5+g9r/EbNiy6qj17oKlPmfP > =TblP > -END PGP SIGNATURE- -- 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.
Bug: When editing unique_togethers in a modelformset you can't reverse values
Take the following models:
class Person(models.Model):
name = models.CharField(_('Person'), max_length=255)
class Production(models.Model):
person = models.ForeignKey(Person)
title = models.CharField(_('Title'), max_length=255)
class Meta:
unique_together = (('person', 'title'),)
Create a Person named "Bob", then create a view with an inline model
formset (I used the factory function) for the Production. Then, using
the inline forms in the Production formset, add a couple of Production
objects, one with the title "One", and one with the title "Two". After
you save them, edit the title fields of "One" and "Two" to change the
values to "Two" and "One", respectively. Upon attempting to save,
you'll receive an error message stating, "Production with this Person
and Title already exists."
--
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: Bug: When editing unique_togethers in a modelformset you can't reverse values
Re Russell: Pertaining to autocommit, I wrapped the view (my base view's dispatch method) in commit_on_success. I asked here (as opposed to opening a ticket) because I wasn't certain there was a way to fix this, but it just seemed too wrong to not at least bring to the table. After Karen's reply I'm quite certain that, without the worst kind of hacking imaginable, this is not fixable. Re Karen: Thanks for clearing that up for me. -- 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: Implement automatic graceful degradation (to CSS) and progressive enhancement (to JavaScript) in Django
While graceful degredation is important, it isn't something that a web framework should provide. It is something that you, the web application developer, should provide. Simply code your web pages to function reasonably without JavaScript. Then, use JS to add the bells and whistles. I can't speak for the admin contrib app, just in case that is what you're referring to. -- 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: Python 3 port - notes for people wanting to review changes/port apps
Is this a prank, or is there really going to need to be a u('') for
every u'' (of which there are thousands, since everything is Unicode
in Django) in my Django apps, in order to use P3K? Removing the "u" is
one thing, but adding another text function seems absurd, no?
name = models.CharField(_(u('name'))). # eek :/
--
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.
Could prefetch_related be modified to utilize select_related for ForeignKey relations?
Speaking with regards to the ORM method documented at
https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related
Of course, ``prefetch_related`` uses a Pythonic join to attach reverse-
related objects and avoids the N+1 queries problem, which of course is
great. However, if you use it like this:
>>> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type')
It doesn't seem to take advantage ``select_related`` (assuming that
``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead
sends a separate query for ``Topping`` and ``ToppingType``, joining
them in Python. Is it feasible to modify ``prefetch_related`` use
``select_related`` when it encounters a ``ForeignKey``?
--
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.
auto_now=True fields aren't updated on QuerySet.update()
If you call ``QuerySet.update`` on the following model, you'll get the
results that proceed it:
# models.py
class Person(models.Model):
cool = models.BooleanField(default=False)
updated_on=DateTimeField(auto_now=True)
# django-admin.py shell
>>> from myapp.models import Person
>>>
>>> # Check the updated_on values
>>> Person.objects.values_list('updated_on', flat=True)
[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]
>>> # Fine, just as they are in the fixture. Update ``cool`` field on them
>>> Person.objects.update(cool=True)
2
>>> # Check the updated_on values again
>>> Person.objects.values_list('updated_on', flat=True)
[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]
I understand that ``QuerySet.update`` issues an UPDATE SQL statement,
but Django's code could be modified to include each ``auto_now=True``
field on a model in the UPDATE statement, setting the value to
``datetime.now()`` as it does when you use ``Model.save``.
If this seems reasonable, I'll be happy to write a patch and tests for
it.
Note: I'm using the latest trunk code (1.4 beta), pulled yesterday
--
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: auto_now=True fields aren't updated on QuerySet.update()
On a related note, the new timezone.now() functionality is used for ``DateTimeField.pre_save`` when ``auto_now=True``, but it isn't used for ``DateField.pre_save`` or ``TimeField.pre_save``. Is this a bug I should report, or is there something I'm missing (I'm pretty uninformed when it comes to UTC and timezone related stuff in Python)? -- 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-posting of previous thread: ``QuerySet.update`` not updating ``auto_now=True`` fields
It seems my previous question was co-opted... by myself, so rather
than try to distract the conversation about TZ stuff (which seems to
be pretty important stuff, esp with the 1.4 launch), I figured I'd
start a new thread with my original question. Here it is:
If you call ``QuerySet.update`` on the following model, you'll get the
results that proceed it:
# models.py
class Person(models.Model):
cool = models.BooleanField(default=False)
updated_on=DateTimeField(auto_now=True)
# django-admin.py shell
>>> from myapp.models import Person
>>> # Check the updated_on values
>>> Person.objects.values_list('updated_on', flat=True)
[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]
>>> # Fine, just as they are in the fixture. Update ``cool`` field on them
>>> Person.objects.update(cool=True)
2
>>> # Check the updated_on values again
>>> Person.objects.values_list('updated_on', flat=True)
[datetime.datetime(2012, 1, 1, 0, 0), datetime.datetime(2012, 1, 1, 0,
0)]
I understand that ``QuerySet.update`` issues an UPDATE SQL statement,
but Django's code could be modified to include each ``auto_now=True``
field on a model in the UPDATE statement, setting the value to
``datetime.now()`` as it does when you use ``Model.save``.
If this seems reasonable, I'll be happy to write a patch and tests for
it.
Note: I'm using the latest trunk code (1.4 beta), pulled yesterday
--
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: auto_now=True fields aren't updated on QuerySet.update()
I haven't quite read up on all the UTC-related stuff in Django as of yet (couldn't find much info about it), but I found some of the posts above concerning. It would seem that if a DateTimeField should be updated with ``timezone.now()``, then a DateField should be updated with ``timezone.now().today()``, and TimeField should be updated with ``timezone.now().time()``, no? If I'm in EST time, and the server is in MST, and it's 11:00PM on the server, my records should be updated as the following day, since it's 1:00AM EST. Is this naive to assume (if not, apologies for my lack of know-how regarding TZ issues)? -- 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: auto_now=True fields aren't updated on QuerySet.update()
I actually know so little that I was even more confused by my own question, but I appreciate your reply, Danny. I feel pretty challenged when I try to understand timezone-related stuff. Is this correct: When using UTC, which, if any, are true: A) If I have a view that simply adds a record of a model with a datetime field, and 3 users in different timezones load the view at the same time, all 3 records will have the same datetime value (assuming, of course, the database was able to write all 3 records within the same microsecond) B) UTC is *the* way to go for almost any application which will have a timezone = models.CharField(... setting for each user profile C) When each user has a timezone setting, it doesn't affect the datetime that's entered into the database, it just gives me the ability to display the time to them in their timezone -- 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: auto_now=True fields aren't updated on QuerySet.update()
Thanks, Danny. That's really helpful to me, and I appreciate you taking the time to explain it. -- 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.
django-admin.py startproject creating duplicate settings.py files
I have trunk installed from last night, and this is actual terminal output (except for the stuff omitted on the left of the $): (my_venv) myusername$ django-admin.py startproject foobarz (my_venv) myusername$ ls foobarz/ __init__.py foobarz manage.py settings.py urls.py (my_venv) myusername$ ls foobarz/foobarz/ __init__.py settings.py urls.py wsgi.py I opened both settings.py files, and they are indeed identical files. Is this intentional? I was interested in the new manage.py format, so I thought I'd adjust my app to use it and whatever other new layout features, but clearly this isn't correct. -- 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: django-admin.py startproject creating duplicate settings.py files
Hey Carl, Thanks for the reply. I removed everything from my venv's site- packages directory (except PIL and some other graph library), then checked to make sure I wasn't able to use django-admin.py or my app's manage.py scripts (ie, making sure there wasn't a global Django install). I then reinstalled Django after pulling the latest master from the github mirror, moved to ~/dev and then: (actual copy/paste from my shell, minus find/replace of my personal/info): (myvenv)My-Names-MacBook-Pro:dev myusername$ mkdir test_startproject (myvenv)My-Names-MacBook-Pro:dev myusername$ cd test_startproject/ (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls -a . .. (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ django- admin.py startproject testing123 (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls testing123 (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls testing123/ __init__.py manage.py settings.py testing123 urls.py (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls testing123/testing123/ __init__.py settings.py urls.py wsgi.py (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ I'm not pulling your chain. I've never had this happen before, and Django functions just fine otherwise (except for now issuing a warning about using naive datetimes in Field.__init__, which is ironically right up the alley of my other thread) Note: In site-packages for the venv, I show Django-1.4b1-py2.7.egg- info On Feb 20, 8:56 pm, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/20/2012 08:31 PM, Yo-Yo Ma wrote: > > > I have trunk installed from last night, and this is actual terminal > > output (except for the stuff omitted on the left of the $): > > > (my_venv) myusername$ django-admin.py startproject foobarz > > (my_venv) myusername$ ls foobarz/ > > __init__.py foobarz manage.py settings.py urls.py > > (my_venv) myusername$ ls foobarz/foobarz/ > > __init__.py settings.py urls.py wsgi.py > > > I opened both settings.py files, and they are indeed identical files. > > Is this intentional? I was interested in the new manage.py format, so > > I thought I'd adjust my app to use it and whatever other new layout > > features, but clearly this isn't correct. > > Nope, it's not correct, and I can't reproduce it either. I get just a > "manage.py" in the outer directory, and settings/urls/wsgi in the > package. My guess is that you already had an old-style startproject in > that "foobarz" directory or something. Try it again, and make sure the > target directory doesn't exist. Also try cleaning your Django repo of > untracked files; it's possible you somehow got extra files in the > conf/project_template directory that don't belong there? > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9DFf4ACgkQ8W4rlRKtE2cY7QCgvT5GMOuWLAgjl6QI3R/cBd6P > Py8AoIQaqmi11fOfx67mz+kzl8bi95iv > =zEND > -END PGP SIGNATURE- -- 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: django-admin.py startproject creating duplicate settings.py files
Thanks, Carl. To fix this issue, I had to delete my local git clone of the django repo, and then clone the github mirror again before reinstalling. I thought it was due to the /build in the repo, but for some reason a ``reset --hard`` didn't even fix it, so I'm not sure how a rm -r then re-cloning did the job, but it did. -- 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: Revisiting multiline tags
I'm -1 on this for s specific reason; If you need multiple lines for a tag, you're doing it wrong. >>> import this -- 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: Revisiting multiline tags
After Ned's message, I'm -0, because while I'm not fond of multi-line tags, I cannot offer a good alternative when it comes to multi-line "with" tags. On Feb 25, 6:48 pm, Ned Batchelder wrote: > On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:> I'm -1 on this for s specific reason; > If you need multiple lines for a > > tag, you're doing it wrong. > > >>>> import this > > This would be far more helpful feedback if you would take the examples > of too-long tags presented in this thread, and show the "right" way to > do it. > > --Ned. -- 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.
USE_TZ related warnings caused by fixture loading
django/db/models/fields/__init__.py:808: RuntimeWarning: DateTimeField received a naive datetime (2012-01-01 00:00:00) while time zone support is active. The above warning is caused by a JSON fixture having "2012-01-01 00:00:00" for a DateTimeField timestamp. Does this mean that fixture loading needs to be modified to account for the new timezone code, or was is this just a side effect of keeping fixture loading backward-compatible? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/oGCVFF3Gn68J. 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: gsoc proposal, dynamic list form field
On Mar 25, 2:41 am, Roy McElmurry IV wrote: > Okay, I have created a Google Doc of my proposal. I have greatly > elaborated on the idea. I have enabled commenting for anyone with the > link. Please take a look and let me know either in this forum or in > the Google Doc if there is anything I can add or change to make this a > more appealing proposal. > > https://docs.google.com/document/d/1zzqcW-OGHGydmJ-S-OLRVTiAMZMvdrRcG... I think the idea you're proposing is predicated on a simple misunderstanding. What your suggesting be encompassed in a ManyToManyField-like model field is already achievable, in effect, by second model with a foreign key to the first, and then by using inlinemodel_formset. The misunderstanding, I think, is the idea that you could create records with a simpler step. A custom form field could be created which excepts space delimited ingredients and saves them as separate ingredients, much like how Tag fields typically work. -- 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.
timezone.override() doesn't play well with template response views, by default
Regarding
https://docs.djangoproject.com/en/dev/ref/utils/#django.utils.timezone.override
# views.py
class TZView(DetailView):
def dispatch(self, request, *args, **kwargs):
with timezone.override(est_tz): # Assuming your default
timezone is US/Pacific
return super(TZView, self).dispatch(request, *args,
**kwargs)
Using the above view with a template which renders datetimes with
{{ foo_timestamp|localtime }} you'll notice that EST isn't reflected
in the values output by the localtime filter. This is because the
context manager returns control after dispatch is called, but the lazy
response isn't rendered to a string until later on (this can be seen
in https://gist.github.com/6259f4e3365dcdfb93e5 from django/core/
handlers/base.py).
I'm not suggesting a solution, just pointing out the problem. If there
are any suggestions as to how to fix this problem without ruining the
request handler, I'd be happy to help implement one.
--
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.
Proposal: Signal connection via "my_app.MyModel"
I'd like to suggest adding the ability to connect signals with models by app label and model name. Example API: post_save.connect( my_signal_handler, sender='my_app.MyModel' ) This would allow for better decoupling of code, as well as a far cleaner dependency graph. I'm not certain how this would affect custom signals. I'm primarily speaking of the provided signals in ``db.models.signals``, but this might be something that applies to custom signals as well. -- 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: Proposal: Signal connection via "my_app.MyModel"
I'd be willing to implement this, with some guidance. -- 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: Proposal: Signal connection via "my_app.MyModel"
It would not be a "hard link". Do you know the definition of "dependency graph", and do you know anything about Django's internals or about how Django already allows you to connect models' foreign keys this way? It would be simply "get me the model 'MyModel' from the app 'my_app'". The app could easily be moved around, and no extra imports would be used in the process (see models.get_models()). This gives you the ability to move the app around easily. The real benefit in my oppinion would be the ability to connect signals for models from app A inside of app B without having to worry about import order or errors, due to some crisscross in app A's dependency graph. On May 12, 4:24 am, Dougal Matthews wrote: > On 9 May 2012 22:14, Yo-Yo Ma wrote: > > > This would allow for better decoupling of code, as well as a far > > cleaner dependency graph. > > The dependancy will still be there, the string containing the dotted path > would be a hard link. However, this will be hidden and a less obvious > dependancy than a normal Python import. > > So, I'd be -1 as I don't see the advantage of this and rather it just adds > further complexity. -- 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.
Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``
A request to: http://www.example.com:8080//foo-bar-baz.html leads to request.build_absolute_uri() returning: http://foo-bar.html -- 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: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``
I've just created https://code.djangoproject.com/ticket/18314 and intend to take a look a better into the implementation of ``build_absolute_uri()`` tonight. On May 13, 10:02 pm, Russell Keith-Magee wrote: > Thanks for the report -- but is there a particular reason that you're > reporting this here, rather than on the ticket tracker? > > Yours, > Russ Magee %-) > > > > > > > > On Mon, May 14, 2012 at 9:55 AM, Yo-Yo Ma wrote: > > A request to: > > > http://www.example.com:8080//foo-bar-baz.html > > > leads to request.build_absolute_uri() returning: > > > http://foo-bar.html > > > -- > > 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 > > athttp://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: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``
I've attached a diff in the ticket I created, and I resolved the ticket as "fixed" (as habit, I'm used to doing this for work, allowing QA to change the status to "closed" after testing). Is this correct? Also, is it better to fork Django and make a pull request on GitHub, or simply provide the git diff as I did (the docs on contributing don't really make mention of any new GitHub-related polices)? On May 13, 10:02 pm, Russell Keith-Magee wrote: > Thanks for the report -- but is there a particular reason that you're > reporting this here, rather than on the ticket tracker? > > Yours, > Russ Magee %-) > > > > > > > > On Mon, May 14, 2012 at 9:55 AM, Yo-Yo Ma wrote: > > A request to: > > > http://www.example.com:8080//foo-bar-baz.html > > > leads to request.build_absolute_uri() returning: > > > http://foo-bar.html > > > -- > > 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 > > athttp://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: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``
Thanks Aymeric, I've reopened the ticket. I skipped the triage page, thinking it would be about the rules for prioritizing bugs. On May 15, 3:44 pm, Aymeric Augustin wrote: > Hello, > > On 15 mai 2012, at 21:36, Yo-Yo Ma wrote: > > > I've attached a diff in the ticket I created, and I resolved the > > ticket as "fixed" (as habit, I'm used to doing this for work, allowing > > QA to change the status to "closed" after testing). Is this correct? > > We resolve tickets as "fixed" only once a patch is committed. > > Seehttps://docs.djangoproject.com/en/dev/internals/contributing/triaging... > > > Also, is it better to fork Django and make a pull request on GitHub, > > or simply provide the git diff as I did > > As you wish! > > Best regards, > > -- > Aymeric. -- 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.
Proposal: Add some extensibility / decoupling features to Django templates
I'll start with an example: Using Jinja2, I can create an environment which is pretty secure (no access to anything but built-ins and objects explicitly marked "safe"), and provide a loader who's templates are loaded from the database (e.g., ``request.client.template_set.all()``), and customize all this for a single request (Since I can simply instantiate an ``Environment`` per request with a custom ``Loader`` which has access to only the ``request.client`` templates). I can also customize the extensions on a per-request basis (that's sort of analogous to customizing template tag/filter built-ins), in order to limit or add to the type of tools that clients have access to. Using Django templates, I'm left with simply running my clients' sites portion of the app under a different settings file. This *almost* cuts it too (since I can use a different URL conf which includes different template.add_to_builtins() calls, etc.), but it doesn't give me all the things that I need, like the ability to instantiate the loader with a queryset of templates for the ``request.client``, etc. "Why don't you just use Jinja2 then?" The Django core team is a pretty intelligent team, and the philosophy behind the style of tags / filters / lack of logic in Django templates is far superior to Jinja2. I simply want a more Jinja2-ish Python API for using Django templates. My Proposal (abstract explanation, btw, I'd be happy to help architect / write code): Without changing any of the existing functionality or settings in Django, refactor the template system to use an ``Environment`` class (something akin to Jinja2's ``Environment``) which takes a list of loaders, and a number of other arguments. Then, instantiate this class, using the provided settings, and use it for all the default functionality (the admin, render_to_response, CBV template access, etc.). This would allow developers to make their own ``Environment`` instance with different arguments, request-specific or otherwise, and without having to do a lot of evil things. Thanks Fellow Djangonaut -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/h9ExRYxoxHUJ. 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.
Docs mistake
At: https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField.upload_to The docs make mention of the "url" attribute being MEDIA_ROOT + upload_to. I think whoever wrote it meant that the aforementioned is how the file name/path is determined, and that also MEDIA_URL + upload_to is used to make the "url" attribute. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/yWuBLG3QTY8J. 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: Proposal: Signal connection via "my_app.MyModel"
Is there anyone else out there who doesn't like having to import models from app X into app Y just so that app Y can connect post save signals to them? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/_vcka4fdtPUJ. 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.
iPython behaves strangely only with Django shell
The following gist demonstrates a strange phenomenon, which occurs when I use ``python manage.py shell``, but not when I use ``ipython`` alone. https://gist.github.com/f8c2fd97647de90d915a I'm not certain whether this is a known issue, or whether it's even a Django bug, but certainly nothing of the sort occurs in iPython when used alone. This occurs with ANY name. I first noticed it when I tried to create a form, and there was a name error on ``forms`` on the line of my first field declaration. IPython 0.12.1 Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/0IjXTJb6WFYJ. 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: Models.py not loaded at server startup ?????
Another good reason for model loading at startup is a good idea; without it, models.get_models becomes a lie. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/bDjcdKrvk9MJ. 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.
``models.BooleanField`` fields default to ``False`` when missing from fixtures
This may be the intended behavior, but I couldn't find docs on it. My recommendation would defer to "The Zen of Python" In the face of ambiguity, refuse the temptation to guess. I would rather see the typical IntegrityError: Problem installing fixture... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/d2qyWIByy-kJ. 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: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
Yep, that looks like it. IMHO, this is a bug that should be fixed without delay, as it breaks a cardinal rule for Pythonistas, and could even lead to a "data corruption" situation, if a dev was to add a boolean field and forget to update a form or fixture, or both. On Monday, September 24, 2012 5:44:29 AM UTC-4, Aymeric Augustin wrote: > > 2012/9/24 Yo-Yo Ma > > >> This may be the intended behavior, but I couldn't find docs on it. My >> recommendation would defer to "The Zen of Python" >> >> In the face of ambiguity, refuse the temptation to guess. >> >> I would rather see the typical IntegrityError: Problem installing >> fixture... > > > Hello, > > This looks a lot like: https://code.djangoproject.com/ticket/15124 > > I hope I'll have time to study this problem again before the feature > freeze of 1.5. > > -- > Aymeric. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/6i5BdRrk8y0J. 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: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
Developer of a pet shop software adds: feed_before_midnight = models.BooleanField() because they're planning on carrying baby gremlins... forgets to update the zoological XML feed importer to use the "feed_before_midnight" value, and the rest is history :) On Monday, September 24, 2012 9:21:34 AM UTC-4, Florian Apolloner wrote: > > ... > I don't see how that could corrupt stuff in the current situation > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/1bdXw5KfYRwJ. 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: ``models.BooleanField`` fields default to ``False`` when missing from fixtures
The gremlin example was just a light-hearted attempt at justifying the claim of "data corruption", in response to Florian, but I really only brought up this issue because it surprised me (nothing in the docs). I would suggest a docs update to let developers know that if a default isn't set, ``False`` is implied - only because this seems like the sort of mini-"bug" that might never warrant fixing due to the ramifications. On Monday, September 24, 2012 9:18:34 PM UTC-4, Russell Keith-Magee wrote: > > On Tue, Sep 25, 2012 at 8:00 AM, Yo-Yo Ma > > wrote: > > Developer of a pet shop software adds: > > > > feed_before_midnight = models.BooleanField() > > > > because they're planning on carrying baby gremlins... forgets to update > the > > zoological XML feed importer to use the "feed_before_midnight" value, > and > > the rest is history :) > > We need to be clear on what we (as in, the Django project) classify as > "catastrophic data loss". > > Examples of Catastrophic data loss: > * You request a save of object X, and object X is not saved. > * You save object X, and object Y is modified. > * You save object X, and object Z is deleted. > > NOT examples of Catastrophic data loss: > * You forget to set a value on an object, and the default isn't what > you expected. > * You set a value on an object, which is saved verbatim, but wasn't > the correct value under the circumstances. > > In the example you provide, I agree that there would be catastrophic > consequences. However, the code is doing exactly what it's instructed > to do. While I may concede that this is a bug, it's a bug caused by > ambiguous default behaviour, not behaviour that is fundamentally > incorrect or destructive -- it's essentially nothing more than "0 is a > default value". You can argue that 0 isn't an appropriate default in > this circumstance, but you can't argue that it is (a) a particularly > surprising default, or (b) that the developer was given an opportunity > (multiple opportunities, really) to set an appropriate default. > > If this conflicts with what you consider to be catastrophic, thats > fine -- I'm just letting you know the benchmark that we, as a project, > use to guide our decision making process. > > Yours, > Russ Magee %-) > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/YO9PTOVrakUJ. 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.
Optimization request - give ``request.session`` lazy read
With ``contrib.sessions`` installed and ``SessionMiddleware`` in use, I noticed that when Django session cookie is set the ``django_session`` table is queried on every request, regardless of whether any session data is used during the request cycle. Making the ``session`` attribute of request a lazy object would represent an optimization in the following 2 cases, both of which are the same, in effect: 1) User logs in to perform login-required tasks, then visits pages that don't require login 2) User logs in to perform login-required tasks, logs out, then visits pages that don't require login Would this sort of change be backward-incompatible? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/uXBhKovPew4J. 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: URL dispatcher slow?
Why does every conversation about Django's performance met with "GTFO we don't care"? (that was a rhetorical question :). I'd venture to guess that most "It's fast enough for me!" responses are predicated on experiences that can be likened to personal blog development, rather than large scale, 10+ server deployments (e.g., Disqus, et al). If you had great abs, nice pecs, ripped legs, a nice deltoids, and 4" circumference biceps, you'd *probably* start to care when people said, "hey, what about those biceps...", no? Are CPUs, RAM, and electricity free? (that too was a rhetorical question :) Django is an *epic* (not in the literal sense :) framework, which offers a tremendous amount of functionality with nary an inkling of logical restraint. You can accomplish basically anything with Django without running into arbitrary limitations (e.g., have a gander at the limitations in most frameworks' URL dispatchers, just as a relevant example). To shorten this, from a features / ease of use standpoint, Django is just plain awesome. BUT... Django is NOT that fast. 1) Django templates are unbearably slow (doesn't matter for a blog or something simple, but try something with lots of inline model formsets in a page and quite a few includes, and before you know it, you're wasting a decent percentage of your CPU on templates). 2) URL dispatching 3) Middleware is applied liberally (vs the a la carté, more efficient decorator approach to AOS) The list goes on. What is the harm in discussing the weak points of Django? Performance is probably the only major weak point in Django right now (aside from the lack of schema migration in core, which is coming soon anyway). I have no solution or patches in my pocket, but I can say with absolute certainty that performance will never, ever get better when discourse is in a monologue format. That's all. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/uZ9r1EtZnj4J. 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: URL dispatcher slow?
I only now realized that this thread had started in a bit of a trolling fashion, and that there was a similar thread this week. That helps to explain the slightly more defensive stance. Django can survive (and thrive) just fine in its current, reasonably performant state, but performance should have a priority, rather than being in a sort of "its fine as-is" stasis. Benchmarks like the ones posted aren't that helpful, but it doesn't change the fact that there tends to be an anti-performance sentiment in this group. When you look at the latest Python 3.3.x release, you see that there are many performance improvements that are clearly not due to incidental changes. I'm merely suggesting that an initiative to better the performance of Django, perhaps by benchmarking to find some of the weakest points, determining the lowest hanging fruit, and creating tickets in trac for them. I would love to help optimize any given part of Django and submit a patch, but not if I'm afraid that it will never be applied and/or the ticket will be marked as "works for me", etc. Help give us who care about performance the most a real chance to make some improvements. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/bxfyOKgoRogJ. 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: save() method could return the object
+1 A lot of people are overriding ``save`` and not returning anything, but this isn't going to hurt them (ideally, they should already be returning the result of ``super(``, but nobody does). On Friday, October 12, 2012 9:25:46 AM UTC-4, Chris Wilson wrote: > > Hi all, > > If the save() method returned the object itself, then we could chain it > like this: > > old_status = Status(last_contact=None).save() > > Instead of having to do this: > > old_status = Status(last_contact=None) > old_status.save() > > It's a trivial one-line change to the Model class and I don't think it > would break backwards compatibility, as I doubt that anyone is relying on > the save() method returning None. Should I submit a patch? > > Cheers, Chris. > -- > Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 > Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK > > Aptivate is a not-for-profit company registered in England and Wales > with company number 04980791. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/WkAiV5BsEiEJ. 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.
Proposal - ``Model.reset_state``
Problem:
a = A.objects.get(...)
form = AModelForm(data={...}, instance=a)
if form.is_valid():
a = form.save()
else:
a.calculate_foo_field()
a.last_attempt = datetime.now()
a.save() # Oops, now the instance has the bad data provided to the form
Workarounds:
# Get a fresh copy of ``a``
a = A.objects.get(pk=a.pk)
# Wasted query
# Also, this won't work in the context of a ``select_for_update`` on
the original instance
# Use ``update`` instead
A.objects.filter(pk=a.pk).update(last_attempt=datetime.now(), ...)
# What about ``calculate_foo_field``?
# Also has the ``select_for_update`` problem
Solution:
a.reset_state() # Resets the instance's field state to the point of
creation (using data stored in a ``_state_reset_cache`` dict)
a.reset_foo() # etc.
a.latest_attempt = datetime.now()
a.save()
Problem: Uses more memory per instance
Solution: Add ``QuerySet.cache_for_reset()`` allowing opt-in usage of the
feature, treating ``reset_state`` as noop when instance doesn't have the
state reset cache.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/kjHIIO5YZJQJ.
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.
Complicated, strange bug in ``prefetch_related`` when used in the context of a test client
I'm still working on forming some sort of understanding of what exactly
causes this and/or what is even going on, so any help is much appreciated.
The resultant attached "bars" in the following example:
queryset = Foo.objects.all()
queryset = queryset.prefetch_related('bars__baz')
obj = queryset.get(pk=1)
are different from the results of:
obj = Foo.objects.all().prefetch_related('bars__baz').get(pk=1)
And, the results attached in the second example are inconsistent as well.
In order to reproduce this, you need to first query for the "Foo", then add
some "bars" to the DB, then perform the above examples.
This only seems to occur, at least measurably, during tests when using
``self.client.get(...``, where the view that is being requested performs
the queries.
I'm using ``TransactionTestCase``, sqlite3, and Django latest master,
pulled about an hour ago, and I've also tried the new live server test case
with the same results.
Note: If I modify django.db.models.query # 590 to the following, the bug
doesn't occur (not to suggest that the following is a solution, but it
might help to debug):
prefetch_related_objects([], self._prefetch_related_lookups)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/qpkxQFmjlvoJ.
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: Complicated, strange bug in ``prefetch_related`` when used in the context of a test client
Hi Anss, thanks for the reply.
The queries are identical.
That's the exact reason I posted. Those two examples should essentially be
the same, save for some sort of operator overloading.
My note at the bottom about providing an empty list instead of the related
cache when calling ``prefetch_related_objects`` implies that something
weird is going on with the related cache, and the fact that it only happens
when using the test client (at least, thus far) makes me think that it
could possibly even be related to some sort of ``threading.local``, or
something to that effect.
The models are simple (named according to the example in the original post):
class Foo(models.Model):
title = models.CharField(max_length=255)
class Baz(models.Model):
name = models.CharField(max_length=255)
class Bar(models.Model):
foo = models.ForeignKey('Foo')
baz = models.ForeignKey('Baz')
quantity = models.IntegerField()
My wild guesses:
> - some sort of state leak in testing
> - non-deterministic bug in prefetch_related (likely caused by random
> ordering of the rows in the resultset)
>
> I hope you can provide us more data about this situation,
> - Anssi
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/SirWYaLJLs4J.
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: Github tags
+1 On Monday, October 29, 2012 5:18:48 AM UTC-4, Jan Bednařík wrote: > > There is also related ticket https://code.djangoproject.com/ticket/19141 > > Jan > > > On Mon, Oct 29, 2012 at 3:36 AM, Matt Austin > > > wrote: > > Hi, > > > > Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 > > alpha tagged on the github repository? The tagging seems to have > > fallen behind with these releases. > > > > Thanks, > > > > -- > > Matt > > > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > > To post to this group, send email to > > django-d...@googlegroups.com. > > > To unsubscribe from this group, send email to > django-develop...@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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/qWKMQb_tsmAJ. 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.
Django 2.0 - a case for a customizable pony
This morning read the SQLAlchemy proposal made by Luke Plant in June. I then decided that this would be a good time to rant about abstraction, extensibility, and decoupling. Background For years, Django has been forced to deal with most implementation issues from within, including the ORM, templates, etc. Even things like JSON support and basic timezones (for the new timezone module) were or are built right into the framework, in order to handle heterogeneous environments and Python versions, and to minimize external dependencies. This strategy contributed to the success of Django, in part because finding nice, well supported libraries was tough, and installing dependencies was too. The Python community has grown and its processes have matured nicely. Nowadays, for a given problem, there are typically multiple solutions, many listed on services like www.djangopackages.com. Installing packages is easy, thanks to things like pip, and pypi. Collaboration is simpler, thanks to services like GitHub. This trend can be summarized as abstraction, which is a good thing. Handling things at a proper abstraction level is always a time and heartache saver, and is of course the reason for using a framework like Django in the first place. The Problem - Solving too many problems from the top down, and coupling things too tightly in a project leads to code rot, because implementations all have to be written by somebody who is intimate with many other parts of the framework, then they have to be vetted others who are intimate with many parts of the framework, and then the code has to be maintained. Coupling becomes an inevitability, simply because it is possible. Backwards compatibility becomes more and more difficult and costly to maintain, and prohibits growth. Projects built atop the framework eventually run into problems for which the solution is to make changes to implementation details (usually via subclassing, but in some cases, via monkey patches), which leads to code debt in a project, and subsequent contention in the community when implementation details are changed in a way that breaks backwards compatibility for those "power users". This means that the issue of "We can't do that because it'll break things" isn't really the problem that Django has. It's a symptom of another problem, which is that Django is not nearly extensible enough (it's parts are not pluggable enough, and or are not well enough abstracted to be quickly changed and/or moved). So, what? - So, Django has evolved toward being a more decoupled, less monolithic framework over the past couple years (e.g., the removal of auth's coupling to things like messages, customizable user models, etc.), but there is a lot left to be desired. I consider a Python web framework to be a minimum of A) request handling, B) URL routing to something callable (a view), and C) response handling. However, certain other things are good ideas to bake in, such as cookie handling, security related features (CSRF, click jacking, etc.), and probably a few others. Anything else should be completely pluggable, and completely decoupled from everything else. Some examples which make me smile: Sessions - Cache - includes support for plugging in a back-end and only defines a simple interface (cache.set, cache.get, etc.) Mail - includes support for writing / plugging the back-end of your choice, only defines a simple interface (send_mail, send_mass_mail, etc.) Some examples which make me sad: Templates - unpluggable (importing a third party template library and using it in your view is not plugging it in, since this isn't compatible with 3rd party or contrib apps) ORM - I'll defer to the complexities that arose from Luke's proposal Admin - lacks abstraction, and therefore has some great tools that can't really be used elsewhere (e.g., filter specs, sorting, etc.), lacks usage of CBV, in favor of an ad hoc solution The Solution - >From an interface perspective, I have some ideas about how to handle the templates side of things, and some pretty vague ideas of how to handle the ORM, but I personally think that the real solution is to work not on implementing new ideas and solutions to use beside or in place of existing ones, but rather to fix the underlying problem that Django has. We can fight an uphill battle constantly by trying to usher new ideas in over our 12 foot wall, believing that it is indestructible, or we can work together to "Tear down this wall!" :) Remember, we're at 1.5 now. If we have a specific goal in mind that is very drastically different now, we can do a lot before 2.0 without breaking backwards compatibility (at least not too badly). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg
[ANNOUNCE] Security releases (Django 1.3.5, Django 1.4.3, Django 1.5 beta 2)
There aren't yet Git tags for the releases. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/ipPpizg3flcJ. 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: [ANNOUNCE] Security releases (Django 1.3.5, Django 1.4.3, Django 1.5 beta 2)
Tom, Create a view that accepts a "uri" argument and returns a 302 to the provided URI. Then, update your redirect_to callable to urlencode the URI and send them to /your/redirect/view/?uri=[encoded URI] and problem solved. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/rVxzz8Z5ubsJ. 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: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
-1 FWIW Computing the root of your project with os.path works just fine and doesn't require another setting... which, btw, could have no sane default. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/ZTjEZkT1TLQJ. 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: Github tags
Sorry to be a pest, but will you guys end up adding a Git tag for RC-1? On Sunday, October 28, 2012 10:38:00 PM UTC-4, Matt Austin wrote: > > Hi, > > Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 > alpha tagged on the github repository? The tagging seems to have > fallen behind with these releases. > > Thanks, > > -- > Matt > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/k5kOIGBuO_AJ. 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: Form.set_data method
With all respect, this seems like a bad idea; there would be little, if any, gain from having this method. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Ticket #17093 -- quarantine global state in django.template
For anyone developing a SaaS that allows users to create templates through the UI (e.g., a hosted CMS), separately initializable template system is paramount, giving the ability to modify multiple settingsin the template system that are in effect during template rendering, including loaders, template builtins, etc. This way, an application's primary UI can use one set of settings, and the settings for users' templates. Note: by "settings", I don't necessarily mean settings.py, just template settings, even of that means instantiating a template system on the fly. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Form validation - char field coerces *any* data into a unicode
A form that has a char field (e.g. "name") when provided a dict of data
will convert the value of "name" to a Unicode, no matter what. I understand
that this is desirable in some circumstances, but it can lead to things
like:
>>> product.name
u"{'haha': 'I am a dict'}"
Perhaps this is desirable, but I wonder if there is any merit to the idea
of sanitizing data to ensure it is "valid" for a char field, since
practically *any* Python object can be cast into a Unicode (vs a
DecimalField or an IntegerField, which will raise an error).
I realize the distinction of a "valid" would be completely arbitrary (e.g.,
who's to say that a dict isn't a valid char field value, but an that
integer is?), but nonetheless, here I am, requesting feedback.
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Form validation - char field coerces *any* data into a unicode
I should note, the use case for this is when the data is being provided to
the form through a mechanism other than normal HTTP form-encoded via
request.POST, such as an API that consumes JSON.
>>> product.name
> u"{'haha': 'I am a dict'}"
>
>
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Policy for stable/1.x.x branches
The commit https://github.com/django/django/commit/2f121dfe635b3f497fe1fe03bc8eb97cdf5083b3 fixed a problem where a custom regex validator's customized message was ignored, in favor of the one set on the class (you just see "Please enter a valid value"). If I pip install the latest master, the problem is of course fixed. If I pip install stable/1.5.x, the problem persists. I searched the docs for info about using the stable/1.x.x branches, but couldn't find anything, so I wanted to ask: 1) Is doing so considered safe (e.g., for production usage), since they're "stable"? 2) What is the policy or lag time for getting commits such as the aforementioned bug-fix into these stable branches? 3) Are there docs for this, and if not, should there be an entry on https://docs.djangoproject.com/en/dev/faq/install/? -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Policy for stable/1.x.x branches
@Jacob - thank you much. That was the exact docs page I didn't think existed. @Ramiro - I meant using stable/1.5.x in production. BTW, Jacob, the first of 2 docs links you provided mentioned providing bug fixes for the most recent release, and follows up with essentially, "they're at stable/A.B.x". Will bugs like that one I mentioned in the OP actually be eventually fixed in 1.5.1, instead? I'm just trying to decide what the best thing (tag, commit, branch tip, etc.) to install to make sure I get those sorts of updates in my production server. It could be just that I install the tip of master and test it out before updating, but that's not ideal of course. On Thursday, March 28, 2013 12:34:56 PM UTC-4, Yo-Yo Ma wrote: > > The commit > https://github.com/django/django/commit/2f121dfe635b3f497fe1fe03bc8eb97cdf5083b3fixed > a problem where a custom regex validator's customized message was > ignored, in favor of the one set on the class (you just see "Please enter a > valid value"). > > If I pip install the latest master, the problem is of course fixed. If I > pip install stable/1.5.x, the problem persists. > > I searched the docs for info about using the stable/1.x.x branches, but > couldn't find anything, so I wanted to ask: > > 1) Is doing so considered safe (e.g., for production usage), since they're > "stable"? > 2) What is the policy or lag time for getting commits such as the > aforementioned bug-fix into these stable branches? > 3) Are there docs for this, and if not, should there be an entry on > https://docs.djangoproject.com/en/dev/faq/install/? > > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Policy for stable/1.x.x branches
Ah, thanks Jacob. Also, great job on the 1.5.1 release. Thanks to everyone for all the hard work. On Thursday, March 28, 2013 12:34:56 PM UTC-4, Yo-Yo Ma wrote: > > The commit > https://github.com/django/django/commit/2f121dfe635b3f497fe1fe03bc8eb97cdf5083b3fixed > a problem where a custom regex validator's customized message was > ignored, in favor of the one set on the class (you just see "Please enter a > valid value"). > > If I pip install the latest master, the problem is of course fixed. If I > pip install stable/1.5.x, the problem persists. > > I searched the docs for info about using the stable/1.x.x branches, but > couldn't find anything, so I wanted to ask: > > 1) Is doing so considered safe (e.g., for production usage), since they're > "stable"? > 2) What is the policy or lag time for getting commits such as the > aforementioned bug-fix into these stable branches? > 3) Are there docs for this, and if not, should there be an entry on > https://docs.djangoproject.com/en/dev/faq/install/? > > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Testing project code that resides outside of installed apps
A common pattern for larger applications is to maintain bits of reusable code outside of applications, but still inside of a project (e.g., myproject/lib), due to synchronous development and modification of application and library code. They're parts that aren't really large enough to warrant their own pip-installable package, but large enough to need tests. Often, the (non-)solution is either to NOT test these small tools at all, or to test them in a way that tightly couples them to one's applications. I'm here to get feedback on the general idea of a solution to the aforementioned problem, and on the acceptability (by the community) of such situations (maintaining libs outside of applications but still inside of a project): 1) Is there merit to (Django) providing a way to specify a project-level tests package/module wherein tests could be imported from various places in your project? OR 2) Is this something that should always remain in a custom test runner? OR 3) Is this sort of code maintenance just not a great idea because libraries that need tests should be factored out as pip-installable packages and independently tested? If this is considered a good practice AND the answer to #1 is something akin to "yes", feel free to make suggestions on what you think the API (or setting, etc.) should look like. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Testing project code that resides outside of installed apps
That's excellent news! Thanks, Carl. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
unittest2 discovery proposal
+1, in general. >> ** The current "myapp." notation is not part of unittest2, and >> would go away I don't know of anyone for whom this would represent a breakage in deployment processes, since it's usually used for quick local testing only. One concern, however: How will `django-admin.py test` be handled when not in the project root? It might be good, for backwards compatibility, to default the `root` argument to the directory containing the settings module. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
value|localize possibly breaking timezone display in templates
If you include {{ object.some_datetime }} with the America/New_York
timezone activated in a template and get:
April 10, 2013, 10:00 p.m.
Then, take the same object, timezone, etc., and add the |localize filter -
{{ object.some_datetime|localize }} - you'll get:
April 11, 2013, 2:00 a.m.
It seems as if the `localize` filter disables the automatic timezone
converting documented @
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#time-zone-aware-output-in-templates
Should the docs be updated to reflect this (i.e., it is intended), or
should I file a bug ticket?
Note, my settings contain:
USE_TZ = True
TIME_ZONE = 'UTC'
USE_L10N = True
The datetime in question was created via `timezone.now()`
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Should saving a model with foreign keys referencing unsaved models raise an error?
The following example can throw a wrench in things, if you don't catch it right away, since it fails silently. >>> instance.some_fk_field = unsaved_instance >>> instance.save() The following example bit somebody I worked with a couple years back as well. >>> instance.some_m2m.add(unsaved_instance) Would it suffice to modify the ORM to fail loudly when either of the above examples occur, or do they both represent documented features (thus preventing them from being "fixed")? -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: test discovery
Wow, this is awesome! Thanks so much guys. Too long have I dreamt of the day when I could include tests for my "lib" and "util", etc. without having to couple them to one app or another. I'm so excited that this was added so quickly. Thanks Yo-yo -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Perception of attitude in tickets
> > How about allowing comments only from the patch author and committers? > The problem I see with this is that original bug reporters, aside from the aforementioned groups, are usually the ones most engaged in these comments, and eliminating them from the process will only serve to further disjoint the technical dialog (e.g., "It's still not fixed" should probably go in the ticket, not here). -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Perception of attitude in tickets
There is a fundamental problem here, albeit one that is rooted in simple misunderstanding. The burden of proof is on the originator of an idea (i.e., the ticket reporter). Arguments can be made against the idea in the ticket. Rebuttal is sent elsewhere. Regardless of the intention, this automatically creates contention (in some cases) because it appears as a double standard, as arbitrary discretion is used to draw a line in the sand (the point at which the discussion should be moved to the mailing list). The solution could be either: A) Allow for full discussion in a ticket (this may not be an option, based on the conversations I've read) or B) Disallow only technical (how to fix, code review, etc.) discussion in a ticket, and make it easy to get from a ticket to its discussion thread and back again. Option A allows for easier collaboration on business aspects by incorporating technical considerations into the conversation at the expense of extra noise. Option B allows for easier digestion of either tech or business at the expense of a lack of cohesion among both parties. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Possible bug: makemigrations caching prior migrations after deletion
Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before this writing), I created a model with a "name" field, then created a migration for it. Moments after, I added an "age" field to the model, deleted the 0001_initial.py migration, deleted __pycache__ directories in my entire project, deleted any *.py[cod] files in my project, then ran makemigrations again (the goal being to create a fresh 0001 migration with the latest fields again, since there is no SQLite3 database file (I verified this as well)). When I do this, Django creates the same 0001 migration it did the first time, then creates a 0002 migration to add the new field. Firstly, how is this even possible? Second, is this a known issue in 1.8? I've never experienced this bug before, and it's always been my M.O. on a new project to recreate a 0001 migration when I'm first working on the models (to avoid having 30 migrations before the app is even on a dev server). -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Possible bug: makemigrations caching prior migrations after deletion
Sorry for the belated reply, Andrew and Curtis. You're both right that the "bug" was just a case of makemigrations resolving dependency issues and my misunderstanding of that fact. To test whether this was a bug or just makemigrations splitting up the migration, I had created a separate app with the exact same model as the supposedly offending app, and this time it didn't result in 2 migrations, so I thought I had empirically proven that this was some sort of pycache related bug... Afterword, I realized that this was because I had created the dependency's 0001 migration first, which of course then allowed makemigrations to simply add that 0001 migration as a dependency. Michael On Sunday, February 8, 2015 at 7:05:00 PM UTC-5, Andrew Godwin wrote: > > Indeed, Django can make many migrations for an initial set if it needs > them to de-circularise dependencies (e.g. two models with foreign keys > pointing at each other - it splits one of their FKs into a second > migration). > > Andrew > > On Sun, Feb 8, 2015 at 11:17 PM, Curtis Maloney < > cur...@acommoncreative.com > wrote: > >> Could you provide details about what sort of field you added, please? >> >> I have seen cases where migrations will create two separate migrations >> for an initial. >> >> -- >> Curtis >> >> On 9 February 2015 at 10:11, Yo-Yo Ma >> > wrote: >> >>> Using Python 3.4.2 and Django @stable/1.8.x (installed just moments >>> before this writing), I created a model with a "name" field, then created a >>> migration for it. Moments after, I added an "age" field to the model, >>> deleted the 0001_initial.py migration, deleted __pycache__ directories in >>> my entire project, deleted any *.py[cod] files in my project, then ran >>> makemigrations again (the goal being to create a fresh 0001 migration with >>> the latest fields again, since there is no SQLite3 database file (I >>> verified this as well)). When I do this, Django creates the same 0001 >>> migration it did the first time, then creates a 0002 migration to add the >>> new field. Firstly, how is this even possible? Second, is this a known >>> issue in 1.8? I've never experienced this bug before, and it's always been >>> my M.O. on a new project to recreate a 0001 migration when I'm first >>> working on the models (to avoid having 30 migrations before the app is even >>> on a dev server). >>> >>> -- >>> 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-develop...@googlegroups.com . >>> To post to this group, send email to django-d...@googlegroups.com >>> . >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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-develop...@googlegroups.com . >> To post to this group, send email to django-d...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-developers/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/21d572d3-aa1d-4e16-99c1-894ae0cdc176%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Concerns with new "libraries" template functionality
I was reading through the 1.9 release notes when I came across the new
OPTIONS['libraries'] feature.
Relevant links:
-
https://docs.djangoproject.com/en/dev/releases/1.9/#template-tag-modules-are-imported-when-templates-are-configured
- https://docs.djangoproject.com/en/dev/releases/1.9/#templates
-
https://docs.djangoproject.com/en/dev/topics/templates/#module-django.template.backends.django
*tl;dr*
This new functionality trades convention for configuration, in a
problematic way, for little gain.
If OPTIONS['libraries'] was made to mean: "only these libraries can be used
in templates", there would be no problem. If it does in fact mean this,
please disregard the following points and view this as a documentation
update request.
*Long version:*
My concern is that we're now offering a way to explicitly register template
libraries in OPTIONS['libraries'], which:
1) allows you to {% load some_key_from_that_dict %}
2) causes the modules to be loaded upon application start (and
presumably `check`)
Unless I missed something, this functionality is lacking / concerning
because of the following reasons:
1) 'libraries' will not be the *only* libraries allowed to be used in
your templates, which *removes the "explicit"* nature (there isn't much
explicit about a setting that is only additive)
2) Due to #2, you can still run into module load time errors via {%
load something_not_registered %}
3) Environment-specific settings module (e.g., local_settings.py) can
now cause unexpected runtime errors due to renaming tag libraries (vs
simply using the module name)
4) 'libraries' will not be automatically built-in ('builtins' does that)
#4 is only mentioned because when you consider #1, #2 and #3 there is
suddenly no additional value added by this "libraries" option, unless it
also acted as add_to_builtins.
If the goal of this feature is to add application start time checks for
template libraries, the right (and *consistent*) way to handle this would
be to follow suit with admin.py, models.py, tests.py, etc., and add
`templatetags` packages to application checks. If the goal of this feature
is to provide a way to control the name used in {% load ... %} (very small
value added, IMHO), then this should be the only thing it does, so that
devs don't rely on the feature for something more.
If I'm understanding this new feature correctly, the *elevator pitch*
becomes:
*You can now use OPTIONS['libraries'] to have Django check for import
errors on *some* of your template libraries, the ones you remember to add
there. The side effect is that {% load some_name_that_isnt_a_module_name %}
will confuse devs. Also, your devs can continue to use {% load
by_module_name_not_libraries_key %} and ignore your settings completely, or
even worse, if they have local template settings due to local file system
differences, they will have to remember to copy new libraries in each time
they're added / changed.*
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2bfe1c14-c4a7-4fc9-a9f7-b77a4f7d35ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Concerns with new "libraries" template functionality
CORRECTION: | Due to #2, you can still run... Should be: | Due to #1, you can still run... -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0485d9ad-0736-4042-8aaa-f89a79d2df51%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Concerns with new "libraries" template functionality
Hi Aymeric, Pardon my misunderstand of the new functionality, and thanks for the explanation. The ability to use template libraries outside of installed apps alone is a great addition. Thanks for your hard work on this. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/eb6a15ba-483e-45eb-98a8-5ffb8ba125e3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?
Another reason you want the two to be separate is that you might allow a field to be blank in forms but then set the value to some context-specific value (vs a simple default=x) before saving. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/cb880dcd-cd9e-4fca-9950-08948dd136c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Improve adding data to forms programmatically
To clarify, are you referring to a state where there are validation errors and the form is redisplayed, whereupon your change the value back to the original value? Pertaining the problem you mentioned last (displaying the intermediary result): you are probably better off using the value from the form's instance for displaying outside of an input. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/daf37ea7-00ed-443f-b674-f9ac2f24acb7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Proposal: --debug-sql option for management commands
I found an N+1 query by inspecting the code of a management command that was running every 10 minutes, and it made me think, it would be good to have an option similar to https://django-debug-toolbar.readthedocs.org/en/1.0/commands.html#debugsqlshell for management commands in general. If there interest in this, I'll look into what it would take to factor out the functionality of debugsqlshell into a --debug-sql (or whatever name) argument that could be passed to management commands in general. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c1a6ac31-ccd8-412a-ac9c-cd1f96f3a477%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Odd behavior change in 1.8 with {% if %}, RelatedObjectDoesNotExist, and TEMPLATE_STRING_IF_INVALID
I may be way off base here, but I actually feel like string_if_invalid should eventually be removed. It seems like a really bad idea to have a setting that can muck up an application in unexpected ways. Meanwhile, settings like DEBUG=True can't muck up your application, even if they're not secure to leave on in production. I think the answer to whether it should be treated as a regression is the inverse of whether there are other places where template logic could unexpectedly change based on this setting. Fixing this one situation by checking for a specific error seems wrong, unless it's the only such case that could be reasonably expected to cause this problem. Based on the warning in the docs (about the admin), I take it that is not the case. So without further ado, I vote "not a regression". -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4431f173-db1f-4b5d-9941-1ca1fb4697e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Questions pertaining the dubious value and the origin of "common" passwords
Today, I decided to check out Django's new password validation functionality (which is a great feature, btw). I noticed there was a CommonPasswordValidator, which mentions "1000 common passwords"... Part 1. The first thing that came to mind was, how would one compile a list of 1000 common passwords, unless they maintained a rainbow table of millions of possible passwords AND had access to a large corpus of leaked password hashes (or databases of plain text passwords)? Here's where it's worth noting the "This is Facebook, so I'll create a real password" vs "This is just some forum I'll probably never come back to, so I'll just use hunter2" phenomenon. Now, given the second part of the question (large corpus of data), or even more so, the plain text case, where does intuition tell you that the majority of this kind of data would likely come from? Facebook / Twitter / online banks? Or, forums and defunct website? I think with that, I've established the potentially dubious potential for the notion of "N most common passwords" being even remotely accurately established. Part 2. So, with the above thoughts in mind, I decided to have a look at the passwords Django is using and find their origin (did they come from a compiled list of "leaked" databases or something else?). The list (plain text: https://gist.github.com/anonymous/59e9eb2935165d7b0fa9), I found after a quick search, is copied wholesale from a website called passwordrandom.com. The website appears to be owned by one Dmitriy Koshevoy in Ukraine, but other than that I know nothing about it. The list that Django uses is from this page specifically http://www.passwordrandom.com/most-popular-passwords - purporting to have the 10,000 most commonly used passwords (in order!), but says nothing about where they came from. I figured, maybe this website is quite popular for password validation / generation, and Dmitriy has compiled... seems like a pretty bad idea to give them your password, but oh wel. Except that passwordrandom.com has basically no traffic, according to SimilarWeb, Compete, and Alexa. Side note: passwordrandom also features this strange and suspicious joke http://www.passwordrandom.com/password-database. Hopefully nobody has entered their real password there or anywhere else on the website, or used the site to generate a password, lest they lose it to the public domain, since the website doesn't even employ TLS. Conclusion. With all that, I'm now wondering how this list of "common" passwords made it into Django's code base. Perhaps, it should be removed, since, as I've established above, it provides no verifiable value or security. It could just as well be replaced with a configuration option (list setting or file path setting), to maintain backwards compatibility (and warm fuzzies for those who think *they* know the most common passwords?). -- 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-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 discussion on the web visit https://groups.google.com/d/msgid/django-developers/c0cfdd0d-98f1-49a4-a8d3-e50ad56b4847%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
UnicodeDecodeError in template rendering due to ’ (angled apostrophe)
I just downloaded trunk about 2 hours ago, and I have a template that has a ’ character (angle style apostrophe that happens if you type something like "This doesn't work" in Fireworks (turns to "This doesn’t work" in Abobe Fireworks). When rendering a static page consisting of only the template, the UnicodeDecodeError occurred. C:\Python26\lib\encodings\utf_8.py in decode, line 16 The string that could not be encoded/decoded was: doesn�t hav -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: UnicodeDecodeError in template rendering due to ’ (angled apostrophe)
Perhaps it isn't a bug in Django. My document's encoding is Western European (CP-1252). Is this typical, or should I manually choose ASCII? On Aug 24, 6:35 pm, Yo-Yo Ma wrote: > I just downloaded trunk about 2 hours ago, and I have a template that > has a ’ character (angle style apostrophe that happens if you type > something like "This doesn't work" in Fireworks (turns to "This > doesn’t work" in Abobe Fireworks). > > When rendering a static page consisting of only the template, the > UnicodeDecodeError occurred. > > C:\Python26\lib\encodings\utf_8.py in decode, line 16 > > The string that could not be encoded/decoded was: doesn t hav -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: UnicodeDecodeError in template rendering due to ’ (angled apostrophe)
@Josh - really helpful. Thanks. So, if Django had a bug pertaining to character encoding, it wouldn't be appropriate for me to report it here because I discovered it while I was developing a site. On Aug 24, 6:39 pm, Josh Ourisman wrote: > Simple solution: don't use Adobe Fireworks. > > Also, this is more appropriate for the django-users group, django-dev is for > discussion of development of Django itself, not development of sites that > use Django. > > > > On Tue, Aug 24, 2010 at 8:35 PM, Yo-Yo Ma wrote: > > I just downloaded trunk about 2 hours ago, and I have a template that > > has a ’ character (angle style apostrophe that happens if you type > > something like "This doesn't work" in Fireworks (turns to "This > > doesn’t work" in Abobe Fireworks). > > > When rendering a static page consisting of only the template, the > > UnicodeDecodeError occurred. > > > C:\Python26\lib\encodings\utf_8.py in decode, line 16 > > > The string that could not be encoded/decoded was: doesn t hav > > > -- > > 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+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. > > -- > Josh Ourismanwww.joshourisman.com > (301) 244-9674 > Washington DC -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: UnicodeDecodeError in template rendering due to ’ (angled apostrophe)
Fireworks isn't an HTML editor. I copied some text from a Fireworks mock up. The issue isn't that Fireworks put smart quotes, which I was well aware of. It was the fact that a Django template didn't allow smart quotes. I was concerned that this might be a bug. On Aug 24, 6:46 pm, Josh Ourisman wrote: > Perhaps I'm misinterpreting the error, but it sounds more to me like the > problem is with Adobe Fireworks inserting smart quotes where they have no > business being. I'm also not aware of Fireworks being an HTML editing > program, so I'm not entirely sure why you're creating templates with it. > > On Tue, Aug 24, 2010 at 8:41 PM, Yo-Yo Ma wrote: > > @Josh - really helpful. Thanks. So, if Django had a bug pertaining to > > character encoding, it wouldn't be appropriate for me to report it > > here because I discovered it while I was developing a site. > > -- > Josh Ourismanwww.joshourisman.com > (301) 244-9674 > Washington DC -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Feature request - extend multiple templates
Let's say I have a site with 5 sections, 6 main tabs per section, and
7 sub tabs per main tab. In order to display the correct tabs for a
given view, I have to have:
baseform.html
baselist.html
foo_section/form.html
foo_section/list.html
foo_section/spam_sub_section/form.html
foo_section/spam_sub_section/list.html
Each section has to have a "form.html" and "list.html" to override the
main tabs, and each sub section has to have a "form.html" and
"list.html" to override the sub tabs for that sub section.
This is of course very painful, but the thing that makes it worse is
that I have to override each block 2 times with the exact same code
(foo_section/list.html and foo_section/form.html have the same tabs
and therefore have 15-20 lines of the exact same HTML in each). This
is true with each level of "form.html" and "list.html". If I could
inherit from two or more templates, and have the later override any
blocks from the former, I could do this:
baseform.html
baselist.html
foo_section/tabs.html
foo_section/form.html
foo_section/list.html
foo_section/spam_sub_section/tabs.html
foo_section/spam_sub_section/form.html
foo_section/spam_sub_section/list.html
For example, Inside of foo_section/form.html and foo_section/
list.html it would have only:
{% extends "form.html" "foo_section/tabs.html" %}
I might be designing this all wrong, but it seems that working with
tabs is very difficult to do without having hundreds of templates. If
my feature request is lamo, any help or suggestions are much
appreciated instead.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Any interest in adding a navigation helper to Django?
I'm speaking about something like http://code.google.com/p/django-nav/ One of the main issues I deal with when developing software with Django is that I need to create a new template for every view that changes navigation (e.g. tabs). The ability to generate some sort of a map that allows for sub-navigation to show up in it's proper place, and make active navigation links take on an active look and feel, without manually adding templates would be very helpful for me. Is there anyone else out their with this problem? Thanks Rog -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Any interest in adding a navigation helper to Django?
You know what, I thought this hadn't been updated for 3 years because the downloads section isn't updated. I didn't bother to browse the SVN for change dates. Thanks Dougal. Rog On Aug 26, 10:32 am, Dougal Matthews wrote: > On 26 August 2010 17:25, Yo-Yo Ma wrote: > > > I'm speaking about something likehttp://code.google.com/p/django-nav/ > > > One of the main issues I deal with when developing software with > > Django is that I need to create a new template for every view that > > changes navigation (e.g. tabs). The ability to generate some sort of a > > map that allows for sub-navigation to show up in it's proper place, > > and make active navigation links take on an active look and feel, > > without manually adding templates would be very helpful for me. Is > > there anyone else out their with this problem? > > I didn't know about this particular project, so thanks I'll check it out. > > I can see the problem, I've had it before - although its not been too much > of an issue. What advantages does this have being included in Django core? > It seems to be doing quite well as an external project. Is there something > in Django that is stopping it work well externally? > > Dougal -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Feature request - set variables in template
I'm sure this will be met with criticism, but there is a reason why
just about all template languages allow the setting of variables. It
allows you to do things like:
{% for thing in things %}
{{ thing }}
{% if thing.is_the_one %}
{% set_var the_one thing%}
{% endif %}
{% endfor %}
{{ the_one.name }} is a really good thing. Click here to read more.
Instead of having to pass in a variable called "active_one" or
something to that effect from your view. I've provided the
implementation:
class SetVarNode(template.Node):
def __init__(self, var_name, raw_var_value):
self.var_name = var_name
self.variable = template.Variable(raw_var_value)
def render(self, context):
context[self.var_name] = self.variable.resolve(context)
return ''
@register.tag
def set_var(parser, token):
"""
Example Template:
{% set_var first_name "Roger" %}
{{ first_name }}
Outputs:
Roger
"""
try:
tag_name, var_name, raw_var_value = token.split_contents()
except ValueError:
raise template.TemplateSyntaxError(
'{0} requires 2 arguments.'.format(token.split_contents()
[0])
)
return SetVarNode(var_name, raw_var_value)
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Feature request - set variables in template
You absolutely cannot. The "with" statement puts the variable in the
scope of the "with" statement only, not to mention that would not be
very explicit at all.
On Aug 26, 6:14 pm, "David P. Novakovic"
wrote:
> You can basically do this with the "with"
> statement:http://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=old...
>
> On Fri, Aug 27, 2010 at 10:06 AM, Yo-Yo Ma wrote:
> > I'm sure this will be met with criticism, but there is a reason why
> > just about all template languages allow the setting of variables. It
> > allows you to do things like:
>
> > {% for thing in things %}
> > {{ thing }}
> > {% if thing.is_the_one %}
> > {% set_var the_one thing%}
> > {% endif %}
> > {% endfor %}
>
> > {{ the_one.name }} is a really good thing. > href="{{ the_one.get_absolute_url }}">Click here to read more. > h1>
>
> > Instead of having to pass in a variable called "active_one" or
> > something to that effect from your view. I've provided the
> > implementation:
>
> > class SetVarNode(template.Node):
> > def __init__(self, var_name, raw_var_value):
> > self.var_name = var_name
> > self.variable = template.Variable(raw_var_value)
>
> > def render(self, context):
> > context[self.var_name] = self.variable.resolve(context)
> > return ''
>
> > @register.tag
> > def set_var(parser, token):
> > """
> > Example Template:
>
> > {% set_var first_name "Roger" %}
>
> > {{ first_name }}
>
> > Outputs:
>
> > Roger
> > """
> > try:
> > tag_name, var_name, raw_var_value = token.split_contents()
> > except ValueError:
> > raise template.TemplateSyntaxError(
> > '{0} requires 2 arguments.'.format(token.split_contents()
> > [0])
> > )
> > return SetVarNode(var_name, raw_var_value)
>
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://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-develop...@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 - set variables in template
I see what you're saying Russell. I myself am reluctant to use the template tag I created in some ways. Although I cannot seem to find a DRY way of doing what I'm doing, the idea of breaking the dogma does bother me a bit. I thought that if I could get confirmation from the crowds, it would make me feel better. Thanks a lot for ruining my evil plans :) On Aug 26, 6:30 pm, Russell Keith-Magee wrote: > On Fri, Aug 27, 2010 at 8:06 AM, Yo-Yo Ma wrote: > > I'm sure this will be met with criticism, but there is a reason why > > just about all template languages allow the setting of variables. > > Yes. It's because most template languages are trying to be a Turing > complete programming language. Django's template language isn't. > > This leads to people putting view logic in their template, and it's > something Django's template language is specifically trying to > prevent. In my opinion (and the historical opinion of the core team) > this is a *feature*, not a bug. > > Yours, > Russ Magee %-) -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Any interest in adding a navigation helper to Django?
I think the thing that would be helpful to most django users is bit really a navigation helper per se. I think what I need could be solved with a more generic tool. Russell, tell me what you think about providing a way to make a view a "child" of another. I'm not speaking in the CMS sense (e.g. /accessories/hair/brushes/) as this is very proprietary and can be aconploshed using a number of different algorithms (Django TreeBeard for example). I'm speaking in terms of software views. (e.g. /configuration/settings/billing/), etc. I want to have a way to know that I should show "settings" tabs when I'm at / configuration/, and without having to create 2 new templates (one for list and one for forms) for "configuration" that just overrides the menu. This works until you have a lot of views and then it gets to the point where you have 50 templates just for menus. Imagine a theme update with that. What's your thoughts on that? On Aug 27, 8:56 am, Tobias McNulty wrote: > On Thu, Aug 26, 2010 at 8:59 PM, Russell Keith-Magee < > > russ...@keith-magee.com> wrote: > > > Navigation menus strike me as something that: > > * Can live happily outside the core - it doesn't need to integrate > > closely with any part of the Django stack. > > > * Isn't a problem that everyone has. > > > * Even if it is a common problem, is something where there are many > > possible ways to solve the problem > > +1 leaving navigation outside the core. > > Tobias > -- > Tobias McNulty, Managing Partner > Caktus Consulting Group, LLChttp://www.caktusgroup.com -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Any interest in adding a navigation helper to Django?
I will do that. I just don't know where to start. The way I envisioned it working with URL confs somehow, but I just can't seem to wrap my brain around how to tie the python classes I created into the way the framework works. I'll read more. On Aug 27, 11:48 pm, Russell Keith-Magee wrote: > On Sat, Aug 28, 2010 at 12:32 PM, Yo-Yo Ma wrote: > > I think the thing that would be helpful to most django users is bit > > really a navigation helper per se. I think what I need could be solved > > with a more generic tool. > > I don't doubt that for a second. What I'm challenging is why this > needs to be in Django's core. > > Django is a web framework. It provides a way to map a HTTP request to > a function that can service that request. It provides the base tools > to render a response to that request. It provides tools to handle form > input, and ways to store that form input into a data store. > > But Django isn't the end of the story. Django is just a Python > library. You can -- indeed, you *should* -- be using a range of other > Python libraries in your Django application, including libraries that > work in parallel to Django, and libraries that build on the framework > that Django provides. > > It sounds like you want some sort of generic navigation framework. > Great. Sounds like a plan. However, I haven't yet heard why it needs > to be part of Django's core. > > And as a matter of project planning -- just posting to Django-dev and > saying "Django should have feature X" doesn't mean Django will gain > feature X, even if we all agree it's a great idea. This is a volunteer > run open source project. The only code that gets committed is code > that has been written. Nobody is going to write the code for you. If > you want feature X, *you* need to build it -- or convince/pay someone > else to build it for you. > > > Russell, tell me what you think about > > providing a way to make a view a "child" of another. I'm not speaking > > in the CMS sense (e.g. /accessories/hair/brushes/) as this is very > > proprietary and can be aconploshed using a number of different > > algorithms (Django TreeBeard for example). I'm speaking in terms of > > software views. (e.g. /configuration/settings/billing/), etc. I want > > to have a way to know that I should show "settings" tabs when I'm at / > > configuration/, and without having to create 2 new templates (one for > > list and one for forms) for "configuration" that just overrides the > > menu. This works until you have a lot of views and then it gets to the > > point where you have 50 templates just for menus. Imagine a theme > > update with that. What's your thoughts on that? > > Honestly, I have no idea what you're suggesting. A view is a function. > How you organize those functions into the navigation structure of your > application isn't something that needs to be embedded in the concept > of a view. > > If your project has gained 50 templates just to describe menus (or, > more importantly, if the number of templates is scaling linearly with > the number of views you're trying to integrate), I suggest that you've > missed the point somewhere along the way. Between template logic, > template tags, and context processors, Django provides a number of > very sophisticated ways of constructing rendered content. It sounds > like you might need to spend some more time investigating the tools > that are already provided. > > Yours, > Russ Magee %-) -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Document direct API usage of FileField and ImageField
I think it might be a good idea to document the direct usage of the
FileField, and ImageField model fields.
The docs make the assumption that everyone is using ModelForm to
upload files. If I have a file on my hard drive and want to use it to
populate the field, I would try something like:
from PIL import Image, ImageFile
image = open('/some/path/to/image.jpg', 'rb')
instance = MyModel(
image=image,
title="Hello, World."
)
instance.save()
The docs show examples of how to manually use models, but don't give
any examples of how to do this when an image, or file is included in
the mix.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Document direct API usage of FileField and ImageField
BTW, ignore the PIL imports
On Sep 15, 12:28 pm, Yo-Yo Ma wrote:
> I think it might be a good idea to document the direct usage of the
> FileField, and ImageField model fields.
>
> The docs make the assumption that everyone is using ModelForm to
> upload files. If I have a file on my hard drive and want to use it to
> populate the field, I would try something like:
>
> from PIL import Image, ImageFile
> image = open('/some/path/to/image.jpg', 'rb')
>
> instance = MyModel(
> image=image,
> title="Hello, World."
> )
>
> instance.save()
>
> The docs show examples of how to manually use models, but don't give
> any examples of how to do this when an image, or file is included in
> the mix.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Document direct API usage of FileField and ImageField
I actually don't know how to do it myself. I'm still trying to put some context to the Storage API, and file uploads in general. There seems not to be a consensus on the best way to handle files in Django. I figured I'd put the request up here so others don't run into the same problem, but I've not solved my own problems in the meantime. When I do, I'll make a patch for the docs. I'm trying to allow a user to upload a single photo, and have it saved as 2 different sized thumbnails, as well the original. Should I look into using the Storage API directly? On Sep 15, 5:52 pm, Russell Keith-Magee wrote: > On Thu, Sep 16, 2010 at 2:28 AM, Yo-Yo Ma wrote: > > I think it might be a good idea to document the direct usage of the > > FileField, and ImageField model fields. > > Sure -- sounds like a reasonable proposal to me. Open a ticket on Trac > so the idea isn't forgotten. > > We also accept patches :-) > > Yours, > Russ Magee %-) -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Inclusion of easy-thumbnails into Django Contrib
Is there any plans to incorporate http://github.com/SmileyChris/easy-thumbnails/ into django.contrib? I have seen so many apps/libraries come into and go out of existence (http://code.djangoproject.com/wiki/ThumbNails for instance mentions sorl-thumbnails which is no longer being developed). I just turned the key with easy-thumbnails and voila. It's like magic, but not. It's easy enough to see what's going on behind the scenes. This is something that, with the help of the core and other contributors, could be really great. It works for me as it it is, but it may not work for a more "enterprise" application that uses S3, etc. It might not be highly efficient (I wouldn't know). It might have bugs that I just haven't noticed yet. I'm mentioning all of this because I know somebody will say, "Why move it into Django if it's doing just fine as a separate project?". After experiencing the bliss I thought I'd drop a line here about it, and see what you guys thought. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
I have no data to support the following assertion, but it's not too unreasonable: More people probably need thumbnail images than they need comments. Comments are most used on blogs, whereas thumbnails can be used on blogs, e-commerce, photo hosting, social networking, project management, et al. It's not to say that we don't need "contrib.comments", just that I wouldn't want to lose easy_thumbnails. On Sep 15, 11:32 pm, "David P. Novakovic" wrote: > Actually, that really did sound negative. Sorry :) > > Is there a trac ticket open to address this issue? Generally it'd be > better to get discussion happening over a ticket and if there are > serious issues that need to be addressed then they can be discussed > here. > > I know it'd be nice to get things like easy-thumbnails accepted into > django.contrib , but the truth is that this probably falls outside of > things that that should be in contrib. Contrib isn't really an easier > way to get stuff into django, it still has to satisfy a bunch of > conditions like the rest of the code in the core. > > The real question is not "can it be included?" but why is it a problem > that this is a third party lib at the moment? Is there a strong case > that it be better if it was part of django core or does it do its job > just fine the way it is now? > > David > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > wrote: > > I don't want to sound negative, but answering your own question before > > anyone else can doesn't change the answer ;) > > > D > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma wrote: > >> Is there any plans to > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/ > >> into django.contrib? I have seen so many apps/libraries come into and > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > >> instance mentions sorl-thumbnails which is no longer being developed). > >> I just turned the key with easy-thumbnails and voila. It's like magic, > >> but not. It's easy enough to see what's going on behind the scenes. > > >> This is something that, with the help of the core and other > >> contributors, could be really great. It works for me as it it is, but > >> it may not work for a more "enterprise" application that uses S3, etc. > >> It might not be highly efficient (I wouldn't know). It might have bugs > >> that I just haven't noticed yet. I'm mentioning all of this because I > >> know somebody will say, "Why move it into Django if it's doing just > >> fine as a separate project?". After experiencing the bliss I thought > >> I'd drop a line here about it, and see what you guys thought. > > >> -- > >> 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+unsubscr...@googlegroups.com. > >> For more options, visit this group > >> athttp://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-develop...@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: Inclusion of easy-thumbnails into Django Contrib
sorl-thumbnails is over. The two developers who were maintaining it have started to different projects. One relies on ImageMagik and is probably not as easy for the crowds. The other is "easy-thumbnails". On Sep 16, 10:33 am, "Brian O'Connor" wrote: > I have absolutely no pull in decision making, but maybe my message will > count towards a "community voice". > > I think that including an image thumbnail package that integrates into the > database as easily as sorl.thumbnail and easy_thumbnail are is a great > idea. From what I can tell, sorl.thumbnail was the de facto standard for > getting thumbnails in to Django, and I think it has just as much of a place > in Django contrib as some of the other contrib apps do. I don't think it > belongs in the core, but contrib seems like an excellent place for it to go > along with the other batteries in the pack. > > > > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma wrote: > > I have no data to support the following assertion, but it's not too > > unreasonable: More people probably need thumbnail images than they > > need comments. Comments are most used on blogs, whereas thumbnails can > > be used on blogs, e-commerce, photo hosting, social networking, > > project management, et al. It's not to say that we don't need > > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > On Sep 15, 11:32 pm, "David P. Novakovic" > > wrote: > > > Actually, that really did sound negative. Sorry :) > > > > Is there a trac ticket open to address this issue? Generally it'd be > > > better to get discussion happening over a ticket and if there are > > > serious issues that need to be addressed then they can be discussed > > > here. > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > > django.contrib , but the truth is that this probably falls outside of > > > things that that should be in contrib. Contrib isn't really an easier > > > way to get stuff into django, it still has to satisfy a bunch of > > > conditions like the rest of the code in the core. > > > > The real question is not "can it be included?" but why is it a problem > > > that this is a third party lib at the moment? Is there a strong case > > > that it be better if it was part of django core or does it do its job > > > just fine the way it is now? > > > > David > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > wrote: > > > > I don't want to sound negative, but answering your own question before > > > > anyone else can doesn't change the answer ;) > > > > > D > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma > > wrote: > > > >> Is there any plans to incorporatehttp:// > > github.com/SmileyChris/easy-thumbnails/ > > > >> into django.contrib? I have seen so many apps/libraries come into and > > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > > > >> instance mentions sorl-thumbnails which is no longer being developed). > > > >> I just turned the key with easy-thumbnails and voila. It's like magic, > > > >> but not. It's easy enough to see what's going on behind the scenes. > > > > >> This is something that, with the help of the core and other > > > >> contributors, could be really great. It works for me as it it is, but > > > >> it may not work for a more "enterprise" application that uses S3, etc. > > > >> It might not be highly efficient (I wouldn't know). It might have bugs > > > >> that I just haven't noticed yet. I'm mentioning all of this because I > > > >> know somebody will say, "Why move it into Django if it's doing just > > > >> fine as a separate project?". After experiencing the bliss I thought > > > >> I'd drop a line here about it, and see what you guys thought. > > > > >> -- > > > >> 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+unsubscr...@googlegroups.com > > . > > > >> For more options, visit this group athttp:// > > 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-develop...@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. > > -- > Brian O'Connor -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
I see what you're saying Chuck. It's almost like you stop evolution (natural selection, if you will) when you accept a "winner" for the trunk. The positive to weigh against is that you remove instability form external projects like this. It's a great project, but it could turn south quickly without being fully supported. To be honest, I'm even on the fence myself, but it's worth mentioning for others to weigh in. On Sep 16, 10:55 am, Chuck Harmston wrote: > There's a negative side to contrib: once an app is included, it stifles > innovation on that particular app (because it is tied to release cycles and > must maintain full backwards compatibility) and discourages other developers > from innovating in that same area. > > In order to get an application included to contrib, you'll need to make a > compelling case that the community will gain by its inclusion in contrib. > Yes, easy-thumbnails is great, but the only argument you've provided is that > you don't want development to die, as it did on sorl_thumbnails (which is > still a functional piece of software, by the way). That's a legitimate fear, > but where do you draw the line? What about django-registration? Or > django-taggit? > > Further discussion from DjangoCon (skip ahead to 22:12 for discussion on > contrib, though I recommend the entire > talk):http://djangocon.blip.tv/file/4112452/ > > On Thu, Sep 16, 2010 at 12:41 PM, Brian O'Connor wrote: > > > > > Yeah, I'm aware, that's why I said '_was_ the de facto standard' :) > > > easy-thumbnails is what I had in mind when I was agreeing with you. I > > think it's a great piece of software that satisfies most people's needs for > > image manipulation within a web development environment, and being in > > contrib will allow people to use another package if they don't like it. > > > On Thu, Sep 16, 2010 at 12:37 PM, Yo-Yo Ma wrote: > > >> sorl-thumbnails is over. The two developers who were maintaining it > >> have started to different projects. One relies on ImageMagik and is > >> probably not as easy for the crowds. The other is "easy-thumbnails". > > >> On Sep 16, 10:33 am, "Brian O'Connor" wrote: > >> > I have absolutely no pull in decision making, but maybe my message will > >> > count towards a "community voice". > > >> > I think that including an image thumbnail package that integrates into > >> the > >> > database as easily as sorl.thumbnail and easy_thumbnail are is a great > >> > idea. From what I can tell, sorl.thumbnail was the de facto standard > >> for > >> > getting thumbnails in to Django, and I think it has just as much of a > >> place > >> > in Django contrib as some of the other contrib apps do. I don't think > >> it > >> > belongs in the core, but contrib seems like an excellent place for it to > >> go > >> > along with the other batteries in the pack. > > >> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma > >> wrote: > >> > > I have no data to support the following assertion, but it's not too > >> > > unreasonable: More people probably need thumbnail images than they > >> > > need comments. Comments are most used on blogs, whereas thumbnails can > >> > > be used on blogs, e-commerce, photo hosting, social networking, > >> > > project management, et al. It's not to say that we don't need > >> > > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > >> > > On Sep 15, 11:32 pm, "David P. Novakovic" > >> > > wrote: > >> > > > Actually, that really did sound negative. Sorry :) > > >> > > > Is there a trac ticket open to address this issue? Generally it'd be > >> > > > better to get discussion happening over a ticket and if there are > >> > > > serious issues that need to be addressed then they can be discussed > >> > > > here. > > >> > > > I know it'd be nice to get things like easy-thumbnails accepted into > >> > > > django.contrib , but the truth is that this probably falls outside > >> of > >> > > > things that that should be in contrib. Contrib isn't really an > >> easier > >> > > > way to get stuff into django, it still has to satisfy a bunch of > >> > > > conditions like the rest of the code in the core. > > >
