On 2020-03-02 18:35, Anna Sidwell wrote:
> Is there any particular reason why it shouldn't look like a button
> instead of a link?
The concern isn't how it looks (with CSS you can make a button look
like a link, or make a link look like a button).
An does the logout action via a GET (and is the
On 2017-05-15 08:54, Tim Graham wrote:
> Does anyone know of a use case for using null bytes in
> CharField/TextField?
Is this not what BinaryField is for? It would seem to me that
attempting to store binary NULL bytes in a CharField/TextField should
result in an error condition.
-tkc
--
You
On 2017-03-07 07:17, Jacob Kaplan-Moss wrote:
> It's certainly _possible_ to implement a in-memory datastore, and
> it might be pretty useful. It's just pretty dang hard to do more
> than the first 20% or so.
Would there also be issues with WSGI spinning up/down various Django
processes? Any in-m
On 2015-11-11 14:44, Collin Anderson wrote:
> Also, doing this from the backend seems like sub-par way to do it.
> I would recommend implementing this in javascript, so it can
> auto-update over time if you leave the window open.
It shouldn't be limited to one or the other: doing it on the
back-e
On 2015-09-22 07:49, Aymeric Augustin wrote:
> > And for your concern, there will be a MaxLengthValidator added to
> > the validators to validate the users input does not exceed the
> > database backends maximum length just like when you set
> > max_length explicitly.
>
> This isn’t possible in a
On 2015-02-27 06:12, Josh Smeaton wrote:
> The concept of batched SELECT statements doesn't really exist in
> SQL, unless the relations you're selecting have identical column
> types. Example:
>
> SELECT name, age_in_years FROM person
> UNION ALL
> SELECT item_name, quantity FROM item;
>
> The UN
[slightly reordered]
On 2015-02-04 18:25, Collin Anderson wrote:
> Also, did we decide if the Model-field-layer or Form-field-layer
> would be better?
I think the Form-field layer is definitely the place for it. If I do
my_model.my_text_field = " leading and trailing "
I expect that value to
On 2015-02-03 10:31, Aymeric Augustin wrote:
> Your request boils down to "make Django's CSRF protection of HTTPS
> pages vulnerable to MITM attacks" which isn't acceptable.
If you've got a MITM that can intercept HTTPS, is there any reason to
assume they aren't in a position to spoof DNS as well,
I've had a couple cases where browser link pre-fetching triggered
an unintended logout from my Django app (I haven't fully tracked down
the exact combination of triggering conditions, but I suspect they
similar to Israel Brewster's CherryPy issue mentioned on
comp.lang.python [1]) and was surprised
On 2014-08-10 01:06, Josh Johnson wrote:
> Django documentation is phenomenal,
I second Josh's comment. I'd naively assumed that all "big Python
web-framework" documentation was as good as Django's. However, when I
had to do some work on a contract involving CherryPy and
SQLObject...marcy was it
n 2014-01-20 20:22, Aymeric Augustin wrote:
> The alternative is to modify INSTALLED_APPS to support passing
> arguments to the AppConfig class. But I find it rather ugly.
[I've only been lurking in this thread, so take with a grain of salt;
just throwing it out there to see what sticks]
Would i
On 2013-10-16 11:10, Javier Guerra Giraldez wrote:
> On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger
> wrote:
> > However, it does so by blurring the distinction between GET and
> > POST parameters, which like other people here, I find
> > disturbing.
>
> care to elaborate about that distinction?
On 2013-09-10 21:05, Russell Keith-Magee wrote:
> So - I think custom Meta options are something that should be
> *possible*. I don't have any particular ideas for how it should be
> implemented, though.
One of the areas I've considered trying this is annotating "private"
information about models.
On 2013-08-08 09:59, Collin Anderson wrote:
>> I am doing something a little different with my CSRF tokens, and
>> I believe it guards against BREACH.
>
> Instead of sending the token in the HTTP response, I am using
> javascript to read (and generate if needed) the CSRF token cookie.
> The javasc
On 2013-08-06 12:53, Donald Stufft wrote:
> On Aug 6, 2013, at 12:16 PM, Tom Scrace wrote:
>> On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss
>> wrote:
>>
>> We plan to take steps to address BREACH in Django itself, but in
>> the meantime we recommend that all users of Django under
On 2013-05-14 10:43, Alex Ogier wrote:
> What happens in the following case?
>
> a = A(dict_field={"hello": "world"})
> d = a.dict_field
> a.save()
> a.refresh()
> d["hello"] = "planet"# does this mutate a.dict_field? does the
> answer change if somebody changed the database in between saving
On 2013-05-11 18:36, Anssi Kääriäinen wrote:
> On 12 touko, 02:55, Russell Keith-Magee
> > What is on the table is essentially adding a refresh() call on an
> > object instance that is an API analog of
> > ".get(id=self.id)"
I guess my minor quibble is about the name itself and possible
clashes w
On 2013-03-26 15:54, Michael Manfre wrote:
> On Tue, Mar 26, 2013 at 12:40 PM, Anssi Kääriäinen
> deal with limit/offset. A generic approach would be nice to have,
> but I can't imagine a generic way that would let me generate the
> "SELECT ... FROM (SELECT ROW_NUMBER() OVER (...)) WHERE ..."
> mon
On 2013-03-25 22:16, Michael Manfre wrote:
> On Monday, March 25, 2013 6:58:12 AM UTC-4, Tim Chase wrote:
> > I can only speak for testing IN-vs-EXISTS speed on MSSQLServer at
> > $OLD_JOB, but there it's usually about the same, occasionally
> > with IN winning out
On 2013-03-25 03:40, Anssi Kääriäinen wrote:
> I am very likely going to change the ORM to use EXISTS subqueries
> instead of IN subqueries. I know this is a good idea on PostgreSQL
> but I don't have enough experience of other databases to know if
> this is a good idea or not.
I can only speak fo
I just read through the novel that is
docs/internals/howto-release-django.txt and I have a new level of
respect for just what happens when a release is made. That's a LOT
of work.
So thanks to those that wade through the whole process!
-tkc
--
You received this message because you are subscri
On 08/26/10 13:25, Jeff Balogh wrote:
In our case the pref was accidentally disabled when testing add-ons,
but people do intentionally turn off Referer for privacy reasons. I
don't know if requiring Referer under https is a good idea.
RFC-2616 makes it pretty clear that one should never requir
On 07/15/2010 01:28 PM, Mark Bucciarelli wrote:
not sure why a subselect would ever need an order by anyway.
i'll have to figure out exactly what django operation
generated that sql.
The only time I've needed an ORDER BY in a subselect involved a
LIMIT/TOP in the subselect
SELECT ...
FRO
Your proposal really needs to cater to two different audiences:
1. People who will use the new {% form myform %} where they just want
all the fields rendered without any fuss, much like {{ form }} now.
2. The tweakers that need to control every aspect of the each field
being rendered.
I'd say t
On 07/12/2010 07:03 AM, Russell Keith-Magee wrote:
On Mon, Jul 12, 2010 at 5:43 AM, Tim Chase
wrote:
[please excuse the slight chop-up-and-reordering of your
original into my quoting]
Only if you grant me the same liberty :-)
Fair's only fair :)
and REALLY -1.0e1 on this syntax
On 07/12/2010 08:12 AM, Russell Keith-Magee wrote:
On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote:
Good proposal overall. One thought I have in order to try and combat
the massive parameter list of {% form %} is to optionally add an
ending tag, as well as sub-tags:
{% form myform %}
[please excuse the slight chop-up-and-reordering of your
original into my quoting]
On 07/11/2010 10:36 AM, Russell Keith-Magee wrote:
{% form myform %}
For what my vote may be worth, I'm -0 on this...
{% form myform field birthdate using calendar %}
and -1 on this
{% form myform field bi
> How do you feel about having a default max_length value for a
> models.CharField, so we can use it like:
> class MyModel(models.Model):
> example = models.CharField()
>
> What are the pros and cons?
I'm pretty -1 against it.
Pros:
+ you get to be lazy in one particular use-case, for what
> This would be a break in tradition. We don't (or haven't in the past)
> done release notes for point releases, as they are normally only
> bugfixes and/or security updates.
>
> I can see three possiblities here:
>
> 1. Mark the feature as 'versionadded:1.2" in trunk; in the 1.1.X
> branch, mar
Just noticed this in [1]
--
csrf_tokenś
New in Django 1.1.2:
System Message: WARNING/2
(/home/djangodocs/en/dev/ref/templates/builtins.txt)
undefined label: releases-1.1.2
--
Looks like some tag/label needs to be created
> I find an orm usefull for 3 scenarios:
> 1. - simple object retrieval posts.objects.all()
> 2. - performance optimized object retrieval, your raw approach would
> suffice here
> 3. - generating complex queries, and reusing sql components
> When you get to complex data models, Django currently fa
> 1) If we encourage people to write their own regex if they want
> tighter email validation, we run the risk that users will
> inadvertently introduce the same bug that we have just fixed.
Russell raises my biggest concern with this proposal. There are
a lot of smart folks in the Django-Devel
> Is there anyone else interested in this?
yes, I'd be interested in seeing some sort of database-level
CHECK constraint as part of Django. I had been sitting on my
thoughts until I see the GSoC work done on model-validation wend
its way towards trunk. My hope had been to see model validatio
James Bennett wrote:
> The current proposal is for a "USPostalCodeField" which
> corresponds to the US Postal Service's list of postal codes:
>
> http://www.usps.com/ncsc/lookups/abbr_state.txt
>
> [snip] Based on the various arguments up to this point, it
> seems like no single field is going
> In terms of the SMTP-specific settings (host, port, username, password
> and use_tls), I personally feel that those parameters should be in the
> settings module and not in the code. Although at the moment,
> django.core.mail will use certain settings if said parameters are left
> out.
Honza,
Thanks for all your work on this -- model-validation is something
I missed when it was removed (well, moved to forms), so you have
one of my favorite GSoC projects.
> Questions for the community:
> -
> I have been toying with the idea of abstract validating objec
> How about:
>
> "You're found the wrong list. You're probably looking for django-users
> unless you're interested in the development of the Django framework itself."
+1
[waves hand] This is not the list you are looking for.
-tim
--~--~-~--~~~---~--~~
You
> I'm here soliciting feedback on both the API, and any potential hurdles I
> may have missed.
While my vote may mean little, Alex has certainly been active and
had quality code on the mailing list. MultiDB has also been a
frequent issue on the mailing-list, so Alex gets my +1
I'd hope to see
Santiago Perez wrote:
> Hi, I found myself needing to reference the previous or next
> element of a list within a for loop of a template. I think it
> would be pretty easy to implement the following extra members
> to the forloop context variable:
>
> + forloop.next_element
> + forloop.next_coun
>> 1) Prevent joins at the query level. Keep track of the joins
>> that are being used for aggregates, and only allow one join.
>> This would mean killing a lot of queries that work correctly
>> right now, but would prevent the class of invalid queries.
>>
>> 2) Push aggregates into subqueries. R
James Bennett wrote:
> Apologies for the length of this email,
Thanks, James, for your post-doctoral dissertation on the History
and Cumulative Predicted Future of Python Versions and Their
Interrelations With the Django Development Process. :-) (joking
aside, it was an appreciated and well-r
> I'd like to officially drop Python 2.3 support in Django 1.1.
> Discuss.
+0.5 (not withstanding any panic'ed folks saying "I need 2.3!",
consider it a +1)
I think Debian Stable has moved to 2.4. All the servers that I
touch currently with 2.3 on them now also have 2.4 on them.
Yay, decorato
> I'm still coming to grips with Sphinx, but is there any reason that we
> can't just use 1.X or 1.SVN as a version number for the development
> version? That gets around the need to specify the exact version
> number, but keeps it reasonably obvious that it's a development
> version.
If non-digi
> I'd trade your controversial part for an alternative: merge mewforms-admin
> back to trunk now. It's been as 'usable' as old admin for months. Sure,
> it's got a couple of dozen 'blocking' bugs in the tracker but none of them
> are all that serious. Current admin, as you note, also has some b
>> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
>> rc or two, and then a final release. Features that are done by the
>> dates get released, those that aren't, don't. Make these dates
>> aggressive but not crazy. And -- here's the controversial part -- make
>> newforms-adm
> To my understanding, a slice isn't automatically a copy - it will be
> in most cases, but there are cases where the bytecode compiler will
> use the original list as an optimization. One example:
>
> >>> s = 'abc'
> >>> t = s[:]
> >>> s is t
> True
>
> I'm willing to be corrected here, but
> * On a similar note, I can see a lot of places where you
> seem to be copies of lists (or sublists) - this is an
> expensive operation if you do it a lot, especially since
> most cases you could get the same effect by keeping the
> index values and slicing the original list as required.
>
>> The real problem is when I try to access the database. I get
>> stack trace below. It looks like it is trying to use the
>> LIMIT keyword incorrectly.
As best I can tell, Firebird doesn't support the SELECT ... LIMIT
x OFFSET y" notation, but rather uses "SELECT FIRST x [SKIP y]
..." as detai
> I poked around 'django.db.model.query' this morning and noticed that
> '_QuerySet' class has 'latest(self, field_name=None)' method. I was
> wondering if adding 'first(self, field_name=None)' had been considered
> before.
>
> It seems that could be a useful shortcut in some instances.
Does
> If we want to crash and burn if you use DEBUG=True in
> production we should do that explicitly, not as a side effect
> of another feature. I think there is enough real-world
> evidence that people are being tripped up by this for
> legitimate reasons (running import scripts in development
> mod
>> class X(models.Model):
>> x = models.CharField()
>>
>> class Y(X):
>> y = models.CharField()
>>
>> class Z(X):
>> z = models.CharField()
>>
>> produced the tables
>>
>> x(id, x)
>> y(id, x, y)
>> z(id, x, y, z)
>>
>> All I need to know is if this is some kind of fall-back till full-
>>
> Am I missing anything here?
>
> So feedback is welcome, please give it.
Ah, the curse of backwards compatibility and permalinks. My one
concern (okay, given more time to think about it, perhaps more
will percolate to the surface) with this is the abundance of
(legacy) HTML-fragment references
52 matches
Mail list logo
