Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

[Dmitry Gladkov]

Hi,

Making Django upgrades less painful is a great goal, but I believe the
patching Django and restoring removed functionality is not the right
solution. JavaScript world has the same problem with far more frequent
major compatibility breakages and they solve it with automatic codebase
upgrade tools like jscodeshift [1]. This approach uses AST transformation
similar to what 2to3 does, but with configurable transformation rules.
There's also another project written in Python [2] that implements simpler
and more general, but less reliable regex-based approach.

I believe adding codebase upgrade rules for each major Django release and
giving users ability to apply them by running something like  ./manage.py
upgrade_from 1.7 after Django upgrade will greatly simplify upgrading of
large Django projects.

[1] https://github.com/facebook/jscodeshift
[2] https://github.com/facebook/codemod

--
Best wishes,
Dmitry Gladkov

On 22 January 2017 at 20:53, Pascal Chambon <chambon.pas...@gmail.com>
wrote:

> Hi,
>
> @James Pc - thanks for the support, if you happen to miss some fixers in
> DCP and don't have the opportunity to contribute them, please open an issue
> so that I have a look
>
> @Tim Graham & James James Bennett - from what I sum up, the new policy
> simply extends the delay between breaking changes, and so the overall life
> expectancy of django reusable apps, but other limitations remain as is.
> I've detailed the misc benefits that a compatibility layer would bring, I
> just hope not too many people needing big compatibility will fail to learn
> about django-compat or DCP, and complicate their life with handmade shims
> or useless forks.
>
> regards,
> Pascal
>
> 2017-01-16 10:48 GMT+01:00 James Bennett <ubernost...@gmail.com>:
>
>> On Sun, Jan 15, 2017 at 1:09 PM, Pkl <chambon.pas...@gmail.com> wrote:
>>
>>> My bad, if people are guaranteed 2 x 24-month cycles before a feature
>>> gets removed, it's already much better. However, the same pattern as
>>> previously appears in docs : "each feature release will continue to have a
>>> few documented backwards incompatibilities where a deprecation path isn’t
>>> possible or not worth the cost.". I might be paranoid, but I foresee lots
>>> of dependency breakages in the future, if incompatibilities continue to be
>>> introduced at developer's will History proved even seemingly harmless
>>> django modifications (ex. import aliases removed) broke external code,
>>> sometimes forcing "commit reverts" in django code.
>>>
>>
>> Just to clarify, the future plan -- beginning with Django 2.0, the next
>> release after 1.11, which is about to feature-freeze -- is:
>>
>> 1. Releases go in a cycle of X.0, X.1, X.2, (X+1).0. So, for example,
>> 2.0, then 2.1, then 2.2, then 3.0.
>> 2. Each X.2 is an LTS.
>> 3. Code which runs with no deprecation warnings on an LTS will also run
>> (though may raise deprecation warnings) on the next LTS.
>> 4. Thus, any time you run on an LTS with no deprecation warnings, you
>> know you're safe to upgrade to the next LTS. And once you clear any new
>> deprecation warnings on the new LTS, you know you're clear to upgrade to
>> the one after that.
>>
>> Regarding backwards-incompatible changes in general: they do happen, but
>> they also follow the guidelines in the API stability document. When they
>> occur, it's because there's a security issue or larger bug being solved.
>> Additionally, many of the seemingly-large list of such changes each release
>> are, if you dig into them, changes to private/internal or at least
>> undocumented APIs not covered by the stability policy, but we've learned
>> people still rely on those APIs and so we document changes to them even if
>> we don't guarantee stability in them.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/django-developers/dKeLB-qR7lY/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/ms
>> gid/django-developers/CAL13Cg8_0BRpu1b_zz2Dx_YXcLaXGXw8Qw0jf
>> A_uDhaxt%3DD_%3Dw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAL13Cg8_0BRpu1b_zz2Dx_YXcL

Re: Check if dependencies are up to date

[Dmitry Gladkov]

On 16 January 2017 at 15:36, Adam Johnson <m...@adamj.eu> wrote:

> The signals as proposed can't really be used for the staticfiles override,
> since that requires subclassing and wrapping a function to change the
> handler ( source
> <https://github.com/django/django/blob/master/django/contrib/staticfiles/management/commands/runserver.py>
> ). If there are other use cases I think they'd also normally be better
> handled by more specific signals, e.g. post_migrate
> <https://github.com/django/django/blob/3c447b108ac70757001171f7a4791f493880bf5b/django/db/models/signals.py#L59>,
> rather than a generic all-commands signal.
>

I agree that staticfiles override is a bad example as signals should not be
used to alter it's sender's behavior, however generalizing
pre_migrate/post_migrate into command signals doesn't seem like a bad idea
to me. Anyway, I created a PR with PoC implementation of command signals
with slightly different usage that my previous example code:
https://github.com/django/django/pull/7857

--
Best wishes,
Dmitry Gladkov

-- 
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/CA%2BkbqrXdQgeedhNAW_1CnM0dKuw-RHcrCP2JAB_%2B-cGaxuLeVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Check if dependencies are up to date

[Dmitry Gladkov]

Hello,

While I was reading this email I got an idea about generic Django command
signals that might be useful for extending command functionality without
subclassing the Command class and relying on INSTALLED_APPS order.
Something like this:

from django.core.management.signals import pre_command, post_command

def handle_pre(sender, instance):
instance.stdout.write('Hello World')

def handle_post(sender, instance):
instance.stdout.write('Bye World')

pre_command.connect(handle_pre, command='runserver')
post_command.connect(handle_post, command='runserver')

I believe this also can be used by Django itself as there are some cases
where contrib apps override core command functionality (I believe this
happens for staticfiles app overriding runserver)

Should I create a ticket about it?

--
Best wishes,
Dmitry Gladkov

On 16 January 2017 at 14:47, Adam Johnson <m...@adamj.eu> wrote:

> Hi Mathieu,
>
> We implemented something similar at YPlan but discovered that it wasn't a
> good idea as a system check, because if a dependency changes from another
> devs work then often Django can't even start and run the system check.
> Especially a problem when upgrading Django itself! Instead we implemented
> it as a function that runs in manage.py before Django is even loaded.
>
> We open sourced our work as https://github.com/YPlan/pip-lock . Check it
> out.
>
> On Mon, 16 Jan 2017 at 04:18, mathieu.tortuyaux <
> mathieu.tortuy...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> I would propose this new Django feature. Now you can check if your
>> dependencies are up-to-date (e.g with `hypothesis` in attachment picture)
>> (it runs with Python2.7 && Python3.6).
>> It is a good habit to check if dependencies are up-to-date, especially
>> for security reasons.
>>
>> I did not find any references about this in Django issues
>>
>> So I wondering if I can have any feedback on this ?
>>
>> Thank you for taking time to read these words.
>>
>> Mathieu Tortuyaux
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> 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/5a6fb42e-e5c8-4608-9b20-
>> 19fc829473b1%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/5a6fb42e-e5c8-4608-9b20-19fc829473b1%40googlegroups.com?utm_medium=email_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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAMyDDM1CeOVQoH8jN35OwxOJUbhVr
> 99gMtchgFsxbPZXac2tcw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1CeOVQoH8jN35OwxOJUbhVr99gMtchgFsxbPZXac2tcw%40mail.gmail.com?utm_medium=email_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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BkbqrUn%2BRnpfuO48WSo%2B8rrtxy%3D%2BUyQK%2Btn14ADbN2m5NcGtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not able to install Django in Windows10

[Dmitry Gladkov]

Hi Nasif,

My colleague had the same problem couple of days ago with running pip on
Windows and in his case the problem was that antivirus software (Avast in
his case) blocked execution of pip process.

Having said that, this is clearly a pip related problem, so please move
further discussion to pip mailing list

--
Best wishes,
Dmitry Gladkov, mailto:dmitry.glad...@gmail.com

+380 91 303-37-46

On 22 February 2016 at 08:09, Nasif Noorudeen <nas...@gmail.com> wrote:

> I am not able to install Django 1.9.2(any version of Django ) in Windows
> 10. I am using following command to install Django
>
> pip install Django==1.9.2
>
> it is working fine in Windows 8 and Windows 7. It seems like this is is the 
> issue with pip tool
>
> If i simply type pip.exe also nothing is happening in console.
>
> If anyone facing same issue in Windows 10. Please help to solve this
>
> --
> 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/aa1bc911-cf2d-4e41-8872-4382c0133f21%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/aa1bc911-cf2d-4e41-8872-4382c0133f21%40googlegroups.com?utm_medium=email_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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BkbqrVFpzA60fUHBkH6ws0r75EadaTwiChrHDQ9YvmsxWH51A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Storing IP address as integer within database to remove need for full text search

[Dmitry Gladkov]

I like the idea, but I don't like the approach, it should be a
subclass of PositiveIntegerField, as it is an unsigned int on DB
level. Also, I agree with Łukasz that it should support both IPv6 and
IPv4.


--
Best wishes,
Dmitry Gladkov, mailto:dmitry.glad...@gmail.com

+380 91 303-37-46



On Mon, Jul 18, 2011 at 6:21 PM, Javier Guerra Giraldez
<jav...@guerrag.com> wrote:
> On Mon, Jul 18, 2011 at 10:13 AM, Javier Guerra Giraldez
> <jav...@guerrag.com> wrote:
>> On Mon, Jul 18, 2011 at 9:56 AM, Cal Leeming [Simplicity Media Ltd]
>> <cal.leem...@simplicitymedialtd.co.uk> wrote:
>>> It stores the IP address in integer form, meaning the lookups on large
>>> tables are much faster:
>>
>> are they?    hashtables shouldn't be too sensitive to key size, as
>> long as the string size stays bounded... like on IP addresses (max 15
>> chars)
>
> OTOH, for really huge database tables, making the index 4 times
> smaller can be a significant difference on RAM-starved servers
> but to fill 1G can hold something like of 50million IP addresses in
> text form...
>
> --
> Javier
>
> --
> 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.
>
>

-- 
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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Dmitry Gladkov]

Hi Yuri,

At first I thought that we should extend validators logic, but then I
realized that validation and cleaning (agree that 'cleaners' is a
better term than 'processors') are rather different tasks and mixing
them could be ambiguous, not mentioning backwards incompatibile as a
cleaner should return a value whether a validator should not.


--
Best wishes,
Dmitry Gladkov, mailto:dmitry.glad...@gmail.com

+380 91 303-37-46



On Tue, Jul 12, 2011 at 2:09 PM, burc...@gmail.com <burc...@gmail.com> wrote:
> Hi Dmitry,
> I think we could have combination of "validators" + "processors":
> they will return either exception or cleaned value.
> For example,
> SomeField(cleaners=[clean_and_validate_email()])
> Did you mean exactly this or rather separated SomeField(validators=[...],
> processors=[...]) ?
> On Mon, Jul 11, 2011 at 6:31 PM, Dmitry Gladkov <dmitry.glad...@gmail.com>
> wrote:
>>
>> I don't see what's wrong with 'strip' attribute for models.Field,
>> we've already non database-related 'blank' attribute, but I agree that
>> it does not solve the general problem.
>>
>> What I'm thinking about is something like django.core.validators [1],
>> but called 'processors' with the only and main difference that
>> processor returns value which gets passed to the next processor in
>> chain.
>>
>> I'm not sure that it plays nice with existing clean_[fieldname]
>> methods and that 'processor' is a good name either, but I'd like to
>> hear what do you think about this idea.
>>
>> Thanks.
>>
>>
>> [1]
>> https://docs.djangoproject.com/en/dev/ref/forms/validation/#using-validators
>>
>>
>> --
>> Best wishes,
>> Dmitry Gladkov, mailto:dmitry.glad...@gmail.com
>>
>> +380 91 303-37-46
>>
>>
>>
>> On Mon, Jul 11, 2011 at 12:26 AM, Chris Beaven <smileych...@gmail.com>
>> wrote:
>> > To clarify, didn't even notice we were talking about models.Field, I'm
>> > +0
>> > for a 'strip' attribute on the form's field, nothing on the model.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Django developers" group.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msg/django-developers/-/r9DLUCsK6rUJ.
>> > 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.
>> >
>>
>> --
>> 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.
>>
>
>
>
> --
> Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com
>
> --
> 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.
>

-- 
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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Dmitry Gladkov]

I don't see what's wrong with 'strip' attribute for models.Field,
we've already non database-related 'blank' attribute, but I agree that
it does not solve the general problem.

What I'm thinking about is something like django.core.validators [1],
but called 'processors' with the only and main difference that
processor returns value which gets passed to the next processor in
chain.

I'm not sure that it plays nice with existing clean_[fieldname]
methods and that 'processor' is a good name either, but I'd like to
hear what do you think about this idea.

Thanks.


[1] https://docs.djangoproject.com/en/dev/ref/forms/validation/#using-validators


--
Best wishes,
Dmitry Gladkov, mailto:dmitry.glad...@gmail.com

+380 91 303-37-46



On Mon, Jul 11, 2011 at 12:26 AM, Chris Beaven <smileych...@gmail.com> wrote:
> To clarify, didn't even notice we were talking about models.Field, I'm +0
> for a 'strip' attribute on the form's field, nothing on the model.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/r9DLUCsK6rUJ.
> 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.
>

-- 
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: Default project layout / directory structure

[Dmitry Gladkov]

I'm +1 on this. Project conventions tend to be the biggest problem
when adding new people to the team, especially when it comes to
configuration management - everyone has their own way.

It would be great if there will be at least an official list of best
practices on building Django project layout.


On Mar 11, 7:14 am, Simon Litchfield  wrote:
> Who votes we should come up with a django-blessed 'official' default project 
> layout / directory structure?
>
> Might sound like a triviality, but sometimes it's the little things.
>
> 1. Newcomers -- startproject throws 9/10 into confusion and results in a 
> messy first few projects.
>
> 2. Gurus -- each have their own way, what a waste, not DRY.
>
> 3. The new breed of django hosting platforms that are on their way -- gives 
> them something to base their tools on.
>
> Why not have a standard way, standard tools, etc etc- built in, batteries 
> included. DRY.
>
> Whether it be a plain old manage.py-friendly directory layout, something 
> virtualenv+pip powered, maybe something like Lincoln Loop's startproject 
> style, Eric Holscher's, or whatever. Lets not go too nuts on directories 
> though, they get tiring (especially in textmate)
>
> Thoughts?

-- 
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: table prefix and question of possible solution

[Dmitry Gladkov]

Hi Vitaliy,

I'm not a core developer myself, but I found your problem very
interesting. I looked at model
property code and couldn't find any clues about table prefix, so I
wrote a patch and opened a
ticket for your particular problem.

By the way, this is my first patch for Django, so I'm sure I've done
something terribly wrong,
so someone please take a look at it: http://code.djangoproject.com/ticket/15238


Best regards,
Dmitry Gladkov

On Feb 2, 4:19 pm, Vitaliy <ppr.vit...@gmail.com> wrote:
> I have a case where I have a lot of django sites(partially with the
> same code) must run in a single mysql database
>
> in order to avoid conflicts  in django.auth, content-types and other
> models tables for them must have unique prefix (since this data must
> be isolated for each site)
>
> Currently there is no way to set global(or per application) table
> prefix (and all tickets that asked for this closed as invalid)
>
> search in this groups gives nothing
> So my question - was global table prefix for tables  considered ?
>
> and what is the way of doing this without this option(setting) in
> framework ?
>
> The only way I currently see is : handle "class_prepared" signal and
> manually add prefix to table name :
>
> from django.db.models.signals import class_prepared
>
> def handle(sender, *args, **kwargs):
>     sender._meta.db_table = PREFIX + sender._meta.db_table
>
> class_prepared.connect(handle)
>
> BUT documentation says that class_prepard for internal only and
> framework users should not use it?
>
> is there any other option ?

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