Re: Benevolent Dicta^H^H^H Designer for Life
Congratulations Idan! I look forward to see what you have in mind for the admin and forms. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #5025 - truncate filter, why hasn't it been accepted?
Just to add more confusion to this, how is truncation handled in other languages? Is it always and ellipse? What about Chinese, Japanese, Korean, and Arabic? I recently had to do some truncation stuff and switch from an ellipse to an image overlay with CSS that faded out the line at the end because of the translation issues of truncating. I really don't think this is worthwhile because it is easy to write truncation to meet your requirements. One person wants word boundaries, another wants ellipse in the center for long names. Someone else might not want any ellipse, but not now to just use slice instead. I see truncation as a design decision. Can true filter be added such that it works for 80% of the use cases while being easy to use? -- 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: Problem with ORM
On Jan 15, 5:38 pm, Sebastian Bauer wrote: > I think ORM supposed to have save insert and update: > > save(force_insert=False,force_update=False) > update() == save(force_update=True) > insert() == save(force_insert=True) > > in that situation we could have clean code and we know that update is > realy update on DB > > i now we can have save(force_update=True) but update() looks better and > we have insert() already > > IMHO save() is only wrapper for save_base() > Those look like great methods to have, but since Django has already hit 1.0 with a statement about API stability, I don't want the core developers changing it on me. I don't think the ORM is wrong, just designed differently than other ORMs. --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Dropping Python 2.3 compatibility for Django 1.1
On Nov 25, 7:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > However, even saying Django 1.1 is the last 2.3-compatible version and > we drop it afterwards gives us a reasonable 3.0 support timeline, since > our timeframe doesn't really encourage any official 3.0 support for 1.1. I am +1 to saying 1.1 is the last release for 2.3 (or just deprecated and dropped sometime in the future). Pulling support for something is large step and was never discussed for 1.1 openly till now. Anyone who has read the roadmap but not following any more than that could be in for a nasty surprise. -John --~--~-~--~~~---~--~~ 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: Ticket 9483
> You try making an implementation of the actual English title casing > rules, and let me know how that goes. :P I would prefer not, though that sounds like a challenge:) > > str.title is a very simple title casing function, and there's a > reason for that. I completely understand. I was just suggesting if it is decided to have special title filters/ functions in Django, it might be worthwhile to have it localized. --~--~-~--~~~---~--~~ 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: Ticket 9483
On Nov 7, 3:07 am, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > On Nov 4, 2008, at 15:26, H. de Vries wrote: > > > From a publishing point of view, I don't know for sure Python's method > > is correct. Personally, I don't think so. > > I'd have to say, if Python's misbehaving, Python should be patched. > > And also, I'm strictly against making the title filter not behave as > str.title does, because let's face it, a lot of template designers are > Python programmers. > > It's also really a corner case, and I wouldn't sacrifice the Python > titlecase implementation just for this one corner case (and which > legitimate words do use semicolons in the middle of them?) > > - Ludvig For English (U.S. English at least), it should also not capitalize articles (a, an, the, etc). I don't know the rules for other languages, but I have heard they are different. So given this, if there was an effort to make the title filter better, it might be worthwhile to put it under the localization stuff. --~--~-~--~~~---~--~~ 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: Oracle testing wanted
On Oct 6, 7:11 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2008-10-06 at 07:33 -0700, varikin wrote:
>
> [...]
>
> > I will test this, but I also want to point something out. I see a lot
> > of talk about developers not having access to Oracle, but that is
> > wrong.
>
> I have neither the disk space or the CPU power on my laptop to run the
> Oracle tests in a VM in any practical sense. It's not merely difficult
> or unbelievably time consuming; it's impossible. I used to have a 64 bit
> machine that had Oracle installed on it (sometimes -- VMWare pretty
> regularly broke with kernel upgrades, so I was often in a position of
> not being able to run VMware because I chose to have other bug and
> security fixes installed on my system) and it took hours to run the
> Oracle test suite, particularly if something went wrong and I had to
> untangle things from an intermediate state. These days I only have
> access to a laptop that is quite a few years old now, so that option
> isn't available to me any longer.
>
> I've agreed to the Oracle developer license in the past (before I
> started ever doing Django development work) and sometimes Oracle's
> authentication server on their website was up for long enough I was able
> to log in and download the developer edition ("unbreakable", my ass! The
> backend to their website was broken pretty much all the time last year).
> I'm aware it is possible to get a developer edition, but being able to
> download a tarball isn't the sole requirement.
>
> This is one of the very few areas I have to totally rely on other
> members of the community to do the final piece of any development work I
> do and I make no apologies for that.
>
> Fortunately, in this case Justin has been able to do the requisite
> testing and pointed out an assumption I missed in my fake testing. I
> need to rethink the solution a little and probably hold my nose and
> commit one fix to 1.0.X and a more holistic change to trunk. I just need
> to work out the details of that second piece first to avoid too much
> churn.
>
> Regards,
> Malcolm
I would like to thank everyone for their responses. I was just reading
the comment about not having Oracle available incorrectly. Being a
developer and former tech support for an app that uses Oracle and
makes Oracle look lightweight, I think about it a bit differently.
BTW, I did test and find the same results Justin commented in the
ticket.
Thanks,
John
--~--~-~--~~~---~--~~
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: Oracle testing wanted
On Oct 6, 10:54 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Mon, Oct 6, 2008 at 9:33 AM, varikin <[EMAIL PROTECTED]> wrote: > > Oracle is free for non production use. > > That's not what we mean when we say we don't have access to Oracle... > > > Actually installing and configuring Oracle is a different matter if > > you are not familiar with it, > > ... this is. > > > but I think the defaults should be decent for testing. > > They're not. Installing Oracle on Debian/Ubuntu is incredibly easy > (add an entry to apt sources and apt-get install oracle). However, > that doesn't actually set anything up, or configure a database, or > whatever. And so the next step is to read through thousands of pages > of badly organized terribly written documentation. > > Sorry, but I really do have better things do to. > > > Also, if you are developing off a computer with > > limited resources, you may not want to install Oracle. > > This is also a big deal: I can run MySQL and PostgreSQL on my > shitty-ass PC, but simply starting Oracle shoots the load up through > the roof. > > OK, so that sounded a bit hostile; I'm sorry! None of this is your > fault (obviously) but you did want to know why none of the core devs > have Oracle installed :) I just get all ranty when Oracle's > involved... > > Jacob I agree with your points. I wouldn't use Oracle myself I didn't have to. I was just making sure people knew they could test with it if they absolutely needed to. And I completely agree with the thousands of pages of disorganized documentation. I have been forced to go through that stuff due to supported and developing something that uses Oracle. John --~--~-~--~~~---~--~~ 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: Oracle testing wanted
On Oct 5, 6:23 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Can somebody with access to Oracle please try out the patch in #9307.
> It's an attempt to allow pickling of the Query class used by the Oracle
> backend.
>
> The most basic test is probably to create any kind of Queryset using
> "manage.py shell" and the pickle.dumps(my_queryset.query) and see if it
> works. Then try reloading that (pickle.loads(...)).
>
> The other test is anything using caching, the obvious one typically
> being the query regression tests ("runtests.py --settings=... queries"),
> since there's a test for Queryset pickling in there. Note any problems
> on the ticket and I'll address them. Hopefully I've avoided the most
> obvious bozo errors (no guarantees, however) and there should be enough
> clues in the patch to self-diagnose the most obvious problems if not.
>
> Regards,
> Malcolm
I will test this, but I also want to point something out. I see a lot
of talk about developers not having access to Oracle, but that is
wrong. Oracle is free for non production use. From Oracle's website:
All software downloads are free, and each comes with a Development
License that allows you to use full versions of the products only
while developing and prototyping your applications (or for strictly
self-educational purposes).
So there is no reason a developer can't install Oracle for testing. At
work, our product uses Oracle so we install it all the time in VMWare,
all the workstations, etc. When in tech support here, I had to tell a
lot of customers they can install Oracle on as many test systems as
they want, it is just production systems that Oracle cares about.
Actually installing and configuring Oracle is a different matter if
you are not familiar with it, but I think the defaults should be
decent for testing. Also, if you are developing off a computer with
limited resources, you may not want to install Oracle.
See here for their downloads overview and the database download page:
http://www.oracle.com/technology/software/index.html
http://www.oracle.com/technology/software/products/database/index.html
If everyone already knew this, I apologize, but like I said, I see a
lot of people saying they don't have access to it.
Thanks,
John
--~--~-~--~~~---~--~~
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: Exceptions documention - #6842
On Aug 27, 9:34 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > The precise location is probably in ref/ although perhaps jacob could > give a better answer. More importantly the way links are done has > been changed, check out > this:http://docs.djangoproject.com/en/dev/internals/documentation/ > for more info, also look at other docs for examples, or ask here or in > IRC. > > Thanks for your work I did see that the links changed format today when looking at another doc ticket. I will update that. Thanks for the feedback, John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Exceptions documention - #6842
Hi, I grabbed ticket #6842 and added a patch that has some documentation for the exceptions Django raises since I needed some of this info:) The file I added, exceptions.txt is not in the right folder after the docs refactor landed between my starting the patch last week and today. I don't know where to put it with the new layout, but moving it is trivial. Also, all the information in it may not be perfect, I did the best I could. This is my first contribution to Django and I am very happy to find a place to help. So I would really appreciate any constructive criticism on the patch. BTW, I am sorry about the timing. I expect this to be post-1.0, I just wanted to get this email out while it was still fresh in my mind. Thanks, John http://code.djangoproject.com/ticket/6842 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
