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 Graham very
elegantly pu
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 wrote
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) a few weeks.
>
> -
> 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
10 at 10:03 PM, Jacob Kaplan-Moss wrote:
> On Fri, Jul 30, 2010 at 3:57 PM, Jerome Leclanche 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 imagine
>> being him right now.
&
[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 el
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
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 wrote:
>> Whoops, I wan't aware of this topic w
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
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
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 tweet-call troll while you're not wa
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
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 users and all the other major
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.
>
> This is exactly why I try not to bitch too much a
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 this
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 / Ad
y happening.
J. Leclanche / Adys
On Mon, Apr 5, 2010 at 10:48 AM, Russell Keith-Magee
wrote:
> On Mon, Apr 5, 2010 at 3:30 PM, Jerome Leclanche wrote:
>> If you're going to use such an ancient version of a distribution, you
>> are only crippling yourself. As you said yourself, y
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 i
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. I'
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 de
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 hacked-about
a __band filter
ed_name="my_relation")
>>> MyModel.objects.all()[:1][0].my_relation.exists()
J. Leclanche / Adys
On Wed, Feb 10, 2010 at 9:22 AM, Russell Keith-Magee
wrote:
> On Wed, Feb 10, 2010 at 3:11 PM, Jerome Leclanche wrote:
>> Hi list
>>
>> Using David Cram
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 m
Which is exactly what I'm doing using a BigIntegerField...
J. Leclanche / Adys
On Thu, Jan 21, 2010 at 1:57 AM, Olivier Guilyardi wrote:
> On 01/21/2010 12:44 AM, Jerome Leclanche wrote:
>>
>> Main issue is precision. I personally very, very often work with
>> milli
/1/21 Łukasz Rekucki :
> Hi, if i'm wrong, please ignore this post ;)
>
> 2010/1/21 Jerome Leclanche :
>> A decimal backend was a lot worse than a bigint backend on that matter
>> (slower, made a lot less sense as well).
>>
>> Keep in mind, TIME fields are for
This is going to be extremely inconsistent between databases. Feel
free to base yourself on my patch, but good luck implementing 4-5
implementations and keeping them abstract...
J. Leclanche / Adys
On Thu, Jan 21, 2010 at 1:36 AM, Olivier Guilyardi wrote:
> On 01/21/2010 12:14 AM, Jer
had to strip
down the patchset.
J. Leclanche / Adys
On Thu, Jan 21, 2010 at 1:02 AM, Olivier Guilyardi wrote:
> On 01/20/2010 11:46 PM, Jerome Leclanche wrote:
>>
>> I've worked on a DurationField implementation (ticket:
>> http://code.djangoproject.com/ticket/2443
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.
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:
> Hello everyone,
>
> M
oth as
possible. 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 wrote:
> On Thu, Dec 31, 2009 at 12:54 AM, Jerome Leclanche
> wrote:
> > On Wed, Dec 30, 2009 at 2:06 PM, Russell Keith-Magee
> > wrote:
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 wrote:
> On Wed, Dec 30, 2009 at 5:05 PM, Jerome Leclanche
> wrot
a filter), voice them just like 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 wrote:
> On Wed, Dec 30, 2009 at 2:
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 wrote:
> On Wed, D
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, some people want this fea
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, trying to extrapolate fro
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 wrote:
> On Wed, Dec 30, 2009 at 11:21 AM, Jerome Leclanche
> wrote:
> >
> > On Wed, D
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 to use CSS [1]. If you
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 that I
> particularly want to
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 wrote:
> On Wed, Dec 30, 2009 at 08:04:47AM +0200, Jerome Leclanche wrote:
> > Users expect it to be called "truncate", that al
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 wrote:
> O
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 use
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 advantage this
> > Composit
warning with --some-switch.
(Disclaimer: I never use warnings)
J. Leclanche / Adys
On Sat, Dec 12, 2009 at 6:22 PM, Russell Keith-Magee
wrote:
> On Sun, Dec 13, 2009 at 8:13 AM, Jerome Leclanche wrote:
>> +1 from me too on the timeline, but why the PendingDeprecationWarning?
>>
+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, Jacob Kaplan-Moss wrote:
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 wrote:
>
> On Tue, Oct 27, 2009 at 11:36 AM, Jerome Leclanche wrote:
>> Point still stands, it's imp
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
> querystring such as a=3&a=4), ass
n format". What else would you propose?
J. Leclanche / Adys
On Tue, Oct 27, 2009 at 6:08 PM, Jacob Kaplan-Moss wrote:
>
> On Tue, Oct 27, 2009 at 10:57 AM, Jerome Leclanche wrote:
>> I've got a patch to let __in accept comma-separated strings; I'm using
>> th
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 d
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> exclude(x=1).exclude(y=2) translates t
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 wrote:
>
> html4 is dere
only after 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 wrote:
> This is a non-issue.
>
> Correct me if I'm
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 wrote:
>
> Or: Why i
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,
hence the feedback reques
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. Lecl
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
> external to the Django c
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, judgej wrote:
> >
> >
> >
> http:/
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 yoursel
dated the patch 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 wrote:
>
> Hi Jerome,
>
> On Mon, May 25, 2009 at 9:27 AM, Jerome Leclan
Oh, disregard the second question, I wasn't fully awake :-)
J
On Mon, May 25, 2009 at 5:27 AM, Jerome Leclanche 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 idea where to
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, I
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 Alchin wrote:
>
>>
>> On Fr
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 password login system, and
On Sat, Apr 25, 2009 at 7:40 AM, Alex Gaynor wrote:
>
> I'm a little considered with the UI considerations of using one mechanism in
> multiple ways. We looked at having admin actions that could support all
> objects and specifically rejected it since it overloaded that UI element in
> a way tha
Apr 24, 2009 at 9:13 PM, Jerome Leclanche wrote:
>>
>> For one it's kind of annoying the FKey/m2m/etc don't link either to
>> the corresponding object's admin or site page if either are available
>> (checking for admin first, then for site?). The fix should
> # 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 them.
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 a
>> ForeignKey/IntegerField?
>>
>> On Feb 23
66 matches
Mail list logo
