Re: UNICODE and newforms

[Arthur]

> +1 for unicode in django

+1

Regards, Arthur.

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

#1165: Wrong column name in ForeignKey constraints

[Arthur]

Hi all

I've had a closer look at ticket #1165 where the wrong SQL column name
is used for PositiveIntegerFields. The problem is that the data type
for foreignKeys gets derived from its referenced field with the
__dict__ of the referenced field. This is correct for fields like
CharFields, where i.e. maxlength  is needed but wrong for types where
a column name is needed. At present this is only for
PositiveIntegerFields and PositiveSmallIntegerField the case.

There are several possible solutions. One would be to use a combined
__dict__ for ForeignKeys where the "column" entry  would be from the
current field and not the referenced one. Or PositiveIntegerFields and
PositiveSmallIntegerField could be special cased. My favourite
solution would be to get rid of the CHECK >= 0 alltogether in the
referencing SQL code. The db already knows about the constraint. My
question is where to put such a change. One could change line 59 in
management.py and make PositiveIntegerFields simple IntegerFields:

get_rel_data_type = lambda f: (f.get_internal_type() == 'AutoField')
and 'IntegerField' or (f.get_internal_type() ==
'PositiveIntegerField') and 'IntegerField' or (f.get_internal_type()
== 'PositiveSmallIntegerField') and 'SmallIntegerField' or
f.get_internal_type()

The downside is that this special cases PositiveIntegerFields and
PositiveSmallIntegerField and isn't a general solution for all
possible future fields which could use a constraint.

Any thoughts?

Arthur

Re: Status of magic-removal

[Arthur]

> I, for one, want to get m-r wrapped up and merged back to trunk as
> soon as humanely possible.  I feel like it's starting to be a drag on
> new users trying to figure out why development on trunk seems to have
> stopped, and I want to get us all back to one codebase.

+1

Arthur

--~--~-~--~~~---~--~~
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: templates and html escaping

[Arthur]

> > I've thought about this a bit more; lots of good points have been
> > raised.  What I'd like to do would be to add a new tag that takes
> > care of auto-escaping variables used within it.  Something like::
> >
> >   {% autoescape %}
> >   Any {{ variables }} used within this {{ block }} will be
> > automatically {{ escaped }}
> >   {% endautoescape %}
> >
> > How does that sound?
>
> Not quite enough IMHO.
>
> I strongly agree with some of the other posters in this thread that
> any kind of output in an HTML-template should be HTML-escaped by
> default. Values that contain markup that should not be escaped should
> be flagged explicitly.
>
> In Trac 0.9.3 we added exactly this kind of behavior to greatly
> eliminate the risk for XSS vulnerabilities. See:
>
><http://projects.edgewall.com/trac/browser/trunk/trac/util.py#L56>
>
> When the template engine sees a value that is a str/unicode, it gets
> escaped. If it gets a value that's an instance of the "Markup" class,
> it gets passed through as-is.
>
> Adding such behavior to the Django template processor would be great.
> It's *much* easier to forget to escape something than to forget to
> flag it as not-needing-escaping.

Sorry for being late to the discussion. Just wanted to give a +1 on
having the possibility to escape (or not escape) whole blocks and a +0
on escaping everything per default. Is there already an open ticket on
this?

Arthur

--~--~-~--~~~---~--~~
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: #1602: urlify.js blocks out non-English chars

[Arthur]

> > I suggest we change urlify.js in a way that will not block out
> > non-English chars. Instead it should translate them into their English
> > feel-a-like, as suggested in #1602.
>
> If we decide to go the sound-alike route, a good resource to start
> from might be the Textpattern CMS [...]>
> http://dev.textpattern.com/browser/releases/4.0.3/source/textpattern/lib/i18n-ascii.txt

That list looks very nice to me, at least for those languages I know.
The problem with the look-alike route is, that at least for German,
people are used to the what you call sound-alike pattern. In the case
of German it's not so much a phonetic pattern as it is more a
transcription convention. ("schwül/schwuel" <-> sweltering, "schwul"
<-> homosexual(♂) don't have the same meaning.)

Unfortunately I don't know much about standards in this area. If there
are any proven ones, I'd vote to use them. Using Unicode in URLs would
be fine with me, I don't know how well Browsers/Proxies/Servers/Search
Engines handle them.

Arthur

--~--~-~--~~~---~--~~
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: #1602: urlify.js blocks out non-English chars

[Arthur]

> @Arthur: You know what? Why don't we just do whatever feels more
> natural to our language? Then again, I can sense some transliteration
> collisions on the way.

Absolutely, this should be language specific. If you look at the
proposed list, you see that there are different transliteration
patterns for example for fi-fi than for others. And yes, google does
quite a bit of that stuff: If you search for "aengstlich" on
google.com it won't find "ängstlich" but if you search for
"aengstlich" under google.de/.ch/.at it'll automagically include all
"ängstlich" results.

Arthur

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

[Feature Request] extra_context -> dataclass

[Arthur]

Hi all!

Currently django views do not accept dataclasses as context.

I stumbled about this because I wanted to do something like this:

@cached_property
def extra_context(self):
data = MyDataClass(...)
...
return data

Unfortunately, this is unpacked by get_context_data and throws an error 
because a dataclass can't be iterated (core code):


def get_context_data(self, **kwargs):
kwargs.setdefault('view', self)
if self.extra_context is not None:
kwargs.update(self.extra_context)
return kwargs


I know I could do a asdict(data)inside the `extra_context` but with the 
transformation to a dict, I will lose all my typesafety, e.g.:


def get_template_names(self):
if self.extra_context.somedata:  # << somedata is typed
...

A simple check for dataclass would be nice (
https://docs.python.org/3/library/dataclasses.html#dataclasses.is_dataclass
):


def get_context_data(self, **kwargs):
kwargs.setdefault('view', self)
if self.extra_context is not None:
if is_dataclass(self.extra_context) and not 
isinstance(self.extra_context, type):
kwargs.update(asdict(self.extra_context))
else:
kwargs.update(self.extra_context)
return kwargs


Kind regards!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b43c5655-c44a-4f9b-8503-37366ec7ea5en%40googlegroups.com.

Re: Improving (and testing!) bash completion

[Arthur Koziel]

Hey Eric,

That's a very good idea. I've looked through the current management commands to 
see what arguments they take. The most used variants are:

- no arguments
- custom list
- appname(s)
- fixture(s)

The problem with your proposal is the handling of multiple appnames and 
fixtures (e.g. "django-admin.py sqlreset [options] " since 
each position must have a value assigned in the iterable returned by 
`complete`. I think a better idea would be to pass the current cursor position 
to the `complete` function:

def complete(self, pos):
if pos == 1:
return ('foo', 'bar',)
elif pos >= 2:
from django.conf import settings
return [(a.split('.')[-1], 0) for a in settings.INSTALLED_APPS]

That way we could easily handle cases where one or multiple appnames are passed 
and avoid dealing with complex data structures. Displaying the directory 
listing for fixtures wouldn't be a problem either since the function could just 
return None. The `-o default` setting of the bash-completion would then default 
to displaying the directory listing.

In addition to that, I'd also like to change the way options and arguments are 
displayed. If you currently type "./manage.py dumpdata " it will display 
options as well as arguments. All other bash-completion scripts[1] display only 
the arguments. The options are displayed if the user entered a dash and pressed 
tab e.g. "./manage.py dumpdata -". I think we should do the same to be 
consistent with other bash-completion scripts.

[1]: 
http://git.debian.org/?p=bash-completion/bash-completion.git;a=tree;f=contrib;h=ae6cbcbb425cfc2cd1c3bb38b349512983187c0a;hb=HEAD

Arthur

On Nov 15, 2009, at 11:35 PM, Eric Holscher wrote:

> Hey all,
> 
> I recently was looking for a way to add bash completion to a management 
> command that I made. With changeset 11526[0] during the djangocon sprints, 
> bash completion was moved from bash into Python. Now there is a super basic 
> bash script that calls django-admin.py with the correct environment for it to 
> autocomplete.
> 
> Now that the code is in Python, this lets us do a lot more with it. As 
> implemented, a custom management command's options (--settings, --list) will 
> be autocompleted. There is currently no way to define arguments to your 
> function that will be autocompleted. I went ahead and looked through the code 
> today and wrote up some proof of concept code that does just this.
> 
> What I did
> 
> 
> First thing I did was write tests for the current behavior[1]. No tests were 
> written for the original commit, so if nothing else, these tests should be 
> commited. The link there works for the current environment, then I added a 
> few more tests that test my changes as well.
> 
> After that, I implemented a basic API for declaring a completion in a Command 
> class[2]. I will describe here the implemented API. I'm hoping that people 
> have some ideas about the correct way to implement this.
> 
> Currently, your Command class will define a complete() function along with 
> your handle() function. The complete() function can then return two different 
> things. In the simple case, it can return a simple list of arguments that it 
> expects to be able to handle. These will be passed along to the bash 
> completion, and complete appropriately. 
> 
> So for example if your custom command 'check_site' had a complete() command 
> that returned ['ljworld', 'kusports', 'lcom'], and on the command line you 
> did `django-admin.py check_site ljw`, it would return ljworld.
> 
> The more complex case is where you want to be able to define multiple 
> positional arguments for a command. Currently, this is implemented by 
> returning a dict with the key being the number that you want to complete 
> (this sucks. So you could do something like:
> 
> def complete(self):
> return {
> '0': ['ljworld', 'kusports']
> '1': ['year', 'week', 'day']
> }
> 
> Then you would be able to do `django-admin.py ljworld ye` and it would 
> return `year`.
> 
> Currently there is also special casing for returning All Installed Apps, and 
> All Installed Commands. I went ahead and made a magic symlbol "APP_NAME" and 
> "COMMAND_NAME" that will evaluate to these lists. Both of these APIs seem a 
> bit hacky.
> 
> So currently I am thinking about making the following changes to make this 
> stuff a bit better.
> 
> Proposal
> ===
> 
> I think that instead of special casing[3] the commands that take an APP_NAME 
> etc., we would put the com

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Arthur Furlan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Dec 30, 2009 at 08:06:02PM +0800, Russell Keith-Magee wrote:
> On Wed, Dec 30, 2009 at 8:15 AM, Nic  Pottier  wrote:
> >
> > New to Django, but certainly not web development.  After being
> > pleasantly surprised with a lot of the available Django filters I was
> > rather surprised not to see a string truncation filter included.
> >
> > A little googling shows I'm not the only one, there are tons of people
> > writing their own filters to accomplish this, and sure enough a nice
> > looking patch submitted two (TWO!) years ago to add a |truncate.
> >
> > I'd be curious to hear what the reason for not accepting this patch
> > is.  String truncation is a pretty common task, and having it built in
> > seems like a no-brainer.
> 
> I disagree.
> 
> Firstly, as James points out, slice already exists, and the ellipsis
> difference between slice and truncate can be easily overcome with
> additional code.
> 
> Secondly, IMHO raw truncation based on characters is bad practice for
> human readable text. A sentence is composed of words, not characters.
> Truncating a sentence mid-word isn't a typographical practice that I
> particularly want to encourage.
> 
> I would be marginally more inclined to support a truncate filter that
> obeyed word boundaries  i.e., no more than 50 characters, but stop at
> the end of the last complete word. However, even with this
> modification - what's the use case for an N character truncation? It
> can't (or shouldn't be) to make sure that text will fit into a visual
> space. You can't guarantee how wide N characters will be at
> render-time due to differences in character width. If you want to
> truncate for display purposes, you should be looking at CSS overflow
> properties or other display-level tricks.

This feature, of truncating in word bondaries or truncating
based on characters, could be added as an option. I think it's valid
to take a look at the truncate[1] filter of the Smarty Template Engine
because it solves some of the problems that have been discussed here.

[1]. http://www.smarty.net/manual/en/language.modifier.truncate.php


- -- 
Best regards,

Arthur Furlan (afurlan)
afur...@afurlan.org
http://blog.afurlan.org
Public GPG KeyID: 27D81084

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLO0fKAAoJEOW5JtQn2BCENIMP/0ex/IKnSFlwHwQTiclfnRyK
ooXODJXsk90sh8GaocLBic3NJ+pminMKHclavZKdlXYgA9RSMTlfLXRJU7WFvEJx
hZ5U2eDUGXyMy++Onj04fAJG8Q7+4mRRlgkEH520b2RRPndyBw4RMpbIaTYzi+Pc
FA1hgTmK+j3ojbkRZeQIYn3w53n0R4n990YumrfclcpOtWc7/YW0g0+uEBdLJ4pZ
B8uAFlDZCABcfj6wS6kewJfXRxDzX+6ch5cMgTle1LfRlWOyu+RAeV5An8fxykw9
pGZClIVHrE5zeFus8J7RawnodbaiuxfTgEGnWqLii/ddrjBEMebeKOrWaEYen/bF
30jFbrfJ+OcqSJJQZO5rqA27ihFpEQH2Qlo297OlJo3yGN2AKVMGMjRERYKRipf6
Wr7JsHYACxxHi1cGtodoBUKuwIDb28UpaIjgTbgU70BwiOYdfO3nU3zDf/sigarz
2HV7OZQYOqoXyf3tQPu/vQ44nompG/zxpdXJAf3dMcZ/HtmAB06a+XROeoq7SkGu
FZllvvIY27x56M6WIw8ZwHJqSfq9u7HGNhJBLRY+dxB6rbAWqDPLyMNvlibzLT+6
H0c+C+Es6qA2HrCt9Oo5nrnMQWw9Xwd/uGdocQBZUY9w7kXzCPIQcXkubhxhwLn6
9SSLNn5nUbJ5xqLZ9f3e
=UCaA
-END PGP SIGNATURE-

--

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.

Re: Porting _django_bash_completion to Windows Powershell

[Arthur Koziel]

On Mar 17, 2010, at 3:35 PM, guillermooo wrote:

> autocomplete() is executed always, regardless whether the user has
> requested completions or not. The only early exit point of
> autocomplete() is reached if DJANGO_AUTO_COMPLETE is false. Otherwise,
> sys.exit(1) returns to the console. How is this avoided when you do
> something like `manage.py sqlall`? Is the variable
> DJANGO_AUTO_COMPLETE implicitly unset after each execution of the
> completion bash script?

36 COMPREPLY=( $( COMP_WORDS="${COMP_WORDS[*]}" \
37COMP_CWORD=$COMP_CWORD \
38DJANGO_AUTO_COMPLETE=1 $1 ) )

The Python function is executed in a Bash subshell (that's what the outer round 
braces are for). COMP_WORDS/COMP_CWORD and DJANGO_AUTO_COMPLETE are local 
variables and available only within this subshell.

Arthur

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

GSoC: App Loading

[Arthur Koziel]

Hi,

I’m going to apply for GSoC with the goal of refactoring the app loading [0]. 
I’ve been looking at Django’s current app loading implementation 
(db.models.loading), Vinay Sajip’s patch in #3591 [1] and the notes on the 
InstalledAppsRevision wiki page [2]. Here's what I'm planning to change. Any 
feedback is appreciated.

Step 1
-

Deal with the two main problems of the current app loading implementation, and 
make it possible to:

- deploy several instances of the same app
- deploy two apps with the same name

The INSTALLED_APPS setting will be changed to:

INSTALLED_APPS = InstalledApps(
'django.contrib.auth', # strings will be converted to App()
App('django.contrib.contenttypes'),
App('django.contrib.sessions'),
App('django.contrib.sites'),
App('django.contrib.messages'),
App('django.contrib.admin'),
App('django.contrib.admin', name=‘demo’),
)

The InstalledApps and App classes will be added to core.apps. The 
db.models.loading module will be deprecated and redirect to core.apps.

The structure of the InstalledApps class will be similiar to the 
db.models.loading.AppCache class. Instead of storing the model 
modules/instances for each app (app_store/app_models), this class will store 
the App instances. An App instance will store the model modules/instances.

The methods of the old AppCache class (get_apps(), get_app(), ...) will be kept 
for backwards compatibility but modified to reflect the change mentioned above.

Step 2
-

As mentioned on the InstalledAppsRevision wiki page [2], model._meta.app_label 
is overloaded and used for:

- Admin app display name (by .title())
- Admin permissions prefix
- DB table creation prefix
- Dumpdata/Loaddata fixture prefix identifier
- When explicitly set, used to associate models elsewhere in the app structure.
- RelatedObject explicit cross-app identification.
- contrib.contenttypes identification

The goals of Step 2 is to add options to the App class and modify other parts 
of Django to not rely so heavily on app_label. For example, a `db_prefix` 
option could be added to the App class and the ORM code could be modified to 
use db_prefix instead of app_label:

INSTALLED_APPS = InstalledApps(
App('django.contrib.admin', db_prefix='chewie'),
)

In order for this to work, each model instance needs to have an app instance 
associated (via _meta.app). The orm code can then use model._meta.app.db_prefix 
to create the table.

Step 3
-

The current app loading implementation in Django was designed to load model 
classes. However, there are many applications which just provide templatetags 
or management commands and don’t use Django’s ORM at all. These applications 
have to ship with an empty models.py file in order to be loaded correctly. The 
goal of Step 3 is to make it possible to load applications without a models.py 
file.

This step is optional. If Step 1 and 2 are finished and there is still some 
time left during the GSoC, I’m going to work on this.

Arthur

[0]: http://code.djangoproject.com/wiki/SummerOfCode2010#Apploading
[1]: http://code.djangoproject.com/ticket/3591
[2]: http://code.djangoproject.com/wiki/InstalledAppsRevision

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

Re: GSoC: App Loading

[Arthur Koziel]

On Apr 7, 2010, at 1:40 PM, Russell Keith-Magee wrote:

> On Mon, Apr 5, 2010 at 5:35 AM, Arthur Koziel  wrote:
>> Hi,
>> I’m going to apply for GSoC with the goal of refactoring the app loading
>> [0]. I’ve been looking at Django’s current app loading implementation
>> (db.models.loading), Vinay Sajip’s patch in #3591 [1] and the notes on the
>> InstalledAppsRevision wiki page [2]. Here's what I'm planning to change. Any
>> feedback is appreciated.
>> Step 1
>> -
>> Deal with the two main problems of the current app loading implementation,
>> and make it possible to:
>> - deploy several instances of the same app
>> - deploy two apps with the same name
>> The INSTALLED_APPS setting will be changed to:
>> 
>> INSTALLED_APPS = InstalledApps(
>> 'django.contrib.auth', # strings will be converted to App()
> 
> Strings will be converted to App()... by What? When?
> 

The InstalledApps() class will do the converting during the initialization. As 
Vinay mentioned, his patch already does this in line 157.

> What happens to existing code that is using "for app in INSTALLED_APS"
> as an idiom?

That's the main reason why INSTALLED_APPS will be an InstalledApps instance. 
This way, an __iter__ function could be added that goes through an internal 
dict of Apps and yields their module path as a string.

> 
>> App('django.contrib.contenttypes'),
>> App('django.contrib.sessions'),
>> App('django.contrib.sites'),
>> App('django.contrib.messages'),
>> App('django.contrib.admin'),
>> App('django.contrib.admin', name=‘demo’),
>> )
>> 
>> The InstalledApps and App classes will be added to core.apps. The
>> db.models.loading module will be deprecated and redirect to core.apps.
> 
> Is there a specific reason for this move? Is it just shuffling
> deckchairs, or is there a purpose behind the move?

Yes, I wanted to make it optional for Apps to have models associated. And if an 
App doesn't require models, what's the point of it to live in db.models?

> 
>> The structure of the InstalledApps class will be similiar to the
>> db.models.loading.AppCache class. Instead of storing the model
>> modules/instances for each app (app_store/app_models), this class will store
>> the App instances. An App instance will store the model modules/instances.
>> The methods of the old AppCache class (get_apps(), get_app(), ...) will be
>> kept for backwards compatibility but modified to reflect the change
>> mentioned above.
>> Step 2
>> -
>> As mentioned on the InstalledAppsRevision wiki page [2],
>> model._meta.app_label is overloaded and used for:
>> 
>> - Admin app display name (by .title())
>> - Admin permissions prefix
>> - DB table creation prefix
>> - Dumpdata/Loaddata fixture prefix identifier
>> - When explicitly set, used to associate models elsewhere in the app
>> structure.
>> - RelatedObject explicit cross-app identification.
>> - contrib.contenttypes identification
>> 
>> The goals of Step 2 is to add options to the App class and modify other
>> parts of Django to not rely so heavily on app_label. For example, a
>> `db_prefix` option could be added to the App class and the ORM code could be
>> modified to use db_prefix instead of app_label:
>> 
>> INSTALLED_APPS = InstalledApps(
>> App('django.contrib.admin', db_prefix='chewie'),
>> )
>> 
>> In order for this to work, each model instance needs to have an app instance
>> associated (via _meta.app). The orm code can then use
>> model._meta.app.db_prefix to create the table.
> 
> I agree with Alex - there's a lot more detail needed here. How will I
> get access to the App instance that a model belongs to? How will
> legacy attributes like db_prefix be proxied? What is the order of
> precedence when a model and an app disagree on db_prefix?
> 
> For the record - I don't think the "multiple versions of a single app"
> problem is one worth solving. I'm not even convinced it can be solved
> at all, for all the reasons Florian identified, and then some.
> Although it may have been part of the original use case for #3591,
> much of that use case has since been replaced by namespaced URLs and
> class-based applications. If you're going to tackle this problem, I'd
> rather see you concentrate on issues like:
> 
> * Translating application names
> * Solving the "two applications called auth" problem
> * Providing configurability for db-level namin

Re: GSoC: App Loading

[Arthur Koziel]

On Apr 7, 2010, at 1:40 PM, Russell Keith-Magee wrote:

> I agree with Alex - there's a lot more detail needed here. How will I
> get access to the App instance that a model belongs to? How will
> legacy attributes like db_prefix be proxied? What is the order of
> precedence when a model and an app disagree on db_prefix?
> 
> For the record - I don't think the "multiple versions of a single app"
> problem is one worth solving. I'm not even convinced it can be solved
> at all, for all the reasons Florian identified, and then some.
> Although it may have been part of the original use case for #3591,
> much of that use case has since been replaced by namespaced URLs and
> class-based applications. If you're going to tackle this problem, I'd
> rather see you concentrate on issues like:
> 
> * Translating application names

The App class could use "verbose_name" and "verbose_name_plural" options. Since 
a lot of projects already do something like "_ = lambda s: s" in their 
settings.py file, we could do the following:

INSTALLED_APPS = InstalledApps(
App('django.contrib.admin', verbose_name=_('Adminstration'), 
verbose_name_plural=_('Administrations'))

> * Solving the "two applications called auth" problem

The "two applications called auth" problem is mainly a problem with the keys of 
the app_models dict in AppCache. The keys are mod.__name__.split('.')[-2], 
which means that for "django.contrib.auth.models" the key will be "auth". Now, 
if there is another models module "foobar.auth.models" the same key will be 
used and the models from foobar.auth will be appended to the "auth" key. So, 
for example, if both applications would have one model each, Django would 
internally load this as one application with 2 models.

Anyway, this is easy to solve. As I mentioned in the proposal I plan to remove 
the app_models dict from AppCache and track App instances instead. Each App 
instance would have a model attribute. There would be no overlap like in the 
app_models dict.

> * Providing configurability for db-level naming convention at the
> deployment level (e.g., so you can override db_prefix and table names
> when you deploy an app)
> * Providing configurability for 'app level' settings; for example,
> when deploying contrib.comments, setting the name of the model that
> will be used for content.

The App class could just take keyword arguments. To actually use this options 
would be up to the application developer. For example, django-disqus currently 
expects the user to set the following variables in settings.py:

DISQUS_SHORTNAME = 'foo'
DISQUS_API_KEY = '123123'

This could be done with:

INSTALLED_APPS = InstalledApps(
    App('django_disqus', shortname='foo', api_key='123123')
)

which I personally like better. We could then provide an get_app() function to 
get the App instance and access the options:

get_app('django_disqus').options.shortname

Arthur

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

GSOC 2010: App Loading - Week 1

[Arthur Koziel]

Hey there,

my name is Arthur Koziel and I'll be working on the app loading refactor for 
this year's gsoc program. I'm currently a business informatics student in 
dortmund, germany and working towards my bachelor's degree.

I didn't get any coding done this week. I attended the djangocon.eu conference 
in berlin and used the chance to discuss the project with my mentor (Jannis 
Leidel) in person. However, I've uploaded part of my proposal to my website 
[0]. It would be great to get some feedback on that.
 
So, what's up for next week? tests! The current app loading implementation 
doesn't have any tests and it's important to have the current implementation 
properly tested in order to validate the refactored code later on.

The code will be available in the 'soc2010/app-loading' branch in django's svn 
repository [1]. I'll be posting a weekly progress report each friday on this 
mailing list.

Arthur

[0]: http://www.arthurkoziel.com/gsoc2010/proposal.txt
[1]: http://code.djangoproject.com/svn/django/branches/soc2010/app-loading/

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

[gsoc] app loading status + questions

[Arthur Koziel]

Hey there,

I'm making some progress on the app loading gsoc project. I'm still in the 
process of writing tests for the AppCache. It took me longer than I've thought. 
However, I'm really confident that I'll finish the testing stuff this week and 
move on to writing the new App class. There are still some things that I don't 
understand. I've written them down below, and would really appreciate it if 
someone could take a look at them.

1. The AppCache is initialized early when the test cases are run, which means 
that not everything can be tested properly. I'm currently using a standalone 
script, but it would be better if Django's test runner could run the tests 
without initialized the AppCache. Are there already plans to change this (maybe 
in the testing improvement gsoc project?)

2. Some methods are using a lock in order to be thread-safe[0]. I haven't found 
a good way to test this nor can I reproduce the threading problems when 
removing the locks. Is there a good way in Python to test concurrency problems? 
(should such problems even be tested at all?)

3. Changeset 5919[1] modified the AppCache class to use the Borg/Monostate 
pattern. However, I haven't found a single case where there is more than one 
instance created. Does someone know a case?

4. Also in the same changeset, the 'nesting_level' and 'can_postpone' variables 
were introduced. These fixed a problem where the package is still being 
imported by Python and the model module isn't available yet. Again, I couldn't 
reproduce this problem. As Malcolm Tredinnick notes in the comments to Ticket 
1796 [3], writing a test case for this is difficult as the problem is dependent 
on hardware/OS/etc. Has anyone here run into similar problems or can reliably 
reproduce the error? (and is there any way to contact Malcolm?)

5. The app_errors attribute/the get_app_errors method doesn't seem to be used 
at all. Is there a reason why it's still there?

Arthur

[0]: 
http://code.djangoproject.com/browser/django/trunk/django/db/models/loading.py#L124
[1]: http://code.djangoproject.com/changeset/5919
[2]: http://code.djangoproject.com/ticket/1796#comment:65


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

[gsoc2010/app-loading] update

[Arthur Koziel]

Hey there,

sorry for not posting an update in such a long time. The hardest part of the 
refactoring so far was keeping backwards compatibility. So while the internals 
of the appcache changed, the functionality remained the same. Ayway, the 
interesting stuff is still coming up. So there aren't any new exciting features 
to try out yet. I met Jannis at EuroPython in Birmingham last week and we got 
to discuss some things. Here's a list of remaining TODO's:

* Task: Loading custom App classes

In its current state, the AppCache creates a generic App class for every entry
in settings.INSTALLED_APPS. But in order to allow packages to modify specific
attributes of this class, it should be possible for a package to ship with
their own App class (which is a subclass of django.core.app.App).

To realize this, an entry in settings.INSTALLED_APPS can be the dotted path
to the App class of a package. For example:

INSTALLED_APPS = ('foobar.FooApplication',)

The AppCache will go through the INSTALLED_APPS and instanciate generic App
classes (for entries that don't point to App classes) and custom App classes
(for those entries that point to an subclass of App).

* Task: Create (custom) App instances for dependencies

If a model from contrib.auth uses a model from another package such as
contrib.contenttypes, the ModelBase will trigger the registration for both
models. This means that there need to be App instances (or custom app
instances) created for these dependencies. This is already partly implemented
as there are generic App classes instanciated.

The problem with this task is that the register_models function from the
AppCache only gets passed the app_label. Which makes it impossible to load
custom app classes. The solution for this problem would be to use the full
qualified name internally in the AppCache, but let methods like get_models,
get_model etc. still work with only the app_label for backwards-compatibility.

This also involves throwing Exceptions when a developer tries to install
two apps that have the same app_label.

* Task: Add verbose_name to the App class

Each App class will have the possibility of setting a
verbose_name/verbose_name_plural attribute. This attribute will be a string
and translateable via gettext. Currently the app_label is used as a, non
translateable, title (as there is no notation of an "application" in django).
This means that for example for the django.contrib.auth package, "auth" would
be the title in the contrib.admin index. However, it would be better for this
to be "Authentication" or "Authentifizierung" in german. To demonstrate this
new attribute, the admin will need to be modified.

* Task: Add db_prefix to the App class

Beside the verbose_name attribute, there will also be a db_prefix attribute.
This attribute will allow users to specifiy a prefix value for the database
tables. Currently, the app_label is used for this. So, for example, tables
for the models in django.contrib.auth will be created under auth_.
There is no way of modifying the name. For this, the ORM needs to be modified
to use the app.db_prefix instead of the models app_label.

* Task: Move django.db.loading to django.core.app

The current model loading core lives in django.db.loading. However, since the
code will be refactored to also allow packages without models it won't
make any sense to let it live in django.db.loading.

* Task: Add Signals

Add signals to the AppCache, so that developers can modify parts of the stages
of the AppCache without monkey patching or replacing it. 

Arthur


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

[gsoc/app-loading] final status report

[Arthur Koziel]

Hey there,

the GSOC is over and I wanted to give you all a final status report.

The AppCache was refactored and now creates app instances instead of just 
loading models. An app is either an instance of django.core.apps.App or a 
custom class. This depends on the entry in the INSTALLED_APPS setting. Here's 
an example:

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.sites',
'myproject.poll.MyPollApp',
)

With this setting, three instances will be created. Two instances of the 
django.core.apps.App class and one MyPollApp instance. The MyPollApp class 
could look like this:

from django.core.apps import App
from django.utils.translation import ugettext as _

class MyPollApp(App):
def __init__(self, name):
super(MyPollApp, self).__init__(name)
self.verbose_name = _('Poll')
self.db_prefix = 'foo'

The first thing to note is the verbose_name attribute, which allows for a more 
descriptive name of the app. Currently the app name is the app_label, so "auth" 
would be used for "django.contrib.auth". However, something like 
"Authentication" would fit better from a UI perspective. The name can be passed 
to the ugettext function and translated in the projects .po file on the next 
run of makemessages. I modified the admin to use the verbose_name instead of 
the app_label.

The db_prefix attribute allows the app to specify the prefix used when the 
tables are created in the database. If the above app would have a "Poll" model, 
it would be created as "foo_poll" instead of "poll_poll".

There many more attributes than can be implemented like a fixture prefix or 
admin permission prefix. The models app label is currently used for far too 
many things.



One thing I noticed was that a lot of code in Django itself or 3rd party apps 
iterates over the installed apps and imports them. This won't work anymore as 
an app can now also be a path to a class, so the import will raise an exception.

The ideal solution would be to change the code to iterate over the app 
instances instead of the INSTALLED_APPS setting, but this might be a little bit 
too much to ask. So, there's now an "installed_apps" attribute on the AppCache 
that is a normalized version of the settings.INSTALLED_APPS variable (with 
classnames removed). This makes the migration easier as this code:

for app in settings.INSTALLED_APPS:
import_module(app)

simply needs to be changed to this:

for app in cache.installed_apps:
import_module(app)

Applications with the same app label still cannot be created. The problem is 
backwards compatibility, as the methods of the AppCache (get_model/get_app 
etc.) all take the app_label as an argument. If, for example, there would be 
two "auth" app instances (e.g. django.contrib.auth
and myproject.auth) calling get_model('auth', ...) the function must still 
return the first one. I don't see migration path from app label to full path 
without breaking bc.

Nevertheless, things have improved a little here. Previously, loading two apps 
with the same app label would assign the models of the second app to the first 
app, leaving the user with one auth app that mixed together the models from 
both apps. That won't happen anymore. Now there will be only one auth app, and 
the second will not be loaded. Hopefully this will clear up some confusion.



Overall, I'm happy with the result. Working on this project was a great 
experience for me. I plan to continue my work on this branch after gsoc. Jannis 
Leidel was a fantastic mentor, always available and really helpful.

I have the next 2 weeks filled up with exams but I'll be in Portland for 
DjangoCon in early September. I'm always open to feedback and planning on 
attending the sprints to do some further work. So until then...

Regards,
Arthur

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

streaming patches reloaded

[arthur debert]

Hi folks.
Following this thread (
http://groups.google.com/group/django-developers/browse_frm/thread/a0ae32019bb02f05/2c05c5363516ea76?q=streaming&rnum=2#2c05c5363516ea76)
, since I can't reply there ( over 30 days old, google tells me).

I have an app that uploads a 4mb file and is taking a ton of memory.
>From tickets 1484/1569 they are set as fixed, but I cannot find them on
django's source code. Are these patches active in trunk? If not,
anyones knows if they're working after the merge? Anyone using them?

Thanks a lot, 
arthur


--~--~-~--~~~---~--~~
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: streaming patches reloaded

[arthur debert]

Hi Ivan.

Just to make sure I understand:
- after patching django I 've set:
STORE_UPLOAD_ON_DISK = True

I am trying to use this on the admin. Any more steps I must take?

thanks a lot
(for the patch and help)
arthur


--~--~-~--~~~---~--~~
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: ImageField and its use in templates

[arthur debert]

Hi Wegen.

carimage = models.ImageField(upload_to = 'images/cars/%s.png' % carID,
null = True, blank = True)

this won't work. upload_to must be a string (it's not evaluated at the
time the object is saved to the database).

your best bet is to leave the path to the desired directory and name
the file on save. something like this:
carimage = models.ImageField(upload_to = 'images/cars/",null = True,
blank = True)

def save(self):
 if self.id is not None and len(self.carimage) >1:
self.carimage = %s.png' % self.id
super(ModelName, self).save()

** the if check is a workaround a bug (ticket # 639) where save passes
two times for file fields.


--~--~-~--~~~---~--~~
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: Set a reasonable default for EMAIL_TIMEOUT

[Arthur Pemberton]

> (Why is "Just give it a value in your settings" not OK? 🤔)

I'm guessing the issue here is that it's currently an unknown-unknown to
most/all newbies.

At the very least, it should probably be addressed in the documentation on
deployment.

Regards,
Arthur Pemberton

On Thu, 17 Nov 2022 at 11:16, Carlton Gibson 
wrote:

> Hi Federico.
>
> Maybe if we were starting from scratch having a default would be the right
> course — "maybe", I didn't think it through yet, or look at why the
> original decision went the way it did — but I don't think changing it is
> worth the disruption, or the difficulty of going through the deprecation
> process.
>
> (Why is "Just give it a value in your settings" not OK? 🤔)
>
> Around core.mail, there's a cluster of tickets that I'm hoping to pull
> into a project idea for this year's GSoC — see...
>
> - [Add Settings EMAIL_FQDN by Jrief · Pull Request #13728 · Django/Django](
> https://github.com/django/django/pull/13728)
>
> - [Ui/Django-post_office: A Django App That Allows You to Send Email
> Asynchronously in Django. Supports HTML Email, Database Backed Templates
> and Logging.](https://github.com/ui/django-post_office)
>
> - [Proposal on How Add Configuration Options to Email Backends](
> https://groups.google.com/g/django-developers/c/R8ebGynQjK0)
>
>
> ... and linked threads.
>
>
> ... and linked threads.
>
> One result of that (if all comes to pass) should hopefully be better
> customizability of your email backends, so you'd be free to set a default
> in your own backend, without the BC concerns for others.
>
> So that's not a, yes, let's change it, but hopefully it doesn't leave you
> without optimism 🙂
>
> Kind Regards,
>
> Carlton
>
> On Thu, 17 Nov 2022 at 16:33, Federico Capoano 
> wrote:
>
>> Hi all,
>>
>> Why is there no default for EMAIL_TIMEOUT?
>>
>> Applications built in Django can potentially stall indefinitely if email
>> sending starts to hang (eg: if the SMTP server is overloaded), when this
>> happens, since there's no timeout, there's also no error being logged, so
>> it's very hard and time consuming to debug.
>>
>> Wouldn't it be better to set a timeout? Some high value like 2 minutes
>> which wouldn't really make sense to wait any longer, so at least if and
>> when this happens, developers will find error traces in the logs and
>> quickly understand where the problem is coming from, instead of spending
>> hours to debug it like I did in the past week.
>>
>> Alternatively, we could set a default timeout only if
>> "socket.getdefaulttimeout()" returns None, just to avoid applications
>> stalling indefinitely, which is something that has been happening to me
>> lately.
>>
>> Best regards
>> Federico Capoano
>>
>> --
>> 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/CAERYH6Vs6%2BWnJMsw95Uc_b006PZ2N_Pr%3DNgx4ztPDkgjVbkivA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAERYH6Vs6%2BWnJMsw95Uc_b006PZ2N_Pr%3DNgx4ztPDkgjVbkivA%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/CAJwKpyRt%3D3AfDF3ygyn2XY9X7OtqzbWJ8U0VwH0KhwW-KJwzQg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAJwKpyRt%3D3AfDF3ygyn2XY9X7OtqzbWJ8U0VwH0KhwW-KJwzQg%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/CA%2BX4dQSeKd7hFvv6fKE3auX6RgdFwsDtUfVBvbg2sJPO-PHJiA%40mail.gmail.com.

Re: Model icons

[Arthur Pemberton]

I too find the idea of hard coded HTML in a Python file to be inelegant,
for what it's worth.

Arthur Pemberton

On Sat, 18 Feb 2023 at 08:12, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Putting HTML for the admin in model definitions is a bit too coupled.
>
> I think you may be able to add icons already by overriding the admin
> template - can you try playing around with that?
>
> On Mon, Feb 6, 2023 at 12:07 AM Yeonggwang Yang 
> wrote:
>
>> that sounds good with me
>>
>> 2023년 2월 5일 일요일 오전 9시 36분 17초 UTC+9에 Marty님이 작성:
>>
>>> Hi all,
>>>
>>> Recently, it's trend to use icons or emoji before menu items and I like
>>> this idea because  IMHO people orient better and more quickly when they see
>>> picture.
>>>
>>> What about to add this feature to native django? I thought the easiest
>>> way would be to add new Meta option to Model. The default Meta icon would
>>> be empty string so everything would work like now. If I want to make menu
>>> more readable, I just add emoji (🔨) or html (Awesome font - *>> class="fa-solid fa-hammer">* , Bootstrap icon - **, etc.) to Meta icon.
>>>
>>> Code example:
>>>
>>> *Model:*
>>> class Hammer(models.Model):
>>> ...
>>>
>>> Meta:
>>> icon = ''
>>>
>>> *app_list.html template:*
>>> ...
>>> {{model.icon}} {{model.name}}
>>> ...
>>>
>>> Final result:
>>> [image: admin navbar.png]
>>>
>>> Maybe own icon could have even the parent app (AppConfig). And the model
>>> icon could be in breadcrumbs.
>>>
>>> What do you think about this idea? 🙂
>>>
>>> --
>> 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/6c859cc5-ea41-4695-9fcf-5cd435310364n%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/6c859cc5-ea41-4695-9fcf-5cd435310364n%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/CAMyDDM1L4rmQ3qomxOqD%2BmugXcsmx7NrOPAh8a53wR9G5q%3D3Gw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1L4rmQ3qomxOqD%2BmugXcsmx7NrOPAh8a53wR9G5q%3D3Gw%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/CA%2BX4dQTq4c_xLio%2BBALsr3opVKHxtWtrQP1xcbktU446BW-wMg%40mail.gmail.com.

Re: Add a minimal Gitignore

[Arthur Pemberton]

I like the idea as I've seen novices commit all their .pyc files, but maybe
this should only triggered by a flag to startproject, --git perhaps.

Arthur Pemberton

On Thu, Mar 9, 2023, 14:13 Daniel Azubuine 
wrote:

> Yeah
>
> What I meant is for the default ‘startproject’ template to include a
> minimal .gitignore file.
>
> I've added the template.
> Just wanted to ask before I push
>
> On Thu, Mar 9, 2023, 20:00 James Bennett  wrote:
>
>> On Thu, Mar 9, 2023 at 10:27 AM 'Adam Johnson' via Django developers
>> (Contributions to Django itself) 
>> wrote:
>>
>>> The Django project has a .gitignore file:
>>> https://github.com/django/django/blob/main/.gitignore
>>>
>> I think this person was asking for the default ‘startproject’ template to
>> include a minimal .gitignore file.
>>
>> --
>> 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/CAL13Cg9ySuiTEcyUQQiPKzP_Q6qCu2JBV6jZeE-0QdEFoimYAg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAL13Cg9ySuiTEcyUQQiPKzP_Q6qCu2JBV6jZeE-0QdEFoimYAg%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/CAHRz_NZ-6rNNN53f6VGVJ4vv827G165yksFK%2BkMXz_vztz5Q8A%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAHRz_NZ-6rNNN53f6VGVJ4vv827G165yksFK%2BkMXz_vztz5Q8A%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/CA%2BX4dQQHWGsGhXs1pM85cBRBJ6cQ%2Bvsi6DA4cNhMXVzNbZtizg%40mail.gmail.com.

Re: Add a minimal Gitignore

[Arthur Pemberton]

What exactly would be considered the burden in maintaining a .gitignore?

Arthur

On Fri, Mar 10, 2023 at 11:37 AM Tega Ukavwe  wrote:

> I strongly agree with Adam and Tom, the extra and unnecessary burden of
> maintaining the .gitignore file outweighs its advantages.
>
> Cheers,
> Tega.
>
> On Fri, Mar 10, 2023 at 5:12 PM 'Adam Johnson' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> I'm also against the idea, unless done in a very minimal fashion.
>>
>> Many tools in the ecosystem put "ignore everything here" .gitignore files
>> into their not-normally-committed directories: at least Coverage.py, Mypy,
>> pytest, and virtualenv. So the trend is that less and less .gitignore
>> patterns are needed for a Python project. I am not sure there are general
>> Django patterns we could add except *.pyc , and maybe Python will start
>> dropped .gitignore files in __pycache__ dirs at some point.
>>
>> I don't think we could even add a pattern for ignoring .mo files from
>> translations, since according to a poll I did last year, about 50% of devs
>> commit them: https://twitter.com/AdamChainz/status/1557058307592015878 .
>>
>>  we could easily just use github's Python default, declare that the
>>> policay, and call it day
>>>
>>
>> GitHub’s Python default file is seriously bloated:
>> https://github.com/github/gitignore/blob/main/Python.gitignore . Their
>> maintenance policy seems to be “accept any suggestion, append-only”. We
>> generally set a higher bar for Django.
>>
>> The GitHub file includes patterns to ignore files generated by tools that
>> have fallen out of favour (e.g. nosetests.xml for nose test runner). And it
>> also includes low-specificity patterns that could confuse new Git users,
>> such as target/ ignoring *all* directories named "target". Also the "Django
>> stuff" patterns in there are related to non-universal ways of using Django.
>>
>> I wouldn't want to burden all Django projects with so many irrelevant
>> patterns. It takes work to understand and remove them.
>>
>> Enough people are using GitHub that they create the repo first with one
>>> of GH's provided gitignores, or copy it in after.
>>>
>>
>> Agree here that people can set up or use Git templates if they wish. Git
>> itself has a repository template mechanism.
>>
>> On Fri, Mar 10, 2023 at 4:07 PM Tom Carrick  wrote:
>>
>>> I don't really like the idea of this for a number of reasons.
>>>
>>> A lot of people create the project in a subdirectory. For them, the
>>> gitignore is in the wrong place.
>>>
>>> Enough people are using GitHub that they create the repo first with one
>>> of GH's provided gitignores, or copy it in after.
>>>
>>> As Python changes, as new tools come out, the gitignore needs to be
>>> constantly updated. There will be a lot of bikeshedding about what should
>>> and shouldn't go in. For example, the .vscode directory sometimes has
>>> project specific code that should be included. Sometimes it should be
>>> excluded because devs are expected to set their own up or use whatever
>>> editor they prefer. Many users (such as myself) have .vscode in a global
>>> gitignore expressly so it doesn't need to be added to every project.
>>>
>>> A lot of people are using a frontend framework, that won't be covered by
>>> our gitignore, and this framework might itself want to set up a gitignore.
>>>
>>> The biggest problem for me is that it would just be a maintenance burden.
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>> On Fri, 10 Mar 2023 at 16:01, Bogdan Barna  wrote:
>>>
>>>> Just want to say that I agree with Cory. Being a non-core
>>>> feature/issue, I don't see a reason of why not to re-evaluate the "denied"
>>>> decisions.
>>>>
>>>> On Friday, March 10, 2023 at 9:11:03 AM UTC+2 Cory Zue wrote:
>>>>
>>>>> Is there a more nuanced discussion of this issue anywhere? The reasons
>>>>> stated in the linked PR that it's "not for the project template to provide
>>>>> configuration for source code management tools" feels more like an opinion
>>>>> than a fact.
>>>>>
>>>>>  I know one of the goals that emerged from recent discussions was how
>>>>> to get more wide adoption of the Django project. This strikes

Production Django use and "real ip"

[Arthur Pemberton]

I have read previous discussions (most recent I could find was Dec 2013 
 [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the 
"real" IP address of an HttpRequest. From what I can see, currently there 
is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.

However, I do notice that Django acknowledges `X_FORWARDED_HOST`, 
`X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`  
(though SECURE_PROXY_SSL_HEADER).

If there is still opposition to having some built-in handling for 
`HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at 
least mention the need for the developer to handle this explicitly.

Regards,
Arthur P.



[1] https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
[2] https://docs.djangoproject.com/en/4.1/howto/deployment/

-- 
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/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com.

Re: Production Django use and "real ip"

[Arthur Pemberton]

At this point, I'm not even suggesting that Django handle this internally.
I'm suggesting that the behaviour/expectation be documented, at least in
the deployment guide.

Are there any deployment scenarios where META.REMOTE_ADDR is ever even
correct?

Arthur Pemberton

On Wed, Apr 19, 2023 at 3:37 AM 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> As someone whose worked on various projects in different languages over
> the last 15 years that heavily involved deciphering IP sent in headers to
> try to determine the "real" IP address of a connection, I would urge
> caution with anything around determining a "real IP". There is no standard
> in terms of where to look and what to trust. The X-FORWARDED-FOR is not
> always right, can easily be spoofed, it can include multiple IPs of which
> the order is not consistent. Sometimes the left most element is the first
> and "true IP", sometimes it's the right, sometimes its a value in the
> middle. It all depends what's included, what appended to the request, what
> the values are and what you want to trust/ignore. I've seen requests that
> include internal network IPs, then router/gateway IPs, proxy IPs and load
> balancers all within that head all in different orders.   It's especially
> messy when dealing with requests on mobile network where the carrier uses
> proxies, sometimes 3rd parties, and where your website is hosted behind
> both load balancers and webserver as each may manipulate the header in
> different ways.
>
> One of the best packages within the Django eco-system for trying to
> identify a users actual external IP that I've come across is django-ipware
> <https://github.com/un33k/django-ipware>. It allows you to choose the
> precedence order that matches your use case, yo have private IP prefixes,
> to configure how many proxies you wish to ignore etc. They also have a
> handy notice/disclaimer
> <https://github.com/un33k/django-ipware/blob/master/README.md#Notice> on
> the subject.
>
> IMO Django core should leave this 3rd party packages and individual
> deployments to decide and determine what they deem as being the source of
> the "real IP" for their individual project.
>
>
>
> On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote:
>
>> It's surprisingly complex to interpret x-forwarded-for:
>> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ .
>> We will never be able to safely add automated handling.
>>
>> I *guess* we could add a note to the deployment guide like "check your
>> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards
>> making the guide too long, and filled with irrelevant details. Most sites
>> don't care about recording the user's IP. On those that do, it should be
>> easy enough to discover the setting.
>>
>> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton  wrote:
>>
>>> I have read previous discussions (most recent I could find was Dec 2013
>>>  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the
>>> "real" IP address of an HttpRequest. From what I can see, currently there
>>> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.
>>>
>>> However, I do notice that Django acknowledges `X_FORWARDED_HOST`,
>>> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`
>>> (though SECURE_PROXY_SSL_HEADER).
>>>
>>> If there is still opposition to having some built-in handling for
>>> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at
>>> least mention the need for the developer to handle this explicitly.
>>>
>>> Regards,
>>> Arthur P.
>>>
>>> 
>>>
>>> [1]
>>> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
>>> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com?utm_medium=email&a

RE: Can we move the activity on this list to the Forum now?

[Arthur Rio]

Yes please!


On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com (
jure.erznoz...@gmail.com) wrote:

+1



*From:* django-developers@googlegroups.com <
django-developers@googlegroups.com> *On Behalf Of *natali...@gmail.com
*Sent:* sreda, 03. maj 2023 20:10
*To:* Django developers (Contributions to Django itself) <
django-developers@googlegroups.com>
*Subject:* Re: Can we move the activity on this list to the Forum now?



Hello everyone!



I was wondering if we could make a decision about this topic. On the one
hand, and as far as I understand, the forum is the preferred channel of
communication. On the other hand, having multiple channels of communication
can spread important discussions too thin, making it difficult to have
productive conversations in one place.



As a newcomer to the contributing community, I can attest that the current
situation causes some confusion. IMHO, the same applies to the chat
options: there is IRC and the Discord server (though perhaps I should start
a new forum topic about that in order to keep decisions separated).



In summary, I'm +1 to "move on-mass (all few of us :) over there"!



Thank you!

Natalia.

On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:

I just submitted a proposal to create a Discourse plugin to improve the
accuracy of their inbound email parsing. This would enable two things:

   - Folks who prefer to live in their inbox could continue to do so and
   contribute by just replying to emails. Discourse currently has
   reply-by-email, but it often mangles formatting and/or entirely deletes
   text. Once these issues are fixed, folks who like the current experience
   would be able to just pretend the forum doesn't exist and continue having
   the same experience as they currently have with Google Groups.
   - Right now importing the archives from Google Groups into Discourse
   isn't realistic for the same reasons; some messages will import correctly,
   but others will be mangled or missing text. This would also be made
   possible.

If this is something you care about (positively or negatively), here is the
exploratory proposal:



https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944



Any feedback and/or testing would be much appreciated! Right now Discourse
recognizes that this is a problem and is interested in solving it, but
getting it prioritized will require folks to A) speak up saying they want
it done B) test the underlying API to verify that it actually solves the
problem.



Alex



On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson  wrote:

OK, I've updated the Trac wiki page to point to the forum too. (We use this
as a wiki-link in responses to guide folk onwards.)



The docs have a `|django-developers|` shortcut used in quite a few places
so that needs a moment more to review and adjust.

(I'll look at it soon-ish... — if no-one beats me to it :)



Thanks.

C



On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:

We should at least update those Trac and Triage Workflow docs to point to
both, maybe with the Forum first?



Andrew



On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:

I'm trying to begin new conversations there where I can.



The main issue is that we're still pointing people here from Trac and the
Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can
adjust practice there.



I expect there will always be the "How do I start?" posts. The Forum at
least has a pinned post for that. ...



On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers
(Contributions to Django itself)  wrote:

Hi all,



I find that the signal-to-noise ratio on this mailing list is (by my
determination) quite bad around this time of year.



Is a move to the forum still on the cards?



Kye

On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin , wrote:



I did some investigation of moving django-users and django-developers to
the Forum right after DjangoCon; I wanted to see if we could import all the
old posts too, which we probably could, but I'm not entirely sure of the
utility of that.



I will say that the forum is a lot easier to moderate - the ability to
moderate after a post has gone out, rather than gating all posts behind
approval if they're untrusted, is a big step in itself, not to mention the
ability to remove sensitive or offensive content once it's posted.



Andrew



On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:

IMO django-announce and django-updates serve a very different purpose and I
would be against moving them if it were suggested.



I am incredibly strongly in favour of moving django-developers and
django-users to the forums. IMO being able to more easily trap people
misusing this list as a tech support channel is itself reason enough to
move. Beyond that, I’d argue that the plentiful UX issues with Google
Groups, and mailing lists in general, certainly don’t do the community any
favours in terms of getting more p

Deploying Django under a sub-path

[Arthur Pemberton]

The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use it.

Reading through the code, I see very little use of `SCRIPT_NAME` itself,
however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how
one deploys Django at a sub-path.

I had to modify wsgi.py per
https://ruddra.com/deploy-django-subpath-openshift/ to get things to work.

Shouldn't this be a complete feature?

I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ and
there's no information on the topic (that I could find).

Arthur Pemberton

-- 
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/CA%2BX4dQRiRkPKQVik9aRQ1z07-j_jOVK9fHQAtt2r_v%3Dajrd0uQ%40mail.gmail.com.

Re: Deploying Django under a sub-path

[Arthur Pemberton]

Even with  `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, but
not `STATIC_URL` .

Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ?

Arthur Pemberton

On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton  wrote:

> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use
> it.
>
> Reading through the code, I see very little use of `SCRIPT_NAME` itself,
> however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how
> one deploys Django at a sub-path.
>
> I had to modify wsgi.py per
> https://ruddra.com/deploy-django-subpath-openshift/ to get things to work.
>
> Shouldn't this be a complete feature?
>
> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/
> and there's no information on the topic (that I could find).
>
> Arthur Pemberton
>

-- 
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/CA%2BX4dQRYbJ4NnKD89ptsJHGx2EUxO4vqZH0oepHVAN%2Bf%3D7S_Ag%40mail.gmail.com.

Re: Deploying Django under a sub-path

[Arthur Pemberton]

I found https://code.djangoproject.com/ticket/7930 seems like
`FORCE_SCRIPT_NAME` just isn't meant to work.

Maybe the docs should reflect that.

Arthur Pemberton

On Fri, Jun 16, 2023 at 5:18 PM Arthur Pemberton  wrote:

> Even with  `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, but
> not `STATIC_URL` .
>
> Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ?
>
> Arthur Pemberton
>
> On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton 
> wrote:
>
>> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use
>> it.
>>
>> Reading through the code, I see very little use of `SCRIPT_NAME` itself,
>> however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how
>> one deploys Django at a sub-path.
>>
>> I had to modify wsgi.py per
>> https://ruddra.com/deploy-django-subpath-openshift/ to get things to
>> work.
>>
>> Shouldn't this be a complete feature?
>>
>> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/
>> and there's no information on the topic (that I could find).
>>
>> Arthur Pemberton
>>
>

-- 
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/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com.

Re: Deploying Django under a sub-path

[Arthur Pemberton]

I actually meant this as a developer question: as, at least in my review of
the code, and testing with `manage.py runserver`. use of `SCRIPT_NAME` has
no observable effect.

If that can be confirmed, then yes, the documentation should be updated,
and I can do a PR accordingly. Use of `SCRIPT_NAME` itself is not
documented anywhere; seems like it should at least be mentioned in the
Deployment section.

Arthur Pemberton

On Fri, Jun 23, 2023 at 3:07 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Hi Arthur,
>
> You've found the wrong mailing list for this thread. This mailing list is
> for discussing the development of Django itself, not for support using
> Django. I guess that's why no one replied.
>
> If you would like to suggest a documentation change please do open a PR
> with reference to the information you found.
>
> Thanks,
>
> Adam
>
> On Fri, Jun 16, 2023 at 10:23 PM Arthur Pemberton 
> wrote:
>
>> I found https://code.djangoproject.com/ticket/7930 seems like
>> `FORCE_SCRIPT_NAME` just isn't meant to work.
>>
>> Maybe the docs should reflect that.
>>
>> Arthur Pemberton
>>
>> On Fri, Jun 16, 2023 at 5:18 PM Arthur Pemberton 
>> wrote:
>>
>>> Even with  `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly,
>>> but not `STATIC_URL` .
>>>
>>> Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ?
>>>
>>> Arthur Pemberton
>>>
>>> On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton 
>>> wrote:
>>>
>>>> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to
>>>> use it.
>>>>
>>>> Reading through the code, I see very little use of `SCRIPT_NAME`
>>>> itself, however as far as I can tell, use of `SCRIPT_NAME` is supposed to
>>>> be how one deploys Django at a sub-path.
>>>>
>>>> I had to modify wsgi.py per
>>>> https://ruddra.com/deploy-django-subpath-openshift/ to get things to
>>>> work.
>>>>
>>>> Shouldn't this be a complete feature?
>>>>
>>>> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/
>>>> and there's no information on the topic (that I could find).
>>>>
>>>> Arthur Pemberton
>>>>
>>> --
>> 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/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%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/CAMyDDM016eww3f5GBB1sPHJncf%2BWUHk7nLdQsf9ezUhJY0d9XQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM016eww3f5GBB1sPHJncf%2BWUHk7nLdQsf9ezUhJY0d9XQ%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/CA%2BX4dQQDEdkmuvFHrpcBKkQEeQ1aF6SNvuZ7Om1hAacEPx_jLg%40mail.gmail.com.

Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

The documentation (
https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
that " the default input formats are taken from the active locale format
TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
<https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
if localization is disabled". However, neither my reading of the code, or
my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
even with "USE_I18N = False"

TimeField gets the formats from `input_formats =
formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
`formats.get_format` -- the documentation of which says "If use_l10n is
provided and is not None, it forces the value to be localized (or not),
otherwise it's always localized."

so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
ignored.

How does one use settings.TIME_INPUT_FORMATS ?

Arthur Pemberton

-- 
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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com.

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

Thanks, I'll look into that. But does that mean that
settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
flows that lead to it being used.

On Tue, Mar 5, 2024 at 3:00 AM David Sanders 
wrote:

> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
>> The documentation (
>> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
>> that " the default input formats are taken from the active locale format
>> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
>> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
>> if localization is disabled". However, neither my reading of the code, or
>> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
>> even with "USE_I18N = False"
>>
>> TimeField gets the formats from `input_formats =
>> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
>> `formats.get_format` -- the documentation of which says "If use_l10n is
>> provided and is not None, it forces the value to be localized (or not),
>> otherwise it's always localized."
>>
>> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
>> ignored.
>>
>> How does one use settings.TIME_INPUT_FORMATS ?
>>
>> Arthur Pemberton
>>
>> --
>> 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%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/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%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/CA%2BX4dQTQwnqe%3DpJf3bmiZH5LHJ87df%2B8-Rq5LbpLcctp9jNfjA%40mail.gmail.com.

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

I haven't yet checked the tests thoroughly enough to determine why things
didn't work for me in practice. I do know they didn't work. And I do see
that the tests pass. But I suspect that the tests may not be fully
mimicking the read-world use case in this scenario.

I'll return here once I have some evidence either way,

Arthur Pemberton

On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson  wrote:

> USE_I18N does not disable localization, but internationalization. USE_L10N
> was the setting to enable/disable localization, but it was deprecated in
> Django 4.0:
> https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was
> removed completely in Django 5.0, in this commit:
> https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
> .
>
> So I think the phrase “if localization is disabled” is at least a little
> bit wrong. But I don’t think the setting is ignored, as there are tests
> confirming that it works:
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
> . The line that reads the setting should be this one:
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
> .
>
> If you can provide a failing minimal project, that would be useful to keep
> debugging. I have some minimal django project templates at
> https://github.com/adamchainz/django-startproject-templates .
>
> On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
>
> Thanks, I'll look into that. But does that mean that
> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
> flows that lead to it being used.
>
> On Tue, Mar 5, 2024 at 3:00 AM David Sanders 
> wrote:
>
> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
> The documentation (
> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
> that " the default input formats are taken from the active locale format
> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
> if localization is disabled". However, neither my reading of the code, or
> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
> even with "USE_I18N = False"
>
> TimeField gets the formats from `input_formats =
> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
> `formats.get_format` -- the documentation of which says "If use_l10n is
> provided and is not None, it forces the value to be localized (or not),
> otherwise it's always localized."
>
> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
> ignored.
>
> How does one use settings.TIME_INPUT_FORMATS ?
>
> Arthur Pemberton
>
>
> --
> 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%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/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%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/CA%2BX4dQTQwnqe%3DpJf3bmiZH5LHJ8

Re: Proposal to upgrade django.core.mail to Python's modern email API

[Arthur Pemberton]

Would this be designed to be compatible with "Proposal 14: Background
Workers"?



On Sun, Jun 23, 2024 at 10:46 PM Mike Edmunds  wrote:

> I want to propose updating django.core.mail to replace use of Python's
> legacy email.message.Message (and other legacy email APIs) with
> email.message.EmailMessage (and other modern APIs).
>
> If there's interest, I can put together a more detailed proposal and/or
> ticket, but was hoping to get some initial feedback first. (I searched for
> relevant discussions in django-developers and the issue tracker, and didn't
> find any. Apologies if this has come up before.)
>
> [Note: I maintain django-anymail
> , which implements Django
> integration with several transactional email service providers.]
>
>
> *Background*
>
> Since Python ~3.6, Python's email package has included two largely
> separate implementations:
>
>- a "modern (unicode friendly) API" based on
>email.message.EmailMessage and email.policy.default
>- a "legacy API" providing compatibility with older Python versions,
>based on email.message.Message and email.policy.compat32
>
> (See https://docs.python.org/3/library/email.html, especially toward the
> end.)
>
> django.core.mail currently uses the legacy API.
>
>
> *Why switch?*
>
> There are no plans to deprecate Python's legacy email API, and it's
> working, so why change Django?
>
>-
>
>*Fewer bugs:* The modern API fixes a *lot* of bugs in the legacy API.
>My understanding is legacy bugs will generally not be fixed. (And in fact,
>there are some cases where the legacy API deliberately replicates earlier
>buggy behavior.)
>
>Django #35497  is an
>example of a legacy bug (with a problematic proposed workaround) which is
>just fixed in the modern API.
>-
>
>*Simpler, safer code:* A substantial portion
>
> 
>  of
>django.core.mail's internals implements workarounds and security fixes for
>problems in the legacy API. This would be greatly simplified—maybe
>eliminated completely—using the modern API.
>
>Examples: the modern API prevents CR/NL injections in message headers.
>It serializes and folds address headers properly—even ones with unicode
>names. It enforces single-instance headers where appropriate.
>-
>
>*Easier to work with:* The modern API adds some nice conveniences for
>developers working in django.core.mail, third-party library developers, and
>(depending on what we choose to expose) users of Django's mail APIs.
>
>Examples: populating the "Date" header with a datetime or an address
>header with Address
>
> 
>  objects—without
>needing intricate knowledge of email header formats. Using email.policy to
>generate a 7-bit clean serialization (without having to muck about
>with the MIME parts
>
> 
>).
>
>
> *Concerns & risks*
>
> Compatibility and security, of course…
>
>-
>
>*Backwards compatibility (for API users):* django.core.mail largely
>insulates callers from the underlying Python email package. There are a few
>places where this leaks (e.g., attachments
>
> 
>  allows
>legacy email MIMEBase
> objects), but in
>general the switch should be transparent. (And I have some ideas for
>supporting the other cases.)
>-
>
>*Backwards compatibility (for third-party libraries):* Some libraries
>may use internals I'd propose removing (e.g., SafeMIME and friends);
>we'd handle this through deprecation.
>-
>
>*Backwards compatibility (bug-level):* There's probably some code out
>there that unintentionally depends on legacy email bugs (or the specific
>ways Django works around them). I don't have any examples, but I also don't
>have a good solution for when they surface. Plus, while Python's modern
>email API is pretty mature at this point, there are still new bugs being
>reported against it. Email is complicated.
>-
>
>*Security:* As noted above, the modern API should be more secure than
>the legacy one. But we also have a nice collection of email security
>tests—which *mostly* don't depend on internal implementation. We'd
>keep these.
>
> --
> 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+

Re: Proposal to upgrade django.core.mail to Python's modern email API

[Arthur Pemberton]

>  The background workers proposal will implement a new background SMTP
EmailBackend (in django.core.mail.backends).

I had missed that fact. Thanks for the explanation.

I for one think that this is a good proposal -- this would modern
transactional email sending.

- Arthur


On Mon, Jun 24, 2024 at 3:14 PM Mike Edmunds  wrote:

> > Would this be designed to be compatible with "Proposal 14: Background
> Workers"?
>
> I wouldn't expect this to impact background workers one way or the other.
> The same goes for the async email proposal(s) floating around.
>
> Virtually all of this work would occur in django.core.mail.message, where
> Python's `email` APIs are used. A goal is to avoid changes that would break
> existing email backends (Django or third-party).
>
> The background workers proposal will implement a new background SMTP
> EmailBackend (in django.core.mail.backends). The existing SMTP EmailBackend
> doesn't directly use Python's `email` APIs, and there should be no reason
> for background SMTP to be any different. (It might be helpful to know that
> Python's `email` library isn't involved in *sending* email; that's
> handled by Python's `smtplib`, which Django uses only in the SMTP
> EmailBackend.)
>
> The existing SMTP EmailBackend *does* use one function I expect will
> become deprecated: django.core.mail.message.sanitize_address(). I haven't
> yet investigated whether that use is still necessary, or whether it's there
> to get around past bugs/limitations in Python's smtplib. If any of it is
> still needed for SMTP, I'd probably want to move that code into the SMTP
> EmailBackend(s).
>
> - Mike
> On Sunday, June 23, 2024 at 10:22:03 PM UTC-7 Arthur Pemberton wrote:
>
>> Would this be designed to be compatible with "Proposal 14: Background
>> Workers"?
>>
>>
>>
>> On Sun, Jun 23, 2024 at 10:46 PM Mike Edmunds  wrote:
>>
>>> I want to propose updating django.core.mail to replace use of Python's
>>> legacy email.message.Message (and other legacy email APIs) with
>>> email.message.EmailMessage (and other modern APIs).
>>>
>>> If there's interest, I can put together a more detailed proposal and/or
>>> ticket, but was hoping to get some initial feedback first. (I searched for
>>> relevant discussions in django-developers and the issue tracker, and didn't
>>> find any. Apologies if this has come up before.)
>>>
>>> [Note: I maintain django-anymail
>>> <https://github.com/anymail/django-anymail>, which implements Django
>>> integration with several transactional email service providers.]
>>>
>>>
>>> *Background*
>>>
>>> Since Python ~3.6, Python's email package has included two largely
>>> separate implementations:
>>>
>>>- a "modern (unicode friendly) API" based on
>>>email.message.EmailMessage and email.policy.default
>>>- a "legacy API" providing compatibility with older Python versions,
>>>based on email.message.Message and email.policy.compat32
>>>
>>> (See https://docs.python.org/3/library/email.html, especially toward
>>> the end.)
>>>
>>> django.core.mail currently uses the legacy API.
>>>
>>>
>>> *Why switch?*
>>>
>>> There are no plans to deprecate Python's legacy email API, and it's
>>> working, so why change Django?
>>>
>>>-
>>>
>>>*Fewer bugs:* The modern API fixes a *lot* of bugs in the legacy
>>>API. My understanding is legacy bugs will generally not be fixed. (And in
>>>fact, there are some cases where the legacy API deliberately replicates
>>>earlier buggy behavior.)
>>>
>>>Django #35497 <https://code.djangoproject.com/ticket/35497> is an
>>>example of a legacy bug (with a problematic proposed workaround) which is
>>>just fixed in the modern API.
>>>-
>>>
>>>*Simpler, safer code:* A substantial portion
>>>
>>> <https://github.com/django/django/blob/stable/5.1.x/django/core/mail/message.py#L32-L190>
>>>  of
>>>django.core.mail's internals implements workarounds and security fixes 
>>> for
>>>problems in the legacy API. This would be greatly simplified—maybe
>>>eliminated completely—using the modern API.
>>>
>>>Examples: the modern API prevents CR/NL injections in message
>>>headers. It serializes and folds address h

Formwizard and manytomany

[Arthur Fortes]

Hello, I'm new in Django and I got a problem with a formwizard. My
manytomany dont works with formwizard. When I try appears this error :
'areaes' is an invalid keyword argument for this function. What I
should do?

So my formwizard is:

class CadastroWizard(FormWizard):

def get_template(self, step):
return ['forms/wizard_%s.html' % step]

def done(self, request, form_list):
data = {}
for form in form_list:
data.update(form.cleaned_data)
user = User(
username=data['email'],
first_name=data['nome'],
email=data['email']
)
user.set_password(data['senha'])
user.save()

tipo = usuario.objects.create(**data)

return render_to_response('cadastro-concluido.html', {'data':
data}, context_instance=RequestContext(request))


Thanks for attention.

-- 
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: Formwizard and manytomany

[Arthur Fortes]

models.py

areaes = models.ManyToManyField(areavaga,verbose_name='Area da
vaga*')
pret_salario = models.CharField('Pretenção
salarial*',max_length=2,choices=SALARIO_C)
cargointeresse = models.CharField('Cargo de interesse*',max_length
=20)
tipoperfil = models.CharField('Tipo de
perfil*',max_length=2,choices=TIPOPERFIL_C)

forms.py

class usuarioForm(forms.ModelForm):
class Meta:
model = usuario
areaes =
forms.ModelMultipleChoiceField(queryset=areavaga.objects.all())
pret_salario =
forms.ChoiceField(widget=forms.Select(attrs={'class':'validate[required]
select-medium'}), choices=SALARIO_C)
cargointeresse = forms.CharField(max_length =50,
widget=forms.TextInput(attrs={'class':'input-medium
validate[required]'}))
tipoperfil =
forms.ChoiceField(widget=RadioSelect(renderer=HorizRadioRenderer,
attrs={'class':'validate[required]'}), choices=TIPOPERFIL_C)


formwizard

class CadastroWizard(FormWizard):

def get_template(self, step):
return ['forms/wizard_%s.html' % step]

def done(self, request, form_list):
data = {}
for form in form_list:
data.update(form.cleaned_data)
user = User(
username=data['email'],
first_name=data['nome'],
email=data['email']
)
user.set_password(data['senha'])
user.save()

tipo = usuario.objects.create(**data) <<<--- In here!

return render_to_response('cadastro-concluido.html', {'data':
data}, context_instance=RequestContext(request))


-- 
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: [gsoc/app-loading] final status report

[Arthur Koziel]

Hey Yuri,

I'm sorry but I don't understand your question. Could you please explain it a 
little more?

Thanks,
Arthur

On Aug 23, 2010, at 5:47 AM, burc...@gmail.com wrote:

> Hi Arthur,
> 
> thanks for your work!
> 
> Is any syntax of setting keywords for app instances in INSTALLED_APPS
> or somewhere in settings supported now?
> 
> On Mon, Aug 23, 2010 at 2:06 AM, Arthur Koziel  
> wrote:
>> Hey there,
>> 
>> the GSOC is over and I wanted to give you all a final status report.
>> 
>> The AppCache was refactored and now creates app instances instead of just 
>> loading models. An app is either an instance of django.core.apps.App or a 
>> custom class. This depends on the entry in the INSTALLED_APPS setting. 
>> Here's an example:
>> 
>> INSTALLED_APPS = (
>>'django.contrib.auth',
>>'django.contrib.sites',
>>'myproject.poll.MyPollApp',
>> )
>> 
>> With this setting, three instances will be created. Two instances of the 
>> django.core.apps.App class and one MyPollApp instance. The MyPollApp class 
>> could look like this:
>> 
>>from django.core.apps import App
>>from django.utils.translation import ugettext as _
>> 
>>class MyPollApp(App):
>>def __init__(self, name):
>>super(MyPollApp, self).__init__(name)
>>self.verbose_name = _('Poll')
>>self.db_prefix = 'foo'
>> 
>> The first thing to note is the verbose_name attribute, which allows for a 
>> more descriptive name of the app. Currently the app name is the app_label, 
>> so "auth" would be used for "django.contrib.auth". However, something like 
>> "Authentication" would fit better from a UI perspective. The name can be 
>> passed to the ugettext function and translated in the projects .po file on 
>> the next run of makemessages. I modified the admin to use the verbose_name 
>> instead of the app_label.
>> 
>> The db_prefix attribute allows the app to specify the prefix used when the 
>> tables are created in the database. If the above app would have a "Poll" 
>> model, it would be created as "foo_poll" instead of "poll_poll".
>> 
>> There many more attributes than can be implemented like a fixture prefix or 
>> admin permission prefix. The models app label is currently used for far too 
>> many things.
>> 
>> 
>> 
>> One thing I noticed was that a lot of code in Django itself or 3rd party 
>> apps iterates over the installed apps and imports them. This won't work 
>> anymore as an app can now also be a path to a class, so the import will 
>> raise an exception.
>> 
>> The ideal solution would be to change the code to iterate over the app 
>> instances instead of the INSTALLED_APPS setting, but this might be a little 
>> bit too much to ask. So, there's now an "installed_apps" attribute on the 
>> AppCache that is a normalized version of the settings.INSTALLED_APPS 
>> variable (with classnames removed). This makes the migration easier as this 
>> code:
>> 
>>for app in settings.INSTALLED_APPS:
>>import_module(app)
>> 
>> simply needs to be changed to this:
>> 
>>for app in cache.installed_apps:
>>import_module(app)
>> 
>> Applications with the same app label still cannot be created. The problem is 
>> backwards compatibility, as the methods of the AppCache (get_model/get_app 
>> etc.) all take the app_label as an argument. If, for example, there would be 
>> two "auth" app instances (e.g. django.contrib.auth
>> and myproject.auth) calling get_model('auth', ...) the function must still 
>> return the first one. I don't see migration path from app label to full path 
>> without breaking bc.
>> 
>> Nevertheless, things have improved a little here. Previously, loading two 
>> apps with the same app label would assign the models of the second app to 
>> the first app, leaving the user with one auth app that mixed together the 
>> models from both apps. That won't happen anymore. Now there will be only one 
>> auth app, and the second will not be loaded. Hopefully this will clear up 
>> some confusion.
>> 
>> 
>> 
>> Overall, I'm happy with the result. Working on this project was a great 
>> experience for me. I plan to continue my work on this branch after gsoc. 
>>

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[Arthur Koziel]

On Sep 9, 2010, at 7:24 AM, Javier Guerra Giraldez wrote:

> what about giving parameters to the apps?  something like:
> 
> INSTALLED_APPS = (
>   'django.contrib.auth',
>   'django.contrib.contenttypes',
>   'django.contrib.sessions',
>   'django.contrib.sites',
>   'django.contrib.admin',
>   ('debug_toolbar', {
>   'INTERCEPT_REDIRECTS': False,
>   'INTERNAL_IPS': ('127.0.0.2',),
>   }),
>   'django_extensions',
>   ('favorites', {
>   'fave': ‘pages.models.Page',
>   }),
>   'comercial',
>   'specs',
> )

Hey Javier,

this approach has been discussed in my GSOC proposal thread[0]. In the end, we 
decided to leave INSTALLED_APPS as strings to maintain backwards compatibility. 
There are also some other resources which you can find on the wiki[1]. You can 
read through my final status report if you're interested in how the gsoc 
went[2]. I'm currently at DjangoCon and we're going to use the sprints to look 
into how the app-loading branch can be integrated into trunk.

Arthur

[0]: 
http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/0cee4bc0557aa9cc
[1]: http://code.djangoproject.com/wiki/SummerOfCode2010#Apploading
[2]: 
http://groups.google.com/group/django-developers/browse_thread/thread/3d730dd8b6653dbb/cd6ce11986aeb162

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

Re: app loading

[Arthur Koziel]

Hey Alex,

thanks for taking the time to review the code. However, we've agreed not to
construct the app instances in the settings.py file as it would require
imports to be used, and stick to the convention of dotted paths. You might
want to read this thread [0], but especially this [1] reply from Jannis
Leidel.

We also discussed this whole thing at the DjangoCon sprints, which led us to
the current implementation. There are now 2 settings with which apps can be
installed:

- APP_CLASSES: which is a list of dotted paths pointing to App classes
- INSTALLED_APPS: stays the same, dotted paths to python modules

Arthur

[0]:
http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/
[1]: http://groups.google.com/group/django-developers/msg/fd2e3bc0593f4158

On Sun, Jan 2, 2011 at 12:17 PM, Alex Kamedov  wrote:

> Hi all! Happy new year!
> Sorry for my bad english.
>
> On this weekend I reviewed app-loading branch[1] and want to propose some
> improvements.
>
> Now app-loading branch resolve how to load application, store its meta data
> and load its models.
> I plan to extend it to get simple way for replacing the same type
> applications. This problem is
> know as Lazy Foreign Key and now can be resolve through settings, but
> django contrib modules
> currently is not supported it. I propose more beautiful way to resolve this
> problem.
>
> The main goal of my improvements is adding ability to simple replace one
> application to another
> with the same type but another functionality.  For example, if you need
> replace `django.contrib.auth`
> on your own application you must rewrite all used 3rd-party applications
> linked with it now. I
> propose way to resolve this problem and I think It is not hard to implement
> with saving backward
> compatibilities.
>
>
> 1. Change INSTALLED_APPS form tuple to dictionary or may be it's better to
> use something with
> the same interface as tuple and dictionary
>
> INSTALLED_APPS = {
> 'auth': 'django.contrib.auth',
> 'comments': 'django.contrib.comments'.
> ...
> }
>
> For backward compatibility it checks on setting load stage and convert to
> dictionary if it need.
>
> INSTALLED_APPS will be low level API to install applications. I propose
> install application through
> `install_applications` function like this:
>
> from django.core.apps import install_applications
>
> INSTALLED_APPS = install_applications(
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> ...
> auth = 'django.contrib.auth',
> comments = 'django.contrib.comments'
> gallery = App(path='my_gallery', db_prefix='new_gallery',
> verbose_name=u'My new gallery')
> )
>
>  There are args and kwargs passed to `install_applications`. It can be
> python module names of
> django applications. Keys of kwargs are system names of the installed
> applications. This names
> will be used to get application instance in other applications (see next
> for more details).
> For applications passed through args keys will be auto generated.
>
> The main benefit is a manage installed applications in project settings
> module without make
> changes in this applications.
>
> Application loading process will be as listed below:
>  * iterate over INSTALLED_APPS items
>  * if item is string - try to load application definition
> (`Application`class) from python package
> defined in this string and create its instance. If application
> definition is not provided, it will be
> auto generated. `django.core.apps.App` class will be used for it.
>  * if item is `App` instance, check existence of python package at `path`
> attribute of `App` instance
>and `ImproperlyConfigured` exception will be raised if this python
> package is not installed.
>
> 2. Way to organize relations between models of different applications
> (something like this it
> already exist in app-loading branch and trunk. I show this only for example
> and demonstrate
> syntax)
>
> from django.core.apps import get_app, get_model
>
> auth = get_app('auth')
>
> class MyModel(models.Model):
> user = models.ForeignKey(auth.models.User)
>
> or
>
> class MyModel(models.Model):
> user = models.ForeignKey(get_model('auth.User'))
>
>
> 3. Add new exceptions: `AppIsNotInstalled` (instead of
> `ImproperlyConfigured`) will be raised if it is
> try to load not installed applications through `get_app`.
>
>
> [1] http://code.djangoproject.com/wiki/Summe

Re: Status of InstalledAppsRevision, soc2010/app-loading branch?

[Arthur Koziel]

Hey there,

I'm going to continue my work on the app loading branch when I finish my
exams end of February.

Oh, and the last discussion about this was 3 weeks ago:
http://groups.google.com/group/django-developers/browse_thread/thread/c8921795bc7868af/

Arthur

On Wed, Jan 19, 2011 at 8:27 PM, bendavis78  wrote:

> It looks like the last discussion on this was back in Apr 2010, and
> the last trunk-merge was 4 months ago.  The last comment on #3591 by
> russelm was that the GSOC branch "is looking reasonably good".So,
> my question is,  is there still any interest in getting this merged
> into trunk,  or is there still a design decision needed?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Moving rest_framework.status into core?

[Arthur Rio]

The one thing that I really prefer from DRF's statuses is their name,
containing the status_code. I used python's `http.HTTPStatus` in a flask
project and I had to have the python docs open
all the time to map between the status code and the name of the status. For
example:
- http.HTTPStatus.BAD_GATEWAY
- rest_framework.status.HTTP_502_BAD_GATEWAY

I don't know if it's enough of an argument to justify maintaining extra
code in Django, but as Carlton said, it's just a file with constants. If
you look at the file in DRF, there haven been very little changes to it
https://github.com/encode/django-rest-framework/commits/master/rest_framework/status.py
and
in my opinion, it does make the developer experience nicer.

Best,

Arthur


On March 23, 2021 at 9:24:32 AM, 'Adam Johnson' via Django developers
(Contributions to Django itself) (django-developers@googlegroups.com) wrote:

Python 3.5 added http.HTTPStatus:
https://docs.python.org/3.9/library/http.html#http.HTTPStatus , so I don't
see a need for such constants in Django, unless they add something extra.
Perhaps you could deprecate from DRF.

On Tue, 23 Mar 2021 at 15:18, Carlton Gibson 
wrote:

> Hiya.
>
> Maybe my search-foo is down but, surprisingly, I couldn't find a
> discussion on this.
>
> Should we maybe bring the HTTP status code constants that we find in
> rest_framework.status into core, as django.http.status?
>
> I find myself wanting them (not for the first time) in a project that
> doesn't really depend on DRF, and thinking (surely) these fit comfortably
> in Django's "I'm a web framework" remit. 🤔
>
> Can I solicit opinions on that please? It's just a list of constants so...
> It seems to fit the "bring some of the more reusable bits of DRF into
> core" theme.
>
> Thanks.
>
> Kind regards,
> Carlton
>
> --
> 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/541cf57b-f369-4dc9-a06e-e3ff8bf4485cn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/541cf57b-f369-4dc9-a06e-e3ff8bf4485cn%40googlegroups.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/CAMyDDM0F9Ly_SMLnSvZRsO4%2BY_Zum9r%2BpvM1H4ZAAgF3mb%2BV3Q%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAMyDDM0F9Ly_SMLnSvZRsO4%2BY_Zum9r%2BpvM1H4ZAAgF3mb%2BV3Q%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/CADOBPEEfe_5bhizzaE74fmvcwpmYC5NOb5NA2yVqt_n%2BrDE5mA%40mail.gmail.com.

Re: Content types shouldn't be created on post_migrate signal

[Arthur Rio]

Hi everyone 👋🏻

After a long period of inactivity I'm back at it with the help of Taylor.

As a reminder: 
Here is the ticket: https://code.djangoproject.com/ticket/29843 
Here is the initial PR: https://github.com/django/django/pull/10540

After some experiments and discussions it felt like while the 
implementation might solve the initial problem, it's a bit under the hood 
and will be hard to debug if something goes wrong.
The idea was to inject operations at the time of running `migrate`.

So... we went back to the idea of having hooks during the `makemigrations` 
process instead, so that the operations would be written to the migration 
files, which would make it more explicit and less risky. Here is a first 
draft of how it would look like: https://github.com/django/django/pull/14229
.

1. We know that the `makemigrations` process is complicated, so before we 
invest more time down that path, is there something obvious we might be 
missing?
2. What do you think of this approach with hooks (pre and post 
"add_operation")?
3. Do you think it would be a useful feature for other third party apps as 
well (not just content types and permissions)?

Thank you for your input, stay safe

Arthur & Taylor

On Saturday, October 13, 2018 at 12:56:25 PM UTC-6 petter.s...@gmail.com 
wrote:

> I encountered a similar issue recently, but with auth permissions.
>
> It is described here: https://code.djangoproject.com/ticket/29843
>
> On Wednesday, October 3, 2018 at 1:01:37 PM UTC+2, Marcin Nowak wrote:
>>
>> Hello.
>>
>> There is a huge issue with content types framework. The data is loaded 
>> after every migration (post_migrate signal) automatically, and this 
>> approach is against db data consistency.
>> The biggest problem is with data migrations, which are applied at the 
>> first time (on clean database). Any data migration which depends on some 
>> content types will not insert the data.
>>
>> The sequence looks like this:
>>
>>1. create db
>>2. insert into auth_permission ...  inner join django_content_type ...
>>3. post migrate: insert into django_content_type ...
>>
>>
>> Two things are wrong:
>>
>>- automatic creation of content types
>>- creation of content types after running migrations
>>
>> Solution:
>>
>>- creation of new app should add very first migration, which will add 
>>entry to the content types
>>- create_contentypes handler should be removed from post_migrate 
>>signal
>>
>> Any data migration, which depends on some content types, should be 
>> declared with proper dependency. This will guarantee existence of the 
>> required content type entry.
>>
>>
>> BR,
>> Marcin
>>
>>
>>

-- 
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/9f6f9bf3-ad26-4874-939e-a7ad3e201a98n%40googlegroups.com.

Case Sensitive Usernames

[Arthur Pemberton]

Especially with the ability to set USERNAME_FIELD to "email", it would be 
really useful to at least have a well documented warning that usernames are 
case-sensitive in Django.

I've been using Django for years, and even I forget that fact some times. 
Until I start Googling and come across [1].

Ideally, it would be great to have a setting (or model field) that would 
allow easy switching to case insensitive usernames.

Arthur Pemberton



[1] https://code.djangoproject.com/ticket/2273

-- 
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/9a5e1df3-778d-4993-8c32-57870fafd8f9n%40googlegroups.com.

Re: Case Sensitive Usernames

[Arthur Pemberton]

A setting to convert all usernames to lowercase would be good too -- that's 
my preference overall in general. However I haven't yet seen how best that 
could/would be accomplished.

For simpler uses case where I'm just sub-classing AbstractUser and not 
customizing the auth backend, I've taken to 
overriding UserManager.get_by_natural_key to allow for case-insensitive 
logins. Though really, I probably should add a signal handler to force 
username to lowercase.

Arthur

On Sunday, December 12, 2021 at 11:21:32 AM UTC-5 Uri wrote:

> Hi Arthur,
>
> I would recommend users of Django to use only lowercase usernames. And if 
> they insist that the username is an email address, also convert it to 
> lowercase. Otherwise you can have 3 separate users uri, Uri, and uRI, or 3 
> separate users with email addresses u...@example.com, u...@example.com, 
> and u...@example.com (or even u...@example.com). Maybe it's better to add 
> an optional setting to enforce usernames to be lowercase. And by the way 
> also alphanumeric. You don't want "!@#" to be a username on your system (or 
> the user's name in Chinese or Hebrew).
>
> It's interesting that this ticket is 15 years old and still not completely 
> resolved.
>
> By the way, when people type their email address, some programs (including 
> browsers) convert the first letter to uppercase, and I have received email 
> addresses from people with the first letter in uppercase, although their 
> true address is lowercase. I don't think you want this uppercase letter to 
> appear on your database in the email field.
>
> אורי
> (Uri)
>
> u...@speedy.net
>
>
> On Sun, Dec 12, 2021 at 6:02 PM Arthur Pemberton  wrote:
>
>> Especially with the ability to set USERNAME_FIELD to "email", it would be 
>> really useful to at least have a well documented warning that usernames are 
>> case-sensitive in Django.
>>
>> I've been using Django for years, and even I forget that fact some times. 
>> Until I start Googling and come across [1].
>>
>> Ideally, it would be great to have a setting (or model field) that would 
>> allow easy switching to case insensitive usernames.
>>
>> Arthur Pemberton
>>
>> 
>>
>> [1] https://code.djangoproject.com/ticket/2273
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%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/c2bb1b2f-e1ac-4770-8989-ebb0fdc47a2cn%40googlegroups.com.

Re: Case Sensitive Usernames

[Arthur Pemberton]

Purely anecdotal, but I've never had a user intentionally signup for an 
account with a case-sensitive email address. I'm not such which users 
expect their username or email addresses to be case-sensitive.

Arthur

On Sunday, December 12, 2021 at 10:40:30 PM UTC-5 m...@kye.id.au wrote:

> Strong -1 on overriding user intent on capitalisation, especially for 
> email addresses as the RFC stipulates that *the local part of an email 
> address is case sensitive*, this is just rarely practiced. There are much 
> better solutions out there (CI[Text|Char]FIeld in Postgres, etc) that 
> enforce case-insensitivity purely for comparison operations which is where 
> you really want it, but without overriding user intent wrt what case the 
> user wants to use in their email or username.
>
> Django could maybe do with easing the process of implementation for 
> case-insensitive fields outside of Postgres. I’m not familiar enough with 
> the other RDBMSs to know how workable that is. But the answer is certainly 
> not discarding user intent. 
>
> Kye
> On 13 Dec 2021, 11:32 AM +0800, Arthur Pemberton , 
> wrote:
>
> A setting to convert all usernames to lowercase would be good too -- 
> that's my preference overall in general. However I haven't yet seen how 
> best that could/would be accomplished. 
>
> For simpler uses case where I'm just sub-classing AbstractUser and not 
> customizing the auth backend, I've taken to 
> overriding UserManager.get_by_natural_key to allow for case-insensitive 
> logins. Though really, I probably should add a signal handler to force 
> username to lowercase.
>
> Arthur
>
> On Sunday, December 12, 2021 at 11:21:32 AM UTC-5 Uri wrote:
>
>> Hi Arthur, 
>>
>> I would recommend users of Django to use only lowercase usernames. And if 
>> they insist that the username is an email address, also convert it to 
>> lowercase. Otherwise you can have 3 separate users uri, Uri, and uRI, or 3 
>> separate users with email addresses u...@example.com, u...@example.com, 
>> and u...@example.com (or even u...@example.com). Maybe it's better to 
>> add an optional setting to enforce usernames to be lowercase. And by the 
>> way also alphanumeric. You don't want "!@#" to be a username on your system 
>> (or the user's name in Chinese or Hebrew).
>>
>> It's interesting that this ticket is 15 years old and still not 
>> completely resolved.
>>
>> By the way, when people type their email address, some programs 
>> (including browsers) convert the first letter to uppercase, and I have 
>> received email addresses from people with the first letter in uppercase, 
>> although their true address is lowercase. I don't think you want this 
>> uppercase letter to appear on your database in the email field.
>>
>> אורי
>> (Uri)
>>
>> u...@speedy.net
>>
>>
>> On Sun, Dec 12, 2021 at 6:02 PM Arthur Pemberton  
>> wrote:
>>
>>> Especially with the ability to set USERNAME_FIELD to "email", it would 
>>> be really useful to at least have a well documented warning that usernames 
>>> are case-sensitive in Django. 
>>>
>>> I've been using Django for years, and even I forget that fact some 
>>> times. Until I start Googling and come across [1].
>>>
>>> Ideally, it would be great to have a setting (or model field) that would 
>>> allow easy switching to case insensitive usernames.
>>>
>>> Arthur Pemberton
>>>
>>> 
>>>
>>> [1] https://code.djangoproject.com/ticket/2273
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%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-develop...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://grou

Re: Case Sensitive Usernames

[Arthur Pemberton]

The current behaviour is an undocumented gotcha. It should at least be
mentioned in the documentation. Very few major login based platforms are
case sensitive, so it should be at least mentioned in the documentation
that by default applications built with Django would be different in that
regard.

Arthur

On Sun, 12 Dec 2021 at 23:01, Benny  wrote:

> IMO this treads dangerously close to what I call a “Django Gotcha” - There
> exist some implementations, where if you’re not paying attention, it’ll
> come back to bite you in the keister. One example would be the test runner
> coercing DEBUG=False in an effort for tests to more accurately reflect a
> production environment.
>
> Normalization is a nightmare all on its own without having to implicitly
> introduce it.
>
> Benny
>
> On Dec 12, 2021, at 9:40 PM, Kye Russell  wrote:
>
> Strong -1 on overriding user intent on capitalisation, especially for
> email addresses as the RFC stipulates that *the local part of an email
> address is case sensitive*, this is just rarely practiced. There are much
> better solutions out there (CI[Text|Char]FIeld in Postgres, etc) that
> enforce case-insensitivity purely for comparison operations which is where
> you really want it, but without overriding user intent wrt what case the
> user wants to use in their email or username.
>
> Django could maybe do with easing the process of implementation for
> case-insensitive fields outside of Postgres. I’m not familiar enough with
> the other RDBMSs to know how workable that is. But the answer is certainly
> not discarding user intent.
>
> Kye
> On 13 Dec 2021, 11:32 AM +0800, Arthur Pemberton ,
> wrote:
>
> A setting to convert all usernames to lowercase would be good too --
> that's my preference overall in general. However I haven't yet seen how
> best that could/would be accomplished.
>
> For simpler uses case where I'm just sub-classing AbstractUser and not
> customizing the auth backend, I've taken to
> overriding UserManager.get_by_natural_key to allow for case-insensitive
> logins. Though really, I probably should add a signal handler to force
> username to lowercase.
>
> Arthur
>
> On Sunday, December 12, 2021 at 11:21:32 AM UTC-5 Uri wrote:
>
>> Hi Arthur,
>>
>> I would recommend users of Django to use only lowercase usernames. And if
>> they insist that the username is an email address, also convert it to
>> lowercase. Otherwise you can have 3 separate users uri, Uri, and uRI, or 3
>> separate users with email addresses u...@example.com, u...@example.com,
>> and u...@example.com (or even u...@example.com). Maybe it's better to
>> add an optional setting to enforce usernames to be lowercase. And by the
>> way also alphanumeric. You don't want "!@#" to be a username on your system
>> (or the user's name in Chinese or Hebrew).
>>
>> It's interesting that this ticket is 15 years old and still not
>> completely resolved.
>>
>> By the way, when people type their email address, some programs
>> (including browsers) convert the first letter to uppercase, and I have
>> received email addresses from people with the first letter in uppercase,
>> although their true address is lowercase. I don't think you want this
>> uppercase letter to appear on your database in the email field.
>>
>> אורי
>> (Uri)
>>
>> u...@speedy.net
>>
>>
>> On Sun, Dec 12, 2021 at 6:02 PM Arthur Pemberton 
>> wrote:
>>
>>> Especially with the ability to set USERNAME_FIELD to "email", it would
>>> be really useful to at least have a well documented warning that usernames
>>> are case-sensitive in Django.
>>>
>>> I've been using Django for years, and even I forget that fact some
>>> times. Until I start Googling and come across [1].
>>>
>>> Ideally, it would be great to have a setting (or model field) that would
>>> allow easy switching to case insensitive usernames.
>>>
>>> Arthur Pemberton
>>>
>>> 
>>>
>>> [1] https://code.djangoproject.com/ticket/2273
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%40googlegroups.com
>>> <https://groups.google

Re: Improvements to the startproject template

[Arthur Pemberton]

For what it's worth, this is the (general) layout I've used for the past 8+
years of my professional Django development.

Arthur

On Wed, 20 Apr 2022 at 15:22, Olivier Dalang 
wrote:

> +1 for Adam's suggestion, I use it as well and like it very much.
>
> > root folder
> - manage.py
> - ...
> > myproject
> - __init__.py
> - settings.py
> - urls.py
> - ...
> > myapp
> - __init__.py
> - models.py
> - ...
>
> Pros:
> - everything is well namespaced under myproject (`myproject.settings`,
> quite straightforward)
> - makes it clear that `settings.py`, `urls.py`, etc. concern the project
> as a whole, and not just an app.
> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it clear
> that myapp is part of this project)
> - it leaves the root level for stuff like .gitignore, db.sqlite, etc, so
> the actual source stays clean from such files.
> - having a parent package allows (does not require) relative imports
> across modules of the same project, which more clearly conveys that such
> apps are tightly coupled
> - with manage.py still in the root folder, you don't need to cd into any
> folder to start working
>
> I use it all the time.
>
> Cheers,
>
> Olivier
>
>
>
>
> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>
>> I prefer Adam's suggestion in the forum post as it lets you namespace
>> everything under your project name nicely and avoids package name
>> collisions, although it doesn't solve the problem of having two directories
>> with the same name by default.
>>
>> That said, either would be an improvement on what we have so I'm in
>> favour of either approach over doing nothing.
>>
>> Cheers,
>> Tom
>>
>> On Wed, 20 Apr 2022 at 16:49, John M 
>> wrote:
>>
>>> I do exactly this for every new Django project, so it's +1 from me as
>>> well.
>>>
>>> John
>>> On 20/04/2022 12:01, da...@springbourne-tech.com wrote:
>>>
>>> +1 for me - this would be really useful.
>>>
>>> On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org
>>> wrote:
>>>
>>>> Hi Tim,
>>>>
>>>> This feels like a good idea to me.
>>>>
>>>> Regards,
>>>> Ian
>>>>
>>>> On Mon, 18 Apr 2022 at 18:17, Tim Allen 
>>>> wrote:
>>>>
>>>>> Greetings, friends!
>>>>>
>>>>> I've issued a PR that makes two changes to the `startproject` template:
>>>>>
>>>>>- instead of putting configuration files such
>>>>>as `settings.py`, `wsgi.py`, and the
>>>>>root `urls.py` in `my_project/my_project`, they are created
>>>>>in `my_project/config`
>>>>>- start the project with a custom User model app, `users`
>>>>>
>>>>> Over the years, I've taught or tutored over 100 Djangonauts starting
>>>>> their first project. Having to distinguish between two directories with 
>>>>> the
>>>>> same name is a constant pain point in the teaching process - "cd into
>>>>> my_project ... no, the other one!"
>>>>>
>>>>>- The `config` option seemed to be the consensus from this thread
>>>>>in the forum: Django New Project Structure/Name - Using Django -
>>>>>Django Forum (djangoproject.com)
>>>>>
>>>>> <https://forum.djangoproject.com/t/django-new-project-structure-name/9987>
>>>>>- Ticket: https://github.com/django/django/pull/15609
>>>>>
>>>>> It is sometimes better to show rather than tell, so following our own
>>>>> documentation and including a custom User model with the initial project
>>>>> template reinforces the best practice that we explicitly point out in the
>>>>> documentation.
>>>>>
>>>>>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) –
>>>>>Django (djangoproject.com)
>>>>><https://code.djangoproject.com/ticket/27909>
>>>>>- Avoids ever having this come up again:
>>>>>
>>>>> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>>>>>
>>>>> Here's a link to the PR: https://github.com/django/django/pull/1560

Re: Content types shouldn't be created on post_migrate signal

[Arthur Rio]

BTW: RunPython() is another thing, which can break your migrations, and
should not be used (especially not by Django internally), because it relies
on the application layer.

How else can you do a data migration? There is no
`migrations.InsertIntoTable`, the only other way currently would be to run
a `migrations.RunSql` query which may look different based on the database
used.

Two things are wrong:

   - automatic creation of content types

Why is it wrong to automatically create a content type? Content type is an
opt-in feature since you can remove it from `INSTALLED_APPS`.


   - creation of content types after running migrations

That’s the only real problem for me. Maybe using a signal for
`migrations.CreateModel` (e.g. post_create_model), instead of using
`post_migrate` would fix it, but there may be other scenarios I’m not
thinking about.


Solution:

   - creation of new app should add very first migration, which will add
   entry to the content types

How would you handle creating a model later on? Or if
`django.contrib.contenttypes` is only added later on to `INSTALLED_APPS`?


Regards,

—

Arthur


On October 4, 2018 at 1:36:39 PM, Marcin Nowak (marcin.j.no...@gmail.com)
wrote:

Hi Aymeric.

Thank you for your reply.

Unfortunately you wrote mostly about me or my writing style, not about the
issue.
I disagree with your opinion about my comments being passive or aggressive.
I'm always writing about a piece of code, functionality,
design/architecture or bug. I never criticised a person directly.



> Starting with "There is a huge issue with content types framework" isn't a
> good way to motivate them.
>
>
But there is an issue with content types framework (not with it's authors).



> Speaking for myself, I would be more eager to investigate if you skipped
> the hyperbole and remained neutral, for example "I'm facing an issue with
> the content types framework".
>
>
Sorry hearing that. I'm not native English speaker.

For me there is almost no difference with these two sentences, except that
first is about the affected thing ("there is an issue with") and second is
more about me ("I have a problem").
Both are valid, I think. I have a problem which is caused by CT framework's
design or issue (in fact it comes from a historical reason, before
migrations era).


> You'd have more success if you managed to write in a positive style.
>

I don't think that my style is unpleasant. If it is - sorry for that.
I'm always trying to describe the problem and give some proposals.
But I'll try to improve this.


> I think the issue itself is valid. I may have hit it before and worked
> around it, likely be executing a subset of migrations to trigger creation
> of content types, then executing the rest of the migrations. Django could
> probably do better.
>
>
I'll generate CTs in very first migration. This will be a workaround, of
course.
But because Django uses migrations internally, CT's should be added to the
database in a same way.

And RunPython() can be problematic. I did something similar with Liquibase'
executeCommand, which was calling management command. And of course it
caused problems after changing app layer.
I'm very conservative about databases and managing them, I think that there
must be complete separation between db and app layer (in the context of
managing dbs), because app layer is changing frequently (more often than
dbs). Mixing both worlds will cause troubles. Always.

Kind Regards,
Marcin
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/0e4464f7-2ed7-4e6b-9b7e-f98a385dffd5%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/0e4464f7-2ed7-4e6b-9b7e-f98a385dffd5%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADOBPEGDbxpNnECnZMk-Ff51YX6T3drfm9MTBRS3gxmcEgQ1tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Content types shouldn't be created on post_migrate signal

[Arthur Rio]

Hey Marcin,

The problem is that data migration based on app layer (python objects, ie.
Models and Managers here) will cause troubles after some time (when app is
changing).
In the other words - you cannot rely on your app layer when doing database
changes. You should never do that, especially for projects requiring LTS.

In theory I understand the idea, but in practice, migrations, the ORM and
the content type model are all part of Django and I don’t really see how
the app changing could cause troubles. Do you have an example in mind?

Maybe "automatic" is not a proper word. They should be created
automatically, but should be applied "at the right time".

Ok, that we agree on!

CT opt-in should be connected to a signal related to the creation of
migration files (Autodetector?), not to a signal related to their
execution. I.e. pre/post_autodection signals should be introduced.

I think we agree that the solution would be some sort of signal triggered
when a model creation/deletion is detected (in the `makemigrations` phase
as opposed to `migrate`) so that some code is added to the generated
migration. The use of a signal is important to keep things decoupled and
flexible.

The “some code is added to the migration” part still needs to be
determined, either in the shape of insert/delete statements or a RunPython
leveraging the ORM. In both cases, the values to insert (Adding a model) or
to lookup for delete (Removing a model) are just 2 strings, the app label
and the model class name.

After adding contrib.contenttypes, Django should check existence of
django_content_type table. If exists, Django should only check for data
changes and generate series of inserts/deletes. If not, Django should
generate inserts for all models. If CT is removed later, Django should
remove all CT data .

It’s a good idea but I don’t know offhand how we can keep migrations and
content type decoupled to do that (especially the removal).

Finally, I also think the concept could be extended to the permission model
which faces similar issues.


Regards

--

Arthur



On October 4, 2018 at 4:47:19 PM, Marcin Nowak (marcin.j.no...@gmail.com)
wrote:


Hi Arthur.

BTW: RunPython() is another thing, which can break your migrations, and
should not be used (especially not by Django internally), because it relies
on the application layer.

How else can you do a data migration? There is no
> `migrations.InsertIntoTable`,
>

You're right. That's why "Insert" should be (in my opinion) introduced.
Together with "migrations.Delete".

The problem is that data migration based on app layer (python objects, ie.
Models and Managers here) will cause troubles after some time (when app is
changing).
In the other words - you cannot rely on your app layer when doing database
changes. You should never do that, especially for projects requiring LTS.

RunPython() should be used only when you cannot do anything else. In such
case you must accept all consequences. I'm not against RunPython(), but
against doing data migrations using it.

The problem with hypothetical "Insert" operation is with mapping field
types. Insert cannot use Models directly (app layer is changing over a
time), but should "know" how to map arguments (python types, values) to a
database literals. It can be achieved by introducing field mapping for a
every insert or per migration file (something like "model freeze", but only
for used fields).

Also Insert should not accept variables calculated in the app layer (within
a migration) - it should contain only plain/direct data. But using Python
as a language for migrations, will be hard to avoid such possibility. This
is important, because database management should not rely on app layer.
Using variables (i.e. from settings) would result in inconsistent data
changes between different environments.

the only other way currently would be to run a `migrations.RunSql` query
> which may look different based on the database used.
>

RunSQL is not the solution for db agnostic operations. It may be only used
within a project, because db engine used changes rarely (due to the nature
and importance of the data and relational databases, and systems dependent
on the db).
But RunSQL is a handful operation, because SQL is a natural language for db
management. I'm doing many raw sqls in migrations.


> Two things are wrong:
>
>- automatic creation of content types
>
> Why is it wrong to automatically create a content type?
>

Maybe "automatic" is not a proper word. They should be created
automatically, but should be applied "at the right time".


> Content type is an opt-in feature since you can remove it from
> `INSTALLED_APPS`.
>

I know, but it is required by contrib.auth. I saw no project depending on
something else, so CT is optional.. but theoretically ;)


>
>- creation of content types after

Re: Content types shouldn't be created on post_migrate signal

[Arthur Rio]

For some reason the text is white… Here it is in black:

Hey Marcin,

The problem is that data migration based on app layer (python objects, ie.
Models and Managers here) will cause troubles after some time (when app is
changing).
In the other words - you cannot rely on your app layer when doing database
changes. You should never do that, especially for projects requiring LTS.

In theory I understand the idea, but in practice, migrations, the ORM and
the content type model are all part of Django and I don’t really see how
the app changing could cause troubles. Do you have an example in mind?

Maybe "automatic" is not a proper word. They should be created
automatically, but should be applied "at the right time".

Ok, that we agree on!

CT opt-in should be connected to a signal related to the creation of
migration files (Autodetector?), not to a signal related to their
execution. I.e. pre/post_autodection signals should be introduced.

I think we agree that the solution would be some sort of signal triggered
when a model creation/deletion is detected (in the `makemigrations` phase
as opposed to `migrate`) so that some code is added to the generated
migration. The use of a signal is important to keep things decoupled and
flexible.

The “some code is added to the migration” part still needs to be
determined, either in the shape of insert/delete statements or a RunPython
leveraging the ORM. In both cases, the values to insert (Adding a model) or
to lookup for delete (Removing a model) are just 2 strings, the app label
and the model class name.

After adding contrib.contenttypes, Django should check existence of
django_content_type table. If exists, Django should only check for data
changes and generate series of inserts/deletes. If not, Django should
generate inserts for all models. If CT is removed later, Django should
remove all CT data .

It’s a good idea but I don’t know offhand how we can keep migrations and
content type decoupled to do that (especially the removal).

Finally, I also think the concept could be extended to the permission model
which faces similar issues.


Regards

--

Arthur

On October 5, 2018 at 9:30:58 AM, Arthur Rio (arthur.ri...@gmail.com) wrote:

Hey Marcin,

The problem is that data migration based on app layer (python objects, ie.
Models and Managers here) will cause troubles after some time (when app is
changing).
In the other words - you cannot rely on your app layer when doing database
changes. You should never do that, especially for projects requiring LTS.

In theory I understand the idea, but in practice, migrations, the ORM and
the content type model are all part of Django and I don’t really see how
the app changing could cause troubles. Do you have an example in mind?

Maybe "automatic" is not a proper word. They should be created
automatically, but should be applied "at the right time".

Ok, that we agree on!

CT opt-in should be connected to a signal related to the creation of
migration files (Autodetector?), not to a signal related to their
execution. I.e. pre/post_autodection signals should be introduced.

I think we agree that the solution would be some sort of signal triggered
when a model creation/deletion is detected (in the `makemigrations` phase
as opposed to `migrate`) so that some code is added to the generated
migration. The use of a signal is important to keep things decoupled and
flexible.

The “some code is added to the migration” part still needs to be
determined, either in the shape of insert/delete statements or a RunPython
leveraging the ORM. In both cases, the values to insert (Adding a model) or
to lookup for delete (Removing a model) are just 2 strings, the app label
and the model class name.

After adding contrib.contenttypes, Django should check existence of
django_content_type table. If exists, Django should only check for data
changes and generate series of inserts/deletes. If not, Django should
generate inserts for all models. If CT is removed later, Django should
remove all CT data .

It’s a good idea but I don’t know offhand how we can keep migrations and
content type decoupled to do that (especially the removal).

Finally, I also think the concept could be extended to the permission model
which faces similar issues.


Regards

--

Arthur



On October 4, 2018 at 4:47:19 PM, Marcin Nowak (marcin.j.no...@gmail.com)
wrote:


Hi Arthur.

BTW: RunPython() is another thing, which can break your migrations, and
should not be used (especially not by Django internally), because it relies
on the application layer.

How else can you do a data migration? There is no
> `migrations.InsertIntoTable`,
>

You're right. That's why "Insert" should be (in my opinion) introduced.
Together with "migrations.Delete".

The problem is that data migration based on app layer (python objects, ie.
Models and Managers here) will cause troubles after some time (when app is
changing).
In the othe

Re: Content types shouldn't be created on post_migrate signal

[Arthur Rio]

Hey Marcin,

I hope you had a good week-end. After looking through the codebase to get 
more familiar with how `pre_migrate` and `post_migrate` are currently used, 
I thought we could simply have the same sort of signal for 
`post_makemigrations`,
where a third party could get a list of the changes and the plan and append 
operations to the generated file (probably adding itself as dependency 
too). However, it seems to be far from trivial given the related
threads I found related to the 
subject: 
https://groups.google.com/d/msg/django-developers/qRNkReCZiCk/I8dIxxhoBwAJ 
and https://groups.google.com/d/msg/django-developers/iClIpvwlbAU/4uX7q_7aAQAJ
I was surprised to see that the `RenameModel` was handled by `ContentType` 
using the `pre_migrate` hook rather than happening in the `makemigrations` 
phase, maybe someone can share some context?

I really think this is a real problem and something that could get improved 
but to do so it would require fixing the bigger issue.

To quote Simon Charette 
(https://groups.google.com/d/msg/django-developers/qRNkReCZiCk/Ah90crNFAAAJ):

"As for the makemigrations hooks I think it would require a lot of thought 
and
efforts to get right. Right now the auto-detector is a black box that deals 
with
dependencies and model state deltas resolution."

If now is the time to take a stab at it, I'd be happy to help as much as I 
can.

Regards

--
Arthur


On Friday, October 5, 2018 at 10:28:06 AM UTC-7, Arthur Rio wrote:
>
> For some reason the text is white… Here it is in black:
>
> Hey Marcin,
>
> The problem is that data migration based on app layer (python objects, ie. 
> Models and Managers here) will cause troubles after some time (when app is 
> changing).
> In the other words - you cannot rely on your app layer when doing database 
> changes. You should never do that, especially for projects requiring LTS.
>
> In theory I understand the idea, but in practice, migrations, the ORM and 
> the content type model are all part of Django and I don’t really see how 
> the app changing could cause troubles. Do you have an example in mind?
>
> Maybe "automatic" is not a proper word. They should be created 
> automatically, but should be applied "at the right time".
>
> Ok, that we agree on!
>
> CT opt-in should be connected to a signal related to the creation of 
> migration files (Autodetector?), not to a signal related to their 
> execution. I.e. pre/post_autodection signals should be introduced.
>
> I think we agree that the solution would be some sort of signal triggered 
> when a model creation/deletion is detected (in the `makemigrations` phase 
> as opposed to `migrate`) so that some code is added to the generated 
> migration. The use of a signal is important to keep things decoupled and 
> flexible.
>
> The “some code is added to the migration” part still needs to be 
> determined, either in the shape of insert/delete statements or a RunPython 
> leveraging the ORM. In both cases, the values to insert (Adding a model) or 
> to lookup for delete (Removing a model) are just 2 strings, the app label 
> and the model class name.
>
> After adding contrib.contenttypes, Django should check existence of 
> django_content_type table. If exists, Django should only check for data 
> changes and generate series of inserts/deletes. If not, Django should 
> generate inserts for all models. If CT is removed later, Django should 
> remove all CT data .
>
> It’s a good idea but I don’t know offhand how we can keep migrations and 
> content type decoupled to do that (especially the removal).
>
> Finally, I also think the concept could be extended to the permission 
> model which faces similar issues.
>
>
> Regards
>
> --
>
> Arthur
>
> On October 5, 2018 at 9:30:58 AM, Arthur Rio (arthur.ri...@gmail.com) 
> wrote:
>
> Hey Marcin,
>
> The problem is that data migration based on app layer (python objects, ie. 
> Models and Managers here) will cause troubles after some time (when app is 
> changing).
> In the other words - you cannot rely on your app layer when doing database 
> changes. You should never do that, especially for projects requiring LTS.
>
> In theory I understand the idea, but in practice, migrations, the ORM and 
> the content type model are all part of Django and I don’t really see how 
> the app changing could cause troubles. Do you have an example in mind?
>
> Maybe "automatic" is not a proper word. They should be created 
> automatically, but should be applied "at the right time".
>
> Ok, that we agree on!
>
> CT opt-in should be connected to a signal related to the creation of 
> migration files (Autodetector?), not to a signal related to their 
> execution. I.e. pre/post_autode

Migration strategy for proxy model permissions to use their own content type

[Arthur Rio]

Hi all,

I have been working on a 9 years old ticket that I'd like to close once and 
for all. The outstanding question is about the migration path to choose in 
order to update existing proxy model permissions. I have explained three 
different approaches I can think of in the pull 
request: https://github.com/django/django/pull/10381#issuecomment-435534644. 

I have implemented the first option and wrote the release notes explaining 
what to expect for users upgrading: 
https://github.com/django/django/pull/10381/files#diff-1f22a5c1d6164c6de8defb36f3829138.

Carlton, who has been the main reviewer, suggested to contact the mailing 
list for further review in order to catch any red flag and make sure we 
have general consensus on the chosen approach. 

Regards.

Arthur

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f3298dbb-e072-4815-944c-2250d0b4d3a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: IRC Channel

[Arthur Rio]

Hi Avi,

There are #django (for usage) and #django-dev (for contributing), both on
irc.freenode.net, as mentioned here:
https://docs.djangoproject.com/en/dev/internals/contributing/

Regards

—
Arthur

On December 13, 2018 at 11:03:51 PM, Avi Garg (avi.grg4...@gmail.com) wrote:

Does Django have an IRC channel? I am unable to join it if so...
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/166e0cef-1f71-40c3-abbe-f0985d6ea7fb%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/166e0cef-1f71-40c3-abbe-f0985d6ea7fb%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADOBPEHc%2BpGc%3D4E-x%2BK%3DX8DykTU6UT2sGV9VCGmdnf0%2Bcgzv3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration strategy for proxy model permissions to use their own content type

[Arthur Rio]

Thank you for your feedback Aymeric,

I have added the backward migration method + tests per your suggestion:
https://github.com/django/django/pull/10381/commits/d5c4a4b08ccee9239e5117df4c788a5a7a2f60a9

Regards


—
Arthur

On January 6, 2019 at 10:04:18 PM, Aymeric Augustin (
aymeric.augus...@polytechnique.org) wrote:

Hello Arthur,

I agree that option 1 is the way to go.

It would be nice to make the migration reversible. If someone upgrades to
Django 2.2.x, migrates the database, and later discovers a blocking issue,
they should have the option to migrate backwards and downgrade to 2.1.y.

Best regards,

-- 
Aymeric.



On 26 Nov 2018, at 16:10, Arthur Rio  wrote:

Hi all,

I have been working on a 9 years old ticket that I'd like to close once and
for all. The outstanding question is about the migration path to choose in
order to update existing proxy model permissions. I have explained three
different approaches I can think of in the pull request:
https://github.com/django/django/pull/10381#issuecomment-435534644.

I have implemented the first option and wrote the release notes explaining
what to expect for users upgrading:
https://github.com/django/django/pull/10381/files#diff-1f22a5c1d6164c6de8defb36f3829138
.

Carlton, who has been the main reviewer, suggested to contact the mailing
list for further review in order to catch any red flag and make sure we
have general consensus on the chosen approach.

Regards.

Arthur

--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f3298dbb-e072-4815-944c-2250d0b4d3a3%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/f3298dbb-e072-4815-944c-2250d0b4d3a3%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/46CD821B-C17E-4FF8-B623-6B40B0FB0BBD%40polytechnique.org
<https://groups.google.com/d/msgid/django-developers/46CD821B-C17E-4FF8-B623-6B40B0FB0BBD%40polytechnique.org?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADOBPEFozUMDawj%3DEi2Ju5eFnTFVzKR%2BYWw5VA0edJ%3DF2neirw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for unittest -k option

[Arthur Rio]

I’m +1 on no short-hand. Also “kdb” is a little to close to “pdb” and
doesn’t really make sense to me.

—
Arthur

On March 11, 2019 at 3:33:50 PM, Dan Davis (dansm...@gmail.com) wrote:

I personally don't think a short-hand is needed.

On Mon, Mar 11, 2019 at 10:41 AM Tim Graham  wrote:

> -kdb could be a suitable short option.
>
> On Monday, March 11, 2019 at 9:20:37 AM UTC-4, Tobias McNulty wrote:
>>
>> Agreed it's probably better to make the switch now, and I'd be fine
>> without a replacement shorthand alternative for --keepdb.
>>
>> Cheers,
>>
>>
>> *Tobias McNulty*Chief Executive Officer
>>
>> tob...@caktusgroup.com
>> www.caktusgroup.com
>>
>>
>> On Mon, Mar 11, 2019 at 8:19 AM Carlton Gibson 
>> wrote:
>>
>>> Thanks François,
>>>
>>> Just on this, my thought is that if we don't follow `unittest` in
>>> changing `-k` for this, we have a steady trickle of confusion forever-more.
>>> I'd rather avoid that.
>>>
>>> C.
>>>
>>> On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:
>>>>
>>>> Hi Django Devs,
>>>>
>>>> https://code.djangoproject.com/ticket/30245 suggests supporting Python
>>>> unittest `-k` option, to selectively run tests matching a keyword.
>>>>
>>>> Currently, `-k` is the shorthand for `--keepdb` in Django.
>>>> A `--filter` flag was suggested to preserve backward compatibility.
>>>> Carlton suggested removing the `-k` option from `--keepdb` and reusing
>>>> it for unittest `-k`. That would follow unittest more closely, reduce
>>>> user confusion and ease maintenance.
>>>>
>>>> What do you think is best? Do you see other options?
>>>>
>>>> If re-taking the `-k` option for unittest `-k`, should a new shorthand
>>>> be introduced for `--keepdb`?
>>>>
>>>> Thanks for your time,
>>>> François
>>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/c54e52d2-012a-4852-9375-be37add55945%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/c54e52d2-012a-4852-9375-be37add55945%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d0f1df05-238c-4ad6-97c2-a852bda939bc%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/d0f1df05-238c-4ad6-97c2-a852bda939bc%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAFzonYYRhKbPbuUvZCb9hM3jM%3D90VPwv9Ug%2B0k%3DdXUuRyDMz_Q%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAFzonYYRhKbPbuUvZCb9hM3jM%3D90VPwv9Ug%2B0k%3DdXUuRyDMz_Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADOBPEEJGbczwxmCax0ak0p3DqSJc9K_wApbbATo_q9Ywx%3D0ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Progress, status, and opinions of #2070

[arthur debert]

Hi Mike.

This is less of a patch review, and more of an user's feedback.
Probably not the best place to post this, but I figured track's ticket
2070 page already has too much going on there.

Been using this patch for a while without a glitch ( in webfaction's
setup, apache2, mod_python). Running pretty smoothly, even with
simultaneous uploads.

One suggestion is that the new setting for settings.py could have a
bit more descriptive names. FILE_UPLOAD_DIR seems somewhat related to
where files are uploaded to (such as upload_to in models) which can be
confusing. Maybe something like FILE_UPLOAD_TEMP_DIR will give more
the idea of what this is really about.
Just wanted to drop in and give the perspective of someone just using
the patch. All in all, thanks for the patch, it's a lifesaver.

cheers
Arthur


--~--~-~--~~~---~--~~
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: {GSoC 2008}Django-Newcomments : A preview

[arthur debert]

Hi Thejaswi.

A couple of suggestions:

Any reasons for having CommentFlag.flag being a string, and not a
foreign key to a FlagType model ? Having them as strings makes it
easier to end up with bad data (misspelling and so forth). Of course
there is always the performance penalty, but it seems worth it.

Also, many times it is useful to keep a "raw" body for a comment (as
the user sent it), but also for performance reasons, a "processed"
version such as html (from markdown or something else). Maybe keeping
both in the db allows for speedier rendering. Then an application can
define somewhere (maybe a settings) which function to process the
comment (markdown, textile, some home made tag removing routine), and
have that run and then persisting both at the database.

Thanks
Arthur
--~--~-~--~~~---~--~~
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: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

To simplify things further, within a view:

TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M', '%I:%M %p']

and

forms.TimeField.input_formats = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M']

On Sun, Dec 8, 2024 at 9:55 AM Arthur Pemberton  wrote:

> I finally got back to this.
>
> I have a failing minimal project (not test) that
> demonstrates TIME_INPUT_FORMATS not being respected:
> https://github.com/pembo13/dateentry
>
> In the example, the form should be valid, if TIME_INPUT_FORMATS worked as
> documented.
>
> I _think_ there's something about how the unittest is written that allows
> it to pass, and not expose this.
>
> Regards,
> Arthur
>
> On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson  wrote:
>
>> USE_I18N does not disable localization, but internationalization.
>> USE_L10N was the setting to enable/disable localization, but it was
>> deprecated in Django 4.0:
>> https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It
>> was removed completely in Django 5.0, in this commit:
>> https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
>> .
>>
>> So I think the phrase “if localization is disabled” is at least a little
>> bit wrong. But I don’t think the setting is ignored, as there are tests
>> confirming that it works:
>> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
>> . The line that reads the setting should be this one:
>> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
>> .
>>
>> If you can provide a failing minimal project, that would be useful to
>> keep debugging. I have some minimal django project templates at
>> https://github.com/adamchainz/django-startproject-templates .
>>
>> On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
>>
>> Thanks, I'll look into that. But does that mean that
>> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
>> flows that lead to it being used.
>>
>> On Tue, Mar 5, 2024 at 3:00 AM David Sanders <
>> shang.xiao.sand...@gmail.com> wrote:
>>
>> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
>> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>>
>> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>>
>> The documentation (
>> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
>> that " the default input formats are taken from the active locale format
>> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
>> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
>> if localization is disabled". However, neither my reading of the code, or
>> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
>> even with "USE_I18N = False"
>>
>> TimeField gets the formats from `input_formats =
>> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
>> `formats.get_format` -- the documentation of which says "If use_l10n is
>> provided and is not None, it forces the value to be localized (or not),
>> otherwise it's always localized."
>>
>> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
>> ignored.
>>
>> How does one use settings.TIME_INPUT_FORMATS ?
>>
>> Arthur Pemberton
>>
>>
>> --
>> 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%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
>>

How to run the CustomTimeInputFormatsTests unit test?

[Arthur Pemberton]

I've read 
through 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/
 
and I'm still uncertain how to properly run it.

As far as I can tell, tests decorated with `@translation.override(None)` do 
not get run when using `./runtests.py`

Even using `./runtests.py 
forms_tests.tests.test_input_formats.CustomTimeInputFormatsTests.test_timeField`
 
results in an error:

TypeError: CustomTimeInputFormatsTests.test_timeField() missing 1 required 
positional argument: 'self'

Arthur Pemberton

-- 
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 visit 
https://groups.google.com/d/msgid/django-developers/2f3cc486-2e47-476a-a036-92850c5dbce6n%40googlegroups.com.

Re: How to run the CustomTimeInputFormatsTests unit test?

[Arthur Pemberton]

I've submitted https://code.djangoproject.com/ticket/35986 

If I'm missing something, please let me know.

Arthur Pemberton

On Monday, December 9, 2024 at 5:12:57 AM UTC-5 Bendegúz Csirmaz wrote:

> Yes you're right, it's not executed for me either.
>
> On Monday, 9 December 2024 at 17:53:16 UTC+8 Arthur Pemberton wrote:
>
>> I've read through 
>> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/
>>  
>> and I'm still uncertain how to properly run it.
>>
>> As far as I can tell, tests decorated with `@translation.override(None)` 
>> do not get run when using `./runtests.py`
>>
>> Even using `./runtests.py 
>> forms_tests.tests.test_input_formats.CustomTimeInputFormatsTests.test_timeField`
>>  
>> results in an error:
>>
>> TypeError: CustomTimeInputFormatsTests.test_timeField() missing 1 
>> required positional argument: 'self'
>>
>> Arthur Pemberton
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/django-developers/8d0f229c-748c-4749-a1a8-1734cf7ee198n%40googlegroups.com.

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

As further follow up on this, as far as I can tell, the relevant unit test 
does not run, seemingly due to the use of `translation.override(None)`

Removing, that, and running the test `./runtests.py 
forms_tests.tests.test_input_formats.CustomTimeInputFormatsTests.test_timeField`
 
results in the test failing.

Arthur Pemberton

On Sunday, December 8, 2024 at 8:03:22 PM UTC-5 Arthur Pemberton wrote:

To simplify things further, within a view:

TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M', '%I:%M %p']

and

forms.TimeField.input_formats = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M']

On Sun, Dec 8, 2024 at 9:55 AM Arthur Pemberton  wrote:

I finally got back to this. 

I have a failing minimal project (not test) that 
demonstrates TIME_INPUT_FORMATS not being respected:
https://github.com/pembo13/dateentry

In the example, the form should be valid, if TIME_INPUT_FORMATS worked as 
documented.

I _think_ there's something about how the unittest is written that allows 
it to pass, and not expose this.

Regards,
Arthur

On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson  wrote:

USE_I18N does not disable localization, but internationalization. USE_L10N 
was the setting to enable/disable localization, but it was deprecated in 
Django 4.0: https://docs.djangoproject.com/en/4.0/releases/4.0/#localization 
. It was removed completely in Django 5.0, in this commit: 
https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
 
.

So I think the phrase “if localization is disabled” is at least a little 
bit wrong. But I don’t think the setting is ignored, as there are tests 
confirming that it works: 
https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
 
. The line that reads the setting should be this one: 
https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
 
.

If you can provide a failing minimal project, that would be useful to keep 
debugging. I have some minimal django project templates at 
https://github.com/adamchainz/django-startproject-templates .

On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:

Thanks, I'll look into that. But does that mean that 
settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic 
flows that lead to it being used.

On Tue, Mar 5, 2024 at 3:00 AM David Sanders  wrote:

Define TIME_INPUT_FORMATS in your local formats.py setup as per: 
https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files

On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:

The documentation (
https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says 
that " the default input formats are taken from the active locale format 
TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS 
<https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
 
if localization is disabled". However, neither my reading of the code, or 
my actual experience shows settings.TIME_INPUT_FORMATS ever being used, 
even with "USE_I18N = False"

TimeField gets the formats from `input_formats = 
formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of 
`formats.get_format` -- the documentation of which says "If use_l10n is 
provided and is not None, it forces the value to be localized (or not), 
otherwise it's always localized."

so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be 
ignored.

How does one use settings.TIME_INPUT_FORMATS ?

Arthur Pemberton


-- 
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-develop...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
 
<https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%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-develop...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
 
<https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.


-- 
You received this message because you a

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

Adam,

Up until now, I've only been reading the test. Now that I actually tried 
running the test, it does not get discovered by the testing system (without 
modifications to test_input_formats.py) and when I do get the test to run, 
it fails.

I used tag "5.1.4" to get the unit tests.

Arthur

On Tuesday, March 5, 2024 at 3:41:10 PM UTC-5 Adam Johnson wrote:

> USE_I18N does not disable localization, but internationalization. USE_L10N 
> was the setting to enable/disable localization, but it was deprecated in 
> Django 4.0: 
> https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was 
> removed completely in Django 5.0, in this commit: 
> https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
>  
> .
>
> So I think the phrase “if localization is disabled” is at least a little 
> bit wrong. But I don’t think the setting is ignored, as there are tests 
> confirming that it works: 
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
>  
> . The line that reads the setting should be this one: 
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
>  
> .
>
> If you can provide a failing minimal project, that would be useful to keep 
> debugging. I have some minimal django project templates at 
> https://github.com/adamchainz/django-startproject-templates .
>
> On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
>
> Thanks, I'll look into that. But does that mean that 
> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic 
> flows that lead to it being used.
>
> On Tue, Mar 5, 2024 at 3:00 AM David Sanders  
> wrote:
>
> Define TIME_INPUT_FORMATS in your local formats.py setup as per: 
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
> The documentation (
> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says 
> that " the default input formats are taken from the active locale format 
> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS 
> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
>  
> if localization is disabled". However, neither my reading of the code, or 
> my actual experience shows settings.TIME_INPUT_FORMATS ever being used, 
> even with "USE_I18N = False"
>
> TimeField gets the formats from `input_formats = 
> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of 
> `formats.get_format` -- the documentation of which says "If use_l10n is 
> provided and is not None, it forces the value to be localized (or not), 
> otherwise it's always localized."
>
> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be 
> ignored.
>
> How does one use settings.TIME_INPUT_FORMATS ?
>
> Arthur Pemberton
>
>
> -- 
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%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-develop...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CA%2BX4dQTQwnqe%3DpJ

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

I finally got back to this.

I have a failing minimal project (not test) that
demonstrates TIME_INPUT_FORMATS not being respected:
https://github.com/pembo13/dateentry

In the example, the form should be valid, if TIME_INPUT_FORMATS worked as
documented.

I _think_ there's something about how the unittest is written that allows
it to pass, and not expose this.

Regards,
Arthur

On Tue, Mar 5, 2024 at 3:40 PM Adam Johnson  wrote:

> USE_I18N does not disable localization, but internationalization. USE_L10N
> was the setting to enable/disable localization, but it was deprecated in
> Django 4.0:
> https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was
> removed completely in Django 5.0, in this commit:
> https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
> .
>
> So I think the phrase “if localization is disabled” is at least a little
> bit wrong. But I don’t think the setting is ignored, as there are tests
> confirming that it works:
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
> . The line that reads the setting should be this one:
> https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
> .
>
> If you can provide a failing minimal project, that would be useful to keep
> debugging. I have some minimal django project templates at
> https://github.com/adamchainz/django-startproject-templates .
>
> On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
>
> Thanks, I'll look into that. But does that mean that
> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
> flows that lead to it being used.
>
> On Tue, Mar 5, 2024 at 3:00 AM David Sanders 
> wrote:
>
> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
> The documentation (
> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
> that " the default input formats are taken from the active locale format
> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
> <https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-TIME_INPUT_FORMATS>
> if localization is disabled". However, neither my reading of the code, or
> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
> even with "USE_I18N = False"
>
> TimeField gets the formats from `input_formats =
> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
> `formats.get_format` -- the documentation of which says "If use_l10n is
> provided and is not None, it forces the value to be localized (or not),
> otherwise it's always localized."
>
> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
> ignored.
>
> How does one use settings.TIME_INPUT_FORMATS ?
>
> Arthur Pemberton
>
>
> --
> 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%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/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%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/CA%2BX