A different approach for the auto-reloader
Hi all, I had a stab at a somewhat simpler development server automatic reloading strategy https://github.com/django/django/compare/master...ramiro:synch-reloader Intention is to test how an implementation of a design by Gary Bernhardt would look. The best written description I could find is this: https://github.com/devlocker/tychus/issues/3 Gary also had posted some tweets (this is how I got interested in the topic) which seems to have been deleted since then. Main idea is: Actual checking of changes on the filesystem for modules under monitoring isn't performed in a loop or by depending on a OS kernel feature but per-HTTP request by a front-end proxy process which is in charge of restarting the 'upstream' web server process (in our case a dumbed-down runserver dev server) only when it detects there have been changes. Been meaning to try this for some time. It would have been much harder before Tom Forbes' work on refactoring and cleaning up the reloading code for Django 2.2. IMHO Tom's code is so very well thought that for example I just had to lightly subclass StatReload to implement this totally different strategy. Current form of the code is a new experimental 'serverrun' (for lack of a better name) added to the Django code base whose command line UI mimics 100% the runserver one. It copies code from a few places of our code base: The runserver command, the WSGI app hosting code, etc. I decided to implement this as a new built-in command for now a) to ease experimentation and b) because it needs some minor changes to the 'runserver' command to handle cosmetic details (logging). If the idea is accepted (read further below for reasons in favor of this) then maybe we can switch runserver to this code. Or if the idea isn't deemed appropate for Django core them I might implement it as an standalone django app/project. If the idea of a smarter stat()-based FS status monitor like this gets actually tested and validated in the field (i.e. by users with big source code trees) it could allow us to possibly stop needing to depend on all of: * watchman * pyinotify * watchdog (and removing our support code for them from the Django code base). Also, this would mean: * Setup simplification for final users (no third party Python libraries or system daemon to install) * Better cross-platform portability for Django (we go back to piggy-backing stat() from the stdlib as our only way yo trigger code reloading). Additionally, as the reloading is performed fully (by restarting the whole HTTP server) and is triggered from another process (the transparent http proxy one) we can drop some contortions we currently need to make: - Having to wait for the app registry stabilization - Avoiding race conditions with the url resolver I suspect there could be power efficiency advantages too as: * The scanning for changes is triggered by HTTP requests which should be less frequent than periodically every N seconds. * If the developer modifies more than one file before switching to the browser there is need of only one FS scan to cater for all these changes, which is performed just in time for the first HTTP request so the code executed to render/serve it is 100% accurate in regard to actually reflecting the state of the code on disk. Similar projects include: - serveit: https://github.com/garybernhardt/serveit - tychus: https://github.com/devlocker/tychus - wsgiwatch: https://github.com/dpk/wsgiwatch Feedback is welcome! Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF99hUobeXs8JQyb%3DywDJ6bkkKWyhUYC%3DEa9JzwQM%2BH_5Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Add Python 3.7 support for Django 1.11?
On Fri, Nov 16, 2018 at 12:32 PM Tom Forbes wrote: > Do we have an idea of how many fixes would need to be backported? > https://github.com/django/django/compare/stable/1.11.x...moneymeets:moneymeets/1.11.16-py37 > 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/CAFNZOJNqLQtq03ee-Sfc5v5z1YzETbxu%3D-bWN9FQk0%3D5Yd1Whg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFNZOJNqLQtq03ee-Sfc5v5z1YzETbxu%3D-bWN9FQk0%3D5Yd1Whg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Ramiro Morales @ramiromorales -- 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/CAO7PdF_VpdxxCPkLSh3GHCA6svsoCKa7zb0WiLnxuZFSPQe4%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Add a setting for customizing the CSRF token name?
Hello,
I'd be in favor of what's proposed.
Slightly related, this made me remember I had some note about proposing we
add either to the Security or the Deployment checklist documents
suggestions about (also) customizing the CSRF_COOKIE_NAME,
LANGUAGE_COOKIE_NAME and SESSION_COOKIE_NAME settings. to make identifying
Django is being used harder.
(This is related to what Aymeric mentions) It's easier this kind of
customization is performed before the initial deployment to avoid the
hassle caused by trying to change them once a site is in production, that's
why I think it's a good idea to make developers/deployers aware they have
these choices at that point.
Regards,
On Sat, Aug 18, 2018 at 11:40 AM Tim Graham wrote:
> Do you think it's worth a new setting to allow customizing the CSRF token
> name ('csrfmiddlewaretoken')?
>
> It was proposed 9 years ago in https://code.djangoproject.com/ticket/12738
> and closed as wontfix absent some justification.
>
> It was again proposed a few days ago in
> https://github.com/django/django/pull/10305 with the rationale:
>
> Wappalyzer identifies Django application with "csrfmiddlewaretoken" input
> name.
> https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json#L2471
>
> I guess the idea is trying to obscure the fact that a site runs Django for
> some "security by obscurity."
>
> --
> 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/01b25887-823e-4008-9ad4-51f80e7c2590%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/01b25887-823e-4008-9ad4-51f80e7c2590%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Ramiro Morales
@ramiromorales
--
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/CAO7PdF8QoVd5CE5q91%3D%2BpnyGxO9-d8YLC5d3aiqSkHr%2BXCbUKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Compilemessages and percent char in msgids
Marcin,
You have upgraded recently to version 1.11.13?
IIRC handling of percent symbols in translatable literals has been the
subject of a few commits along the history trying to get it right for as
many use cases as possible. It's entirely possible it was broken in some
way during the 1.11 release cycle.
Please examine the history for the compilemessages module source file.
Perhaps you can cherry pick one or more commit to your local copy.
If memory doesn't fail me there is some complexity related to the fact that
xgettext (used by makemessages) auto detects some strings that contain %
symbols as literals using 'traditional' Python string interpolation and
there is no way to control such detection.
HTH
On Tue, Jul 24, 2018 at 9:32 AM Marcin Nowak
wrote:
> Hi.
>
> I'm not sure what is going on, but I've updated recently Django to 1.11.13
> and two things seems to be broken (from my perspective):
>
>- behaviour of translation messages containing % is inconsistent, for
>example:
>
>- prevously used msgis are staying untranslated with trans/blocktrans:
>
> msgid "Source %"
> msgstr "Translated %"
>
> ugettext("Source %") -> "Translated %" [OK]
> trans "Source %" -> "Source %" [FAIL, expected "Translated %"]
> blocktrans "Source %" -> "Source %" [FAIL, expected "Translated %"]
>
> - msgids with double percent chars:
>
> msgid "Source2 %%"
> msgstr "Translated2 %"
>
> ugettext("Source2 %") -> "Source2 %" [FAIL, should fail probably?]
>
> ugettext("Source2 %%") -> "Translated2 %" [OK]
> trans "Source2 %" -> "Translated2 %" [OK]
> blocktrans "Source2 %" -> "Source2 %" [FAIL, expected "Translated2
> %"]
> blocktrans "Source2 %%" -> "Source2 %%" [FAIL, expected "Source2
> %"]
>
> activate(original) /* no msgid/msgstrs defined */
>
> ugettext("Source2 %%") -> "Source2 %%" [FAIL, expected "Source2 %"]
>
> - msgids and msgstr with double percent chars:
>
> msgid "Source3 %%"
> msgstr "Translated3 %%"
>
> ugettext("Source3 %%") -> "Translated3 %%" [FAIL, expected
> "Translated3 %"]
> ugettext("Source3 %") -> "Source3 %" [FAIL]
> trans "Source3 %" -> "Translated3 %" [OK]
> blocktrans "Source3 %" -> "Translated3 %" [OK]
> blocktrans "Source3 %%" -> "Source3 %%" [FAIL]
>
> activate(original) /* no msgid/msgstrs defined */
>
> ugettext("Source3 %%") -> "Source3 %%" [FAIL, expected "Source3 %"]
> ugettext("Source3 %")-> "Source3 %" [OK]
> trans "Source3 %" -> "Source3 %" [OK]
> trans "Source3 %%" -> "Source3 %%" [OK]
> blocktrans "Source3 %" -> "Source3 %" [OK]
> blocktrans "Source3 %%" -> "Source3 %%" [OK]
>
> - and second is wrong compilemessages behaviour, because it scans
>and compiles all files starting from cwd. Eariler only django apps were
>scanned. Now this command is trying to compile everything, also unused or
>already compiled files from 3rd party packages.
>
>
> First issue must be fixed. Translations behaviour isn't consistent. I
> cannot make any reliable translations having % in msgids anymore. Assuming
> that double percent in msgid is required (one for escape, one for percent
> sign), this makes wrong translations with "p/n/u/gettext" functions if
> msgstrs with single % were not defined. Please imagine switching to not
> fully translated language, and user will get double % in messages (excl.
> templates with trans, but not blocktrans).
>
> Second should be probably fixed by reverting a patch which adds a tree
> scan of files. Currently I did workaround by copying older version of
> compilemessages into my project's app. But this is not how Django should
> work. I'm using buldout where all external eggs,parts and other projects
> lies in cwd.
>
> Any thoughts?
>
> Kind Regards,
> Marcin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this g
Re: Optionally using a custom queryset for Paginator and MultipleObjectMixin (ListView)
On Sat, Jun 30, 2018 at 12:40 PM Tom Forbes wrote:
> Are you sure it is the prefetches that is causing this? As Adam pointed
> out these are correctly ignored. Annotations however are not, which can
> cause unnecessary work and longer execution times. i.e:
>
> Book.objects.annotate(something=Max('pages__word_count')).count()
>
> We have enough information to be able to strip the pages join when using
> count() it certain conditions are met, and this might be preferable than
> adding workarounds to various places.
>
FYI: This had already been reported in #23771 (
https://code.djangoproject.com/ticket/23771) (and a couple of
similar/duplicates tickets)
Regards,
--
Ramiro Morales
@ramiromorales
--
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/CAO7PdF_Y_vQqYNst5ZR1d9vxWaZMqhZwfF3fcZ4PC7tQv0hGJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: #28975 - Skip automatic creation of postgis extension if it already exists
On Wed, Jan 10, 2018 at 3:12 AM, Niclas Kron wrote: > Hello, > I am writing to you to establish some sort of consensus on how to proceed > with this bug/PR: > > * PR https://github.com/django/django/pull/9518 > * BUG https://code.djangoproject.com/ticket/28975 > > With regard to the problem - the current implementation is that a query is > ran to determine > if the extension exists or not in the current database. That query unlike > `CREATE EXTENSION ...` > does not require superuser status on the executing database user. > > The pros and cons for this implementation: > > ### Pros > * Operates as normal with the only addition that if it already exists we > dont > run the CREATE EXTENSION thus the application wont fail if the user is a > non-superuser. > > ### Cons: > * Hard to test due to the fragility of the tests > > By hard to test, I mean that I can't easily test it because current > implementation leads some sort of race condition > and sometimes the tests fail. At least if you look at my current tests > (yes I am a new to this). > > I did talk about this on the irc channel #django and #django-dev to try to > solve it - however > the recommendation was to write on the mailing list to try to establish a > consensus on a proper > way to go forward. This especially since another create suggestion was put > forward by Ramiro Morales > as per: https://code.djangoproject.com/ticket/28975#comment:5 > > Please disregard that comment as I posted it before or in parallel with the discussion you and Tim were having via the GitHub PR about a non-admin Postgres user being able to introspect at runtime if the postgis extension is installed or not. Had considered the idea myself bud assumed it woudn't be possible or that it would introuduce too much complexityto the code. Was wrong on both counts. Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF8PXETx%3D%2BP2DqgX0CetuzPDk5Gb2E5dF%3Dd7TL55nn8BxA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Password validation Error with Latin characters
Adrian,
I suspect:
1) Django is doing its work: It's checking the strenght and robustness of
the password. It's detecting the password the user has chosen is too
similar to their user name.
2) So, the fact the text shown has latin characters has nothng to do with
the issue you are seeing.
3) The translation ('es') you are using isn't correct (
https://github.com/django/django/blob/1a34dfcf797640d5d580d261694cb54e6f97c552/django/contrib/auth/locale/es/LC_MESSAGES/django.po#L258)
and this might be what is misleading you.
The original English text is
The password is too similar to the %(verbose_name)s.
and the translation should be:
La contraseña es demasiado similar a {{ verbose_name }}
verbose_name has the value "nombre de usuario" in this context.
To confirm this you could temporarily set the languante to English
(en-us) or to the es-ar (castellano as it's used in Argentina) and verify
the original text/a more correct translation (
https://github.com/django/django/blob/1a34dfcf797640d5d580d261694cb54e6f97c552/django/contrib/auth/locale/es_AR/LC_MESSAGES/django.po#L253
)
As Claude said, Please open a thread in the django-users mailing lis i f
you need to follow up this.
On Thu, Nov 30, 2017 at 9:09 AM, Adrian Mansilla
wrote:
> Thanks for the reply.
> I assumed that the error is in django because I do not send that message,
> Django sends it, the error is in:
>
> django/contrib/auth/password_validation.py
>
> And it's because my configuration is in Spanish.
>
> El jueves, 30 de noviembre de 2017, 3:48:28 (UTC-4), Claude Paroz escribió:
>>
>> Hi Adrian,
>>
>> I don't see anything related to Django development in your post. Maybe
>> this was more for the django-users mailing list?
>>
>> Claude
>>
>> Le jeudi 30 novembre 2017 02:39:31 UTC+1, Adrian Mansilla a écrit :
>>>
>>> I am using the function 'validate_password (password, new_user)' and I
>>> have my settings configured in Spanish, the problem comes when the
>>> validate_password function raises an error with the word 'contraseña' and
>>> shows me this error:
>>> ValidationError: [u'La contrase\xf1a es demasiado similar a la de nombre
>>> de usuario.']
>>> I am using python 2.7 and Django 1.11.4
>>>
>>> This is the traceback:
>>>
>>> Traceback (most recent call last):
>>> File
>>> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/core/handlers/exception.py",
>>> line 41, in inner
>>> response = get_response(request)
>>> File
>>> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/core/handlers/base.py",
>>> line 187, in _get_response
>>> response = self.process_exception_by_middleware(e, request)
>>> File
>>> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/core/handlers/base.py",
>>> line 185, in _get_response
>>> response = wrapped_callback(request, *callback_args, **callback_kwargs)
>>> File
>>> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/contrib/auth/decorators.py",
>>> line 23, in _wrapped_view
>>> return view_func(request, *args, **kwargs)
>>> File
>>> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/utils/decorators.py",
>>> line 185, in inner
>>> return func(*args, **kwargs)
>>> File "/Users/adrianmansilla/Documents/sisgos/sisgos/company/views.py",
>>> line 129, in new_user
>>> validate_password(password, new_user)
>>> File
>>> "/Users/adrianmansilla/Documents/sisgos/venv/lib/python2.7/site-packages/django/contrib/auth/password_validation.py",
>>> line 56, in validate_password
>>> raise ValidationError(errors)
>>> ValidationError: [u'La contrase\xf1a es demasiado similar a la de nombre de
>>> usuario.']
>>>
>>> --
> 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/867d623d-7707-4f16-a77
Improving Windows users experience at the command line
Hi all, Tim Graham suggested to post this to this mailing list. Currently, users of Django on Windows have a less than ideal experience hen using the command line. The users mailing list still see posts of new users suffering problems like: - I run django-admin.py startproject and I get an error message stating django-admin.py isn't a known command (This is usually because the \Scripts\ path isn't listed in the PATH environment variable.) - I run django-admin.py startproject as directed and a text editor window opens containing Python code (source code of django-admin.py). (This is usually because the user somehow had the .py extension associated to such editor in their OS-maintained mapping DB of file extensions -> Programs.) - I run python django-admn.py startproject and I get an error message stating Python isn't a known command (This is because the directory containing python.exe hasn't been added to the PATH environment variable.) And similar issues. As we know, versions of Python supported by the currently WIP version of Django [1]will be 3.5 or newer. Also, since version 3.3, the official Windows Python installer [2]includes an implementation of the 'Windows python launcher' proposed by [3]PEP 397. This tool gets installed to a system directory always present in PATH and can act a a pivot to get scripts like django-admin.py, manage.py and runtests.py executed by the right Python interpreter binary, even when running inside a virtual environment. This led me to think it would be possible to simplify lives of our Windows users because today, with a default installation of Python 3.5 o 3.6 (tested this with Python 3.5 on a Windows 7 system) Windows users can simply write django-admin.py startproject foo And things Just work (TM). be it either using the global interpreter, or using a virtual enviromnent. Ticket is #28343: https://code.djangoproject.com/ticket/28343 PR is #8684: https://github.com/django/django/pull/8684 The PR also modifies the introductory document for contributors to Django so it stops suggesting Windows users to use the alien Git Bash shell. At first is seems like a good idea but considering facts like - It forces users to type in "Unixisms" like `./manage.py` or `mkdir ~/.virtualenvs` - Is incompatible with venv (another useful tool, also new in Python 3.3 as part of the standard library) and forces the document to divert Windows users so they install and use virtualenv, putting them in the strange situation of having to do that because then they can activate the virtual env by using the Unix shell-specific `source` builtin instead of using native scripts activate.bat or activate.ps1 Another change proposed by the PR is the addition of a custom Sphinx directive that modifies the UI of CLI example text boxes so they can show a native prompt and native command line input as it should actually be typed by the user either on Unix-based shells or the Windows command prompt through a tabbed interface. A small demo of the proposed change is here (as would be seen on the docs.djangoproject.com website) is here: http://imgur.com/3ce03UT Feedback is welcome. Regards, 1. https://docs.djangoproject.com/en/dev/faq/install/#what-pyth on-version-can-i-use-with-django 2. https://docs.python.org/3.5/using/windows.html#python-launch er-for-windows 3. https://www.python.org/dev/peps/pep-0397/ -- Ramiro Morales @ramiromorales -- 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/CAO7PdF-JC%2BoWkSsDPL2E3msV3g%3DP7E2N4PO2%2B%3DRBMa29CrHXng%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Missing support for gettext fallback translations
On Fri, May 19, 2017 at 9:31 PM, Matt Westcott wrote: > Hi all, > > I've noticed that the django.utils.translation module apparently doesn't > recognise gettext's handling of fallback translations when both a > territory-specific translation catalog (e.g. Spanish (Spain), 'es_ES') and > a generic one (e.g. Spanish, 'es') exist. > > > According to Python's locale logic (specifically gettext._expand_lang and > locale.normalize), the territory-specific catalog always takes precedence - > even when only the generic 'es' locale was requested - and so when the > gettext module constructs a translation catalog for Spanish, it uses the > 'es_ES' dictionary with 'es' as a fallback. When django.utils.translation > assembles the final merged catalog to apply Django's own precedence rules, > it doesn't check for the existence of fallbacks on the individual gettext > objects, so we end up not using the 'es' translations at all. > > > We just got bitten by this on the Wagtail project, because the last > version added a small and incomplete 'es_ES' translation, inadvertently > causing our existing (comprehensive) 'es' translations to disappear from > view: https://github.com/wagtail/wagtail/issues/3600 > > > I haven't been able to find any previous mention of this gotcha, which > surprises me a bit since it seems like quite a fundamental part of > gettext's functionality. I've come up with a quick-and-dirty fix at > https://github.com/wagtail/wagtail/issues/3600#issuecomment-302354552, > but a proper solution that respects both gettext's and Django's precedence > rules is probably going to be a lot more involved. So, before I go ahead > and work on that fix, I was wondering if A) this is legitimately a missing > feature rather than just our translation management not being up to > scratch, and B) whether there's been any previous work on addressing this? > > > If this isn't a bug IMHO then it would be a nice to have feature because of predictability, being a good citizen to the python/gettext ecosystem and to do a good work for our users by providing for reuse of hopefully more helpful translations. In the "it's a bug" case, chances are it's a regression. And I really hope it wasn't me who introduced it. It would be interesting to test some really old Django version (circa 1.0) and if needed, perform a bisection. I'm also surprised by your findings. I guess it's something we simply took for granted. It's mentioned in the [1]docs and has been so for [2]years. I found a couple of threads somewhat related to the topic: https://groups.google.com/d/topic/django-users/EaPVUi2KMhE/discussion https://groups.google.com/d/topic/django-developers/gDU8HlZg4Ug/discussion (this is actually about JS i18n but drove unification of the translation catalog handling code for JS and backend.) Thanks for pointing out this issue. Regards, 1. https://github.com/django/django/blob/master/docs/topics/ i18n/translation.txt#L1996-L1999 2. https://github.com/django/django/blob/attic/i18n/docs/transl ation.txt#L267-L270 -- Ramiro Morales @ramiromorales -- 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/CAO7PdF_bT8XJAnMft7neZOZWK6nTjrjbxQ-bh2d--LVtYSNNHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Error while doing migrations for a new table
On Tue, Apr 18, 2017 at 6:52 AM, Mohamed Ghariani < ghariani.mohamed...@gmail.com> wrote: > Hello, > I tried to apply migrations for a new model. The model was used in a form > used in the admin so the migrations failed. > Please don't post questions like this (about using Django) to this list (its topic is about developing Django). Use the django-users or the #django IRC channel list for that. Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF-jOx9yzbmvrXYEPYDQ2cujTM0s9JaYms1JSadq1z1aeg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: AbstractBaseUser.set_unusable_password() why a random string instead of an empty string?
On Wed, Oct 19, 2016 at 9:20 PM, Jon Dufresne wrote: > When set_unusable_password() is called on a user object, the user's > password is set to a random string starting with "!" [0]. The "!" is then > used by is_password_usable() [1] to determine that this password isn't > usable. > > My question is, why is a random string used instead of an empty string? An > empty string would appear to make the code both simpler and slightly more > efficient. Is the random string more secure or solving some other issue I'm > not aware of? > > I tested this idea and all tests pass: https://github.com/jdufresne/ > django/commit/2332194b449fe4a336c8ea515221955ba0ea3aeb > > The change is relatively easy as all interactions with unusable passwords > are nicely abstracted by functions > > Thoughts on me following through with this code simplification? > > [0] https://github.com/django/django/blob/90c3b11e873a326219a68c14a3b5dc > a0181e7b3c/django/contrib/auth/hashers.py#L78 > [1] https://github.com/django/django/blob/90c3b11e873a326219a68c14a3b5dc > a0181e7b3c/django/contrib/auth/hashers.py#L27 > > Quick perusal if the history and blame log of that file reveals some interesting data: https://github.com/django/django/commit/2c4fe761a0e2b28e2c5c3b4bc506ee06824a443d https://github.com/django/django/commit/aeb1389442d0f9669edf6660b747fd10693b63a7 and its associated ticket #20079 I suspect the answer to your quesin lies somewhere ther. Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF8vSz6j-oSHAWhg84noa1jVyRSjDZC9Da6RqWLi4d3%2Bxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django admin and messages
On Thu, Mar 3, 2016 at 11:06 PM, Cristiano Coelho wrote: > By "we are doing" do you mean that's how it is translated by django, or > are you patching translations on your projects? Any ideas why would it be > different for spanish? It really burns my eyes seeing those grammar > mistakes :D > You could the es_AR translation. I think we have all these cases covered. -- Ramiro Morales @ramiromorales -- 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/CAO7PdF_N_DMA6Pd0uNY8-o7NDdHykjfoZNMj6XnC9kZGB6t5aQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Improving MSSQL and Azure SQL support on Django
Hi all, On Fri, Aug 21, 2015 at 2:39 PM, Meet Bhagdev wrote: > Hi Django Committers, > > > > My name is Meet Bhagdev, I work in the Database Systems engineering team at > Microsoft in Seattle, WA. My focus is the APIs used to connect to and use > Azure SQL Database and SQL Server (MSSQL). Example APIs are ODBC, JDBC, > ADO.NET, etc. (sorry for possibly repeating things folks have already posted to this thread) Meet: Is this list of APIs the final and full one? Because there is work being done on a different stack, the one formed by : * FreeTDS (http://www.freetds.org/ GPL licensed) which implements the wire-level TDS protocol. * pymssql (http://pymssql.org LGPL licensed) -- Python bindings for FreeTDS which implements the Python DB-API 2.0. I'm part of the team maintaining it * django-pymssql (https://github.com/aaugustin/django-pymssql , MIT-licensed) which was created by Aymeric Augustin and depends on pymssql plus ... * django-mssql (https://django-mssql.readthedocs.org/en/latest/ , MIT-licensed) which was created by Michael Manfre Michael, Aymeric and me are Django development team members. Personally, I've been working on stabilizing the lower layers by following a "yak shaving" non-strategy: We (the pymssql team) realised the official pymssql Windows binaries (in particular the FreeTDS libraries) we published when releasing pymssql 2.1.1 don't link in a SSL implementation and so they aren't usable to actually connect to Azure even if the pymssql code iself has such ability. This, plus the fact that the manual process of creating the actual matrix of Windows deliverables is a bit tedious led me to try using the AppVeyor.com hosted Windows CI platform (free for open source projects) to test and actually build the binaries. The work in progress on this can be seen at https://github.com/ramiro/pymssql/tree/appveyor and https://ci.appveyor.com/project/ramiro/pymssql (When working on pymssql 2.1.1 at some point I created a free Azure account with my credit card, tested (on Linux) the pymssql implementation of connection changes needed to get it to work against Azure's SQL Server and cancelled it before it started billing.) So, this led me to start contributing to FreeTDS so to get it back to build cleanly on Windows (work partially included with the 0.95 release back in June) and to also get it built/tested using AppVeyor.com using the experience gained with pymssql. This has been already merged in the current FreeTDS development code and allows the maintainer and contributors to work without access to Windows/SQL Server licenses (my case). - https://ci.appveyor.com/project/freetds/freetds - https://github.com/FreeTDS/freetds/commit/3db5caa48f281f3558d4031cb5a0f0d8e8eef28c I know MS dropped support of the DB-Library (and hence the API it provides, of which FreeTDS is a open source implementation) back in the SQL Server 2005 times. That's why I ask if this stack has any chance of getting some support from Microsoft. Personal motivation for this is simply to get Django (running on Linux) + SQL Server to be a viable choice, even when I currently have no actual need of this. I was one of the two developers behind the original django-pyodbc project which had reached "almost full Django test suite passing" status back in the Django 1.0 & 1.1 (2008-2009) times, but abandoned it when discoverd (by logging the traffic with SQL Servr tools) that the combination of pyodbc + Linux ODBC stack meant the queries were sent twice to the DB server, see https://code.google.com/p/django-pyodbc/issues/detail?id=16 . This is also why I started considering a FreeTDS-based solution a better technical choice. I'm posting a message to the FreeTDS mailing list later today pointing to Meet's post which opened this thread. Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF9v1X5HBRynWKzsda2UUpOVhNgoOAAXJJHY7ZUCzU88KQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains
On Fri, May 29, 2015 at 12:41 AM, Troy Grosfield wrote: > > I have the following domain and subdomains both are trusted and both are > secure (https): > > https://example.com > https://api.example.com > > When making POST ajax request from https://example.com to > https://api.example.com I see the following error message: > > detail: "CSRF Failed: Referer checking failed - > https://example.com/path/to/some/url does not match https://api.example.com/."; > > > Which takes me to the CsrfViewMiddleware where I see same_origin checking: > > # Note that request.get_host() includes the port. > good_referer = 'https://%s/' % request.get_host() > if not same_origin(referer, good_referer): > reason = REASON_BAD_REFERER % (referer, good_referer) > return self._reject(request, reason) > > I trust my subdomain, but there's no way for this code to actually pass this > validation. Am I just missing something? Why would trusted subdomains fail > validation here? Can't this at least be a setting something like > TRUSTED_SUBDOMAINS that's also checked? See ticket [1]24496, it's associated [2]PR and e.g. thios [3]comment. Any help in advancing the issue (e.g. reviewing the patch and adding the missing documentation changes) is welcome. 1. https://code.djangoproject.com/ticket/24496 2. https://github.com/django/django/pull/4337/files 3. https://code.djangoproject.com/ticket/16010#comment:3 -- Ramiro Morales @ramiromorales -- 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/CAO7PdF-WiQN_6FP0uW6P3%3D1bbQFtDy_FBRpYayxpKMByVVh-oQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django detects HTTP Accept-Language header in case-sensitive manner
Hi Carl, On Mon, Sep 29, 2014 at 2:45 PM, Carl Meyer wrote: >> 1. https://docs.djangoproject.com/en/dev/topics/i18n/#definitions > > I do notice that this bit of documentation asserts that a language code > "Represents the name of a language. Browsers send the names of the > languages they accept in the Accept-Language HTTP header using this > format. Examples: it, de-at, es, pt-br. Both the language and the > country parts are in lower case." > > It seems misleading to say that browsers send Accept-Language in "this > format" and then say that both parts in this format "are in lower case". > Do you think this paragraph should be updated to clarify that the > Accept-Language header is actually handled case-insensitively? Today while reading about this library[1] I realized I never went back to this thread. Please accept my apologies. Regarding your comments about that documentation paragraph I must say I agree with you. I can correct and enhance it myself, hopefully soon if nobody beats me to it. -- Ramiro Morales @ramiromorales 1. https://github.com/LuminosoInsight/langcodes -- 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/CAO7PdF-NCon4%2ByRFXpDpqBHzAUj28KvWUC2-DXP%2BrUAM2-rRUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django detects HTTP Accept-Language header in case-sensitive manner
On Fri, Sep 26, 2014 at 4:58 AM, Wayne Ye wrote: > I noticed on small defect here while I was testing my django website's > I18N/L10n, basically below are example Accept-Language headers sent by > Chrome and Firefox (all latest version): > > Chrome: Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4 > Firefox: Accept-Language: zh-tw,zh;q=0.8,en-us;q=0.5,en;q=0.3 > > You noticed that "zh-TW" and "zh-tw", according to the standard: w3c and > ietf rfc2616, the language tag(s) are lower-cased. > > But I've verified that Django will only correctly recognize Chrome's request > (i.e. treat end user prefers zh-tw), for Firefox example above, Django will > actually fallback to en-us/en. > > Could some fellow developers in this forum kindly triage this issue? Once > confirmed I will create a ticket in Trac and submit a pull request > accordingly, expecting any feedback on this. I'd be very interested in learning about the scenario necessary to reproduce this. My reading of the code and tests make me think it's correclty handling these language names in a case insensitive manner when it comes to interpret users' user agent language preferences. Also, I've expanded test a bit to try to demonstrate this. See https://github.com/ramiro/django/compare/lang-tag-ordering?expand=1 On Fri, Sep 26, 2014 at 12:32 PM, Carl Meyer wrote: > Here's the section of RFC 2616 that makes it explicit that language tags > should be treated as case insensitive: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.10 > > I haven't tested, but based on code inspection of > translation.get_language_from_request() and the functions it calls, it > appears to me that you are correct; Django is incorrectly handling > language tags as case-sensitive. See above. > > Ideally (ISTM) the pull request would be comprehensive in testing and > implementing case-insensitive locale-name handling throughout: i.e. not > just in handling the HTTP header, but also checking against > settings.LANGUAGES, etc. > > I wonder if this also has implications for checking whether a given > locale is present on the system. It looks to me like we also do this > case-sensitively right now, but we should do it case-insensitively. This > might be a bit of work, since it would mean that rather than just > checking for the existence of a particular locale directory as we do > now, we would need to read in all the available locale names into memory > (presuming we can't/don't want to enforce that all locales on disk are > lower-cased or whatever). The names of directories with translations on disk are actually GNU gettext locale names[1] as opposed to language names[1] (the ones in the Accept-Language HTTP header and discussed above.) It does specify that the part after the underscore separator must be a ISO 3166 country code. See [2] and [3]. So, for me, this indicates Django current behavior with these file system dir names is correct. But perhaps I'm missing something? Regards, 1. https://docs.djangoproject.com/en/dev/topics/i18n/#definitions 2. https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html 3. https://www.gnu.org/software/gettext/manual/html_node/Country-Codes.html#Country-Codes -- 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/CAO7PdF_Bm%2Btg-mkv38fGGjTCSuEAU6bNvQuo-UXxDwaVMpu87g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: #23321 (Remove .mo from git) Some questions.
I don't think compilation At Package installation time is a good idea because it would mean requiring GNU get text msgfmt binary availability at that point. I'd say the way to go is to perform that .mo files generation at release time so that msgfmt needs to be installed on the Django team release manager in charge of cutting it. Regards, Ramiro Morales @ramiromorales On Sep 23, 2014 10:57 AM, wrote: > Hi. I have some questions about implementation. > > It would be nice to compile those .mo files at package build time. >> > > It's about setup.py? Or compilation must be in another place? > One more question - if it should be in setup.py, will I be able to run > compilemessages command during package installation? > > -- > 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/f5c18c2c-f326-4788-a29e-a58cae65378b%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/f5c18c2c-f326-4788-a29e-a58cae65378b%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-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/CAO7PdF_7mMa9bUVcCdPYWuj-MCjWBnhEXHRG_T7oE-N88Vsfcw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: no relationship between session and user model
On Thu, Jun 19, 2014 at 1:07 PM, Vaal wrote: > This would be useful in a situation when the user changes the password, and > we could remove all the sessions of that user. > For example the user changes the password because he believes that pass has > been compromised. But if the attacker was already has active session - it > will not be interrupted. > Django 1.7 changes this. See https://docs.djangoproject.com/en/1.7/topics/auth/default/#session-invalidation-on-password-change Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF81VrLaF5GsZYxbBEVZsoBNuzXJg%2BW87nQB3_hsXcgYFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Changing development server threads type.
On Wed, Jun 4, 2014 at 11:29 AM, Tim Graham wrote: > I think we should try to move away from maintaining our own web server and > focus our efforts on trying to integration with others like gunicorn > (#21978). For this particular change I'd go with what Moayad proposes but without the backward compatibility command line switch (assuming it actually enhance the reloadind responsiveness). This essentially reduces it to a one-liner. I agree with Tim about being -1 on other kind of changes which mean adding code to the development web server plus it maintenance burden (like for the OS-specific FS change detection mechanism, moving the console output to happen via logging, etc.). Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF-uWkm8XAZyV4HkwaB%2Bm5p70POPOwmWtOB5UAH10K%2Be4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [GSOC] Hi from Daniel!
Hi Daniel,
On Wed, Apr 23, 2014 at 4:23 PM, Daniel Pyrathon wrote:
> Hi,
>
> My name is Daniel, and this summer I will be working on formalising Meta.
> This will allow developers to build custom implementations of Meta and
> deploy them into their Django project. In case you missed my proposal, you
> can have a look at it here:
> https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit#heading=h.wyxx4xxijubt
>
> I'm really looking forward to getting started: I am already in contact with
> my mentor and I was hoping to get to know the community a bit more too :)
I hope you enjoy your summer working on this project.
I have some ideas regarding i18n-related (de)coupling of Meta
atributes like verbose_name{,_plural} to/from such a core part of
Django. I'll be participating in the discussion and following your
work.
Welcome and good luck!
Regards,
--
Ramiro Morales
@ramiromorales
--
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/CAO7PdF_npVHUH1-29fMzF%3DB7SRz1B%2B8ErWUfCq%2BanVe3XTa-Qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Who manages the django-i18n mailing group?
On Thu, Apr 10, 2014 at 9:26 AM, Bruno Ribeiro da Silva wrote: > Hi everyone, > > I'm trying to fix some translations in transifex but I'm waiting for 3 days > since I requested to join the pt-br group. I've just accepted you there (with my Transifex the Django project admin hat.) -- Ramiro Morales @ramiromorales -- 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/CAO7PdF_6rwNWFTh6rpJw9MzvFuCxMN5i5WVW0AHpbaa6eX8uOQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: py2exe + Django 1.6
On Thu, Apr 10, 2014 at 7:13 AM, Antonio Francisco Martín Romero wrote: > Hi everyone, > > I was using py2exe + Django 1.3 without problems This post doesn't belong to this list. django-dev is exclusively for discussions about development _of_ Django. Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF-_YsDzxhLbo7ZtRQCALWD0im%2BQs0YUU%2BF8oH-_Wj_3Xw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal for prepared statements API
On Thu, Mar 27, 2014 at 5:11 AM, VernonCole wrote: > There was a recent query about prepared statements on the db-sig mailing > list, too. Apparently thought is being given to adding such functionality to > Psycopg. This thread on the psycopg mailing list (and the linked, older discussion and article) of the status might be of interest regarding the status of PS support in such DB-API driver: http://www.postgresql.org/message-id/20140314184216.gb3...@fetter.org -- Ramiro Morales @ramiromorales -- 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/CAO7PdF9ncUrfaF4mLAZEozj%3D1PREKUTd4FmhANv2OdWGq7B-9g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: LiveServerTestCase vs StaticLiveServerCase
On Sat, Mar 29, 2014 at 1:26 PM, Harry Percival wrote: > > [...] > > But I just wanted to express the fact that it feels a little > counter-intuitive. I don't know enough to weigh how important it is to > remove a dependency on a contrib app from the testcases framework, but, as a > user, having to remember that i need to run `collectstatic` before all my > tests will pass is a bit weird. collectstatic is something i do on servers, > not on my local dev box. and LiveServerTestCase isn't much use without > working static files. Are you saying that you need to run collectstatic before all your tests when you make your test cases inherit from StaticLiveServerCase instead of LiveServerTestCase?. Because if so, that's a bug I'd need to fix because that's not the intended behavior and I'm the one behind this change. Or are you saying that you don't want to bother to edit your tests code to replace StaticLiveServerCase with LiveServerTestCase as part of your migration to 1.7? Regards, -- Ramiro Morales @ramiromorales -- 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/CAO7PdF9xTf7rtLtemaSHUXeX8eqc7oR7wD-%3DZyL9LedjQ7ZxRA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Enforce the use of a unicode string in settings.LANGUAGES
On Wed, Jan 22, 2014 at 1:12 PM, Henrique Romano wrote:
>
> That was just an example, ugettext_* returns a functional.proxy, which
> doesn't try to render the string when you print it on the screen, but if you
> try to do it you will see the same result.
You are right.
On Wed, Jan 22, 2014 at 1:58 PM, Henrique Romano wrote:
>
> On Wed, Jan 22, 2014 at 2:38 PM, Shai Berger wrote:
>> You might want to take this up with django-cms.
>
> Not exactly true. Even though my problem was with django-cms, if you grep
> django source code for "LANGUAGES" you will find this templatetag:
>
> # templatetags/i18n.py
> 15 class GetAvailableLanguagesNode(Node):
> 16 def __init__(self, variable):
> 17 self.variable = variable
> 18
> 19 def render(self, context):
> 20 from django.conf import settings
> 21 context[self.variable] = [(k, translation.ugettext(v)) for k, v
> in settings.LANGUAGES]
> 22 return ''
>
> It is also translating the given language name.
Yes, I think that what both pieces of code are doing there is assume
the LANGUAGES setting in effect is the one shipped with Django where:
- All the original language names are in English (covered by ASCII)
- Most of them are translated by the Django translators and shipped
with Django
(https://github.com/django/django/blob/master/django/conf/locale/en/LC_MESSAGES/django.po#L16)
so translations are readily available.
So it's relying on the fact there there is no need to go outside ASCII
when working with original language names.
I think you are onto something re: the fact that we don't make clear
that our ugettext*() functions fail to accept encoded literals with
characters outside ASCII under Python 2.x. even when the encoding
metadata is correct.
My theory is that the facts that documentation is a bit unclear about
the requirements these source strings arguments should comply with (or
rather, what are the data types supported by these functions) and that
using another language than English as translate-from language doesn't
seem like a common setup have contributed to this not getting too much
visibility until now.
In Python 3 (3.3) this problem doesn seem to exist. See tests below.
> My suggestion is to update the documentation saying that the developer should
> use ugettext_lazy for the language name if they want it translated
We have something along these lines. See (last two bullets)
https://docs.djangoproject.com/en/1.6/topics/i18n/translation/#how-django-discovers-language-preference
> *or* at least use a unicode string.
I will try to get some feedback from some more experienced devs to if
there is anything to be done about this in code and/or docs.
$ cat a.py
# -*- coding: utf-8 -*-
import sys
from django.utils.translation import ugettext, ugettext_lazy, ugettext_noop
print("Python version: %s" % sys.version)
a = ugettext_noop("Portugués")
print(a)
print(type(a))
b = u'%s' % a # try to get the lazy placeholder to evaluate itself.
print(b)
print(type(b))
$ file a.py
a.py: Python script, UTF-8 Unicode text executable
PYTHONPATH=.:~/django/upstream
DJANGO_SETTINGS_MODULE=lang_i18n.settings python a.py
Python version: 2.7.3 (default, Sep 26 2013, 20:03:06)
[GCC 4.6.3]
Portugués
Traceback (most recent call last):
File "a.py", line 12, in
b = u'%s' % a # try to get the lazy placeholder to evaluate isself.
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
7: ordinal not in range(128)
$ PYTHONPATH=.:~/django/upstream
DJANGO_SETTINGS_MODULE=lang_i18n.settings python3.3 a.py
Python version: 3.3.3 (default, Dec 27 2013, 19:27:19)
[GCC 4.6.3]
Portugués
Portugués
Thanks!
--
Ramiro Morales
@ramiromorales
--
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/CAO7PdF_9%3Dxp0SCkwzmM-rRDTE7X4Yn_UhDaFUuecKSw29jXXZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Enforce the use of a unicode string in settings.LANGUAGES
On Wed, Jan 22, 2014 at 10:59 AM, Henrique Romano wrote:
> On Wed, Jan 22, 2014 at 11:38 AM, gilberto dos santos alves <
> gsa...@gmail.com> wrote:
>
>> please look details about on [1]. if you put
>>
>> # -*- coding: utf-8 -*- on sources and config files for django your string
>> "português" will be automatically handled.
>>
>>
> Can you just try what I reported? For example:
>
> $ cat ~/foofoo.py
> # -*- coding: utf-8 -*-
> from django.utils.translation import ugettext
>
> print ugettext("Português")
> $ python ~/foofoo.py
> Traceback (most recent call last):
> ...
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7:
> ordinal not in range(128)
>
> So, I'm not sure what you are talking about.
>
You aren't telling us all the story. there are many missing parts in your
description of the issue you are finding so far so I don't think it's right
to jump straight to the "As per the documentation, it is not clear that
you _must_ use a unicode string for the language name. ... What do you guys
think about making it clear that the user should always use an unicode
string for the LANGUAGES setting?" conclusion.
Some questions:
- What are you trying to do? Reducing the choics in the LANGUAGES setting?
Do you intend to translate them from Portuguese to other laguages?
- Why are you using gettext() at the module level? You should use
ugettext_lazy() or ugettex_noop()
- Why did you show us a python interactive session instead of a Python
soruce code file? How do you thing the interpreter can deduce the encoding
of a bare string in that case?
- Why in both cases are you using Django without are for setting up the
settings infrastructure first?
- Is the foofoo.py file are you (or rather you text editor) actually using
the utf-8 encoding?
You link to the development documentation but the tests I performed below
are against the latest 1.6.x stable branch code with Python 2.7.3 (another
piece of information you don't give us):
$ django-admin.py startproject lang_i18n
$ cd lang_i18n/
$ cat foofoo.py
# -*- coding: utf-8 -*-
from django.utils.translation import ugettext, ugettext_lazy, ugettext_noop
print(ugettext_lazy("Portugués"))
$ file foofoo.py
foofoo.py: Python script, UTF-8 Unicode text executable
ramiro@mang:~/dtest/lang_i18n$ DJANGO_SETTINGS_MODULE=lang_i18n.settings
python foofoo.py
So the (lazy) translation machinery is working.
--
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/CAO7PdF9NgfG35MvJ5X24M7cSb%3DuOmZLkgkR9250DuT7ESCZO%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Django doesn't give any feedback if it cannot connect to a DB
On Fri, Jan 10, 2014 at 7:12 PM, Glyn Jackson wrote: > Correction, I run the test again, it does time out: > > OperationalError: (2003, "Can't connect to MySQL server on > 'x.rds.amazonaws.com' (60)") > > It just takes a very long time to do so. I haven't tried this myself but in theory you can set a connection timeout by combining the following functionality: 1. Django passes any value you specifiy in an OPTIONS dict for the DB connection description in the DATABASES setting to the connect() call of the MySQLdb low-level driver. This is documented: https://docs.djangoproject.com/en/1.6/ref/databases/#connecting-to-the-database 2. One of the options such driver provides is 'connect_timeout' (see http://mysql-python.sourceforge.net/MySQLdb.html#functions-and-attributes) I suspect that timeout value can also be specified in a peer DB, user or global MySQL configuration file. HTH -- Ramiro Morales @ramiromorales -- 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/CAO7PdF-WkfprsmE7tRQr9p4jjonaHTx1%3DNuiwY6D4qbqPrcK%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: LiveServerTestCase, and override_settings(DEBUG=True)
On Wed, Dec 18, 2013 at 12:57 PM, Harry Percival wrote: > Django's test runner overrides your settings to force DEBUG to be True, > which I understand the intention behind, but it is occasionally annoying. > One solution for those cases is to use `override_settings`, but that has > very weird effects when using `LiveServerTestCase`. What version of Django are you using? -- Ramiro Morales @ramiromorales -- 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/CAO7PdF8baK65P2%2BZnD21mWD_tKtK5TvX1NVUWYs2WOOt7hFfYQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Strange crash with ugettext_lazy when accent letter
On Mon, Dec 16, 2013 at 11:19 AM, Bastien Sevajol
wrote:
> Hi,
>
> I want ask to this mailing list before open bug issue on code.django.
> When use ugettext_lazy with accent like "â" some strange behaviour happens.
> Exemple:
>
>> # -*- coding: utf-8 -*-
>> from django.db import models
>>
>> from django.utils.translation import ugettext_lazy as _
>>
>> class MyModel(models.Model):
>>
>> name = models.CharField(_(u"name"), max_length=80)
>> type = models.CharField(max_length=1,
>> choices=(('a', 'â'), ('b', 'b')),
You aren't using ugettext_lazy with accent like "â" al all here.
--
Ramiro Morales
@ramiromorales
--
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/CAO7PdF_3eVehj64H6_9FmFMkkTS5d%2BecEhyk-45dCG2CkB-uLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: mod_python support
If it implements WSGI then there is no need to add or modify anything from the Django side. Both should be able to talk to each other using that protocol. Now that specs like WSGI exist there is no point in going back one decade implementing interfaces to cater for one particular web server integration implementation. Ramiro Morales @ramiromorales On Nov 25, 2013 1:36 PM, "Kamil Gałuszka" wrote: > Hi ! > > I wanted to post this in old topic from 2010 but Google always gives me an > error on posting so I can't do that there. (soory for that!) > > I know that mod_python support was dropped long time ago but I think this > information should be noted to core developers. There is new release of > mod_python that support WSGI and is adding Python 3. Maybe we should > reconsider adding it to django (only documentation I think since if it has > WSGI support we maybe don't need do anything more. But I'm not sure so I > could be wrong.)? > > Here is WSGI handler to mod_python: > http://modpython.org/live/current/doc-html/handlers.html#wsgi-handler > > New version was released 13 November http://modpython.org/. I think > someone started refactoring old mod_python and moved project to github. > > Cheers > Kamil Gałuszka > > > > -- > 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/cea5e59a-42a7-4084-91ab-8759da7d2f1d%40googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/CAO7PdF-_3ydN7q5uoZ_rVvgVT6egcwk63D7udn2LXBZhqwkciw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Unit tests error out with WinError 10013 in my Windows 7 machine with Python 3.3.2
If you update your git clone these Windows-specific extra errors and failures shouldn't be there anymore either. Please report back if that isn't the case. Ramiro Morales @ramiromorales On Oct 30, 2013 10:12 AM, "Antony J" wrote: > Sam, Marc, > > Thank you for your responses. Sorry I could not get back on this sooner. > > I ran the command “netstat -anob | findstr 8081” and found that the McAfee > framework service was listening in port 8081. > After killing the frameworkservice.exe, the errors went away. > > However, there still are 2 failures and the UnicodeDecodeError. > I am going to investigate them more, because the Django documentation > states that all tests should pass. > > Thank you for your help. I will get back with more info on the 2 failures > soon. > > Regards, > Antony > > > On Friday, October 25, 2013 10:05:30 AM UTC+5:30, Marc Tamlyn wrote: >> >> As this is about running the Django teat suite in order to try to write a >> patch it does belong on this mailing list. >> >> I don't have any concrete ideas what's wrong - but it does look like all >> your issues are related to running the LiveServer (selenium) tests. >> Something bound to a certain port already is likely the culprit, or some >> sort of version mismatch. Is your code running in a virtual python >> environment? I don't like selenium tests should run by default so of you >> set yourself up a virtualenv where selenium isn't installed but your Django >> checkout is then you shouldn't get these tests running. This may be the >> difference Sam was seeing. >> >> In any case, if the patch you were looking to write is not related to >> this area of the tests, I suggest you try just running the tests on the >> area you know works (and your new tests) or ignoring the failures. >> >> Alternatively, spin up a Linux VM ;) >> >> Marc >> On 25 Oct 2013 00:18, "Sam Lai" wrote: >> >>> Do you have anything running on port 8081 (running netstat will tell >>> you)? >>> >>> I just ran Django's test suite on my machine (Windows 7, Python >>> 3.3.2), from the trunk cloned an hour ago, and it completed mostly >>> without an issue (there's a UnicodeDecodeError but that's likely >>> because it's printing a character to stdout that isn't supported by >>> the Windows console codepage). >>> >>> Can you move this discussion over to django-users (just post your >>> reply with the rest of the email chain over there)? I don't think it's >>> an issue with Django itself. >>> >>> -- > 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/d90610d8-afd9-4958-a225-de21b1ee1e76%40googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/CAO7PdF-J6uc_bFUV0aCMLPjQgHHY25eMd-wu2PHUSVYoG%3D%3D6zQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Creating a minimal custom user model. Seems last_login is required. Should it be?
On Sun, Oct 20, 2013 at 7:25 PM, Harry Percival wrote: > I'm trying to create a minimal custom user model. The only thing I care > about is email. But it seems Django really wants me to set a last_login > field. Can I avoid it somehow? Thhis has been asked/discussed a couple of times since introduction of the custom user feature. Please see e.g. https://groups.google.com/forum/#!msg/django-users/tSzYy8liFRQ/i6dcJh4dBSoJ -- Ramiro Morales @ramiromorales -- 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/CAO7PdF9FHCOBUooFvpsKGtdN4ac18O_AT%3DQdPfWdh3oEr5SaRQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Oracle broken on 1.6
Shai, On Fri, Oct 4, 2013 at 12:43 PM, Shai Berger wrote: > Hi, > > It looks like the fix to #21165[1] broke the tests on Oracle (seems like the > behavior with respect to timezone information changed) in 1.6.X. I just saw > the Jenkins report[2], I hope to look at it later tonight. > > Thanks, > Shai. > > [1] https://github.com/django/django/commit/5252885494079cf28a337644a87e61b19340f09c > [2]http://ci.djangoproject.com/job/Django%20Oracle/246/ > Oops, I'm the committer of that one. That particular commit only touches a test unrelated to the ones failing (and makes it use some test decorator infrastructure added [1]recently to solve failures on Windows). Plus, the additions made don't look like something that would leak some kind of state that could explain the observed failures. >From what I can gather from the Jenkins UI most of the last Oracle 1.6.x builds have been extremely unstable, some of them even didn't start. I suspect the failures started with some older commit but only appeared now. But I'm also aware anything is possible in the Land of the Oracle when the magic of Time Zone Spells are involved, so don't quote me on the above affirmation. Please feel free to contact me via IRC (nick: cramm) if you think I can be of any help debugging and solving these issues. -- Ramiro Morales @ramiromorales 1. https://github.com/django/django/commit/5b97b99a014443b255cf8ab0467864c5874027da -- 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/CAO7PdF_rdvw3kfj%3D9-zMRJxhBQqUh3rh-kL10-00uCoijxDJLA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Converting (session, CSRF-protection, language) cookie settings to dicts
I've opened ticked [1]21051 and PR [2]1554 This would help with ticket [2]#15381 that asks for the ability to tweak domain and expires of the language cookie By allowing to provide that kind of configurability without introducing more top-level settings and some other similar efforts. Alternatively, the dictionary keys could be replaced with lowercased versions that mimic the names of the stdlib [4]Morsel object atributes. I can implement this change if necessary. One slightly topic is the one of the deprecation warnings shown to the developer. The strategy implemented currently in the PR is to show PendingDeprecationWarnings when one of the old settings is used in a settings file. There is the possibility to also shown them when the old settings are accessed (coomented out implementation BaseSettings.__getattribute__ method code and a test case) but I deemed it potentially too noisy. PR includes tests and docs changes. Any feedback is welcome. Regards, 1. https://code.djangoproject.com/ticket/21051 2. https://github.com/django/django/pull/1554 3. https://code.djangoproject.com/ticket/15318 4. http://docs.python.org/2/library/cookie.html#morsel-objects -- Ramiro Morales @ramiromorales -- 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: Silencing deprecation warnings in the test suite
On Mon, Sep 2, 2013 at 8:08 AM, Aymeric Augustin wrote: > Hello, > > When a feature is deprecated, it raises a PendingDeprecationWarning, either > at import time or at run time. After the following release it raises > DeprecationWarning. Assuming we have a good test coverage, these warnings > will be shown by the test suite, with -Wall for PendingDeprecationWarning, by > default for DeprecationWarning. This is annoying. The output of the test > suite should remain clean. > > Unfortunately, I've noticed that we often forget to silence warnings when we > deprecate a feature. For instance, right new, the test suite raises warnings > related to custom SQL, syncdb, and SortedDict (with -Wall). If you committed > one of these deprecations, would you mind silencing the > PendingDeprecationWarnings in the tests? > > There are two ways to achieve that: > [...] Thanks Aymeric for raising awareness about the problem and the compact action item description. I plan to propose some changes that involve a deprecation cycle and had some vague recollection about an email or ticket about the same issue by Carl but had been unable to find it. Your mail made me search again and luckily this time I could find it: https://code.djangoproject.com/ticket/17049 -- Fortunately, the recommended solution there is in the same spirit as yours. A result of that ticket is the fact that our CI setup uses -Wall so we can see these warnings at the console output of every configuration e.g.: http://ci.djangoproject.com/job/Django/database=postgres,python=python3.3/lastBuild/console Regards, -- Ramiro Morales @ramiromorales -- 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: #20739 - Making LiveServerTestCase not depend on staticfiles?
On Tue, Aug 13, 2013 at 8:01 PM, Ramiro Morales wrote: > > Guys, I've updated the PR with further work on this: > > https://github.com/django/django/pull/1354 FYI This has landed on master with commit: https://github.com/django/django/commit/e909ceae9b3e72b72e0a2baaa92bba9714f18cd2 Regards, -- Ramiro Morales @ramiromorales -- 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: #20739 - Making LiveServerTestCase not depend on staticfiles?
On Mon, Jul 15, 2013 at 1:16 PM, Ramiro Morales wrote: > [...] > > I will be working further on the PR keeping all this design advice in > mind. Guys, I've updated the PR with further work on this: https://github.com/django/django/pull/1354 Any feedback is welcome. Thanks, -- Ramiro Morales @ramiromorales -- 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: Order of INSTALLED_APPS
On Mon, Aug 12, 2013 at 9:59 AM, Aymeric Augustin wrote: > 2013/8/12 Stefano Crosta > >> There is one situation where the order of INSTALLED_APPS really matters - >> which is template override. > > > There are at least two other similar cases: translations and static files. > >> >> Though not officially documented (?) I've found references in the mailing >> list to the fact that APPS coming first in the INSTALLED_APPS will have >> priority - their templates will be loaded effectivily overriding/shadowing >> lower priority app ones. > > > Yes, we should standardize and document that. For translations, we have such documentation already: https://docs.djangoproject.com/en/1.5/topics/i18n/translation/#how-django-discovers-translations -- Ramiro Morales @ramiromorales -- 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: Avoid unbounded memory consumption when running `manage.py test`
On Fri, Jul 26, 2013 at 11:03 AM, Matt McClure wrote: > TestSuite holds references to each TestCase instance. So attributes of my > TestCase subclasses don't get freed by the garbage collector until the last > reference to TestSuite disappears, which isn't until the entire test run > ends. In a large test suite, the test run exhausts memory and the OS kills > it before the suite finishes. > > The most obvious solution to me is to put tearDown methods in all my > TestCase subclasses that delete the references to their own attributes. But > it seems like there has to be a more general, automatic solution. I can > start to answer my own question. But I'm interested to know if others run > into similar problems and how you solve them. > > It looks like there are at least two participants that hold TestCase > references longer than desirable. > > 1. TestSuite. Here's a minimal hack to release the reference that TestSuite > would otherwise hold after a TestCase runs until the remainder of the suite > had finished. > > diff --git a/django/utils/unittest/suite.py b/django/utils/unittest/suite.py django.utils.unittest is a copy of the Python>= 2.7 stdlib unittest library (aka unittest2) Looking at the list of classes involved in your description seems to indicate you might want to report your findings to the upstream maintainers. That way if it's actually confirmed as an issue, the solution will benefit much more people than people doing testing in Django. Regards, -- Ramiro Morales @ramiromorales -- 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: Deprecate FCGI support in Django 1.7
On Mon, Jul 15, 2013 at 6:45 PM, Jacob Kaplan-Moss wrote: > > Let's start FCGI (and the others) down the path to deprecation. If there's > truly a community that finds value in these things -- and frankly I think > that once they try modern options they'll quickly switch and never look back > -- then let them maintain the code. Coincidentally, Juan Luis Boya has just attached a [1]patch to ticket #20751. It includes an initial FastCGI testing infrastructure that could be of help to the maintainers of any project that result of this discussion. -- Ramiro Morales @ramiromorales 1. https://code.djangoproject.com/attachment/ticket/20751/0001-socketumask-argument-for-runfcgi-tests.patch -- 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: Django runfcgi umask: what is it meant to do and why?
On Mon, Jul 15, 2013 at 3:02 PM, Juan Luis Boya wrote: > I've posted a patch for runfcgi here: > > https://code.djangoproject.com/ticket/20751 > > It includes documentation update and unit tests, for anyone interested, if > any. Juan Luis, This is all great work. Thank you very much for it. There are some new in the fastCGI front: https://groups.google.com/forum/?hl=en#!topic/django-developers/oGmD8LvLTPg I will make sure your work isn't wasted and ends in the FastCGI dapter code whatever that means (external community maintained project or project under Django umbrella) Regards, -- Ramiro Morales @ramiromorales -- 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: #20739 - Making LiveServerTestCase not depend on staticfiles?
Hi Jannis, Thanks for your reply, On Sun, Jul 14, 2013 at 10:16 AM, Jannis Leidel wrote: > > I'm pretty sure we don't want to increase the code that deals with > serving files. We've repeatedly improved the documentation about > helping users to configure their web server to serve the files instead > of adding an official file serving WSGI middleware like you propose > here. Especially since we already provide a view in > django.views.static to serve files I think we need to clarify what the > purpose of the FSFilesHandler would be. If there is little good reason > (e.g. only supporting LiveServerTestCase) then we **shouldn't** make > the FSFilesHandler a new core component but just a implementation > detail. It would support it and the staticfiles handler but I agree with you on that we should not be shipping something like FSFilesHandler or at least should move it near where it's used and/or marking/documenting it as internal. > >> Another change introduced is duplicating (simplifying it slightly) >> django.contrib.staticfiles.views.serve() view functionality. > > Where was that duplicated specifically? Couldn't find it in the pull request. Ah yes, sorry for not making the PR more granular commit-wise. This is the staticfiles serve() view: https://github.com/django/django/blob/master/django/contrib/staticfiles/views.py#L20 and this is the new, albeit simplified, duplicate copy: https://github.com/django/django/pull/1354/files#L3R1072 > >> The last stumbling block we need to remove is use of staticfiles' >> finders infrastructure, for which I don't have any solution for now. > > Maybe the LiveServerTestCase should simply have a generic file serving > feature, basically just using the core static view to serve > STATIC_ROOT under STATIC_URL. > > Users that want to continue using staticfiles we could ask to call > collectstatic in a setUpClass method in their LiveServerTestCase > subclasses. Or just ask them to run it before running the tests. > > [...] I think decoupling the file serving slightly from how the files > got to the place they are served from, is a good first step. The > common denominator between the core ability to serve files and > staticfiles is the reliance on conventions like STATIC_ROOT and > STATIC_URL. If we can backscale LiveServerTestCase to only do the core > ability out of the box and document the way to do it the staticfiles > way, then I think we're on the right track. I will be working further on the PR keeping all this design advice in mind. Thanks again, > > Jannis > -- Ramiro Morales @ramiromorales -- 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: Spam on ticket #542
On Sun, Jul 14, 2013 at 12:23 PM, Aymeric Augustin wrote: > Hello, > > For some reason, ticket #542 has been collecting spam comments that bypassed > Trac's antispam. Since receiving spam on django-updates and deleting it > manually gets tedious after 100 messages, I hacked Trac to prevent further > comments on this ticket. > > I'm positive that Trac's antispam works in general: the monitoring views > shows that it fends off over 200 spams every day. However, these comments > weren't blocked and they don't appear in the monitoring view. I can't explain > that. Please contact me privately if you can help! Thanks for that, I myself deleted 10+ such comments and was starting to feel like the the dumb side of the battle because the spammer side most surely was a script :) This is what I found: * Feeding the comments contents to our Trac instance Bayes anti-spam component test form says it would be effectively be identified as spam with a 100% confidence score. * Strangely enough, looking at the anti-spam monitoring log, there is no trace of these attempts (what would mean it isn't even detected as a comment worth being analyzed in search of spam), but I saewat least another attempt by another spammer being successfully rejected. Would it be worth look at the web server log to see if these comments were effectively created by HTTP POST requests at all? Thanks, -- Ramiro Morales @ramiromorales -- 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.
#20739 - Making LiveServerTestCase not depend on staticfiles?
Hi all, Ticket [1]8713 is tracking removing dependency of Django core on contrib apps code. One of the action items enumerated there is the fact that LiveServerTestCase makes use of django.contrib.staticfiles' facilities. I've opened ticket [2]20739 for it and have some work in progress on a [3]PR. What I've done so far is move some base functionality of staticfiles' StaticFilesHandler to a new FSFilesHandler that lives in django.core.handlers and make both StaticFilesHandler and a new ad-hoc, private _StaticFilesHandler located in django/test/testcases.py (similar to the existing _MediaFilesHandler) inherit from it. Another change introduced is duplicating (simplifying it slightly) django.contrib.staticfiles.views.serve() view functionality. The last stumbling block we need to remove is use of staticfiles' finders infrastructure, for which I don't have any solution for now. I'm posting this here to get feedback/help on the approach and more generally to know your opinions about if the dependency removal is worth pursuing because, frankly, moving contrib.* code to the core and duplicating functionality smells a little bit funny to me. Regards, -- Ramiro Morales @ramiromorales 1. https://code.djangoproject.com/ticket/8713#comment:13 2. https://code.djangoproject.com/ticket/20739 3. https://github.com/django/django/pull/1354 -- 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: Limitation for Named Urls for reverse url resolve.
On Fri, Jul 12, 2013 at 1:27 PM, Sergio Pulgarín
wrote:
>
> In Django 1.5.1 I have a named url like this:
>
> url(r'confirm/', 'confirm_user', name='auth-confirm-user'),
>
> which gave me this error when I tried to using reverse, from
> django.core.urlresolvers, on it:
>
> NoReverseMatch at /auth/signup/
>
> Reverse for 'auth-confirm-user' with arguments '()' and keyword arguments
> '{}' not found.
>
>
> When I changed it to: name='auth-confirm', reverse worked.
>
>
> Is this by design? I couldn't find any reference to this
> on the documentation.
You don't give us any context but it seems the views and named URLs involved
are from your application and not provided by any of the applications shipped
with Django.
So I'd suggest to
a) Post to the -users mailing list. This list is for discussion about
the development
of Django itself, not for support in discovering if there is a bug
in your app or Django.
b) Post more details like:
- Do you have another URL named 'auth-confirm'?
- Do you have more than one one URL called 'auth-confirm-user'?
- Do the arguments you are passing to the view match the ones it expects?
--
Ramiro Morales
@ramiromorales
--
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: Django runfcgi umask: what is it meant to do and why?
On Sat, Jun 29, 2013 at 9:56 PM, Juan Luis Boya wrote: > > When daemonize=false, it will set the umask for Django child > processes, effectively changing default permissions for newly created > files, including the socket. When daemonize=true, it will do nothing. Hrm no. It's exactly the opposite. > > What sense makes that? Is there any case in where I would like my > Django process umask to be different when I run it in the background > than when I run it on the foreground? I can't think of any. Is there > even any logical reason for the default umask for new files setting to > be a runfcgi argument? > > On the other hand, I feel a flagrant miss: I need to set the > permission mask just for my socket, not for other files. I want my web > server being run as a different user and I want it to be able to write > on the socket, but not to overwrite uploaded files, for example. I am > not entirely alone. There are questions like this in StackOverflow > [1], in this list [2], in the IRC logs [3] and I would bet there is > many people suffering it in silence. This is ticket #14958. I think there is value in having the ability to set both the umask of the forked process to control the permission mode of files/dirs created (and so not use the umask of the parent, launching process) as it is already possible and the umask of the Unix socket used to communicate with the FastCGI-speaking web server as proposed, using the facility provided by Flup. FastCGI-related reports are scarce and contributions are almost non-existent which IMHO seems to indicate it isn't a widely used deployment technique. You seem to have experience with it and to have a test setup so if you can fix/update (complete with documentation additions and corrections, a lot of bonus points if you can figure a way to write some tests,-)), and try the associated patch then the ticket can reach a status in which it's ready to be applied. On Sun, Jun 30, 2013 at 12:11 PM, Juan Luis Boya wrote: > They talk about there was a os.umask(0) and they created that option > in order to change it. > >But I would like to know then, why was that `os.umask(0)` there in the >first place? What was it purpose? Seems like some code history research work similar to the one suggested by Karen is in order if you really want to understand the original motivations. > On the other hand there is the confusion this option brings. Many > people think the option is intended to set the socket umask. Just in > that bug report there is a user saying "umask=0111 creates a socket > with umask...". That particular comment is talking about another issue that has been fixed (the pased umask value was interpreted incorrectly.) Regards, -- Ramiro Morales @ramiromorales -- 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: Ticket #9321 -- Modelform widgets help text for ManyToMany fields
On Sat, May 18, 2013 at 11:38 PM, Ramiro Morales wrote: > Hi all, > > This is a proposal for fixing this small and old issue > (https://code.djangoproject.com/ticket/9321): > > [...] > > Django 1.7: > Simply stop forcing the hard-coded sentence. If users want to have it > set or added to their help text they should provide it by themselves > just like it happens with every other [model] form field. > These users are in a better position to know if it is relevant to the form > widget in use. > > This deprecation cycle won't be implemented using > [Pending]DeprecationWarning's, but rather by only documentation. The > release notes and backward incompatible timeline entry for 1.6 would > warn about the changes coming in 1.7 so they can act in advance. > > [...] > > Also, WIP PR: > https://github.com/ramiro/django/compare/master...9321-m2m-help_text > (only piece missing is the warnings described in the last two paragraphs.) I've updated the branch to add such documentation warnings. Also, changed the timeline to extend over two release cycles (1.6 - 1.8) instead of accelerating it to finish in 1.7. I've also created a second branch with the changes that would need to be performed before releasing 1.8: https://github.com/ramiro/django/compare/9321-m2m-help_text...9321-m2m-help_text-post-1.6 Apps now need to take care of the help text, the admin app is one of them and so does this patch by moving the logic there. Note how tests that check the HTML output of modelforms for models with m2m fields don't need to contain the non-relevant help text markup anymore. Regards, -- Ramiro Morales @ramiromorales -- 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.
Ticket #9321 -- Modelform widgets help text for ManyToMany fields
Hi all, This is a proposal for fixing this small and old issue (https://code.djangoproject.com/ticket/9321): Model forms for models that include a ManyToMany field get a hard-coded "*Hold down "Control", or "Command" on a Mac, to select more than one." sentence in the respective help text This sentence can be either: a) Forced as the HTML field help text if the user didn't provide a help_text or b) Appended to the user's one. Emphasis should be put on the fact that this only affects: * Model forms * ...for models with at least one m2m field * ...for which custom form fields/widgets are being used where the user interaction doesn't actually involve using a visual selection expandable by mouse click and key presses combinations. Or designs where the developer simply doesn't want that string appearing on their form at all. The proposed fix is somewhat simple (I'd say trivial) compared to the ones proposed so far and has the following implementation timeline: Django 1.6: Stop hard-coding this at the model level. Still do that at the form field level (ModelMultipleChoiceField) but only for field instances that are paired to a (subclass of) SelecMultiple widget. This has the net effect that we stop forcing the hard-coded string on every kind of form field for m2ms (the main complaint and the actual fix of the issue at hand). This could impact custom m2m field form fields/widgets that don't inherit from SelectMultiple with a previously unannounced backward-incompatible change if they rely on the help_text munging performed by the ORM field, but OTOH would keep the greater audience (those who use the default widgets or use a subclass of SelectMultiple for which the hard-coded help text is relevant/useful e.g. the admin) safe by not changing anything at all for them. Django 1.7: Simply stop forcing the hard-coded sentence. If users want to have it set or added to their help text they should provide it by themselves just like it happens with every other [model] form field. These users are in a better position to know if it is relevant to the form widget in use. This deprecation cycle won't be implemented using [Pending]DeprecationWarning's, but rather by only documentation. The release notes and backward incompatible timeline entry for 1.6 would warn about the changes coming in 1.7 so they can act in advance. Reasoning for this is that we would be forced to detect field/widget subclassing to be able to catch the cases where warnings should be triggered and these warnings could get noisy fast. IMHO this isn't worth the trouble. What do you think? Also, WIP PR: https://github.com/ramiro/django/compare/master...9321-m2m-help_text (only piece missing is the warnings described in the last two paragraphs.) -- Ramiro Morales @ramiromorales -- 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
On Thu, Mar 28, 2013 at 1:34 PM, Yo-Yo Ma wrote: > 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"? Doing what? > 2) What is the policy or lag time for getting commits such as the > aforementioned bug-fix into these stable branches? That kind of fixes aren't ported to the stable branches. See https://docs.djangoproject.com/en/1.5/internals/release-process/#supported-versions > 3) Are there docs for this, and if not, should there be an entry on > https://docs.djangoproject.com/en/dev/faq/install/? Sound like a dood idea. We could add at least a link there. -- Ramiro Morales @ramiromorales -- 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: What can I do to get feedback on my pull request?
On Tue, Mar 26, 2013 at 12:36 AM, meric wrote: > Thanks, I'll reply to that thread. I posted my proposal 6 months before that > post, would've been nice if they posted in my thread... Jacob voted in favor of the feature (on the #16774 [1]ticket) and Adrian voted -1 on that thread. But they were unaware of the existence of the ticket. 1. https://code.djangoproject.com/ticket/16774 -- Ramiro Morales @ramiromorales -- 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: What can I do to get feedback on my pull request?
On Tue, Mar 26, 2013 at 12:28 AM, meric wrote: > I have made a pull request for django 6 months ago, but it doesn't seem to > be getting much response so far. > > What can I do to get more feedback as to what's wrong with it, and try to > get it accepted? > > Here is the pull request: > > https://github.com/django/django/pull/378 Isn't it the same idea proposed (and rejected) in this thread?: https://groups.google.com/forum/?fromgroups=#!topic/django-developers/64I3Qy4OH-A -- Ramiro Morales @ramiromorales -- 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: Proposal: move non-db tests out of TransactionTestCase
On Thu, Mar 7, 2013 at 5:32 PM, zalew wrote: > fall back to SimpleTestCase (which > TransactionTestCase inherits from), but this class doesn't contain useful > test helpers, which aren't in any way related to db handling: > > * assertRedirects > * assert(Not)Contains > * assertFormError > * assertTemplate(Not)Used > * _urlconf_setup(teardown). > > Is there a reason why these functions were bound to a transaction handling > test class instead of SimpleTestCase? > > My proposal is to move them out either to SimpleTestCase, or a separate > class other tests (including TransactionTestCase) can inherit from. I have > experimentally written a SimpleTestCase based class for my needs, but I > haven't yet tested it against the Django suite. > > What do you think? If you agree and/or have some ideas, I will submit an > issue and work on a patch proposal. We inserted [1]SimpleTestCase in the hierarchy relatively [2]recently (Django 1.4) and moved some functionality to it from its subclasses. But at that time I didn't even think about challenging the status quo and move all the non-DB related like you've just done. +1 to you proposal. Please open a ticket. This thread and the ticket should give the topic the visibility it needs to raise alarms if there is any backward compatibility involved. Thanks! 1. https://docs.djangoproject.com/en/1.5/topics/testing/overview/#django.test.SimpleTestCase 2. https://docs.djangoproject.com/en/1.5/releases/1.4/#minor-features -- Ramiro Morales @ramiromorales -- 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: Proposal: Django Admin Site and "pretty" app name
On Fri, Dec 7, 2012 at 11:18 AM, Aymeric Augustin wrote: > FYI the latest efforts on this topic are here: > https://github.com/ptone/django/compare/app-loading > http://code.djangoproject.com/ticket/3591 Exactly, The issue described in this thread is already reported as ticket [1]10436. The fix for it depends on 3591[2] wich should introduce first class app entities that could carry this and other meta-data. Please read the story of the former ticket for more details. -- Ramiro Morales 1. https://code.djangoproject.com/ticket/10436 2. https://code.djangoproject.com/ticket/3591 -- 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: Possible bug in django oracle backend - no way to map from model type to oracle NUMBER type.
On Wed, Oct 17, 2012 at 7:26 AM, Michał Nowotka wrote: > Currently I'm working with some oracle legacy db which I would like to > access using django ORM. > I have a column of type NUMERIC (without precision and scale) and all > possible values are kept there (for example, 65, 2.3, 0.5) > After running inspectdb django suggested that this column should be of type > models.DecimalField(unique= True, null=True, max_digits=0, > decimal_places=-127, blank=True) but this makes little sense since I'm > getting an error when trying to do syncdb from this model: > > Error: One or more models did not validate: DecimalFields require a > "decimal_places" attribute that is a non-negative integer. > DecimalFields require a "max_digits" attribute that is a positive integer. > > Do you know what type in model will map to NUMBER in oracle? This is a question for the django-users mailing list. django-dev is exclusively for the development OF Django not for development WITH Django. To answer your question. Take a look at this file frm the source code, it might be fo help: https://github.com/django/django/blob/master/django/db/backends/oracle/creation.py -- Ramiro Morales -- 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: Testing django 1.5 with firebirdsql
Hi Maxi, On Thu, Sep 13, 2012 at 8:20 PM, maxi wrote: > Hi, > > I'm testing Django 1.5 (branch:master) from trunk against FirebirdSQL 2.5 on > Ubuntu 11.04 with Python 2.7 > I'm working right now on a new django-firebird [1] backend which do use the > new python firebird driver (fdb) [2]. > > Then, I'm running the django test suite and I get an error when it try to > create serializers_regress_ > generice928. Seem like django is trying to create a table without fields, > like this: > > 'CREATE TABLE "SERIALIZERS_REGRESS_GENERICE928" ( );' > > And this is not valid on Firebird. > > What does it trying to test here? > Are there any way to avoid (or silence) this test ? > Where is defined this model? Hopefully the following leads will be of some help: As per the usual Dango policy for namign DB tables (i.e. prefixed by the app name and then the model name) it is clear the test app is serializers_regress. it its located in: tests/regression_tests/serializers_regress The Django test suite test apps are actually precisely that: Django apps. So something you can do is to transplant them to a pristine project (copying the app dir, adding it to INSTALLED_APPS, etc.). Once you have that you can perform any of the actions manage.py allows you to do with an app. With the advantage you have only that app and there is no noise from the massive Django test suite: For instance: * Running ./manage.py sql serializers_regress To see the DDL Django+your backend generates for the app models * Running ./manage.py test serializers_regress To run the tests, add -v2 to see the order in which the Django test machinery creates the model tables in the test DB. Now, looking at the 'GENERICE928' part of the table name, we have another hint, ist corresponds to a model whose name begins (case insensitively) with 'generic'. A quick perusing of serializers_regress.models shows there are a couple of them, and in particular there is this model:: class GenericIPAddressPKData(models.Model): data = models.GenericIPAddressField(primary_key=True) It has only one field, marked as the PK. Wild guess: Your backend's creation.py isn't generating the DB field corresponding to the (new in 1.4 IIRC) GenericIPAddressField field types i.e. is generating no DDL for it. And there is the origin of your no-fields-table DDL problem. HTH -- Ramiro Morales -- 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: Test reordering and TransactionTestCase cleanup
On Thu, Jul 19, 2012 at 8:32 PM, Ramiro Morales wrote: >> I ran the full test suite on SQLite, and got this error: >> == >> ERROR: test_pass_connection_between_threads >> (regressiontests.backends.tests.ThreadTests) >> -- >> Traceback (most recent call last): >> File "/home/akaariai/Programming/django/tests/regressiontests/ >> backends/tests.py", line 595, in test_pass_connection_between_threads >> self.assertTrue(isinstance(exceptions[0], DatabaseError)) >> IndexError: list index out of range >> >> I don't know if this is related to this patch or not. The error does >> not happen when running the backends test alone. This might be related >> to test ordering > > Exactly > [...] > Maybe we can fix the LiveServerTestCase so it doesn't leak the munging of > `allow_thread_sharing` it performs by resetting its value in its > classTearDown() method?. > Julien solved this precisely in that way, the fix got applied in: https://github.com/django/django/commit/ea667ee3aeed33bce1dd681d9c0ea42f9926db5a This hopefully completes the changes motivated by the feedback you provided. I intend to apply this patch in the next days, any further opinions is welcome. Regards, -- Ramiro Morales -- 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: Test reordering and TransactionTestCase cleanup
Anssi, Thanks for the review, On Tue, Jul 10, 2012 at 2:16 AM, Anssi Kääriäinen wrote: > > I spotted one error: > https://github.com/ramiro/django/compare/pr45_t18271#L7R472 - The > line should say conn.cursor(), not connection.cursor(). Fixed in the last iteration of the branch. > > I ran the full test suite on SQLite, and got this error: > == > ERROR: test_pass_connection_between_threads > (regressiontests.backends.tests.ThreadTests) > -- > Traceback (most recent call last): > File "/home/akaariai/Programming/django/tests/regressiontests/ > backends/tests.py", line 595, in test_pass_connection_between_threads > self.assertTrue(isinstance(exceptions[0], DatabaseError)) > IndexError: list index out of range > > I don't know if this is related to this patch or not. The error does > not happen when running the backends test alone. This might be related > to test ordering Exactly, this is what I've found is happening: The problems shows when you run together (minimal expression): A. Any test from the servers `regression` tests (that subclass TransactiontestCase via LiveServerTestCase) B. The test that is generating the error: A test from the `backends` regression tests (that subclass TestCase) e.g. runtests.py --settings=test_sqlite servers.LiveServerViews.test_404 backends.ThreadTests.test_pass_connection_between_threads For SQLite, memory-hosted databases, LiveServerTestCase sets main thread's 'default' DB connection's allow_thread_sharing to True. The `backends` tests: * Spawns a second helper thread * It clobbers this thread's connection with the main thread's one. * Both main and helper threads 'default' connections' allow_`thread_sharing` values are initialized or assumed be False and then the effects of such value are then verified. Currently, tests that subclass TestCase always run first so the order is always B before A and no problem occurs. Even when the main thread default connection `allow_thread_sharing` value state is preserved across test cases after all the LiveserverTestCase have finished. But when the patch is applied such order isn't guaranteed anymore (all the tests that inherit from unittest.TestCase are run intermixed w/o a defined orderiing.) The test discovery seems to always order them so A runs before B, the main thread connection allow_thread_sharing=True values survives, causes a condition that isn't expected by the B test and so the error occurs. Maybe we can fix the LiveServerTestCase so it doesn't leak the munging of `allow_thread_sharing` it performs by resetting its value in its classTearDown() method?. > > And a question: > This change in https://github.com/ramiro/django/compare/pr45_t18271#L9R502 > says that changing a TestCase to TransactionTestCase might solve some > errors caused by test ordering. I don't get why this is true. It was text I had moved from a spot below in the same document. It applied to the changes introduced in 1.1 and is actually inaccurate now. My fault, I've reworded it. Regards, -- Ramiro Morales -- 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: Test reordering and TransactionTestCase cleanup
On Mon, May 7, 2012 at 6:50 PM, Anssi Kääriäinen wrote: > > I would like to just get rid of the sequence resets. Oracle doesn't do > it currently, TestCase doesn't do it, and IMO assuming the IDs are > going to start from 1 is an assumption one should not make. > > Objections to just getting rid of the sequence resets altogether (with > the opt-in flag)? Hi all, Based on Andreas' work and discussion on this thread, I've: 1. If the user specifies the `reset_sequences` flag, what is performed during test case setup is actually that: A reset of DB sequences. There is no more flushing of tables. For this a method was added to DB backends DatabaseOperation classes. 2. Dropped resetting of sequences from the DB flush now performed during test case teardown code. For this, a stealth option was added to the `flush` management command. 3. Expanded and re-factored [related] documentation a bit. 1. and 2. mean that now: * Pre test case execution: There is no DB table flushing nor reset of sequences (the latter can be asked for the developer by using reset_sequences. * Post test case execution: Flushing of DB tables is performed. https://github.com/ramiro/django/compare/pr45_t18271 So far, I count two favorable from core devs: Karen and Anssi. Any further feedback about the proposed changes is welcome. Especially reports of results of people running their own test suites. I ran the Django test suite w/o against Postgres, MySQL and sqlite3 w/o problems. Hopefully I will be able to commit something along the lines soon. Regards, -- Ramiro Morales -- 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: Test reordering and TransactionTestCase cleanup
On Thu, May 3, 2012 at 1:29 PM, Andreas Pelme wrote: > I am trying to run my Django test suite with an alternative test runner > (py.test), and found some issues with test isolation. > > TransactionTestCase does currently not clean up after itself (i.e. flush the > database), but instead assumes that the next test will flush the database. > [...] > > Djangos default testrunner reorders the test suite to run all TestCase tests > before TransactionTestCases, which avoids this problem. Just a quick related note There is a [1]proposal to extend this reordering to be: * TestCases * doctests * TransactionTestCases So doctests aren't affected either. I intend to commit a fix for it soon. -- Ramiro Morales 1. https://code.djangoproject.com/ticket/12408 -- 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: startproject template context
On Tue, May 1, 2012 at 11:04 AM, Sam Simmons wrote: > For app/project templates I found the docs a little misleading when they say > 'Any option passed to the startapp command' will be added to the context. You' ve understood the documentation correctly. This is a feature that is currently (and AFAICT was DOA) not fully implemented because there is code to process and add the custom command line switches to the context but the validation that the management commands framework performs on the command line options isn't allowing them to pass. Please open a ticket in our issue tracker. Thanks. -- Ramiro Morales -- 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: Stop supporting MySQL < 5.0 in Django 1.5
Hi all, I've opened ticket [1]#18116 to track this cleanup change. This change would allow to close a handful of tickets about half-backed compatibility with deprecated MySQL 4.x. More specifically the commit would make Django trunk require MySQL 5.0.3 or newer. This will allow avoid a limitation on the length (<= 255) of char fields imposed by older MySQL versions. Opinions on the proposal and the respective patch are welcome. -- Ramiro Morales 1. https://code.djangoproject.com/ticket/18116#comment:7 -- 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 db library doesn't handle quoted table/field names
On Thu, Apr 12, 2012 at 9:14 PM, Craig Lucas wrote: > i actually didnt try the db_column attribute because I read about quoting it > before I started writing the code. But that wont solve the schema problem. > It will still try to create the index and fk constraints with the dots and > quotes around the table name. > > i believe it is required to quote the schema and table name in the db_table > property as '"dim"."Application"', if you left it as 'dim.Application' it > would create the table as 'dim.application' and if it quoted it it would > still be wrong as "dim.Application"...that will fail also > > On the schema question, yes adding a db_schema property and all the > supporting code sounds like it would fit well...you can create fk's to > tables in diff schemas. This is ticket [1]#6148. There is some recent renewed energy and know how being put in addind that feature. Maybe you can help by testing the proposed changes with your use case and giving feedback? Regards, -- Ramiro Morales 1. https://code.djangoproject.com/ticket/6148 -- 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: suggestion: Don't make the tag "url" dirty in Django1.5
On Tue, Mar 27, 2012 at 5:22 AM, gs412 wrote:
> In Django1.5
>
>> {% url app_views.client %}
>
> will change to
>>
>> {% "url app_views.client" %}
>
>
> I think it is a stupid idea
> Why so many people use django? becouse of 'DRY', but now django become more
> and more 'dirty'
Please post references from where did you get this nonsense. It is
completely wrong to the point of not even being correct syntax.
Please read the oficial documentation.
--
Ramiro Morales
--
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: Status of issue 17758: dict ordering bugs
2012/3/22 Łukasz Rekucki :
> Hi,
>
> I got a sad message today, that it's most likely that issue #17758
> won't go in to 1.4; While most of the problems addressed by this
> ticket are harmless, I really don't think it's a good idea to ship 1.4
> without resolving the ORM bug. The hash randomization is a security
> fix. Right now, people upgrading to Python 2.6.8 or 2.7.3 will start
> randomly getting different results on some queries.
>
> If the whole patch can't be merged, lets at least fix that bug[2]. Is
> there any work I can do to make it happen?
>
> [1]: https://code.djangoproject.com/ticket/17758
> [2]:
> https://github.com/lqc/django/commit/84dc450ec861e34de068fde891537f0481342ef7
I think part of the problem is that the ticket conflates two (three? more?)
different problem reports under one title ("Do not depend on dict
order in test suite")
The title itself leads to think the issue is something of a lesser
severity/priority
than the other issues.
Maybe we should split these problem reports in their own tickets?
Regards,
--
Ramiro Morales
--
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: Jquery library update in django 1.4
On Wed, Feb 29, 2012 at 4:41 AM, Ric wrote: > hi, is it possibile to upgrade the jquery library in admin to the > lastest version with the now django 1.4? > > for what i've seen there is just one little bug when you use the > select all checkbox in admin changelist, all other javascript works > out of the box Please if you can open a ticket in the issue tracker describing that 'one little bug' with a little more detail. Or if you can't give us such details here so somebody else can report it with a ticket. -- Ramiro Morales -- 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 1.4b + mysql + boolean fields
On Fri, Feb 24, 2012 at 7:53 AM, Tomasz Kloc wrote: > The problem was caused by django.contrib.gis.db.backends.mysql backend. It > has own backend implementation which returns booleans as integers (it was > fixed for 'core' mysql backend in > https://code.djangoproject.com/ticket/13293 ) > > I think it's a bug which will afect some users after upgrading to django 1.4 > - in my opinion quite serious. > > Any comments before creating a ticket? I think there is one already: https://code.djangoproject.com/ticket/15169 -- Ramiro Morales -- 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: ModelFormSet validation fails when initial queryset contains objects not in the default manager's queryset
On Tue, Feb 21, 2012 at 12:46 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Ramiro, > > [...] > > It seems to me you may have mis-read Tom's message. It seems perfectly > on-topic to me; he's not asking how to fix his problem, he's asking > about the design of BaseModelFormSet itself. Oh you are right. Sorry Tom for replying too fast and thanks Carl for correting me. Regards, -- Ramiro Morales -- 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: ModelFormSet validation fails when initial queryset contains objects not in the default manager's queryset
On Tue, Feb 21, 2012 at 2:58 AM, Tom wrote: > Hi everyone, Please start threads like this to the django-users mailing list as this list is dedicated exclusively to discussions about development of Django. -- Ramiro Morales -- 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: Add model file to add in django.contrib.localflavor.ar
Hi Cesar, On Tue, Jan 17, 2012 at 9:33 PM, César H. Roldán wrote: > Hi, I have a models.py file to add in localflavor.ar. > This file has the same Fields as forms.py but it's to use in models. > Do I need to add a ticket with the attached file? Or I have to follow > another steps? Sorry for not replying earlier. I was going to ask you why do you think custom model fields are needed when localflavor is only about forms. Then I inspected the contrib.localflavor hierarchy and see now flavors for Australia, Macedonia, Mexico and USA ship custom model fields. But I still can't see the advantage. AFAICT feature and behavior -wise these new custom model forms provide no added value over their CharField counterparts ¿Am I wrong on this? This last question is honest and I want to share it with the rest of the -developers subscribers. I'd like to grasp this fully before deciding if I will apply the proposed patch to the AR localflavor. -- Ramiro Morales -- 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: Custom transform in django docs
Hi Luke, On Thu, Oct 13, 2011 at 9:16 PM, Luke Plant wrote: > > [...] > there were several hundreds more! I might > not have attempted this if I had correctly counted at the beginning... > but anyway, I've fixed them all now (hopefully!). > > It seems we were relying on this hack in *lots* of places, not just in > the docs that originated from Jacob's import of docs. Wow that was fast. Thanks! -- Ramiro Morales -- 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: Custom transform in django docs
On Tue, Oct 11, 2011 at 9:37 PM, Luke Plant wrote: > > Ah, well that explains it! It's gone now :-) Belated +1 to this -- Great finding and fix Luke. But it seems this is affecting styling of locally generated builds of the HTML version of the docs. Fon an example see (from tutorial part #1) http://i.imgur.com/CQrjo.png Compare that with: https://docs.djangoproject.com/en/dev/intro/tutorial01/ There are a lot of other bulleted (and numbered?) lists in our docs that sport the same green vertical bar at the left as the two-elements one at the top of that page. Looking at the ReST documentation[1] it seems the indentation we use for such lists are non-conventional and would explain this. Can anybody confirm this?. If so, we have a bunch of documentation .txt files to tweak. (also, if/when we fix this we should verify that we don't break the stylin of the affected parts in the docs.djangoproject.com) Regards, -- Ramiro Morales 1. http://docutils.sourceforge.net/docs/user/rst/quickstart.html#lists -- 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: __getattr__ on SimpleTemplateResponse causes problems
On Thu, Sep 29, 2011 at 8:43 PM, Luke Plant wrote: > Hi all, > > r16568 [1] added SimpleTemplateResponse.__getattr__ as part of a fix for > #16326 [2]. > > There is one obvious bug in the implementation - it calls > super(...).__getattr__ which itself raises AttributeError because none > of the base classes have __getattr__. It should use getattr instead. #16935[1] reports that, I think. https://code.djangoproject.com/ticket/16935 -- Ramiro Morales -- 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: Reversing translated urls in templates
On Sat, Jun 25, 2011 at 6:58 AM, Jannis Leidel wrote:
>
> As I said initially when we discussed this on IRC, I believe a "i18n_url" is
> good enough
> and would fit well with the other i18n related template tags.
>
> Besides the ambiguity of a potential keyword argument "lang", I'd like to
> mention that
> we specifically chose to use "i18n_patterns" as the name for the function
> that returns
> i18n-enabled URL patterns to be explicit about when a URL should be
> translated. I believe
> this pattern should also be applied to the template tag which a user might
> use to point to
> one of those translatable URLs.
>
On Sat, Jun 25, 2011 at 2:50 AM, maxk wrote:
> What do you think about something like below
>
> {% url viewname k1=v1, k2=v2 with lang=lang %}
Briefly discussed this via IRC th Jannis. I'm +1 on keeping the new tag
in the i18 ttag lib for the reasons exposed by Jannis. So a prefix like
'i18n_' would fit well IMHO. +1 on this.
Adding that functionality to the i18n tag can also work, I think.
Especially now that Jannis makes me see it wouldn't cause loading of the
i18n machinery for people with USE_i18N=False. But I'd like to
completely avoid the possibility of clashing with existing 'lang'
arguments and I'm not 100% convinced by the "with lang='xx'" part of the
proposed syntax. It is a hybrid between our 'old' "with var as alias"
and the new (from future) "var=alias" form. I'm -0 on this option
--
Ramiro Morales
--
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: Should postgresql cascade after truncate
On Tue, Jun 21, 2011 at 12:48 PM, Peter Russell wrote: > I've just been writing a test which checks that a delete() method > works correctly. The test passes, but on closer inspection it should > have failed, because creating my object creates a second object which > is not being deleted. In principle Postgres will raise an > IntegrityError about this, but because all foreign keys are created > "DEFERRABLE INITIALLY DEFERRED", the check doesn't happen until the > transaction is committed... which doesn't happen. If I switch to > using TransactionTestCase (which is massively slower), the test fails > as expected. > > I haven't tested this yet, but I suspect that if I modified the Django > TestCase code to emit "SET CONSTRAINTS ALL IMMEDIATE;" before it > truncates the tables my IntegrityError will be raised. That's what [1]ticket 11665 reports. -- Ramiro Morales 1. https://code.djangoproject.com/ticket/11665 -- 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: Test optimizations (2-5x as fast)
On Sun, Jun 5, 2011 at 5:18 PM, Ned Batchelder wrote:
> When I try this on a PostgreSQL database, I have problems relating to
> violated uniqueness constraints, sometimes from tests themselves, sometimes
> from setUpClass, sometimes from tearDownClass. In the latter two cases,
> it's the sites table involved. Is this something others have dealt with, or
> am I on my own? :)
>
> I tried adding a PostgreSQL "disable constraints" statement here:
> https://github.com/jbalogh/test-utils/blob/master/test_utils/__init__.py#L109
>
> cursor.execute('SET CONSTRAINT ALL DEFERRED')
>
> It didn't help.
This might be related to ticket [1]#11665, a knownissue in the TestCase
handling of constraints with pg. Suggestion athere si to use
SET CONSTRAINTS ALL IMMEDIATE
before the rollback.
HTH
--
Ramiro Morales
1. https://code.djangoproject.com/ticket/11665
--
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: Test optimizations (2-5x as fast)
On Fri, May 13, 2011 at 11:57 PM, Erik Rose wrote: > tl;dr: I've written an alternative TestCase base class which makes > fixture-using tests much more I/O efficient on transactional DBs, and I'd > like to upstream it. > [...] > 1. Class-level fixture setup > [...] > 2. Fixture grouping > [...] Only wanted to point that optimization of database data fixture loading in tests is the topic of ticket [1]9449 in the Django bug tracker. The two contributors that participated in the discussion there so far took the fixture caching path, but I think the ticket can be considered associated with the general problem and so is open for other solution strategies. -- Ramiro Morales 1. https://code.djangoproject.com/ticket/9449 -- 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: #15294 -- Don't use hard-coded URLs in the admin
On Thu, Jun 2, 2011 at 11:30 AM, Ramiro Morales wrote:
>
> o We added an inner template block inside breadcrumbs one, we called it
>crumbs, among other cleanups in the breadcrumbs code. Is it worth it?
Jannis posted this comment in the ticket:
What's the purpose of the crumbs block? Isn't that a bit OT for this
ticket and would make upgrading harder?
We initially though it would allow to reduce the duplication of HTML
code in the breadcrumbs and help to fix the inconsistent nesting of
the 'breadcrumbs' template block and an 'if not is_popup' contidional
used in some of the templates but I see now it isn't worth it and it
introduced its own inconsistencies.
I've reverted that and attatched a new [1]patch to the ticket.
Something I forgot to mention in the first email is that the changes
introduce (for me) six errors like this in the admin_views regression
tests:
==
ERROR: testAdminIndex (regressiontests.admin_views.tests.NeverCacheTests)
Check the never-cache status of the main index
--
Traceback (most recent call last):
File "tests/regressiontests/admin_views/tests.py", line 2610, in
testAdminIndex
response = self.client.get('/test_admin/admin/')
File "django/test/client.py", line 445, in get
response = super(Client, self).get(path, data=data, **extra)
File "django/test/client.py", line 229, in get
return self.request(**r)
File "django/core/handlers/base.py", line 111, in get_response
response = callback(request, *callback_args, **callback_kwargs)
File "django/contrib/admin/sites.py", line 209, in wrapper
return self.admin_view(view, cacheable)(*args, **kwargs)
File "django/utils/decorators.py", line 91, in _wrapped_view
response = view_func(request, *args, **kwargs)
File "django/views/decorators/cache.py", line 77, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
File "django/contrib/admin/sites.py", line 192, in inner
return view(request, *args, **kwargs)
File "django/views/decorators/cache.py", line 77, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
File "django/contrib/admin/sites.py", line 345, in index
'admin_url': reverse('admin:%s_%s_changelist' % info,
current_app=self.name),
File "django/core/urlresolvers.py", line 398, in reverse
*args, **kwargs)))
File "django/core/urlresolvers.py", line 344, in reverse
"arguments '%s' not found." % (lookup_view_s, args, kwargs))
NoReverseMatch: Reverse for 'comments_comment_changelist' with
arguments '()' and keyword arguments '{}' not found.
But strangely enough, e.g. Florian doesn't see them.
These errors aren't reproducible when running the admin_views tests
alone, nor either using --bisect or --pair
Debugging so far shows that that 'comments_comment_changelist' URL is
affective available in the AdminSIte instance URL map at the point
the NoReverseMatchexception is raised (AdminSite.index() view).
Any idea or hint bout what could be the problem is welcome.
Regards,
--
Ramiro Morales
1. https://code.djangoproject.com/attachment/ticket/15294/15294.2.diff
--
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.
#15294 -- Don't use hard-coded URLs in the admin
Hi all, We have a first [1]patch ready for review and feedback for this [2]ticket. It is strongly based on one Florian Apolloner had posted to ticket #13588. It's about removing as many hard-coded '../../..'-prefixed URLs in Python code and templates of the admin app as possible. Some notes and questions: o It implements the same changes for ForeignKeyRawIdWidget and ManyToManyRawIdWidget admin-specific widgets, e.g. it changes their __init__ to add a adminSite instance argument. o AdminSite.root_path is removed for good. o We added an inner template block inside breadcrumbs one, we called it crumbs, among other cleanups in the breadcrumbs code. Is it worth it? o It adds a new template tag library 'admin_urls' with a very simple 'model_url' tag that needs to receive the app name, the model name and that returns it's URL in the current admin site. Ideas for a better implementation are welcome. o It also removed the hard-coded URLS in the admindocs app! This is thanks to Dario Ocles that spotted this omission and worked on implementing the needed changed. o It included one test that involves a model with CharField PK, one instance of such model has a 'add' value whose -change_view' form URL clashes with the 'add_view' form URL. To workaround the clash, the URL for 'add_view' is changed to .../!add/ making use of the patch functionality. o That test environment revealed a strange trait of the URL resolving machinery in the admin *: If one wants to add an URL when there is already one with the same name (e.g. 'appname_modelname_add') you can't simply append it to the end or insert it at the front of the url patters list returned by your ModelAdmin.get_urls() because it either is ignored or breaks resolution of other URLs realted to you model. You need either to remove the existing entry first or re-define all the URLs related to the model in your ModelAdmin.get_urls() simply to only change one of them. I don't knw if we should consider this a bug on its own. Opinions welcome. * Actually, I 've had no time to check if this a more general problem of the URL routing framework or if it only affects the admin URLs. Regards, -- Ramiro Morales 1. https://code.djangoproject.com/attachment/ticket/15294/15294.1.diff 2. https://code.djangoproject.com/ticket/15294 -- 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: Translation catalog for localflavor must be loaded manually
On Thu, Apr 14, 2011 at 7:51 AM, Fidel Ramos wrote: > I included some fields from localflavor.es.forms in a project, and > expected the error messages to appear translated, as localflavor > already has a catalog. However the messages only appeared in English. > > Turns out the localflavor catalog is not automatically loaded, it must > be included manually in the LOCALE_PATHS setting as implied by the > internationalization documentation [1], because only the django/conf/ > locale catalog is loaded automatically. Do you have django.contrib.localflavor listed in your INSTALLED_APPS setting?. -- Ramiro Morales -- 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: Error importing template source loader when upgrading from r15883 to r16025
On Wed, Apr 13, 2011 at 1:37 PM, lazyant wrote:
> Hello,
>
> I have a small web site that was running happily with django r15883
> that I updated March 21st.
>
> Yesterday I upgraded to the latest version (r16025) and then I'm
> getting an error that 505s my site:
>
> Error importing template source loader
> django.template.loaders.filesystem.load_template_source: "'module'
> object has no attribute 'load_template_source'"
>
> at /usr/lib/python2.6/dist-packages/django/template/loader.py in
> find_template_loader, line 101
>
> I couldn't find anything related to this in my web searches including
> http://code.djangoproject.com.
>
> I'm running Apache 2.2 on Ubuntu 10.10, everything pretty updated.
>
> I just rolled back to the previous version, but just leaving this
> here, I'm not even sure this is the right place.
>
> I checked the changes done between the two versions with svn log -r
> {2011-03-20}:{2011-04-12} and these two commits are what they look as
> possible candidates for this issue:
>
> Advanced deprecations in django.template.
>
> r15986 | russellm | 2011-04-02 04:41:26 -0400 (Sat, 02 Apr 2011) | 1
> line
>
> Removed support code for deprecated module-based template loaders from
> debug view postmortem.
>
> r16004 | ramiro | 2011-04-02 15:03:11 -0400 (Sat, 02 Apr 2011) | 1
> line
Function-based template loader were deprecated in Django 1.2
and will be removed in 1.4. They were replaced with class
a based loader API
http://code.djangoproject.com/changeset/11862
You seem to be running your site against trunk, and we've
started to delete the code scheduled to be removed in 1.4 a
few days after the release of 1.3, the two commits you isolated
are part of that.
It is not clear to me if you are using a custom template loader
(in such case you need to adapt it to conform to the new API),
or if you have some weird Django setup problem with both
old and new code. Maybe you can share tat with us once
you discover what's happening?
Regarding the documentation, unfortunately the documentation
changes introduced together with the code changes didn't include
proper markup to signal the specific modifications perfoemed
nor a related section in the respective release notes.
We tried to correct these omissions somewhat late during the 1.3
development cycle. The changeset is r15309
http://code.djangoproject.com/changeset/15309
and it adds the text sections Lucasz pointed you at.
It was also backported to the 1.2.X branch and th 1.2.5
release included these new doc blurbs.
Regards,
--
Ramiro Morales
--
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 multiple databases router(Cross-database foreign key)
On Thu, Mar 24, 2011 at 7:23 AM, dy wrote: > Hi django devs, This list isn't a second level support fallback from django-users threads. It is exclusively dedicated to the discussion about development of Django*itself*. Please, keep this discussion in django-users. -- Ramiro Morales -- 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: Permision Denied on share acces
On Fri, Mar 18, 2011 at 11:57 AM, mik3langelo wrote: > i got a problem that drains me. I created an application/interface > that a certain thing would need to create a file on a particular > share. problem is that I get IOError code 13. There are some > restrictions in Django that they not know? > strange is that if I make a first os.path.isdir () and returns ok, but > when I try to do os.mkdir () failed You've sent the post to the wrong mailing list for this post. This list is for the discussion of Django development itself. Hopefully you will have better luck in general Python programming list or the django-users mailing list. Regards, -- Ramiro Morales -- 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: Inline formset exception
On Mon, Mar 7, 2011 at 3:17 PM, poswald wrote: > (Sorry Ramiro, I think I replied directly to you instead of to the > group. Resending here) > > Understood. I believed I was adding a testcase and expanding the scope > of the issue but it is certainly possible that they are two separate > causes. I will keep that in mind in the future and will certainly open > a new issue/revert this one here if everyone would prefer. > > For what it is worth I was able to reproduce the exception using the > original reporter's code but only if I follow the process I outlined > in my report. Actually I've just reproduced (using trunk) the situation reported by the OP: Simple two-model generic foreign key plus generic inlines setup in the admin app, activation and usage of the save as button and no need to add a second browser window in the mix. A very simple to prepare and reproduce setup. The other users that added comments to the ticket before loosely described their problem as not related to the admin inlines at all rather with more low level model formsets; in any case they don't provide enough details to be able to know if they are really contributing to the isolation of the original issue or simply landed in that ticket with a search and found something similar in its symptoms to their own issues. Because of this I'm going to revert your changes to the ticket and I'd like to ask you to open another ticket and move what you've found so far there. We might be in presence of he same issue but I think the divergence of initial conditions show it's too early to be sure of that. Thanks, -- Ramiro Morales -- 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: Inline formset exception
On Mon, Mar 7, 2011 at 10:29 AM, poswald wrote: > It seems that I have managed to get a reproducible process for an > issue that has flummoxed a few other people over the past few months: > http://code.djangoproject.com/ticket/14642 Procedural note: You've changed the summary and focus of that ticket. Do you have the same enviroment as the OP? (i.e. using generic inlines and the 'Save as' button functionality but without any multiple user simultaneous interaction). Have you tried to reproduce it before editing the ticket? If not, you might be "stealing" a ticket instead of opening a completely new one which would be the right thing to do. Your description of the analysis of the issues doesn't show you've taken in account OP's issue either it is not clear both issues are the same. Regards, -- Ramiro Morales -- 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: GSoC 2011 student contribution
Hi Ben, On Thu, Feb 10, 2011 at 4:48 AM, Ben Ripkens wrote: > Hello Django developer community, > my name is Ben Ripkens and I'm planning to contribute to the Django > project through this years Google Summer of Code. I'm replying because I'm the one that created that page mostly as a initial draft by copying the GSoC '10 page and updating the deadlines. One core developer has already pointed that he wants to refactor that page to be more clear. > I found the ideas page for 2011 [1] and even though it seems not publicly > available I'm curious whether the mentioned ideas are up to date, available Yes, the list is up to date in the sense that the projects mentioned haven't been implemented, with the exception of the last one (Testing updates) that has been partially completed. Also, most surely there will be new ideas added. > and whether you are applying at all (the list is lacking mentors). > Yes, we intend to apply this year. And I suspect there will be more activity from potential mentor once we get 1.3 out the door this month. The updated schedule for the 1.3 release and the project application period seem to fit nicely. > I'm especially interested in the idea called "Multiple timezone support > for datetime representation" (for which the issue is not fixed) as I had > a similar issue in my last project where the customer asked for timezone > support during the final presentation (final internship presentation, > the goal was documentation and visualization [2, 3]). I guess that this > idea is still available? Yes, it is. I see Russell has created a complete reply to the rest of you email so I will stop here because there is now way I could be more clear than him :) -- Ramiro Morales -- 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: Admin DateTimeShortcuts performance (feature request / improvement suggestion)
Fabian, On Jan 28, 11:18 am, Fabian Büchler wrote: > [...] > As an addition, I think it would make sense to integrate the jQuery UI > datepicker (maybe with a timepicker extension [1]) instead of the existing > one, because that might resolve some problems, as with the datepicker > opening outside of the viewport when the calendar icon is too far on the > right side of the screen. > While your jQuery UI dependency inclusion proposal is discussed I'd like to focus in the specific datepicker calendar outside of viewport problem you describe. We fixed a related problem regarding negative vertical positions in [1]r15143 closing ticket #11414. You seem to be proficient in JavaScript and hopefully have a way to reproduce the issue so if you can identify the exact problem maybe we can fix it in the short term. Please feel free to open a ticket with your findings, bonus points for a patch fixing it :) Thanks for taking the time to help us with all those issues and enhancements. Regards, -- Ramiro 1. http://code.djangoproject.com/changeset/15143 2. http://code.djangoproject.com/ticket/11414 -- 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: i18n bug in template rendering.
Hi, I've opened ticket [1]15157 in the Django issue tracker for this report. Any feedback or correction is welcome. Thanks! 1. http://code.djangoproject.com/ticket/15157 -- Ramiro Morales -- 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: I18N locale per app resolving - documentation incorrect or bug?
On Thu, Jan 13, 2011 at 4:13 PM, Klaas van Schelven wrote: >> >> a) The doc fix attached to #14910 to describe the current situation >> and that got committed isn't correct. At no point of the catalog building >> process a '``locale`` directory in the directory containing your settings >> file.' is involved at all. And it doesn't mention the LOCALE_PATHS part. >> > > [...] > > What I meant with "a ``locale`` directory in the directory containing > your settings file." is "the project path". It is/was not clear to me > that Django thinks of the location of the file you specify when doing > --settings=some_settings as the "project path". This may lead to > unexpected behavior when you put your actual settings file in a > different location than the rest of your project files. Which led to > unexpected behavior for me. > Is this conflation of "the path to your specified settings file" with > "project path" the default Django behavior? I can imagine there's > other cases where a notion of a project path is used. If so: is this > documented somewhere? > For me the project has always been the place where the settings file is located. And yes, grep shows there are other places in Django that makes this assumption but based in the structure created by startproject; the project and application distinction and definitions are touched in part one of the tutorial. I agree with that we can be a bit more specific here and will refine that paragraph when updating the docs. Thanks for the heads up. >> b) I'm not sure I understand what converting the merge to a no >> destructive update has to do with all this, I think the behavior of a >> dictionary update() on the catalog being built is basic for the >> translations overriding functionality. > > If we decide the he fact that the later latter elements in the lists > (INSTALLED_APPS and LOCALE_PATHS) have higher precedence is non- > intuitive, we can implement a reversal of that order in one of two > obvious ways: > 1] make the update non-destructive, and reverse the order you mention > above (1-4). > 2] wrap both of the lists with reversed(), or something to that > effect. Ok > > I'm not sure what you mean by "short circuit logic" and it seems to be > a key part of your argument. Could you explain? > By short circuit logic I mean thay in the case of templates, one template is looked up by traversing the paths in the documented order and when one is found the lookup ends there. > > On the matter of backwards compatibility I can only make an educated > guess and express the hope that others will chime in on the issue. > > I have one clue that this will not lead to many backwards > compatibility issues. Which is: I haven't found anyone else > complaining or asking about the issue on Trac or elsewhere on the > internet. > > Having said that, I think the proposed changes are "the right thing", > because: > > 1] on the matter of the reversed order within the lists > (INSTALLED_APPS and LOCALE_PATHS) this is the exact opposite of > Django's templating behavior, and for example the way staticfiles > works. So the behavior is unexpected, and will therefore lead to bugs. > Secondly, this means that if you have an application that depends on > the order of the apps for both templates and localizations, you're > hosed, because you can't put A before B and B before A at the same > time. > > 2] As to the higher preference for LOCALE_PATHS, I'll just repeat that > the reason someone would put up a specific path for locales pretty > much has to be to override the existing behavior (which would be found > in project and apps). > I'm leaning to agree in general with you regarding the directory precedence order schema. But I'm still unsure we will be able to do this before 1.3. I will attach a patch to the ticket and ask for opinions. Thanks, -- Ramiro Morales -- 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: I18N locale per app resolving - documentation incorrect or bug?
On Mon, Jan 10, 2011 at 7:12 PM, Klaas van Schelven wrote: > > Input (discussion) on this is much appreciated. I'll gladly put in a > new patch once a decision is reached. If this is a separate issue, I'm > also fine on opening a separate ticket. (it could be argued that we > can move forward on the original bug report as a separate issue more > easily, since it's "obviously broken") > Ok, had some time to look at this. These are the notes resulting from that: a) The doc fix attached to #14910 to describe the current situation and that got committed isn't correct. At no point of the catalog building process a '``locale`` directory in the directory containing your settings file.' is involved at all. And it doesn't mention the LOCALE_PATHS part. The translation built is constructed by: 1. Adding the Django translations. 2. Updating it with the translations found in the paths listed in settings.LOCALE_PATHS with the latter ones having greater precedence. 3. Updating it with the translations found in the apps listed in settings.INSTALLED_APPS with the latter ones having greater precedence. 4. Updating it with the translation found in the locale/ dir under the project dir. (this was before 3 before r12447) this could be described in that way or by saying that the precedence of the literals found while building the final unified translation is (from higher to lesser): * The translation found in the project locale/ dir * the translations found in the apps listed in settings.INSTALLED_APPS with the latter ones having higher precedence. * The translations found in the paths listed in settings.LOCALE_PATHS with the latter ones having higher precedence. * The translations shipped with Django. See also item d below. b) I'm not sure I understand what converting the merge to a no destructive update has to do with all this, I think the behavior of a dictionary update() on the catalog being built is basic for the translations overriding functionality. c) Regarding reversing the priority of the translations in apps listed in INSTALLED_APPS. Comparing it with the order followed when loading templates isn't IMHO totally correct because template lookup has a short circuit logic while translation loading has incremental updating semantics. I'm not saying I'm against the change (and against the change of the precedence of the translation is LOCALE_PATHS) the but I think we need to discuss further to decide if they really correct and if they are worth the potential change in translated literals in existing projects they might introduce. d) I think the documentation text can be changed to make it clear that no translation searching with short circuit is done but rather a build of a unique translation by merging in/overriding the different parts in the order documented. Also, the note about the LocaleMiddleware can be dropped. Will take care of this soon. Regards, -- Ramiro Morales -- 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: Regressions in 1.2.4
On Wed, Jan 5, 2011 at 1:05 PM, Russell Keith-Magee wrote: > > We will obviously to do a 1.2.5 release when we hit 1.3 final; but I'm > not sure if we should push an 1.2.5 (and 1.1.4) ASAP addressing these > regressions, and then do 1.2.6 when we cut 1.3 final. > > This also points out that we should perhaps reconsider our release > policy. Putting out security releases that include unrelated fixes is > a bit of a risk. We've been bitten by this in the past, but never this > bad. I would suggest that when security issues arises in 1.2.3, we > should be releaseing 1.2.3.1 rather than 1.2.4. If a security release > coincides with a point release -- as it did when we released 1.3beta1 > -- we should release 1.2.3.1 (to address the security issue) *and* > 1.2.4 (to get the other bugfixes). This will ensure that it is > possible to update production code and get just the security fix, > without any risk of regressions. > > Any opinions on these two points? I agree with getting a 1.2.5 ASAP. Also, it has always been my thought that the security releases should contain only the security fix(es) that trigger them, and always asked myself if it would be too crazy to propose a four-component A.B.C.D versioning schema. IT policies that force users to only install releases software won't allow people to run a 1.2.3 with the security fixes manually applied over it, and user won't dare to go straight to e.g. 1.2.4 based on knowledge of our release policy plus experience of regressions in other parts of the framework in security releases. Data point: Ubuntu has released these two security fixes for their users not by packaging 1.2.4 but by creating a 1.2.3-1ubuntu0.2.11.04.1 (talk about long package release numbers) I suspected they simply applied the patches linked from the announcement. http://changelogs.ubuntu.com/changelogs/pool/main/p/python-django/python-django_1.2.3-1ubuntu0.2.11.04.1/changelog The only issue I have with these two yes it that they mean adding burden to our release manager. But maybe that's topic for another discussion. Regards, -- Ramiro Morales -- 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: i18n bug in template rendering.
On Thu, Jan 6, 2011 at 8:15 AM, Ramiro Morales wrote:
> Weird, it's working here:
Ignore me, I was creating a new Template instance. I can reproduce it:
In [1]: from django.utils import translation
In [2]: from django.template import Template, Context
In [3]:
In [4]:
In [5]: def language(language_code):
...: class with_block(object):
...: def __enter__(self):
...: self._old_language = translation.get_language()
...: translation.activate(language_code)
...: def __exit__(self, *args):
...: translation.activate(self._old_language)
...: return with_block()
...:
In [6]: with language('de'): z = Template("{% load i18n %}{{
0|yesno:_('yes,no,maybe') }}")
...:
In [7]: with language('nl'):
...: z.render(Context())
...:
...:
Out[7]: u'Nein'
In [8]: with language('en'):
...: z.render(Context())
...:
...:
Out[8]: u'Nein'
If I apply this small fix to our code:
http://paste.pocoo.org/show/315758/
Things work correctly:
In [1]: from django.utils import translation
In [2]: from django.template import Template, Context
In [3]:
In [4]:
In [5]: def language(language_code):
...: class with_block(object):
...: def __enter__(self):
...: self._old_language = translation.get_language()
...: translation.activate(language_code)
...: def __exit__(self, *args):
...: translation.activate(self._old_language)
...: return with_block()
...:
In [6]: with language('de'): z = Template("{% load i18n %}{{
0|yesno:_('yes,no,maybe') }}")
...:
In [7]: with language('nl'):
...: z.render(Context())
...:
...:
Out[7]: u'nee'
In [8]: with language('en'):
...: z.render(Context())
...:
...:
Out[8]: u'no'
and out test suite still runs, but I need to add regression tests.
Will ask about this to I18N maintainers/contributors. Thanks!
--
Ramiro Morales
--
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: i18n bug in template rendering.
On Thu, Jan 6, 2011 at 5:07 AM, Jonathan S wrote:
>
>> You aren't supposed to use _('Foo') as a standalone variable.
>> (see last paragraph
>> herehttp://docs.djangoproject.com/en/1.2/topics/i18n/internationalization...)
>
>
> Why shouldn't I use it as a standalone variable? (A language should
> have a *context free* grammar, which means, that the underscore
> function can be used in any variable. But that's no problem in
> Django.)
>
>
> That's not the point, the bug applies to any variable, template tag or
> template filter parameter. It seems like a bug to me:
> Any underscore function is translated during the initialisation of the
> template, and that is wrong to me.
>
> I guess, also for this one, like mentioned in the documentation.
> {% some_special_tag _("Page not found") value|yesno:_("yes,no") %}
>
> And I did a quick test:
>
>
> with language('nl'):
> t = Template("{% load i18n %}{{ 1|yesno:_('yes,no') }}")
>
> t.render(Context()) # Will output 'ja'
> with language('en'):
> t.render(Context()) # Will still output 'ja', even if the language
> is English now...
Weird, it's working here:
In [1]: from django.utils import translation
In [2]: from django.template import Template, Context
In [3]:
In [4]:
In [5]: def language(language_code):
...: class with_block(object):
...: def __enter__(self):
...: self._old_language = translation.get_language()
...: translation.activate(language_code)
...: def __exit__(self, *args):
...: translation.activate(self._old_language)
...: return with_block()
...:
In [6]: with language('nl'):
...: Template("{% load i18n %}{{ 1|yesno:_('yes,no,maybe')
}}").render(Context())
...:
...:
Out[6]: u'ja'
In [7]: with language('en'):
Template("{% load i18n %}{{ 1|yesno:_('yes,no,maybe') }}").render(Context())
...:
...:
Out[7]: u'yes'
In [8]: with language('nl'):
Template("{% load i18n %}{{ 0|yesno:_('yes,no,maybe') }}").render(Context())
:
:
Out[8]: u'nee'
In [9]: with language('en'):
Template("{% load i18n %}{{ 0|yesno:_('yes,no,maybe') }}").render(Context())
:
:
Out[9]: u'no'
--
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: i18n bug in template rendering.
On Wed, Jan 5, 2011 at 12:21 PM, Jonathan S wrote:
> I guess, we found a bug, not sure if it has been reported earlier and
> whether this is the right place to report.
>
> When a template contains translations in variables, like
> {{ _("text") }}, the text seems to be translated already during the
> creation of the Template object. Every following call of
> Template.render() will output the translation which was made earlier.
> (Possibly in the wrong language.)
>
> Templates are cached in 'django.template.loaders.cached.Loader', so
> this bug makes constructions like {{ _("text")|upper }} impossible.
But you aren't using the i18n support correctly.
You aren't supposed to use _('Foo') as a standalone variable.
(see last paragraph here
http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#other-tags)
Also,
* You need to load the i18n template tag library
* Use the trans tag.
Try using Template("{% load i18n %}{% trans 'Yes' %}").render(...)
to achieve what you want.
All this is covered in the docs:
http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#specifying-translation-strings-in-template-code
--
Ramiro Morales
--
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: I18N locale per app resolving - documentation incorrect or bug?
Klaas, On Thu, Dec 23, 2010 at 7:43 AM, Klaas van Schelven wrote: > Hi all, > > Thanks for checking in 14910! > > Could anyone take a serious look at > http://code.djangoproject.com/ticket/14924 > > It has a test that proves the problem and a relatively simple patch. > > I'm doing a lot of "app overriding" and this bug is extremely annoying > in that case. It would be great if the fix could still make it to 1.3 > I'm pretty sure a design decision will be made about it before 1.3 gets released. It is in the list of tickets I want to look at, and I know it is in the radar of at least one core developer. Just bear with us, we have a lot of tickets (some of them older and/or uglier) to review and fix and one almost seven weeks to work on bug killing before 1.3 goes gold. Thanks for reporting, following and contributing to the solution of this old issue, and for your patience. -- Ramiro Morales -- 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: Settings for a pure Oracle multi-db Django test suite setup
On Wed, Nov 10, 2010 at 10:06 PM, Ian Kelly wrote:
>
> Yes, here are the settings I'm using:
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.oracle',
> 'NAME': 'xe',
> 'USER': 'ikelly',
> 'PASSWORD': 'ikelly',
> 'OPTIONS': {'threaded': True},
> 'TEST_USER': 'django_test_default',
> 'TEST_TBLSPACE': 'django_test_default',
> 'TEST_TBLSPACE_TMP': 'django_test_default_temp',
> },
>
> 'other': {
> 'ENGINE': 'django.db.backends.oracle',
> 'NAME': 'xe',
> 'USER': 'ikelly',
> 'PASSWORD': 'ikelly',
> 'OPTIONS': {'threaded': True},
> 'TEST_USER': 'django_test_other',
> 'TEST_TBLSPACE': 'django_test_other',
> 'TEST_TBLSPACE_TMP': 'django_test_other_temp',
> },
> }
>
> The key is that NAME should be the same ('xe') for both entries, since
> you're really establishing two connections to the same database. The
> TEST_USER, TEST_TBLSPACE, and TEST_TBLSPACE_TMP entries must be different,
> however.
Wow. Thanks Ian!. With these settings, plus your [1]patch for #11101
(and plus [2]r14510)
things look definitely better in the Oracle front:
--
Ran 2804 tests in 1935.104s
FAILED (failures=4, errors=6, skipped=42, expected failures=2)
Will run the test suite against 1.2.X and update the [3]wiki page tomorrow.
--
Ramiro Morales
1. http://code.djangoproject.com/ticket/11101
2. http://code.djangoproject.com/changeset/14510
3. http://code.djangoproject.com/wiki/OracleTestSetup
--
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: Settings for a pure Oracle multi-db Django test suite setup
Andrew,
On Tue, Nov 9, 2010 at 2:15 AM, Andrew Kurinnyi wrote:
> Hi Ramiro
>
> I've been working with Oracle during the sprints after last DjangoCon,
> and had the same problem. I've been told by several people that
> the second db can't be oracle and should be something else, like sqlite.
Thank you very much for your reply. I will test this tonight at home.
Karen had already given me some hints via IRC about havin
to use such a mutiple, heterogeneous DB scheme.
Thanks again for taking the time to share your experiences.
>
> Here is my db settings.
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.oracle', # Add 'postgresql_psycopg2',
> 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> 'NAME': 'XE', # Or path to database file if using
> sqlite3.
> 'USER': 'andrew', # Not used with sqlite3.
> 'PASSWORD': 'djangocon', # Not used with sqlite3.
> 'HOST': '192.168.2.33', # Set to empty string for
> localhost. Not used with sqlite3.
> 'PORT': '1521', # Set to empty string for
> default. Not used with sqlite3.
> },
> 'other': {
> 'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2',
> 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> 'NAME': 'other_db', # Or path to database file if
> using sqlite3.
> 'USER': '', # Not used with sqlite3.
> 'PASSWORD': '', # Not used with sqlite3.
> 'HOST': '', # Set to empty string for localhost.
> Not used with sqlite3.
> 'PORT': '', # Set to empty string for default.
> Not used with sqlite3.
> 'TEST_NAME': 'other_db',
> }
> }
>
> Andrew
>
--
Ramiro Morales
--
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.
Settings for a pure Oracle multi-db Django test suite setup
Hi all,
I'm setting up a Oracle XE instance on Linux to be able to test Django ORM
changes. This has so far resulted in a couple of small fixes and
a [1]wiki page documenting the process and hopefully any feeback
I get to this email.
Being a total newbie regarding Oracle is th reason I post this question after
a couple of hours trying to get our Django test suite working against
Oracle without errors to no avail.
I know that with this product only a 'XE' database is available and
that the Oracle
backend creates 'tablespaces' for every Django database.
I've reached the point where I can run most tests when
the DATABASES setting only includes the 'default' connection
but obviously I get a bunch of
ConnectionDoesNotExist: The connection other doesn't exist
errors and the following summary:
Ran 2712 tests in 1559.220s
FAILED (failures=28, errors=850, skipped=36, expected failures=1)
When I use a settings file, created after trial and error, containing:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xe',
'USER': 'djangotest',
'PASSWORD': 'foo',
},
'other': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xeother',
'USER': 'djangotest2',
'PASSWORD': 'bar',
'TEST_TBLSPACE': 'tblspace_other',
'TEST_TBLSPACE_TMP': 'tblspace_tmp_other',
},
}
the auxiliary test-specific code of the Oracle bckend creates both tablespaces
and their respective users before running them and cleanly deletes all of it
afterwards. But then I get a lot of
DatabaseError: ORA-12520: TNS:listener could not find available
handler for requested type of server
errors and a summary like:
Ran 2746 tests in 2335.718s
FAILED (failures=36, errors=207, skipped=41, expected failures=2)
Has anybody had success with this setup i.e. one where the 'default and 'other'
alias pointing to such an Oracle product/install?. Is it possible at all?
If so, could you please share the relevant Django settings file (not
really, only
the DATABASES setting)?
Thanks,
--
Ramiro Morales
1. http://code.djangoproject.com/wiki/OracleTestSetup
--
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: Custum permission bug
On Thu, Oct 28, 2010 at 9:12 AM, Narciso Oceguera wrote:
> Hi, everyone.
>
> As documentation said, I just added the lines:
>
> class USCitizen(models.Model):
> # ...
>
> class Meta:
> permissions = (
> ("can_drive", "Can drive"),
> ("can_vote", "Can vote in elections"),
> ("can_drink", "Can drink alcohol"),
> )
>
> But after executing: manage.py syncdb
> I can't get my custom permission added in the permission table. I think this
> is a bug because the permissions was not found in
> model._meta.permission attribute ( opts.permissions ) as the signals
> (syncdb) expect. These
> permission were added to the model object itself.
If I understand you correctly, you have found an eror in the Django
documentation
that had already been reported as ticket [1]13503. I will fix it now.
The permissions are about things an user can or can't do with
a model instance, not about things a model can or can't do.
Could you please confirm this is what you're talking about?
Sorry for the inconvenience and thanks for bringing it to our attention..
--
Ramiro Morales
1. http://code.djangoproject.com/ticket/13503
--
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: A prompt 1.2.3 release
On Thu, Sep 9, 2010 at 8:59 PM, Luke Plant wrote: > Hi all, > > It looks like we'll be needing a fairly prompt 1.2.3 release. So far > we've got: > > One major/critical bug (depending on how many people are using the > deprecated CsrfResponseMiddleware): > > http://code.djangoproject.com/ticket/14235 > > One significant regression: > > http://code.djangoproject.com/ticket/14242 > > Packaging error(s): > > http://code.djangoproject.com/ticket/14245 Add to that ticket #14247 -- A test suite error http://code.djangoproject.com/ticket/14247 Unfortunately we didn't catch this failure in four weeks, the fact that the buildbot isn't running tests for the 1.2.X branch doeesn't help either. -- Ramiro Morales | http://rmorales.net -- 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.
SQLite support for FK constraints
Hi all, SQLite 3.6.19 from Oct 14 2009 added support for enforcing these constraints. The relevant documentation is available at http://www.sqlite.org/foreignkeys.html I've opened ticket [1]14204 with a initial patch. In short, the SQLite feature has the following particularities: * There is no need to defer the declaration for these constraints to avoid references to tables still no created because no check is performed at CREATE TABLE time. * In fact, there is no support in ALTER TABLE for adding constraints after the fact. * It supports deferring the constraint enforcement until the end of a transaction (by using 'DEFERRABLE INITIALLY DEFERRED' in the FOREIGN KEY declaration). * It has no support for DROP CONSTRAINT so if a table of a model pointed to by a FK is deleted there is no way to delete the constraint (beforehand of afterwards). This leaves us in the situation in which we can easily create constraints and instruct SQLite to enforce them but we can't remove them. As this delete-this-table functionality is currently being used exclusively for DB teardown performed by tests (DatabaseCreation.sql_destroy_model() method), I' ve chosen to use ON DELETE CASCADE option when creating the FK to avoid table deletion failures caused by referencial integrity errors because in such scenarios normally all the tables of the DB are being removed anyway As you know, during normal usage of the ORM, Django currently performs its own collection of reverse FK and cascade deletes them so the point where cascade deletion is done by SQLite should never be reached (famous last words). I'm still not totally sure this is safe. * Availability of this feature can be queried and toggled by using the 'foreign_keys' pragma. Old versions of SQLite or new versions that were compiled with the feature disabled can be detected and starting with that information, it can be turned on/off explicitly. At this point the following doubts remain: Should we: * Create another backend that defers most of its functionality to the 'sqlite3' one and only change behavior to make use (and require?) the feature in SQLite? * Extend the current backend to detect the SQLite support is available, and if so change behavior to make use of it?. This is what the current patch does. * As above and additionally provide a way to control with a backend boolean switch [2]option?. Also, can/should the default value for this option be scheduled to be changed at a future Django release and providing a migration path? Did I miss too many design considerations? Regards, -- Ramiro Morales� |� http://rmorales.net 1. http://code.djangoproject.com/ticket/14204 2. http://docs.djangoproject.com/en/1.2/ref/settings/#options -- 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.
