Re: Two proposals for the Django Code of Conduct.

Benjamin, 1. It's not a zero-tolerance policy, and it never has been. So all of your arguments based on that idea are null and void. 2. The only instance of "abuse" of the policy relates to behavior that was inappropriate even given cultural differences. Just because you don't understand somethin

Re: Two proposals for the Django Code of Conduct.

Benjamin, Out of your three links only the 3rd describes an actual harassment > occurring at a Django-related event. Actually, even the third link doesn't describe harassment occuring at a Django-related event. It described harassment by a Django community member at a non-Django event. And it de

Re: Two proposals for the Django Code of Conduct.

Benjamin, I believe there have been serious issues with harassment of women specifically at previous DjangoCons (though there may not be mention of it on the mailing lists.) It has definitely been a major issue at other tech conferences and tech meetups. That was a major factor in the recent push

Re: Two proposals for the Django Code of Conduct.

If you think you could do it better, maybe you should submit your own version for consideration. I assume that's how the process works. On Mon, Sep 8, 2014 at 11:20 AM, Benjamin Scherrey wrote: > Daniele, > > You're reading me completely wrong. I am not being sarcastic at all. > I'm pointin

Re: Two proposals for the Django Code of Conduct.

, 2014 at 12:30 AM, Stephen Burrows < stephen.r.burr...@gmail.com> wrote: > Ben, > > Just to clarify, it sounds like what you're saying is the following: If > there were a member of the django community who (may this never be the > case) was harassing members of the django co

Re: Two proposals for the Django Code of Conduct.

Ben, Just to clarify, it sounds like what you're saying is the following: If there were a member of the django community who (may this never be the case) was harassing members of the django community, but limited their harassment to non-django-specific forums, you would want it to not affect their

1.7 release?

It's been a while since I've heard anything about the 1.7 release - but it looks like there aren't any release blockers left . And there weren't any the last time I checked either. What's th

Re: Tests of contrib apps

The tests are nested whether they're in the core tests or in contrib. Philosophically this is more a question of coding at a distance. Putting the tests in /tests makes it less obvious which app they actually belong to. Additionally, I'd see the fact that it would be impossible to use manage.py

Re: first() and last(), earliest() and latest()

So if I understand correctly, you want something that returns 0-or-1 objects, without having to do try/except? (Or alternately, try: qs[:1][0] except IndexError.) First of all, I don't understand why first/last are the names you've chosen. This isn't about getting the first object or the last o

Re: Ticket 19237

... if we're concerned about strip_tags' ability to hit this kind of edge case, why are we using regex? http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 Or more generally http://www.codinghorror.com/blog/2009/11/parsing-html-the-

Re: Django Admin Revamp - Any updates?

There is a project to create a third-party django admin. It is currently moving slowly, but it does have basic admin functionality. https://github.com/django-djam/django-djam irc: Freenode/#django-djam (if you want to ping me about it.) --Stephen On Friday, November 16, 2012 7:41:05 AM UTC-8, C

Re: Add a "split" field to a model causes problems

I've opened a ticket to track this issue. On Tuesday, October 23, 2012 3:52:10 AM UTC-7, Andrew Ingram wrote: > > Hi all, > > This one stung me today. Basically as part of an event (calendar) app, I > have functionality for splitting a series of even

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

; > On Tuesday, October 9, 2012 7:28:43 AM UTC+2, Stephen Burrows wrote: >> >> I'm a little confused by the track the discussion took recently... my >> impression was that the solution would *not* be to change from >> last_modified to a checksum, or to add an ad

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

I'm a little confused by the track the discussion took recently... my impression was that the solution would *not* be to change from last_modified to a checksum, or to add an additional checksum method. Instead, storage backeds could support a has_changed method, which could be overridden to pr

Anyone have time for a 5-for-1?

If there are any core devs with time for it, I'd like to cash in some triage. I've triaged: https://code.djangoproject.com/ticket/15338 https://code.djangoproject.com/ticket/16630 https://code.djangoproject.com/ticket/18413 https://code.djangoproject.com/ticket/12836 https://code.djangoproject.co

Re: #16630: Support for HTML5 input types

Hey all - Last I heard, today was the last day for new features for 1.5. I was triaging tickets yesterday and ran this ticket. [1] The ticket looks fine, and it addresses the issues raised here. The only new issue (raised on the ticket) is that this change could break third-party javascript and

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

I use S3 as well, and I have seen cases where files get copied that I know don't need to be. That being said, it was never so slow that it was an issue for me. Is there clear evidence that this is something which can't be handled by the S3 backend due to an inadequate API on the django side? --

Re: ModelForm enforces its version of save_m2m

It's definitely possible for users to support commit=False. If you call form.save(commit=False), you can then store form.save_m2m in a temporary variable, define a new save_m2m function, and then call the old function from the new. Here's sort of an example: https://github.com/pculture/mirocomm

Dogfood the new class-based views in contrib.syndication?

I was recently working with django's syndication framework, and noticed that it felt clunky in a lot of ways. For example, I can only access the request and the kwargs for the function during the get_object method; if I want to do anything more complicated with them - for example, say I want to

Re: Proposal: upgrading the choices machinery for Django

I generally like this idea, except for the implicit integer ids based on declaration order. As people have said, it seems like just asking for data corruption. I'd much rather see implicit character ids based on the attribute name of the choice, analogous to django fields. Will you be making this

Re: Revisiting multiline tags

> Personally, I would like to be able to see a tag all at once (that is > without scrolling), even though I might have to scroll to get to the > start of it.  I believe this improves readability of the template. My > specific use case is with include tags with long template paths and > added contex

Re: Feature Request: Client side validation classes for forms

The problem I've run into with client-side validation of django projects is: 1) If you can't replicate every piece of validation the server does, the user experience will be inconsistent, which is bad. 2) You can't replicate every piece of validation the server does. Simple example: uniqueness che

Re: Deprecate change pk + save behavior for 1.4

I've often longed for a "read-only" concept in ModelForms. For example, if I want the "site" field to always have a certain value (i.e. the current site) but also want to enforce multiple-column uniqueness (i.e. slug/site). I can write it myself, but it always feels like I shouldn't have to. Probab

Re: load template tag library

I second what Luke and Russ have already said. If what you're interested in is a way to securely allow users to enter template code into the database, you can just write a custom field that validates its input for security problems. Here's a third-party implementation of a validator for such a fi

Re: contrib.sessions test oddities

some of what you're experiencing. Best, Stephen Burrows On Oct 4, 9:22 pm, Justin Holmes wrote: > I posted this message on -users today, but at PaulM's urging, I'm > bringing it over here out of concern that it may reflect a bug in the > contrib.sessions test suite. > >

Re: deprecation vs removal

mand, etc, that still works but has been replaced. - en.wikipedia.org/wiki/Deprecate Best, Stephen Burrows On Oct 2, 2:07 am, Łukasz Rekucki wrote: > 2011/10/2 Alexander Schepanovski :> Then when I > upgrade django I'll just upgrade it and fix> any wrong calls, imports, >

Re: confusing things in Trac UI (was: Design decision for #1625...)

nce. Ticketeer should. https://github.com/melinath/django-ticketeer Best, Stephen Burrows -- 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 fro

Re: Weekly Check-in

> I found some use cases that are not yet possible with the form rendering > template tags. The biggest issue is that it's not possible to exchange field > labels with translated text. Currently there is no way of storing a translated > string in the templates as variable, like {% trans "foo" as va

Re: initial_data and post_syncdb conflicts

Perhaps I'm missing something... initial_data is "test-only", right? As opposed to other fixtures which should always be loaded? Then why would the other fixtures rely on the initial_data? On Aug 18, 4:15 pm, David Cramer wrote: > We've been working on switching our test suite to use some new "su

Re: How do add ancillary, display-only data to each form in a formset?

This post seems to be squarely in django-users territory, not django- developers. Perhaps the discussion could continue there? On Jul 22, 9:25 pm, Andre Terra wrote: > I'm on my phone, and therefore read your message really quickly, so > excuse me if I misunderstood the issue. > > A few questions

Re: Admin inlines and fieldsets

Hey, I reopened the ticket and suggested a syntax that would make more sense to me than the options already presented there. Best, Stephen On Jun 27, 10:00 am, Russell Keith-Magee wrote: > On Mon, Jun 20, 2011 at 7:51 PM, Aymeric Augustin > > > > > > > > > > wrote: > > Hello, > > Ticket #10938 [

Re: "c" date formating and Internet usage

quot;c" > behaviour should be useful (naive and non naive datetime). And maybe to warn > about the non consistent behaviour of Django depending on the date formater > used. > > Yohan > > 2011/6/27 Ian Clelland > > > > > > > > > On Sun, Jun 26, 20

Re: Timezone-aware storage of DateTime

would need to be a separate field in the database to store the timezone. On Jun 27, 3:12 pm, Sam Bull wrote: > On 2011-06-02, at 12:34 AM, Stephen Burrows wrote: > > > Django actually already adds support for some capabilities to certain > > database backends, if I'm not

Re: "c" date formating and Internet usage

This is related to the recent discussion about timezone-aware datetime storage [1] and how django doesn't do it. Since the date filter's "c" argument is handled with python's datetime.isoformat() [2] timezone- naive datetimes will not display a UTC offset. [1] http://groups.google.com/group/djang

Re: 5-for-1?

le-posting, but you can check it out > here:https://github.com/trapeze/fancy_tag > > It's got unit tests, keyword argument support (like the new with tag), *args > support, **kwargs support, and support for the "with " pattern. > > Is this something I should convert

Re: 5-for-1?

oject.com/ticket/13956 On Jun 7, 12:24 pm, Carl Meyer wrote: > Hi Stephen, > > On 06/07/2011 02:37 AM, Stephen Burrows wrote: > > > Hi - is the 5-for-1 deal still active on ticket reviews? [1] > > If so, I've reviewed the following tickets: > > > 3624 > >

Re: Django Error Display Page

On Jun 10, 3:34 am, Dougal Matthews wrote: > On Friday, 10 June 2011 at 04:31, Valentin Golev wrote: > > What I'd really like is a stacktrace in a plain text in the html > > commentary ("") on the very top of the page. > > +1 > > This would actually be very useful when debugging Ajax calls in brow

5-for-1?

Hi - is the 5-for-1 deal still active on ticket reviews? [1] If so, I've reviewed the following tickets: 3624 16152 16157 16158 16166 And would love it if someone could have a look at ticket 14082 [2]. If not, ah well. :-) Best, --Stephen Burrows [1] http://groups.google.com/group/d

Re: Vote on {% include %} behaviour.

#12008 was repurposed as a documentation improvement because the current implementation is correct and just needs to be explained better. As for the other two... I agree that consistency is important, and that it would make sense (in a way) for ConstantIncludeNode to either always raise or always s

Re: Timezone-aware storage of DateTime

Django actually already adds support for some capabilities to certain database backends, if I'm not mistaken - such as cascades through GFKs on delete. In terms of time zones, could django "assume"/ensure that the datetime stored in the backend is UTC, then handle the conversion to the local timez

Re: Proposal: switch to HTML5 for bundled templates

Anyone interested in reading about html5 can find a lot of great information at http://diveintohtml5.org/. Some of the highlights: 1. a change to the doctype of the admin from http://www.w3.org/TR/xhtml1/DTD/xhtml1- strict.dtd"> to should still keep ie6 in Almost Standards Mode [1] 2. Browsers

Re: type-field model inheritance

It sounds like you want to make polymorphic models - queries that retrieve various types of objects. There's an implementation of this: https://github.com/bconstantin/django_polymorphic On Mar 2, 9:07 pm, Craig de Stigter wrote: > I realise everyone's been busy with getting 1.3 ready, but doesn't

Re: Getting Slammed Hard on Foreign Keys in the admin due to __unicode__

Though it's a little hard to tell from your post, this sounds more like it's definitely a case where your code needs improvement. From what I understand, the database hits are coming from your custom AJAX, not from the admin's default behavior. Also, you already know the solution: use select_relate

Re: Inheritance of rel fields from base classes should not cause conflicts if the base classes involved are all abstract.

provement, docs, and tests; I plan to do that next week. Best, Stephen Burrows On Feb 10, 1:48 am, Russell Keith-Magee wrote: > On Wed, Feb 9, 2011 at 1:43 AM, Stephen Burrows > > > > > > > > > > wrote: > > Hi! I was going to submit this as a ticket, but I glan

Inheritance of rel fields from base classes should not cause conflicts if the base classes involved are all abstract.

y also need to move the get_FIELD_display method declaration [2] into cls._meta.add_field.) If this is an acceptable idea, I would be happy to add tests and docs. If the general idea is acceptable, but the implementation is flawed, I would be happy to write patches using other methods that people may

Re: annotating fields with null=True

Perhaps I'm missing something, but if you count all the defined foreign keys AND all the null values, won't you just end up with a count of the parent model? Or are you saying that you explicitly want to count how many values are null *instead of* defined? On Jan 25, 2:39 pm, Sergiy Kuzmenko wrot

Re: Problem with ``Model.objects.create``

Just to clarify, an IntegrityError is raised if "the relational integrity of the database is affected, e.g. a foreign key check fails, duplicate key, etc." [1] Since the creation of a model instance doesn't affect the database, it should definitely not raise an IntegrityError. Additionally, blank=T

Ticket 14567 bump/update (ModelMultipleChoiceField: self.queryset.none() vs. [])

sting topics, as it's a fairly simple change, but I was wondering if there's anything I should be working on to get this ready for commit. I'd rather not have to continue making minor updates to make sure the patch continues to match trunk. Best, Stephen Burrows -- You received this

Re: Bump/question for #13956

As far as I know, the only thing still missing from the ticket is a decision as to whether there need to be documentation changes for simple tags and inclusion tags... if there need to be changes, I could try working on them. I would just need to know. Best, Stephen -- You received this message b

Re: Bump/question for #13956

Thanks for the suggestion. I've added tests for the inclusion tags, so now everything is being tested that I could think of - with the exception of inclusion tags that have takes_context=True. Really, though, they should act the same way from the tag's point of view. The only difference is that if

Re: Patch: Indefinite args for simpletags and inclusion tags

I went ahead and made a ticket with the patch. Thanks! http://code.djangoproject.com/ticket/13956 --Stephen On Jul 16, 1:25 pm, Tobias McNulty wrote: > On Fri, Jul 16, 2010 at 1:07 PM, Stephen Burrows < > > stephen.r.burr...@gmail.com> wrote: > > Before posting the patch

Patch: Indefinite args for simpletags and inclusion tags

Hi, I've patched django to allow indefinite args for simple tags and inclusion tags. My impetus for doing so was as follows: I have a project that registers inclusion template tags for methods on objects in a registry. (http://github.com/melinath/pipettes/blob/ master/templatetags/pipettes.py) In