date:20100202

Re: 1.2 Beta Thursday

2010-02-02 Thread Russell Keith-Magee

On Wed, Feb 3, 2010 at 5:19 AM, James Bennett  wrote:
> I'm kind of choosing this arbitrarily, but as far as I can tell we
> should be good to go for rolling a beta any time. So I'm picking
> Thursday.
>
> If there are any blockers I'm not aware of, let me know. Also, note
> that this will be the final feature freeze for 1.2; if it ain't in
> trunk when I roll the tarball, it'll have to wait until 1.3.

I'm fine with Thursday (or earlier, if the whim takes you). We have
bugs, but nothing that can't wait till the bugfix phase (e.g., #7190
boolean fixes for MySQL)

Before you do roll the tarball, I might draw your attention to #11520
- it's pointing at something that needs to be tweaked in your release
script.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Porting Django to Python 3

2010-02-02 Thread Martin v . Löwis

> Some examples:

Thanks for posting them:

> >>> Template(u"{{ foo }}").render(Context({"foo":"bar"}))
> u'bar'

I get

py> Template("{{ foo }}").render(Context({b"foo":b"bar"}))
''

I think that's correct: the dictionary has no key "foo".
I'm also unsure what this has to do with UTF-8: isn't this the regular
default encoding (ASCII) that allows you to have Unicode and byte
strings compare equal?

What is the syntax for variable names (i.e. can you even have non-
ASCII characters in variable names)?

> >>> Template("{{ foo }}").render(Context({u"foo":"bar"}))
> u'bar'

py> Template(b"{{ foo }}").render(Context({"foo":b"bar"}))
'bar'

Not sure why this happens - perhaps variable names get always
converted into strings?

> >>> Template("{{ foo }}").render(Context({"foo":u"bar"}))
> u'bar'

py> Template(b"{{ foo }}").render(Context({b"foo":"bar"}))
''

Also notice that it never produces bytes in these cases. Again, I'm
unsure why this happens.

> >>> MyModel.objects.filter(my_attr="foo")

py> Choice.objects.filter(choice=b'geht so')
[]

> >>> MyModel.objects.filter(my_attr=u"foo")

py> Choice.objects.filter(choice='geht so')
[]

> >>> mymodel_instance.my_attr = "foo"
> >>> mymodel_instance.my_attr = u"foo"

>>> c=Choice()
>>> c.choice=b'fine'
>>> c.choice='fine'

>
> In addition to these things, there may be problems where dictionary
> keys and various other values have used byte strings up until now,
> with no problems, but based on assumptions that no longer hold.  For
> example, declarative classes (e.g. Models) are an interesting one - 
> inPython2.x, the keys of MyClass.__dict__ are byte strings, but in 3.0,
> they are unicode strings.  Since non-ascii names for identifiers are
> valid inPython3.0 (thanks in part, I believe, to your good self :-),
> and also in at least some databases, this is not an academic issue.

Not sure what issue you see here. It's most likely difficult to map
such names into a relational database. Having a restriction that
requires field names to follow SQL syntax sounds reasonable to me.

As for __dict__ now containing Unicode strings - this already had a
number of consequences on the patch. My recommendation would be that
identifier-like things always get represented as (unicode) strings in
Django on 3k (or more generally, by the "standard" string type).

> Also, inPython3.0, you can have models with non-ascii names, which
> challenges some assumptions about things like the INSTALLED_APPS
> setting.

Again, I don't see a need to support these. I doubt the ability to
create them would be the primary reason why people would switch to
Python 3...

> I imagine that some of these things will 'come out in the wash', so to
> speak, and the lack of automatic conversion will help identify
> problems, but some things might come back to bite us if we don't get
> them right.

I think migration of existing applications is probably the biggest
challenge. For a new 3.x application, the guideline should be to use
the (unicode) string type throughout, and leave encodings entirely to
Django.

Regards,
Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Porting Django to Python 3

2010-02-02 Thread Mathieu Leduc-Hamel

By the way, did you the effort of porting reported on the python website:

http://wiki.python.org/moin/PortingDjangoTo3k

Seems to the good way to achieve it some times...

On Tue, Feb 2, 2010 at 5:37 PM, Dave  wrote:
> Ok everyone, a bit of a status update.
>
> We finished our preliminary exercise in learning Django - we created
> an architecture, performance and call profile, as well as a screencast
> instructing how to install Django in Linux and a few simple use cases.
> We'll try to make these publicly available so you the community can
> use them if you wish. Right now they're in our school's repository so
> we'll try to export them soon.
>
> Right now we're trying to decide how our work should be evaluated at
> the end of our term, April 1. What we would like to hear back from you
> is, how much do you think we should finish by that point in time?
> All / 75% / 50%, or whatever is appropriate. We're also debating how
> it should be evaluated. What made the most sense to us was to pick a
> number (if not all) of the test cases in the test suite, and try to
> have them passed by the end of term, as well as being able to perform
> some use cases. How many test cases do you think the Django / Python 3
> port should be able to pass by April 1? What use cases should a Django
> user be able to do when using the port? We were also thinking of
> making a screencast to showcase these use cases.
>
> Finally, a small aside but Martin, we tried to email you at your
> Google Group address - we were interested in talking to you about the
> work you're doing or have done on the port. Is there a way we could
> contact you in case we had some questions or needed some guidance?
>
> On Jan 15, 6:50 pm, Luke Plant  wrote:
>> On Friday 15 January 2010 18:54:51 Martin v. Löwis wrote:
>>
>> > > That sounds like a not-unreasonable distribution of work.  One of
>> > > the big architecture questions is that in Django currently
>> > > anywhere you can pass a string Django will accept either a utf-8
>> > > encoded string or unicode, in Py3k given the clear
>> > > differentiation in purpose between str and bytes is that still
>> > > reasonable behavior?
>>
>> > What APIs does this refer to? There are certainly places in Django
>> > where there is no choice of providing byte strings (i.e. where you
>> > must pass Unicode strings).
>>
>> Some examples:
>>
>> >>> Template(u"{{ foo }}").render(Context({"foo":"bar"}))
>> u'bar'
>> >>> Template("{{ foo }}").render(Context({u"foo":"bar"}))
>> u'bar'
>> >>> Template("{{ foo }}").render(Context({"foo":u"bar"}))
>>
>> u'bar'
>>
>> >>> MyModel.objects.filter(my_attr="foo")
>> >>> MyModel.objects.filter(my_attr=u"foo")
>> >>> mymodel_instance.my_attr = "foo"
>> >>> mymodel_instance.my_attr = u"foo"
>>
>> In addition to these things, there may be problems where dictionary
>> keys and various other values have used byte strings up until now,
>> with no problems, but based on assumptions that no longer hold.  For
>> example, declarative classes (e.g. Models) are an interesting one - in
>> Python 2.x, the keys of MyClass.__dict__ are byte strings, but in 3.0,
>> they are unicode strings.  Since non-ascii names for identifiers are
>> valid in Python 3.0 (thanks in part, I believe, to your good self :-),
>> and also in at least some databases, this is not an academic issue.
>>
>> Also, in Python 3.0, you can have models with non-ascii names, which
>> challenges some assumptions about things like the INSTALLED_APPS
>> setting.
>>
>> I imagine that some of these things will 'come out in the wash', so to
>> speak, and the lack of automatic conversion will help identify
>> problems, but some things might come back to bite us if we don't get
>> them right.
>>
>> Luke
>>
>> --
>> "Outside of a dog, a book is a man's best friend... inside of a
>> dog, it's too dark to read."
>>
>> Luke Plant ||http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

1.2 Beta Thursday

2010-02-02 Thread James Bennett

I'm kind of choosing this arbitrarily, but as far as I can tell we
should be good to go for rolling a beta any time. So I'm picking
Thursday.

If there are any blockers I'm not aware of, let me know. Also, note
that this will be the final feature freeze for 1.2; if it ain't in
trunk when I roll the tarball, it'll have to wait until 1.3.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Per application default database?

2010-02-02 Thread kmpm

Wouldn't a database router like this sort of do the thing for now...

==settings.py==
DATABASE_ROUTERS = ['dbrouter.AppRouter',]
==dbrouter.py==
APPS_WITH_DB=('my_app_with_same_name_as_db',
)

class AppRouter(object):
"""A router to control all database operations on models in
that belongs to a app in APPS_WITH_DB"""

def db_for_read(self, model, **hints):
if model._meta.app_label in APPS_WITH_DB:
return model._meta.app_label
return None

def db_for_write(self, model, **hints):
if model._meta.app_label in APPS_WITH_DB:
return model._meta.app_label
return None

def allow_relation(self, obj1, obj2, **hints):
if (obj1._meta.app_label in APPS_WITH_DB) or
(obj2._meta.app_label in APPS_WITH_DB):
return True
return None

def allow_syncdb(self, db, model):
"Make sure the app only appears on the db where it belongs"
#print "db=%s, app=%s, model=%s" % (db, model._meta.app_label,
model)
if db in APPS_WITH_DB:
return db == model._meta.app_label
elif model._meta.app_label in APPS_WITH_DB:
return False
return None



On Jan 19, 4:35 pm, Russell Keith-Magee 
wrote:
> On Tue, Jan 19, 2010 at 12:20 AM, Tobias McNulty  
> wrote:
>
> > On Mon, Jan 18, 2010 at 11:04 AM, Bill Hubauer  wrote:
>
> >> One of the use cases that may be common for multiple database support is
> >> being able to combine multiple Django applications that require different
> >> databases into a single site.   This is exactly what I need to do for one
> >> project.   This can be done with the new multiple database support, but it
> >> feels heavy handed to me to require the "integrator" go through all of the
> >>applicationcode and insert "using" specifiers.   I also get nervous to
> >> about missing some places where it would be required.
>
> >> I've reviewed the code related to the selection of the default database
> >> and think that it wouldn't be too hard to make it possible to doapplication
> >> specific defaults to database settings.   It would mostly be refactoring 
> >> the
> >> django.db.DEFAULT_DB_ALIAS constant into a function, and then deciding the
> >> best way to allow the user to specify a default databaseperapplicationin
> >> the settings file.
>
> >> Has there been any consideration or discussion of this type of
> >> functionality?
>
> > There has been.  See:
>
> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> > If I recall correctly, the resolution was basically "not in this phase,"
> > i.e., this is something to be worked out in a future release of Django.
>
> You recall correctly :-)
>
> The goal for 1.2 is to get enough of the plumbing in place so that
> enthused individuals can use multi-db if they need to. The clean
> public API that addresses will be added (hopefully) in 1.3, using the
> experiences and guidance gathered from early adopters of the raw API.
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Help with Django model and 'choices'

2010-02-02 Thread Vladimir Abramov

You try to store char value in DecimalField

2010/2/2 Karen Tracey :
> Please post questions about using Django to django-users.  This list is for
> discussion of developing Django itself.
>
> Karen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Vladimir Abramov.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Help with Django model and 'choices'

2010-02-02 Thread Karen Tracey

And now I see you posted there a couple of minutes before posting here.
Please don't do that either.  Choose the right list and post once.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Help with Django model and 'choices'

2010-02-02 Thread Karen Tracey

Please post questions about using Django to django-users.  This list is for
discussion of developing Django itself.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Help with Django model and 'choices'

2010-02-02 Thread Chris McComas

I have this model http://dpaste.com/153722/ and I have a ModelForm for
it on my site. When I complete the form it saves everything as it
should and displays just a detail page for each entry with all of the
correct information from the Model.

When I go back to edit the form, or I view it in the CRUD admin that
comes with Django the fields ha_grade and hp_grade do not display the
previously selected grade, just the ---

This is a big problem since we are constantly updating/editing these
files for students and we don't want to have to reenter every grade,
every time...

What have I done wrong?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 1.2 Beta Thursday

Re: Porting Django to Python 3

Re: Porting Django to Python 3

1.2 Beta Thursday

Re: Per application default database?

Re: Help with Django model and 'choices'

Re: Help with Django model and 'choices'

Re: Help with Django model and 'choices'

Help with Django model and 'choices'

9 matches

Site Navigation

Mail list logo

Footer information