File "admin_modify.py" method "def prepopulated_fields_js(context)"
Line 11:
if context['add'] and 'adminform' in context:
should be changed to
if 'adminform' in context:
to allow slug be auto updated every time and not only on the entity
creation in admin.
Is there any setting to do it without cha
Hello,
Are there any plans to add CUBRID - http://www.cubrid.org/ ad Django
backend?
Seems to be very optimized DB for web application (opensource with
internal support clastering, partitioning, efficient paging support)
Thanks,
Alex
--
You received this message because you are subscribed to
Hy,
Summary:
I'm getting this error "(2026, 'SSL connection error: Failed to set
ciphers to use')", on the django error page and I don't know what i
happening!!!
I'm using apache / wsgi and my aplication it's on a virtualenv.
The main problem is that I can't connect to a remote mysql ove
Hi Folks,
We're looking to hire a Web Developer with Django experience for a new
funded startup in Montreal, Canada. Please see the job description
below. Appologies in advance if this is not the right group for this
type of posting.
Regards,
Alex
Project: www.project-ojibwe.or
#3, I think it's an over
simplification. There's another way to change a class: class decorators.
And there's ample precedent for their use in such a manner, unittest's skip
decorators, our own decorators for swapping settings during testing, etc.
Alex
--
"I disapprove of wha
lasses (or functions).
c) I'm not sure how it's magic, but certainly if it's too complex we'd take
patches to simplify the implementation.
> On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote:
>
>
>
> On Fri, Sep 16, 2011 at 9:47 PM, James Bennett wrote:
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
FWIW there was a thread either on python-dev, or maybe python-idea, or it
might have been
of core, it's not as easy as it ought to be,
but it's very possible (citation: I've done it :)). Finally (for now ;)) it
doesn't feel right for something inside core to have caveats like "only
works if you use .all()", there's a very good technical reason for this, but
tween, working on something you find interesting, maybe something you like
using in Django, or that you don't like so much, makes the process of
contributing to Django significantly more awesome.
Hope that answers some of your questions,
Alex
--
"I disapprove of what you say, but I will
).
Thanks,
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
--
You received this message because you are subscribed to the Google G
On Thu, Sep 29, 2011 at 1:20 PM, Luke Plant wrote:
> On 29/09/11 17:13, Alex Gaynor wrote:
> > Hi Luke (and the rest of the list ;)),
> >
> > Just saw r16912 and the subsequent commits, I wonder if you
> > saw https://code.djangoproject.com/ticket/14270? I think most
s, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
When I did this externally a number of years ago, I basically subclassed
ManyToManyField, overrode a bunch of code (quite a bit of copy paste as I
recall), and it's related manager and made it return a cust
On Thu, Sep 29, 2011 at 6:36 PM, Luke Plant wrote:
> On 29/09/11 18:23, Alex Gaynor wrote:
>
> > Your right, there should be an additional assert. FWIW it's not even a
> > time/memory tradeoff, it's just savings. Type objects on every Python
> > VM are some
is group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
To be (layman's understanding) the purpose of the corporate CLA is that in
many jurisdictions an em
x27;s not fair to compare PyCharm to VIM, it's fair to compare
PyCharm to VIM with 700 plugins). Trying to make this an official doc page
will, I fear, lead to a pile of tickets asking for slight changes to feature
one plugin, or theme, or whatever else, with no way for core developers to
act
ango developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django
Danny, I think you meant that for a different thread.
Alex
On Mon, Oct 24, 2011 at 1:36 AM, Daniel Greenfeld wrote:
> One of the things that I think would be wonderful is to see this and other
> issues such as server specific settings actually described in a Django best
> practices
veloping with Django, for that you should use the django-users mailing
list.
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
--
You
.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
I basically agree with what Carl said, but if you want to use fixture
files, I highly reccomend: https://github.com/alex/django-fixture-generator
Alex
--
"I disapprov
encoding/decoding, yeah I'd say that's a blocker, because
it'll never improve otherwise. On the other hand if it's slow because
psycopg happens to be slow on py3k, well, that's someone else's problem
then and I'm ok to merge it.
Alex
--
"I disapprove of
or more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
It's a fine goal, though I'm not convinced this should necessarily ship
with Django given PyMySQL has relatively few users. However, the approach
is the wrong one, django database backend
On Wed, Dec 7, 2011 at 4:03 PM, Ian Clelland wrote:
>
>
> On Wed, Dec 7, 2011 at 12:48 PM, Alex Gaynor wrote:
>
>> It's a fine goal, though I'm not convinced this should necessarily ship
>> with Django given PyMySQL has relatively few users.
>
>
>
On Wed, Dec 7, 2011 at 5:17 PM, Ian Clelland wrote:
> On Wed, Dec 7, 2011 at 1:07 PM, Alex Gaynor wrote:
>
>> I'm saying database backends need badly to me refactored to split up
>> these two seperate concerns.
>>
>
> Agreed, then. Is there a ticket for thi
-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
It isn't alreayd?!?! All file objects django e
s group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
2.5 is EOL and no longer
up/django-developers?hl=en.
>
>
Once you get a real memory error (i.e. one indicating you're out of memory,
not just some operation wouldn't work "" * sys.maxint for example),
doing *any* allocation might fail, so any limits you try to put down won't
work in a
No, really guys this is totally off topic for this list. Please find an
appropriate one for this discussion.
Alex
On Dec 27, 2011 11:16 PM, "James Richards" wrote:
> I do agree that the fundamental point of Django is free distribution of
> content. Are developers now obl
--
> 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 from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For mo
m this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
I haven't analyzed your suggestion in detail Carl, but there is a good
reason for managers to ex
in Django itself is going to stunt it's growth, and
it's going to suck for new developers to Django who, like many of us (or at
least myself), were and still are, Python developers at heart, who can
write some HTML, badly.
Alex
--
"I disapprove of what you say, but I will defend t
We're using django-pyodbc http://code.google.com/p/django-pyodbc/ here at
the office and ran into a few snags when testing Django 1.4. I forked the
project onto github and made some changes to support 1.4
(https://github.com/avidal/django-pyodbc/compare/master...django-1.4), but
I was thinking
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
I suspect you're going for `from . import module`?
Alex
--
"I disapprove of what you say, but I will defend to the deat
iling list's
readership, much less of the Django community at large. Django is the way
it is because, first and foremost, of taste. If you'd like to make an
argument as to *why* it's useful, that's useful, but we don't take polls.
Alex
--
"I disapprove of what yo
in
the eyes of the beholder, but the reason we have BDFLs is to keep those
decisions consistent. Glyph Lefkowitz's keynote from DjangoCon this year
really drives this home.
>
> On Feb 24, 10:15 am, Daniel Moisset wrote:
> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor
> wro
s.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
I'm extremely strongly -1 on this. .pycs are a) an implementation detai
e to break, etc.
Anyways, asides for circular dependency edge cases I think the rest of
the downsides can be mitigated by good docs. What do you guys think?
-Alex Ogier
P.S. I hear you are accepting GSOC applications.
--
You received this message because you are subscribed to the Google Groups
&qu
ctly necessary, and can wait until
explicitly overriding fields has proper support in core (something I
think will be generally useful).
-Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
> Would something like the following alleviate that problem?
>
> class User(models.Model):
>if settings.USE_LONG_USER_FIELDS:
>username = models.CharField(max_length=255, unique=True, ...)
>else:
>username = models.CharField(max_length=30, unique=True, ...)
>...
Maybe,
backends. You basically hack them on in a per-project
fashion, wherever you define your profile.
Pluggable user field mixins would let people take advantage of auth
backends in a whole new way: distribute an auth backend and associated
fields in an app, and people can install it by changing settings and
I like the project and am +1 on Łukasz's points #1 and #3.
Meta.fk_level looks very useful though. For example if models have
parent/sibling relationships or otherwise relate to themselves and you
can't guarantee the relationships are acyclic.
Definitely a worthy project.
-Alex Ogie
the same parameter that throws at time of serialization.
-Alex Ogier
--
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 from this group, sen
nsidering the first phase to be serializing a model instance
into python primitive types, before serializing it to a textual
format.
-Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email t
mmonly, would basically
dictate a high-level architecture that consists of a lot of
meta-programming expressed through lazy references and class attributes,
resolving as the first requests make their way through the project.
-Alex Ogier
--
You received this message because you are subscribed to the
to expose pieces of
auth.User for people to reuse and/or depend on.
https://github.com/ogier/django/tree/auth-mixins
Does anyone have any opinions?
-Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
south.aeracode.org/docs/settings.html#south-migration-modules>setting
to handle this.
-Alex Ogier
--
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
at in turn
imports django.contrib.admin.models in their settings file. It's not a
common situation, probably, and it's an unfortunate restriction for many
reasons. So if I were to propose a patch that did so, would it get shut
down for that reason?
-Alex Ogier
--
You received this message
th, off-topic, or non-objective comments will be cut -- or at
> least heavily edited.
>
> Yours,
> Russ Magee %-)
I hope you don't mind, I added solution 2a. It's basically solution 2 minus
the monkey-patching and resultant circular dependency issues, and
correspondingly requir
n the wiki as a limitation.
Alex Ogier
--
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 from this group, send email to
django-developers+un
each
field you remove is an unknown risk.
Alex Ogier
--
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 from this group, send email to
django-deve
Why does the demo require Facebook integration?
--
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 from this group, send email to
django-developers+unsubs
n't
necessarily match your conception.
-Alex Ogier
--
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 from this group, send email
you want the tutorial code as a reference, the tutorial itself
is an excellent textual description of all the changes made, so why not
just refer to that?
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post t
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.co
{% url "app_views.client" %}
But this change definitely doesn't make things "dirty," in fact it cleans
up the tag to have consistent syntax with nearly every other tag, such as
{% block %} and {% extends %}
Best,
Alex Ogier
--
You received this message because yo
t for the email field is important, arguably a 1.5
release blocker, but so long as there is a good chance that migration
support will be 1.5's poster-child feature then I think email support
should be our poster child's poster child.
Best,
Alex Ogier
--
You received this message because yo
>
Well yes, it's not widespread: It's currently impossible. And it's only
three lines if you want to explicitly create a context variable inside a
template (which you will note is done with a quoted string constant). What
your example demonstrates is how to create a constant variab
x27;t know the usual timeframe on
controversial decisions like this, so if it is unlikely that a BDFL will
put their foot down significantly before the deadline then that is also
good to know. I could then apply with a looser definition of the project
contingent on an eventual decision.
Ciao,
t. The question is why force_encoding(...,
errors='replace') is giving you a string that PostgreSQL can't handle.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
I'd favor number two.
Alex
--
"I disapprove of what you say, but I will defend to the death your right to
say i
son (possibly with C
extensions) whenever available.
Therefore I am in favor of option #1, unless the shim is so trivial as
to warrant asking any developers who use it to rewrite it themselves.
Best,
Alex Ogier
On Thu, Mar 29, 2012 at 7:43 PM, Russell Keith-Magee
wrote:
>
> Option 2 looks be
lejson. I don't know how common that is, most alternate json
modules appear pretty inactive but you never know.
Also, whether or not that is common, it turns out there has been a bug
that looks like it was added last October that means that no one has
been using the system json module at all.
On Thu, Mar 29, 2012 at 10:06 PM, Alex Ogier wrote:
> So in the process of removing simplejson I realized it's not strictly
> true that we no longer need to bundle it: if someone uses 2.6+ but has
> a 'json' module with a different interface sitting in front of the
&
Best,
Alex Ogier
On Fri, Mar 30, 2012 at 4:13 AM, Florian Apolloner wrote:
> Hi,
>
> I am for number 2 too, but don't forget that's deprecation in 1.5 and 1.6
> and removal in 1.7
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscr
t's just not worth
worrying about.
Best,
Alex Ogier
On Fri, Mar 30, 2012 at 2:02 PM, Łukasz Rekucki wrote:
> On 30 March 2012 13:04, Alex Ogier wrote:
> > At the same time, I want to reiterate my support for option #1: not
> deprecating the
> > module and leaving t
ns (and hence, what your login forms look
like), add in whatever authentication mechanisms you like, add in whatever
authorization mechanisms you need (with specific instructions on what
contrib.admin demands from your model), and run with that.
Sorry for the rant, hopefully I'm not burning
n #2?"
Then as soon as everyone does that and facebook, twitter, browserid, and
plain emails all share the same namespace, we open up the same whole can of
worms that we get with cache keys, except now failures to manage things
properly manifest themselves as security holes in basic authentication
i
x27;s proposal.
You can find it at https://gist.github.com/2289395
Best,
Alex Ogier
On Mon, Apr 2, 2012 at 8:35 PM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> I've written up a proposal for how *I* would like to address refactoring
> auth.user: https://gist.github.com/2245327.
>
e chunks into a ticket on trac? I think it makes
sense to merge no matter what we decide on for specific settings and access
mechanisms to developer-defined users.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
T
ed on, and they give the project enough direction that it will rapidly
become obvious if and when I am derailing your conception of what needs to
be done, so I hope you will consider letting it be done as a GSoC project.
Best,
Alex Ogier
--
You received this message because you are subscribed to th
Fair enough. My goal was never to shut down collaboration, and if GSoC will
do that then I am happy to drop it. The money was never my motivation, and
I will definitely still contribute what I can.
Best,
Alex Ogier
On Wed, Apr 4, 2012 at 2:46 PM, Jacob Kaplan-Moss wrote:
> On Wednesday, Apri
oesn't restrict you from
altering display values for internationalization.
It seems to me like this is really a documentation problem, where
distilling the wisdom of developers like Adrian into a little best
practices paragraph in the choices argument reference would go very far in
making the awk
at
> http://groups.google.com/group/django-developers?hl=en.
>
>
I haven't been following this thread nearly closely enough. But ISTM that
any abstraction that doesn't let the admin work with any User (assuming it
supplies the right interface) isn't very useful, and
ined MALE/FEMALE as globals too :) Otherwise you'll get
> a NameError.
>
> --
> Łukasz Rekucki
As attributes of the class object I'm pretty sure they are in scope. No
NameErrors there.
Best,
Alex Ogier
--
You received this message because you are subscribed to the
Interesting, you are right. It's still a little strange to me to be
accessing class attributes via the self object, but I suppose it is more
flexible than accessing them as User.MALE etc. which would make renaming
the class awkward.
Best,
Alex Ogier
On Apr 5, 2012 2:16 PM, "Łukasz Rekuc
force decisions on them.
So, stop thinking just in terms of contrib.auth.models.User. If you're
already using that with a profile and it's all working fine, then this
change isn't for you. This is for everyone who just wishes auth.User would
go away without totally borking admin.
Respectfully,
Alex O
Tai, read https://gist.github.com/2289395 for a summary of many reasons why
I think profiles are a bad idea, and unifying multiple profiles is an even
worse idea.
Best,
Alex Ogier
On Fri, Apr 6, 2012 at 6:15 AM, Tai Lee wrote:
> Alex Ogier,
>
> Is it really better to require users
could roll your own proxy
attributes to app fields, after all you control the entire user class.
Best,
Alex Ogier
On Apr 10, 2012 5:47 AM, "Tom Evans" wrote:
> On Fri, Apr 6, 2012 at 7:31 PM, Alex Ogier wrote:
> > Tai, read https://gist.github.com/2289395 for a summary of many
are a bunch of
standard ways to relate to a model that don't invasively change it. They
are all still available, and in fact preferred because no matter how easy
it is to use a mixin, doing nothing is even easier.
Best,
Alex Ogier
On Apr 10, 2012 10:58 AM, "Tom Evans" wrote:
> On
MO, and doesn't signal that every app should store all data
related to the user on the user model.
Best,
Alex
On Apr 10, 2012 6:34 PM, "Tai Lee" wrote:
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to t
every other unhandled exception.
It's not a code path you should ever reach in normal use, only when someone
is getting crafty with the admin URLs. A 400 response suggests that there
is a fixable error somewhere, and there isn't.
Best,
Alex Ogier
On Apr 11, 2012 2:44 PM, "3point2&q
Maybe it would be worth experimenting with various combinations of django
1.x django-admin.py executables with django 1.4 libraries? Maybe if
django-admin.py is a symlink into a 1.3 tree but django 1.4 is on the
search path this stuff could crop up?
Best,
Alex Ogier
On Apr 12, 2012 2:32 PM, "
can be done at load time to avoid
performance hits from isinstance calls.
Best,
Alex Ogier
On Apr 12, 2012 2:59 PM, "Carl Meyer" wrote:
> On 04/12/2012 12:43 PM, Anssi Kääriäinen wrote:
> > It is important that pre/post init signals will not get more expensive
> > than
;t
happen. It's a bit hacky but it would work.
Best,
Alex Ogier
On Thu, Apr 12, 2012 at 5:16 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 12 avr. 2012, at 21:16, Carl Meyer wrote:
>
> > The open question is just how this situation occurs in the fi
27;distutils.dir_util.remove_tree'. Adding that for our
specific directory that needs to be clean should work, yes?
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dj
On Thu, Apr 12, 2012 at 11:56 PM, Ben Finney wrote:
>
> Alex Ogier writes:
>
> > That seems like too much to ask. "setup.py install" should Just
> > Work(tm),
>
> In the absence of a proper package management system (as implemented in
> operating syst
So, this "import django"
will import relative to current directory and will work.
>
And in fact, this behavior is relied upon. Django's setup.py imports the
relative django to get the version number.
Best,
Alex Ogier
--
You received this message because you are subscribed
le create issues on github is to
> disable it for the
> official repository. This is possible through the Github's Admin interface.
>
Err, I think the point was that Trac is less accessible than Github so
Django *should* be using Github Issues instead.
Best,
Alex Ogier
--
You re
everal successful projects
that use git that use patch-based workflows rather than merging. The
advantage of that is a linear history with each feature packaged into
a neat commit. The extra detail is great for developing, but not so
great for a mainline history (it breaks 'git bisect' for ex
fits, and all the same drawbacks, so I don't
think anyone would seriously advocate moving there.
Best,
Alex Ogier
--
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@googlegroup
I have posted instructions on how to easily and safely rebase feature
branches from an old fork of Django's SVN mirror onto Django's official git
repository. I hope this helps. Let me know if you need help or the
instructions are unclear or incorrect.
https://gist.github.com/2549844
ust a theory, but it explains the behavior you are seeing if you are
importing a different name when you do the native import.
Best,
Alex Ogier
On May 7, 2012 4:34 PM, "Scott Sadler" wrote:
> Hi all,
>
> I'm making some extensions to the Django AdminSite for dashboard I'
>
> https://convore.com/djangopeoplenet-development/ - gives http404
>
Djangopeople.net is dead?
If to be honest I don't understand you, guys! What's the profit of
rewriting views to class-based if djangopeople.net is down for a year ?
I would like to help, but don't know how.
--
You receive
t 9:19 AM, Aaron C. de Bruyn wrote:
>
> > On Wed, May 9, 2012 at 1:37 PM, Alex Sosnovskiy wrote:
> >>>https://convore.com/djangopeoplenet-development/ - gives http404
>
> >> Djangopeople.net is dead?
>
> >> If to be honest I don't understand you, guy
clean
up commit messages for posterity.
Best,
Alex Ogier
On Fri, May 18, 2012 at 12:48 PM, Donald Stufft wrote:
> On Friday, May 18, 2012 at 12:30 PM, Anssi Kääriäinen wrote:
>
> On May 18, 6:08 pm, Donald Stufft wrote:
>
> I personally prefer doing normal merges with --no-ff. While
Git actually has native support for this workflow. Each commit has an
"author" and a "committer" which are typically the same, but in the
case of a squash merge or patch are different.
For example,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=72c04a
form, you rely on the
internals executing something for you, which makes understanding
preconditions for various methods difficult to understand without
extensive docs.
Anyways, this is a deeper problem than "There are two things we can
fix, let's get on that."
Best,
Alex Ogier
--
tor to make the field again (as there's no
> way to get them directly). For those familiar with south_field_triple,
> it would be a bit like that.
>
>
This sounds similar to pickling's __getinitargs__, is there anyway we can
reuse some of:
http://docs.python.org/library/pickle.
el Foo
has an unknown field: `field_name` of type: `project.app.CustomField`.
Please register this field with
`django.db.migrations.register_field()` before creating migrations on
the Foo model." Also, you can support third-party fields by
registering them in your own modules if you need
On Mon, Jun 11, 2012 at 5:51 PM, Luke Plant wrote:
>
> i.e. simplejson returns bytestrings if the string is ASCII (it returns
> unicode objects otherwise), while json returns unicode objects always.
>
This seemed strange to me because the standard library json shipping
with python 2.7.3 is in fac
#x27;}
>>> from django.utils import simplejson
>>> simplejson.loads('{"a":"b"}')
{u'a': u'b'}
>>> json.loads == simplejson.loads
True
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google G
1 - 100 of 885 matches
Mail list logo
