Re: ImportError: cannot import name actions

[Andrew Pashkin]

Got this while tried to laucnh Djangos test suite on 
fb1e3435a4d7e0265f19a1a9f130c9485fb8dfe9

On Tuesday, October 15, 2013 4:56:56 PM UTC+4, rok wrote:
>
> I have recently been testing the 1.6b4 tag with a new app we are writing, 
> using apache and wsgi. However, I could not get rid of the following issue 
> happening on every request:
>
> ...
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1]   File 
> "/home/rok/apps/django-trunk/django/contrib/gis/admin/__init__.py", line 2, 
> in 
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] from 
> django.contrib.admin import autodiscover, site, AdminSite, ModelAdmin, 
> StackedInline, TabularInline, HORIZONTAL, VERTICAL
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1]   File 
> "/home/rok/apps/django-trunk/django/contrib/admin/__init__.py", line 6, in 
> 
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] from 
> django.contrib.admin.sites import AdminSite, site
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1]   File 
> "/home/rok/apps/django-trunk/django/contrib/admin/sites.py", line 3, in 
> 
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] from 
> django.contrib.admin import ModelAdmin, actions
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] ImportError: cannot 
> import name actions
>
> by doing the following change, I could get rid of what looked like a 
> circular import issue:
> --- a/django/contrib/admin/sites.py
> +++ b/django/contrib/admin/sites.py
> @@ -1,6 +1,7 @@
>  from functools import update_wrapper
>  from django.http import Http404, HttpResponseRedirect
> -from django.contrib.admin import ModelAdmin, actions
> +from django.contrib.admin import ModelAdmin
> +from django.contrib.admin.actions import delete_selected
>  from django.contrib.admin.forms import AdminAuthenticationForm
>  from django.contrib.auth import REDIRECT_FIELD_NAME
>  from django.contrib.contenttypes import views as contenttype_views
> @@ -46,7 +47,7 @@ class AdminSite(object):
>  self._registry = {}  # model_class class -> admin_class instance
>  self.name = name
>  self.app_name = app_name
> -self._actions = {'delete_selected': actions.delete_selected}
> +self._actions = {'delete_selected': delete_selected}
>  self._global_actions = self._actions.copy()
>  
>  def register(self, model_or_iterable, admin_class=None, **options):
>
> Switching to 1.5.4 resolves the issue as well (even though the sites.py 
> code is the same). What is more, this did not occur in the development 
> environment when using the runserver run.
>
> Any clue?
>

-- 
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/ed8449fb-152d-46f4-b8d0-4d4944121d45%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Improving the Test-Suite

[Andrew Pashkin]

BTW - I recent;y trid to run Django test suite with Py.test and 
pytest-django plugin and achived some success - main problem, that some 
tests are failing and reason of it is not clear to me yet.
This solution require pytest, django-pytest packages and lightweight 
configuration.
See patch in attachment. I was tested it with Django 1.4.10. Command that I 
used: 
PYTHONPATH=..:$PYTHONPATH py.test


On Monday, February 17, 2014 4:06:33 PM UTC+4, Akshay Jaggi wrote:
>
>
>
> On Saturday, 15 February 2014 20:47:37 UTC+5:30, Chris Wilson wrote:
>>
>> Hi all, 
>>
>> It just occurred to me that most classification systems are completely 
>> arbitrary and therefore not very useful. What's a "system" test and how 
>> would I know whether I need to run it? 
>>
>
> For development purposes we can stick to certain pre-defined and fixed 
> categories. 
> Users may define their own categories according to their own needs and 
> wishes.
>  
>
> But some ideas that I can think of that might be useful are: 
>>
>> * Automatically building test coverage maps for each test, and reversing 
>> them, so we can see which tests touch the line(s) of code that we just 
>> modified, and rerun them easily. A good smoke test to run while modifying 
>> part of Django. 
>>
>
> py.test has a plugin for coverage reporting -> 
> https://bitbucket.org/memedough/pytest-cov/overview.
> Might turn out to be helpful.
>  
>
>>
>> * Categorising by imports: run all tests that import django.db or 
>> django.core.http for example. Not perfect, some tests may touch 
>> facilities 
>> without needing to actually import them, but it would be quick and cheap. 
>>
>>
> This looks like another possible way we can go.
>  
>
>> * Profile and speed up the test suite, so that we can run all tests more 
>> quickly, especially with databases like postgres where it takes an hour 
>> to 
>> run them all. 
>>
>>
> Py.test -> we can parallelise and distribute test loads.
>
>
> --
> Akshay Jaggi
>

-- 
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/d5f33c9e-89f5-4299-acdc-8f1456d04109%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
diff --git a/tests/conftest.py b/tests/conftest.py
new file mode 100644
index 000..ed65e84
--- /dev/null
+++ b/tests/conftest.py
@@ -0,0 +1,26 @@
+# coding=utf-8
+from collections import deque
+from genericpath import isdir, exists
+
+__author__ = 'andrew'
+from runtests import setup as django_tests_setup
+from os.path import dirname, split, basename, abspath, normpath
+
+
+def pytest_configure(config):
+TESTS_PATH = dirname(abspath(__file__))
+
+modules = deque()
+for path in config.getoption('file_or_dir'):
+abs = abspath(path)
+if not exists(abs) or TESTS_PATH not in abs or TESTS_PATH == abs:
+continue
+module_path = path
+while not isdir(module_path):
+module_path = dirname(module_path)
+module_name = basename(normpath(module_path))
+modules.append(module_name)
+
+django_tests_setup(0, modules)
+
+
diff --git a/tests/pytest.ini b/tests/pytest.ini
new file mode 100644
index 000..6a83477
--- /dev/null
+++ b/tests/pytest.ini
@@ -0,0 +1,3 @@
+[pytest]
+python_files=test*.py
+DJANGO_SETTINGS_MODULE = test_sqlite
\ No newline at end of file

Re: `prefetch_related` for non-homogenous data and "weak" lookups through GFKs

[Andrew Pashkin]

Ive made workaround for this case as external 
app<https://bitbucket.org/andrew_pashkin/django-deep-prefetch>
.

On Sunday, February 9, 2014 12:14:32 AM UTC+4, Andrew Pashkin wrote:
>
> With GenericForeignKey functionality, it is possible to refer to 
> arbitrary model. Let's ay we have Like model, which is naturally may 
> refer to many types of data (blogposts, users, photos, comments, etc). And 
> so it is desireable to be able to perform such lookups: 
>
> Like.objects.prefetch_related('content_object__followers', 
> 'content_object__people_on_photo')
>
> where followers is the field of User model and people_on_photo the field 
> of Photo model.
>
> Currently .prefetch_related will raise an error like 
>
> Cannot find field `followers` on Photo object. 
>
> because currently it is assumed that lookups are 'strict', and data for 
> each lookup is homogenous (stealed the word form comment in sources :). 
> So I think it would be nice to implement feature for non-strict lookups in 
> addition to #17001‎.
> <https://code.djangoproject.com/ticket/17001‎>
>

-- 
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/8b40412d-1740-4389-992c-2b5363e29545%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Andrew Pashkin]

>
>
>>1. Distributed testing (speed up, especially on multi-core machines), 
>>Line Coverage, etc using plugins
>>
>> How would this work? We still have shared resources like the database 
> where you can't just run 10 Test against in parallel.
>

There is django plugin for py.test 
exists, it is able to create separate 
DBs for each process.

On Thursday, February 27, 2014 11:59:56 PM UTC+4, Florian Apolloner wrote:
>
> Hi Akshay,
>
> On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote:
>>
>> *Why Py.Test?* (http://pytest.org)
>>
>>1. Widely Used
>>
>> So is nose and unittest, you'll need to add a bit more info to such 
> statements. 
>
>>
>>1. Better reporting
>>
>> Better how exactly? 
>
>>
>>1. Distributed testing (speed up, especially on multi-core machines), 
>>Line Coverage, etc using plugins
>>
>> How would this work? We still have shared resources like the database 
> where you can't just run 10 Test against in parallel.
>
> Cheers,
> Florian
>

-- 
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/17553c1f-ec24-401f-8b62-91d39f1fbe54%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

[Andrew Pashkin]

The problem is actually exists, I also want to find a way, how to rid my 
cleints of that crazy wording in admin-site.
I've found promising package - pymorphy2 
(https://github.com/kmike/pymorphy2), it can find grammatical information 
for words and translate words to needed forms. So all what is needed to 
solve this problem - is some way, in Django, that would allow to inject 
pymorphy in admi, and Django actually has it - for now I think it would be 
enough to override templates of admin and use pymorphy within them. 

On Wednesday, March 12, 2014 10:52:59 PM UTC+4, Алексей Сидаш wrote:
>
> Hello there!
> My name is Alexey and I would like to do some work for django project. I'm 
> from Russia, and English is not my native language(my native one is 
> Russian). Russian localization of django admin is poor. It is even worse 
> then my English :D. Of course, I do not like it, I believe that Meta 
> property of Admin-related objects (like ModelAdmins and Inlines, for 
> example) are suitable for storing all the custom letters(Such as "Add new 
> %modelname%") from admin-forms. To get it done, we need formalizing meta 
> objects
>  and 
> adding custom fields for labels in admin forms. then, we only need to make 
> some template changes.This will make admin panel more customizable and 
> translatable. 
>
> Also, I think we may add custom admin widgets for every application, for 
> example, we define a Meta class in application __init__.py, where we make 
> add property widget_template, and add there something custom instead of 
> default links.
> Good luck, thanks for your time. 
>
> P.S. I have got some open-source experience connected with django, see 
> https://github.com/iLikeKoffee/tiny_feedback . It is not ready enough for 
> usage, but you can see my code. I want to make possible adding feedback 
> functionality by couple of shell commands and config variables.
>

-- 
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/8390313f-e9c9-48ab-9956-bf40cf846936%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

[Andrew Pashkin]

Proof of concept for pymorphy solution:
https://gist.github.com/StillNewb/9703843

On Saturday, March 15, 2014 9:20:24 PM UTC+4, Алексей Сидаш wrote:
>
> Hello
>
> Yes, Adam Mesha seems to be right. The problem of translation is very 
> complicated.
> I see only one solution, all the text in admin panel should not be 
> generated dynamically.
> I mean, that code like *"Add new {{ model.verbose_name }}"* makes 
> translation to languages like Russian very difficult, because of 
> grammatical matching between words in sentenses.(For example, subject(noun) 
> and predicate(verb) in Russian must have the same grammatical gender and 
> etc). That's why, words should not be translated in isolation, sentenses 
> must be "atomical" unit of translation.
> No doubdt, we need some consultation from other language speakers, 
> unfortunately, I speak only Russian and English, but I strongly believe 
> that "atomicity" of sentenses is the most suitable solution for this case. 
> It is not too much complicated as pymorphy, but good enough to solve 
> existing problems. 
> Rough "plan" is:
>
>1. Put all the letters from admin panel into *.po files as message ids.
>2. Including dynamically generated, because every single one should 
>have own translation.
>3. Second item means, that this files should be generated with shell 
>command(for example).
>4. If there are no translations yet, framework should fallback to 
>current solution, or to English(Fallback should be discussed).
>
> For example, in application directory *django-admin.py translate-admin 
> *command 
> creates folder named admin-translations with structure like this:
>
> admin-translations/
> |ModelOneLetters.po
> |ModelTwoLetters.po
> |...
>
> And example of ModelOneLetters.po file is:
>
> #: Add new item to database letter.
> msgid "Add new ModelOne item"
> msgstr "Добавить первую модель"
>
> #: Edit item letter.
>
> msgid "Edit ModelOne"
>
> msgstr "Редактировать первую модель"
>
> ...
>
> P.S. Feel free to criticize it, especially, if your native language has 
> translation problems. I believe that this problem's solution cannot be 
> found without consultation with different language speakers. 
>

-- 
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/9f82a32d-80ba-4e46-b750-e20fe11f3043%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Andrew Pashkin]

Some Pytest advocacy:
1) Pytest has convenient tests collection options - you can just specify 
folder to run all tests in it. It is also possible to filter tests by 
regex, and select specific ones.

2) PyUnit:

class MyTestCase(TestCase):
def test_something(self):
   expected_content = ...
   response = self.client(...)
   self.assertEqual(expected_content, response.content)   

Pytest:

def test_something(client): 
expected_content = ...
response = self.client(...)
assert expected_content == response.content

Pytest style is cleaner and complies PEP8. Assertions with assert are more 
readable. It is also possible to group tests, by placing them into class, 
without subclassing something.
4) In Pytest it is possible to define setup functions for modules, classes 
and specific tests.
5) Pytest also has fixture mechanism, which allows to use additional 
resources in tests by specifying fixture names as an arguments (like client) 
- it is good alternative to using setUp's and subclassing something.
6) pytest-xdist plugin provides parallel execution of tests.
7) Pytest has features for writing parametrized tests.

So Pytest is kind of cool and it is easy to migrate to it.

On Friday, February 28, 2014 3:42:17 AM UTC+4, Russell Keith-Magee wrote:
>
>
> On Fri, Feb 28, 2014 at 4:17 AM, Gwildor Sok 
> > wrote:
>
>> Personally I'm a big fan of Py.test, simply because it's so simple and 
>> Pythonic to use. Simple functions with simple assert statements. That's 
>> all. For me this significantly lowers the threshold to write tests and 
>> requires less effort, which in the end results in way more tests written in 
>> Py.test than the testsuite Django is currently using.
>>
>
> This is an argument that I've never understood. Why is typing:
>
> class MyTestCase(TestCase):
>
> such a burden? Because once you've typed that, everything else in the 
> class is "just a method". However, you also get the added benefit of test 
> grouping, and if you've got common setup/teardown requirements, the class 
> provides a place to put them.
>
> I know py.test has a lot of fans, but I'm seriously unconvinced by the 
> "it's so easy to write tests" argument.  
>
> For this proposal to be acceptable to core, it's going to need to start 
> with a *comprehensive* analysis of why py.test is a better approach to 
> take. Don't just assume everyone is on board.
>
> Yours,
> Russ Magee %-)
>

-- 
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/f1133fe6-bd1c-4641-857a-e721e26e4e23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Andrew Pashkin]

...Sometimes it gets different results (if one of the tested methods 
has side effects) and then the assertion message makes no sense, hides 
the problem, or pytest breaks.


* It makes it much harder to write custom assertions and get 
meaningful display on error.
Can you give an examples for cases with messages/breakings and for 
custom assertions?


Regarding magic in Pytest - yeah - there is some =))
But if think deeper, inheritance and self is also magic, and Pytest just 
uses its own magic (dependency injection) that is differs from OO magic =)


Actually it would be interesting to discuss cases where Pytest cant 
handle (or handle with convennience) what PyUnit can and vice versa.



On 06.04.2014 21:02, Chris Wilson wrote:

Hi Andrew,

I'm not a Django core contributor but just a user and occasional 
patcher. I submit some comments on this proposal in the hope that they 
will be useful.


On Sun, 6 Apr 2014, Andrew Pashkin wrote:


Some Pytest advocacy:
1) Pytest has convenient tests collection options - you can just 
specify folder to run all tests in it. It is also possible to

filter tests by regex, and select specific ones.


I do use pytest and it has a lot of good points. Running all tests in 
a directory or a specific file is one of them, as is the better test 
selection logic.



class MyTestCase(TestCase):
def test_something(self):
expected_content = ...
response = self.client(...)
self.assertEqual(expected_content, response.content)

Pytest:

def test_something(client):
expected_content = ...
response = self.client(...)
assert expected_content == response.content


But this is not one of them, at least not for me. I strongly dislike 
this style of assertions:


Pytest style is cleaner and complies PEP8. Assertions with assert are 
more readable.


* The difference between "self.assertEquals(a, b)" and "assert a == b" 
is minimal for me.


* It hides a LOT of magic in how pytest goes back and evaluates the 
assertion's arguments again if the assertion fails. Sometimes it gets 
different results (if one of the tested methods has side effects) and 
then the assertion message makes no sense, hides the problem, or 
pytest breaks.


* It makes it much harder to write custom assertions and get 
meaningful display on error.


It is also possible to group tests, by placing them into class 
without subclassing something.


Grouping tests with decorators allows tests to be members of multiple 
suites, it's true. However this is not something that I've ever needed.


And losing the power of inheritance to add methods to my test classes, 
by not putting tests into classes, is enough to kill this style 
completely for me. I write a LOT of my own assertions:


https://github.com/aptivate/django-harness/tree/master/django_harness

4) In Pytest it is possible to define setup functions for modules, 
classes and specific tests.


I can do this by adding mixins to test classes. Works fine for me, and 
less magical.


5) Pytest also has fixture mechanism, which allows to use additional 
resources in tests by specifying fixture names as an arguments (like 
client) - it is good alternative to using setUp's and subclassing 
something.


We have named fixtures in Django test classes already, so I don't see 
that as much of an advantage. We can't easily add fixtures in mixins 
at the moment. I've not needed that so far.



6) pytest-xdist plugin provides parallel execution of tests.
7) Pytest has features for writing parametrized tests.

So Pytest is kind of cool and it is easy to migrate to it.


I don't think it's necessary or wise to rewrite the test suite to use 
pytest-style assertions. But better integration of Django and Pytest, 
and the ability to write tests with Pytest-style assertions if you 
like, would certainly have my support (fwiw).


Cheers, Chris.


--
С наилучшими пожеланиями, Андрей Пашкин.
м.т - +7 (985) 898 57 59
Skype - waves_in_fluids
e-mail - andrew.pash...@gmx.co.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5341952A.8000201%40gmx.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

[Andrew Pashkin]

Another advantage of Pytest is its ability to launch tests written in 
all styles - PyUnit, Nose, and Pytest own style.
Recently I understood that it is a good practice to launch tests not 
only for project, but for all packages it uses before deployment - to 
ensure that nothing is broken (like missing system library that causes 
failure in functionality of image manipulation package, etc).


--
С наилучшими пожеланиями, Андрей Пашкин.
м.т - +7 (985) 898 57 59
Skype - waves_in_fluids
e-mail - andrew.pash...@gmx.co.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/536C88DE.80402%40gmx.co.uk.
For more options, visit https://groups.google.com/d/optout.