Re: schema-evolution: status?

[Derek Anderson]

i only ever made two commits into django's repo:

changeset 3646 - the meat and potatoes
changeset 3647 - test code

can someone who knows svn better than i help me out as to how i would
refresh the branch with the latest from the trunk, and then remerge
these changes back into it?

thanks,
derek


Victor Ng wrote:
> 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

>>>
> 
> 


--~--~-~--~~~---~--~~
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: schema-evolution: status?

[Kenneth Gonsalves]

On 26-Oct-06, at 12:40 PM, Derek Anderson wrote:

> can someone who knows svn better than i help me out as to how i would
> refresh the branch with the latest from the trunk, and then remerge
> these changes back into it?

in your working copy root do:

svn merge http://code.djangoproject.com/svn/django/trunk

and then, after resolving conflicts do

svn commit

-- 

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/



--~--~-~--~~~---~--~~
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: DecimalField

[Christopher Lenz]

Am 25.10.2006 um 00:25 schrieb Jason Davies:
> I am working on an application which deals with monetary values and it
> *really* needs proper support for decimal, fixed-point (as opposed to
> floating-point) values.
>
> See: http://code.djangoproject.com/ticket/2365
>
> Could someone take a look and get this patch approved?
>
> I think we should just distribute decimal.py to maintain Python 2.3
> compatibility.

Oh come on, just let Python 2.3 users install the decimal module from  
SF:

   

I'd also suggest keeping FloatField as it is (i.e. half-broken,  
depending on DB backend, or fix it to always return floats, but  
that's break backwards compatibility again), deprecate it, and  
introduce the new DecimalField. Only the use of DecimalField would  
require the decimal.py module, same as ImageField requires PIL.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~-~--~~~---~--~~
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: schema-evolution: status?

[Derek Anderson]

"svn merge http://code.djangoproject.com/svn/django/trunk"; gives me the
"svn help merge" message.

here's what i did:

$ svn co
http://code.djangoproject.com/svn/django/branches/schema-evolution/
django_tmp_src
[normal checkout crap]

$ cd django_tmp_src/

$ svn merge http://code.djangoproject.com/svn/django/trunk
[help message]


god i miss cvs...



Kenneth Gonsalves wrote:
> 
> On 26-Oct-06, at 12:40 PM, Derek Anderson wrote:
> 
>> can someone who knows svn better than i help me out as to how i would
>> refresh the branch with the latest from the trunk, and then remerge
>> these changes back into it?
> 
> in your working copy root do:
> 
> svn merge http://code.djangoproject.com/svn/django/trunk
> 
> and then, after resolving conflicts do
> 
> svn commit
> 


--~--~-~--~~~---~--~~
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: fastcgi: maxRequests

[Michael Radziej]

Hi,

the patch has been ready since yesterday but I can't create 
tickets (Akismet), so I dump it here (what can I do?)--the patch 
is attached. 'python manage.py runfcgi help' describes the 
additional parameter.

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49 911 9352-0 - Fax +49 911 9352-100

http://www.noris.de - The IT-Outsourcing Company


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
--- a/django/core/servers/fastcgi.py
+++ b/django/core/servers/fastcgi.py
@@ -31,6 +31,8 @@ Optional Fcgi settings: (setting=value)
   port=PORTNUM port to listen on.
   socket=FILE  UNIX socket to listen on.
   method=IMPL  prefork or threaded (default prefork)
+  maxrequests=NUMBER   if positive: how many requests a child handles
+   before it is killed and a new child forked.
   maxspare=NUMBER  max number of spare processes to keep running.
   minspare=NUMBER  min number of spare processes to prefork.
   maxchildren=NUMBER   hard limit number of processes in prefork mode.
@@ -66,6 +68,7 @@ FASTCGI_OPTIONS = {
 'maxspare': 5,
 'minspare': 2,
 'maxchildren': 50,
+'maxrequests': 0,
 }
 
 def fastcgi_help(message=None):
@@ -103,6 +106,7 @@ def runfastcgi(argset=[], **kwargs):
 'maxSpare': int(options["maxspare"]),
 'minSpare': int(options["minspare"]),
 'maxChildren': int(options["maxchildren"]),
+'maxRequests': int(options["maxrequests"]),
 }
 elif options['method'] in ('thread', 'threaded'):
 from flup.server.fcgi import WSGIServer

Re: schema-evolution: status?

[Malcolm Tredinnick]

Hey Derek,

On Thu, 2006-10-26 at 03:30 -0500, Derek Anderson wrote:
> "svn merge http://code.djangoproject.com/svn/django/trunk"; gives me the
> "svn help merge" message.
> 
> here's what i did:
> 
> $ svn co
> http://code.djangoproject.com/svn/django/branches/schema-evolution/
> django_tmp_src
> [normal checkout crap]
> 
> $ cd django_tmp_src/
> 
> $ svn merge http://code.djangoproject.com/svn/django/trunk
> [help message]
> 
> 
> god i miss cvs...

Subversion merging isn't that different from CVS merging: you have to
tell it where to start (and, optionally, stop) merging. In subversion,
since revision numbers are global (they account for commits to all
branches), you can use the revision numbers to specify a point on a
branch.

A good reference on the web (or in paperback) for svn commands is
http://svnbook.red-bean.com/ (there are a number of versions depending
on the version of svn you are using, but for the most part, the commands
are the same).

At
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.wholebr
 is a fairly good description for branch merging. However, stay awake as read 
that page, since their example if for merging a development branch into trunk 
(you are going in the other direction).

The general ideas behind subversion's merge design are at
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac
 which is worth reading, because it explains --dry-run and how to resolve 
conflicts.

Merging two branches really comes down to working out the revision
numbers you are merging between and the direction, doing the merge and
then committing back the changes. If you are still stuck after reading
through the above examples, by all means post again and we can try to
break down the problems.

Regards,
Malcolm

> 
> 
> 
> Kenneth Gonsalves wrote:
> > 
> > On 26-Oct-06, at 12:40 PM, Derek Anderson wrote:
> > 
> >> can someone who knows svn better than i help me out as to how i would
> >> refresh the branch with the latest from the trunk, and then remerge
> >> these changes back into it?
> > 
> > in your working copy root do:
> > 
> > svn merge http://code.djangoproject.com/svn/django/trunk
> > 
> > and then, after resolving conflicts do
> > 
> > svn commit
> > 
> 
> 
> > 
> 


--~--~-~--~~~---~--~~
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: Ticket spam

[Michael Radziej]

let me add the Akismet is not a solution, it looks like it has 
become part of the problem. It doesn't keep the spam out to a 
degree that could be ignored, but now it keeps me from opening 
tickets (yes, I sent the mail to Tom after digging through my 
email archive for his address--the whitelist procedure is not 
documented properly). A matter of minutes now takes hours. I'd 
rather simply have a login procedure than go through *that*.

Michael


-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49 911 9352-0 - Fax +49 911 9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

comment to ticket 2839

[patrickk]

since my comment is rejected by Akismet, I´m posting it here ...

in filterspecs, line 40

{{{
t.append(_('By %s:\n\n') % self.title())
}}}

in filter.html, line 2

{{{
{% blocktrans with title|escape as filter_title %} By  
{{ filter_title }} {% endblocktrans %}
}}}

in django.po, line 354:

{{{
"By %s:\n
"\n"
msgstr ""
"Nach %s:\n"
"\n"
}}}


in my view, that somehow doesn´t fit together.
in filter.html, the translated title doesn´t include "" - the  
translation-file looks for  though.

i´m using the latest SVN.

patrick
--~--~-~--~~~---~--~~
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: schema-evolution: status?

[Matthew Flanagan]

Hi Derek,

To do the merge you need to look at the last revision that you merged
from trunk or in your case when your branch was created. In this case
it is revision 3332. So to merge the latest trunk you need to:

cd django_tmp_src
svn merge -r 3332:HEAD http://code.djangoproject.com/svn/django/trunk

[resolve and conflicts and test your code]
svn co -m 'merged latest changes from trunk'

To keep up to date with the trunk you just need to run an 'svn log' in
your working copy and look at the last revision that you merged from
the trunk, rev xyz say, and use that like this:

svn merge -r xyz:HEAD http://code.djangoproject.com/svn/django/trunk
etc

regards

matthew

On 26/10/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> "svn merge http://code.djangoproject.com/svn/django/trunk"; gives me the
> "svn help merge" message.
>
> here's what i did:
>
> $ svn co
> http://code.djangoproject.com/svn/django/branches/schema-evolution/
> django_tmp_src
> [normal checkout crap]
>
> $ cd django_tmp_src/
>
> $ svn merge http://code.djangoproject.com/svn/django/trunk
> [help message]
>
>
> god i miss cvs...
>
>
>
> Kenneth Gonsalves wrote:
> >
> > On 26-Oct-06, at 12:40 PM, Derek Anderson wrote:
> >
> >> can someone who knows svn better than i help me out as to how i would
> >> refresh the branch with the latest from the trunk, and then remerge
> >> these changes back into it?
> >
> > in your working copy root do:
> >
> > svn merge http://code.djangoproject.com/svn/django/trunk
> >
> > and then, after resolving conflicts do
> >
> > svn commit
> >
>
>
> >
>

--~--~-~--~~~---~--~~
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: Ticket spam

[James Crasta]

On 10/24/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:

> Also, I've been mulling over the idea of requiring an account signup
> in order to post tickets and comments. Would that be worth the pain?

I'm +1 on requiring an account signup; it's irritating to make wiki
edits and append to tickets only to be shot down by the spam catcher,
then have to go back, edit and re-submit, only to notice a minor
change of a single character here and there is enough to trick the
spam catcher into allowing me to make the post.


On 10/25/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> In one project I know of that uses trac they just have a single login
> for users to create tickets and submit patches rather than requiring
> every user to register. This eliminated 99% of their trac spam. They
> just documented the login/password in their 'contributing' docs. This
> saves someone having to manage trac users

This is a somewhat viable option as well, since it will stop pretty
much all robots, but it will make all anonymous postings appear under
the same username.  +0 on this.

--~--~-~--~~~---~--~~
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: DecimalField

[Jacob Kaplan-Moss]

On 10/26/06 2:49 AM, Christopher Lenz wrote:
> Oh come on, just let Python 2.3 users install the decimal module from  
> SF:
> 
> group_id=104148&package_id=130611&release_id=291663>
> 
> I'd also suggest keeping FloatField as it is (i.e. half-broken,  
> depending on DB backend, or fix it to always return floats, but  
> that's break backwards compatibility again), deprecate it, and  
> introduce the new DecimalField. Only the use of DecimalField would  
> require the decimal.py module, same as ImageField requires PIL.

Yeah, this sounds like a very good idea.  Doesn't break existing code, doesn't 
require decimal.py if floats are OK.  I'm +1 on this - any objections?

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: DecimalField

[Jason Davies]

Jacob Kaplan-Moss wrote:
> On 10/26/06 2:49 AM, Christopher Lenz wrote:
> > Oh come on, just let Python 2.3 users install the decimal module from
> > SF:
> >
> > > group_id=104148&package_id=130611&release_id=291663>
> >
> > I'd also suggest keeping FloatField as it is (i.e. half-broken,
> > depending on DB backend, or fix it to always return floats, but
> > that's break backwards compatibility again), deprecate it, and
> > introduce the new DecimalField. Only the use of DecimalField would
> > require the decimal.py module, same as ImageField requires PIL.
>
> Yeah, this sounds like a very good idea.  Doesn't break existing code, doesn't
> require decimal.py if floats are OK.  I'm +1 on this - any objections?

+1 too.

I think we should fix FloatField to use the correct type in the DB
backend though (and document possible backwards-incompatibilities) -
it's a shame to leave it half-broken before a 1.0 release.

Jason


--~--~-~--~~~---~--~~
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: schema-evolution: status?

[Rob Hudson]

Matthew Flanagan wrote:
> cd django_tmp_src
> svn merge -r 3332:HEAD http://code.djangoproject.com/svn/django/trunk
>
> [resolve and conflicts and test your code]
> svn co -m 'merged latest changes from trunk'

I think that should be:
svn ci -m 'merged latest changes from trunk'

After you resolve conflicts and things look good you check in your
code.

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Comments system

[Rob Hudson]

The Wiki page on the API Stability says this about the comment system:

> The comments framework, which is yet undocumented, will likely get a complete 
> rewrite
> before Django 1.0. Even if the change isn't quite that drastic, there will at 
> least be
> moderate changes.

Are there goals or docs about what this might become?  There seem to be
enough people using the comments systems that maybe people could work
on a patch (or at least get started in the right direction) if there
were some goals and ideas on what's considered broken currently.

I've personally hacked apart the FreeComment system.  At work I'm
building an internal tool and will need to hack apart the Comment
system.  So I've got a little bit of a vested interested in knowing
where this is going and may even be able to help out a little.

Being that the Forms and Manipulators code is going to be overhauled,
and the comments depend on that, that may be a dependency before any
work happens on Comments.  Even so, some ideas on what people want out
of a generic comments solution would be interesting.

Personally, I'd like to see:

* Combine Comment and FreeComment and by configuration allow the
ability to post anonymously.
* Let ratings and karma be more modular so these can be
enabled/disabled and not dependent on the other (for example, I think
currently if you have ratings you also have to submit a comment.  Maybe
this simply means pulling ratings out completely into its own app.)

Thanks,
Rob


--~--~-~--~~~---~--~~
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: Comments system

[James Bennett]

On 10/26/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Are there goals or docs about what this might become?  There seem to be
> enough people using the comments systems that maybe people could work
> on a patch (or at least get started in the right direction) if there
> were some goals and ideas on what's considered broken currently.

IIRC, one of the big (and, to me, most interesting) suggestions
involved changing the system so that you could write a model which
conformed to a particular interface (e.g., FK to user, FK to
contenttype and an object_id, plus maybe a couple methods), then drop
it into a setting and have it be "the comment model". The ones we ship
now should still be bundled, of course, and used as the defaults, but
that would add a huge amount of flexibility to the system.


-- 
"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
-~--~~~~--~~--~--~---

another ticket: related-object window is missing query ...

[patrickk]

when doing a search in the related-object window in the admin- 
interface and using the link "xxx total" after that search, the query  
is missing.
because "pop=1" is in the query, the header is shown ...

using 0.95

thanks,
patrick

(don´t know if it is appropriate to post here, but since my tickets  
are rejected I thought it´s better than doing nothing ...)
--~--~-~--~~~---~--~~
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: Comments system

[Rob Hudson]

James Bennett wrote:
> On 10/26/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>> Are there goals or docs about what this might become?  There seem to be
>> enough people using the comments systems that maybe people could work
>> on a patch (or at least get started in the right direction) if there
>> were some goals and ideas on what's considered broken currently.
> 
> IIRC, one of the big (and, to me, most interesting) suggestions
> involved changing the system so that you could write a model which
> conformed to a particular interface (e.g., FK to user, FK to
> contenttype and an object_id, plus maybe a couple methods), then drop
> it into a setting and have it be "the comment model". The ones we ship
> now should still be bundled, of course, and used as the defaults, but
> that would add a huge amount of flexibility to the system.

I'm having trouble visualizing how that would work.  I searched the list 
and the tickets for more info but didn't find anything.

Is the gist of the idea that you'd set up the model and a few methods 
and the bulk of the work would get wrapped around that?

Thanks,
Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

spamblocked ticket: Use IPython profile if in current directory

[David S .]

"Akismet rejected spam", so, though very minor, here's my ticket.

=== Use IPython profile if in current directory ===

[http://ipython.scipy.org/ IPython] is great.  It's profiles are very nice and
it would be neat to use one if available.  

This patch offers a way to do that.  It assumes that any file in the current
working directory that starts with ipythonrc- is an IPython profile and tells
IPython to use the first 1 found.

Of course you could just have a go.py script in the same directory and always
%run go.py as your 1st command.

Did I mention IPython is great?

Priority: lowest
Component: django-admin.py
Severity: trivial

Patch follows:
Index: core/management.py

===

--- core/management.py  (revision 3918)

+++ core/management.py  (working copy)

@@ -1170,10 +1170,14 @@

 if use_plain:
 # Don't bother loading IPython, because the user wants plain 
Python.
 raise ImportError
-import IPython
-# Explicitly pass an empty list as arguments, because otherwise IPython
+import IPython, glob
+# Explicitly pass a list as arguments, because otherwise IPython
 # would use sys.argv from this script.
-shell = IPython.Shell.IPShell(argv=[])
+try:
+argv = ['-profile',
glob.glob("ipythonrc-*")[0][10:].replace('.ini','')]
+except:
+argv = []
+shell = IPython.Shell.IPShell(argv=argv)
 shell.mainloop()
 except ImportError:
 import code



--~--~-~--~~~---~--~~
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: schema-evolution: status?

[Derek Anderson]

thanks for your help.  the merge went smoothly, and has been committed
as revision 3937.



Matthew Flanagan wrote:
> Hi Derek,
> 
> To do the merge you need to look at the last revision that you merged
> from trunk or in your case when your branch was created. In this case
> it is revision 3332. So to merge the latest trunk you need to:
> 
> cd django_tmp_src
> svn merge -r 3332:HEAD http://code.djangoproject.com/svn/django/trunk
> 
> [resolve and conflicts and test your code]
> svn co -m 'merged latest changes from trunk'
> 
> To keep up to date with the trunk you just need to run an 'svn log' in
> your working copy and look at the last revision that you merged from
> the trunk, rev xyz say, and use that like this:
> 
> svn merge -r xyz:HEAD http://code.djangoproject.com/svn/django/trunk
> etc
> 
> regards
> 
> matthew
> 
> On 26/10/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
>> "svn merge http://code.djangoproject.com/svn/django/trunk"; gives me the
>> "svn help merge" message.
>>
>> here's what i did:
>>
>> $ svn co
>> http://code.djangoproject.com/svn/django/branches/schema-evolution/
>> django_tmp_src
>> [normal checkout crap]
>>
>> $ cd django_tmp_src/
>>
>> $ svn merge http://code.djangoproject.com/svn/django/trunk
>> [help message]
>>
>>
>> god i miss cvs...
>>
>>
>>
>> Kenneth Gonsalves wrote:
>>> On 26-Oct-06, at 12:40 PM, Derek Anderson wrote:
>>>
 can someone who knows svn better than i help me out as to how i would
 refresh the branch with the latest from the trunk, and then remerge
 these changes back into it?
>>> in your working copy root do:
>>>
>>> svn merge http://code.djangoproject.com/svn/django/trunk
>>>
>>> and then, after resolving conflicts do
>>>
>>> svn commit
>>>
>>
> 
> > 
> 


--~--~-~--~~~---~--~~
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: Ticket spam

[Christopher Lenz]

Am 25.10.2006 um 17:22 schrieb Christopher Lenz:
> Am 25.10.2006 um 11:24 schrieb Michael Radziej:
>> Adrian Holovaty schrieb:
 Also, I've been mulling over the idea of requiring an account  
 signup
>>> in order to post tickets and comments. Would that be worth the pain?
>>
>> I wouldn't mind to have to sign up before I could submit a
>> ticket, but it seems there's no automatic sign-up in trac. That
>> would be a nuisance.
>
> Multiple options here, all plugins:

FYI: Akismet has been having a really high rate of false positive  
lately, we've seen the same problems with it at trac.edgewall.org.  
I've filed a support request but haven't heard back.

Anyway, this whole issue has provoked me to completely overhaul the  
Trac SpamFilter plugin today. It's now based on a Karma/Score system  
that lets you fine tune how much of an effect any single spam filter  
"strategy" has on the overall outcome. Using the default values, when  
a user sets up their name or email address on the settings screen,  
that would overrule an Akismet spam response. Also, the plugin now  
provides much better means for monitoring what's going on. And more  
to come very soon (traiing, anyone?)

Probably worth a try for code.djangoproject.com, and IMHO better than  
requiring registration and a password just to file a ticket.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~-~--~~~---~--~~
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: Comments system

[Malcolm Tredinnick]

On Thu, 2006-10-26 at 11:29 -0700, Rob Hudson wrote:
> James Bennett wrote:
> > On 10/26/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
> >> Are there goals or docs about what this might become?  There seem to be
> >> enough people using the comments systems that maybe people could work
> >> on a patch (or at least get started in the right direction) if there
> >> were some goals and ideas on what's considered broken currently.
> > 
> > IIRC, one of the big (and, to me, most interesting) suggestions
> > involved changing the system so that you could write a model which
> > conformed to a particular interface (e.g., FK to user, FK to
> > contenttype and an object_id, plus maybe a couple methods), then drop
> > it into a setting and have it be "the comment model". The ones we ship
> > now should still be bundled, of course, and used as the defaults, but
> > that would add a huge amount of flexibility to the system.
> 
> I'm having trouble visualizing how that would work.  I searched the list 
> and the tickets for more info but didn't find anything.
> 
> Is the gist of the idea that you'd set up the model and a few methods 
> and the bulk of the work would get wrapped around that?

I think what James is suggesting (I may be completely wrong, though) is
that we define the interface that the class must provide: so the comment
class must have methods X, Y and Z and fields A, B, and C. Then people
are free to write whatever class they like that meets those requirements
in addition to extra methods their class might have (such as karma
management, etc). Then, in settings.py, you put in the location of the
class (model) to import that satisfies the required interface.

Since comments requires the developer to design the template in any
case, this should work quite smoothly. You will receive the full comment
object (or list of objects) in the template, so you can extract
information from any of your extra attributes without trouble.

It might also be possible to achieve the same with model inheritance
because the way we have decided to expose that is via an attribute on
the base model. So if MyComment was a subclass of Comment, a Comment
instance would have a mycomment attribute (or the name can be set by the
user) that would provide access to the associated MyComment instance.

Both of these ideas seem workable to me.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Jython with Django

[JsD]

Has anybody tested Django on Jython?

I am interested in using simplified Java servlets with Jython and
Django to add needed AJAX / AJAJ functionality to the ever interesting
Django project.

Thanks,
JsD


--~--~-~--~~~---~--~~
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: Comments system

[James Bennett]

On 10/26/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> It might also be possible to achieve the same with model inheritance
> because the way we have decided to expose that is via an attribute on
> the base model. So if MyComment was a subclass of Comment, a Comment
> instance would have a mycomment attribute (or the name can be set by the
> user) that would provide access to the associated MyComment instance.

My personal preference would be to specify an interface that comments
have to implement, and then let the actual model be whatever the
developer wants; maybe a subclass of django.contib.models.Comment,
maybe not. That feels like it'd give the maximum flexibility, and also
feels a bit more natural in terms of Python -- rather than having to
*be* a Comment, it just has to be able to *act like* a Comment.

-- 
"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: Jython with Django

[James Bennett]

On 10/26/06, JsD <[EMAIL PROTECTED]> wrote:
> I am interested in using simplified Java servlets with Jython and
> Django to add needed AJAX / AJAJ functionality to the ever interesting
> Django project.

As far as I know, Jython is still "stuck" at a version of the Python
language specification too old to work with Django (Django requires a
2.3 or higher implementation, Jython was still at 2.1 last I checked).

-- 
"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
-~--~~~~--~~--~--~---

Call for comment: Forms/manipulator replacement, take 1

[Adrian Holovaty]

Hello all,

I've attached the first draft implementation of the manipulator
replacement framework -- it's just a single Python module. This
handles validation, form display/redisplay and rendering of HTML form
elements. It's mostly similar to what came out of the discussion here:

http://groups.google.com/group/django-developers/browse_thread/thread/7eceb616b251cbd0/2615be5ec6d13bd1

It's not 100% finished. Not all the common validators are implemented,
nor are all of the HTML form widgets. But the basic design is there.
I'm trying to "release" early and often to get plenty of critiques
before things get stable.

I don't have the time to document the whole thing, but...You guys are
Django developers, you're smart! :) But really, there are 134 unit
tests at the top of the module, and they should give you a pretty good
idea of what's going on.

Here's a basic example of form use:

class ContactForm(Form):
your_name = CharField(max_length=100)
your_email = EmailField()
message = CharField(max_length=2000)

def my_view(request):
form = ContactForm(request.POST)
if form.is_valid():
send_email(form.to_python())
return HttpResponseRedirect('/success/')
return render_to_response('foo', {'form': form})

And in the template:

{{ form.your_name.errors }}
Your name: {{ form.your_name }}

{{ form.your_email.errors }}
Your e-mail: {{ form.your_email }}

{{ form.message.errors }}
Message: {{ form.message }}

Notes:

* There's no distinction between a Form and a BoundForm, as previously
discussed. A form is always passed a dictionary of form data, and that
dictionary can be empty.

* All output is Unicode. I did this because eventually Django's
internal strings will all be Unicode, and we might as well do that
from the start with this.

* Each Field has a 'widget' attribute, which is set to the Widget
class to use when rendering it. This is nice and decoupled but, more
importantly, practical.

* Two of the unit tests are failing at the moment, because of a
subtlety: When a BoundField is rendered, the BoundField.__str__()
method uses the *original* data, not the data that has possibly been
altered by to_python(). The unit tests are written in a way that
expects the field to render the post-to_python() data. Specifically,
the input for the 'birthday' field is the string '1940-10-9', and
to_python() converts that to datetime.date(1940, 10, 9), which
resolves to the string '1940-10-09' (note the zero) when run through
str().

I'm not sure what the ideal behavior is here. The (at least) three
possibilities are:

   - Always render the original input data, even if the field was
valid and got converted to something slightly different by
to_python().

   - Check whether the form has any errors (in all fields). If it
doesn't, then render the to_python() data. Otherwise, render the
original input data.

   - Check whether the form has any errors (in just the particular
field). If it doesn't, then render the to_python() data. Otherwise,
render the original input data.

* There's a to-do list at the top. As I said, this is just a work in
progress at this point. I welcome any thoughts, comments and patches!

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
-~--~~~~--~~--~--~---
"""
Django validation and HTML form handling.

TODO:
 and validation of lists
Default value for field
Nestable Forms
FatalValidationError -- short-circuits all other validators on a form
ValidationWarning
Validation not tied to a particular field
"This form field requires foo.js" and form.js_includes()

# CharField ###

>>> f = CharField(required=False)
>>> f.to_python(1)
u'1'
>>> f.to_python('hello')
u'hello'
>>> f.to_python(None)
u''
>>> f.to_python([1, 2, 3])
u'[1, 2, 3]'

>>> f = CharField(max_length=10, required=False)
>>> f.to_python('')
u''
>>> f.to_python('12345')
u'12345'
>>> f.to_python('1234567890')
u'1234567890'
>>> f.to_python('1234567890a')
Traceback (most recent call last):
...
ValidationError: [u'Ensure this value has at most 10 characters.']

>>> f = CharField(min_length=10, required=False)
>>> f.to_python('')
Traceback (most recent call last):
...
ValidationError: [u'Ensure this value has at least 10 characters.']
>>> f.to_python('12345')
Traceback (most recent call last):
...
ValidationError: [u'Ensure this value has at least 10 characters.']
>>> f.to_python('1234567890')
u'1234567890'
>>> f.to_python('1234567890a')
u'1234567890a'