newforms documentation
Hi, My earlier confusion with the newforms 'id' attributes was caused by some poor wording in the documentation. Just above this link is some unnecessarily wordy text: http://www.djangoproject.com/documentation/newforms/#as-p "Each text label is surrounded in an HTML tag, which points to the appropriate form field via its id. Its id, in turn, is generated by prepending 'id_' to the field name." The preposition "via" is used incorrectly - "its id" refers to the label tag in this case. I think a clearer wording is: "Each text label is surrounded in an HTML tag, whose 'for' attribute contains the id of the appropriate form field." vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms markup with id attributes
oops... i didn't read the documentation carefully to see that label uses a 'for' attribute. Sorry. vic On 7/4/07, Victor Ng <[EMAIL PROTECTED]> wrote: > I noticed that newforms generates the same id attribute for both the > label and the input field of a form. Can we get different attribute > values here? I couldn't find a reason for duplicated 'id' values in > the mailing list archives and this looks like a bug to me - id's > should be unique within a document. > > vic > > -- > "Never attribute to malice that which can be adequately explained by > stupidity." - Hanlon's Razor > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
newforms markup with id attributes
I noticed that newforms generates the same id attribute for both the label and the input field of a form. Can we get different attribute values here? I couldn't find a reason for duplicated 'id' values in the mailing list archives and this looks like a bug to me - id's should be unique within a document. vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution branch?
Ugh... my stupid harddrive with developer Xen images keeled over on Friday and I'm trying to get everything back into a normal working state. I ought to be able to start committing code in the next day or two. argh... i hate hard disks. vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution branch?
On 1/16/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: You're attributing to malice that which can be adequately explained by the fact that we are all very busy people. Read Jacob's last post. He pretty much said he is happy to give Victor access - he just needs to find the time to do it. I don't know Jacob's specific situation at the moment, but if it's anything like mine, sometimes the little things that aren't urgent or directly related to work get lost in the miasma. I'm sure everyone is just insanely busy. Someone once told me that the reward for doing good work quickly is more work. :) I'm going to restart a mirror of the Django repo on my own. I don't think uploading a patch is the right way to go about having the code integrated into the trunk since my code is working and stable, but there are a couple quirks still to work out. I'll try to have a repo setup for people to play with this week - getting schema-evo stabilized isn't something that the core-devs should have to be involved with anyway. vic --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution branch?
Hey - any chance I'll get a schema evo-branch before 1.0? vic On 1/9/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: On 1/8/07 7:52 PM, Victor Ng wrote: > I've already emailed Jacob last week to open the branch for me. Crap -- I must have missed that email. I'll get something set up first thing tomorrow morning (my wife's telling me to close the damned laptop and go to bed...); please feel free to poke me again if I forget! Jacob > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution branch?
I've already emailed Jacob last week to open the branch for me. As it turns out - I've got *lots* of spare programming cycles since I'm stuck in an entirely unholy quagmire of bureaucratic sludge right now. :) Mmm. bureaucratic sludge. vic On 1/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: On 1/9/07, inflector <[EMAIL PROTECTED]> wrote: > > That whole discussion seems like it should have taken place here to me > but I'm a noob so perhaps I've missed the disctinction between users > and developers. There is no formal distinction - users are the set of people interested in using Django to develop websites, whereas developers are those interested in contributing to improve Django itself. Anyone is welcome to be a member of either group. Inside the developers, there are the core developers (such as myself) that have commit access to the repository, and branch developers that have commit access to a particular branch of Django. There is a subset of the core developers (Adrian and Jacob) that have administrator access to the repository and can grant commit access to various parts of the tree. Branch developer status will generally be granted to anyone that has a good idea, and can demonstrate that they will be able to deliver what they promise (a prototype implementation is the usual minimum benchmark). Core developer status is the next step, once a reputation for consistent contribution to the community is established. > Any idea what the status is on the potential for a branch, or for > Victor's changes getting rolled into the schema evolution branch? I've > volunteered to put some work into this on the other discussion but am > not sure what the next steps are or who will make those decisions. At the moment, the ball is in Victor's court - he has presented a prototype implementation, so if he wants to champion this cause, he needs to contact Jacob and request SVN access to the schema evolution branch. At that point, he will be the integration person for that branch, so if you want to contribute, he will be the person to coordinate with. If Victor doesn't want the champion role, then the floor is open for someone to step up, with some sample code to prove that they are capable of completing the task. Yours, Russ Magee %-) > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Defaults in the database?
I have a "Person" model where I have a field defined like this:
sex = models.CharField(maxlength=1, default='M', choices=(('M',
'Male), ('F', "Female")))
Although this is a simple case, I'd like to be able to do raw SQL
inserts into the table and not have to worry about missing some
default values.
Is there a reason why default values for fields aren't enforced at the
database level or is this a design choice to support some particular
backend?
thanks,
vic
--
"Never attribute to malice that which can be adequately explained by
stupidity." - Hanlon's Razor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
How do i run just 1 test module?
Is there a way to tell runtests.py to test just one module? Is this not the right command to invoke? PYTHONPATH=~/testdir python runtests.py modeltests.schemaevo.models --settings=testapp.settings thanks, vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Branch Merges?
Let's *please* keep the trunk stable. It would be very discouraging to new developers if they checked out Django from SVN head and got a broken source tree. On the topic of which branches will ever land - I'm actively working on schema evolution right now. There's still a fair bit of work to make it stable but it *is* being worked on.I'm hoping to have code ready for review within a week. vic On 11/10/06, Bill de hOra <[EMAIL PROTECTED]> wrote: > > In any case, the way to solve branch testing isn't to make the trunk > unstable as a convenience. I guess two questions to ask now are a) how > many of these branches are realistically going to land, ever, and b) > which ones are considered high value, so we can focus on testing those? -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: running the unit tests in the schema evolution branch
Thanks for the heads up on the symlinks. My problem was with stale pyc files created by symlinked .py files. Blech. What version of sqlite and pysqlite were you testing on? I can get SQL output from mysql and psycopg1 now, but nothing out of sqlite3. vic > > The emitted output on my machine is always empty. I always get this: > > > > ~/svk-ws/remote/mb-django/branches/schema-evolution/tests/evolvedbtests> > > python manage.py sqlevolve case01_add_field > > BEGIN; > > COMMIT; > > > Which is obviously not what I really want. > > Any thoughts? > > check to make sure you've switched your symlinks from pre to post (or > back again) since your last sync, and that the models actually are > different than the tables in your db. (i can't tell you how many times > this summer i was asking myself "wtf" for this exact reason) > > -- derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: running the unit tests in the schema evolution branch
Nevermind. Tests are starting to run for me, but they only work on mysql. I get failures on sqlite3 and postgresql_psycopg2. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
running the unit tests in the schema evolution branch
Hi all, Has anyone had any success in running the tests in the schema evolution branch? The tests don't look like they're integrated with runtests.py at all. As far as I can tell, you have to do the following to get the test suite to run: 1) cd schema-evolution/tests/evolvedbtests 2) the INSTALLED_APPS is setup incorrectly. Remove all the "evolvedb." prefixes 3) Run reset_all_to_pre (note that this doesn't have a shebang at the top) 4) Run python manage.py syncdb 5) Run reset_all_to_post (note that this script also doesn't have a shebang at the top) 6) Run python manage.py sqlevolve on each of the case0 applications and watch as SQL is emitted So do basically something like this: cd branches/schema-evolution/tests/evolvedbtests ./rest_all_to_pre python manage.py syncdb ./reset_all_to_post python manage.py sqlevolve case01_add_field python manage.py sqlevolve case02_rename_field python manage.py sqlevolve case03_rename_model python manage.py sqlevolve case04_change_flag python manage.py sqlevolve case05_remove_field There doesn't seem to be any automation around what the expected SQL output is, and as far as I can tell, this only works on the mysql backend. The emitted output on my machine is always empty. I always get this: ~/svk-ws/remote/mb-django/branches/schema-evolution/tests/evolvedbtests> python manage.py sqlevolve case01_add_field BEGIN; COMMIT; Which is obviously not what I really want. Any thoughts? vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
schema-evolution, oracle stability?
On 11/7/06, James Bennett <[EMAIL PROTECTED]> wrote: > > Cool. Let us know when you're ready to start sending in code and we'll > get you set up (though it might not be able to happen today; it's > election day in the US, and all of us in the news industry are running > around like chickens with our heads cut off...). Excellent - thanks James. Eric Florenza and I gave a quick stab at it tonight - and I think there's a fair bit of work so I wouldn't expect a patch against trunk for about a week. vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Branch Merges?
Ok, I've talked to Eric Florenza and the latest merge from trunk into the schema-evolution branch seems to be broken for him as well - in exactly the same way. So I'll assume that that merge wasn't done correctly. I'm starting to incrementally merge from r3647 back to trunk fixing things along the way.victor "i ♡ source control" ngOn 11/7/06, Victor Ng <[EMAIL PROTECTED]> wrote: Hi all, I've got time at work to work on the schema evolution branch and tomake sure that it works properly and to get it properly synced up todjango's SVN head.From what I can see - the latest merge from trunk to the schema evolution branch has caused quite a lot of code breakage - can anyoneelse verify this?I'm testing everything using the postgresql_psycopg2 backend for now.I'm getting a couple postgresql errors in branch revision r3647 which are related to tzinfo_factory settings in psycopg2 driver, but thoseare easy to fix.I can't get the tests to work at all using branch revision r3937. I get this:---> python tests/runtests.py --settings= schematests.settingsTraceback (most recent call last): File "tests/runtests.py", line 138, in ?django_tests(int(options.verbosity), args) File "tests/runtests.py", line 117, in django_tests run_tests(test_models, verbosity, extra_tests=extra_tests) File "/usr/local/lib/python2.4/site-packages/django/test/simple.py",line 81, in run_testsmanagement.syncdb(verbosity, interactive=False) File "/usr/local/lib/python2.4/site-packages/django/core/management.py",line 717, in syncdbfor sql in get_sql_evolution(app): File "/usr/local/lib/python2.4/site-packages/django/core/management.py", line 462, in get_sql_evolutionoutput = get_sql_evolution_check_for_changed_field_flags(klass,new_table_name) File "/usr/local/lib/python2.4/site-packages/django/core/management.py",line 570, in get_sql_evolution_check_for_changed_field_flags existing_fields = introspection.get_columns(cursor,db_table)AttributeError: 'module' object has no attribute 'get_columns'---Can anyone else verify this problem? If this is the case, I'm going rebranch from r3647 on my local repository and merge back to trunkincrementally.thanks,vicOn 11/6/06, Victor Ng < [EMAIL PROTECTED]> wrote: > What problems have you had with schema evolution?>> We're pretty commited to using Django over at my company - and I need> schema evolution badly - so I'll be starting to kick the s-o branch > starting tomorrow afternoon to see if it's stable enough for us. >> If necessary, I can apply patches myself as I'm running an instance of> svk that mirrors the entire django source tree anyway.>> vic>> On 11/6/06, Matthew Flanagan < [EMAIL PROTECTED]> wrote:> >> >> > I don't think any of those proposals reflect what is actually> > implemented. I've used the schema-evolution branch and have had some > > issues which are yet to be resolved or even responded to by the> > developer.> >>>> --> "Never attribute to malice that which can be adequately explained by > stupidity." - Hanlon's Razor>--"Never attribute to malice that which can be adequately explained bystupidity." - Hanlon's Razor -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Branch Merges?
Hi all, I've got time at work to work on the schema evolution branch and to make sure that it works properly and to get it properly synced up to django's SVN head. >From what I can see - the latest merge from trunk to the schema evolution branch has caused quite a lot of code breakage - can anyone else verify this? I'm testing everything using the postgresql_psycopg2 backend for now. I'm getting a couple postgresql errors in branch revision r3647 which are related to tzinfo_factory settings in psycopg2 driver, but those are easy to fix. I can't get the tests to work at all using branch revision r3937. I get this: --- > python tests/runtests.py --settings=schematests.settings Traceback (most recent call last): File "tests/runtests.py", line 138, in ? django_tests(int(options.verbosity), args) File "tests/runtests.py", line 117, in django_tests run_tests(test_models, verbosity, extra_tests=extra_tests) File "/usr/local/lib/python2.4/site-packages/django/test/simple.py", line 81, in run_tests management.syncdb(verbosity, interactive=False) File "/usr/local/lib/python2.4/site-packages/django/core/management.py", line 717, in syncdb for sql in get_sql_evolution(app): File "/usr/local/lib/python2.4/site-packages/django/core/management.py", line 462, in get_sql_evolution output = get_sql_evolution_check_for_changed_field_flags(klass, new_table_name) File "/usr/local/lib/python2.4/site-packages/django/core/management.py", line 570, in get_sql_evolution_check_for_changed_field_flags existing_fields = introspection.get_columns(cursor,db_table) AttributeError: 'module' object has no attribute 'get_columns' --- Can anyone else verify this problem? If this is the case, I'm going rebranch from r3647 on my local repository and merge back to trunk incrementally. thanks, vic On 11/6/06, Victor Ng <[EMAIL PROTECTED]> wrote: > What problems have you had with schema evolution? > > We're pretty commited to using Django over at my company - and I need > schema evolution badly - so I'll be starting to kick the s-o branch > starting tomorrow afternoon to see if it's stable enough for us. > > If necessary, I can apply patches myself as I'm running an instance of > svk that mirrors the entire django source tree anyway. > > vic > > On 11/6/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > > > > > I don't think any of those proposals reflect what is actually > > implemented. I've used the schema-evolution branch and have had some > > issues which are yet to be resolved or even responded to by the > > developer. > > > > > -- > "Never attribute to malice that which can be adequately explained by > stupidity." - Hanlon's Razor > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Branch Merges?
What problems have you had with schema evolution? We're pretty commited to using Django over at my company - and I need schema evolution badly - so I'll be starting to kick the s-o branch starting tomorrow afternoon to see if it's stable enough for us. If necessary, I can apply patches myself as I'm running an instance of svk that mirrors the entire django source tree anyway. vic On 11/6/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > > I don't think any of those proposals reflect what is actually > implemented. I've used the schema-evolution branch and have had some > issues which are yet to be resolved or even responded to by the > developer. > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: schema-evolution: status?
Any luck with schema evolution lately?
I'm starting to look at seeing if i can merge this back to trunk as
well, but wanted to know if you've made any progress.
I'm using the postgresql_psycopg2 backend.
vic
On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> postgresql
>
> On 14/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
> >
> > which backend are you using?
> >
> > Matthew Flanagan wrote:
> > > Derek,
> > >
> > > I have manually merged the trunk into my local working copy of the
> > > schema-evolution branch and started playing with it. I wanted to
> > > question the SQL "sqlevolve" is outputting. I have this model in an
> > > application called "asset":
> > >
> > > class Interface(models.Model):
> > > name = models.CharField(maxlength=64, core=True, db_index=True,
> > > help_text='The name of the interface as given by the asset.')
> > > interfacetype = models.ForeignKey(InterfaceType)
> > > ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
> > > raw_id_admin=True)
> > > # allow for EUI-48 and EUI-64 addresses
> > > mac_address = models.CharField(maxlength=24, blank=True,
> > > help_text='The EUI-48 or EUI-64 physical address of the
> > > interface.')
> > > domain = models.CharField(maxlength=255, blank=True,
> > > help_text='The DNS domain this host resides in.')
> > > asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
> > > num_in_admin=10, num_extra_on_change=5)
> > > objects = InterfaceManager()
> > >
> > > def _get_meta(self):
> > > return self._meta
> > > meta = property(_get_meta)
> > >
> > > def __str__(self):
> > > return "%s:%s" % (self.asset, self.name)
> > >
> > > def get_absolute_url(self):
> > > return self.asset.get_absolute_url()
> > >
> > > class Meta:
> > > ordering = ['name']
> > > unique_together = (('asset', 'name'),)
> > >
> > > class Admin:
> > > pass
> > >
> > > and the schema from "./manage.py sql asset":
> > >
> > > CREATE TABLE "asset_interface" (
> > > "id" serial NOT NULL PRIMARY KEY,
> > > "name" varchar(64) NOT NULL,
> > > "interfacetype_id" integer NOT NULL,
> > > "ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
> > > "mac_address" varchar(24) NOT NULL,
> > > "domain" varchar(255) NOT NULL,
> > > "asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
> > > UNIQUE ("asset_id", "name")
> > > );
> > >
> > >
> > > when I run "./manage.py sqlevolve asset" with absolutely no changes to
> > > my models it outputs:
> > >
> > > BEGIN;
> > > ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
> > > UPDATE "asset_interface" SET "name_tmp" = "name";
> > > ALTER TABLE "asset_interface" DROP COLUMN "name";
> > > ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
> > > ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
> > > COMMIT;
> > >
> > >
> > > Any ideas why it is doing this?
> > >
> > > regards
> > >
> > > matthew
> > >
> > > >
> > >
> >
> >
> > >
> >
>
> >
>
--
"Never attribute to malice that which can be adequately explained by
stupidity." - Hanlon's Razor
--~--~-~--~~~---~--~~
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: Local unicode-related fixes
+1 (with passion. and intensity.):) vic On 9/15/06, gabor <[EMAIL PROTECTED]> wrote: > > Malcolm Tredinnick wrote: > > > > > [I'm a leading advocate for the "give Gabor a unicode branch in svn" > > school, btw, so that you and he and others can go nuts and just do it.] > > > > +1 :-) > > gabor > > > > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ 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: Django and psycopg2 problems
Fair enough - any chance we can get that unicode branch opened up soon? vic On 8/31/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Essentially the problem is that this makes the psycopg2 backend > behave differently from all the other backends. Thus many framework > tests fail when using psycopg2, and code written for psycopg2 breaks > when running with a different backend. > > It's totally a step backwards, but I think consistancy is more > important. I'd suggest if you need the unicode behavior that you > call the ``register_type`` function in your code yourself. > > Jacob > --~--~-~--~~~---~--~~ 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: django unicode-conversion, beginning
Hi gabor, I've put up some patches to help with the unicode conversion of django. We have a site which is shortly going to production where we actually have to handle multiple unicode scripts including some which have characters that do not fall into iso-8859-1. Since I'm pretty lazy and I'm not really interested in maintaining my own set of unicode patches against django forever - I'm *very* interested in helping with any effort to get Django to support unicode. Adrian - can we get that branch opened up soon? vic On 8/21/06, gabor <[EMAIL PROTECTED]> wrote: > > Adrian Holovaty wrote: > > On 8/8/06, gabor <[EMAIL PROTECTED]> wrote: > >> i think unicodizing django can be done in 4 easily separated steps/parts: > >> > >> 1. request/response > >> 2. templating-system > >> 3. database-system > >> 4. "overall unicode-conversion". this is mostly about replacing > >> bytestrings with u"bla" in the code, and switching __str__ to __unicode__ > >> > >> my biggest problem currently is, that i do not know how to continue... > >> should i just write more and more patches to increase the > >> "unicode-coverage" to more parts of django? or maybe a more coordinated > >> approach would be better? > > > > Hey gabor, > > > > Sorry for the slow response on this -- I'm just now wading through a > > couple of weeks' worth of django-users and django-developers messages. > > This patch is a great step forward! > > > > Are you interested in a Subversion branch devoted to Unicoding Django? > > Let me know... > > > > (to make sure my original response is not caught up in a spam-filter or > such, sending this to the list too) > > > hi, > > > yes, i'm interested :) > > cannot really promise how long it will take to convert the whole django > to unicode, but will try. it's not hard. as i wrote, the changes are > simple, it's just that many changes have to be done. > > > thanks, > gabor > > > > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Patch to make unit testing applications easier/faster
Hi all, I've submitted a ticket 1763 (http://code.djangoproject.com/ticket/1763) which has a script to enable the teardown/setup of a SQLite in-memory database for use with unit tests. The script is based on the one from Ian Maurer : http://itmaurer.com/blog/?p=2 I've also included a patch which changes the way that django.db.connection is referenced in the Django code as the current idiom of : from django.db import connection causes problems with replacing the db backend. In a nutshell, you have to use import django.db or else you'll get the a reference to the connection attribute in all the calling modules. That won't work if you want to replace the db module at runtime (like when you're unit testing). I think the script and patch has a lot of value since it makes unit testing Django apps much easier as you no longer have to sit there waiting on disk i/o when your tests run. Changes like the MR merge to trunk are manageable for me - i just run my test suite with the in-memory database and see what fails, fix my failures and move on. I've never submitted code to Django before - what can I do to help make this patch go in to the trunk? I've run the Django testsuite with all passes, but I'm not sure if I should do anything else. thanks, vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ 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: speeding Django up
Hi Adrian,I'm new to Django - but I have written a metaclass based ORM before and I *have* seen psyco do weird things - sometimes causing a spontaneous crash. Maybe include a disclaimer that "your mileage may vary" if you turn on psyco. vicOn 2/3/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: On 2/3/06, Wojtek/brandlay.com <[EMAIL PROTECTED]> wrote:> I just finished testing it with FCGI and it gives a 2x speed gain after> enabling it in the WSGIHandler. I posted a patch with it > http://code.djangoproject.com/ticket/1323>> Hopefuly someone will add it to the trunk :) I'm going to test it on> all my pages in a minute and then enable on all my servers. Maybe the > load will go down to 50 from 100 now :)Hey Wojtek,Thanks for this patch. I've added it to trunk. My only concern is thatthe Psyco Web page says "[t]here are some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent inmost programs." Perhaps some of Django's current magic, implemented byadvanced features such as metaclasses, could trigger these subtle bugs. Keep us posted on the results of your tests.Adrian--Adrian Holovatyholovaty.com | djangoproject.com | chicagocrime.org-- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor
