Re: Cleaning up manage.py and import paths
This is fantastically clear and sensible. +1. I can't count the hours I've lost either chasing PYTHONPATH issues or helping nontechnical people work around them so they could deploy their newly-minted thing. I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/2ZtSAWg--NMJ. 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: Cleaning up manage.py and import paths
On Oct 12, 9:31 am, Idan Gazit wrote: > This is fantastically clear and sensible. +1. > > I can't count the hours I've lost either chasing PYTHONPATH issues or > helping nontechnical people work around them so they could deploy their > newly-minted thing. I would agree that this is a well-thought-out solution to a long- standing problem, and moves things in a very positive direction. S -- 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: Update on Ticket #16891: Delete/update should return number of rows modified
Uhm question -- Does the count for Model.save() make any sense? Isn't that always one? Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/rpkcIupLI9gJ. 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.
#16869 - BaseGenericInlineFormSet does not use form's save() method
Hello, As described on the ticket [1], I attach a patch that changes the behaviour of "save_new" method in order to use the form's "save" method. Is the patch correct, or there's something to improve? Thanks in advance [1] https://code.djangoproject.com/ticket/16869 [2] https://code.djangoproject.com/attachment/ticket/16869/save_new_using_form_save.patch -- Pablo Recio Quijano -- 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.
#17028 - diveintopython.org links now dead
Hello, As described on the ticket [1], it seems that diveintopython.org is dead, so I changed every occurence for the mirror http://diveintopython.nfshost.com/, that it seems to be the most updated. The changes are on the patch attached in the ticket [2]. Best regards [1] https://code.djangoproject.com/ticket/17028 [2] https://code.djangoproject.com/attachment/ticket/17028/diveintopython_mirror_doc.patch -- Pablo Recio Quijano -- 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: #17028 - diveintopython.org links now dead
How about: http://web.archive.org/web/20110726001211/http://diveintopython.org/ ? On Wed, Oct 12, 2011 at 2:37 AM, rikuthero...@gmail.com wrote: > Hello, > > As described on the ticket [1], it seems that diveintopython.org is dead, so > I changed every occurence for the mirror > http://diveintopython.nfshost.com/, that it seems to be the most updated. > The changes are on the patch attached in the ticket [2]. > > Best regards > > [1] https://code.djangoproject.com/ticket/17028 > [2] > https://code.djangoproject.com/attachment/ticket/17028/diveintopython_mirror_doc.patch > > -- > Pablo Recio Quijano > > -- > 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: #17028 - diveintopython.org links now dead
Both have the content updated since 20 May 2004, so the content it's the same, and I think is better to have a smaller URL, and it has no header banner like the one from web.archive.org But as I said, the content is really the same, so there should be no problem changing it. 2011/10/12 Jeremy Dunck > How about: > http://web.archive.org/web/20110726001211/http://diveintopython.org/ > ? > > On Wed, Oct 12, 2011 at 2:37 AM, rikuthero...@gmail.com > wrote: > > Hello, > > > > As described on the ticket [1], it seems that diveintopython.org is > dead, so > > I changed every occurence for the mirror > > http://diveintopython.nfshost.com/, that it seems to be the most > updated. > > The changes are on the patch attached in the ticket [2]. > > > > Best regards > > > > [1] https://code.djangoproject.com/ticket/17028 > > [2] > > > https://code.djangoproject.com/attachment/ticket/17028/diveintopython_mirror_doc.patch > > > > -- > > Pablo Recio Quijano > > > > -- > > 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. > > -- Pablo Recio Quijano -- 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: #17028 - diveintopython.org links now dead
Mirrors are appearing in a number of places for this and the html5 version. Its hard to know which are more likely to stick around. http://diveintopython3.ep.io/ https://github.com/diveintomark/diveintopython3 Dougal -- 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: Update on Ticket #16891: Delete/update should return number of rows modified
Am 12.10.2011 um 03:35 schrieb Steven Cummings: > Finally got around to these simple changes: > > * > https://github.com/estebistec/django/commit/b48a87afc324f5546b6654fa7638e406b397c0d6 > * > https://github.com/estebistec/django/commit/28ace32980b370fd17ae35019bfe8d055c673684 > > If the core devs approve of these changes I can get to work on creating the > proper patch for SVN and add doc changes. > > Ticket: https://code.djangoproject.com/ticket/16891#comment:3 Ticket #12086 is a duplicate. I don't think QuerySet.delete() should return the number of all collected objects, but just the number of objects deleted from QuerySet.model. And Model.save()/Model.delete() should really only return 1, as *one object* has been saved/deleted, even if more than one database row was touched. Thus, both methods don't need the return value. Thanks for working on this! __ Johannes -- 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: #17028 - diveintopython.org links now dead
Those mirrors are from Dive into Python 3, is not the one linked from the Django docs. 2011/10/12 Dougal Matthews > Mirrors are appearing in a number of places for this and the html5 > version. Its hard to know which are more likely to stick around. > > http://diveintopython3.ep.io/ > https://github.com/diveintomark/diveintopython3 > > Dougal > > -- > 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. > > -- Pablo Recio Quijano -- 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: Cleaning up manage.py and import paths
On Tue, Oct 11, 2011 at 6:05 AM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > In the spirit of making Django behave better as a Python library (c.f. > Glyph's keynote at djangocon.us), I'd like to finally tackle removing > the sys.path hacks in django.core.management.setup_environ. I'll give > the full detailed rundown here on the current behavior and how I propose > to change it. Fortunately, the fix isn't that complicated, and I think > it's a no-brainer. For the impatient, you can skip straight to my > proposed patch [2]. > > The tl;dr summary is that I think with some small changes to manage.py > and the default project layout, we can fix some very common bugs and > deployment problems, dramatically reduce the extent to which manage.py > is "unknown magic" for newcomers to Django, and take a significant step > towards being "just a Python library." Pile on another +1 from me too. This looks like an extremely elegant solution to something that has been a wart for a long time. My only feedback on the patch is a point of clarification in the tutorial. Rather than creating a mysite directory with a mysite project directory in it, and then having to refer to the "inner/outer directory" or "the directory with manage.py in it", it strikes me that it might be cleaner to name the outer directory something generic (like "django_tutorial"). This reinforces that the outer directory name doesn't matter, and that startproject is only creating the inner directory. Other than that, it looks great to me. Russ %-) -- 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: Cleaning up manage.py and import paths
On Oct 11, 9:05 am, Carl Meyer wrote: > What's the impact on adding a standard WSGI entrypoint? > - --- > > #16360 [5] has a patch to add a "wsgi.py" file to the default project, > which will serve as a standard WSGI entrypoint that can be used both by > runserver and by production WSGI servers. I love the idea and the patch > - - except that its approach to easing the deployment path is to extend > the current sys.path-hacking of setup_environ beyond just manage.py and > into every WSGI deployment. > > But if we first fix the sys.path-hacking as I propose, the wsgi.py file > will go next to manage.py in the default project layout. Since WSGI > servers chdir() to the directory of the wsgi file you point them at, no > sys.path additions (whether manually or magically in Django) will be > needed in order to deploy a Django project under a production WSGI > server. Again, win. Apache/mod_wsgi does not change the current working directory to be where the WSGI file is located so that will not work for Apache/ mod_wsgi. A sys.path modification would still be need. Graham -- 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: #17028 - diveintopython.org links now dead
On Wed, Oct 12, 2011 at 5:37 PM, rikuthero...@gmail.com wrote: > Hello, > > As described on the ticket [1], it seems that diveintopython.org is dead, so > I changed every occurence for the mirror > http://diveintopython.nfshost.com/, that it seems to be the most updated. > The changes are on the patch attached in the ticket [2]. > > Best regards > > [1] https://code.djangoproject.com/ticket/17028 > [2] > https://code.djangoproject.com/attachment/ticket/17028/diveintopython_mirror_doc.patch > > -- > Pablo Recio Quijano Hi Pablo, Thanks for your recent work on patches for Django. However, as it notes in the last bullet point in the contribution guide about reporting bugs [1] -- you don't have to post to Django-developers just to tell us that you've added a patch. Anyone interested in watching for new patches can subscribe to django-updates and get automatically notified of *all* updates to Trac. The only reason to post to Django-dev is if you're looking for specific guidance on a patch -- for example, if you need confirmation that you''re taking the right approach in a fix, advice on where to put tests, and so on. Keep up the great contributions! [1] https://docs.djangoproject.com/en/1.3/internals/contributing/#reporting-bugs Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Cleaning up manage.py and import paths
I suggest naming it src, and then having example.com - contrib - docs - public - src - manage.py - myapp - __init__.py - settings.py - urls.py - virtualenv -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/PbsyqJj4jOcJ. 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: #17028 - diveintopython.org links now dead
Hello, Sorry, it seems that I miss that last point. I'll try to re-read the contribution docs and work better in the proper way. Thanks and sorry again. 2011/10/12 Russell Keith-Magee > On Wed, Oct 12, 2011 at 5:37 PM, rikuthero...@gmail.com > wrote: > > Hello, > > > > As described on the ticket [1], it seems that diveintopython.org is > dead, so > > I changed every occurence for the mirror > > http://diveintopython.nfshost.com/, that it seems to be the most > updated. > > The changes are on the patch attached in the ticket [2]. > > > > Best regards > > > > [1] https://code.djangoproject.com/ticket/17028 > > [2] > > > https://code.djangoproject.com/attachment/ticket/17028/diveintopython_mirror_doc.patch > > > > -- > > Pablo Recio Quijano > > Hi Pablo, > > Thanks for your recent work on patches for Django. > > However, as it notes in the last bullet point in the contribution > guide about reporting bugs [1] -- you don't have to post to > Django-developers just to tell us that you've added a patch. Anyone > interested in watching for new patches can subscribe to django-updates > and get automatically notified of *all* updates to Trac. > > The only reason to post to Django-dev is if you're looking for > specific guidance on a patch -- for example, if you need confirmation > that you''re taking the right approach in a fix, advice on where to > put tests, and so on. > > Keep up the great contributions! > > [1] > https://docs.djangoproject.com/en/1.3/internals/contributing/#reporting-bugs > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-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. > > -- Pablo Recio Quijano -- 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.
Towards a more friendly NoReverseMatch
It would be really good if we could improve the errors provided when
Django can't do reverse().
For example:
>>> reverse('i_dont_exist')
NoReverseMatch: Reverse for 'i_dont_exist' with arguments '()' and
keyword arguments '{}' not found.
In this case, it would be nicer to have something like:
NoURLPattern: No patterns specified for 'i_dont_exist'.
Alternatively, if NoReverseMatch listed the patterns it tried (similar
to template loader post-mortem given on TemplateDoesNotExist which
shows the folders tried) then a new error message would be
unnecessary:
NoReverseMatch: Reverse for 'i_dont_exist' with arguments '()' and
keyword arguments '{}' not found (patterns tried: []).
As for regex patterns that can't be reversed, it would nice to improve
the errors or improve the docs. The docs state that:
> The main restriction at the moment is that the pattern cannot contain
> alternative choices using the vertical bar ("|") character.
Upon reading this, I expected that Django would warn me if I tried to
reverse a pattern with a '|' in it. However, it's sometimes possible
url(r'^fruit/(bananas|apples)$', some_view, name='fruit'),
>>> reverse('fruit', args=['bananas'])
'/fruit/bananas'
There's also the issue that there are other ways of expressing
alternatives that produce NoReverseMatch, although the docs don't
really say that these are problematic:
url(r'^fruit(/location/(?P[a-z]+))?(/name/(?
P[a-z]+)/)?$', some_view,
name='fruit_with_alternative_groups'),
>>> reverse('fruit_with_alternative_groups', kwargs={'location':
'london', 'name': 'apples'})
NoReverseMatch: Reverse for 'fruit_with_alternative_groups' with
arguments '()' and keyword arguments '{'location': 'london', 'name':
'apples'}' not found.
It would be great for the error to mention that I've used '?' which
stopped reversing working. Sure, I could have multiple URL patterns
named 'fruit_with_alternative_groups', but if there's only one (or all
the patterns have this problem) then we could be more helpful.
TL;DR:
1. It'd be nice to know how many patterns were tried by reverse().
2. It'd be nice to get a warning when users try to reverse patterns
that contain alternatives with '?' or '?' (or others).
3. It'd be good to clarify the docs as to what patterns are
reversible.
Thoughts? I'll open bugs, whip up a patch or two if people are
interested.
--
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: Cleaning up manage.py and import paths
On Mon, Oct 10, 2011 at 3:05 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 ... > 2. People write code that imports things inconsistently (sometimes with > the project prefix, sometimes without it), and then when they go to > deploy (without manage.py or setup_environ), their imports break and > they don't understand why. This comes up frequently in #django. In order > to fix it they either have to make all their imports consistent, or add > both the inner and outer directories to sys.path/PYTHONPATH in their > deployment setup. Inconsistent imports should fail fast, not when you > move to production. If anyone is interested in this specific problem, I've written a script to highlight places your sys.path allows aliasing of modules: https://gist.github.com/857091 -- 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: Cleaning up manage.py and import paths
On Tue, Oct 11, 2011 at 9:05 AM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > In the spirit of making Django behave better as a Python library (c.f. > Glyph's keynote at djangocon.us), I'd like to finally tackle removing > the sys.path hacks in django.core.management.setup_environ. I'll give > the full detailed rundown here on the current behavior and how I propose > to change it. Fortunately, the fix isn't that complicated, and I think > it's a no-brainer. For the impatient, you can skip straight to my > proposed patch [2]. > > The tl;dr summary is that I think with some small changes to manage.py > and the default project layout, we can fix some very common bugs and > deployment problems, dramatically reduce the extent to which manage.py > is "unknown magic" for newcomers to Django, and take a significant step > towards being "just a Python library." > > This issue is tracked in ticket #15372 [1], though there's a lot more > detailed info in this message than on that ticket. > > The problem > === > > Right now "django-admin.py startproject mysite" generates this: > > mysite/ > __init__.py > manage.py > settings.py > urls.py > > This layout is the root of the problem, because it commingles manage.py > (a command-line script entry point that should not be imported) with > importable modules inside a package. > > When Python runs a command-line script it puts the script's directory > onto sys.path (even if you run "python /full/path/to/mysite/manage.py" > from somewhere else entirely). So with this layout, via manage.py, > "import settings" and "import urls" will both work, and if we add any > other modules or packages to this directory, they are also importable as > top-level modules/packages. This is a standard feature of Python. > > But "mysite" is a package, and Django wants us to be able to import > "mysite.settings" and "mysite.urls" (in fact, the latter is the default > ROOT_URLCONF setting). In order to make that possible, setup_environ > does some magic: it finds the parent directory of "mysite", temporarily > adds it to sys.path, imports mysite, and then reverts sys.path. Now we > can either "import settings" or "import mysite.settings", and both will > work. Same is true for any other modules or packages (e.g. apps) we add > under mysite/. How nice! > > Not really. This bit of clever causes a boat-load of problems: > > 1. Python's importer doesn't know that the same module imported under > two different names is the same module, so it imports it twice. Which > means module-level code can run twice, which causes really confusing bugs. > > 2. People write code that imports things inconsistently (sometimes with > the project prefix, sometimes without it), and then when they go to > deploy (without manage.py or setup_environ), their imports break and > they don't understand why. This comes up frequently in #django. In order > to fix it they either have to make all their imports consistent, or add > both the inner and outer directories to sys.path/PYTHONPATH in their > deployment setup. Inconsistent imports should fail fast, not when you > move to production. > > 2a. Even worse, our tutorial now encourages people to make their imports > inconsistent! ROOT_URLCONF is "mysite.urls" but we tell people to use > just "polls" rather than "mysite.polls" - so any tutorial-based project > now requires the double import paths in order to even run. > > 3. Since it's not obvious what Django is doing, people don't always > realize that the name of the outer directory matters, they think it's > just a container (which is what it ought to be). If they commit the > startproject layout at the top of a VCS repo, then check it out under a > different name, imports break. (If they check it out under a name that > isn't a valid Python module name, setup_environ breaks entirely). > > 4. The temporary addition to sys.path can cause unrelated packages > adjacent to the project to be imported, if the import of the project > module triggers an import of a name that happens to exist adjacent. This > is extremely difficult to track down; since Django restores sys.path, it > appears the adjacent package is somehow imported without even being on > sys.path. This can catch very experienced Python devs; I once spent an > hour on IRC working with Ned Batchelder to track this down in his project. > > 5. Understanding Python import paths is hard enough for beginners. The > Django tutorial could help them on the road to understanding, with no > loss in usability; pulling a trick like this behind the scenes helps > them stay confused instead. > > The solution > > > The key is to fix the "startproject" layout: > > mysite/ > manage.py > mysite/ > __init__.py > settings.py > urls.py > > The outer "mysite/" is now just a container, not a Python package. It > can be renamed without consequence. The inne
Re: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Alec, On 10/12/2011 06:38 AM, Alec Taylor wrote: > Backwards compatibility is easily solved, include an upgrade.py file > which is called if project rootfolder has settings.py. upgrade.py > would fix the directory structure Thanks for the suggestion! I don't think it's quite that simple, as we can't assume that every upgrading project has maintained exactly the default startproject layout - I think quite a significant percentage don't. And we also don't know which style of import the project is using (with or without project prefix) for various things, and inconsistent imports would be tricky to fix automatically. We need to provide migration help for all projects that currently work, not just for the previous default layout. I think we're better off carefully documenting how the location of things in the new setup determines how they can be imported, and letting projects make the necessary changes themselves, rather than trying to provide an upgrade script that isn't likely to have a real high success rate. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VjcUACgkQ8W4rlRKtE2fRqACeOAL+Etvd2n2IqyV/aUVPQ4EY 09wAoJqbQ6NcCH0QD46zE8q/pRCUE1Ad =D0va -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-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: Update on Ticket #16891: Delete/update should return number of rows modified
On Oct 12, 1:37 pm, Johannes Dollinger wrote: > Ticket #12086 is a duplicate. I don't think QuerySet.delete() should return > the number of all collected objects, but just the number of objects deleted > from QuerySet.model. Agree. A way to get the counts per object type would be useful (logging for starters). It should not be the default return value, though... > And Model.save()/Model.delete() should really only return 1, as *one object* > has been saved/deleted, even if more than one database row was touched. Thus, > both methods don't need the return value. Model.delete() can easily return 0. The easiest way to get 0 is doing the delete two times in a row. Or having a concurrent delete. The return value costs us nothing, except if for some reason we would want to return something else from .delete() in the future. I don't see that happening. Model.save() should return models.UPDATED or models.INSERTED. That is more helpful than the 1/0 return value. For example you might want to do different things if the model was inserted or updated in application code. Or if loading data from a file, you might want to know how many objects already existed in the DB and how many were inserted. Of course if you could cheaply get models.UNCHANGED, that would make the feature perfect... I agree that model.save() should never return 0/None/models.NOACTION, that should be an exception instead of a return value. After .save() the model should exists in the database. If the object for some reason isn't persisted, it is worth an exception instead of easy to miss return value. - Anssi Kääriäinen -- 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: Cleaning up manage.py and import paths
Moving the manage.py is a great move. Post 1.4 you actually might want to think a bit about integrating a distutils2 setup.cfg into the manage.py folder and the startproject command. Since distutils2 will be the standard in python3.3 for packaging and backported to python 2.5 it makes sense to leverage it for Django. At the very least the setup.cfg could provide the DJANGO_SETTINGS_MODULE env variable for installation scripts as a custom meta-data variable that an installation script could do something with. It will probably be good practice to setup a minimal setup.cfg file anyway with the project name. My thoughts are that the whole Django project structure existed as a way to get started quickly, and people replicated it on servers because python packaging sucked. Hopefully distutils2 will make it suck a little less and make it feasible to make Django play nicely with it. Brett H -- 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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Karen, On 10/11/2011 06:21 PM, Karen Tracey wrote: > One thing that I think should be added before commit is a note in the > tutorial along the lines of "what if startproject didn't actually do > what we are saying it did?" and explaining that the structure has > recently changed and if you didn't get the structure described here than > you are likely using an older version of the code than the documentation > you are reading and you should get the two in sync. > > This was done back in the day of changing maxlength to max_length, and > that note stayed in the tutorial a laughably long time after the change > was no longer "recent", but it likely prevented lots of questions and > duplicate bug reports about the tutorial being wrong. Interesting, I didn't realize we had precedent for doing that explicitly. I've added just such a note to the patch, thanks for the suggestion. Perhaps we should have done this for the "from django.conf.urls import url, patterns" change, too :-) Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Vk5wACgkQ8W4rlRKtE2c8qACfZwIXGuXrm8gxrnV/aPCqXJlr UY8AoKt21Fh167sZfiZdy5O82iL07z5N =POwS -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-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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Russ, On 10/12/2011 05:14 AM, Russell Keith-Magee wrote: > My only feedback on the patch is a point of clarification in the > tutorial. Rather than creating a mysite directory with a mysite > project directory in it, and then having to refer to the "inner/outer > directory" or "the directory with manage.py in it", it strikes me that > it might be cleaner to name the outer directory something generic > (like "django_tutorial"). This reinforces that the outer directory > name doesn't matter, and that startproject is only creating the inner > directory. So the repeated directory name does make the tutorial wording slightly clumsy (though I don't think it's much of a problem otherwise). The issue is that startproject _does_ in fact create both the outer and inner directory; and I think it must do so, else its creating a manage.py in the current directory, and we have to explicitly tell people "first create an empty directory, then run startproject inside of it" - I don't think that's a good plan. I toyed with ideas like allowing startproject to take two arguments instead of one, or allowing its argument to be an invalid Python module name, using that for the outer directory, and then doing an automatic slugify-like conversion to a valid Python module name for the inner directory. In the end I decided it was simplest to just live with the repeated directory name. I suppose the one other thing we could do is explicitly have the user rename the outer directory in the tutorial? This doesn't really seem worth it, though... Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VlOAACgkQ8W4rlRKtE2fWywCfZ/Lzj2F4AGUn6l4xo4rB1YTg bkgAniAMyoP/S1zUUILEUKBeyVGgyhaZ =m891 -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-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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Graham, On 10/12/2011 05:16 AM, Graham Dumpleton wrote: > Apache/mod_wsgi does not change the current working directory to be > where the WSGI file is located so that will not work for Apache/ > mod_wsgi. A sys.path modification would still be need. Thanks for the correction, sorry to misinform. I'll make sure the Apache/mod_wsgi docs are correct on this point when I update the patch for #16360. Adding one directory to sys.path is still better than adding two! Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VlUEACgkQ8W4rlRKtE2flQwCgneEzv5tiKGPajdewDzUE4CpR WFsAn394n7mUkP9xlOwkmslyufKKDdmM =ja+f -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-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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mateusz, On 10/12/2011 05:20 AM, Mateusz Harasymczuk wrote: > I suggest naming it src, and then having > > example.com > - contrib > - docs > - public > - src > - manage.py > - myapp > - __init__.py > - settings.py > - urls.py > - virtualenv Thanks for the suggestion. I think this is out of scope for this patch. I'm not opposed to further discussion of startproject enhancements and additions, though I think we're going to have a hard time reaching consensus on exactly what should be added and how, which is a good argument for keeping it minimal. In any case, my goal at this point is to make the minimal change necessary to fix the path issues. The good news is that if you like this layout, it's trivial to create it for your project using the new startproject, since you just create your outer directories and move the result of startproject to src/. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VliYACgkQ8W4rlRKtE2d8/gCgzLVm8Ua/657FT0lz3L/HZLnN YSAAn3TmCJS0Gm83wtvzJB73w+paUyfh =84Ok -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-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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brett, On 10/12/2011 07:11 AM, Brett H wrote: > Post 1.4 you actually might want to think a bit about integrating a > distutils2 setup.cfg into the manage.py folder and the startproject > command. Oh, I certainly have thought about it :-) A number of people, myself included, have played around with making projects installable, which is an even more thorough solution to making sure its on sys.path properly. Without that, we're still depending on either using an entrypoint script in the correct directory, having the correct directory be the CWD, or using PYTHONPATH or equivalent. Currently, the main difficulty with installable projects is that it's hard to do properly, because projects typically rely on a large number of templates and static assets, and today in distutils/setuptools it's quite painful to get all those listed correctly in your setup.py so they'll be installed. I think a lot of people doing "installable projects" just punt on that and install --editable and/or reference static assets and templates from the original checkout rather than an installed location. This is a bit janky, since normally when a Python package is installed you expect it to come with everything it needs, and not still be relying on stuff from the installation source. With distutils2 it should be much easier to do it right, and I'm certainly interested in the idea of adding a setup.cfg to the startproject layout, and possibly as an option to startapp as well. I think we should wait to make this move until distutils2 has seen some adoption and the initial warts are hammered out, though - so hopefully some time late next year? Even that might be optimistic. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VmHEACgkQ8W4rlRKtE2f/BACgg/VLBmQEghsgTAOHIRPf4it8 YXkAoNVNYSFPf2O6wd7yoHFS9uTpRbcg =MqHe -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-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: Update on Ticket #16891: Delete/update should return number of rows modified
It is for now, but the ticket I'm building up to [1] is that it may actually be 0 if a precondition is not met. This is how your code can know if the current request really got to do a save or delete if two or more are trying to update the object at the same time. [1] https://code.djangoproject.com/ticket/16549 -- Steven On Wed, Oct 12, 2011 at 4:28 AM, Florian Apolloner wrote: > Uhm question -- Does the count for Model.save() make any sense? Isn't that > always one? > > Cheers, > Florian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/rpkcIupLI9gJ. > 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: Update on Ticket #16891: Delete/update should return number of rows modified
-- Steven On Wed, Oct 12, 2011 at 5:37 AM, Johannes Dollinger wrote: > > Am 12.10.2011 um 03:35 schrieb Steven Cummings: > > Ticket #12086 is a duplicate. I don't think QuerySet.delete() should return > the number of all collected objects, but just the number of objects deleted > from QuerySet.model. > Is the idea that you should just assume related objects are deleted, and so the count should just reflect the current set of top-level objects in the QuerySet? I ask because I'm actually not sure about this one myself. And Model.save()/Model.delete() should really only return 1, as *one object* > has been saved/deleted, even if more than one database row was touched. > Thus, both methods don't need the return value. > See my response to Florian. The result may not always be one after further enhancements. > Thanks for working on this! > __ > Johannes > > -- > 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: Update on Ticket #16891: Delete/update should return number of rows modified
-- Steven On Wed, Oct 12, 2011 at 8:07 AM, Anssi Kääriäinen wrote: > > Model.save() should return models.UPDATED or models.INSERTED. That is > more helpful than the 1/0 return value. For example you might want to > do different things if the model was inserted or updated in > application code. Or if loading data from a file, you might want to > know how many objects already existed in the DB and how many were > inserted. Of course if you could cheaply get models.UNCHANGED, that > would make the feature perfect... > If you're ensuring a set of data from some other source, what's the use of knowing what was new? Are there other concrete cases where this might be useful? > > I agree that model.save() should never return 0/None/models.NOACTION, > that should be an exception instead of a return value. After .save() > the model should exists in the database. If the object for some reason > isn't persisted, it is worth an exception instead of easy to miss > return value. > Possibly, but an exception cannot be added until the programmer is passing a precondition and can reasonable expect the condition of nothing being saved. That's definitely not on this ticket. > > - Anssi Kääriäinen > > -- > 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: Cleaning up manage.py and import paths
On Wed, Oct 12, 2011 at 9:23 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Russ, > > On 10/12/2011 05:14 AM, Russell Keith-Magee wrote: >> My only feedback on the patch is a point of clarification in the >> tutorial. Rather than creating a mysite directory with a mysite >> project directory in it, and then having to refer to the "inner/outer >> directory" or "the directory with manage.py in it", it strikes me that >> it might be cleaner to name the outer directory something generic >> (like "django_tutorial"). This reinforces that the outer directory >> name doesn't matter, and that startproject is only creating the inner >> directory. > > So the repeated directory name does make the tutorial wording slightly > clumsy (though I don't think it's much of a problem otherwise). The > issue is that startproject _does_ in fact create both the outer and > inner directory; and I think it must do so, else its creating a > manage.py in the current directory, and we have to explicitly tell > people "first create an empty directory, then run startproject inside of > it" - I don't think that's a good plan. I'm not convinced it's a bad idea. From an pedagogical perspective, it's easy to explain -- Make a directory to contain all the bits for your project, move into the directory, then bootstrap your project. My only hesitation about this is that startproject wouldn't be namespacing it's own output -- this is akin to the problem of zip/tar files dumping their contents into the current working directory. However, we're only dropping 1 file -- manage.py -- and if overwriting manage.py is a concern, we could put protections on startproject so that it only runs on an empty directory (unless you specify a --force option or similar). > I toyed with ideas like allowing startproject to take two arguments > instead of one, or allowing its argument to be an invalid Python module > name, using that for the outer directory, and then doing an automatic > slugify-like conversion to a valid Python module name for the inner > directory. In the end I decided it was simplest to just live with the > repeated directory name. Agreed that extra arguments aren't needed. Duplicating the directory name is weird, but it's a one time thing, and can be easily renamed. > I suppose the one other thing we could do is explicitly have the user > rename the outer directory in the tutorial? This doesn't really seem > worth it, though... Yeah - this doesn't sound worth it. The only upside I can see is that it would really drive home the fact that it doesn't matter what the top level directory is called. However, it's something that we'd be teaching users to do for no reason other than to not confuse them -- but by putting it in the tutorial, it becomes "best practice". In the long run, it's probably better to avoid doing things like this. Russ %-) -- 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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/2011 07:53 AM, Russell Keith-Magee wrote: > I'm not convinced it's a bad idea. From an pedagogical perspective, > it's easy to explain -- Make a directory to contain all the bits for > your project, move into the directory, then bootstrap your project. It's not so easy to explain why startproject can't just create the directory to contain all the bits it creates in the first place, instead of making me do it manually :-) I really do think dumping non-namespaced bits in the current directory is a serious usability problem for a utility like startproject, even if we tried to implement some kind of "manage.py overwriting protection". It's also a much more significant departure from how you use startproject currently. And if the only justification is "well, it makes it very slightly easier for the tutorial to explain which directory you should be in to do certain things" - I just don't see that as a good tradeoff, at all. I think the current tutorial wording in the patch is plenty clear, if slightly awkward. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VnvwACgkQ8W4rlRKtE2ehUwCeKyy0lSw9GCmTSczn46pXkD6F HVkAmwZNV7bsuWJOpxQ+E0ChoCegroDc =bOma -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-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: Towards a more friendly NoReverseMatch
On Wed, Oct 12, 2011 at 12:56 PM, Wilfred Hughes
wrote:
> It would be really good if we could improve the errors provided when
> Django can't do reverse().
>
> For example:
>
> >>> reverse('i_dont_exist')
> NoReverseMatch: Reverse for 'i_dont_exist' with arguments '()' and
> keyword arguments '{}' not found.
>
> In this case, it would be nicer to have something like:
>
> NoURLPattern: No patterns specified for 'i_dont_exist'.
>
Just on this point, I must disagree. For instance, consider if you
have a URL named 'i_dont_exist', and the URL pattern has two
positional arguments. If I attempted to reverse() that name, but don't
supply the required arguments, then the existing error clearly
explains why no match was found - there were no arguments passed.
The proposed error message would not explain why, and would be
misleading - there is a URL pattern, but it is not applicable without
additional arguments.
The most common time I encounter this is when using {% url %} in a
template. You pass in the appropriate positional/named arguments, but
if the variables you pass in don't correspond to valid variables, you
don't want to be told that the reason it couldn't reverse the URL was
because there was no such pattern.
Cheers
Tom
--
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: Update on Ticket #16891: Delete/update should return number of rows modified
On Oct 12, 4:47 pm, Steven Cummings wrote: > If you're ensuring a set of data from some other source, what's the use of > knowing what was new? Are there other concrete cases where this might be > useful? The standard use when synchronizing data is to make sure there aren't too many changes. This is to protect for corrupted data. For example if more than 10% of the data changed, then rollback the action. Send an email to administrator who needs to validate the changes by had. Granted, without models.UNCHANGED this use case has limited value. Another use case is overriding model.save(), and based on the action you might want to create an entry in another table. Something like when saving User, if the user was created, then save a Profile for him. Or just displaying "The object was successfully created"/"The object was successfully updated" to the user. This would be more useful even in manage.py shell: >>> someobj.save() INSERTED >>> someobj.save() UPDATED vs. >>> someobj.save() 1 >>> someobj.save() 1 Then there is the possibility that some day we could support the UNCHANGED return value. This would be actually cheap to do if Django would support update of only changed fields. We couldn't support that return value if the only choices would be just 1/0 return values. One way to see that there might be some uses for this, is that post_save does have a created argument. And then there is the question that what does this cost Django? The only cost I can see is that you can't do save_count += obj.save() but you need to do save_count += obj.save() and 1 or 0. > > I agree that model.save() should never return 0/None/models.NOACTION, > > that should be an exception instead of a return value. After .save() > > the model should exists in the database. If the object for some reason > > isn't persisted, it is worth an exception instead of easy to miss > > return value. > > Possibly, but an exception cannot be added until the programmer is passing a > precondition and can reasonable expect the condition of nothing being saved. > That's definitely not on this ticket. Agreed. The only question is: If we don't want to support the models.UPDATED / models.INSERTED return values, and we decide that 0 should not be ever returned, then why return the 1? That will be a return value of no information. If you are not going to do the models.UPDATED/INSERTED return value, then using up the .save() return value should not be done at this time. We can't change the return value at will, so we should not commit to something which doesn't have any use now, and might not have any use ever. - Anssi -- 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: Cleaning up manage.py and import paths
On 12/10/11 15:06, Carl Meyer wrote: > > > On 10/12/2011 07:53 AM, Russell Keith-Magee wrote: >> I'm not convinced it's a bad idea. From an pedagogical perspective, >> it's easy to explain -- Make a directory to contain all the bits for >> your project, move into the directory, then bootstrap your project. > > It's not so easy to explain why startproject can't just create the > directory to contain all the bits it creates in the first place, instead > of making me do it manually :-) I think there could be at least one good reason - if the developer has already created a directory in which to store all the stuff, which would actually be my natural instinct especially when it comes to a new project with VCS: $ mkdir foo $ cd foo $ hg init # OK, now what am I going to put in it? Oh, a Django project. In fact, it might be good idea to encourage use of VCS by mentioning it. If I remember SVN correctly, you would actually need to think about it before 'mkdir foo' - you 'svnadmin create', then checkout the empty repo to start working. For either of these workflows, you probably wouldn't want startproject creating your main directory. I actually like the idea that Django is not supposed to be managing your entire project - rather, your project uses Django. Luke -- "Oh, look. I appear to be lying at the bottom of a very deep, dark hole. That seems a familiar concept. What does it remind me of? Ah, I remember. Life." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- 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: Cleaning up manage.py and import paths
+1 mkdir project cd project git init django-admin.py startproject project Is basically what I already do, and either way it's not terrible hard to switch, but I think it makes a lot of sense to use CWD as the top level directory. On Wednesday, October 12, 2011 at 10:59 AM, Luke Plant wrote: > On 12/10/11 15:06, Carl Meyer wrote: > > > > > > On 10/12/2011 07:53 AM, Russell Keith-Magee wrote: > > > I'm not convinced it's a bad idea. From an pedagogical perspective, > > > it's easy to explain -- Make a directory to contain all the bits for > > > your project, move into the directory, then bootstrap your project. > > > > > > > > > It's not so easy to explain why startproject can't just create the > > directory to contain all the bits it creates in the first place, instead > > of making me do it manually :-) > > > > > I think there could be at least one good reason - if the developer has > already created a directory in which to store all the stuff, which would > actually be my natural instinct especially when it comes to a new > project with VCS: > > $ mkdir foo > $ cd foo > $ hg init > > # OK, now what am I going to put in it? Oh, a Django project. > > In fact, it might be good idea to encourage use of VCS by mentioning it. > If I remember SVN correctly, you would actually need to think about it > before 'mkdir foo' - you 'svnadmin create', then checkout the empty repo > to start working. For either of these workflows, you probably wouldn't > want startproject creating your main directory. I actually like the idea > that Django is not supposed to be managing your entire project - rather, > your project uses Django. > > Luke > > -- > "Oh, look. I appear to be lying at the bottom of a very deep, dark > hole. That seems a familiar concept. What does it remind me of? Ah, > I remember. Life." (Marvin the paranoid android) > > Luke Plant || http://lukeplant.me.uk/ > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Luke, On 10/12/2011 08:59 AM, Luke Plant wrote: >> It's not so easy to explain why startproject can't just create the >> directory to contain all the bits it creates in the first place, instead >> of making me do it manually :-) > > I think there could be at least one good reason - if the developer has > already created a directory in which to store all the stuff, which would > actually be my natural instinct especially when it comes to a new > project with VCS: > > $ mkdir foo > $ cd foo > $ hg init > > # OK, now what am I going to put in it? Oh, a Django project. In a real project, I think a layout more similar to what Mateusz suggested is better - there should actually be a third containing directory outside anything startproject creates, in which you put all the non-Python stuff (including templates). This is what I generally do - - I consider it preferable to keep non-Python stuff out of directories that are on sys.path. In which case that outer directory would be the one you initially create yourself. This (and VCS considerations) are a topic for that "project layout" docs page, which can be added separately. I don't think we need to add more stuff to the first page of the tutorial - and even if some people want to, it doesn't need to happen in this patch. > In fact, it might be good idea to encourage use of VCS by mentioning it. > If I remember SVN correctly, you would actually need to think about it > before 'mkdir foo' - you 'svnadmin create', then checkout the empty repo > to start working. For either of these workflows, you probably wouldn't > want startproject creating your main directory. I actually like the idea > that Django is not supposed to be managing your entire project - rather, > your project uses Django. Right. I think the stuff that startproject currently creates in my patch is just the "Django stuff", not your entire project - and that that "Django stuff" should be self-contained in a directory, and startproject should create it that way. The other non-Django/non-Python bits of your project should go outside that. I'm pretty strongly opposed to any change that involves startproject dumping files directly into the current directory, not inside a container that you provide the name for. That's just bad behavior, IMO. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VrvMACgkQ8W4rlRKtE2ebTACfS8KNH+Zj7U5P9EYD+S6sfXag jtMAoMyu5/sA4sTIzqcRgeuw5fmc6HzL =08bN -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-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: Cleaning up manage.py and import paths
Hmm, well maybe we need to survey current structures, I'd expect some constant (i.e. the settings.py file) On Wed, Oct 12, 2011 at 11:53 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Alec, > > On 10/12/2011 06:38 AM, Alec Taylor wrote: >> Backwards compatibility is easily solved, include an upgrade.py file >> which is called if project rootfolder has settings.py. upgrade.py >> would fix the directory structure > > Thanks for the suggestion! I don't think it's quite that simple, as we > can't assume that every upgrading project has maintained exactly the > default startproject layout - I think quite a significant percentage > don't. And we also don't know which style of import the project is using > (with or without project prefix) for various things, and inconsistent > imports would be tricky to fix automatically. We need to provide > migration help for all projects that currently work, not just for the > previous default layout. > > I think we're better off carefully documenting how the location of > things in the new setup determines how they can be imported, and letting > projects make the necessary changes themselves, rather than trying to > provide an upgrade script that isn't likely to have a real high success > rate. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6VjcUACgkQ8W4rlRKtE2fRqACeOAL+Etvd2n2IqyV/aUVPQ4EY > 09wAoJqbQ6NcCH0QD46zE8q/pRCUE1Ad > =D0va > -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-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: Towards a more friendly NoReverseMatch
> > >>> reverse('i_dont_exist')
> > NoReverseMatch: Reverse for 'i_dont_exist' with arguments '()' and
> > keyword arguments '{}' not found.
>
> > In this case, it would be nicer to have something like:
>
> > NoURLPattern: No patterns specified for 'i_dont_exist'.
>
> Just on this point, I must disagree. For instance, consider if you
> have a URL named 'i_dont_exist', and the URL pattern has two
> positional arguments.
Ah, sorry. I've been unclear. My point here is that when there /isn't/
a URL with that name. It would be good to distinguish between having
no regexes and not being able to reverse the regex.
So, if I have an URL:
url(r'^fruit/(bananas|apples)$', some_view, name='fruit'),
And I make a spelling mistake:
>>> reverse('rfuit', args=['bananas'])
I would like some hint that the problem isn't in my regex. The two
options I'm proposing are:
NoURLPattern: No patterns specified for 'rfuit'.
Or:
NoReverseMatch: Reverse for 'rfuit' with arguments '()' and
keyword arguments '{}' not found (patterns tried: []).
--
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: Cleaning up manage.py and import paths
Carl, why not have django-admin.py startproject create a site_root directory and within it a project_root directory by default if issued from within e.g. example.com (the outermost container/directory e.g. a virtualenv): example.com <-- mkvirtualenv example.com; non-Python stuff somehow related to this project sass tmp gems ... site_root<-- django-admin.py startproject; on sys.path from here down; Python stuff .git <-- git init (or hg init or whatever) .gitignore manage.py sqlite3db ... project_root <-- django-admin.py startproject; Django stuff specific to this project __init__.py settings.py urls.py ... django-admin.py startproject would create site_root and project_root put as this patch intends, one could always easily rename site_root to whatever he wants. example.com is entirely decoupled anyway and can be named anything. Maybe it is not bad having project_root as a fix name at this location in the filesystem tree as it makes it easy to reference things -- not just for people but also scripts and such. I am generally against to much rules/conventions but in this case I think having some fixed name at a fixed location would make things easier (even if it is just for new people to grasp things). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/pVCDd7qP2ucJ. 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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Markus, On 10/12/2011 10:30 AM, Markus Gattol wrote: > django-admin.py startproject would create site_root and project_root > put as this patch intends, one could always easily rename site_root to > whatever he wants. example.com is entirely decoupled anyway and can be > named anything. > > Maybe it is not bad having project_root as a fix name at this location > in the filesystem tree as it makes it easy to reference things -- not > just for people but also scripts and such. I am generally against to > much rules/conventions but in this case I think having some fixed name > at a fixed location would make things easier (even if it is just for > new people to grasp things). Since "project_root" is the actual importable Python package name, I don't think it's a good idea to have it be a fixed name; it should be an appropriately-chosen package name for each individual project. I guess we could consider always using the same name for the outer directory, but I think it's better to reuse the package name for that directory. It means you can run startproject twice from within the same directory without overwriting things, and I think it just makes intuitive sense that the output of startproject is a directory with the same name you just gave it. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VxIwACgkQ8W4rlRKtE2f9ggCeOgOpcbsGHw4h/zuUs9o5J8eV xA0AnisROi6OlHIRG2UR9MkWw7fWXDRs =f6cP -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-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: RFC: "universal" view decorators
Sorry for the delay, Here's a possible method of handling the idea of adding the additional functionality of things like requiring logins to both FBV's and CBV's in a way that I feel is consistent with the methodologies of each of those types (decorators for FBV, Mixins for CBV). This also keeps all the logic in one place. It allows for anyone (even people using FBV's) to easily extend the decorators and create their own versions of them, without having to rewrite the whole thing (which was one of the major reasons I like CBV's). It shouldn't break anything, the tests are passing and a functional test in a browser they all appear to be working. https://github.com/dstufft/django/compare/master...mixin-decorators Thoughts? Good Idea? Bad Idea? On Thursday, September 22, 2011 at 2:49 AM, ptone wrote: > > > On Sep 21, 8:44 am, Donald Stufft (http://gmail.com)> wrote: > > > > > > The goal is to provide a Mixin for class based views, a decorator for class > > based views, a decorator for methods, and a decorator for functions, all > > from the same codebase. > > > > Currently I have the decorator for classes working, and the mixin working. > > I have the places where the other 2 will go but from a combination of not > > being very good at decorators, and not feeling well I haven't finished it > > yet. > > I like the overall direction of this approach (mixin class as the root > container of functionality) - but a number of technical issues still > need to have a resolution demonstrated (ie the decorating function > behavior) > > One, perhaps pony, of a universal approach, would be to convert the > decorator kwargs into class attributes, so that they could be > overriden in subclasses of a decorated parent, something easy to do > with mixins as the starting point. > > Also on a somewhat related note, a better option for middleware > process_view to interact with class based views > > -Preston > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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: Cleaning up manage.py and import paths
On Oct 12, 7:59 am, Luke Plant wrote: > $ mkdir foo > $ cd foo > $ hg init > > # OK, now what am I going to put in it? Oh, a Django project. > > In fact, it might be good idea to encourage use of VCS by mentioning it. > If I remember SVN correctly, you would actually need to think about it > before 'mkdir foo' - you 'svnadmin create', then checkout the empty repo > to start working. For either of these workflows, you probably wouldn't > want startproject creating your main directory. I actually like the idea > that Django is not supposed to be managing your entire project - rather, > your project uses Django. > > Luke For a possible solution to this situation, I've put together a patch that allows startproject/startapp to write into an existing folder. That way, if you want to turn an existing folder into a project you can, otherwise the default outer directory will be created. https://code.djangoproject.com/ticket/17042 https://github.com/django/django/pull/65 -Preston -- 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: Cleaning up manage.py and import paths
Great job on getting the ball rolling on this, Carl! +1 on the whole idea Similar to what Russ and Luke are saying, I'd also prefer it if startproject dropped manage.py and the project Python package in the current working directory (with overwrite checks first). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/5PAROq593r4J. 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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chris, On 10/12/2011 05:28 PM, Chris Beaven wrote: > Great job on getting the ball rolling on this, Carl! > > +1 on the whole idea Thanks! > Similar to what Russ and Luke are saying, I'd also prefer it if > startproject dropped manage.py and the project Python package in the > current working directory (with overwrite checks first). I remain -1 on CWD pollution by default; I haven't yet seen any arguments in favor of it that I find even slightly convincing. As we just discussed on IRC, I'd be happier to have an optional second argument to startproject, if this is really an issue. If two arguments were given, the first would be the containing directory name (which could also be "."), and the second the package name. (Could also do it in the other order, but I think putting the containing directory first feels more natural, as it's "first" in the hierarchy). I'm also fine with ptone's patch to allow using an existing directory, which maybe addresses some of the same cases. I think either one of these should be done as a separate follow-on patch, though, as I think they are mostly-orthogonal new features for startproject, not closely related to the purpose of this patch. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6WLCAACgkQ8W4rlRKtE2fK7wCgqnSaF8lHx0/bKcSIb4ElYEJ4 hdsAn27cKx/j+m0prV9Kz8MptfQR2Dj+ =GUEr -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-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: Cleaning up manage.py and import paths
+1 on installing CWD. Integrates nicely with the virtualenvwrapper mkproject command. I have a much longer reasoning why startproject should not get into creating the outer folder which is effectively the distribution folder, and the domain of distribution packaging tools, so I'll follow this post up. On Oct 13, 11:09 am, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Chris, > > On 10/12/2011 05:28 PM, Chris Beaven wrote: > > > Great job on getting the ball rolling on this, Carl! > > > +1 on the whole idea > > Thanks! > > > Similar to what Russ and Luke are saying, I'd also prefer it if > > startproject dropped manage.py and the project Python package in the > > current working directory (with overwrite checks first). > > I remain -1 on CWD pollution by default; I haven't yet seen any > arguments in favor of it that I find even slightly convincing. > > As we just discussed on IRC, I'd be happier to have an optional second > argument to startproject, if this is really an issue. If two arguments > were given, the first would be the containing directory name (which > could also be "."), and the second the package name. (Could also do it > in the other order, but I think putting the containing directory first > feels more natural, as it's "first" in the hierarchy). > > I'm also fine with ptone's patch to allow using an existing directory, > which maybe addresses some of the same cases. > > I think either one of these should be done as a separate follow-on > patch, though, as I think they are mostly-orthogonal new features for > startproject, not closely related to the purpose of this patch. > > Carl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6WLCAACgkQ8W4rlRKtE2fK7wCgqnSaF8lHx0/bKcSIb4ElYEJ4 > hdsAn27cKx/j+m0prV9Kz8MptfQR2Dj+ > =GUEr > -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-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: RFC: "universal" view decorators
Definitely +1 on this idea. It seems to me like the cleanest solution yet proposed insofar as it provides the desired new functionality while requiring very little change for current code. Cheers, AT On Wed, Oct 12, 2011 at 5:31 PM, Donald Stufft wrote: > Sorry for the delay, > > Here's a possible method of handling the idea of adding the additional > functionality of things like requiring logins to both FBV's and CBV's in a > way that I feel is consistent with the methodologies of each of those types > (decorators for FBV, Mixins for CBV). > > This also keeps all the logic in one place. It allows for anyone (even > people using FBV's) to easily extend the decorators and create their own > versions of them, without having to rewrite the whole thing (which was one > of the major reasons I like CBV's). It shouldn't break anything, the tests > are passing and a functional test in a browser they all appear to be > working. > > https://github.com/dstufft/django/compare/master...mixin-decorators > > Thoughts? Good Idea? Bad Idea? > > On Thursday, September 22, 2011 at 2:49 AM, ptone wrote: > > > > On Sep 21, 8:44 am, Donald Stufft wrote: > > > > The goal is to provide a Mixin for class based views, a decorator for class > based views, a decorator for methods, and a decorator for functions, all > from the same codebase. > > Currently I have the decorator for classes working, and the mixin working. > I have the places where the other 2 will go but from a combination of not > being very good at decorators, and not feeling well I haven't finished it > yet. > > > I like the overall direction of this approach (mixin class as the root > container of functionality) - but a number of technical issues still > need to have a resolution demonstrated (ie the decorating function > behavior) > > One, perhaps pony, of a universal approach, would be to convert the > decorator kwargs into class attributes, so that they could be > overriden in subclasses of a decorated parent, something easy to do > with mixins as the starting point. > > Also on a somewhat related note, a better option for middleware > process_view to interact with class based views > > -Preston > > -- > 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. > -- 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: Cleaning up manage.py and import paths
Having reworked project structures so many times I think creating the outer folder 'site_root' with startproject is a bad idea. Making startproject install manage.py in the current working directory is the best transitional solution until distutils2 becomes stable. Even though distutils2 is not ready for primetime, by python convention the outer folder IS the source distribution folder. Django can have many sites under one project, so conceptually site_roots are just distributions. Having been stung with setup.py or any .py file being in the outer directory I believe ultimately manage.py should be deprecated post 1.4 since ultimately all it does is save 3 keystrokes, and deal with path issues that could go away when replaced with a setup.cfg file and appropriate meta-data to locate the settings.py. Ultimately distutils2 was accepted into Python 3.3 so it will be the standard for installation, and so the python way for creating distributions will be `pysetup.py create [distribution]`[http:// docs.python.org/dev/install/pysetup.html] Since distutils2 is meant to be extensible pretty much like Django management commands, you should probably be able to have a Django installed pysetup command so that `pysetup.py create-django [distribution] --project=[different project name]` extends the pysetup.py create command and also creates the project in the same step. Of course as I said - distutils2 is a way off being stable and backported, and the documentation is not good enough, despite making it into python 3.3 alpha, so if people wanted an interim solution then having an additional django command such as `django-admin.py createdist [distribution] --project=[alt project name]` that created a minimal distribution folder with setup.cfg (the most minimal required to package), manage.py, and project structure in one command would I think be one way to do it. Having a separate createdist command would I think also allow creating default folders for templates, static, and media as part of that distribution, since I think ultimately pysetup.py should be able to install that django project distribution on a server, and play nicely with other installation tools. Logically some of the meta information about project layout required for installation might conceivably move to setup.cfg while retaining settings.py for actual non file-location settings, but baby steps are good. Since people love inventing their own weird and wonderful ways to organise things, startproject should I think remain a much more minimalist command that just creates the minimum to get going, and doesn't preconceive whether or where someone wants to have a site_root, templates or a kitchen_sink folder (except for the new manage.py). I think it's important that Django focus on not creating a new wheel when a lot of people are already working on fixing the existing packaging & installation wheel in other forums. As I said previously, the historical reasons for how django deals with python paths and finding package directories is there because the python methods sucked, but really django projects are no more special than any other python distribution with metadata, packages, data, docs, scripts, and sources. Brett On Oct 13, 11:21 am, Brett H wrote: > +1 on installing CWD. Integrates nicely with the virtualenvwrapper > mkproject command. > > I have a much longer reasoning why startproject should not get into > creating the outer folder which is effectively the distribution > folder, and the domain of distribution packaging tools, so I'll follow > this post up. > > On Oct 13, 11:09 am, Carl Meyer wrote: > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > Hi Chris, > > > On 10/12/2011 05:28 PM, Chris Beaven wrote: > > > > Great job on getting the ball rolling on this, Carl! > > > > +1 on the whole idea > > > Thanks! > > > > Similar to what Russ and Luke are saying, I'd also prefer it if > > > startproject dropped manage.py and the project Python package in the > > > current working directory (with overwrite checks first). > > > I remain -1 on CWD pollution by default; I haven't yet seen any > > arguments in favor of it that I find even slightly convincing. > > > As we just discussed on IRC, I'd be happier to have an optional second > > argument to startproject, if this is really an issue. If two arguments > > were given, the first would be the containing directory name (which > > could also be "."), and the second the package name. (Could also do it > > in the other order, but I think putting the containing directory first > > feels more natural, as it's "first" in the hierarchy). > > > I'm also fine with ptone's patch to allow using an existing directory, > > which maybe addresses some of the same cases. > > > I think either one of these should be done as a separate follow-on > > patch, though, as I think they are mostly-orthogonal new features for > > startproject, not closely related to the purpose of this patch. > > > Carl
Re: Cleaning up manage.py and import paths
On 13/10/11 01:09, Carl Meyer wrote: >> Similar to what Russ and Luke are saying, I'd also prefer it if >> startproject dropped manage.py and the project Python package in the >> current working directory (with overwrite checks first). > > I remain -1 on CWD pollution by default; I haven't yet seen any > arguments in favor of it that I find even slightly convincing. Just to say that personally I'm not that bothered either way, I'm happy to let you paint this bike shed. Luke -- O'REILLY'S LAW OF THE KITCHEN Cleanliness is next to impossible. Luke Plant || http://lukeplant.me.uk/ -- 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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brett, On 10/12/2011 06:31 PM, Brett H wrote: > Having reworked project structures so many times I think creating the > outer folder 'site_root' with startproject is a bad idea. Making > startproject install manage.py in the current working directory is the > best transitional solution until distutils2 becomes stable. I do understand the desire to have startproject play nicely with other tools (like distutils2, or VCS') that may want to create an outer directory themselves. And I also understand that not everyone cares to keep the sys.path-added directory isolated from other things, so many people will want manage.py directly in the outermost containing directory. My concern is that the default behavior of startproject should do something that is experimentation-friendly and beginner-friendly, and I don't think dumping multiple things into the CWD is either of those. I think that you should be able to just try out startproject and get something sensible and workable right off the bat, without having to first understand distutils2 or why you should use a VCS, or read the docs carefully to find out that you really should create an outer directory yourself first manually before running it. So I think it makes sense to (as a separate feature) make startproject flexible enough to work with pre-existing directories, for more advanced users who want that flexibility, either via the two-argument extension or ptone's patch. But I still think the best default behavior is to contain all our output under a single provided name, not dump into the CWD. > Of course as I said - distutils2 is a way off being stable and > backported, and the documentation is not good enough, despite making > it into python 3.3 alpha, so if people wanted an interim solution then > having an additional django command such as `django-admin.py > createdist [distribution] --project=[alt project name]` that created a > minimal distribution folder with setup.cfg (the most minimal required > to package), manage.py, and project structure in one command would I > think be one way to do it. As I said before, I think that some type of Django integration with distutils2 is an interesting idea and worth exploring, but I think it belongs in third-party extensions for quite some yet before it should be considered in core. > I think it's important that Django focus on not creating a new wheel > when a lot of people are already working on fixing the existing > packaging & installation wheel in other forums. As I said previously, > the historical reasons for how django deals with python paths and > finding package directories is there because the python methods > sucked, but really django projects are no more special than any other > python distribution with metadata, packages, data, docs, scripts, and > sources. Hear hear! Couldn't agree more with all of this. The only part I don't understand is if you're drawing an equivalence between "startproject containing its output by default" and "Django creating a new wheel" - that seems like a bit of a stretch :-) Thanks for your thoughts! Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6WOQoACgkQ8W4rlRKtE2dR1wCfesxGqxvN1TOZIjJa16TO+5TY eBsAoJTOfucTz41agwkeDxMFCRAezqlb =fG0n -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-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: Update on Ticket #16891: Delete/update should return number of rows modified
On Wed, Oct 12, 2011 at 9:35 AM, Anssi Kääriäinen wrote: > On Oct 12, 4:47 pm, Steven Cummings wrote: > Then there is the possibility that some day we could support the > UNCHANGED return value. This would be actually cheap to do if Django > would support update of only changed fields. We couldn't support that > return value if the only choices would be just 1/0 return values. > Fair enough. That is an interesting possibility. > > I agree that model.save() should never return 0/None/models.NOACTION, > > > that should be an exception instead of a return value. After .save() > > > the model should exists in the database. If the object for some reason > > > isn't persisted, it is worth an exception instead of easy to miss > > > return value. > > > > Possibly, but an exception cannot be added until the programmer is > passing a > > precondition and can reasonable expect the condition of nothing being > saved. > > That's definitely not on this ticket. > > Agreed. The only question is: If we don't want to support the > models.UPDATED / models.INSERTED return values, and we decide that 0 > should not be ever returned, then why return the 1? That will be a > return value of no information. If you are not going to do the > models.UPDATED/INSERTED return value, then using up the .save() return > value should not be done at this time. We can't change the return > value at will, so we should not commit to something which doesn't have > any use now, and might not have any use ever. > Well, obviously I hope it does have use in the original ticket that spawned this one. I guess what I might need some help with here is: what are some of the directions of the ORM that might affect this decision. The reasons I stuck with counts across the board in this change were: 1. A uniform interface: object counts all the time for create/updated/delete. 2. Ready support for cascading updates if Model.save() were to ever trigger save() on related models that were dirty. Admittedly #2 is speculative, but so are the examples above of supporting update of only fields that have changed. So, is there a good sense of "sure" or "probable" enhancements to models that could help us with the return API of Model.save, and whether QuerySet.delete should return counts that include related objects? If "coming enhancements" or directions for Models can concretely inform, that would be great. Thoughts? -- Steven -- 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: Update on Ticket #16891: Delete/update should return number of rows modified
On Oct 13, 5:40 am, Steven Cummings wrote: [About the 1/0 return value of .save()] > Well, obviously I hope it does have use in the original ticket that spawned > this one. I guess what I might need some help with here is: what are some of > the directions of the ORM that might affect this decision. My point is that we should never just return 0 if there is a concurrent modification or some other reason for not being able to persist the object state. Why? When you request obj.save() you are requesting the object state to be persisted. If that can't be done, it's an exception. delete() does not have the same problem: if you do a delete, and the object is already deleted, then there is no problem. The DB state is still synchronized with the delete. The biggest problem of just returning 0 from the .save() on concurrent modification is that if the developer forgets to do if obj.save(): ... else: "show error" and instead does only a obj.save(), the application thinks the data was saved when in fact it was not. In the best case you will get an angry call from the user. Users don't like it when an application claims the data was saved but in fact it was not. In the worst case, you are doing other saves in the same request, and the state is half-persisted. Which is a data corruption bug right there. If instead .save() throws an exception, and the developer forgets to try-catch it, the user gets a 500 page. This is better than claiming the data was saved when it wasn't, and much better than doing a half- save. Also, if you just return 0, you will lose the information WHY the object couldn't be saved, you just know it wasn't saved for some reason. Another way to think about this: when there is a unique constraint violation, we raise an exception (the one from the DB backend). To be consistent with returning 0 when the object can't be saved due to some other reason, shouldn't we just catch that exception and return 0? Bad idea, right? > The reasons I stuck with counts across the board in this change were: > 1. A uniform interface: object counts all the time for > create/updated/delete. > 2. Ready support for cascading updates if Model.save() were to ever trigger > save() on related models that were dirty. > > Admittedly #2 is speculative, but so are the examples above of supporting > update of only fields that have changed. Agreed. Re point 1: An uniform interface would also be returning models.DELETED / models.ALREADY_DELETED(?) from .delete(). Granted, in the #1 case 0/1 makes more sense. I do see the problem with model.delete() returning a number, while model.save() returns a constant. > So, is there a good sense of "sure" or "probable" enhancements to models > that could help us with the return API of Model.save, and whether > QuerySet.delete should return counts that include related objects? If > "coming enhancements" or directions for Models can concretely inform, that > would be great. I don't think there is. For that reason I would just postpone the model.save() return value decision. I feel pretty strongly that model.save() should never return 0 in the meaning of "didn't save your changes" (note that this is different from "there were no changes"). It is just too easy to miss that return value and have half-done updates because of that. - Anssi Kääriäinen -- 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: Update on Ticket #16891: Delete/update should return number of rows modified
On Wed, Oct 12, 2011 at 11:51 PM, Anssi Kääriäinen
wrote:
>
>
> My point is that we should never just return 0 if there is a
> concurrent modification or some other reason for not being able to
> persist the object state. Why? When you request obj.save() you are
> requesting the object state to be persisted. If that can't be done,
> it's an exception. delete() does not have the same problem: if you do
> a delete, and the object is already deleted, then there is no problem.
> The DB state is still synchronized with the delete.
>
I'm not sure anybody said 0 would be returned for an *inability* to save
data. I would agree that would be an exception situation, but it hasn't been
discussed here yet.
>
> The biggest problem of just returning 0 from the .save() on concurrent
> modification is that if the developer forgets to do if obj.save(): ...
>
>
So the situation I expect this to occur in is the context of very deliberate
coding by the programmer, e.g.:
count = obj.save(where={'version': 1})
If the programmer forgets to check the count then they probably didn't
understand the feature being used to being with. I don't think this is going
to result in the accidents you're describing, because until there is a
specific feature context, save will return 1 (or whatever else we decide).
I've no intention of introducing implicit features or pitfalls.
>
> Also, if you just return 0, you will lose the information WHY the
> object couldn't be saved, you just know it wasn't saved for some
> reason.
> Another way to think about this: when there is a unique constraint
> violation, we raise an exception (the one from the DB backend). To be
> consistent with returning 0 when the object can't be saved due to some
> other reason, shouldn't we just catch that exception and return 0? Bad
> idea, right?
>
I generally agree with this, but as I stated above I've yet to discuss a
situation involving the inability to save. In the example so far the reason
for not saving is the condition given by the programmer. I won't be
swallowing any exceptions and returning zero, and if a coder chooses to
avoid saving on a version for optimistic concurrency, that is a decision,
not an inability.
> > So, is there a good sense of "sure" or "probable" enhancements to models
> > that could help us with the return API of Model.save, and whether
> > QuerySet.delete should return counts that include related objects? If
> > "coming enhancements" or directions for Models can concretely inform,
> that
> > would be great.
>
> I don't think there is. For that reason I would just postpone the
> model.save() return value decision. I feel pretty strongly that
> model.save() should never return 0 in the meaning of "didn't save your
> changes" (note that this is different from "there were no changes").
> It is just too easy to miss that return value and have half-done
> updates because of that.
>
I think a reasonable option to discuss might be leaving the save() API as it
is and rolling this enhancement back to the internal code (i.e.,
UpdateQuery, DeleteQuery) returning counts to support the prospective
enhancements I've alluded to, and/or overrides of save(). Until there are
any changes to save(), I agree it is not going to be useful info. However
for delete it seems immediately usable (and then we're left with the debate
of counting immediate-only or including related objects).
--
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: Update on Ticket #16891: Delete/update should return number of rows modified
On Oct 13, 8:33 am, Steven Cummings wrote:
> So the situation I expect this to occur in is the context of very deliberate
> coding by the programmer, e.g.:
>
> count = obj.save(where={'version': 1})
>
> If the programmer forgets to check the count then they probably didn't
> understand the feature being used to being with. I don't think this is going
> to result in the accidents you're describing, because until there is a
> specific feature context, save will return 1 (or whatever else we decide).
> I've no intention of introducing implicit features or pitfalls.
Ok, so if this is going to be low level API only, then this isn't as
dangerous as I though. Still, even in this case, an exception wouldn't
be any worse IMHO. You could always do try: obj.save() except
ConcurrentModification: pass.
Now I have the feeling that I have gone through this exact same
discussion before, and have had the exact same misunderstanding, too,
before. So, sorry for that...
> I think a reasonable option to discuss might be leaving the save() API as it
> is and rolling this enhancement back to the internal code (i.e.,
> UpdateQuery, DeleteQuery) returning counts to support the prospective
> enhancements I've alluded to, and/or overrides of save(). Until there are
> any changes to save(), I agree it is not going to be useful info. However
> for delete it seems immediately usable (and then we're left with the debate
> of counting immediate-only or including related objects).
I would go with immediate only, with the ability to get the counts for
cascaded deletes per object type as a kwarg option. The kwarg option
could be left for later implementation. One reason for immediate only
is that at least PostgreSQL and MySQL does it that way for ON DELETE
CASCADE foreign keys. So, if you are getting the value from the cursor
and using ON DELETE CASCADE instead of doing the cascade in Django,
you will not get the cascade counts anyways. And even if you do the
cascade in Django, then it would be consistent with what a SQL
database would report.
- Anssi Kääriäinen
--
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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just committed the patch as r16964 [1]. Yay! Follow-up to other issues discussed in this thread: * #17042 [2] is tracking enhancements to startproject to allow specifying the target container directory (including CWD), and allowing it to write into an existing directory. ptone already has good progress on a patch there. * I just filed #17044 [3], to track the idea of creating a "project layout and python path" page in the docs, where some of the issues discussed in this thread can be explained more fully. Thanks everyone for the feedback and discussion! Carl [1] https://code.djangoproject.com/changeset/16964 [2] https://code.djangoproject.com/ticket/17042 [3] https://code.djangoproject.com/ticket/17044 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6WhnwACgkQ8W4rlRKtE2eU5wCgvEd8YI4sXyZO8QJPyh6cStaV 1ecAn1pt7BySbBpUnE9saZkEzm+xOf55 =bIuA -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-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.
