add encoding comment to project all python file
add comment "# coding:utf8# to all python file
- command
add comment "# coding:utf8# to all python file
Adds `--pretty` option to django `./manage.py dumpdata` command, which produces pretty utf-8 strings instead of ugly unicode-escaped s**t: > $ ./manage.py dumpdata app.pricingplan --indent=1 <pre> <code>[ { "pk": 1, "model": "app.pricingplan", "fields": { "name": "\u0411\u0430\u0437\u043e\u0432\u044b\u0439", } }, { "pk": 2, "model": "app.pricingplan", "fields": { "name": "\u0425\u0443\u044f\u0437\u043e\u0432\u044b\u0439", } } ] </code> </pre> > ./manage.py dumpdata app.pricingplan --indent=1 --pretty <pre> <code>[ { "pk": 1, "model": "app.pricingplan", "fields": { "name": "Базовый", } }, { "pk": 2, "model": "app.pricingplan", "fields": { "name": "Хуязовый", } } ] </code> </pre> Forked from an [old versions snippet](https://djangosnippets.org/snippets/2258/)
The Mixin approach for applying permissions to CBV views suffers from 3 issues: 1. you need to read the code to see what permissions are being applied to a View 2. multiple bits of disparate code required to specify, e.g., a simple permission check 3. permissions set on a base class are overridden by permission set on sub-class, unless special care is taken Here's a nice trick, using only built-in django machinery, apply a decorator intended to decorate a django view function to a CBV view. https://docs.djangoproject.com/en/1.11/topics/class-based-views/intro/#decorating-the-class This approach works for any function decorators with arguments - simply wrap it in a function that takes the same arguments: def my_cbv_decorator(*args **kwargs): return method_decorator(a_view_function_decorator(*args, **kwargs), name='dispatch') Use your new CBV decorator to decorate View sub-classes: @my_cbv_decorator('some_parameter') class MyCBView(django.views.generic.TemplateView): pass # dispatch method for this view is now wrapped by a_view_function_decorator Note: you can also pass decorator parameter directly to method_decorator, but wrapping it up like this makes the code read nicer.
output: ``` {u'Ogrenci': [u'Tum okullar', u'Lisans', u'Onlisans', u'Yuksek Lisans / Doktora', u'Ingilizce Hazirlik'], u'Ogretim Elemani': [u'Tum okullar', u'Lisans', u'Onlisans', u'Yuksek Lisans / Doktora', u'Ingilizce Hazirlik']} ```
With this awesome manage.py, it will try to migrate first when called with runserver. Also, this manege.py has super power to be used in your entry point as such: entry_points = { 'console_scripts': [ # u haz a setup.py -> u haz importable module :) 'yourcommand = yourproject.manage:main', ], }, Example output: $ yourcommand runserver Operations to perform: Apply all migrations: auth, contenttypes, admin, sessions Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying sessions.0001_initial... OK Operations to perform: Apply all migrations: admin, auth, contenttypes, sessions Running migrations: No migrations to apply. Performing system checks... Username (leave blank to use 'jpic'): Email address: [email protected] Password: Password (again): Superuser created successfully. Welcome in 2017, where automation is king System check identified no issues (0 silenced). September 17, 2017 - 21:21:41 Django version 1.9.10, using settings 'crudlfap_example.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C. Extra note: it doesn't matter if migrate crashes for now, since django runserver doesn't support not being able to connect to database. So most of the time I hope to shouldn't need to disable this hack.
Place the code any admin.py file in your registered apps
If the primary key on a table is an integer, it can be desirable after a lot of adding and removing either during testing (as was my case) or otherwise, to tidy up the key space a little and see the primary keys run up as unbroken sequences from 1. An excellent snippet here: https://djangosnippets.org/snippets/2915/ showed us how change the primary key value from in a given table and in all tables that relate to it (have a foreign key pointing into it). We can exploit that to achieve this outcome with integrity. For any given table we just fetch the primary keys into a sorted list and then walk the list assigning key 1, 2, 3, 4 etc where needed (if it doesn't already have that key).Because our list is sorted we're always moving tuples down the ladder of available keys to next empty slot basically until we've compacted the whole list. And voila. Mission accomplished. Works in with database introspection, in part because the integrity of relations is a little obscured by the ORM which hides intermediary tables in ManyToMany relationships and such. At the database API level these concerns all disappear. Built and tested with Django 1.11 but the form only goes to 1.10 here. Not even sure it works on 1.10. Certainly the snippet I based it on didn't work in 1.11 and need some updating.
An upgrade to the excellent snippet by variant at https://djangosnippets.org/snippets/2915/ Upgraded to work with Django 1.11.
This is an example of Django auth with JWT tokens, you can find how to add [jwt auth to Django Rest Framework in this tutorial](https://www.techiediaries.com/django-rest-framework-jwt-tutorial/)
django online users, usage: `{{ request.online_now }}` or `{{ request.online_now_ids }}`, complete tutorial: https://python.web.id/blog/django-count-online-users/, this snippet forked from: https://gist.github.com/dfalk/1472104
Easy way to get base64 for the image to display in the template, eg: `<img src="{{ post.get_cover_base64 }}">`
1. Next to the Play button you can Edit Configuration 2. Click the green + on the left, add 2 "Django Server". Call one DEBUG, call the other RUN. 3. Add "DEBUG False" to RUN in its "Environment variables" 4. Add "DEBUG True" to DEBUG in its "Environment variables" (make sure the port # is different from RUN!) Change `DEBUG = True` in `settings.py` to the below code Go back to the main IDE window and either select RUN or DEBUG and go to localhost/404 to either see the dev debug 404 or your custom `404.html` (that you obviously previously made in the `/templates/` folder ;)
You can place this snippet in management/commands/ and have it upload files from disk into objects in your database. Usage: ``` python manage.py upload_file_to_model myapp mymodel myfield 1 field_name /some/file/path ```
This is just modified version of [friendly id](https://djangosnippets.org/snippets/1249/) for make this script compatible with python 3.x Invoice numbers like "0000004" are a little unprofessional in that they expose how many sales a system has made, and can be used to monitor the rate of sales over a given time. They are also harder for customers to read back to you, especially if they are 10 digits long. This is simply a perfect hash function to convert an integer (from eg an ID AutoField) to a unique number. The ID is then made shorter and more user-friendly by converting to a string of letters and numbers that wont be confused for one another (in speech or text). To use it: import friendly_id class MyModel(models.Model): invoice_id = models.CharField(max_length=6, null=True, blank=True, unique=True) def save(self, *args, **kwargs): super(MyModel, self).save(*args, **kwargs) # Populate the invoice_id if it is missing if self.id and not self.invoice_id: self.invoice_id = friendly_id.encode(self.id) self.save() if self.id and not self.invoice_id When an object from this model is saved, an invoice ID will be generated that does not resemble those surrounding it. For example, where you are expecting millions of invoices the IDs generated from the AutoField primary key will be: obj.id obj.invoice_id 1 TTH9R 2 45FLU 3 6ACXD 4 8G98W 5 AQ6HF 6 DV3TY ... 9999999 J8UE5 The functions are deterministic, so running it again sometime will give the same result, and generated strings are unique for the given range (the default max is 10,000,000). Specifying a higher range allows you to have more IDs, but all the strings will then be longer. You have to decide which you need: short strings or many strings :-) This problem could have also been solved using a random invoice_id generator, but that might cause collisions which cost time to rectify, especially when a decent proportion of the available values are taken (eg 10%). Anyhow, someone else has now already written this little module for you, so now you don't have to write your own :-)
This mixin is for class based views. Kwargs passed from url patterns to views via the dispatch method.
3109 snippets posted so far.