Re: 1.9 release planning

I was worried about 1.10 because I wrongly assumed that the entire version string was ordered. SemVer (and https://www.python.org/dev/peps/pep-0386/) specifically call out that each component of a version identifier MUST be ordered numerically. My objections based on that incorrect assumption I

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

On Tuesday 23 June 2015 15:50:14 Tim Graham wrote: > I don't think there's an "architecture rule" that would prevent that > design. It looks like DISALLOWED_USER_AGENTS has been around since 2005, > but handler403 wasn't added until 1.4. Since the docs for the setting say > "Use this for bad

Re: Mongo related issue in Django

Sure, I will ask this question in Django users also. Though I ran the test suite after fixing this and all tests passed without any error. On Wednesday, June 24, 2015 at 12:59:48 AM UTC+5:30, Tim Graham wrote: > > Sorry, but that doesn't help as I have no experience with mongoengine. As > I

Re: Mongo related issue in Django

Sorry, but that doesn't help as I have no experience with mongoengine. As I said, if you want further help, you might find it on the django-users mailing list but I would check mongoengine support for Django. It's not so clear they are working on it now.

Re: Mongo related issue in Django

Hi, This is my settings.py """ Django settings for testApp project. Generated by 'django-admin startproject' using Django 1.8.2. For more information on this file, see https://docs.djangoproject.com/en/1.8/topics/settings/ For the full list of settings and their values, see

Re: Mongo related issue in Django

It's difficult to tell what the issue is without seeing all you code, but "is this is a bug?" questions are more suited for the django-users mailing list. A good first step in testing your "fix" is to see if Django's test suite passes afterwards. I suspect you'll see some test failures with the

Mongo related issue in Django

Hi, Today I was trying to do user authentication with Django + MongoDB. I was constantly getting "Metadict object has no attribute pk" error. I searched for the fix but nothing helped. In the end, I read the implementation of login function and changed request.session[SESSION_KEY] =

Re: 1.9 release planning

I am +1 on the 1.10 - 1.11 - 2.0 plan; I think the discrepancy between 2.x and the future version numbering scheme will in practice be _much_ more confusing (and already has been). I have never found any objection to 1.10-style version numbers convincing. Dotted version numbers are clearly a

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

Aymeric I have created the ticket https://code.djangoproject.com/ticket/25017 with suggested fix. Let me know if you need more input/information from me. Best regards François > On Jun 23, 2015, at 9:15 AM, Aymeric Augustin > wrote: > >

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

Aymeric Sure, I will do that later today, I’ll also take a look at the code to see what needs to be done. François > On Jun 23, 2015, at 9:15 AM, Aymeric Augustin > wrote: > > DISALLOWED_USER_AGENTS predates the addition of the 403 handler and wasn't >

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

DISALLOWED_USER_AGENTS predates the addition of the 403 handler and wasn't updated to take advantage of it. I believe it would make sense to raise Http403 there. Would you mind filing a ticket on https://code.djangoproject.com/? Thanks! -- Aymeric. PS: perhaps we should audit the code base

Re: 1.9 release planning

OK, count me as -0 ;-) -- Aymeric. 2015-06-23 13:23 GMT+02:00 Loïc Bistuer : > > > On Jun 23, 2015, at 17:24, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > > > > I'm against making changes to the version numbers we've already planned > for and also

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

I don't think there's an "architecture rule" that would prevent that design. It looks like DISALLOWED_USER_AGENTS has been around since 2005, but handler403 wasn't added until 1.4. Since the docs for the setting say "Use this for bad robots/crawlers." I guess it's implied that customizing the

Re: 1.9 release planning

2015-06-23 13:23 GMT+02:00 Loïc Bistuer : > > > On Jun 23, 2015, at 17:24, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > > > > Besides, honestly, 1.10 is just ugly :-) > > I don't really see anything wrong with 1.10+ versions but maybe that's > because

Re: Config file for startproject.

for example, check whether this level of customization capabilities of the generated project that you need: pip install tox cookiecutter cookiecutter https://github.com/ionelmc/cookiecutter-pylibrary.git The ionelmc cookiecutter-pylibrary project uses the cookiecutter hooks to customize

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

And quoting Tim Graham: You'll get answers to questions like this on the django-users email list, - the web interface is . The list you've posted to is django-developers, which is for the discussion of the

Re: CommonMiddleware DISALLOWED_USER_AGENTS logic

What about the 403 handler ? https://docs.djangoproject.com/en/1.8/ref/urls/#handler403 François > On Jun 23, 2015, at 8:10 AM, michael.nacha...@gmail.com wrote: > > Dear, folks! > > I wonder is there some architecture rule that doesn't allow CommonMiddleware > raise PermissionDenied

CommonMiddleware DISALLOWED_USER_AGENTS logic

Dear, folks! I wonder is there some architecture rule that doesn't allow CommonMiddleware raise *PermissionDenied* exeption when client agent matches one of the settings.DISALLOWED_USER_AGENTS regexps? Right now

CommonMiddleware DISALLOWED_USER_AGENTS logic

Dear, folks! I wonder is there some architecture rule that doesn't allow CommonMiddleware raise PermissionDenied exception? Right now if django-developer wants to use DISALLOWED_USER_AGENTS setting than all

Re: can't receive IPN in the production with Django-paypal

You'll get answers to questions like this on the django-users email list, < django-us...@googlegroups.com> - the web interface is < https://groups.google.com/forum/#!forum/django-users>. The list you've posted to is django-developers, which is for the discussion of the development of Django

Re: 1.9 release planning

> On Jun 23, 2015, at 17:24, Aymeric Augustin > wrote: > > I'm against making changes to the version numbers we've already planned for > and also against 1.10, 1.11 etc. version numbers. > > Such numbers can easily break version checks that don't expect

Re: Config file for startproject.

Sounds like you might want to take a look at cookiecutter[0] and/or project templates[1] [0] https://github.com/audreyr/cookiecutter [1] https://docs.djangoproject.com/en/dev/ref/django-admin/#startproject-projectname-destination On Tue, Jun 23, 2015 at 2:26 PM, Hiroki Kiyohara

can't receive IPN in the production with Django-paypal

Hello, I have done all the testing on my local machine using *ngro *and it was great! But on the server, it can't receive any notification once the payment is done through the sandbox. Then, I tried the simulator. I can't receive notification if *payment_date* and

Re: 1.9 release planning

+1 to not changing already planned version numbers. - Anssi On Tue, Jun 23, 2015 at 1:24 PM, Aymeric Augustin wrote: > I'm against making changes to the version numbers we've already planned for > and also against 1.10, 1.11 etc. version numbers. > > Such

Re: 1.9 release planning

I'm against making changes to the version numbers we've already planned for and also against 1.10, 1.11 etc. version numbers. Such numbers can easily break version checks that don't expect this case. There's lots of code in the wild with version checks, some of which will probably behave

Re: 1.9 release planning

+1 to 1.11 It was an arbitrary decision not to use 2.0 in the first place because we were not going to do special version numbers. Now Y.0 is a special version (dropping backwards compat after the LTS) it makes more sense. Marc On 22 Jun 2015 19:28, "Tim Graham" wrote: >

Re: Config file for startproject.

You may also want to look into cookiecutter as a way of managing more complex templates for projects. Marc On 23 Jun 2015 05:26, "Hiroki Kiyohara" wrote: > Thanks, Josh. > > * I thought the config (.djangorc) should be included in project template > it's own. > * bash alias