ORAC
Hi there! I think I found a little bug in http://code.djangoproject.com/browser/django/trunk/django/db/backends/oracle/query.py#L132 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Error: cannot import name Xyz and --traceback option
Hi there,
today I've dealed with circural import (probably) located in project
i'm involved in. The message I got with enabled --traceback option
was:
jon...@mcf:~$ ./manage.py validate --traceback
"Error: cannot import name Listing"
...nothing more ( using Django version 1.1 beta 1 SVN-11250 ).
I think prefered output should look like this:
jon...@mcf:~$ ./manage.py validate --traceback
Error: cannot import name Listing
Traceback (most recent call last):
File "/home/jonson/pypath/django/core/management/base.py", line 214,
in execute
translation.activate('en-us')
File "/home/jonson/pypath/django/utils/translation/__init__.py",
line 73, in activate
return real_activate(language)
File "/home/jonson/pypath/django/utils/translation/__init__.py",
line 43, in delayed_loader
return g['real_%s' % caller](*args, **kwargs)
File "/home/jonson/pypath/django/utils/translation/trans_real.py",
line 205, in activate
_active[currentThread()] = translation(language)
File "/home/jonson/pypath/django/utils/translation/trans_real.py",
line 194, in translation
default_translation = _fetch(settings.LANGUAGE_CODE)
File "/home/jonson/pypath/django/utils/translation/trans_real.py",
line 180, in _fetch
app = import_module(appname)
File "/home/jonson/pypath/django/utils/importlib.py", line 35, in
import_module
__import__(name)
File "/home/jonson/pypath/ella/newman/__init__.py", line 5, in
from ella.newman.sites import site
File "/home/jonson/pypath/ella/newman/sites.py", line 17, in
from ella.core.models.publishable import Placement, Publishable
File "/home/jonson/pypath/ella/core/models/__init__.py", line 2, in
from publishable import *
File "/home/jonson/pypath/ella/core/models/publishable.py", line 13,
in
from ella.ellaadmin.utils import admin_url
File "/home/jonson/pypath/ella/ellaadmin/__init__.py", line 1, in
from ella.ellaadmin.sites import EllaAdminSite, site
File "/home/jonson/pypath/ella/ellaadmin/sites.py", line 11, in
from ella.ellaadmin.options import EllaAdminOptionsMixin
File "/home/jonson/pypath/ella/ellaadmin/options.py", line 10, in
from ella.ellaadmin import widgets, fields
File "/home/jonson/pypath/ella/ellaadmin/fields.py", line 12, in
from ella.core.templatetags.core import BoxNode,
ObjectNotFoundOrInvalid
File "/home/jonson/pypath/ella/core/templatetags/core.py", line 10,
in
from ella.core.models import Listing, Category,
LISTING_UNIQUE_DEFAULT_SET
ImportError: cannot import name Listing
With this ^^ output I'm able to find problem more quickly.
I'm not sure if this should be reported via ticket. I made a patch,
it's about three lines of code added to django.core.management.base
module ;-)
Thanks in advance,
Jonas
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
ORACLE QuerySet offset
Hi there! I think I found a little bug in http://code.djangoproject.com/browser/django/trunk/django/db/backends/oracle/query.py#L132 Offsetting the QuerySet (like qs[2:4]) on Oracle backend mixes the ordering in the final result set. Author claims that "This is the canonical way to emulate LIMIT and OFFSET on Oracle." but looking a bit through the web You can find that more popular (appropriate?) way is the RANK() OVER function (http://www.techonthenet.com/oracle/functions/rank.php) so instead SELECT ROWNUM AS "_RN" in line 132 I would write SELECT RANK() OVER(ORDER BY ROWNUM ASC) AS "_RN", but it needs some testing though. Do You agree with me? Should I open a ticket or something? Best regards Sławek --~--~-~--~~~---~--~~ 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: code style and external library
On Mon, Jul 27, 2009 at 9:12 AM, Charlie DeTar wrote: > > Hi, > > I'm writing a reusable Django app that interfaces with a standalone > javascript library, which I hope eventually to submit for inclusion in > Django. I've run into a conundrum: the javascript library uses mixed > case naming (likeThis), where Django recommends using PEP 8 naming > (like_this). This isn't really a question for Django-developers - this is a forum for discussing the development of Django itself. General usage/style questions should be directed to django-users. 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: code style and external library
Russell Keith-Magee wrote: > On Mon, Jul 27, 2009 at 9:12 AM, Charlie DeTar wrote: >> Hi, >> >> I'm writing a reusable Django app that interfaces with a standalone >> javascript library, which I hope eventually to submit for inclusion in >> Django. I've run into a conundrum: the javascript library uses mixed >> case naming (likeThis), where Django recommends using PEP 8 naming >> (like_this). > > This isn't really a question for Django-developers - this is a forum > for discussing the development of Django itself. General usage/style > questions should be directed to django-users. > > Yours, > Russ Magee %-) > Thanks for the reply, Russ. I asked in django-developers as I was intending to develop such that my code would be suitable for inclusion in Django itself; thus, I saw this as a question relevant to the development of Django itself. The code I'm writing constitutes a "medium-to-big" change in the Geodjango admin implementation, so it seemed reasonable to me to write it as a standalone app first, but my intention has been from the start to contribute this code to Django. The code is growing closer to a point where I would submit patches to include it into Django, so I wanted feedback on a non-obvious code style choice. Is this contrary to the purposes of this list? cheers, Charlie --~--~-~--~~~---~--~~ 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: code style and external library
On Tue, Jul 28, 2009 at 10:45 PM, Charlie DeTar wrote: > > Russell Keith-Magee wrote: >> On Mon, Jul 27, 2009 at 9:12 AM, Charlie DeTar wrote: >>> Hi, >>> >>> I'm writing a reusable Django app that interfaces with a standalone >>> javascript library, which I hope eventually to submit for inclusion in >>> Django. I've run into a conundrum: the javascript library uses mixed >>> case naming (likeThis), where Django recommends using PEP 8 naming >>> (like_this). >> >> This isn't really a question for Django-developers - this is a forum >> for discussing the development of Django itself. General usage/style >> questions should be directed to django-users. >> >> Yours, >> Russ Magee %-) >> > > Thanks for the reply, Russ. I asked in django-developers as I was > intending to develop such that my code would be suitable for inclusion > in Django itself; thus, I saw this as a question relevant to the > development of Django itself. > > The code I'm writing constitutes a "medium-to-big" change in the > Geodjango admin implementation, so it seemed reasonable to me to write > it as a standalone app first, but my intention has been from the start > to contribute this code to Django. The code is growing closer to a > point where I would submit patches to include it into Django, so I > wanted feedback on a non-obvious code style choice. Is this contrary to > the purposes of this list? My apologies, Charlie - I didn't catch the GeoDjango angle to your question. In that case, you're probably in the right place :-) Personally, I'd be tempted to take Option 3 (translate), although I'd probably shy away from a generic 'translation' function and lean towards a simple dictionary-style mapping of Python names to JavaScript alternatives. Yes, this will mean that you need to manually maintain the dictionary when (if) the JavaScript API changes. However, you're going to need to have conversions for each of the arguments - some arguments take floats, some take strings, some take arrays - so you will need some sort of per-argument handling anyway. On top of that, updating the mapping won't be too hard, it will keep the runtime lookups fast, and the implementation painfully simple. Option 1 would be a close second, on the "When in Rome" argument. I'm guessing the Python code needs to know that it is generating Javascript, but the Javascript won't know it's being generated by Python - in which case, it makes sense to make Python yield in this case. This has the added benefit that your documentation can be as simple as "takes the same arguments as olwidget". 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: ORACLE QuerySet offset
On Tue, Jul 28, 2009 at 6:20 AM, slafs wrote: > > Hi there! > > I think I found a little bug in > http://code.djangoproject.com/browser/django/trunk/django/db/backends/oracle/query.py#L132 > Offsetting the QuerySet (like qs[2:4]) on Oracle backend mixes the > ordering in the final result set. > Author claims that "This is the canonical way to emulate LIMIT and > OFFSET on Oracle." but looking a bit through the web You can find that > more popular (appropriate?) way is the RANK() OVER function > (http://www.techonthenet.com/oracle/functions/rank.php) > so instead SELECT ROWNUM AS "_RN" in line 132 > I would write SELECT RANK() OVER(ORDER BY ROWNUM ASC) AS "_RN", but it > needs some testing though. > Do You agree with me? > Should I open a ticket or something? > > Best regards > Sławek Hi Slawek, We used to do it this way [1] until a contributor pointed out that ROWNUM scales better [2]. I think that comment actually dates back to the original implementation, so I would take the word "canonical" with a grain of salt. Please go ahead and open a ticket for this. But I'd like to know: are you encountering problems with ordered queries, or does the mixed ordering bug only occur with unordered queries? Also, when this happens, is the pagination consistent, i.e. if you combine all the pages together, does each row appear exactly once? As long as it only affects unordered queries and the pagination is consistent, I think this can probably be fixed in documentation. Thanks, Ian [1] But with ROW_NUMBER() instead of RANK() -- the problem with RANK() is that if two rows compare equally in the ordering, it returns the same value for both. As a result, the query might return more rows than requested. [2] http://code.djangoproject.com/ticket/9136 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Ticket 3090 - multi-tag template tags
Partly pasted from http://code.djangoproject.com/ticket/3090 - a trivial
reordering in template.Parser.parse to allow inner template tags to take
parameters, something like 'parser.parse_until(('case', 'endswitch'))' where
the 'case' tag can take parameters.
I would like to see this change. In closing the ticket, a snippet is
referenced which uses multiple templatetags to achieve a similar end, but would
need additional registered tags to support 'default' or 'else' - each
registered tag could cause conflicts, and the 'case' tag makes no sense outside
of 'switch' and shouldn't be available).
http://www.djangosnippets.org/snippets/967/ shows a way to achieve this, but it
requires a hack that would be unnecessary with this patch (basically duplicates
it by overloading __contains__ of the object passed to parse_until).
Since the patch is so simple - it's clear by inspection that the reordering
can't break anything (unless someone attempts to 'parse_until' an empty tag,
which I assume is unsupported) - it'd be nice to see it accepted.
--~--~-~--~~~---~--~~
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: code style and external library
On Monday 27 July 2009 02:12:07 Charlie DeTar wrote: > Hi, > > I'm writing a reusable Django app that interfaces with a standalone > javascript library, which I hope eventually to submit for inclusion > in Django. I've run into a conundrum: the javascript library uses > mixed case naming (likeThis), where Django recommends using PEP 8 > naming (like_this). PEP 8 is really about writing Python, not any other language. While javascript is close enough to Python in syntax that some conventions can be carried over, it's a different language and I don't think it should be bound by the same rules. There is already plenty of javascript code in Django that uses mixed case, so I'd go for option 1. Luke -- "I asked mom if I was a gifted child. She said they certainly wouldn't have paid for me." (Calvin and Hobbes) 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 -~--~~~~--~~--~--~---
IDE for Django and Ext JS
Hi All, What development environment do you suggest for Django and Ext JS based large projects? Is Netbeans the best choice out there? Thanks Amir --~--~-~--~~~---~--~~ 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: IDE for Django and Ext JS
The django-developers mailing list is for the development of django itself. Please use the django-users mailig list. Alex On Jul 28, 2009 1:18 PM, "Amir Habibi" wrote: Hi All, What development environment do you suggest for Django and Ext JS based large projects? Is Netbeans the best choice out there? Thanks Amir --~--~-~--~~~---~--~~ 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: Multi-DB Status Update
Hi Alex What is the current status of the multi version support? I mean will it be merged with trunk any time soon? I ask you this because I am at a early stage of designing the architecture of a new project, and this will have to support several clients (separate databases) but connected by a master database (authentication, shared resources, etc). I have achieved this using a process_request middleware that can map to the client, my only problem is changing the database connection from the master database to the client one. Additionally the client will have to replicate some data on the master one, from time to time. I have read a lot of posts on this subject, but I am yet to find a solution that actually works and that I can trust that wont break on a following release, due to using custom Managers with custom connections, feel too much like hacking undocumented features, and therefore totally unsafe. I am considering using SQLalchemy for all the master database interactions, but still use Django ORM for the client ones, as I wish to go away from the Django patterns the least possible and maybe it will make it easier to change it when this multi-database support actually comes out stable. If you could please give me some feedback or suggestion on the path to take, I would gracefully appreciate it. Ricardo --~--~-~--~~~---~--~~ 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: Multi-DB Status Update
On Tue, 28 Jul 2009, Ricardo Santos wrote: > What is the current status of the multi version support? I mean will > it be merged with trunk any time soon? ... snip ... I think this is slated for the 1.2 timecycle. The GSoC istelf ends sometime in late August, so that's likely the earliest timeframe for this. That said, it could invariably be later as it may not be in a usable state. Furthermore, it will likely not be "production ready" for at least a few weeks after that. Hope it helps, -justin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ANN: Security updates released
Tonight the Django team has issued two releases related to a security issue reported to us. These releases are Django 1.0.3 and Django 0.96.4. Full information is available on the Django project weblog: http://www.djangoproject.com/weblog/2009/jul/28/security/ These releases are strongly recommended upgrades for users of affected Django versions (1.0.X, 0.96.X). Django 1.1, which is due to be released within a few hours, will also include this update, as well as a second security-related change detailed in the blog post listed above. Also, please note that with the release of Django 1.1 tonight, the Django 0.96.X release series will reach end-of-life; after tonight's 0.96.4 there will be no further official releases in that series. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ANN: Django 1.1 released!
Tonight we're extremely proud to announce the release of Django 1.1, the latest major milestone in Django's development. To learn about the new release: * Blog post: http://www.djangoproject.com/weblog/2009/jul/29/1-point-1/ * Release notes: http://docs.djangoproject.com/en/dev/releases/1.1/ * Download: http://www.djangoproject.com/download/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
