Re: What is the Right Way to handle DECIMAL fields?
On 8/29/06, Andrew Durdin <[EMAIL PROTECTED]> wrote: > In a project I am working on, we need to store monetary values in the > database, and we want to avoid floats altogether so that we don't lose > precision or have representation errors. The existing FloatField was > not suitable for use, because it would sometimes return floats and > sometimes decimals, depending on circumstances. I submitted a ticket & > patch, #2365 (http://code.djangoproject.com/ticket/2365) that addresses > this by making FloatField work exclusively with floats, and added > DecimalField (in db. and forms.) that would work with decimal.Decimal > objects. The problem with the latter is that the decimal module is only > in 2.4, and django is targeting 2.3 as the minimum support version of > Python. What about simply distribuite the module decimal.py in django.utils , as whe already do for, i.e., threading? try: # Only exists in Python 2.4+ from decimal import Decimal except ImportError: # Import copy of _decimal.py from Python 2.4 from django.utils._decimal import Decimal Decimal is just a single python file. See http://www.taniquetil.com.ar/facundo/bdvfiles/get_decimal.html#downloading-the-files-separately HAND, (c) -- Carlo C8E Miron, ICQ #26429731 -- Disclaimer: If I receive a message from you, you are agreeing that: 1. I am by definition, "the intended recipient". 2. All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it on USENET or the WWW. 3. I may take the contents as representing the views of your company. 4. This overrides any disclaimer or statement of confidentiality that may be included on your message. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Was:[Django] #2656: After creating a new user with create_user, calling login is failed
As I saw Adrian said this problem should be discussed in the maillist, so I post here. And what I want indeed is not invoke "authenticate()", but only invoke "login()" is enough after I create a new user using create_user(). I thought since I create a new user successfully, it's implied that the user is valid, and why should I re-query the database to "authenticate" the user's validity? I don't want to wirte: user = User.objects.create_user(...) user = authenticate(username=user.username, password=user.password) if user is not None: login(request, user) else ... I want to write: user = User.objects.create_user(...) login(request, user) So I think the later is more comfortable. But there is no automaticly authenticate in create_user, so for now, I must write like the former. What do you think, everyone? -- I like python! My Blog: http://www.donews.net/limodou UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad UliPad Maillist: http://groups.google.com/group/ulipad --~--~-~--~~~---~--~~ 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: Initial data hooks: management.install vs. management.syncdb
Ned Batchelder wrote: > I've also tried Jason's nose-django plugin, and it uses > management.install(app) to create the test database. This doesn't fire > a signal I can hook, so I wasn't able to create my initial data. Now that syncdb can be run non-interactively, I can switch the plugin over to calling that instead. It will take some time, however, because I need to figure out how to do that and use the new create/drop test db functions from djagnoo.test.utils when they are available without breaking the plugin for people who aren't tracking svn trunk. I should also mention that the plugin's home is now on Google code: http://code.google.com/p/nose-django/ JP --~--~-~--~~~---~--~~ 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: Was:[Django] #2656: After creating a new user with create_user, calling login is failed
On 9/5/06, limodou <[EMAIL PROTECTED]> wrote: > So I think the later is more comfortable. But there is no automaticly > authenticate in create_user, so for now, I must write like the former. As I said in the ticket (that was me, btw, not Adrian), I think your second method of just calling 'login' should be fine -- if you've just, within that request, created the user go ahead and call 'login' and proceed from there. -- "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: Validation Aware Models and django.forms on steroids
On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > How To Be Sexy, Rule 1: The word "manipulator" has really got to go. > Thinger = "Manipulator" or "Form" # The thing that holds the fields Bah, I try and try, but I can't figure out how to seperate the manipulation process from the Thinger. It really belongs in there. If you can define it in one spot, all of the different apps (including the Admin) can use that same process. This means that the Thinger is an actor on the object, and therefore a "Manipulator". Er, we could change the name to "Negotiator", or "Handler" Perhaps The Thinger doesn't have a home in the MVC paradigm-- It is defining a Form structure (not model structure) and controller code to "manipulate" a model instance. Also, I've realized now that a lot of what is defined in the Django Model should really be placed into the Thinger, as it's not Model specific (like blank=True), but is rather specific to the Admin / Thinger. I guess it's in there for simplicity (DRY and all that), but I wonder if that is 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-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: Initial data hooks: management.install vs. management.syncdb
On 9/5/06, JP <[EMAIL PROTECTED]> wrote: Now that syncdb can be run non-interactively, I can switch the pluginover to calling that instead. It will take some time, however, becauseI need to figure out how to do that and use the new create/drop test db functions from djagnoo.test.utils when they are available withoutbreaking the plugin for people who aren't tracking svn trunk.Glad to see that the new testing pieces are useful to you. If there is anything we can do that will make integrating nose-django (or any other external testing system for that matter) easier, let me know. 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-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: Was:[Django] #2656: After creating a new user with create_user, calling login is failed
On 9/5/06, James Bennett <[EMAIL PROTECTED]> wrote: > > On 9/5/06, limodou <[EMAIL PROTECTED]> wrote: > > So I think the later is more comfortable. But there is no automaticly > > authenticate in create_user, so for now, I must write like the former. > > As I said in the ticket (that was me, btw, not Adrian), I'm sorry to Adrian, I don't know :P > I think your > second method of just calling 'login' should be fine -- if you've > just, within that request, created the user go ahead and call 'login' > and proceed from there. > No, the reason I submit a new ticket is django raise an error, it says that: Request Method: POST Request URL:http://localhost:8000/register/ Exception Type: AttributeError Exception Value:'User' object has no attribute 'backend' Exception Location: C:\Python24\lib\site-packages\django-0.95-py2.4.egg\django\contrib\auth\__init__.py in login, line 53 So I checked the source of create_user and authenticate, and found in authenticate function, it'll assign a backend attribute to user after authenticate successfully, but create_user will not. So it's the problem I think. -- I like python! My Blog: http://www.donews.net/limodou UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad UliPad Maillist: http://groups.google.com/group/ulipad --~--~-~--~~~---~--~~ 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: Initial data hooks: management.install vs. management.syncdb
Russell Keith-Magee wrote: > On 9/5/06, JP <[EMAIL PROTECTED]> wrote: > > > > > > Now that syncdb can be run non-interactively, I can switch the plugin > > over to calling that instead. It will take some time, however, because > > I need to figure out how to do that and use the new create/drop test db > > functions from djagnoo.test.utils when they are available without > > breaking the plugin for people who aren't tracking svn trunk. > > > Glad to see that the new testing pieces are useful to you. If there is > anything we can do that will make integrating nose-django (or any other > external testing system for that matter) easier, let me know. I think the new testing stuff is great. Broke the heck out of my tests in the multi-db branch, but they're better now for having been broken. :) The only thing I can think of that would ease things for nose users would be to pass to the runner function whatever parts of sys.argv manage.py didn't consume, but I think that would be pretty tough to do with OptionParser, if it's even possible. Now I just need to find some time in between keeping multi-db merged and finishing nose's next release and making money and moving house to bring the nose-django plugin up-to-date to take advantage of the cool new stuff you added. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
