Signal on management command exception

Request exceptions have always been easy to manage, because you can use middleware, and there is the built-in signal: https://docs.djangoproject.com/en/3.0/ref/signals/#got-request-exception Problem: However, if you want to send data to e.g., Sentry or perform some other action (logging,

Re: Proposal: Multiple-Inheritance in Templates

: > > I need help with this project, I can't configure the template pages to > display the information > https://github.com/shadowruge/benim_pro.git > > Em ter., 18 de fev. de 2020 às 18:39, Yo-Yo Ma > escreveu: > >> Hi Matthias, >> >> Thanks for the reply.

Re: Proposal: Multiple-Inheritance in Templates

ot; in the products app. > > I often use this pattern exactly for the case when some app needs to add > its own submenu. > > Best, > Matthias > > > > On Tue, Feb 18, 2020 at 9:44 PM Yo-Yo Ma > wrote: > >> Please help us all understand, then: >> >> How

Re: Proposal: Multiple-Inheritance in Templates

Tuesday, February 18, 2020 at 3:59:09 PM UTC-5, Aymeric Augustin wrote: > > Hello Yo-Yo Ma, > > Please assume good faith. You've been around for 11 years, so you know the > way you address Matthew isn't how we behave on this mailing-list. > > I believe that the most common w

Re: Proposal: Multiple-Inheritance in Templates

design concept is that > multiple template inheritance is unnecessary. > > > > *From:* django-d...@googlegroups.com [mailto: > django-d...@googlegroups.com ] *On Behalf Of *Yo-Yo Ma > *Sent:* Tuesday, February 18, 2020 2:25 PM > *To:* Django developers (Contributions to Django itse

Re: Proposal: Multiple-Inheritance in Templates

ple. > > > > *orders/list.html* > > > > {% extends 'generic-list.html' %} > > > > {% block list-item %} > > Order # {{ order.id }} (total: {{ order.total }}) > > {% endblock %} > > > > > > *From:* django-d...@googlegroups.com [mailt

Proposal: Multiple-Inheritance in Templates

Please read this in full - you will not be disappointed by the end. We often talk about "multiple-inheritance" when referring to multiple levels of {% extends ... %} and defining {% block ... %} many layers up in base templates. But, something that comes up as a useful idea in my mind on a

Re: Make `raw_id_fields` the default functionality in the admin

One last note: M2M could also benefit from this, and could continue to look for `filter_horizontal` and not use a raw IDs field in those cases. On Wednesday, October 17, 2018 at 11:59:43 AM UTC-4, Yo-Yo Ma wrote: > > I have yet to ever come across a situation where the default > fiel

Make `raw_id_fields` the default functionality in the admin

I have yet to ever come across a situation where the default field is more useful than the raw ID field, pertaining foreign key fields in the admin. I have, however, personally witnessed a major publishing company bring their production app servers to a halt (out of memory) due to Django

Re: Update permissions on custom permissions migration

FWIF, I wrote a custom data migration to update the Permission model. My OP is attempting to suggest that migrations should handle this automatically. On Friday, March 30, 2018 at 5:43:39 PM UTC-4, Yo-Yo Ma wrote: > > A model with a custom permission: > > class *Spam*(Model): >

Update permissions on custom permissions migration

A model with a custom permission: class *Spam*(Model): class *Meta*: permissions = (('spam', 'Can eat spam'),) ... $ manage.py makemigrations $ manage.py migrate Now we have a custom permission in the User admin: foods | spam | Can eat spam Then update the

Re: “Abusing BinaryField” warning about binary files in DB

The nice thing about leaving the warning as stern as it is is that anybody who is absolutely sure that they need to store files this way isn’t going to stop because of the warning to begin with; while weaking the warning will most assuredly lead to “Django is Slow” posts by newcomers that

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

> I found it much more difficult to follow to the point where I didn't feel it > was an improvement. I think that patch was just an example of bad abstraction. For instance, _log_and_response was strange and confusingly named, and seemed to be there mostly for vanity, to mask the imperative

#27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

I'm not a fan of adding more complexity, for a couple reasons: 1) you have the ['*'] option for local / office development 2) you can just add a record to /etc/hosts to point to the server and then use a name like e.g., local-office - just update the record to point to whatever IP you're using

Re: should blank POST data fallback to use model field defaults?

@Tom > I'd be surprised if they didn't end up with the model default. Personally I'd treat that as a regression, and revert to the older behavior. I think Tim is saying the opposite, that Django 1.10 accidentally introduced "fields missing from POST are set to model defaults" behavior. @Tim

Re: Django Integration

Correction: *JKM starred (not started) - stupid, stupid iPhone. -- 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

Re: Django Integration

To hopefully add to this conversation: I'll start by saying I've enjoyed the contributions by Andrew over the years and believe he is a most excellent developer. A couple months ago, around the same time that JKM started Andrew's repo (which is what got my attention) I decided to give Channels

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

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

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

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

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

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

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

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 -

Re: Possible bug: makemigrations caching prior migrations after deletion

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 <baxters...@gmail.com >> > wrote: >

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

Feature request: Add SITE_NAME setting

Along with the subject, I'd also propose abstracting the purposes that contrib.sites.requests.RequestSite serves out of the sites app, since the purpose it serves is more of a general one whose usefulness spans admin and auth, as well as third-party apps. The use of code from sites when sites

[ANNOUNCE] Django 1.7 released

Epic, thanks so much! -- 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

Re: Please don't kill the ecosystem

With as many new frameworks as there are out there, with the gains in popularity seen in Go and Node, my thinking is, move quickly, break (some very small) things, or die slowly. As was said, if your favorite lib doesn't work with 1.6 or 1.7, either use a prior version, or spend some time

Re: manage.py migrate doesn't call createsuperuser

: > > This was a deliberate change, I think it was discussed on the list but > maybe just IRC. The tutorial was changed to reflect it, if any > documentation still says otherwise it is a documentation bug. > > On 31 באוגוסט 2014 18:23:58 GMT+03:00, Yo-Yo Ma <baxters...@gmail.com > &

Re: manage.py migrate doesn't call createsuperuser

(continued) I'm using Django 1.7c3, and the above is the first time running migrate (sqlite3 database deleted prior to running). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails

manage.py migrate doesn't call createsuperuser

If this is a known bug, I apologize, otherwise I'll create a ticket in Trac for it. Details: INSTALLED_APPS is ( 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages',

Re: integrating django-secure

+1 on basically adding the functionality of checksecure to the default validation. -1 to adding the middleware. -- 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

Re: On django multi tenancy

It's so easy to build an Account or Tenant or Site model of your own, do a little leg work, and you've got a multitenant app with all the custom functionality you need. Getting caught up in trying to use contrib apps and hacking things together turned out to be more work once you pass the

Working towards a simpler GCBV implementation?

I'm excited about Django Vanilla Views. I think the GCBV implementation in Django is pretty good (I use GCBV got everything - leads to better extensibility), but a simpler version of the same functionality would be great. I'm NEVER certain of whether I'm using the right mixins and base class

Re: Circularly dependent fixtures fail with Postgres 9.2

> > -- > Aymeric. > > On 26 juin 2013, at 02:43, Yo-Yo Ma <baxters...@gmail.com > > wrote: > > > It does happen in 1.5, but the error is somehow slightly different (no > traceback in 1.5 to find the root cause). I have 2 fields on the order > model poi

Re: Circularly dependent fixtures fail with Postgres 9.2

it doesn't, > it's a regression introduced by the new transaction management in Django > 1.6, and it's a release blocker. > > -- > Aymeric. > > > > On 25 juin 2013, at 22:30, Yo-Yo Ma <baxters...@gmail.com > > wrote: > > I should actually note, this bug

Re: Circularly dependent fixtures fail with Postgres 9.2

I should actually note, this bug affects all versions of Postgres, and presumably all other supported RDBMSs as well. On Sunday, June 23, 2013 7:35:45 PM UTC-4, Yo-Yo Ma wrote: > > Minor correction: I placed Atomic.__exit__ to verify - the transaction is > commited every time

Re: Circularly dependent fixtures fail with Postgres 9.2

:24:40 PM UTC-4, Yo-Yo Ma wrote: > > Hi again Russell, > > I did a little digging. I'm not sure, but I may have uncovered the > problem. A transaction block (using `commit_on_success_unless_managed`) is > entered and exited during each fixture object loaded, due to the calls to &g

Re: Circularly dependent fixtures fail with Postgres 9.2

4 PM UTC-4, Yo-Yo Ma wrote: > > Pardon one typo: I meant `python manage.py loaddata test_data` in my > previous post. > > On Friday, June 21, 2013 4:32:33 PM UTC-4, Yo-Yo Ma wrote: >> >> Hi Russel, >> >> Thanks for taking the time to explain that. I tried that

Re: Circularly dependent fixtures fail with Postgres 9.2

Pardon one typo: I meant `python manage.py loaddata test_data` in my previous post. On Friday, June 21, 2013 4:32:33 PM UTC-4, Yo-Yo Ma wrote: > > Hi Russel, > > Thanks for taking the time to explain that. I tried that same day to > reproduce the issue in a testing env with

Re: Circularly dependent fixtures fail with Postgres 9.2

f models (which you have done) > and simple fixture (which you haven't) that fails reliably, we have a new > bug on our hands, and you should open a ticket with all the details you can > provide. Confirming whether this is a problem with the alpha, or an ongoing > problem would also

Circularly dependent fixtures fail with Postgres 9.2

There doesn't appear to be a way to load fixtures from JSON (using Postgres - works fine in sqlite3) for the following models: class Collection(models.Model): main_thing = models.OneToOneField( 'things.Thing', null=True, on_delete=models.SET_NULL ) class

Re: Meta-Proposal: Write *above* quotations in mailing list replies

reiterate, in email digests the latter format results in the reply not even being included in the email. Since this is a mailing list, it's sometimes useful to be able to actually read a digest of it it in your email. Cheers Yo-Yo On Tuesday, June 4, 2013 1:28:47 PM UTC-4, Javier Guerra w

Meta-Proposal: Write *above* quotations in mailing list replies

If you're posting to this list by logging in to https://groups.google.com/ rather than via email, I'd like to propose that you write your reply above the quoted message to which you're replying. If you do this, the digest emails that most subscribers get will be easily previewable from their

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

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

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

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

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

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

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

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

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 wh

Re: Policy for stable/1.x.x branches

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

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,

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

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

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,

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

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

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

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

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,

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

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

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

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

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

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

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,

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

Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures

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

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

Re: ``models.BooleanField`` fields default to ``False`` when missing from fixtures

ptember 24, 2012 5:44:29 AM UTC-4, Aymeric Augustin wrote: > > 2012/9/24 Yo-Yo Ma <baxters...@gmail.com > > >> 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

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

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

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

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

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 +

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

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 <aymeric.augus...@polytechnique.org> wrote: > Hello, > > On 15 mai 2012, at 21:36, Yo-Yo Ma wrote: > > &

Re: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``

here, rather than on the ticket tracker? > > Yours, > Russ Magee %-) > > > > > > > > On Mon, May 14, 2012 at 9:55 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote: > > A request to: > > >    http://www.example.com:8080//foo-bar-baz.ht

Re: Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``

ar 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 <baxterstock...@gmail.com> wrote: > > A request to: > > >    http://www.example.co

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

Re: Proposal: Signal connection via "my_app.MyModel"

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 <douga...@gmail.com> wrote: > On 9 May 2012 22:14, Yo-Yo Ma <baxterstock...@gmail.com> wrote: > > > This would allow for better decou

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

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

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

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

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 <n...@nedbatchelder.com> wrote: > On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:> I'm -1 on this

Re: django-admin.py startproject creating duplicate settings.py files

-1.4b1-py2.7.egg- info On Feb 20, 8:56 pm, Carl Meyer <c...@oddbird.net> 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

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

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

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

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

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

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

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

  1   2   >