Re: Ticket 19445

[Luke Plant]

On 07/05/13 02:04, Russell Keith-Magee wrote:

> As for the "ModelForm without a Meta" approach -- I see what you're
> driving at, and I can see how it's an elegant solution to the problem.
> My concern is that we'd be encouraging people to pass around
> "half-baked" ModelForm definitions -- i.e., under any other
> circumstances, a ModelForm without a Meta wouldn't be valid. If someone
> puts that ModelForm into a forms.py, it's going to appear like it can be
> used as a form in general usage… except it can't. 

Currently, a ModelForm without a Meta *is* valid, and will work in the
admin no problem. I don't know how long that has been true, but I've got
a Django 1.4 project where it works. ModelAdmin creates the Meta class
for you, or will fill in missing attributes (like 'model') if it is
incomplete.

The difference is that we would be encouraging that practice. But in the
docs, I would only be encouraging it for use in the admin, as the
solution to avoid having to specify 'fields' multiple times.

> The only alternative that immediately comes to mind is allowing a flag
> to be passed into the constructor for a form that explicitly allows
> "insecure default all-fields" behaviour. The admin would always pass in
> that flag, users could if they wanted to (but at least they'd be opting
> in to a known potentially insecure behaviour). I'm not saying I
> particularly like this option either; I'm just floating it as an
> alternative.

A flag to the constructor (by which I assume you mean __init__ not
__new__) is too late. If a model is inspected to create the form fields,
that happens when the ModelForm subclass is defined (within the
ModelFormMetaclass.__new__ method). And that isn't going to be something
we can change, because it would break all the code that depends on it,
like this:

class MyForm(forms.ModelForm):
class Meta:
model = MyModel

MyForm.base_fields['my_field'].widget = ...


...and lots of similar code

In many ways, setting 'Meta.fields = "__all__"' is exactly the flag you
are talking about, only it operates at the ModelForm metaclass level.

Regards,

Luke


-- 

Luke Plant || http://lukeplant.me.uk/

-- 
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 #13910: Generator based rendering (streaming) of templates

[Roger Barnes]

Hi all,

I picked up on earlier work done for generator based template rendering, 
brought it up to master and improved a little on it with tests and a 
StreamingTemplateView class.

I've created the following pull request for consideration: 
https://github.com/django/django/pull/1037

Feedback welcome either here, on the pull request, or on the ticket.
https://code.djangoproject.com/ticket/13910

Cheers,
- Roger Barnes

-- 
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: test discovery

[Carl Meyer]

Hi Anssi,

On 05/08/2013 03:31 PM, Anssi Kääriäinen wrote:
> It would be really nice to be able to use same syntax for running a
> single Django's testcase at least for a while. I expect that there
> will be problems if inspecting how a given test case behaves in older
> versions compared to HEAD. Also, bisecting over the test case renaming
> boundary will be really ugly. I don't believe end users will have too
> much problems with this, but bug hunting and development in Django
> itself will be a bit more tedious to do.

I don't think this is enough of a problem to warrant more code to try to
work around it.

If you're bisecting, at worst this means having two commands in your
shell history instead of one and hopping up to the right one for each
bisect step. I think this is a minor irritation that will fade away soon
enough.

Most of our test apps are small/fast enough that you could just run the
whole app when bisecting instead of an individual TestCase, making this
a non-issue (since Django's test apps are top-level on sys.path, the
command to run a single app in Django's test suite is the same with the
new runner as with the old: "python runtests.py app_name").

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this 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: test discovery

[Jacob Kaplan-Moss]

On Wed, May 8, 2013 at 2:00 PM, Carl Meyer  wrote:
> Jacob has suggested that back-compat breaks in test-running are not as
> serious as in production code, and that we should just switch to the new
> test runner by default in Django 1.6.

I still think this. I don't see the need to maintain compatibility in
testing, especially when compatibility is just a TEST_RUNNER change
away.

Jacob

-- 
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: test discovery

[Anssi Kääriäinen]

It would be really nice to be able to use same syntax for running a
single Django's testcase at least for a while. I expect that there
will be problems if inspecting how a given test case behaves in older
versions compared to HEAD. Also, bisecting over the test case renaming
boundary will be really ugly. I don't believe end users will have too
much problems with this, but bug hunting and development in Django
itself will be a bit more tedious to do.

I don't have any bright ideas of how to do this nicely. Maybe just try
the new way, if no tests found, then try to convert appname.SomeClass
to projectname.appname.tests.SomeClass, and somehow do this only for
tests/runtests.py.

Otherwise the plan looks good to me. And the above issue isn't
anything severe, just something that would make developing Django a
bit easier in certain cases.

 - Anssi

On 9 touko, 00:00, Carl Meyer  wrote:
> Hi all,
>
> Preston Timmons and I have been working the last several weeks to get
> the test discovery branch (#17365) ready for merge, and I think we now
> have a pull request ready for 
> consideration:https://github.com/django/django/pull/1050
>
> Brief summary of the features, changes, and open questions:
>
> * You can now place tests in any file matching the pattern 'test*.py',
> anywhere in your codebase, rather than only in tests.py and models.py
> modules of an INSTALLED_APP. The filename pattern is customizable via
> the --pattern argument to "manage.py test".
>
> * When you run "manage.py test" with no arguments, tests are discovered
> and run in all subdirectories (recursively) of the current working
> directory. (This means that django.contrib and other third-party app
> tests are no longer run by default).
>
> * When you pass arguments to "manage.py test", they are now full Python
> dotted module paths. So if you have a "myproject.myapp" app, and its
> tests.py contains "SomeTestCase", you would now run that single test
> case via "manage.py myproject.myapp.tests.SomeTestCase" rather than
> "manage.py myapp.SomeTestCase". This is longer, but allows more control
> when an app's tests are split into multiple files, and allows for tests
> to be placed anywhere you like.
>
> * Doctests are no longer discovered by default; you will need to
> explicitly integrate them with your test suite as recommended in the
> Python docs:http://docs.python.org/2/library/doctest.html#unittest-api
>
> * Tests in models.py and tests/__init__.py will no longer be discovered
> (as those don't match the default filename pattern).
>
> * The old test runner, and Django's extensions to the doctest module,
> are deprecated and will be removed in Django 1.8; they could of course
> be packaged separately if some people would like to continue using them.
>
> Open question: how to handle the transition?
>
> Jacob has suggested that back-compat breaks in test-running are not as
> serious as in production code, and that we should just switch to the new
> test runner by default in Django 1.6. This is what the pull request
> currently does. This will mean that some people's test suites will
> likely be broken when they upgrade to 1.6. They would have two options,
> both documented in the release notes: they can update their test suite
> to be discovery-compatible immediately, or they can just set TEST_RUNNER
> to point to the old runner and get back the old behavior, which they can
> keep using until Django 1.8 (or longer, if they package the old runner
> externally).
>
> The alternative would be to keep the old test runner as the default in
> global_settings.py until it is removed in 1.8, and add the new runner as
> the TEST_RUNNER in the startproject-generated settings.py. This would
> provide a gentler transition for upgrading projects. On the other hand,
> we just recently got the startproject settings.py all cleaned-up,
> slimmed-down, and newbie-friendly, so it would make me sad to start
> polluting it again with stuff that new projects generally shouldn't care
> about, for solely legacy reasons.
>
> Thoughts, questions, comments, code review and testing welcome! I'd like
> to merge this on Friday (it's a bear to keep updated with trunk), so let
> me know if you need longer.
>
> Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this 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: test discovery

[Aymeric Augustin]

On 8 mai 2013, at 23:00, Carl Meyer  wrote:

> Jacob has suggested that back-compat breaks in test-running are not as
> serious as in production code, and that we should just switch to the new
> test runner by default in Django 1.6. This is what the pull request
> currently does.

That seems reasonable to me.

Thank you very much for working on this.

-- 
Aymeric.



-- 
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: test discovery

[Donald Stufft]

On May 8, 2013, at 5:00 PM, Carl Meyer  wrote:

> Jacob has suggested that back-compat breaks in test-running are not as
> serious as in production code, and that we should just switch to the new
> test runner by default in Django 1.6. This is what the pull request
> currently does. This will mean that some people's test suites will
> likely be broken when they upgrade to 1.6. They would have two options,
> both documented in the release notes: they can update their test suite
> to be discovery-compatible immediately, or they can just set TEST_RUNNER
> to point to the old runner and get back the old behavior, which they can
> keep using until Django 1.8 (or longer, if they package the old runner
> externally).


This sounds reasonable to me. Tests are not production code so I agree with 
Jacob.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Ticket 19445

[Julien Phalip]

Hi Luke,

On May 1, 2013, at 3:31 PM, Luke Plant  wrote:

> Hi all,
> 
> Can I get some feedback on what to do about ticket 19445?
> 
> https://code.djangoproject.com/ticket/19445
> 
> I have re-opened this ticket because I don't think it was addressed
> satisfactorily. I apologise in advance that this is a bit involved!
> 
> The fundamental problem is that the validation routines attempt to do
> static validation of a ModelAdmin class, but ModelAdmin has gained
> methods that mean that many of the things that we want to validate are
> only generated at run time (by which I mean the point when a request is
> received).
> 
> So ModelAdmin.get_form() is the method used to create a form class, but
> the validation routines want to validate ModelAdmin.form . Even without
> subclassing ModelAdmin.get_form(), it's possible to create a form class
> that will not pass validation, but will work fine in practice (see
> ticket for more details).
> 
> The main reason I'm bothered about this is ticket 19733, which is about
> requiring the ModelForm.Meta.fields attribute to be present. Please see
> below for why 19733 is involved.
> 
> Even without #19733, it seems that validation of ModelAdmin.form is
> broken in the general case. The attempts to fix it so far were quite hacky:
> 
> https://github.com/django/django/commit/0694d2196f0fadde37ff2d002a9a4a8edb3ca504
> 
> And I'm fairly sure there are other bugs with validation related to the
> dynamic methods such as get_fieldsets() and get_readonly_fields(), which
> both take a request object.
> 
> Since we can't do static validation properly, I'm tempted to remove it
> altogether, but I imagine the static validation will catch lots of
> problems, which is pretty helpful for newbies. A large part of the
> ModelAdmin validation would need to be removed - everything that depends
> on knowing what fields are going to be present.
> 
> One possibility is to remove the static validation, but where specific
> errors are common (e.g. misnamed fields), we try to make the error
> handling further down the line much more friendly.
> 
> If you read the current validation routines, there are quite a few
> places where potential errors have to be ignored (e.g. a field that
> doesn't exist on the model is referred to), because there are other
> things which could mean that it is actually correct. To me this implies
> that validation is happening at the wrong point.
> 
> 
> 
> Why it matters for #19733:
> 
> https://code.djangoproject.com/ticket/19733
> 
> #19733 will (eventually) require ModelForms to have Meta.fields
> explicitly set. (Or, alternatively, Meta.exclude, but this is discouraged).
> 
> To cover the case where we really do want all fields, you can do 'fields
> = "__all__"', as discussed previously on django-devs.
> 
> However, if you are creating a ModelForm to be used solely in the admin,
> this is not good. We've agreed that that admin should use all fields by
> default, and it has its own ways of specifying which fields to use.
> Having to specify anything about fields on the custom ModelForm is
> confusing.
> 
> There is one good solution I've found: specify a ModelForm without a
> Meta inner class, or at least without a Meta.model attribute.
> 
> This already works fine with the admin. The ModelAdmin already knows the
> model to use, and happily constructs the Meta inner class for your form
> if it is missing.
> 
> This is a really good solution, because:
> 
> 1) It's DRY - you specify everything once:
> 
> ###
> class MyModel(models.Model):
>field1 = models.BooleanField()
> 
> class MyForm(forms.ModelForm):
>def clean(self, *args):
># ...
> 
> class MyAdmin(admin.ModelAdmin):
>form = MyForm
>fieldsets = (
>('Group', {
>  'fields': ['field1']
>  }),
>)
> 
> admin.site.register(MyAdmin, MyModel)
> ###
> 
> 
> 2) It is secure.
> 
> If we do 'MyForm.Meta.fields = "__all__"' just to satisfy ModelForm,
> then not only is it confusing, we've also created a functioning
> ModelForm that could end up being used outside the admin, which has all
> fields included and is therefore potentially insecure. We want to avoid
> that.
> 
> 3) It provides a simple upgrade path.for people who hit the new
> requirement on ModelForm, where they were only using them for ModelAdmin.
> 
> Instead of asking people to add a fields attribute, we tell them to
> remove the whole Meta inner class, or at least the model attribute. This
> can be in the upgrade notes.
> 
> 4) It works well in terms of implementation.
> 
> The admin uses all the ModelForm machinery in terms of location Model
> fields. However, we need ModelForms to have the opposite behaviour from
> the admin in this respect - ModelForms should not use all fields unless
> explicitly told to.
> 
> This means that the obvious place to patch up the mismatch is in the
> admin implementation - it should create an appropriate 

Re: Moving from PIL to Pillow

[Aymeric Augustin]

On 1 mars 2013, at 17:59, Alex Clark  wrote:
> Everything else e.g. "from PIL import Image" should be the same.


Hi Alex,

As we're starting to clear the blockers for the release of Django 1.6, I'm 
resurrecting this discussion.

Quick question: is there a way to tell if the installed library is PIL or 
Pillow? The use case in Django is, when running on PyPy, to fail gracefully 
when attempting to use PIL but allow using Pillow.

I've summarized the situation here: 
https://code.djangoproject.com/ticket/19934#comment:15
Let me know if I've missed or misunderstood something.

Thank you,

-- 
Aymeric.



-- 
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: Recommending a Python 3-compatible MySQL connector

[Aymeric Augustin]

On 7 mai 2013, at 08:34, Aymeric Augustin  
wrote:

> These problems look fairly easy. I plan to work on them.


I just updated the pull request and everything works except BinaryField:
https://code.djangoproject.com/ticket/20025#comment:5

Something forces the output to be a string, either in the MySQL connector or in 
the converters registered by Django.

I would appreciate some help on this.

Here's how to setup the MySQL connector with python 3.3:

$ pyvenv-3.3 mysql-py33
$ . mysql-py33/bin/activate
$ curl http://python-distribute.org/distribute_setup.py | python
$ git clone https://github.com/clelland/MySQL-for-Python-3
$ cd MySQL-for-Python-3
$ python setup.py install

Then run model_fields tests.

-- 
Aymeric.



-- 
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: Progress report: django-mssql for Linux

[Aymeric Augustin]

Hi Vernon,

I'm glad to see that your plan is working.

Regarding "auto_proxy", I would advise against magic configuration; explicit is 
better than implicit.

-- 
Aymeric.



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

Progress report: django-mssql for Linux

[VernonCole]

Hello all:
   I just want to let everyone know what has happened on this proposal in 
the last little while.

1) The combination of a Linux (or Windows) database client with a Windows 
proxy database server is up and running.  The remote supports all of the 
features of adodbapi (when run locally) except: custom error handlers, 
user-defined conversions, and manipulation of module 
values-that-really-ought-to-be-constants.  I ended up using Pyro4 as the 
connection method.  It has performed well. The default operation was 
remarkably good, and after a bit of work on timing and retry logic, it 
passes tests even across VLAN on a less-than-wonderful Nigerian Internet. I 
have tested briefly using Python 2.5 and 3.3, IPv6, and extensively using 
Python 2.7 on IPv4. My final test consisted of the two suites (dbapi20 and 
adodbapitest) running on Ubuntu 13.4, using two Windows proxy servers, one 
serving SQL Server (on Windows Server 2008), the other (Windows 7) serving 
Jet, MySQL, and PostgreSQL. The latter two database were in America on 
different Ubuntu servers, so this was not a trivial test. I will not 
release this version of adodbapi until I have had time to do more extensive 
testing with IronPython and Python 3.2 -- besides, I am still making minor 
adjustments as django integration continues.

2) The code changes to have django-mssql.base call adodbapi, rather than 
its built-in fork are complete.  The forked code has been removed from my 
copy, and django is starting to run its tests.  The creation and deletion 
of the test database are done in autocommit mode, so I had to use switched 
autocommit (newly supported in adodbapi). The backend now defaults 
"autocommit = django.VERSION > (1,6)" and allows settings.AUTOCOMMIT to 
override the default. [The Manfre/Thompson fork already had a form of 
switchable autocommit, so the adaptation was trivial. They had already done 
the hard work.] This is all running django on Windows using the 1.5 stable 
branch.  

3) I will try to support 1.5 and 1.6 from the same code base.  I have not 
found any sticky spots yet.

4)  Today, I plan to try the same tests with django running on Linux using 
the proxy server. The only change should be adding   
<>  to my configuration. 
The backend will switch to using the proxy adapter when it sees that 
option. I am toying with an "auto_proxy" option which turns on 
auto-magically when it sees that it is running on non-Windows.  Is that too 
much, or a good idea?  What if it is called "macro_auto_proxy"?
--
Vernon Cole

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