Gsoc 2015
Hello, My name is Sharad Boni, currently in the third year of engineering (Information Technology). I want to contribute to the development of Django. I have worked upon Django before and had made a image search engine upon it. I am fluent in python,have considerable knowledge about django and ethical hacking.I was really interested in Security enhancements. Can anyone please help me to get started with it. Thanks -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0f68a37d-23ad-4008-9b33-a8b86fdb8d02%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Interested to contribute to django for gsoc 15 regarding security enhancements
I am in the third year of engineering(Information Technology) I have background in python 2.7 and 3.3 both, have previously made image search engine in django and currently practicing ethical hacking. I would like to contribute to this topic.Could someone please help me regarding 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ca430cf6-a2f2-4024-a2ed-c7a4bb4b1d49%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Adding an option on db_index to not create text/varchar_pattern_ops
Hi Marc, Great, that's very interesting reading! A lot of similarities to what I had in mind and a couple of differences. As I imagine the API, Indexes would be backend-specific rather than generic. Field would have a get_db_indexes() method which took a connection as its first argument like get_db_prep_value(), db_type(), etc. Every backend would implement a common interface to meet the most common needs, and from there its Indexes would be free to diverge. Are the various DBMS's indexes really similar enough that the differences can be abstracted over in an elegant and useful way? What does such abstraction offer? Take the operator class example that prompted this thread: how would TextField specify that it needed a text_pattern_ops index in PostgreSQL? Cheers, Alex On Fri, Mar 20, 2015 at 2:50 PM, Marc Tamlyn wrote: > I have some plans (see https://github.com/django/deps/pull/6) to rework > more widely how indexes are managed and allow finer control over them. It > pretty much includes all the things mentioned by Alex. I'm intending on > doing some work on it over the next few weeks. > > Marc > > On 20 March 2015 at 02:27, Alex Hill wrote: > >> I agree that this is a problem, and I'd like to see more control over >> indexes generally in Django. >> >> However, at first glance I suspect that fixing only your problem would >> mean adding special-case gunk to the Field class in addition to the >> Postgres schema editor where it currently lives[1]. It feels wrong to >> expand this special-casing when other types could benefit from having >> customisable indexes. For instance, the db_index parameter is useless for >> column types that don't work with a btree index, like jsonb and tsvector. >> >> To fix your immediate problem, can't you avoid creating the extra indexes >> by just setting db_index=False, and then use django-json-dbindex to define >> the indexes you DO want? >> >> I would like to see an index API that allowed Field subclasses to >> specify, per-backend, the indexes that should be created if db_index is >> True. Those defaults should be overridable by the user, perhaps by passing >> a sequence of some Index type as the db_index parameter instead of simply >> True or False. >> >> Not all indexes relate to a single field, so it would make sense to also >> be able to register indexes in a model's Meta as well. The Index type >> should be able to use Expressions to create functional and multi-column >> indexes. >> >> So, that's my wishlist. All that said if you can come up with a patch >> that fixes your problem in a sane way, great! :) >> >> Cheers, >> Alex >> >> [1] >> https://github.com/django/django/blob/35b3158d52a5fe51d3b52aec1109a30a73c5abe9/django/db/backends/postgresql_psycopg2/schema.py#L22 >> >> On Friday, March 20, 2015 at 3:44:58 AM UTC+8, rodolphe.q...@novapost.fr >> wrote: >>> >>> As proposed by timgraham in https://code.djangoproject.com/ticket/24507 >>> I open the discussion here. >>> >>> When adding db_index=True on a CharField Django automatically create 2 >>> indexes on some backends as PostgreSQL. But in usage the second index is >>> not always necessary if you never use contains() or similar queries. As you >>> can see here I extracted indexes usages statistics from one of our >>> production server. >>> >>> The index *foo_bar_email_from_create_like* is never use even if >>> *foo_bar_email_from_create* is, and if we look on our queries this is >>> totally logic and regular. And it's the same for *foo_bar_tech_id* and >>> *foo_bar_user_type*, and it's the same on the other table. >>> >>> indexrelname | idx_scan | idx_tup_read | >>> idx_tup_fetch >>> --++ >>> --+-- >>> foo_bar_address_like | 0 |0 | >>> 0 >>> foo_bar_current_profile_id| 1846 | 617 | >>> 236 >>> foo_bar_date_delete | 0 |0 | >>> 0 >>> foo_bar_email_from_create | 31209 |90886 | >>> 21903 >>> foo_bar_email_from_create_like| 0 |0 | >>> 0 >>> foo_bar_entity_id | 8026 |28957 | >>>14 >>> foo_bar_pkey | 1258565593 | 1418841848 | >>> 1194873240 >>> foo_bar_site_id |4495829 | 51000840065 | >>> 3564 >>> foo_bar_tech_id | 25045160 | 28233693 | >>> 25087324 >>> foo_bar_tech_id_like | 0 |0 | >>> 0 >>> foo_bar_user_type | 21428 |263769329 | >>> 216686751 >>> foo_bar_user_type_like| 0 |0 | >>> 0 >>> foo_bar_uuid_like | 0 |0 | >>> 0 >>> foo_bar_uuid_uniq | 13134415 | 13157636 | >>> 12928178 >>> >>> A last point is each
Re: Adding an option on db_index to not create text/varchar_pattern_ops
Hi Alex and Marc, Alex thanks for your answer, to be clear I did not open the discussion to find a solution to resolve my problems, they are done. My goal is to open discussion on indexes support in Dango. And as you right said, the solution is effectively to not create indexes in the models and use and external tool. Marc, I add a look at your PR and it contains a lot of things I thought about these last weeks, thanks for that, I'd love to see Gist and Gin index support in Django, and indeed all other specific indexes in other RDBMS. I did not see if your PR includes partial indexes, have you plan to support them too or not ? Regards -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20b3027f-8030-4a22-a4a5-990eae97ddc1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Pre-DEP: community support of unmaintained versions of Django
Hi All, I am free of 2.6 websites myself (and nearly free of 2.x completely), but I think this makes sense and I'm certainly in favor of community-maintained longer support periods of django versions, assuming people want to do it :) Two thoughts: - This doesn't _need_ to happen through Django officially, but doing it this way has the advantage of receiving pre-notify and the having some of Django's blessing gives more confidence to anyone using it. - I'm not saying anyone wants this, but I could also see the possibility of volunteers wanting to continue 1.4's support on 2.6 and 2.7 only (dropping 2.5 support). If it helps, I have the historical Python support in table form: https://gist.github.com/collinanderson/3597ec51a7d2f1092eb5 Collin On Thursday, March 19, 2015 at 6:59:59 PM UTC-4, James Bennett wrote: > > There's been some recent discussion in a django-users thread[1] about > the impending end-of-life of Django 1.6, which in turn will mean > end-of-life for Django supported on Python 2.6. In addition, the > end-of-life of the current LTS release, Django 1.4, will mean > end-of-life for Django supported on Python 2.5. The following is a > draft of a proposal based on ideas raised in that thread; it should be > considered pre-DEP status, to be elevated to a DEP submission if there > is sufficient support. > > > Abstract > > > The support process for older versions of Django is changed, as > follows: > > * Official support for older versions of Django from the Django core > team will continue to end at the scheduled times (i.e., upon release > of a new minor version for non-LTS releases, at end of advertised > support lifetime for LTS releases). > > * Unofficial support, by persons willing to volunteer their time, will > be permitted through a secondary code repository existing solely to > provide this support. > > * As the official end-of-life of each Django version approaches, the > Django core team will solicit proposals and volunteers to provide > unofficial support for that version past its official end-of-life, > and select maintainer(s) from amongst those volunteers. This support > will be known as "community maintenance". > > > Rationale > - > > For the past five years, Django has been in the process of deprecating > support for older 2.x release of Python, as part of a plan to move > Django toward, first, compatibility with both Python 2 and Python 3 > (completed as of Django 1.6), and ultimately with only Python 3 (in a > future, to-be-determined, release). > > The timeline for this was as follows: > > * May 2010: Django 1.2 instituted a minimum Python version of 2.4. > > * March 2011: Django 1.3 was the final release to support Python 2.4. > > * March 2012: Django 1.4 (LTS) raised the minimum Python version to > 2.5, and was the final release to support Python 2.5. > > * February 2013: Django 1.5 raised the minimum Python version to 2.6. > > * November 2013: Django 1.6 was the final release to support Python > 2.6. > > * September 2014: Django 1.7 raised the minimum Python version to 2.7. > > * Late Q1/early Q2 2015: Django 1.4 and Django 1.6 will reach > end-of-life (the former on a scheduled date, the latter upon the > release of Django 1.8). > > While this process was necessary to achieve at least a minimum of > Python 2.6 (the lowest version enabling compatibility with Python 2 > and Python 3 in a single codebase) and ultimately a minimum of Python > 2.7 (the only Python 2.x release still receiving upstream security > support), and while moving Django in the direction of Python 3 is an > absolute necessity for the future of the framework, this has had an > effect on some users of Django who are effectively locked in to now- > or soon-to-be-unsupported versions of Python by their choice of > operating system and associated support contract. > > In particular, the impending end-of-life of Django 1.6, the final > release which supported Python 2.6, is poised to cut off support for > users of products like Red Hat Enterprise Linux, who may be locked to > Python 2.6 and thus unable to use a supported version of Django past > 1.6 end-of-life (these users continue to receive security support for > Python itself from the operating-system vendor, who provides such > support on their behalf even after official upstream support has > ended; no such support appears to be provided, at this time, for > Django). > > Although these users are not a majority of Django's users, they are > still a significant group, and simply ending their ability to use > Django is likely to be an unacceptable option. But the Django core > team cannot and will not extend the official support lifetimes of > older Django releases; the additional maintenance burden is beyond > that which can be borne, and would impede the future development of > Django. > > This is not the first time in Django's history that a significant > minority of users have been affected by backwa
Re: Gsoc 2015
Unless you can pose some more specific questions, I think it's probably not a good choice for you. On Friday, March 20, 2015 at 4:20:15 AM UTC-4, Sharad Boni wrote: > > Hello, > > My name is Sharad Boni, currently in the third year of engineering > (Information Technology). > I want to contribute to the development of Django. I have worked upon > Django before and had made a image search engine upon it. > I am fluent in python,have considerable knowledge about django and > ethical hacking.I was really interested in Security enhancements. > Can anyone please help me to get started with it. > > Thanks > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/136ab367-126c-4279-9e82-c8cb854dcb6f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Pre-DEP: community support of unmaintained versions of Django
Hi James, Thanks for taking the time to write this up carefully, research the history, etc. I think some form of extended community-based support could work, but I have some concerns about your specific proposal; mostly, that it places too much of the responsibility with the core team. My feeling is that we don't really need a DEP or this much process specified at this point; it'd be plenty for now to simply express guarded openness to the idea of extended community maintenance for 1.6 and/or 1.4 and see if anyone actually steps up to do the work. I'm also curious how this sounds to Christian and Stephen, who asked for the extended support on django-users. Since they're the only ones who have asked, if a proposal along these lines won't work for their cases, then there's not much point in going forward with it. Comments interspersed: On 03/19/2015 04:59 PM, James Bennett wrote: > There's been some recent discussion in a django-users thread[1] about > the impending end-of-life of Django 1.6, which in turn will mean > end-of-life for Django supported on Python 2.6. In addition, the > end-of-life of the current LTS release, Django 1.4, will mean > end-of-life for Django supported on Python 2.5. The following is a > draft of a proposal based on ideas raised in that thread; it should be > considered pre-DEP status, to be elevated to a DEP submission if there > is sufficient support. > > > Abstract > > > The support process for older versions of Django is changed, as > follows: > > * Official support for older versions of Django from the Django core > team will continue to end at the scheduled times (i.e., upon release > of a new minor version for non-LTS releases, at end of advertised > support lifetime for LTS releases). > > * Unofficial support, by persons willing to volunteer their time, will > be permitted through a secondary code repository existing solely to > provide this support. "Permitted" sounds odd to me, since regardless of this DEP I don't think the core team is in a position to forbid anyone else from continuing to patch older Django releases if they want to. (I suppose if we really wanted to we could prevent them from using the Django trademark to describe what they are doing, but IANAL.) I'm also not convinced we should provide a special repo under the django/ org for this. That doesn't bring any technical benefits, just social ones (perception of "officialness"). And I'm not clear that perception of officialness is a good thing - after all, this support is unofficial. So I would lean towards saying that this concept should be well-proven in a third-party repo (created by whoever is doing the work) before we even consider a django/ repo for it. > * As the official end-of-life of each Django version approaches, the > Django core team will solicit proposals and volunteers to provide > unofficial support for that version past its official end-of-life, > and select maintainer(s) from amongst those volunteers. This support > will be known as "community maintenance". This is my strongest objection to the proposal. This whole scheme will only work if the community maintainer is highly motivated, and there's a strong need for the extended community maintenance for a specific release. One indicator of both is that the initiative comes unsolicited from the community. I think it makes sense to clarify our general openness to such initiative, but I'm opposed to adding an additional responsibility to the core team's plate to "solicit proposals and volunteers" for community maintenance of every release that hits EOL. > Rationale > - > > For the past five years, Django has been in the process of deprecating > support for older 2.x release of Python, as part of a plan to move > Django toward, first, compatibility with both Python 2 and Python 3 > (completed as of Django 1.6), and ultimately with only Python 3 (in a > future, to-be-determined, release). > > The timeline for this was as follows: > > * May 2010: Django 1.2 instituted a minimum Python version of 2.4. > > * March 2011: Django 1.3 was the final release to support Python 2.4. > > * March 2012: Django 1.4 (LTS) raised the minimum Python version to > 2.5, and was the final release to support Python 2.5. > > * February 2013: Django 1.5 raised the minimum Python version to 2.6. > > * November 2013: Django 1.6 was the final release to support Python > 2.6. > > * September 2014: Django 1.7 raised the minimum Python version to 2.7. > > * Late Q1/early Q2 2015: Django 1.4 and Django 1.6 will reach > end-of-life (the former on a scheduled date, the latter upon the > release of Django 1.8). > > While this process was necessary to achieve at least a minimum of > Python 2.6 (the lowest version enabling compatibility with Python 2 > and Python 3 in a single codebase) and ultimately a minimum of Python > 2.7 (the only Python 2.x release still receiving upstream security > support), and while movin
Re: Pre-DEP: community support of unmaintained versions of Django
Hi James, When I read your proposal I thought -- "this makes sense, but if maintainers are making this commitment, they should be part of the Django team". Only after reading Carl's comment did I realize that they shouldn't be part of the team in order to keep the "unofficial" aspect. This makes me think that you've drawn the line too close to official extended support. Otherwise I'm +0 on the general concept, mostly because I'm lucky enough to care about Python 3.4 only ;-) -- Aymeric. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mX75eaq3c4w3BFTVUhNEOcTUAGNo-z88z2L4b7ZCY1MwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
