Re: About the django-core mailing list

On Fri, Sep 10, 2010 at 1:17 AM, Anton Bessonov wrote: > >> I disagree. Although it is normal for a project to have private >> mailing lists, such as -security > > You disagree, but it is normal? Decide for you first. I disagree that there was no explanation necessary. As

Re: About the django-core mailing list

I disagree. Although it is normal for a project to have private mailing lists, such as -security, I'm very glad Jacob took the time to explain the need for its presence in Django. And a big +1 on scheduling releases in public. J. Leclanche On Thu, Sep 9, 2010 at 11:41 PM, Anton Bessonov

Re: Eric Florenzano's presentation slides

Amazingly accurate. J. Leclanche On Wed, Sep 8, 2010 at 9:24 PM, Jeremy Dunck wrote: > http://www.scribd.com/doc/37113340/Why-Django-Sucks-and-How-we-Can-Fix-it > > Presented here without comment, except that video of will be available > (probably on blip.tv) in (hopefully)

Re: Django, The Web Framework for perfectionists and innovative with rechargeable batteries.

> Ignoring language and newbie barriers, it was not a django-dev post, > and clearly had no spark of idea.  I think jacob and others are > extremely fair and tolerant in moderating this list. > I agree, it should have been posted on django-users. But (this subject came up before) it could just as

Re: Django, The Web Framework for perfectionists and innovative with rechargeable batteries.

at 10:03 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Fri, Jul 30, 2010 at 3:57 PM, Jerome Leclanche <adys...@gmail.com> wrote: >> Nice job scaring that poor guy who was just trying to be helpful. His >> first post is met with so much hostility and elitism, I can't

Re: Django, The Web Framework for perfectionists and innovative with rechargeable batteries.

[2] People who do have ideas and do write code, but still get rejected because their ideas don't conform to whatever the core devs need in their websites. See? It works both ways. Nice job scaring that poor guy who was just trying to be helpful. His first post is met with so much hostility and

Re: Suggestion: Better handling of HTML entities by slugify()

I wasn't even aware there was a slugify; mine looks something like this[1]." However, if you are passing the actual string "stuffhere" to slugify(), you are escaping it too early. It should go something like slugify(txt), escape(txt), response(txt). This is more of a django-users matter at this

Re: 1.3: Start deprecating mod_python?

Agreed. mod_python was already "not recommended" for very long; now it's dead, I don't see any reason to support it for three full release cycles. On Wed, Jun 23, 2010 at 2:28 AM, Alex Gaynor wrote: > On Tue, Jun 22, 2010 at 6:24 PM, Gustavo Narea

Ticket #11521; Can someone take a look?

Ticket #11521's patch has been sitting in my production server install for months now. I didn't have time to write a test for it (read: I don't currently have time to understand and get familiar with the test suite), so I would really be glad if someone possibly with some ORM experience could take

Re: Decision required: PostgreSQL minimum versions

This is not a "good" thing, in my opinion. There are a lot of features in postgres 8.0, 8.1 and 8.2 which we *should* make available to end users (and even enforce in some cases). Dropping support for old dependencies is a very good thing and hell knows how much fire this sort of thing started in

Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process

On Tue, Apr 20, 2010 at 9:20 AM, orokusaki wrote: > Q: Why do folks turn away constructive criticism with a sarcastic > snicker? > A: "None but the well-bred man know how to confess a fault, or > acknowledge himself in an error." Careful there, some devs might

Re: Process discussion: reboot

If you contribute to open source projects, at one point you'll be faced with the forced choice to use git. It is extremely popular (I believe it's the most popular after svn), and unlike svn it's popular for a good reason. However, hg is decent as well; whatever the django team chooses, as long as

Re: High Level Discussion about the Future of Django

On Sat, Apr 17, 2010 at 4:50 PM, Stephen Wolff wrote: > I feel quite sad reading this thread. Good luck completing 1.2. I only wish > I had time and energy to contribute. I suggest the core team ignore the > thread for now if at all possible. > Yes, let's ignore the

Re: High Level Discussion about the Future of Django

On Sat, Apr 17, 2010 at 6:35 AM, Tom X. Tobin wrote: > On Fri, Apr 16, 2010 at 10:10 PM, Russell Keith-Magee > wrote: >> However, at this point, I would like to tell you a story about four >> people named Everybody,  Somebody, Anybody, Nobody. > >

Issues with .only() and Meta.verbose_name{,_plural} inheritance

The following code reproduces an issue I'm getting on prod with verbose_name. When using .only(), the class changes, and Meta does not get inherited. Trac is being even more terrible than usual, I've been trying to file a bug for the past 15 minutes. I'd love to work on a patch, hopefully get

Re: High Level Discussion about the Future of Django

Without trying to defend anyone or anything here... Why ask other developers to ignore an otherwise healthy discussion? I believe Russ engaged in the discussion because he's interested; if not in the idea, at least in discussing it. Not everything has to be backed up with code... J. Leclanche /

Re: High Level Discussion about the Future of Django

. Leclanche / Adys On Mon, Apr 5, 2010 at 10:48 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Mon, Apr 5, 2010 at 3:30 PM, Jerome Leclanche <adys...@gmail.com> wrote: >> If you're going to use such an ancient version of a distribution, you >> are only crip

Re: High Level Discussion about the Future of Django

If you're going to use such an ancient version of a distribution, you are only crippling yourself. As you said yourself, you should move on; if someone is using Python 2.3, they can use Django 1.1/1.2. If they want all-new 1.3 features, then updating Python/distro should not be a roadblock. This

Re: proposal: ask a queryset to not raise exceptions

A couple of things: * Technically, a queryset doesn't raise DoesNotExist; a model does. When you call latest(), you call the latest model in the queryset, which, in the case of an empty qs, raises DoesNotExist * (bite me) I work with lossy data and very often have to deal with broken relations.

Re: truncate filter

http://groups.google.com/group/django-developers/browse_thread/thread/924112bf84709225?pli=1 http://code.djangoproject.com/ticket/5025 The proper solution would be a truncate filter, unfortunately, the ticket is still sitting on "Design decision needed". (Could someone PLEASE just take a design

Re: Adding a new convenience filter 'contains_any'

On Thu, Mar 4, 2010 at 11:05 PM, Gabriel Hurley wrote: > The Django Developers list for discussion of the development of Django > itself. Please ask questions related to using Django on django-users, > not here. This looks very django-development-related to me. Having

Re: QuerySet.exists() - Possible bug?

ation") >>> MyModel.objects.all()[:1][0].my_relation.exists() J. Leclanche / Adys On Wed, Feb 10, 2010 at 9:22 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Wed, Feb 10, 2010 at 3:11 PM, Jerome Leclanche <adys...@gmail.com> wrote: >> Hi lis

QuerySet.exists() - Possible bug?

Hi list Using David Cramer's really nice replacement devserver (http://github.com/dcramer/django-devserver), I noticed a bunch of huge queries in some table generation code. Example: http://dpaste.com/156907/ This is from one of my smallest tables, bigger ones with 120+ish rows can take multiple

Re: TimeField for duration

Which is exactly what I'm doing using a BigIntegerField... J. Leclanche / Adys On Thu, Jan 21, 2010 at 1:57 AM, Olivier Guilyardi <m...@xung.org> wrote: > On 01/21/2010 12:44 AM, Jerome Leclanche wrote: >> >> Main issue is precision. I personally very, very often work

Re: TimeField for duration

Łukasz Rekucki <lreku...@gmail.com>: > Hi, if i'm wrong, please ignore this post ;) > > 2010/1/21 Jerome Leclanche <adys...@gmail.com>: >> A decimal backend was a lot worse than a bigint backend on that matter >> (slower, made a lot less sense as well). >> >&

Re: TimeField for duration

010 12:14 AM, Jerome Leclanche wrote: > >> Keep in mind, TIME fields are for storing time, not for storing >> durations. For durations, postgres has an INTERVAL field (cf ticket), >> however not every database has that field type. > > Not in MySQL, from the official docs:

Re: TimeField for duration

had to strip down the patchset. J. Leclanche / Adys On Thu, Jan 21, 2010 at 1:02 AM, Olivier Guilyardi <m...@xung.org> wrote: > On 01/20/2010 11:46 PM, Jerome Leclanche wrote: >> >> I've worked on a DurationField implementation (ticket: >> http://code.djangoproject.

Re: TimeField for duration

Hi Olivier I've worked on a DurationField implementation (ticket: http://code.djangoproject.com/ticket/2443). However I was extremely displeased with the whole DecimalField backend. With the recent addition of BigIntegerField, I am now saving durations with a bigint and mapping them to timedelta.

Re: Porting Django to Python 3

Best of luck in your port. On that note, I'm hoping when the 3k port will be officially supported, it will not be backwards compatible. The core idea of 3k itself is the lack of backwards compatibility ... J. Leclanche / Adys On Fri, Jan 8, 2010 at 8:25 PM, Dave wrote: >

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

sible. I'm pretty sure that's what all of us in this thread want. J On Thu, Dec 31, 2009 at 7:58 AM, Russell Keith-Magee <freakboy3...@gmail.com > wrote: > On Thu, Dec 31, 2009 at 12:54 AM, Jerome Leclanche <adys...@gmail.com> > wrote: > > On Wed, Dec 30, 2009 at 2:06 PM,

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Right, sorry -- I'm gonna have to go with Eric on that, there are builtin libraries that do just that (from unicodedata import normalize). J. Leclanche / Adys On Thu, Dec 31, 2009 at 1:30 AM, James Bennett <ubernost...@gmail.com>wrote: > On Wed, Dec 30, 2009 at 5:05 PM, Jerome Leclan

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

e this and they will get an answer. Asking for people to "stop saying +1" just makes you look like you don't want people disagreeing with you. J. Leclanche / Adys On Thu, Dec 31, 2009 at 12:46 AM, James Bennett <ubernost...@gmail.com>wrote: > On Wed, Dec 30, 2009 at 2:35 PM, Jero

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

What's this supposed to mean? If something is trivial to implement, it shouldn't be in the core? Tell me I'm reading it wrong, please, because I can think of 1000 reasons why this argument doesn't hold ground. J. Leclanche / Adys On Wed, Dec 30, 2009 at 11:39 PM, Alex Gaynor

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

PS; I don't see anybody "just saying +1". So far everyone has explained why they agree with inclusion, which is not the case of most of the (very few) comments against inclusion. J. Leclanche / Adys On Wed, Dec 30, 2009 at 10:29 PM, Alex Gaynor wrote: > Ok, we get it,

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 10:29 PM, Alex Gaynor wrote: > Ok, we get it, some people want this feature. I'd like to kindly > request that people just saying "+1" stop. The number of people in > this thread is minuscule compared to the size of the django user > population,

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

single person who has ever asked for a "truncate filter" is wrong? because there's a hell of a lot of them. J. Leclanche / Adys On Wed, Dec 30, 2009 at 8:37 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Wed, Dec 30, 2009 at 11:21 AM, Jerome Leclanche <adys

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 8:02 PM, Ian Kelly wrote: > > What I haven't seen yet for this filter is a clear use case. If > you're just trying to get something working quickly, then slice is > fine. When you're ready to go back and do it right, then the optimal > solution is

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 2:06 PM, Russell Keith-Magee wrote: > Secondly, IMHO raw truncation based on characters is bad practice for > human readable text. A sentence is composed of words, not characters. > Truncating a sentence mid-word isn't a typographical practice

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Will, I meant its usage on strings. Admittedly, it's probably not the best thing to do. On Wed, Dec 30, 2009 at 8:11 AM, Thomas K. Adamcik <tadam...@gmail.com>wrote: > On Wed, Dec 30, 2009 at 08:04:47AM +0200, Jerome Leclanche wrote: > > Users expect it to be called "t

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Users expect it to be called "truncate", that alone is sufficient reason. There's truncate_html, truncate_words. Deprecate slice, move it to "truncate" and add the ellipsis for consistency. No harm done, happy users. J. Leclanche / Adys On Wed, Dec 30, 2009 at 8:01 AM, Alex Gaynor

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Last time I asked on IRC, dev answer was "because nobody asked for it". Of course one could cat ~./irc/logs/django | grep -i truncate and just look at how ridiculous that statement is. Unfortunately, more often than not, the needs of the developers don't leave room for contributions from other

Re: Proposal for new field type: CompositeField

I like it, always wondered if there was a way to do this in the core. Hope the patch gets through. J. Leclanche / Adys On Fri, Dec 25, 2009 at 1:22 AM, Michael P. Jung wrote: > On 2009-12-24 19:45, Stephen Crosby wrote: > > In your address example, I'm not sure what

Re: Deprecating psycopg 1

-switch. (Disclaimer: I never use warnings) J. Leclanche / Adys On Sat, Dec 12, 2009 at 6:22 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Sun, Dec 13, 2009 at 8:13 AM, Jerome Leclanche <adys...@gmail.com> wrote: >> +1 from me too on

Re: Deprecating psycopg 1

+1 from me too on the timeline, but why the PendingDeprecationWarning? I don't see the point, there isnt exactly a limit to how long something can be deprecated. J. Leclanche / Adys On Sat, Dec 12, 2009 at 6:04 PM, Alex Gaynor wrote: > On Sat, Dec 12, 2009 at 7:02 PM,

Re: __in and comma-separated strings.

Right. I'll experiment a bit more with this and look for a better solution than comma-splitting. J. Leclanche / Adys On Tue, Oct 27, 2009 at 6:39 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > > On Tue, Oct 27, 2009 at 11:36 AM, Jerome Leclanche <adys...@gmail.com> wro

Re: __in and comma-separated strings.

On Tue, Oct 27, 2009 at 6:23 PM, Alex Gaynor wrote: > > I meant precisely what I said, comma separating values in a GET string > is a fairly arbitrary means of serializing a value, in past I've seen > other characters used (or just having multiple values in the >

Re: __in and comma-separated strings.

uot;. What else would you propose? J. Leclanche / Adys On Tue, Oct 27, 2009 at 6:08 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > > On Tue, Oct 27, 2009 at 10:57 AM, Jerome Leclanche <adys...@gmail.com> wrote: >> I've got a patch to let __in accept comma-separated

__in and comma-separated strings.

I've got a patch to let __in accept comma-separated strings; I'm using this locally to avoid going through the trouble of splitting a string before processing a GET. The exact same technique is used in django-admin, and I'd bet many other apps as well. Is there a reason why this behaviour isn't

Re: Proposal for __neq field lookup

This is something I attempted once to do over a small GET wrapper by adding __not; any __not query would be passed to exclude(). Would that be a solution to the problem? J. Leclanche / Adys On Tue, Oct 20, 2009 at 6:31 PM, Michael P. Jung wrote: > > rm>

Re: Proposal: Better HTML4 support

This is unrelated Andreas. HTML5 has the exact same syntax as HTML4, just new tags. This thread is about syntax. By the way, neither html4 nor xhtml are deprecated. HTML5 is still not "officially released". J. Leclanche / Adys On Mon, Sep 28, 2009 at 12:12 PM, Andreas

Re: Proposal: Better HTML4 support

xhtml and html? So on. I'm all for a better abstraction, but it needs to be thought twice before adding features "just because". J. Leclanche / Adys On Sat, Sep 26, 2009 at 8:50 AM, Jerome Leclanche <adys...@gmail.com> wrote: > This is a non-issue. > > Correct me if

Re: Proposal: Better HTML4 support

This is a non-issue. Correct me if I'm wrong, but is valid html syntax. It's parsed as valid by every html parser, and I'm positive this is the entire point of xhtml: staying backwards-compatible with html. J. Leclanche / Adys On Sat, Sep 26, 2009 at 7:48 AM, Rob Hudson

Re: Accepting foreignkey assignment by PK on QuerySet.update() (#11521)

On Fri, Sep 11, 2009 at 5:03 PM, Karen Tracey wrote: > > Why doesn't it have a test? I'll write one then. > Mentioning in the description that the fix may be a hack might not have been > the best idea. It's not "may", it's "I don't know". I'm not an ORM expert either,

Accepting foreignkey assignment by PK on QuerySet.update() (#11521)

Could someone give some feedback on #11521? (http://code.djangoproject.com/ticket/11521) It's been sitting for almost 3 months without any kind of answer. The current patch is a 2-line change which looks very reasonable, but I'd love to be aware of any possible side effect of that change. J.

Re: Proposal for contrib feature (DictionaryField in models)

Might be slightly off-topic, but, if that's the main criterion, are we ever going to include django-tagging in contrib? J. Leclanche / Adys On Wed, Aug 12, 2009 at 3:20 AM, Russell Keith-Magee wrote: > > Regardless of my opinion, this is a feature that can happily live

Re: Why are checkboxes *still* like this?

I already opened a ticket about this, it was creating problems with some custom MultiSelectFields. http://code.djangoproject.com/ticket/11422 J. Leclanche / Adys On Sun, Jul 26, 2009 at 3:19 PM, Russell Keith-Magee wrote: > > On Sun, Jul 26, 2009 at 9:53 AM,

Re: DurationField, request for help and comments

Gul, appreciate the feedback. Right now, removing months and years is a matter of removing two lines from the patch. I didn't want to write a patch just to get told "it's lacking months/years!"; I'm also in favour of dropping it and following Python's style; but up until now no one except

Re: DurationField, request for help and comments

tch on ticket #2443 earlier today to apply cleanly to current trunk. It's the one I've been using today and I haven't found any other issue. On Tue, May 26, 2009 at 7:44 PM, Yuri Baburov <burc...@gmail.com> wrote: > > Hi Jerome, > > On Mon, May 25, 2009 at 9:27 AM, Jerome Leclanc

Re: DurationField, request for help and comments

Oh, disregard the second question, I wasn't fully awake :-) J On Mon, May 25, 2009 at 5:27 AM, Jerome Leclanche <adys...@gmail.com> wrote: > Hi Yuri, thanks for the fixes. Two questions: > > - Why mention *args at all (l20,21) if it's to assert they don't exist? > - Any

Re: DurationField, request for help and comments

Hi Yuri, thanks for the fixes. Two questions: - Why mention *args at all (l20,21) if it's to assert they don't exist? - Any idea where to put the TimeDelta class? I still don't believe it belongs in django.widgets, but I'm not familiar enough with the structure to know where to put it. Cheers,

Re: Posting to the wrong list (was: Re: Need Django Developer urgent)

Perhaps emphasis on "contributors" rather than "developers"? J On Fri, May 8, 2009 at 4:32 PM, Justin Lilly wrote: > > As an alternative, we could try FRAMEWORK for extra emphasis. Perhaps > a bit janky, though. > >  -justin > > > > On May 8, 2009, at 9:24 AM, Marty

Re: A Letter to the Authors of Web Authentication Libraries

Is there a fallback to normal auth possible if js is not running? I like the idea, but preventing someone who doesn't have js enabled to register/auth is pretty harsh. On Sun, May 3, 2009 at 6:27 AM, Paul Johnston wrote: > > Hi, > > Many web sites have a user name and

Re: My Proposal [GSoC '09 Admin UI Improvements]

> # Disable selecting dates before or after a certain date This sounds like it should be general behaviour (adding min_date and max_date to DateField or something similar - I thought this was already in?). I've got a couple more comments on admin UI in general, if you want to take a bite at

Re: Creating "lazy" foreign keys

Sounds like that wouldn't work. Django fails on __init__ with invalid foreignkeys. On Tue, Feb 24, 2009 at 3:24 AM, join.toget...@gmail.com wrote: > > On Feb 22, 10:30 pm, Adys wrote: >> Not sure I follow you. You mean overriding the set property of