Re: django multi application, multi database, need to sync..
On 17 янв, 05:58, otonk <[EMAIL PROTECTED]> wrote: > hi, i am currently designing two or more django application, one > application act as the master application, contains all the data, the > other application has partial function of the master application. The > master database belongs to the master application, other database has > a partial data from the master database. The reason we have such > design is these application is separated geographically and the > connection may not be always available. The problem with this design > is how to move partial data from master db to other db, the sync > process is triggered by user. I need an way to sync the data. I know > this is doable but I am confused with the implementation. Any solution > is appreciated. Thank you. Create the sync script using the Python DB API directly (no Django ORM). And then trigger it either automatically with the cron job or manually, by wrapping that script inside django view. You may want to add `modified` DateTimeField to all your Django models and store the last sync date/time somewhere. So the sync script should only SELECT records from master database where 'modified' is greater than last sync date and INSERT/UPDATE it into other database. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: django multi application, multi database, need to sync..
And it's also important to not really delete records from database. Use the 'delete' boolean field to mark unneeded records. On 18 янв, 06:18, otonk <[EMAIL PROTECTED]> wrote: > > Create the sync script using the Python DB API directly (no Django > > ORM). And then trigger it either automatically with the cron job or > > manually, by wrapping that script inside django view. You may want to > > add `modified` DateTimeField to all your Django models and store the > > last sync date/time somewhere. So the sync script should only SELECT > > records from master database where 'modified' is greater than last > > sync date and INSERT/UPDATE it into other database. > > cool thanks Ivan.. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Django multilingual
Piotr, having django-multilingual features in the core won't make them any better. Complex models and use-cases will still need custom/manual solutions. It will add unneeded overhead to single-language sites and may even break the sites that use explicit custom solutions (like mine). I am developing several 2 language projects with Django and I don't use django-multilingual - I do all multilingual tasks manually - and some code is hardcoded/optimized for my Russian/English needs - no general-purpose solution will ever help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Django multilingual
Models that need flexibility have `lang` and `is_translation_of` fields. Views (or custom managers) filter the output based on `lang` and add the link to other language if translation exists. Some models just have two separate text fields for each language and views (or custom managers) display the text from either one or another. Some content appears only in one language and is hardcoded into views/ templates. My multilingual projects deal only with two languages: Russian and English - and don't have the goal to support more. I try to customize each language version of the site to reflect both cultural and local/international differences - any automagic solution will fail to do that. On 27 янв, 15:28, maco <[EMAIL PROTECTED]> wrote: > Can you share the logic behind the models and views you use. Don't > need to go into details, just the philosophy behind it, > eg.http://orestis.gr/en/blog/2007/05/14/international-part3/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Best practice for implementing multilingual content in template
IMO code_berzerker's approach is the best for complex models. But in many cases that don't require a lot of flexibility it can be better to use simpler approach with text fields for each language and function/ property to get the right field from templates. I even wrote the metaclass to make this DRY. http://pastebin.com/m715ba882 You might need to edit the LANGUAGES tuple for your needs and add __metaclass__ = MultilingualModelBase in the beginning of your multilingual model classes. Properties will be automatically created. If your model has `title_en` and `title_sv` this metaclass will create `title` property that will get the right filed based on settings.LANGUAGE_CODE. Hope this helps. --Ivan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Best practice for implementing multilingual content in template
Made some corrections: http://pastebin.com/d6337d211 On Jan 28, 10:45 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote: > IMO code_berzerker's approach is the best for complex models. But in > many cases that don't require a lot of flexibility it can be better to > use simpler approach with text fields for each language and function/ > property to get the right field from templates. I even wrote the > metaclass to make this DRY. > > http://pastebin.com/m715ba882 > > You might need to edit the LANGUAGES tuple for your needs and add > __metaclass__ = MultilingualModelBase in the beginning of your > multilingual model classes. Properties will be automatically created. > If your model has `title_en` and `title_sv` this metaclass will create > `title` property that will get the right filed based on > settings.LANGUAGE_CODE. > > Hope this helps. > > --Ivan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Newbie Question
> Fortnately, Python makes this very easy with the built-in > property() call: > > class MyModel(Model): > surname = CharField(...) > forenames = CharField(...) > def _get_name(self): > return self.forenames + ' ' + self.surname > name = property(fget=_get_name) Python (2.4+) makes it even easier with decorator: class MyModel(Model): surname = CharField(...) forenames = CharField(...) @property def name(self): return 'self.forenames + ' ' + self.surname or, better: @property def name(self): return '%s %s' % (self.forenames, self.surname) or one-liner (not very good): name = property(lambda self: '%s %s' % (self.forenames, self.surname)) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
1.3x-3x Model Instantiation Optimization
After discussion on Django developers group about Model.__init__(*args) deprecation I found the way to dramatically optimize instantiation of Django models. Here is a code: http://pastebin.com/m8e7e365 You may add this code to your Django model class and then instead of obj = YourModelClass(title='Title', , pub_date=datetime.datetime.now() ) use row = (None, 'Title',..., datetime.datetime.now()) obj = YourModelClass.fromtuple(row) # 1.3x faster then before or obj = YourModelClass.fromtuple(row, False) # 3x faster then before only if you don't need pre_init and post_init signals! The number of tuple items should be exactly the same that number of fields. And, be careful, the code is experimental, untested and relies on deep black magic of object.__new__(class) which creates the instance without calling __init__ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: We're having an extremely difficult to diagnose problem:
I had A LOT of similar problems when I need to work with cyrillic. I
can easily replay your problem. Fortunately I'm on localized Windows
machine.
So:
>>> path = r'C:\Documents and Settings\vanilla'
>>> os.path.isdir(path)
True
>>> os.listdir(path)[-1]
'\xd8\xe0\xe1\xeb\xee\xed\xfb'
>>> a = os.listdir(path)[-1]
>>> a
'\xd8\xe0\xe1\xeb\xee\xed\xfb'
>>> a.decode('utf-8')
Traceback (most recent call last):
File "", line 1, in
File "C:\Python25\lib\encodings\utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1:
invalid dat
a
Here it is! Extremely difficult to diagnose problem!
And let's fix it:
>>> import sys
>>> a.decode(sys.getfilesystemencoding())
u'\u0428\u0430\u0431\u043b\u043e\u043d\u044b'
>>> b = a.decode(sys.getfilesystemencoding())
>>> print b
Шаблоны
>>> c = b.encode('utf-8')
Fixed
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: We're having an extremely difficult to diagnose problem:
It looks that you have encoding problem. You have wrong characters somewhere. The solution is to find the text that causes problems and create custom encode and/or decode function that fixes this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: We're having an extremely difficult to diagnose problem:
> Our database is utf8 we explicitly convert ignoring errors to utf8 > before passing to textile. Also it's not 1 page that poops it's every > site pooping at once. That means that the problem is inside something that shows on every page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: We're having an extremely difficult to diagnose problem:
You have this in your log: func ignore_failures False Maybe try to change this to True. And double check that everything is converted with 'ignore'. Another option: store the textiled xhtml in database. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: We're having an extremely difficult to diagnose problem:
You pass unicode value to textile.textile. I was able to repeat your error by doing the same: textile.textile breaks with similar error when it recieves a unicode string. It can be fixed by encoding your value as utf-8 before passing to textile.textile. Your error log has: return textile.textile(value, encoding=settings.DEFAULT_CHARSET, output=settings.DEFAULT_CHARSET) But current Django trunk has: return mark_safe(force_unicode(textile.textile(smart_str(value), encoding='utf-8', output='utf-8'))) So you need to update your django/contrib/markup/templatetags/ markup.py and problem should dessapear. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: We're having an extremely difficult to diagnose problem:
Your problem was solved here: http://code.djangoproject.com/changeset/5609/django/trunk/django/contrib/markup/templatetags/markup.py You may have other problems if you mix trunk with 0.96. Many bugs are solved in trunk - the best strategy is to update everything. Hope, this helps. -- Ivan On Jan 30, 8:25 am, Ivan Illarionov <[EMAIL PROTECTED]> wrote: > You pass unicode value to textile.textile. I was able to repeat your > error by doing the same: textile.textile breaks with similar error > when it recieves a unicode string. It can be fixed by encoding your > value as utf-8 before passing to textile.textile. > > Your error log has: > return textile.textile(value, encoding=settings.DEFAULT_CHARSET, > output=settings.DEFAULT_CHARSET) > > But current Django trunk has: > return mark_safe(force_unicode(textile.textile(smart_str(value), > encoding='utf-8', output='utf-8'))) > > So you need to update your django/contrib/markup/templatetags/ > markup.py and problem should dessapear. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: 1.3x-3x Model Instantiation Optimization
> Hm, a code running fast is really good but this solution seems to be really > experimental and hard-to-use, as well as making code kinda unreadable. It > would be great if it's implemented in next django releases to make django > fast :). Is it possible to do it? It depends on Django developers. I propose this to be included in core Model class as alternative method, because they want to disable instantiation from positional args. But they also want to keep their API as clean as possible. Two methods of doing one thing violates Python philosophy. And this is a good point - features like these are not oriented for all Django users - they need more skill and Python knowledge to be used effectively. It's not for Django core - it's for 3rd party Django extensions and for advanced Django customization/optimization by Django :) > And exactly in the same order they appear in instance._meta.fields... Yes. Tuple instantiation can be very handy and fast - but requires more care and testing. And disabling of Model.__init__ signals should be even more careful - they are extremely slow and rarely used - but some code may depend on them, so you need to double check that they are not used anywhere. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: We're having an extremely difficult to diagnose problem:
The problem here is not about wrong encoding of strings - it's all about unicode/string relationship and from-unicode-to-string/from- string-to-unicode problem. I really think that it will be fixed if you replace return textile.textile(value, encoding=settings.DEFAULT_CHARSET, output=settings.DEFAULT_CHARSET) with, at least: return textile.textile(value.encode(settings.DEFAULT_CHARSET), encoding=settings.DEFAULT_CHARSET, output=settings.DEFAULT_CHARSET) or, better: return textile.textile(smart_str(value), encoding='utf-8', output='utf-8') in django/contrib/markup/templatetags/markup.py On 30 янв, 18:51, Noah <[EMAIL PROTECTED]> wrote: > Our default encoding is UTF-8 and that problem would manifest more > often and not take out the whole server. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: We're having an extremely difficult to diagnose problem:
If you don't want to rely on Django's smart_str, you can do following:
if isinstance(value, unicode):
value = value.encode('utf-8', 'ignore')
return textile.textile(value, encoding=settings.DEFAULT_CHARSET,
output=settings.DEFAULT_CHARSET)
textile.textile() certainly breaks with your error if given unicode
object. Anyone can repeat it. The problem probably doesn't manifest
more often because textile.textile() could get strings in most cases
and only in few cases it gets unicode - and then your server breaks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: How to know if an object is being created in the save() method?
There is 'post_save' signal with 'created' parameter. But, unfortunately, this feature is undocumented... On Jan 31, 6:44 am, Julien <[EMAIL PROTECTED]> wrote: > Hello there, > > Does the title says it all? When overriding the save method of an > object, I'd like to know if that object is being created or updated. > > How I do it so far is: > > def save(self): > if self.pk: > ...=> being created > else: > ...=> being updated > > I vaguely remember seeing a parameter for the save method which would > do that, but I can't find it. Any thoughts? > > Thanks! > > Julien --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: How to know if an object is being created in the save() method?
Example of post_save with 'created' flag is in Django tests: http://code.djangoproject.com/browser/django/trunk/tests/modeltests/signals/models.py --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Any way to know if a value has changed before saving?
> def save(self):
> if self.stuff !=
> magic_function_that_tells_what_is_in_database_for('stuff')
> do_this()
> super(A, self).save()
This 'magic function' is
self.__class__.objects.get(id=self.id).stuff
if self.stuff != self.__class__.objects.get(id=self.id).stuff:
do_this()
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: how to speed up objects saving
You have two options: 1. Execute raw SQL 'INSERT' queries 2. Override the Model.save() or create new save_fast() method in your Model class. The main speed eaters in Model.save() are dispatcher.send() calls - so if you copy/paste the content of save method from Django code without dispatcher.send() lines you'll get a reasonable speed increase. --Ivan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: how to speed up objects saving
> I'll try to redefine save methods in all the objects to see how much time it > saves You may want to redefine the __init__ methods as well (it's called when you create your objects before save), it adds overhead of two more signals that are probably unused and can be removed for speed. You can try comment out all dispatcher.send() lines of __init__ and __save__ methods of Model class in /django/db/models/base.py and save the file as base2.py in the same place inside your Django package and say something like `from django.db.models.base2 import Model as MyModel' and replace model.Model with MyModel in class definitions. I know it's hackish, but it's easier and it works. :) Hope this helps, Ivan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Flash and Django
http://djangoamf.sourceforge.jp/index.php?DjangoAMF_en On 1 фев, 18:33, "Ronaldo Z. Afonso" <[EMAIL PROTECTED]> wrote: > Hi, > > I'm new in Django and Web development and I just want to know if it's > possible to have a flash script showing elements that was retrieve from > a data base by django? > Any link or documentation would be appreciated. > Thanks. > > Ronaldo. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Best practices for creating Manager methods?
> def create_user(self, username, email, password=None): > def make_random_password(self, length=10, > allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789'): > > These two methods seem to involve situations where they need to act on > a model, but the object instance hasn't been created yet. Should > managers always be used for this? Dave, these methods are methods of "UserManger" which is a Manager. The Model that uses this Manager is called "User" and is a little deeper in the code. It looks that you misunderstood the code. > Have people placed similar functionality within the model classes > directly? I suppose it depends on whether you need the functionality > in absence of an object instance... There was a discussion about this rescently. Classmethods and staticmethods will work, as well as plain module-level functions, but a Manager is a preferred way in Django. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Feel free to test queryset-refactor branch
Glad to hear that queryset-refactor is almost ready. Currently, I noticed that there are few SQL portability issues and few old queryset API issues (eg in admin). I already filed #6956 and #6957. I do some heavy testing of this branch and I will report anything that goes wrong. Regards, -- Ivan On Apr 13, 3:23 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > We're getting pretty close to merging queryset-refactor into trunk and > would like to do this as soon as practical. There are still a couple of > enhancements to add (#5420, mostly), one bug to fix (#5937) and some > internal tweaking to do, but all the main stuff is ready to be used. > > So if anybody wants to test it out, go ahead. Read the wiki page[1] if > you've got code that does any slightly unusual stuff, but for existing > code that works on trunk, there shouldn't be any real changes required. > > [1]http://code.djangoproject.com/wiki/QuerysetRefactorBranch > > File any bug reports in Trac against the queryset-refactor > "version" (please do NOT put the qs-rf keyword on the ticket; I'm using > that for other purposes). Bug reports that are regressions from existing > functionality are more interesting and important at the moment than > feature enhancements to the new features, since the latter case can be > dealt with at our leisure (they're not features that people are already > relying upon). > > If you see any different results testing against the branch compared to > trunk, it would be interesting to know about them. Reduce it to a small > example before opening a ticket, wherever possible. Please don't make me > wade through dozens of lines of code just to get to one query that is > relevant. Bear in mind, though, that the difference could be because a > bug existed in trunk and the branch is now giving the correct result. So > make sure your test case is valid (even I got bitten by that in a > project I wrote). > > Regards, > Malcolm > > -- > The sooner you fall behind, the more time you'll have to catch > up.http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Trouble installing PIL
There is one common problem with PIL: if you tried to install it *before* you install JPEG and other libraries, it won't recompile C extensions with newer headers and libraries. The solution is to rebuild PIL with -f switch: python setup.py build_ext -f (sudo) python setup.py install Hope this helps. Ivan On 19 май, 03:22, Austin Govella <[EMAIL PROTECTED]> wrote: > I used MacPorts to install jpeg (libjpeg), freetype, zlib, and then > Python Imaging Library. > > When I validate, I get the "no PIL" error. > > Error: One or more models did not validate: > imagetest.filetest: "image": To use ImageFields, you need to install > the Python Imaging Library. Get it athttp://www.pythonware.com/products/pil/ > . > imagetest.imagetest: "image": To use ImageFields, you need to install > the Python Imaging Library. Get it athttp://www.pythonware.com/products/pil/ > . > > Any tips on where the problem might be? > > (This is my nth attempt. I was using Fink to install libjpeg and zlib, > but when I installed PIL from source, it could never find libjpeg or > zlib... :-( Any tips or links on installing on osx 10.4 greatly > appreciated.) > > Thanks, > -- > Austin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
