Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

These queries are actually not equivalent. Consider the following code: >>> r = Related.objects.create(field='related') >>> r.main_set.create(field_one='1', field_two='3') >>> r.main_set.create(field_one='2', field_two='4') >>>

Re: Make bool(AnonymousUser) evaluate to false

{% if request.user %} is a perfectly valid way to check if the user object is available in the template. I don't think we should change that or give a warning. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: Review of DEP 201 - simplified routing syntax

The regex in `url()` can be translated using `ugettext_lazy()`, in which case the lazy translation happens when `resolve()` or `reverse()` is called. It seems the current `path()` implementation would

Re: Review of DEP 201 - simplified routing syntax

On Friday, May 12, 2017 at 6:43:34 PM UTC+2, Florian Apolloner wrote: > > > > On Friday, May 12, 2017 at 12:33:28 PM UTC+2, Aymeric Augustin wrote: >> >> Django's URL resolver matches URLs as str (Unicode strings), not bytes, >> after percent and UTF-8 decoding. As a consequence \d matches any

Re: DEP pre-proposal for a simpler URLs syntax.

> >- The more complex part is (I think) figuring out how to deal with >cases where we have a `path('/', include(other_urls))` and >`other_urls` also has a `path()` mentioning `something`. However this > might >just be my perfectionism and paranoia seeing edge-cases where

Re: Template handling of undefined variables

What about adding a filter |defined that returns True if a variable is defined, False otherwise? It may not solve any problems when it's left implicit, but at least it allows users the explicitly define the behaviour for non-existing template variables, and it makes the intention of the

Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

This issue is actually limited to reverse(). When resolving urls, each nested regex is matched against the url separately, so you can just apply the flags to the "local" regex pattern, and get: a/c/ a/C/ a/b/ matching, but not: A/c/ A/C/ A/b/ The behaviour for reverse() can be a problem. For

Re: Rethinking migrations

On Saturday, November 5, 2016 at 4:53:49 PM UTC+1, Patryk Zawadzki wrote: > > 1. Dependency resolution that turns the migration dependency graph into an > ordered list happens every time you try to create or execute a migration. > If you have several hundred migrations it becomes quite slow. I'm

Re: Challenge teaching Django to beginners: urls.py

I actually do have working code[1] that among other things abstracts the regex to a Constraint, which allows you to easily inject your own custom logic for resolving and reversing url fragments. This allows for a "simple" system at a more fundamental level, rather than just translating the

Re: Possible Bug in RegexURLResolver

using locals it means each thread will always end up calling > the actual populate code? Is there any point for the RegexURLResolver class > to be a singleton then? > > > El jueves, 14 de julio de 2016, 9:12:54 (UTC-3), Marten Kenbeek escribió: >> >> It's not quite a

Re: Possible Bug in RegexURLResolver

It's not quite as simple. Concurrency is actually not the main issue here. The issue is that self._populate() only populates the app_dict, namespace_dict and reverse_dict for the currently active language. By short-circuiting if the resolver is populating, you have the chance to short-circuit

Re: Add support for relative imports in django.conf.urls.include()?

Hi Josh, On Monday, February 29, 2016 at 11:34:18 PM UTC+1, Josh Smeaton wrote: > > Going off topic a little bit but.. have we considered deprecating string > based includes in favour of actually importing the urls module? > I've tried to remove them as a proof of concept, but that's not

Re: Add support for relative imports in django.conf.urls.include()?

The current approach can lead to surprising errors if include() is called by a helper function, rather than directly called in your urlconf. The relative import would be resolved in relation to the module where the helper function is defined. I'm not sure how much of an actual problem that is

Re: db.models.options help with a piece of code analysis.

Hi Elton, Django makes the Meta class of abstract models available as Foo.Meta. This allows you to define common Meta options on the abstract base class, and inherit the base Meta in your concrete child models. So the above example won't work as you noted, but this will: class

Re: Google Summer of Code 2015 statistics

Hi Himanshu, Last summer I was the only participant in GSoC 2015 for Django. I worked on a complete rewrite/refactor of the URL dispatching framework. I wasn't able to finish my project at the time due to personal circumstances. Right now the project is nearing completion, I'm aiming at the

Re: URL dispatching framework: feedback requested

, **kwargs): url_object.host = self.domain return url_object, args, kwargs On Thursday, January 7, 2016 at 2:07:03 PM UTC+1, Florian Apolloner wrote: > > > > On Monday, December 28, 2015 at 5:23:19 PM UTC+1, Marten Kenbeek wrote: >> >> One can for example impl

URL dispatching framework: feedback requested

A quick question: Aymeric suggested to merge django.conf.urls into django.urls as well. Does anyone think we should not make this move? If no one disagrees, I will proceed with a new PR to make the move. -- You received this message because you are subscribed to the Google Groups "Django

Re: Backwards-compatibility import shims

ill continue > using django.core.urlresolvers in new code if there's no indication that > it's deprecated. > > On Wednesday, December 30, 2015 at 8:50:10 AM UTC-5, Marten Kenbeek wrote: >> >> As noted >> <https://github.com/django/django/pull/5578#discussion_r44212450&

Backwards-compatibility import shims

As noted by Collin on deprecating old import paths: I personally wouldn't mind if we didn't actually deprecate this, and left > these shims in a bit longer :). (Makes it just a hair easier for people > upgrading.) But that's just

URL dispatching framework: feedback requested

Hi everyone, This past week I've made some great progress in rewriting the URL dispatcher framework and iterating on my implementation. A big part of my effort to refactor my original code was to increase the performance of reverse() to a level similar to the legacy dispatcher, and to decouple

Re: A community Poll

> > I'm quite sure I was driven to that PR because importing ContentTypes > was causing lots of pain with AppState not being ready. > Whenever I see this error message pop up, it's not because code directly imports ContentTypes, but because it imports some other models.py module, which in

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

I think it'd be more consistent with other parts of the ORM to use **kwargs to specify aliases. For nested data you can use an object, say N, similar to Q and F objects: Articles.objects.filter(id=1).values('body', N('author'), my_custom_title= 'title') I'm no ORM expert, but could something

Re: __ne, #5763

The 'con' side argument is that it would create in inconsistency in the API, since we don't have any other negated lookups either. If we can get the same behaviour by fixing the current API, Django should not introduce an unnecessary consistency. ("Closed as wontfix by core dev" is not an

Re: Automatically get default value for "current_app", for easier namespace support.

Hi George, The behaviour for {% url %} has since been changed when used with a RequestContext. It will now default to the current namespace when one is available. This change will be available in 1.9. This change doesn't cover the thread-local storage for calls to reverse(), or for {% url %}

Re: Why is from_db_value not called on ModelClass.objects.create()?

I've had to explain this behaviour a few times - most recently this SO question - so I think it's worth it to explicitly document this behaviour. I agree with Simon, though - I don't think

Re: Ability to migrate other applications

> > The order of migrations isn't something which is local to this feature, it > is something which isn't fixed (probably by design, correct me if I'm > wrong) and if it is not "the right way" to do it, maybe it should be part > of another issue. The order of migrations within a single app

Re: URL Dispatcher

s Addison wrote: >> >> In the interests of keeping the excellent work done by Marten Kenbeek >> (knbk on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current >> and moving along, I've created a new branch [2] and rebased it against >> current master

Re: Ability to migrate other applications

Say A.0002 and B.0001 are different leaf nodes for A.0001, and both alter the same field. Now, on a clean database, the order is pretty stable. If that order is A.0001, A.0002, B.0001, you'll always end up with the field from B.0001. This is also what the autodetector sees. If you first

Re: Ability to migrate other applications

Hi Emmanuelle, I think the main problem is the dependencies between migrations. The order in which migrations are run is not fixed. It depends on which migrations have already run, and we can't guarantee the same order for each deployment. If each chain of migrations that could act on a

Re: URL dispatcher API

Hi James, Thanks for taking a look at this, I really appreciate it. *Major bug:* the `request` object needs to be passed into `resolve()` here: > https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134 > > - otherwise host and scheme

Re: URL dispatcher API

be a cause for hard-to-debug problems. I haven't given it much attention yet, but I'm looking for an efficient way to solve this while maintaining a simple API for `construct()`. As always, feedback is welcome. Marten Op zondag 24 mei 2015 02:13:31 UTC+2 schreef Marten Kenbeek: > >

Re: URL namespaces

ts in Django's test suite. That would > offer a starting point to think about the ramifications. Wouldn't the fix > for broken user code be to set "request.current_app = None" where > necessary? > > On Sunday, June 7, 2015 at 3:29:56 PM UTC-4, Marten Kenbeek wrote: &

Re: URL namespaces

that are able to resolve their own > URLs properly and consistently is an important feature. > > Here's a relevant conversation from a couple years back: > https://groups.google.com/forum/#!topic/django-developers/VVAZMWi76nA > > Cheers. > Tai. > > > On Monday, June

Re: URL namespaces

:42 UTC+2 schreef Marten Kenbeek: > > The admin proves problematic. Looking at the uses of `AdminSite.name`, > it's not easily replaced. There are quite a few places that use the name to > reverse urls, but don't have access to the request and the current > namespace. I think th

Re: URL namespaces

The admin proves problematic. Looking at the uses of `AdminSite.name`, it's not easily replaced. There are quite a few places that use the name to reverse urls, but don't have access to the request and the current namespace. I think the best solution for now is to document that you should pass

Re: URL namespaces

something like: > > urlpatterns = patterns('', > url(r'^my_foo_login/$', 'myapp.views.my_foo_login', name='login', > app='foo', namespace='foo'), > url(r'^foo/', include('foo.urls', app='foo', namespace='foo')), > ) > > Then when templates or view code in the `foo

Re: URL namespaces

erseded by > https://code.djangoproject.com/ticket/21927. Could you review those > tickets as well as the others in the "Core (URLs)" component of Trac? It > would be good if you could assign yourself any tickets that your project > will address. > > On Wednesday, May 27, 2015 at 5:58:

URL namespaces

Hi all, URL namespaces have a few quirks that make them a bit difficult to use and understand. I hope to create a patch that clears up these issues. First up: the distinction between an application namespace and an instance namespace. The docs say on the application namespace: This describes

Re: URL dispatcher API

hat single request typically has just one resolve operation, and thus the >> amount of time used for resolving tends to end up in the noise. But large >> list/table views can have up to thousands of reverse() operations, when >> there are multiple urls per row. >> >> I believ

URL dispatcher API

Hi all, I'd like to discuss the API I'm proposing for the new url dispatcher I'm working on. I'll try to explain the API and some of the rationale behind it. There is a working proof-of-concept at https://github.com/knbk/django/tree/url_dispatcher. Currently, all the names are chosen as not

Re: Must a Django Database Support Migrations?

Hi Marcin, I don't believe it's some sort of ethos that got Andrew to collaborate with Django and create the current migration framework: It's the fact that pretty much everyone who used Django also used South that convinced Andrew to recreate its behaviour as a core Django app. I'm not

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

. Thanks, Marten Op maandag 2 maart 2015 17:57:24 UTC+1 schreef Marten Kenbeek: > > Hey all, > > I'm working on a proposal to extend the URL dispatcher. Here, I'd like to > provide a quick overview of the features I propose. > > I'd like to: > - Allow matching bas

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

domain into your subdomain, so this allows you to raise `StopResolving` if none of the subdomain urls match. [1] https://github.com/fish2000/django-url-namespaces Op maandag 9 maart 2015 15:01:02 UTC+1 schreef Marten Kenbeek: > > After all the feedback I got here and at the sprint, I

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

After all the feedback I got here and at the sprint, I think the core of my proposal will be the revamping of the current dispatcher and creating a public API. I'll keep in mind the other features and in general the extendibility of the new dispatcher, and if there is time left I'll start

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

ion of the existing resolver architecture. > > -- > Curtis > Interesting, definitely worth taking a look. A revamped framework would also allow for an easy extension later on that adds resolvers based on this, in case it isn't included initially. I'll be at the Django sprint in Am

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

: > > > > On 3 March 2015 at 03:57, Marten Kenbeek <marte...@gmail.com > > wrote: > >> Hey all, >> >> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to >> provide a quick overview of the features I propose. >> >>

Extending the URL Dispatcher (GSoC 2015 proposal)

Hey all, I'm working on a proposal to extend the URL dispatcher. Here, I'd like to provide a quick overview of the features I propose. I'd like to: - Allow matching based on request attributes such as the subdomain or protocol, and business logic such as the existence of a database object. -

Re: Support for DATABASES['default'] = {}

sday, February 24, 2015 at 3:11:08 PM UTC+1, Marc Tamlyn wrote: >>> >>> I can't see why it is sensible to support an invalid database >>> configuration as the default. If you explicitly want the default to be a >>> dummy, you should configure that IMO. &

Re: Support for DATABASES['default'] = {}

oposal sounds perfectly reasonable. > > On 24 February 2015 at 13:47, Marten Kenbeek <marte...@gmail.com > > wrote: > >> In fact, DATABASES={} is a valid configuration and merely sets 'default' >> as a dummy backend. An exception is only explicitly raised if you supp

Re: Support for DATABASES['default'] = {}

rc > > On 24 February 2015 at 13:38, Marten Kenbeek <marte...@gmail.com > > wrote: > >> With recent bug reports (#24332 >> <https://code.djangoproject.com/ticket/24332>, #24298 >> <https://code.djangoproject.com/ticket/24298> and now #24394 &g

Support for DATABASES['default'] = {}

With recent bug reports (#24332 , #24298 and now #24394 ) all caused by setting `DATABASES['default'] = {}`, this makes me wonder if it should be supported

Re: Signature of the allow_migrate database router.

Loïc, the model_name is indeed the lower-case version of the object_name: https://github.com/django/django/blob/master/django/db/models/options.py#L203 On Wednesday, February 18, 2015 at 2:07:28 PM UTC+1, Loïc Bistuer wrote: > > Individual routers don't have a base class but we can add it to

Re: status of 1.8 release blockers

@Tim I believe it's quite easy actually, I've fixed my original patch and it's just waiting to be reviewed. It's available at https://github.com/django/django/pull/4071. However, it's a very rare bug and I only encountered it in the tests when working on another issue, not in any real project.

Re: Feature proposal: Allow shadowing of abstract fields

tion > based on locks. > > Please look at how Form and ModelForm support inheritance and shadowing > without it. > > -- > Loïc > > > On Feb 16, 2015, at 21:35, Marten Kenbeek <marte...@gmail.com > > wrote: > > > > Okay, as things wer

Re: Feature proposal: Allow shadowing of abstract fields

vrijdag 13 februari 2015 15:28:53 UTC+1 schreef Marten Kenbeek: > > Hi Loïc, > > Thanks for the response. I will change my code to generate errors in the > case of abstract fields shadowing concrete fields. > > At the moment, the locking mechanism of fields is pretty much the

Re: Feature proposal: Allow shadowing of abstract fields

Bistuer: > > Hi Marten, > > Sorry for the late response, it's been a busy week. Thanks for working on > this, I'll try to have a look at your branch this weekend. > > In the meantime I'll leave some comments below. > > > On Feb 12, 2015, at 22:43, Marten Kenbeek

Re: Feature proposal: Allow shadowing of abstract fields

, but don't include the new scenario's. - Documentation. My WIP branch can be found at https://github.com/knbk/django/compare/ticket_24305. Op dinsdag 10 februari 2015 14:36:53 UTC+1 schreef Marten Kenbeek: > > Hi Aron, > > With option 3, this would work: > > class C

Re: Feature proposal: Allow shadowing of abstract fields

auto created reverse field descriptor. > about option 3 I didn't quite understand. can you explain a bit more? > > On Monday, February 9, 2015 at 4:25:22 PM UTC-5, Marten Kenbeek wrote: >> >> I'd like some additional opinions on the following: >> >> Say you have

Re: Feature proposal: Allow shadowing of abstract fields

on the child class when the reverse relation is added. Option 3) would require an additional patch to the code that adds the reverse relationship, but it allows for some extra options. Any input? Additional options are also welcome. Op zondag 8 februari 2015 21:09:41 UTC+1 schreef Marten Kenbeek

Re: Feature proposal: Allow shadowing of abstract fields

ctB) with AbstractA redefining a field from > AbstractB. > > The last case may be tricky because if I remember well ModelBase iterates > through the MRO in the wrong direction (i.e. bases should be iterated over > in reverse). > > We also need some tests to show how migratio

Re: Feature proposal: Allow shadowing of abstract fields

erride the max length of a field. This was indeed just a proof-of-concept. That remark was meant more like "it doesn't appear to break everything". Marten Op vrijdag 6 februari 2015 23:48:55 UTC+1 schreef Marten Kenbeek: > > Hey, > > While fiddling with django I notice

Feature proposal: Allow shadowing of abstract fields

Hey, While fiddling with django I noticed it would be trivial to add support for shadowing fields from abstract base models. As abstract fields don't exist in the database, you simply have to remove the check that reports name clashes for abstract models, and no longer override the field.