FYI

[Ahmad]

A list of open source software is available at http://www.osslinks.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.

Re: Feedback on ticket 7777

[Farhan Ahmad]

The existing patch and tests are coded to behave like this so those should
be good.  I added our discussion to the ticket for historical purposes.  I
don't have to do anything more from here on so I will wait for the final
decision.

Thanks,
Farhan

On Wed, Dec 9, 2009 at 4:41 AM, Russell Keith-Magee
wrote:

> On Tue, Dec 8, 2009 at 10:18 AM, thebitguru  wrote:
> > OK, here is what I have gathered about the databases listed under
> > DATABASE_ENGINE [4].
> >
> > Postgresql 8: Supports all three, +/-Inf and NaN [0]
> > MySQL: No support for either NaN or Inf [1]
> > sqlite3: No support for either NaN or Inf [2]
> > Oracle: Supports all three [3]
> >
> > So, we have a 50/50 split.  What do you say?
>
> Combine the complete absence of support in SQLite and MySQL with my
> previous comment about the nonsensical nature of NaN and Inf as user
> inputs, and my gut reaction is that NaN and Inf should be rejected as
> invalid inputs. I'm willing to be convinced otherwise, though.
>
> Yours,
> Russ Magee %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.

Cutting applications vertically, like multiple weblogs software

[Ahmad Alhashemi]

Hello,

Immagine that I created a weblog application. Then I decide to make it
accomodate multiple weblogs, by adding a weblog model and weblog_id to
all records in the application.

Is there an easy way to achieve this without having to change all the
model code in the application? I mean so that I don't have to go to the
"post new entry" view for example and add some code to make sure the
post is added to the correct weblog, then change the "view entries"
view to filter comments to only display the ones made in that weblog,
..etc.

What I was thinking is someway of partitioning certain models then
deciding the partition to be used somewhere outside the scope of any
certain view.

I hope that my point is clear.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Cutting applications vertically, like multiple weblogs software

[Ahmad Alhashemi]

Hi Malcolm,

Thank you for your reply. Sorry that my first email wasn't clear.

I wasn't asking on how to add this feature to an actual application I
currently have, I'm asking for pointers because I want to add a new
feature to Django's core that will make it easier to add such a feature
to any Django application.

It is difficult for me to give an example of this feature because I've
never seen it implemented anywhere else, but I've been thinking about
it for a very long time.

Let me get back to the weblog_id example. Assume that I'm giving
weblogs as subdomains and putting some code that will deduce the
weblog_id from the subdomain and have it available for all views.

Then in the entries list, instead of displaying all entries, I will
have to filter by weblog_id. In the RSS feeds, I will have to filter by
weblog_id too. In the display all comments view I will have to filter
by weblog_id.

See the pattern here?

Almost everything in the application is filtered by weblog_id.

When it comes to creating new objects, another pattern emerges.
Everytime you create a new object, you will have to set the weblog_id.
Everytime it will be the same line of code setting the weblog_id of
that object to the weblog_id deduced at the initial processing of the
request.

This is not very DRY.

I have two ideas on how to fix this.

The first one is to provide a feature in models that will allow me to
pre-define some filters. For example, I can put one line that will make
the ORM always filter the results of a certain object by weblog_id
without having to specify the filter everytime something is retrieved.

Then provide another feature to the ORM to define the default value of
a certain parameter in this particular request. So that I can say
somewhere outside of all specific views that I want the weblog_id of
any newly created posts to be set to a certain value without having to
specify it everywhere a new post object is created.

The second idea is to provide this functionality at a higher level,
where you can configure Django somewhere to split certain models by
certain other models. For example, tell it to split the private
messages model by the users model.

This feature will shine in areas where there is a major splitting
variable that is splitting all the tables of the database almost to the
extent that you can use seperate databases (but you don't want to do
that). In these cases, filtering of the results by that variable is the
rule, not the exception.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Cutting applications vertically, like multiple weblogs software

[Ahmad Alhashemi]

Hi Luke,

I agree that explicitness is better. But I think implicit filtering
here is not that bad for two reasons. The first is, as I said, it is
the rule not the exception. The second is that it makes it extremely
easy to start your application as a single site application then turn
it into a multi-site application.

In all the other solutions, a lot of view code has to be changed when
you decide to turn a single site application into a multi-site one.

Besides, I think of this feature more as DRY than as implicit parameter
setting. It is in a way similar to authentication code. You don't have
to repeat authentication code in every view becasue authentication is
the rule not the exception.

The same way, you don't have to add code to tell the view that the
table contains records for many weblogs and we are only interested in
one weblog at a time. You will almost never run a query without
specifying the weblog_id because the weblogs are completely seperate,
and as I said before, you can almost put each weblog's data in its own
database, but you don't want to do that.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Cutting applications vertically, like multiple weblogs software

[Ahmad Alhashemi]

Sorry again everyone. I don't actually have a specific application.
Allow me to check all the suggestions, take a better look at Django
then I promise I'll come back and summarize my findings.

In the mean time, does the need to tie the views with the models also
apply to the proposed Row Level Permissions?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Model inheritance API

[Ahmad Alhashemi]

Malcolm Tredinnick wrote:
> ---
> 1. Abstract Base class
> ---
> One use-case for subclassing is to use the base class as a place to
> store common fields and functionality. It is purely a "factor out the
> common stuff" holder and you don't ever intend to use the base class on
> its own. In the terminology of other languages (e.g. C++, Java), the
> base class it is an abstract class.
>
> At the database level, it makes sense to store the fields from the base
> class in the same table as the fields from the derived class. You will
> not be instantiating the base class (or querying it) on its own, so we
> can view the subclassed model as a flattened version of the parent +
> child. For example,
>
> class Thing(models.Model):
>name = models.CharField(...)
>
> class Animal(Thing):
>genus = models.CharField(...)
>
> class Toy(Thing):
>manufacturer = models.CharField(...)

In this case, they will simply be a list of fields with no
corresponding tables, managers, instances, data, .. etc. So they aren't
really models. Maybe we should consider them a different kind of
classes. Call them something like schema classes, or model templates.

This means that it will not be sufficient for their derivatives to
subclass them to become models, so they will be forced to use multiple
inheritance. Like this:

 class Thing(models.Schema):
name = models.CharField(...)

 class Animal(models.Model, Thing):
genus = models.CharField(...)

 class Toy(models.Model, Thing):
manufacturer = models.CharField(...)

This alternative solution is clearer and better because:
1. It makes it clearer the fact that you cannot use Thing directly as a
model (because it is never thought of as a model anyway).

2. It makes the syntax for subclassing the abstract way and subclassing
the Pythonic way different in the definition of the derivative classes.

Two possible drawbacks:
1. It won't work if we need to inherit anything other than a commonly
used set of fields, but that should probably be the job of the Pythonic
inheritance.

2. I'm not sure weather multiple inheritance will be a feasible
solution in Python (because the code that is going to introspect the
Thing super class and add its fields to our class is model.Model, which
is one of the suer classes).

But I don't see this as a problem either, because we can always find an
alternative method of adding those fields to the model. We don't have
to use inheritance, because there is really no inheritance involved
here. We can simply declare the fact that we want to add a pre-defined
set of fields in the META section of the derivative class.

This would be the most extreme form of my reasoning:

 fields_common_to_things = {name = models.CharField(...)}

 class Animal(models.Model, Thing):
genus = models.CharField(...)
class META:
   merge_fields = [fields_common_to_things]

 class Toy(models.Model, Thing):
manufacturer = models.CharField(...)
class META:
   merge_fields = [fields_common_to_things]


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Model inheritance API

[Ahmad Alhashemi]

A few corrections...

> 2. I'm not sure weather multiple inheritance will be a feasible
> solution in Python (because the code that is going to introspect the
> Thing super class and add its fields to our class is model.Model, which
> is one of the suer classes).

It is actually feasible, I just checked.


>  fields_common_to_things = {name = models.CharField(...)}

Small typo here. This should have been:

  fields_common_to_things = {'name': models.CharField(...)}


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

A proposal for URL generation

[Ahmad Alhashemi]

This is a well know problem. You can read about it in the background
section below. The ticket for this problem have been sitting unresolved
for a long time now. I would really like to get some feedback from the
developers. If you like this, I will submit a patch with the
implemenation.

My solution
---

My solution is based heavily on the URLConf framework and goes parallel
to it. I think that code for both URL parsing (urlpatterns) and URL
generation (urlgenerators) should be placed together. This will make it
easier to maintain URL's.

The idea is to create a variable called urlgenerators that is similar
to the urlpatterns variable. This is what it looks like:

def get_poll_url(poll):
  return '/poll/%s/' % poll.id

urlgenerators = ('mysite.polls.models',
  ('Poll', get_poll_url),
)

The lookup for the correct URL generation function will be by the fully
qualified name of the Model on which the object is based. For example,
the Poll model in the example above will resolve to the function
get_poll_url, which is defined earlier in the file. The object itself
will be passed to the function that is called.

It will also provide a method of including URL generator functionality
from external files, like this for example:

urlgenerators = ('',
  ('mysite.polls.models', include('/polls',
'mysite.polls.urls')),
)

The example above tells Django that any model found in the
'mysite.polls.models' should be handled by the urlgenerators variable
in the 'mysite.polls.urls' module. It also tells it to prepend the
string '/polls' to any value returned for the URL by the included
module.

This framework will give us all the benifits of the 'get_absolute_url'
method, but with more decoupling of the models from the views. And more
decoupling of applications from projects. And with more sophistication
and robustness.

We can also have a template filter that will take a model object and
returns its absolute URL. So that code like this:

{{ object.get_absolute_url() }}

Would become like this:

{{ object|get_absolute_url }}


Some Background
---

The problem is that the URLConf system is very sophisticated that there
is no way to dynamically reverse engineer it to produce the URL's back
from our model objects. There is simply no safe way of converting a URL
back from a regular expression. Even if that was possible, URL's aren't
directly mapped to model objects in the first place.

To make matters even more complicated, the URLConf has this modularity
system which is intended to seperate the different application's URL
configurations. This modularity system have the same two qualities as
in the application level URLConf. It is based on regular expressions,
so there is no safe way of reversing the pattern. And it does not
neccessarily point to a certain application.

If we want to keep the same level of sophistication in the URLConf
system, then any kind of automatic determination of the URL's is out of
the question. We need to provide a system or URL generation that is
parallel to the URLConf system of URL parsing.

The current solution is to have model objects define a function called
get_absolute_url that returns the absolute URL of the object. The
absolute URL is, of course, dependent on the project, which makes it
impossible to make applications independent of the projects they live
in. There is consensus that current solution is sub-optimal, but a
satisfactory solution haven't been reached yet. This problem have been
discussed before in [ticket
#672][http://code.djangoproject.com/ticket/672].

Thank you for reading to the end!


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Reversed urlresolvers and included urlconfs

[Ahmad Alhashemi]

This is a know issue waiting for a solution that will satisfy the
developers. I've just posted a proposed solution here in the developers
list. You can also check the ticket which was opened nine months ago
and is still unresolved:
http://code.djangoproject.com/ticket/672


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: A proposal for URL generation

[Ahmad Alhashemi]

Great to hear that Adrian. Nevermind my post then :)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Default escaping -- again!

[Ahmad Alhashemi]

Default escaping couples the Django templates with HTML. I don't think
that this is a good idea, even if HTML is, incidentally, the most
commonly used language in templates, for the time being.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Default escaping -- again!

[Ahmad Alhashemi]

Simon Willison wrote:
> Here's an idea I don't think anyone has brought up yet: what if
> escaping was on by default for templates ending in .html and off by
> default for templates ending in .txt?

This does seem like a practical solution. But I think that it gives
more meaning to template file names than they should have. It will make
excerpts of Django templates impossible to interpret without knowing
the name of the file. I can see the topic of the IRC channel becoming:
"please specify the filename of any template code you paste here".

Besides, it will force people to change template filenames if they
don't want auto-escaping. This can cause trouble, especially if you are
referring to your template names in other places (extends, includes and
views).


Jeremy Dunck wrote:
> Make a setting to turn define the default, and if the setting's not
> there, auto-escape.
> Anyone that doesn't want it can just turn it off by defining the setting.
>
> AUTO_ESCAPE_TEXT = _True_|False

This will couple templates to the project. This is the #1 reason why
PHP suck.


Todd O'Bryan wrote:
> {! !} seems perfect for raw, because the exclamation points emphasize
> that something bad could happen.
>
> {$ $} could be used for escaping, with the $'s designed to remind
> people of environment variables. This would be tag people are
> encouraged to use unless they need raw HTML text.

This again is putting too much emphasis on HTML as the language used in
templates. It reminds me with the special treatment Perl gives to
regular expressions.


Bill de hÓra wrote:
> Scope it per template:
>
> {% extends "base_generic.html" %}
> {% escape %}
>
> This lets people who want auto-escaping, have it, without typing in
> "|escape" everywhere or screwing things up site wide with globals.

This is nearly perfect for my taste. The only thing is to make it just
a bit more generic like this:

{% autofilter escape %}

This will specify that the escape filter will be applied automatically
to all variables. It is just as easy to use, it is not specific to HTML
and it can be used in other useful contexts, like for escaping in a
JavaScript template. It doesn't break backward's compatibility. It
doesn't force you to do anything you don't want to.

We can even provide the {! !} tags to mean "do not apply auto filter".
Then I can immagine some files starting with:

{% autofilter javascript_escape %}

Then escaping and the {! !} will work perfecly well in a JavaScript
template.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Where escaping belongs

[Ahmad Alhashemi]

I think that this is prone to error. At least for me, when I see a
piece of code like this one, I will definitly think that it needs to be
escaped:

{{ content }}

But if I'm passing something in the view code without escaping, I will
have to check the template to make sure it is being handled properly.

So I cannot do a security audit of my code just by scanning my lines of
code.

It will also make it difficult to debug errors when the tempaltes are
viewed.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Where escaping belongs

[Ahmad Alhashemi]

> Regarding doing a "security audit", assuming you had some method of
> defining the default escaping (if any) it would seem easier and safer
> to audit if you were looking for cases where you didn't need to escape
> (the more rare case). But this is getting back to the main auto-escape
> discussion.

It is definitly a good idea to have an application that is secure by
default. But when a template author comes and puts a variable
replacement code in the middle of his HTML code, it is assumed that he
knows exactly what he is doing. This is not insecure by default, it is
insecure because the template author made it insecure.

It don't think that template authors should come and put variable
replacements all over the place then security auditing will come after
them and add all the escapes. When security auditing comes, tempalte
authors should have already put escape filters all over the template
and a variable replacement without an escape is what should stand out.


> So if DRY *is* a major priority then say I am writing an project that I
> know will be outputting to HTML 99% of the time. Having to turn on
> escaping on every template (or worse, every tag!) seems quite a
> "repetitious" task.
> I guess then it becomes an argument between DRY vs Explicitness. So is
> explicit > DRY?

This might well be subject to personal taste. In general, Python is all
for explicitness, and so is Django.

Also note that DRY does tell you that it is wrong to repeat the same
code ten times in your application and that you should wrap it all up
in a common function. But it doesn't tell you that it is wrong to
*call* that function ten times. This is not un-DRY.

But then again, having to remember to escape each and every variable
does seem like a problem that is can be solved with DRY, so... I don't
know.


> [...] I would be happy if you could just specify your {% escape
> html %} block (in whatever format it ends up in) in your base template
> as opposed to doing it in every single template.

The problem here is that the base and extending templates are not
always managed by the same person.

Consider the case of the admin templates for example. Sometimes you
just want to create your own base template to change the general theme,
but you want to leave the remaining admin templates unchanged. Now if
you apply autoescaping to your base template, all the extending admin
templates will become broken and need to be changed to work properly.

This also applies to larger scopes, like when you download several
applications from the Internet, each with their own default set of
templates, you put them in a single project and you make them all
extend a common template that provides the basic functionality for your
site. Now if some of them are designed to work with autoescaping "on"
and others are designed for autoescaping turned "off", there won't be a
correct elegant solution to the problem.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: the template system's whitespace handling

[Ahmad Alhashemi]

In Rails, template tags can have an extra hyphen at the end to denote
the fact that they should consume the newline right after the tag. So:

{% some_tag %}

Would look like this:

{% some_tag -%}

Isn't it possible to just add this functionality by making the newline
that comes right after the tag part of the regex of the tag?

Something like this:


# template syntax constants
[...]
BLOCK_TAG_END_NO_NEWLINE = '-%}\n'
[...]
tag_re = re.compile('(%s.*?(%s|%s)|%s.*?%s)' % \

(re.escape(BLOCK_TAG_START),
  re.escape(BLOCK_TAG_END),

re.escape(BLOCK_TAG_END_NO_NEWLINE),

re.escape(VARIABLE_TAG_START),

re.escape(VARIABLE_TAG_END)))


Just one more small change to Lexer.create_token and we are all set up.
This way the newline will be matched with the tag and consumed, and
therefore it will just disappear. No big performance hit sustained.

(Note that I did not test any of this)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: modularity of apps

[Ahmad Alhashemi]

Malcolm Tredinnick wrote:
> I'm not a fan of infinite flexibility as solutions for undefined future
> problems, so it's good that you've put in some specific cases you've
> encountered. Food for thought here.

+1 on that.

All these suggestions are going to make Django much fatter. It will
make the learning curve steeper too.

The good thing is that it is really easy to implement such features for
our own use without the need to touch a single line of Django's core.
For example, if you want to implement this idea of a context_processors
function in every application, you can easily do this as a "meta"
context_processor that you will add to your settings file as a context
processor.

Then when your "meta" context processor is called, you can have it go
through INSTALLED_APPS, call whatever function you want and collect the
responses whatever format you want, then return the whole thing from
your "meta" context processor, and everything will be available in the
templates automatically.

The same thing for middleware. You can just create some kind of a
"meta" middleware that will use a systematic way of calling other
predefined middleware functions in your INSTALLED_APPS.

I really like these features, they can suddenly make applications much
more powerful. But I'm always afraid that they might make applications
a bit too powerful. I think of them as explosive ideas. I'm working on
a currently experimental extension to Django that adds all sorts of
things like this. I call it Dynamite. If it goes well, I will release
the code for it.

In the end, if a certain feature proves itself popular and useful over
time, we can easily add it to Django's core.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: translation of content

[Ahmad Alhashemi]

Kenneth Gonsalves wrote:
> hi,
> just a few random thoughts on translation of content. At first i was
> leaning towards developing a dependant model for each model which
> would hold translations. One thing i have realised is that of all the
> field types, only three - CharField, TextField and numeric fields
> would need to be translated. So was thinking, why not have a model like:
>
> EnglishString:
> fieldtype - this is text/char/number
> englishstring - the english string
>
> Translation:
> englishstring - foreignkey to EnglishString
> language - foreignkey to Languages
> translation - actualtranslation
>
> and something to prompt a lookup to see if there is a translated
> string available. But this is going to be slow. An alternative would
> be to eliminate the 'EnglishString' model and have only one model
> like so:
>
> Translation:
> origmodel - foreignkey to a the modelname+model_id
> +fieldnameof_stringtobetranslated
> language - foreignkey to Languages
> translation - actualtranslation
>
> a mechanism should be there to serve these strings to a tranlator for
> translation and saving into the database. translation of numeric data
> could be automated.

This is very similar to the way gettext works. English is considered
the default and translations follow. I would use this method if I were
only translating the interface of a web application, but then again,
gettext is already a very good solution to this problem.

For content however, there are a couple of issues with this method:
1. There is a performance hit for non-English pages.
2. The content in the actual models is duplicated in the EnglishString
table.
3. The EnglishString table is not very rectangular (having a one fits
all field), the same thing goes for the translation table.

Another problem here is that you cannot add non-English content without
corresponding English content, which might not always be the case.

What I would do is to simply use the sites framework to create
per-language sites. This way, content of the different sites is
essentially independent. Then, on top of that, you can have a system
linking several objects togther as translations of the same thing. For
example, you can have a weblog entry in the English site linked to one
in the French site and one in the German site.

Then, in templates of a certain language site, you would look for
objects that are related to the current object in the translation
tables and link to them through their get_absolute_url preceded by
their site's address.

Of course, as I said, it all depends on what you are trying to achieve.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: XSS comments from PHP Creator

[Ahmad Alhashemi]

This reminds me of the autoescaping arguments.

Note that you can do this outside of Django. I think that there is
something like this for apache called mod_security. It works
regardless of the scripting language/framework you are using.

--Ahmad

On 8/20/06, Paul Sargent <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I know the topic of auto-escaping user data comes up on here from time
> to time. I just wondered if others had heard this.
>
> http://www.twit.tv/floss12   PHP Creator - Rasmus Lerdorf
>
> Say what you want about PHP (I'll happily join in ;-) ), but I found it
> interesting to listen to the guy.  I would have thought he's learnt a
> few lessons in all the time PHP has been on the front line.
>
> At about the 40 minute mark (it might start a little earlier) Rasmus
> talk about his ideas on how to deal with XSS style holes in PHP Code.
> My take was this was a method he was already using at Yahoo.
>
> Basically (for those who are too lazy / buzy to listen) he talks about
> having a 'firewall' that incoming data passes through and is sanitized
> by. Then all data is deemed safe for output. 'Holes can be poked in the
> firewall' if you need to be able to enter HTML (for example). It struck
> me that we could do something similar in the manipulators. They already
> validate. Why not sanitize?
>
> Key point is not to let the attack in the system, rather than to avoid
> executing it.
>
> Paul
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: XSS comments from PHP Creator

[Ahmad Alhashemi]

On 8/22/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> On 21/08/2006, at 9:24 PM, [EMAIL PROTECTED] wrote:
> > @ Ahmad - mod_security (modsecurity.org) is fantastic, and I highly
> > recommend installing it on all apaches, but filtering content at the
> > webserver level is a sledgehammer approach and should only be done for
> > *really* bad content (e.g. known exploits, spam bots etc)
> >
> you should be doing filtering exactly the opposite way than this.
>
> You deny everything by default, and have holes added when you need them.
> and when you poke a hole you have a reference to why it is required
> (ie what module needs a particular variable unfiltered)
>
> Things which you don't know will hurt you unfortunately.  and by
> using deny by default with a big sledgehammer will
> stop a lot of these things before they even touch your code.
>
> doing it the other way requires a conscious effort to maintain the
> firewall, and you won't know when you are failing.

Obviously, mod_security is not the only solution, it will just provide
some extra security. I don't think that it is a flawed method of
security by itself, this is the same model used in anti-virus,
anti-spyware and spam protection. You maintain a long list of known
threats that you test against.

I can argue that the kind of passive security you are talking about,
as in everything is denied by default, is already present in Django.
It is not like variables are passivly going all the way to your
templates and being randomly embedded in there. You are actively
passing a variable to the template through context and embedding it at
certain places. You are just poking a hole in this firewall.

But if you keep poking holes in all the wrong places, then it is not
the frameworks fault.

Autoescaping might be a nice DRY feature, but I don't think it has
anything to do with being secure by default.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: slow response when using manage runserver without Internet connection

[Ahmad Alhashemi]

Hi,

I'm not sure I have a solution, but are you sure it is the built in
server that is slow? Maybe you have some kind of a browser extension
trying to access the Internet. Maybe you should try it using a
different browser and see if there is any difference.

Also, what address are you using to access the site? Mine, for
example, is usually http://127.0.0.1:8001/

P.S: this questions might be more appropriate in the django-users group.

--Ahmad

On 8/22/06, DD <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am using the Django built-in web server. The server's reponse time is
> nomal when connecting to Internet, once it's offline, the speed is
> extremely slow. Does anyone have experience how to fix it?
>
> Thanks,
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Django.contrib applications modifying Django to work properly?

[Ahmad Alhashemi]

On 8/22/06, Mart <[EMAIL PROTECTED]> wrote:
>
> Hi Chris,
>
> I was just wondering why wasn't there any helper methods to achieve
> exactly the same result as you can by editing the Django source (in
> your case the django.db), but without editing anything out of your
> application's directory.
> That way even the code repository wouldn't have invent some way to
> install the application/add-on, just download the application
> directory, add it to the project and setup some settings, no mangling
> with Django's source.
>
> (The previous might be exactly what you said in your message's last
> paragraph.)
>
> Mart

Do you mean by your question why is this row level permissions feature
not available in the main Django distribution?

If I understand you correctly, and that was your question, then the
answer is that it is very experimental and under heavy development. So
it is being isolated for the time being. Once it is a bit more mature,
it will be merged with the main Django distribution, and you will not
have to download it seperatly.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Validation Aware Models and django.forms on steroids

[Ahmad Alhashemi]

On Aug 24, 2006, at 2:21 PM, Brantley Harris wrote:
> > The whole raising a Form thing is just a shocking idea.

+1

At first, I really digged this raising a Form, but then I realized
that it is just returning a value, but too cleverly...
1. It feels like a goto is happening (execution jumping in an unusal path)
2. It abuses raise as a replacement for a return and a try...except as
a replacement for an if-statement
3. It makes the return value strongly typed (you have to raise a Form object)
4. Form becomes a sub-class of Exception (yuch)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Extend URL resolver support for HTTP Methods / REST support

[Ahmad Alhashemi]

+1 on the idea.

It is starting to make less and less sense to treat a GET and a POST
the same way just because they use the same URL.

I don't think the implementation is ugly, either. I can't see how it
can be made cleaner, except for using constants instead of strings for
GET, POST, ..etc. But then again, we are probably getting those as
strings from the backends.


--Ahmad

On 9/22/06, Simon de Haan <[EMAIL PROTECTED]> wrote:
>
> Hello everyone,
>
> I've posted a patch in trac which will allow the urlresolver to
> select a view depending on the HTTP method (GET,POST,PUT,DELETE, etc..)
> Its posted at http://code.djangoproject.com/ticket/2784
>
> My implementation has been hacked together in a few minutes and isn't
> pretty by any standards but Malcom suggested I pitch it here to start
> a bit of a discussion.
>
> The urlpatters could then look like this:
>
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('',
> # Example:
> (r'^django_rest_urls/get/(?P\d+)',
> 'django_rest_urls.restful.views.get'),
> (r'^django_rest_urls/(?P\d+)', {
>   
>  'GET':  'django_rest_urls.restful.views.get',
>   
>  'POST': 'django_rest_urls.restful.views.post',
>   
>  'PUT':  'django_rest_urls.restful.views.put',
>   
>  'DELETE':   'django_rest_urls.restful.views.delete',
>   
>  }),
>
> # Uncomment this for admin:
> # (r'^admin/', include('django.contrib.admin.urls')),
> )
>
> I like the idea of allowing the methods specify the view, in certain
> situations it can be cleaner than using "if request.POST" type of
> stuff in the view and will make RESTful type of applications easier
> to build using Django. I guess it could be beneficial for AJAX type
> of backends too.
>
> I'd be interested in your ideas.
>
>
> Kind regards,
>
> Simon de Haan
>
> Eight Media
> [EMAIL PROTECTED]
> +31 (0)26 38 42 440
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Contrib context processor?

[Ahmad Alhashemi]

Also, this is the most recent thread about this:

http://groups.google.com/group/django-developers/browse_thread/thread/11b9a6f2b18f7daf/02cb8b3974f0a329?lnk=st&q=context+processor+settings&rnum=1#02cb8b3974f0a329

You can probably find much more threads regarding this.

--Ahmad

On 10/13/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 10/13/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > I'm adding it locally, but was wondering if you'd like a patch for one
> > either to core or contrib?
>
> It came up in ticket 2532, and Adrian vetoed it on the grounds that
> adding context processors for some settings could be a slippery slope
> toward having a context processor for every setting.
>
>
>
> --
> "May the forces of evil become confused on the way to your house."
>   -- George Carlin
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

dating website

[tauqir ahmad]

Send free email to dating members
http://www.datingseasons.com

Find your dream partner online free
http://www.datingseasons.com

Search and make your online partners
http://www.datingseasons.com

Find more details about your dream partner
http://www.datingseasons.com

Search your soulmate
http://www.datingseasons.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Reopen ticket #32088, django.contrib.sessions, get_expiry_date() func problem

[ahmad khalili]

* Confusing return value in 
SessionStore('some_session') .get_expiry_date(),  example:*

   from datetime import datetime
from django.contrib.sessions.backends.db import SessionStore
my_session = SessionStore()
my_session.get_expiry_date()
# this return new created sessions expiration time(14 days after 
datetime.now()) this is expected and logical but:
  my_session = SessionStore( 'some_session' )
my_session.get_expiry_date()
# this return new created sessions expiration time too, unexpected, this 
should return my_session expiration time

Here in this example django force us using 
*my_session._get_session_from_db().expire_date* instead 
*my_session.get_expiry_date()*, but one simple question: why we should do 
additional work when we saied to django 'we have specific db session?

In last reply in ticket #32088 i described a bit more.






-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c2d4a4de-b133-44cb-acb1-768e3b6265bbn%40googlegroups.com.

Form required field

[Ahmad Sharif]

Hi,
We can add a new field to formbase class like 'fields' or 'exclude' called 
'required'.
Any field is in that list, must be completed for submitting and validating.
I think it's not so difficult.
How do I can do that with contributing in django?
It's so good if we can impliment that.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d015e145-0290-4f68-a515-f730bf19093e%40googlegroups.com.

Can we use a django application class?

[Ahmad Alhashemi]

Hello,

Right now, django applications are strange creatures. They are python
packages with some magic. They have to have a "models" module.
Everything else is free form. We have strong conventions like urls.py,
maybe admin.py, but they all have to be explicitly called and used in
the project.

How about creating an actual class for django applications. This way
django applications can be actual objects instead of just being
magical python packages. We can make it a convention to put the djagno
application object in the __init__.py module of the package. We can
then use this class to add various functions related to other parts of
djagno, like defining application specific url patterns and admin
objects.

Imagine something like this:
  from apps.weblog import weblog_app
  INSTALLED_APPS = (weblog_app, )

  from apps.weblog import weblog_app
  urlpatterns = patterns('',
   (r'^weblog/', weblog_app)
  )

This will also be the natural place to add any future functionality
and still be backwards compatible. In contrib.admin for example, we
can easily take a look into weblog_app and see if it defines an
"admin" property or not.

It makes the application less magical because we don't have to have a
"models" module any more, it makes applications more self contained,
it adds the ability to expand application features in the future.

The __init__.py file of the application will look something like:
  from . import models, admins, urls
  from django.somewhere import Application
  weblog_app = new Application()
  weblog_app.models = models
  weblog_app.admins = admins
  weblog_app.urls = urls


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Can we use a django application class?

[Ahmad Alhashemi]

On May 29, 2:55 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Could you elaborate on what's "magical" about an application? It's
> just a Python module, with one convention imposed on where you put
> model classes so that Django can auto-discover them; adding a whole
> new level of infrastructure on top of that would be a serious
> undertaking, and I can't honestly see what it is that's so confusing
> or difficult about that one convention that would justify it. What
> real-world obstacles are being created by the requirement that models
> live inside the application in a module named "models"?
>
> Am I missing something here?

I'm definitely not suggesting a major infrastructure change. I'm just
suggesting something similar to the passing views as callable objects
instead of passing them as strings containing the names of those
objects. It is just more pythonic.

Why are we reinventing import everywhere in django? Is this really
common in python, passing strings containing package names around
instead of simply passing objects? I don't see this anywhere in the
library.

The real world problems it would solve are the problems similar to
what we had to deal with when breaking Admin out of models. How do we
retain auto discovery? Remember that admin is a django application,
not a core feature. Other people are likely to create similar
applications and will face the same problem. I had the same problems
when I wanted to add auto discovery to some other feature I wanted to
build on top of Django.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Can we use a django application class?

[Ahmad Alhashemi]

On May 29, 3:36 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On the topic of "magic", that's a very polarizing phrase. There's no
> one definition of magic in the Python sense, so each person is free to
> define it differently. For instance, your proposal seems (in a way)
> more magical to me, from the perspective of average developers.
> Instead of supplying specific import paths to various features, you're
> proposing that a single import path be used for pretty much
> everything. You pass the same module object to urlpatterns that you
> pass to INSTALLED_APPS (and presumably to AdminSite in newforms-admin
> as well). It's not clear from a developer's perspective that each of
> these subframeworks is looking for something different; it seems like
> Django is "magically" using one object for everything.
>

It is not going to be magical any more because you "know" you are
passing this certain object that represents a Django application. When
you look at the code, you will instantly know that there is this
object being imported for this package and used in such and such
places.

But in the current situation, all you see is a couple of strings in a
list called INSTALLED_APPS, but there is a lot happening behind the
scene, where these strings get parsed, pieces of information being
extracted from them, then they are used as python package names that
must be in the python path and must contain a module called "models".

> Also, what about applications that may have different URL schemes for
> different purposes? Your proposal limits applications to just one URL
> scheme, since Django would only get one application object and would
> have to get urlpatterns from that. If (for instance)
> django-registration gets integrated into django.contrib.auth, there
> would possibly be two separate URL structures, one for logging in/out,
> and one for registration. With the current system, that's easy to
> handle, but how would your proposal deal with that?

You will still be able to use urlpatterns the same way you do now. The
extra advantage is that you will not have to specify the full path to
the application specific urls.py file if you don't want to. This makes
applications more self contained and will allow application developers
to move stuff around in the application without breaking all the
projects using them.

Besides that, even if you use the application object, you are not
limit it to one URL schema. If anything, it gives the application
developers infinite flexibility without compromising current settings
files. In your settings file, right after you import the Django
application object you want, you can call a function on that
application object and tell it what kind of URL scheme you want from
it.

from apps.weblog import weblog_app
weblog_app.allow_registration = True # or whatever


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Can we use a django application class?

[Ahmad Alhashemi]

On May 29, 7:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
>
> > Why are we reinventing import everywhere in django? Is this really
> > common in python, passing strings containing package names around
> > instead of simply passing objects? I don't see this anywhere in the
> > library.
>
> I don't see this anywhere in Django, either, which makes me wonder
> what relevance it has ;)

The settings.py file is full of strings defining things that will
eventually be imported using __module__ instead of a simple, well
known and obvious import.


> Seriously, it's just Python, and I don't see where we've "reinvented
> importing everywhere"; Django uses normal Python imports, even in the
> "magical" discovery of models.

I know that it uses python imports. It is always python. Even before
magic-removal, it was all python, right?

And I'm not suggesting to drop everything we have now. I'm suggesting
that it would be more transparent and obvious if the user can look and
see that the weblog_app he imported with an explicit import is put in
INSTALLED_APPS. It is similarly more obvious in urls.py for a user to
see that the weblog_app which he imported with an explicit import is
going to handle all urls that start with 'weblog'.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Can we use a django application class?

[Ahmad Alhashemi]

On May 29, 7:16 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
>
> > I'm definitely not suggesting a major infrastructure change. I'm just
> > suggesting something similar to the passing views as callable objects
> > instead of passing them as strings containing the names of those
> > objects. It is just more pythonic.
>
> With all due respect, that's not what your proposal recommended. To
> just do what you're explaining now, the "proper" technique would be to
> supply INSTALLED_APPS with the models module of the application, since
> that's what's already used internally (in some places anyway) to refer
> to an application. Then, for urlpatterns, you'd pass in the urls
> module (the module itself, not just the import path), and other
> subframeworks would use their own locations.

Well, it is called INSTALLED_APPS, not MODELS_OF_INSTALLED_APPS,
right? :)

The only reason that the "models module of the application is what's
already used internally (in some places anyway) to refer to an
application" is because we don't have an application object. And
that's exactly what I'm proposing.

In the URL's, it'll be like saying: delegate weblog/* to the weblog
app. It is not a replacement for what is already in here. It just
makes project files a bit simpler easier and shift things into
applications.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Can we use a django application class?

[Ahmad Alhashemi]

On May 29, 7:24 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hey Ahmed --
>
> Let's back up a step here: what's the problem you're having with the
> way Django currently does INSTALLED_APPS? What can't you do that you'd
> like to do?
>
> Jacob

I can't change my application structure without changing setting files
of projects.

I can't extend Django applications with extra features that require
auto-discovery. I'm working on a CMS using Python, and I want to know
which applications support special features that my CMS can build upon
(something similar to admin).

I can't install two applications with the same name.

I can't translate my application names (thank you Brian).

The most important thing is that it makes things more pythonic. This
is important. This is why magic-removal was undertaken, isn't it?

To paraphrase what Brian said, it might not appear that ugly in the
common case, but I'm sure that you will find solutions to all the
problems I've mentioned above. But those solutions are going to look
really ugly and hackish in my opinion. For example, why do I have to
use project wide settings to tell two closely related applications how
to deal with each other?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Can we use a django application class?

[Ahmad Alhashemi]

On May 29, 7:53 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
>
> > Well, it is called INSTALLED_APPS, not MODELS_OF_INSTALLED_APPS,
> > right? :)
>
> > The only reason that the "models module of the application is what's
> > already used internally (in some places anyway) to refer to an
> > application" is because we don't have an application object. And
> > that's exactly what I'm proposing.
>
> Point of fact: Python already exposes a module for each application,
> so its supposed non-existance is hardly the "only reason" it's done
> the way it is. It uses the models module instead, because that's where
> the useful information is stored.

Models are completely irrelevant to any web application that do not
use databases.

These include online conversion tools, mashups that get all their
information from other services over the web, and a MySQL
administration tool like phpMyAdmin. All real projects and I
personally intend to implement in Django.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Can we use a django application class?

[Ahmad Alhashemi]

On May 29, 9:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
>
> > I can't extend Django applications with extra features that require
> > auto-discovery. I'm working on a CMS using Python, and I want to know
> > which applications support special features that my CMS can build upon
> > (something similar to admin).
>
> Sure you can. Again, look in django.db.models.loading, or just iterate
> on INSTALLED_APPS and import stuff yourself. It's not that hard.

Is this considered part of the stable API? Is it part of the backward
compatibility guarantee?

I can do it myself, and everyone do the same themselves, then the
internals change and all our code needs re-writing. Or we can do it
once with a nice API and everyone can grow safely inside the django
application object.

> > I can't install two applications with the same name.
>
> As far as I know, you can install two applications which live in
> folders which happen to have the same name though they're nested
> inside different parts of an overall directory structure (e.g., you
> can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting
> 'app_label' manually since Django infers that from the directory name.

The solution is ugly, as I've pointed out before. Vinay already
mentioned this.

> Two applications whose Python paths are identical, of course,
> represent an impossible situation, but this is impossible because of
> Python.

I never said anything about that!

> > I can't translate my application names (thank you Brian).
>
> If that's the only justification left, I'd say we should just find a
> good way to mark app names for translation, not overhaul the way
> applications are put together.

No sir, this is but one problem. The other problems still don't have
easy, API like, pythonic solutions. Not to mention that you've skipped
my first point:

I can't change my application structure without changing setting files
of projects.

> > The most important thing is that it makes things more pythonic. This
> > is important. This is why magic-removal was undertaken, isn't it?
>
> More Pythonic in what way? And to whom? To me, a Python module is
> about the most "Pythonic" way to wrap something up, and isn't
> "magical" at all -- subjectively, having a specialized class to
> represent something that can be represented by a Python module is the
> "un-Pythonic" approach.
>
> But there's the problem: we're down to an entirely subjective distinction.

I had very strong feeling regarding this, and I thought everyone would
share them, so I guess that's my mistake. Maybe we need an outside
opinion, like from one of Python's mailing lists. Show two approaches
and ask them which one looks more "pythonic" to them.

> > really ugly and hackish in my opinion. For example, why do I have to
> > use project wide settings to tell two closely related applications how
> > to deal with each other?
>
> Why do you have to do that? If they're that closely related, why can't
> they know about each other directly? Why can't one app export some
> constants for the other to refer to?

Because sometimes you want to use one of them alone.

> I think you're confusing "this is
> how some people do things in Django" with "this is how you must do
> things in Django"...

Sorry I didn't understand your last comment. Please bare with an
English as a second language speaker :)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: How to Start for GSOC 2020 in Django org.

[Ahmad A. Hussein]

Hi Priyanshu,

I'm a fellow GSoC aspirer. What helped me a lot is checking out the
contributing guide posted on the Django website.

Here is the link:
https://docs.djangoproject.com/en/dev/internals/contributing/

It'll make things a lot easier for you if you've never used Git before and
never tracked tickets in an open-source environment.

You should also try to start contributing as soon as possible to get a feel
for Django's internal codebase.

If you have any other questions, don't hesitate to ask on here. Everyone
here replies promptly.

In the future, try to search for your question before posting a new thread
because this question was asked in three different threads before I
believe.

On Mon, Jan 13, 2020 at 2:56 PM Priyanshu Panwar 
wrote:

> Hello Everyone.
> Please help me. How do I start for gsoc 2020, though I have a good
> background in Python and Django as a freelancer.
> Thank you.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3d87d5a8-ab76-45a7-ab28-b8a6501fce7d%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJNa-uPs-_eoH3e1r0hDuja7VFyG-j4%3DC4CtcEwDKQMd%3DYY5NQ%40mail.gmail.com.

Where to post to ask questions about solving a Django ticket

[Ahmad A. Hussein]

I'm currently stuck on solving a Django ticket I assigned to myself, and I 
don't know where to post to ask for help/feedback.
Should I post here or ask someone on the #django IRC channel or should I 
make a post on the django project forums?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9d3b5148-4303-4453-bbd0-eb574432968a%40googlegroups.com.

Re: [Feature Request] Having an middleware to be able to force authentication on views by default

[Ahmad A. Hussein]

I completely agree with what has already been said by everyone here; 
moreover, this is a battery missing from Django in my opinion. It would 
make Django more "batteries-included" if this was part of core rather than 
third party-libraries. If you need help with documentation, I can 
definitely throw a hand.


Regards,
Ahmad

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ef6ad79b-e37b-46b3-87c3-60d7c97e5395%40googlegroups.com.

GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Ahmad A. Hussein]

Django's parallel test runner works through forking processes, making it 
incompatible on Windows by default and incompatible in macOS due to a 
recent update. Windows and macOS both support spawn and have it enabled by 
default. Databases are cloned for each worker.

To switch from fork to spawn, state setup will be handled by spawned 
processes instead of through inheritance via fork. Worker’s connections to 
databases can still be done through get_test_db_clone_settings which 
changes the names of databases assigned to a specific worker_id; however, 
SQLite's cloning method is incompatible with spawn. 


SQLite’s cloning method relies on it both being in-memory and fork as when 
we fork the main process, we retain SQLite's in-memory database in the 
child process. The solution is to get a SQL dump of the database and throw 
it into the target cloned databases. This is also the established standard 
in handling MySQL’s cloning process. Both Postgresql's and MySQL's cloning 
methods are independent of fork or spawn and won't require any modification.


Oracle has not been implemented in the parallel test runner originally even 
on Linux and I propose to extend support to Oracle as well in my proposal. 
I want to confirm if there is significant support behind this as a feature 
or not before I commit to writing a specification, but as a summary it is 
definitely possible as the work collaborated on by Aymeric Augustin and 
Shai Berger show that cloning CAN be done through multiple ideas. The 
reason why it's a headache is that Oracle does not support separate 
databases under a single user- unlike our other supported databases, so we 
can't clone databases without introducing another user. Some methods may 
also need to be rewritten to accommodate for the Oracle backend, but that 
isn't an issue. I've glossed over writing out a schedule or a more detailed 
abstract as I I'm mainly posting here to see if there is indeed support for 
the Oracle proposal and to make sure I am not missing any details in 
regards to adapting the current parallel test runner to work through spawn. 
Let me know what you think.


Regards,

Ahmad

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/317f67c6-4b23-483f-ada5-9bdbb45d0997%40googlegroups.com.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Ahmad A. Hussein]

Apologies for the late response. I've had to attend to personal matters 
concerning the current crisis we're all facing. All is well though

I should have posted a more detailed post from the get-go. I apologize for 
the lack of clarity as well.

Last week, I initially did exactly what you suggested. I called 
django.setup() in each child process during worker initialization. This 
fixed app registry issues but like you said it isn't enough for testing. 
Test apps and test models were missing and caused tons of errors. Later, I 
read through runtests.py and saw the setup method there; it was exactly 
what I needed since it searched for setup the correct template backend, 
searched for test apps and added them to installed apps, and called 
django.setup(). I passed that method along with its initial arguments into 
the runner so I could call it during worker initialization. That fixed all 
errors related to state initialization. I do wonder though if any 
meaningful time could be saved if we use a cache for setup instead of 
having to call the setup for each process.

The last glaring hole was correct database connections. I had a naming 
mismatch with Postgres and I ended up fixing that through prepending 
"test_" in each cloned database's name during worker initialization. In 
case of the start method being fork, we can safely ignore that step and 
it'll work fine. 

Currently what I'm figuring out is getting a SQL dump to change SQLite's 
cloning method and implementing an Oracle cloning method. I'm searching 
through Django's documentation and internal code to see if there is a 
ready-made SQL dump method for SQLite and if not I'll search for it in a 
third-party library, and if I still don't find it, I'll start thinking 
about a ground-up implementation using the ORM. 

As for progress on the Oracle cloning method, I'm consulting Oracle 
documentation right now to see if anything has changed in the last 5 years. 
If I don't find anything interesting, I'll start toying around with Shai 
Berger's ideas to see what works and what's performance-costly.

Lastly, testing does seem to be an enigma to think about right now. I've 
thought about tests for both SQLite's and Oracle's cloning method, but I 
can't imagine anything else.

If you have any pointers, suggestions or feedback, I'd love to hear it! And 
thank you for your help so far.


Regards,
Ahmad


On Thursday, March 26, 2020 at 10:39:28 AM UTC+2, Aymeric Augustin wrote:
>
> Hello Ahmad,
>
> I believe there's interest for supporting parallel test runs on Oracle, if 
> only to make Django's own test suite faster.
>
> I'm not very familiar with spawn vs. fork. As far as I understand, spawn 
> starts a new process, so you'll have to redo some initialization in the 
> child processes. In a regular application, this would mean calling 
> `django.setup()`. In Django's own test suite, it might be different; I 
> don't know. Try it and see what breaks, maybe?
>
> Hope this helps :-)
>
> -- 
> Aymeric.
>
>
>
> On 23 Mar 2020, at 20:22, Ahmad A. Hussein  > wrote:
>
> Django's parallel test runner works through forking processes, making it 
> incompatible on Windows by default and incompatible in macOS due to a 
> recent update. Windows and macOS both support spawn and have it enabled by 
> default. Databases are cloned for each worker.
>
> To switch from fork to spawn, state setup will be handled by spawned 
> processes instead of through inheritance via fork. Worker’s connections to 
> databases can still be done through get_test_db_clone_settings which 
> changes the names of databases assigned to a specific worker_id; however, 
> SQLite's cloning method is incompatible with spawn. 
>
>
> SQLite’s cloning method relies on it both being in-memory and fork as when 
> we fork the main process, we retain SQLite's in-memory database in the 
> child process. The solution is to get a SQL dump of the database and throw 
> it into the target cloned databases. This is also the established standard 
> in handling MySQL’s cloning process. Both Postgresql's and MySQL's cloning 
> methods are independent of fork or spawn and won't require any modification.
>
> Oracle has not been implemented in the parallel test runner originally 
> even on Linux and I propose to extend support to Oracle as well in my 
> proposal. I want to confirm if there is significant support behind this as 
> a feature or not before I commit to writing a specification, but as a 
> summary it is definitely possible as the work collaborated on by Aymeric 
> Augustin and Shai Berger show that cloning CAN be done through multiple 
> ideas. The reason why it's a headache is that Or

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Ahmad A. Hussein]

Thank you Adam for the amazing pointer. That's exactly the solution I was
looking for.

I didn't even know VACUUM INTO was a thing in SQLite3 (quite nifty). Both
sources you listed can definitely copy memory-to-memory efficiently. I had
also found two useful APIs in the standard library's documentation:
iterdump() and backup(). The latter is an attempt at recreating the online
backup API you linked.

I did face an issue in my implementation though. Memory-to-memory copying
is impossible under the current conditions.

We can't copy memory-to-memory and retain the resultant databases into our
spawned workers since spawned child processes don't share an environment
with parent processes.

There are two possible workarounds:
 1. To copy our in-memory database into
an on disk database using VACUUM INTO and subsequently restore it into
in-memory during worker initialization
 2. Pass a string query resulting from
calling Connection.iterdump() into worker initialization and call that to
restore copies of the database into in-memory for every child process.

I'm testing out both now to see if there are any major differences. There
might be a performance difference between them. I'm also checking if there
are any unexpected errors that might arise.

Regards,
Ahmad

On Sun, Mar 29, 2020 at 5:56 PM Adam Johnson  wrote:

> Currently what I'm figuring out is getting a SQL dump to change SQLite's
>> cloning method and implementing an Oracle cloning method. I'm searching
>> through Django's documentation and internal code to see if there is a
>> ready-made SQL dump method for SQLite and if not I'll search for it in a
>> third-party library, and if I still don't find it, I'll start thinking
>> about a ground-up implementation using the ORM.
>>
>
> SQLite has an online backup API and the "VACUUM INTO" command both of
> which can efficiently clone databases: https://sqlite.org/backup.html . I
> think they can even copy memory-to-memory with the right arguments.
>
> On Sat, 28 Mar 2020 at 06:59, Ahmad A. Hussein 
> wrote:
>
>> Apologies for the late response. I've had to attend to personal matters
>> concerning the current crisis we're all facing. All is well though
>>
>> I should have posted a more detailed post from the get-go. I apologize
>> for the lack of clarity as well.
>>
>> Last week, I initially did exactly what you suggested. I called
>> django.setup() in each child process during worker initialization. This
>> fixed app registry issues but like you said it isn't enough for testing.
>> Test apps and test models were missing and caused tons of errors. Later, I
>> read through runtests.py and saw the setup method there; it was exactly
>> what I needed since it searched for setup the correct template backend,
>> searched for test apps and added them to installed apps, and called
>> django.setup(). I passed that method along with its initial arguments into
>> the runner so I could call it during worker initialization. That fixed all
>> errors related to state initialization. I do wonder though if any
>> meaningful time could be saved if we use a cache for setup instead of
>> having to call the setup for each process.
>>
>> The last glaring hole was correct database connections. I had a naming
>> mismatch with Postgres and I ended up fixing that through prepending
>> "test_" in each cloned database's name during worker initialization. In
>> case of the start method being fork, we can safely ignore that step and
>> it'll work fine.
>>
>> Currently what I'm figuring out is getting a SQL dump to change SQLite's
>> cloning method and implementing an Oracle cloning method. I'm searching
>> through Django's documentation and internal code to see if there is a
>> ready-made SQL dump method for SQLite and if not I'll search for it in a
>> third-party library, and if I still don't find it, I'll start thinking
>> about a ground-up implementation using the ORM.
>>
>> As for progress on the Oracle cloning method, I'm consulting Oracle
>> documentation right now to see if anything has changed in the last 5 years.
>> If I don't find anything interesting, I'll start toying around with Shai
>> Berger's ideas to see what works and what's performance-costly.
>>
>> Lastly, testing does seem to be an enigma to think about right now. I've
>> thought about tests for both SQLite's and Oracle's cloning method, but I
>> can't imagine anything else.
>>
>> If you have any 

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Ahmad A. Hussein]

 I did stumble upon shared memory when I originally wanted to pass the
database connection itself into shared memory. Your idea of passing the
query string is MUCH more reasonable, can be done using shared memory, and
will ultimately be much more cleanly written.

i'll definitely test out if it has significant performance boost and see
how it compares to other methods.

I did consider copying the SQLite database file itself. That's essentially
what's happening with VACUUM INTO. It's a SQLite command that lets you
clone a source database whether in-memory or on disk into a database file.
I got the parallel test runner to work with these database files, creating
a database file for each worker. I think there's a performance boost to
have if we make the databases for workers in-memory, especially if the test
suite and tables grow in number; however, we also need to consider the time
it takes to make the databases in-memory.

Re-running migrations and recreating the SQLite database from scratch for
every worker might be a time-sink, but it could actually prove quicker than
other methods. I'll try it out as well and see.

Thank you for your suggestions

Regards,
Ahmad

On Mon, Mar 30, 2020 at 9:39 AM Tom Forbes  wrote:

> There is an interesting addition to the standard library in Python 3.8:
> multiprocessing.shared_memory (
> https://docs.python.org/3/library/multiprocessing.shared_memory.html).
> It’s only on 3.8 but it might be worth seeing if that has a performance
> improvement over passing a large string into the workers init process.
>
> Have you also considered simply re-running the migrations and creating the
> SQLite database from scratch in each worker, or simply copying the SQLite
> database file itself?
>
> On 30 Mar 2020, at 08:13, Ahmad A. Hussein 
> wrote:
>
> 
> Thank you Adam for the amazing pointer. That's exactly the solution I was
> looking for.
>
> I didn't even know VACUUM INTO was a thing in SQLite3 (quite nifty). Both
> sources you listed can definitely copy memory-to-memory efficiently. I had
> also found two useful APIs in the standard library's documentation:
> iterdump() and backup(). The latter is an attempt at recreating the online
> backup API you linked.
>
> I did face an issue in my implementation though. Memory-to-memory copying
> is impossible under the current conditions.
>
> We can't copy memory-to-memory and retain the resultant databases into our
> spawned workers since spawned child processes don't share an environment
> with parent processes.
>
> There are two possible workarounds:
>  1. To copy our in-memory database
> into an on disk database using VACUUM INTO and subsequently restore it into
> in-memory during worker initialization
>  2. Pass a string query resulting from
> calling Connection.iterdump() into worker initialization and call that to
> restore copies of the database into in-memory for every child process.
>
> I'm testing out both now to see if there are any major differences. There
> might be a performance difference between them. I'm also checking if there
> are any unexpected errors that might arise.
>
> Regards,
> Ahmad
>
> On Sun, Mar 29, 2020 at 5:56 PM Adam Johnson  wrote:
>
>> Currently what I'm figuring out is getting a SQL dump to change SQLite's
>>> cloning method and implementing an Oracle cloning method. I'm searching
>>> through Django's documentation and internal code to see if there is a
>>> ready-made SQL dump method for SQLite and if not I'll search for it in a
>>> third-party library, and if I still don't find it, I'll start thinking
>>> about a ground-up implementation using the ORM.
>>>
>>
>> SQLite has an online backup API and the "VACUUM INTO" command both of
>> which can efficiently clone databases: https://sqlite.org/backup.html .
>> I think they can even copy memory-to-memory with the right arguments.
>>
>> On Sat, 28 Mar 2020 at 06:59, Ahmad A. Hussein 
>> wrote:
>>
>>> Apologies for the late response. I've had to attend to personal matters
>>> concerning the current crisis we're all facing. All is well though
>>>
>>> I should have posted a more detailed post from the get-go. I apologize
>>> for the lack of clarity as well.
>>>
>>> Last week, I initially did exactly what you suggested. I called
>>> django.setup() in each child process during worker initialization. This
>>> fixed app registry issues but like you said it isn't enough for testing.
>>> Test apps and test models were missing and cause

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Ahmad A. Hussein]

You're definitely right!

I just finished rewriting it to re-run migrations and setup in each worker.
I didn't bench mark it so I'll do that again later, but as a gut reaction
it isn't significantly slower; but of course the numbers will tell the real
story.

Passing the dump string through shared memory or converting in-memory to on
disk seems way too overkill now. The performance drop probably won't be
significant especially since this is SQLite.

I'll update you here with the exact benchmarks later. I'm busy now with
school work, but I'll get back to it again later today.

It is definitely exciting to find out!

Regards,
Ahmad

On Mon, Mar 30, 2020 at 11:46 AM Tom Forbes  wrote:

> Awesome! However there is always a tradeoff between speed and code
> complexity - it might not be worth a more complex system involving shared
> memory or copying SQLite files in other ways if it only saves ~5 seconds at
> the start of a test run compared to re-running the migrations in each
> worker. I guess this might be unique to SQLite where things are generally
> faster.
>
> Just something to keep in mind, I’m excited to see the results though!
>
> Tom
>
> On 30 Mar 2020, at 10:34, Ahmad A. Hussein 
> wrote:
>
>  I did stumble upon shared memory when I originally wanted to pass the
> database connection itself into shared memory. Your idea of passing the
> query string is MUCH more reasonable, can be done using shared memory, and
> will ultimately be much more cleanly written.
>
> i'll definitely test out if it has significant performance boost and see
> how it compares to other methods.
>
> I did consider copying the SQLite database file itself. That's essentially
> what's happening with VACUUM INTO. It's a SQLite command that lets you
> clone a source database whether in-memory or on disk into a database file.
> I got the parallel test runner to work with these database files, creating
> a database file for each worker. I think there's a performance boost to
> have if we make the databases for workers in-memory, especially if the test
> suite and tables grow in number; however, we also need to consider the time
> it takes to make the databases in-memory.
>
> Re-running migrations and recreating the SQLite database from scratch for
> every worker might be a time-sink, but it could actually prove quicker than
> other methods. I'll try it out as well and see.
>
> Thank you for your suggestions
>
> Regards,
> Ahmad
>
> On Mon, Mar 30, 2020 at 9:39 AM Tom Forbes  wrote:
>
>> There is an interesting addition to the standard library in Python 3.8:
>> multiprocessing.shared_memory (
>> https://docs.python.org/3/library/multiprocessing.shared_memory.html).
>> It’s only on 3.8 but it might be worth seeing if that has a performance
>> improvement over passing a large string into the workers init process.
>>
>> Have you also considered simply re-running the migrations and creating
>> the SQLite database from scratch in each worker, or simply copying the
>> SQLite database file itself?
>>
>> On 30 Mar 2020, at 08:13, Ahmad A. Hussein 
>> wrote:
>>
>> 
>> Thank you Adam for the amazing pointer. That's exactly the solution I was
>> looking for.
>>
>> I didn't even know VACUUM INTO was a thing in SQLite3 (quite nifty). Both
>> sources you listed can definitely copy memory-to-memory efficiently. I had
>> also found two useful APIs in the standard library's documentation:
>> iterdump() and backup(). The latter is an attempt at recreating the online
>> backup API you linked.
>>
>> I did face an issue in my implementation though. Memory-to-memory copying
>> is impossible under the current conditions.
>>
>> We can't copy memory-to-memory and retain the resultant databases into
>> our spawned workers since spawned child processes don't share an
>> environment with parent processes.
>>
>> There are two possible workarounds:
>>  1. To copy our in-memory database
>> into an on disk database using VACUUM INTO and subsequently restore it into
>> in-memory during worker initialization
>>      2. Pass a string query resulting
>> from calling Connection.iterdump() into worker initialization and call that
>> to restore copies of the database into in-memory for every child process.
>>
>> I'm testing out both now to see if there are any major differences. There
>> might be a performance difference between them. I'm also checking if there
>> are any unexpected errors that might arise.
>>
>> Regards,
&g

Re: Selected projects for Google Summer of Code 2020

[Ahmad A. Hussein]

I'm honestly ecstatic to have been accepted! It's something that I wanted 
to do since last year when I read about Sage's project after I started 
using Django.

I'll definitely start a blog to document the entire journey and I think 
it'll help with keeping track of my own progress. Thanks for the suggestion 
Sage.

I'll make a thread on the forums to discuss my current plans/preparations 
or any issue, and I'll be sure to link to the PR as relevant and discuss 
specific details there. 

Looking forward to working with Tom and Adam!


Regards,
Ahmad


On Wednesday, May 6, 2020 at 5:52:49 PM UTC+2, Adam Johnson wrote:
>
> Congratulations Kacper and Ahmad! 
>
> Thanks to my fellow mentors for their work so far helping filtering the 
> applications. And especially Carlton for keeping us organized.
>
> Yes the forum is a great place to keep the conversation.
>
> Looking forward to mentoring Ahmad,
>
> Adam
>
> On Wed, 6 May 2020 at 12:27, Kacper Szmigiel  > wrote:
>
>> Hello all!
>>
>> TBH I'm still shocked that I got accepted!  I don't even know how to 
>> express my satisfaction. I would like to thank you for your trust, and 
>> promise to do my best.
>>
>> About the communication channels - I will adapt to whatever suits you 
>> best. I got used to writing emails, but I can switch to forum, no problem.
>>
>> I'm also about to start vlogging about GSoC in the near future. I was 
>> planning to start doing so since a while, and this seems to be a good 
>> opportunity :D At this point I'm collecting equipment and discussing the 
>> details with my friend who is a video editor.
>>
>> I've already contacted Nikita Sobolev and started going through Mypy 
>> documentation. I think we'll establish a plan and timeline of my work next 
>> week.
>>
>> I also have to ask you to keep in mind that I will be taking my exam 
>> session at Uni in June, so I will probably do most of the work in July and 
>> September. I informed my lecturers and University authorities about getting 
>> accepted into GSoC, so maybe they'll make it easier for me to pass this 
>> semester, I hope to know the answer in a few days.
>>
>> Kind regards,
>> Kacper Szmigiel
>>
>>
>> śr., 6 maj 2020 o 11:45 Sage M. Abdullah > 
>> napisał(a):
>>
>>> Thanks, Carlton, for the briefing!
>>>
>>> I agree it's a good idea to utilize the forum for discussions. Aside 
>>> from the forum and GitHub, I'd suggest Ahmad and Kacper start a blog if you 
>>> haven't already, and write about your GSoC Journey there. I'm sure folks 
>>> would enjoy reading how you learn and implement stuff along the way. You 
>>> can also use it as a portfolio in the future. As Carlton said, we had a lot 
>>> of applications, so I think getting selected is quite an achievement. Make 
>>> the most of it for your future endeavors.
>>>
>>> You can use a static site generator like Jekyll or Hugo and use GitHub 
>>> pages to get it up and running quickly. Starting a blog is just a 
>>> suggestion, it's okay if you don't feel like it :)
>>>
>>> I was also a GSoC student with Django just last year so I'm still quite 
>>> new to a lot of things as well, but I'll try to help the best I can.
>>>
>>> So, congrats Ahmad and Kacper, looking forward to working with you!
>>>
>>> Regards,
>>> Sage
>>>
>>>
>>> On Wednesday, 6 May 2020 13:46:26 UTC+7, Carlton Gibson wrote:
>>>>
>>>> Hi all. 
>>>>
>>>> We had lots of applications for GSoC, and lots of folks to act as 
>>>> mentors, so I want to 
>>>> thank everyone there.
>>>>
>>>> Django was accepted into GSoC. We were granted two slots. Thus for 
>>>> 2020, 
>>>> two student proposals were selected:
>>>>
>>>> * Kacper Szmigiel, an undergraduate student at Technical University of 
>>>> Lodz in Poland, will work on a refactor of the mypy plugin plugin that is 
>>>> part of [django-stubs][0]. His primary mentors are Nikita Sobolev, and 
>>>> Artem Malyshev, maintainers of django-stubs. 
>>>>
>>>> [0]: https://github.com/typeddjango/django-stubs
>>>>
>>>> * Ahmad A. Hussein, an undergraduate student German University in 
>>>> Cairo, will work to extend the parallel test runner to Windows, macOS, and 
>>>> add Oracle support. His primary mentors are 

Re: Proposal for Table Functions

[Ahmad A. Hussein]

I'm not an expert or even an amateur at the ORM, but here are my thoughts
on the matter:
1. Does it carry over well across the four databases?
2. Is it necessary to include it as part of core versus a third-party app?
3. What specific use case will benefit from adopting this idea?

I ask the second question because it seems from your gist that you don't
need your proposal to be part of core for it to work. It seems it would
work completely well and flourish even as a third-party app given how
you're subclassing the API and expanding on its usage. Contrast this with
django-pytest for example that can have a harder problem running pytest on
Django due to how the test runner is currently built (namely that setup
assumes a subclass of the Django test runner).

Regards,
Ahmad
On Sun, May 17, 2020 at 4:36 PM Petr Přikryl  wrote:

> Hi, I have just implemented Table Function support on Django 2.1. What do
> you think about adopting it into Django itself?
>
> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a
>
> It is all about passing function parameters into BaseTable and Join
> classes
> https://github.com/django/django/blob/master/django/db/models/sql/datastructures.py
>
> Here are other thoughts which were inspiring me
> https://schinckel.net/2019/10/31/functions-as-tables-in-django-and-postgres/
>
> Thanks,
> Petr
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6d16fdfc-332f-4a72-83ae-04ee5c9fd28a%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/6d16fdfc-332f-4a72-83ae-04ee5c9fd28a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJNa-uPBFBhOyrMB9X97wVU12Hk6%2Bn7Jy8qSXhZr6-jGn9mOsQ%40mail.gmail.com.

Re: Proposal for Table Functions

[Ahmad A. Hussein]

Concerning tests, I did not mean to comment about the tests you wrote. I 
used the third party py-test django app as an example of an app that does 
need work in core to function better, not as a comment about your usage of 
tests. You're more than free to work the way you want to :) (I like pytest 
too)

If there's an optimization to be had in including table functions and it'll 
be backwards compatible without breaking anything, then I think there's 
merit in the idea. I suggest you open a ticket on the issue tracker and 
mention how significant the optimization was. It'll help with getting this 
new feature adopted.

You can open it here <https://code.djangoproject.com/newticket>



On Monday, May 18, 2020 at 8:31:04 AM UTC+2, Petr Přikryl wrote:
>
> ad 1. I was testing it on PostgreSQL only. But:
>
>- Oracle is feasible through custom extendings in compiler 
>
> https://livesql.oracle.com/apex/livesql/file/content_C87XCH8SE085LMS3C5KR03VFS.html
>- MySQL is also feasible https://stackoverflow.com/a/23421816/1763888
>- SQLite has some special limited table functions which should be 
>syntax-compatible with Postgres 
>https://www.sqlite.org/vtab.html#tabfunc2
>
> ad 2. Yes, "it is necessary". Because I must do some nasty hacks in my 
> gist. For example:
>
>- SQL regex parsing 
>
> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a#file-function-py-L189.
>  
>Which could be removed if base method would know about parameters.
>- Classic "Join" overriding 
>
> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a#file-function-py-L277.
>  
>I don't like it because I need work with "level" (order) of joins to map 
> it 
>to user lookups correctly. If ithis would be in core, then the lookups 
> from 
>"filter" could be merged witth lookups from "table_function" more easily. 
>There is also possibility to merge logic from table_function into filter 
>and use only filter method for passing parameters into table functions.
>
> ad 3. The use case is optimization for me. Because I had SQL View with 
> recursion. The View was mapped into Django through model. But operations 
> with this view takes long time for my app. So I found out that I can 
> optimize that using table function instead view with parameter limiting the 
> recursion depth. But I couldn't switch view to table function because no 
> ORM support. With this gist I could.
>
> ad tests. I used them because I am used to use them :-). And I think that 
> it should be re-writable to classic Django tests.
>
> Petr
>
>
> Dne neděle 17. května 2020 23:08:08 UTC+2 Ahmad A. Hussein napsal(a):
>>
>> I'm not an expert or even an amateur at the ORM, but here are my thoughts 
>> on the matter:
>> 1. Does it carry over well across the four databases?
>> 2. Is it necessary to include it as part of core versus a third-party app?
>> 3. What specific use case will benefit from adopting this idea?
>>
>> I ask the second question because it seems from your gist that you don't 
>> need your proposal to be part of core for it to work. It seems it would 
>> work completely well and flourish even as a third-party app given how 
>> you're subclassing the API and expanding on its usage. Contrast this with 
>> django-pytest for example that can have a harder problem running pytest on 
>> Django due to how the test runner is currently built (namely that setup 
>> assumes a subclass of the Django test runner).
>>
>> Regards,
>> Ahmad
>> On Sun, May 17, 2020 at 4:36 PM Petr Přikryl  wrote:
>>
>>> Hi, I have just implemented Table Function support on Django 2.1. What 
>>> do you think about adopting it into Django itself? 
>>>
>>> https://gist.github.com/petrprikryl/7cd765cd723c7df983de03706bf27d1a
>>>
>>> It is all about passing function parameters into BaseTable and Join 
>>> classes 
>>> https://github.com/django/django/blob/master/django/db/models/sql/datastructures.py
>>>
>>> Here are other thoughts which were inspiring me 
>>> https://schinckel.net/2019/10/31/functions-as-tables-in-django-and-postgres/
>>>
>>> Thanks,
>>> Petr
>>>
>>> -- 
>>> 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-d...@googlegroups.com.
>>> To view this discus

Re: The blacklist / master issue

[Ahmad A. Hussein]

I'd argue that since Django is an international framework, we should strive
to set an international standard. If a certain word is off-putting or
problematic to individuals in our community, and if it does not convey an
accurate and least astonishing meaning to a non-native English speaker,
then we should definitely change it.

On Fri, Jun 19, 2020 at 2:54 PM Alexander Lyabah 
wrote:

>
> Django in international framework, not US-framework. You should not change
> variable names just because meaning of some words have been changed in US
> recently. Those words have been used in source-code for years, and nobody
> put racism in those word when this framework was founded and nobody puts
> any racism in when one is using for creation something big and meaningful.
>
> What I'm encourage you to do, is to thing farther than what is going on
> right now.
>
> If Django Foundation really want to help in this revolution - add a banner
> on that landing page. Feel free to choose
>
> https://eji.org/
> https://org2.salsalabs.com/o/6857/p/salsa/donation/common/public/
>
> And this kind of contribution will work much better.
>
> Thank you, for this opportunity to share my opinion.
>
> On Monday, June 15, 2020 at 7:28:23 PM UTC+3, Tom Carrick wrote:
>>
>> This ticket was closed wontfix
>>  as requiring a
>> discussion here.
>>
>> David Smith mentioned this Tox issue
>>  stating it had been closed,
>> but to me it seems like it hasn't been closed (maybe there's something I
>> can't see) and apparently a PR would be accepted to add aliases at the
>> least (this is more recent than the comment on the Django ticket).
>>
>> My impetus to bring this up mostly comes from reading this ZDNet article
>> 
>> - it seems like Google have already made moves in this direction and GitHub
>> is also planning to. Usually Django is somewhere near the front for these
>> types of changes.
>>
>> I'm leaning towards renaming the master branch and wherever else we use
>> that terminology, but I'm less sure about black/whitelist, though right now
>> it seems more positive than negative. Most arguments against use some kind
>> of etymological argument, but I don't think debates about historical terms
>> are as interesting as how they affect people in the here and now.
>>
>> I don't think there is an easy answer here, and I open this can of worms
>> somewhat reluctantly. I do think Luke is correct that we should be
>> concerned with our credibility if we wrongly change this, but I'm also
>> worried about our credibility if we don't.
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1c9178a3-cb80-428c-bacb-e8904695f6b6o%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJNa-uOOWNRmAnDhiydQC-MrEsRDyED%2B_PJzFDu5gU6GjqSs1A%40mail.gmail.com.

Re: Welcome email

[Ahmad A. Hussein]

+1 on this. Here's the relevant feature
<https://support.google.com/a/users/answer/9308780?hl=en> I found.


Ahmad

On Sun, Jul 5, 2020 at 7:58 PM Adam Johnson  wrote:

> I can't find a google groups feature that would allow this. Do you know of
> one? It might otherwise require a custom bot.
>
> On Sun, 5 Jul 2020 at 16:14, Arvind Nedumaran 
> wrote:
>
>> Oh I understand. I meant we could include the distinction in the welcome
>> email and possibly a link to the other list.
>>
>> That may reduce the number of people who may be looking for help but end
>> up here mistakenly?
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>>
>> --
>> *From:* django-developers@googlegroups.com <
>> django-developers@googlegroups.com> on behalf of אורי 
>> *Sent:* Sunday, July 5, 2020 8:39:22 PM
>> *To:* Django developers (Contributions to Django itself) <
>> django-developers@googlegroups.com>
>> *Subject:* Re: Welcome email
>>
>> I think because this list is called Django developers and what we call
>> "Django users" are also developers who use Django. But they are developers.
>>
>> אורי
>> u...@speedy.net
>>
>>
>> On Sun, Jul 5, 2020 at 5:59 PM Arvind Nedumaran 
>> wrote:
>>
>> Hey everyone,
>>
>> I notice that people who try to find support on using Django mistakenly
>> post in this list and sometime usually has to write an explanation about
>> how this is the wrong place.
>>
>> Could we possibly as a welcome email whenever someone joins the group?
>>
>> Just a suggestion.
>>
>> Best,
>> Arvind
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/BYAPR14MB29181EBF50C845052F69E5E1A3680%40BYAPR14MB2918.namprd14.prod.outlook.com
>> <https://groups.google.com/d/msgid/django-developers/BYAPR14MB29181EBF50C845052F69E5E1A3680%40BYAPR14MB2918.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CABD5YeH0WySFuBnzyXENnMt-5bN5hawS4HYoNUVeGFG8TLG0qw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CABD5YeH0WySFuBnzyXENnMt-5bN5hawS4HYoNUVeGFG8TLG0qw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/BYAPR14MB291816DB21661EDBBC954AB5A3680%40BYAPR14MB2918.namprd14.prod.outlook.com
>> <https://groups.google.com/d/msgid/django-developers/BYAPR14MB291816DB21661EDBBC954AB5A3680%40BYAPR14MB2918.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> Adam
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2YJpza4URzW%2BrcDZi_7crJcqOz4QrCd7W45PZeR71%3DNA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2YJpza4URzW%2BrcDZi_7crJcqOz4QrCd7W45PZeR71%3DNA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJNa-uPEnskA_seJhscuJ1%2B%3DcR17-OfFM26HpWDDGS7bqv1o0g%40mail.gmail.com.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[Ahmad A. Hussein]

Hi Diptesh,

This is a great idea! (And one that has had a fair bit of discussion). I
don't think anyone holds an opinion against supporting pytest as a testing
tool, but I believe the main hurdle is laying a convincing argument why
this support should be in Django Core versus remaining in its current
third-party state. I personally believe it should be in core because a lot
of custom features we'd like to add to the test runner already exist in
pytest's rich ecosystem. Just as Tom mentioned, adding timings was a lot
harder than expected while such a feature already exists in pytest.

If we aren't going to add it to core, the question I'd like to raise (and
preferably get an answer from experienced pytest-django users/developers)
is what changes can we make in core to make it easier for the pytest-django
package.

Lastly, if you intend to purely write documentation, I would recommend you
apply for next year's Google Season of Docs instead of Google Summer of
Code. It would be a better fit for the job description

On Tue, Dec 15, 2020 at 3:52 PM Diptesh Choudhuri <
diptesh.choudh...@gmail.com> wrote:

> Though the django default runner gets the job done, I think its high time
> to leverage the power of dedicated frameworks for testing django apps. I
> will take up the case of *pytest* here because other frameworks like *nose
> *are not widely used.
>
> For everyone who has used pytest for testing in django, I think we will
> all agree that pytest is much better suited to this task.
>
>1. The passing tests look better.
>2. Failing tests are much more verbose with where the error actually
>occurred.
>3. Parameterizing the test cases using the default runner requires a
>third party library and looks difficult
>
> 
>  (I
>will be honest, I haven't used this package myself at all).
>4. Injecting runtime conditions into the tests is quite difficult, if
>not impossible, and requires a lot of hacky workarounds.
>5. I am not sure about this, but the default runner also doesn't cache
>results from previously run tests, making retesting unchanged tests much
>slower.
>6. This might sound non-trivial but typing *pytest *is much more
>easier than typing *python manage.py test *into the command line.
>7. IDEs like VSCode can discover tests written for *pytest *but not
>the ones written using the default runner. This might not sound a big deal,
>but it is infinitely more easier to run tests using the GUI that these IDEs
>have. They provide real-time feedback and show exactly which tests have
>passed and what haven't in the code source itself. Here
> is a picture showing what I mean.
>8. The directory structure created by *python manage.py startapp
>my_app *creates a *tests.py *file. This goes against testing best
>practices which say that all tests should be aggregated at one place (as
>opposed to inside individual apps).
>9. A single *tests.py *file encourages new, inexperienced developers
>to write all their tests in a single file. This, yet again, goes against
>testing best practices which put a lot of emphasis on modularization of
>tests. Models should be tested in *test_models.py*, views in *test_views.py
>*etc.
>10. Though *unittest*'s *setUp *and *tearDown *work fine, I personally
>find that *pytest*'s fixture system provides a bit more freedom. I
>might want to put all my test methods in one *class*, but I might not
>want to run the *setUp *and *tearDown *for every test method. (Let me
>know if this point is a bit unclear.)
>
> *pytest *and *pytest-django *are quire mature frameworks and don't need a
> lot of changes. We could make it easier to setup tests right out of the
> box. For example, *django-admin startproject my_project *could create a 
> *pytest.ini
> *right out of the box in the project root.
>
> Most of my focus would be on rewriting and adding documentation. Even
> though widely used, *pytest *and *pytest-django *are pretty difficult to
> get started with for a newbie. I intend to fix this by adding a lot of
> examples to the docs (maybe even make a separate repository for this).
>
> *NOTE: I intend to work on this project for GSoC 2021. I am just scouting
> beforehand to see how the community receives it.*
>
> Please let me know what you think of this idea. Any critiques will be
> welcome.
>
> Best,
> Diptesh
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8c5e0baa-5104-4876-a936-8792b3c8d5b8n%40googlegroups.com
> 

Re: Changing the discovery method for management commands

[Ahmad A. Hussein]

What are the remaining use cases here? Is the proposed change absolutely
necessary for these use cases?



On Sat, Dec 19, 2020 at 6:19 PM Diptesh Choudhuri <
diptesh.choudh...@gmail.com> wrote:

> Though its just one file and two directories, the use case is common
> enough to be used by a lot of packages and I think django should do
> something to support it officially.
>
> On Saturday, December 19, 2020 at 8:19:28 PM UTC+5:30 f.apo...@gmail.com
> wrote:
>
>> On Saturday, December 19, 2020 at 3:16:51 PM UTC+1 diptesh@gmail.com
>> wrote:
>>
>>> and having to add a bunch of unnecessary files to the source code
>>
>>
>> A bunch? You can literally get away with one file:
>>
>> ➜  testing git:(dc_message_signing) ✗ tree testabc
>> testabc
>> └── management
>> └── commands
>> └── my_cmd.py
>>
>> This is a complete (!) django app. While I agree that in theory it would
>> be nice to support some other mechanisms, I do not think it is worth the
>> effort given how easy it is to add a command (one file & two directories)
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d1f62c54-8f9c-46a1-ba57-e5506bca3436n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJNa-uMrVZJAOtSJ3qMrB89L8RA%3DdGo_aD1%2BFArM6FYDnr1ugA%40mail.gmail.com.

Re: Query regarding Google Summer Of Code

[Ahmad A. Hussein]

Hello Muskan,

"We're still going to be strict with what we accept - you'll need to
provide a *strong use case* for your idea and show that it would be *useful
to a majority of developers* or *significantly improve* the development of
Django itself."

This is from the wiki page
 for GSoC 2021. So I
believe you could submit a GSoC proposal for UI/UX but your proposal would
need to greatly impact a sizable amount of developers.

As for UI/UX fixes, I believe the process is the same as normal tickets:
you submit a ticket on the issue tracker, people review it and establish
consensus, and then you submit a patch following said consensus.

If you're looking to get feedback on your proposal, submit it on the forums
 under Mentorship. Plenty of people will
take a look at it and will help you get on the right track.

On Tue, Mar 16, 2021 at 7:50 PM Muskan Vaswan 
wrote:

> Hello again, I am Muskan and I have a few questions regarding GSoC 2021.
>
> Are contributions to django/djangoproject (the tickets trac) considered in
> GSoC. While the dashboard itself is mentioned on the wiki page I was
> wondering if it extends to the issue tracker itself to. If so, then would
> fixing UI/UX bugs (large enough) be considered a valid contribution to
> GSoC?
> Besides this, regardless of GSoc, what is the process of approval for
> UI/UX fixes in any of the django projects/sub-projects? Does this process
> stay the same in consideration of a GSoC proposal?
>
> Is there any mentor or such, that we as GSoC aspirants can get in tough
> with before the submissions of proposals so we can more more freely ask
> doubts specifically related to our potential proposals?
>
> -
> Regards
> Muskan Vaswan
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f1bf29ea-f7ce-421d-8c3d-b3af9c6d89c8n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJNa-uMgEkStpU_z%3DgwFBuR7i43Hao5pnHQZBs-o-fth0nbE9w%40mail.gmail.com.