Re: Trac is broken
It seems that the issue is somehow related to empty trac_session cookie which somehow has got set. Here is the curl request which can be used to obtain the 403 response: curl -I -H 'Cookie: trac_session=' https://code.djangoproject.com/ticket/2659 Clearing the cookies solved the problem, so the issue is probably low-priority. -- 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/87pos1fd5y.fsf%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Trac is broken
Trying to browse any ticket on code.djangoproject.com yields 403 Forbidden, with a message “TICKET_VIEW privileges are required to perform this operation. You don't have the required permissions.”. An attempt to login via https://code.djangoproject.com/login results in 502. It has been broken that way for some days (at least). Is there a plan to fix this? Browsing tickets via web.archive.org is not very handy… -- 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/87r3chff24.fsf%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Choosing fallback language for translation (#16284)
Hi, I’m raising the issues found in ticket #16284 ( https://code.djangoproject.com/ticket/16284 ). To sum up, here is how Django currently chooses translation in jsi18n: — It searches for a translation for the active language. — If the above is not found, it searches for the settings.LANGUAGE_CODE translation. – If the above is not found, it searches for English translation. There are two problems related to this algorithm: ⒜ If source code language is other than English – for example, let it be Polish – and the programmer wants to provide English translation, then only the English .mo file is present. Therefore when Polish language is active, English translation supersedes it. ⒝ If there exists translation for settings.LANGUAGE_CODE and there is no translation for source code language, then when the latter is active, it is analogously superseded by settings.LANGUAGE_CODE translation. The ⒜ issue could be solved by simply removing English preference (although this behavior is tested, it doesn’t seem to be documented). However this still leaves us with ⒝, which can be solved by letting Django know what is the language of translated texts. Obviously, the natural place to put that information would be the newly-created AppConfig class. An attribute named like “natural_language” could be created. This leaves us with the question what should be done with translations from settings.LOCALE_PATHS (those are not tied to any particular app). In that case, an additional setting could be created which would serve as the natural language when determining whether those translations should be loaded. Also, it could be the default natural language for applications. If no information is provided, Django will behave in a backwards compatible way, except perhaps removing English language preference. Does it sound like a reasonable approach? Any caveats that I missed? Regards, Krzysztof -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5307212A.1050400%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Feature request: New middleware method for "universal" decoration
W dniu 24.10.2013 18:33, Gavin Wahl pisze: I really like the idea of implementing this as a url pattern decorator. This seems similar to Alex Gaynor's talk about everything being a view. It's more flexible than a middleware because you can decorate any part of the urls tree, such as the patterns for a single reusable app. urls = decorate_recursively(login_required, patterns(...)) This is actually possible to implement today, see snippets like https://djangosnippets.org/snippets/2532/. The code required is kind of ugly, so I think it would benefit from an implementation in core. There is also the django-decorator-include package: https://github.com/jeffkistler/django-decorator-include and it contains DecoratedPatterns class: https://github.com/jeffkistler/django-decorator-include/blob/cc50e071e51af63e24583dc7274547796478fec3/src/decorator_include/__init__.py#L10 . -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/529752E0.5020603%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal to end the war with flake8 warnings
On 10/09/2013 08:38 PM, Tim Graham wrote: A drawback is that it will introduce some noise in the commit history in the short term and make git blame less efficient. Note however that there is “-w” option for git blame, which does the following: “Ignore whitespace when comparing the parent’s version and the child’s to find where the lines came from.” So that noise can be somewhat reduced, at least when using the command line. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/52592AA5.7070405%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Proposal: Deprecate SimpleTestCase.settings and SimpleTestCase.urls
There is a SimpleTestCase.settings method added in commit 0dc6420ⁱ, which, according to the docstring, returns “A context manager that temporarily sets a setting and reverts back to the original value when exiting the context.”. In commit a3a53e0² its implementation has been simplified so that now it is only an identity wrapper around override_settings class (which was added in the same commit). The documentation states that SimpleTestCase.settings should be used as a context manager and override_settings should be used as a decorator³, but, given that implementation, override_settings can be used for both tasks. Making a distinction generates only unnecessary noise, so I propose to deprecate and remove SimpleTestCase.settings method and document the fact that override_settings can act also as a context manager. There is also a SimpleTestCase.urls class attribute which allows user to specify overriden ROOT_URLCONF setting. It was added in commit 415bd69⁴, long before SimpleTestCase.settings and override_settings were available. Currently the same effect can be achieved with override_settings decorator, so SimpleTestCase.urls can be considered redundant, and also marked for deprecation. Krzysztof ⁱ https://github.com/django/django/commit/0dc6420 ² https://github.com/django/django/commit/a3a53e0 ³ https://docs.djangoproject.com/en/dev/topics/testing/overview/#overriding-settings ⁴ https://github.com/django/django/commit/415bd69 -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: Support for HTTP PATCH method
W dniu 21.05.2013 14:38, Russell Keith-Magee pisze: These are all reasonable and fairly small I'd be happy to see these added after the alpha - a ticket and patch would definitely be welcome. I’ve created a ticket and a pull request with PATCH support for View and RedirectView (support for test client is already done): https://code.djangoproject.com/ticket/20478 https://github.com/django/django/pull/1198 I agree that leaving the rest of PUT/PATCH issues untouched for now looks like a reasonable approach. -- Krzysiek -- 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.
Proposal: Support for HTTP PATCH method
There is a RFC describing HTTP method named PATCH: http://tools.ietf.org/html/rfc5789 Quoting that RFC: “ The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.” Django currently has (seemingly shallow) support for PUT method. Based on that, I’ve grepped for places in code where it is implemented to see if support for PATCH could be easily added on a basis of symmetry. Those places are: In test client: There is a `put` method, but `patch` is also implemented: https://github.com/django/django/commit/293f7a21147ad94c92c7d5b3f33cbab2f87b001b In View class: https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L33 `put` is listed in http_method_names In RedirectView: `put` is a fallback to .get(): https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L207 In ProcessFormView: https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L164 PUT is implemented as a fallback to POST and it seems to assume that request data is form encoded. While it is not generally true for PUT method, it looks like a reasonable assumption when processing a form. However since PATCH request doesn’t have to contain full form data, I think the best approach may be to not implement `patch` method here (unless we want to deal with editing only some of the form’s fields – for example this is the case in Rails, where PATCH will be the primary method for updates in 4.0 version: http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/ ). The same stays true to `get_form_kwargs` method in FormMixin: https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L44 In general, Django’s approach to whether PUT should be treated as a request containing form data seems to be inconsistent because we generate forms in the views, but we refuse to generate PUT QueryDict on a request object: https://groups.google.com/d/msg/django-developers/dxI4qVzrBY4/m_9IiNk_p7UJ . So maybe it’s worth to consider removing PUT support in form processing just on the basis of consistency. In conclusion, it seems pretty easy to add basic PATCH support similar to PUT. So if it gets enough +1s, I’m willing to make a patch and hope it gets included in 1.6 alpha. Or maybe it is (from a technical point of view) so small a feature that it doesn‘t need to be merged before alpha release? -- Krzysiek -- 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: Single table inheritance - working implementation
Dnia 2012-12-21, pią o godzinie 11:05 -0800, Anssi Kääriäinen pisze: > I went with a different approach than the patch for 1.5. At this stage > as minimal as possible change to get_default_columns() seemed like a > good idea. See commit a0155f35343afbfd9e98ab9aa4615f06780f697e in > stable/1.5.x. > > I patched only 1.5.x. Master will get soon different handling of the > parent model joining in get_default_columns(). The taken approach in > master should still allow typedmodels to work. See: > https://github.com/akaariai/django/compare/names_to_path_to_fields#L3L254 > > If you have still problems in 1.5.x please tell us soon. There isn't > too much time before the release. Thanks for the patch, it seems to do the job - all tests pass (including two I added today), both on 1.5.x and on 1.4.x. _fill_fields_cache still has to be monkeypatched (I've also added similar patch for _fill_m2m_cache), but this is no change comparing to the previous state. I haven't yet looked through changes from your names_to_path_to_fields branch, but tests pass on it too, which is promising. Regards, Krzysztof -- 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: Single table inheritance - working implementation
On 13.12.2012 15:54, Anssi Kääriäinen wrote: Second, I have created a patch which should allow your work to continue working in master. See https://github.com/akaariai/django/commit/94c417d2a29a0f72b26019fc38ef400420097aa4 - the idea is to change get_fields_with_model() so that it doesn't return different values for proxy models compared to concrete models. I think this is a good solution overall, though this change is somewhat scary - get_fields_with_model is used in many places of the ORM... Thanks for the patch. It causes all typedmodels' tests to pass, however I still have to monkey patch _fill_fields_cache to bypass some currently untested issues. I will investigate this further and hopefully provide some more detailed comments. Regards, Krzysztof -- 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: Single table inheritance - working implementation
On 29.10.2012 14:34, Krzysztof Jurewicz wrote: In February, Craig de Stigter released django-typed-models <https://groups.google.com/d/topic/django-users/63z-ejUQ1Eg/discussion>, a package implementing inheritance hierarchy for Proxy models with automatic type recasting. I've written a fork of it with additional possibility of adding fields to subclasses, therefore achieving a single table inheritance implementation similar to Ruby on Rails' STI. Refreshing this thread because it looks like my fork stopped working properly with recent Django master. I suspect that commit c2e1e by Anssi Kääriäinen should be blamed for this, especially the line # Skip all proxy to the root proxied model opts = opts.concrete_model._meta in get_default_columns method. This causes it to generate potentially invalid set of columns for instantiated model because children typed models are implemented as proxy models and they have different set of fields than the root model, which stores all fields from its subclasses. In general having richer set of columns than required wouldn't be a problem, but those columns are used as positional arguments in model constructor and are therefore mapped incorrectly. I know that proxy models are intended to have the same set of fields as the root model and that I was relying on a completely internal implementation detail, so it has no chance of being treated as a bug, but that being said, I wonder if maybe Django could be changed to make such modifications easier. Currently I see the following solutions to the encountered problem: 1. Do not touch Django code directly and adjust django-typed-models to the changes made. This would probably require writing custom Manager class for TypedModel with custom QuerySet class which will use custom Query class with custom SQLCompiler class which will finally have get_default_columns method copy-paste-changed. Not an elegant solution. 2. Take a completely different approach to achieve single table inheritance — ideas are welcome. 3. Modify Django code to be more friendly to django-typed-models. Current behavior of SQLCompiler looks a bit hackish to me, because in ideal world get_default_columns shouldn't care if a model is proxy or not — this should be handled by model class internally. So perhaps another layer of abstraction could be added to Django ORM to allow internal handling of such special cases as proxy models. This would ideally allow to specify STI as a completely different model type than proxy model. 4. Add single table inheritance as a new inheritance type in Django. I'm not very familiar with Django ORM internals and additionally I don't know which of the above solutions have chances of getting approval by core devs, so feedback is welcome. Regards, Krzysztof -- 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.
Single table inheritance - working implementation
Hi all, In February, Craig de Stigter released django-typed-models<https://groups.google.com/d/topic/django-users/63z-ejUQ1Eg/discussion>, a package implementing inheritance hierarchy for Proxy models with automatic type recasting. I've written a fork of it with additional possibility of adding fields to subclasses, therefore achieving a single table inheritance implementation similar to Ruby on Rails' STI. This is possible mostly thanks to metaclass magic and monkey patching. The fork's homepage is at https://github.com/KrzysiekJ/django-typed-models. Note that it should be considered early alpha and there is much room for optimisation, code cleanup and maybe additional features. Feel free to fork and/or add issues. I don't know yet what to do with licensing since Craig didn't specify any license in the original package. Craig, please comment or send me an email. Regards, Krzysztof Jurewicz -- 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/-/aSgkQliZHtYJ. 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.
