About licenses
When I began to create several tables of data for the globalization I wanted to use a license of CC because GPL or BSD are more specific of software. I repeat, a license for data. http://satchmo.python-hosting.com/browser/trunk/satchmo/G11n/data/ http://creativecommons.org/licenses/by-sa/2.5/ After of a little discussing here http://groups.google.com/group/django-ecommerce/browse_thread/thread/ed90b6f909964621/087cb9f3da54c60c it did not matter to me to use the New BSD license, although I would prefer to use the following one of CC who is compatible with BSD and not viric (it's different of avobe) http://creativecommons.org/licenses/by/2.5/ But David Pratt demands in the next message the exclusive use of the BDS license http://groups.google.com/group/django-ecommerce/tree/browse_frm/thread/ed90b6f909964621/768c2c4fc956dd2e?rnum=31&_done=%2Fgroup%2Fdjango-ecommerce%2Fbrowse_frm%2Fthread%2Fed90b6f909964621%3Ftvc%3D1%26#doc_d39bacb4bcd0093a and my surprise has been great when I have seen that to the projects of google that license is not demanded to them althought it is advised http://code.google.com/soc/django/about.html Then: 1) Has more preference the contributors of Google summer code that the one independents? 2) Is possible use licenses compatibles con BSD as MIT or CC-by? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
About licenses
When I began to create several tables of data for the globalization I wanted to use a license of CC because GPL or BSD are more specific of software. I repeat, a license for data. http://satchmo.python-hosting.com/browser/trunk/satchmo/G11n/data/ http://creativecommons.org/licenses/by-sa/2.5/ After of a little discussing here http://groups.google.com/group/django-ecommerce/browse_thread/thread/ed90b6f909964621/087cb9f3da54c60c it did not matter to me to use the New BSD license, although I would prefer to use the following one of CC who is compatible with BSD and not viric (it's different of avobe) http://creativecommons.org/licenses/by/2.5/ But David Pratt demands in the next message the exclusive use of the BDS license http://groups.google.com/group/django-ecommerce/tree/browse_frm/thread/ed90b6f909964621/768c2c4fc956dd2e?rnum=31&_done=%2Fgroup%2Fdjango-ecommerce%2Fbrowse_frm%2Fthread%2Fed90b6f909964621%3Ftvc%3D1%26#doc_d39bacb4bcd0093a and my surprise has been great when I have seen that to the projects of google that license is not demanded to them althought it is advised http://code.google.com/soc/django/about.html Then: 1) Has more preference the contributors of Google summer code that the one independents? 2) Is possible use licenses compatibles con BSD as MIT or CC-by? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
About licenses
When I began to create several tables of data for the globalization I wanted to use a license of CC because GPL or BSD are more specific of software. I repeat, a license for data. http://satchmo.python-hosting.com/browser/trunk/satchmo/G11n/data/ http://creativecommons.org/licenses/by-sa/2.5/ After of a little discussing here http://groups.google.com/group/django-ecommerce/browse_thread/thread/ed90b6f909964621/087cb9f3da54c60c it did not matter to me to use the New BSD license, although I would prefer to use the following one of CC who is compatible with BSD and not viric (it's different of avobe) http://creativecommons.org/licenses/by/2.5/ But David Pratt demands in the next message the exclusive use of the BDS license http://groups.google.com/group/django-ecommerce/tree/browse_frm/thread/ed90b6f909964621/768c2c4fc956dd2e?rnum=31&_done=%2Fgroup%2Fdjango-ecommerce%2Fbrowse_frm%2Fthread%2Fed90b6f909964621%3Ftvc%3D1%26#doc_d39bacb4bcd0093a and my surprise has been great when I have seen that to the projects of google that license is not demanded to them althought it is advised http://code.google.com/soc/django/about.html Then: 1) Has more preference the contributors of Google summer code that the one independents? 2) Is possible use licenses compatibles con BSD as MIT or CC-by? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: About licenses
Sorry this message was sent 3 times by a google error. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: generic-auth and per-object-permission integration
Chris Long wrote: > Already had a few people point out some bugs and some features they > want. Community involvement is key to get this moving ahead as quickly > as possible. I'm planning to move my development work to the pop/gen_auth branch once they are merged. Hopefully I will be able to give some good feedback at that point. When the merge is complete, would it be possible to have you guys merge with trunk fairly regularly? Thanks! --Nick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: generic-auth and per-object-permission integration
On 9/6/06, Linicks <[EMAIL PROTECTED]> wrote: > > I'm planning to move my development work to the pop/gen_auth branch > once they are merged. Hopefully I will be able to give some good > feedback at that point. When the merge is complete, would it be > possible to have you guys merge with trunk fairly regularly? As long as svn behaves iteself I plan on merging at least once a week. At least unless there are a huge set of changes that need to be merged manually. Joseph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Limit Fields for serializers.serialize
Hi, all.
Been playing with the serializer stuff a bit. What do people think
about the optional ability to limit which fields get serialized?
Something like:
serializers.serialize('json', foo.objects.all(), fields=('somefield',
'anotherfield'))
So that only 'somefield' and 'anotherfield' get seriailzed. The app I
was playing with had a few fields that I didn't need and didn't really
want in publicly viewable JS. I have a patch and can open a ticket.
Seems to work fine with my limited use and when deserializing back to
Django objects, though I've really only tried from/to JSON.
Cheers,
deryck
--
Deryck Hodgehttp://www.devurandom.org/
Web Developer, Naples News http://www.naplesnews.com/
Samba Team http://www.samba.org/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: About licenses
On 06/09/2006, at 11:19 PM, GinTon wrote: > > it did not matter to me to use the New BSD license, although I would > prefer to use the following one of CC who is compatible with BSD and > not viric (it's different of avobe) > http://creativecommons.org/licenses/by/2.5/ > > But David Pratt demands in the next message the exclusive use of the > BDS license > http://groups.google.com/group/django-ecommerce/tree/browse_frm/ > thread/ed90b6f909964621/768c2c4fc956dd2e?rnum=31&_done=%2Fgroup% > 2Fdjango-ecommerce%2Fbrowse_frm%2Fthread%2Fed90b6f909964621%3Ftvc% > 3D1%26#doc_d39bacb4bcd0093a I'm not a lawyer, but it is my understanding that the Creative Commons license is not viral in the slightest, and is complementary to the source code license. CC is on the copy/text, and is more a explicit granting of what is permissible. (by default ALL text is copyrighted, and not copyable). the only 'viral' in my reading is '4b as long as chris (the owner of the ecommerce code) is happy with the type of CC license you put in there it should be fine. ` > > and my surprise has been great when I have seen that to the > projects of > google that license is not demanded to them althought it is advised > http://code.google.com/soc/django/about.html > > Then: > > 1) Has more preference the contributors of Google summer code that the > one independents? > 2) Is possible use licenses compatibles con BSD as MIT or CC-by? -- Ian Holsman [EMAIL PROTECTED] join http://gypsyjobs.com the marketplace for django developers --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: About licenses
On 9/6/06, GinTon <[EMAIL PROTECTED]> wrote: > 1) Has more preference the contributors of Google summer code that the > one independents? For the students who did SoC projects, they of course can choose any license they want. But if they want their projects to be merged into Django proper, they need to license the code to use under something compatible with the BSD-style Django license. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: generic-auth and per-object-permission integration
Same as Linicks. Alain (Dazzi) and I plan to use this new merged pop/gen-auth branch for development, and also would like relatively frequent (once a week sounds fine) merges from trunk. Would let you know how that goes. Let us know when the new branch is ready to try out. (by replying here) /Nara --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: About licenses
Ian Holsman wrote: > the only 'viral' in my reading is '4b > as long as chris (the owner of the ecommerce code) is happy with the > type of CC license you put in there it should be fine. > The '4b' section simply leaves the author attribution very clear http://creativecommons.org/licenses/by/2.5/legalcode "Attribution. You must attribute the work in the manner specified by the author or licensor." It would be the same that in your BSD license: http://code.djangoproject.com/browser/django/trunk/LICENSE "Copyright (c) 2005, the Lawrence Journal-World All rights reserved. Redistributions of source code must retain the above copyright notice,..." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Freelance Work Exchange Home Jobs For Writers Programmers Designers
Freelance Work Exchange is a premier online community for freelance professionals and companies looking to hire skilled freelance experts. We have thousands of freelance and work-at-home jobs in the US and worldwide. http://www.shopzero.com/best_services/freelance-work-exchange-home-jobs-for-writers-programmers-vt4.html New work-at-home Opportunities and Projects Added Daily... Work from home, running your own business and take control of your own future. Sounds great, huh? And now you can make it happen. Freelance Work Exchange is dedicated to bringing you all the latest freelance jobs and projects, with new listings added daily. So whether you're an experienced professional, or just starting out, we can bring you hot leads and cool projects in every work-at-home job and freelance sector, including: writing and editing jobs web design and development projects medical and legal transcription jobs Internet research and email support work data entry and administration jobs programming and technical projects graphic design and illustration jobs ..plus a great deal more, too. To sign up for the free edition of the Freelance Job Report, fill in the fields below. http://www.shopzero.com/best_services/freelance-work-exchange-home-jobs-for-writers-programmers-vt4.html Find thousands of freelance jobs and discover the secrets of earning a six-figure income working from home - anyone can do it!" Learn how to quit your boring day job and start earning REAL money working for yourself. Subscribe now free of charge and get all these bonus benefits: FREE report: 'How to Find Freelance Work' FREE course: 'The Secrets of Work at Home Success' FREE eBook: 'Start Freelancing for Profit Today' FREE Freelance Job Reports and FREE jobs toolbar - fresh jobs to your desktop every day http://www.shopzero.com/best_services/freelance-work-exchange-home-jobs-for-writers-programmers-vt4.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
get form-field name from Field object
I'm in the process of creating a FileBrowseField that inherits from the CharField, but implements similar accessors to the File/ImageField. e.g. get_%s_url Additionally, in the admin, I want it to pop-up a filebrowser to allow me to select the file I want. I'm currently using a modified version of the filebrowser at http://www.vonautomatisch.at/django/filebrowser/ and it's working ok. The problem I'm having now, is that I can't find the name of the form-field that's generated in the admin, so I can set the id of my popup-link be "locate_name.of.the.field". Basically, I've added a string to the help_text of my inherited Field that show's an icon, which pops up the fileBrowser when clicked. To do the popup, I'm calling the javascript function showRelatedObjectLookupPopup from the django admin js folder. What I want to know is, how can I know the name of the that will be created in the form when this Field is used in a manipulator. Man I hope that makes sense. /Marc DM PS. I need this field because I don't want to depend on http for uploading. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
TypeError?: Float argument required
Any idea what, --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: generic-auth and per-object-permission integration
Sometime over the next few days when I feel a bit more organized I'll merge it to trunk. Moving into a new house so everything has been a bit chaotic. Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: get form-field name from Field object
On Wed, 2006-09-06 at 17:36 -0500, Marc D.M. wrote: > I'm in the process of creating a FileBrowseField that inherits from the > CharField, but implements similar accessors to the File/ImageField. e.g. > get_%s_url > > Additionally, in the admin, I want it to pop-up a filebrowser to allow > me to select the file I want. > > I'm currently using a modified version of the filebrowser at > http://www.vonautomatisch.at/django/filebrowser/ and it's working ok. > > The problem I'm having now, is that I can't find the name of the > form-field that's generated in the admin, so I can set the id of my > popup-link be "locate_name.of.the.field". > > Basically, I've added a string to the help_text of my inherited Field > that show's an icon, which pops up the fileBrowser when clicked. To do > the popup, I'm calling the javascript function > showRelatedObjectLookupPopup from the django admin js folder. > > What I want to know is, how can I know the name of the > that will be created in the form when this Field is used in a > manipulator. > > Man I hope that makes sense. > > /Marc DM > > PS. I need this field because I don't want to depend on http for > uploading. > I'm not sure how cool it is to talk to yourself in public, but I think I've solved my own problem. I havne't found the answer to my question, but I've found out how to add those extra elements to the right of the field. And I feel silly. Use Javascript . duh!! /Marc DM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Small change to utils.functional.curry
Just because I stubled on the code of curry (I had to find out what this function really does). It's not a big of a deal, but I think it would be better to change the function from the current implementation: def curry(*args, **kwargs): def _curried(*moreargs, **morekwargs): return args[0](*(args[1:]+moreargs), **dict(kwargs.items() + morekwargs.items())) return _curried too: def curry(fct, *args, **kwargs): def _curried(*moreargs, **morekwargs): return fct (* (args+moreargs), **dict(kwargs, ** morekwargs)) return _curried It's just a performance issue (saving a few list operations) andbecause I have to use CGI I care about performance at bit more than others ... Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
App portability
When moving an app to a different project, I had to go through and fix all the references to my project name in code. Is there a better way to import my code? Currently I import like: from projectname.appname.models import Model It seems like this inhibits portability of apps somewhat. Perhaps there could be some sort of "from django.conf import settings" for apps? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Small change to utils.functional.curry
On 9/6/06, Martin <[EMAIL PROTECTED]> wrote: > def curry(fct, *args, **kwargs): > def _curried(*moreargs, **morekwargs): > return fct (* (args+moreargs), **dict(kwargs, ** morekwargs)) > return _curried > > It's just a performance issue (saving a few list operations) andbecause > I have to use CGI I care about performance at bit more than others ... Thanks for the great catch and fix, Martin! I've checked in your change in changeset 3733. Please do let us know if you find any other places we could optimize. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: App portability
On Thu, 2006-09-07 at 03:41 +, SmileyChris wrote:
> When moving an app to a different project, I had to go through and fix
> all the references to my project name in code. Is there a better way to
> import my code? Currently I import like:
>
> from projectname.appname.models import Model
>
> It seems like this inhibits portability of apps somewhat. Perhaps there
> could be some sort of "from django.conf import settings" for apps?
>
Well, as far as I know, python's import is relative. So if you're in the
module /home/gray/white.py and you say
import blue
it will first try to find blue.py in /home/gray, so design your imports
carefully.
Second, there's a hack I think I saw on the documentation site (in the
comments), I use it in my urlconf, it goes like :
_package = '.'.join(__name__.split('.')[:-1])
urlpatterns = patterns(_package+'.views',
..
which just assumes that it's loading views from the same directory as
the urls.py file. This is because, a string is needed for urlpatters, a
string to the full python path. Here we determine it at runtime.
Hope this helps.
/Marc DM
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Small change to utils.functional.curry
Adrian Holovaty wrote: > On 9/6/06, Martin <[EMAIL PROTECTED]> wrote: >> def curry(fct, *args, **kwargs): >> def _curried(*moreargs, **morekwargs): >> return fct (* (args+moreargs), **dict(kwargs, ** morekwargs)) >> return _curried >> >> It's just a performance issue (saving a few list operations) andbecause >> I have to use CGI I care about performance at bit more than others ... > > Thanks for the great catch and fix, Martin! I've checked in your > change in changeset 3733. Please do let us know if you find any other > places we could optimize. > > Adrian > Martin's version is indeed faster, but has a 'gotcha' in that it precludes passing a keyword arguments named 'fct' to a curried function... >>> def curry1(*args, **kwargs): ... def _curried(*moreargs, **morekwargs): ... return args[0](*(args[1:]+moreargs), **dict(kwargs.items() + ... morekwargs.items())) ... return _curried ... ... >>> def curry2(fct, *args, **kwargs): ... def _curried(*moreargs, **morekwargs): ... return fct (* (args+moreargs), **dict(kwargs, ** morekwargs)) ... return _curried ... Check the speed up... >>> def adder(a,b,c,d): ... return a+b+c+d ... >>> adder_cur1 = curry1(adder, 1, 2) >>> adder_cur2 = curry2(adder, 1, 2) >>> shell.timefunc(adder_cur1, 3, 4) '_curried(...) 37276 iterations, 13.41usec per call' >>> shell.timefunc(adder_cur2, 3, 4) '_curried(...) 54986 iterations, 9.09usec per call' which is about 30% faster in this case However... >>> def adder2(a,b,c,d, fct=sum): ... return fct([a,b,c,d]) ... >>> import sys >>> p1 = curry1(1,2, fct="".join) >>> p2 = curry2(1,2, fct="".join) ... Traceback (most recent call last): File "", line 1, in ? TypeError: curry2() got multiple values for keyword argument 'fct' >>> Oops. Better to rename fct to something less likely to clash, such as _curried_fct If you're really hunting for speed, there is a significant boost available in the common special case of a python function curried with one positional argument. In this case, you can [ab]use the method binding machinery, e.g.: def curry3(_curried_fct, *args, **kwargs): if len(args) == 1: # Special case where we try to abuse the descriptor try: return _curried_fct.__get__(args[0]) except AttributeError: # built-ins fail - handle them in the normal way pass def _curried(*moreargs, **morekwargs): return _curried_fct (*(args+moreargs), **dict(kwargs, ** morekwargs)) return _curried This is about twice as fast as curry2 for the case of a python function curried with one argument. It also offers better introspection than either curry1 or curry2, since the original signature is preserved. It's a bigger change than the curry2 though, since it changes the type of the curry from function to bound method. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Admin breaks if unicode data is put into PostgreSQL ascii encoded database
Hello! gabor wrote: ... > this way works perfectly: > - have EVERYTHING in utf8 ... Sadly not so :( There are some places in Django that prohibit you from using utf8 (any multibyte encoding in fact) - already mentioned admin's `last change` list is one of those places. For example, see contrib\admin\models.py, line 12: ..., object_repr[:200], ... Unicode or plain ASCII str `object_repr` there would be fine. But utf8-encoded `object_repr` easily becomes garbled. Couldn't be said better: > everytime when you are really > "processing" the data (shortening it to a given length, iterating over > it character-by-character, etc..) then first you have to convert your > text to unicode-strings, do the processing, and then convert back to > byte-strings Good luck! libraM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: App portability
> Well, as far as I know, python's import is relative. So if you're in the > module /home/gray/white.py and you say > import blue > it will first try to find blue.py in /home/gray, so design your imports > carefully. Be careful ... in one of the next releases of python, support for relative import will be dropped! So I would suggest that you don't rely on relative import in new written code and change it whenever you find it in old code. Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
