present the same data as their parent
class. Everything else follows naturally.
Best,
Alex Ogier
On Aug 18, 2013 12:32 AM, "Jorge C. Leitão"
wrote:
> Hi there.
>
> I was working with proxies models and I found an odd behavior on a
> QuerySet, and I ask here whether it s
That's too hard to enforce. It would mean that you can't show user content
on any public page, or any page that you want to be accessible from outside
links. For example, you couldn't show blog comments to unregistered users.
It would be too disruptive. Modifying the format of the secret token is a
Debian Wheezy and Ubuntu 12.04 LTS are both on Python 3.2.
On Mon, Jul 1, 2013 at 5:44 PM, VernonCole wrote:
>
> Dropping support of 3.2 would potentially aid projects which have not yet
> converted to Python 3, since Python 3.3 supports u"Unicode Literals" but
> 3.2 does not. Skipping over the
No worries, that's always been one of the most awkward gotchas in python.
It's made doubly so by the fact that iterating over a string gives more
strings.
On Jun 5, 2013 4:29 PM, "Cal Leeming [Simplicity Media Ltd]" <
cal.leem...@simplicitymedialtd.co.uk> wrote:
> Hi Noah,
>
> Sorry yes I remember
>>
>> That's what I thought- But why not just qs[0]?
>>
>> Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems that
>> the [:1] is unnecessary. I would expect both to raise IndexError.
>>
>>
>>
>> On Wed, May 15, 2013
Significantly better. The latter method loads every single model in the
queryset into Python, potentially the whole database!
On May 15, 2013 9:24 PM, "Lee Trout" wrote:
> Is qs[:1][0] better form than list(qs)[0]?
>
>
> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong wrote:
>
>> I've updated the fi
On Tue, May 14, 2013 at 7:38 AM, Shai Berger wrote:
> On Tuesday 14 May 2013, Alex Ogier wrote:
> >
> > It's a totally new behavior that has
> > plenty of corner cases such as foreign keys, and especially
> OneToOneFields.
> >
> Another one is initializers:
you could iterate over Meta.fields
calling "setattr(old_a, field_name, getattr(new_a, field_name))" for each
one, but that has the problem that field setters may expect to do some
massaging of the data on the way in which can cause data corruption.
Basically this is a Hard Problem(tm) w
following should be
equivalent to the previous example:
bb = B()
bb.save()
aa = A(b=bb)
aa.save()
assert aa.b is bb
assert bb.a is aa # back-reference is cached
aaa = A.objects.get(id=aa.id)
aaa.b = None
aaa.save()
aa.refresh() # back-reference is cleared
assert aa.b is None
assert bb.a is None
all, .reload() or .refresh() would the existing
instance in place. It's more akin to foo.__dict__ = MyObj.objects.get(id=
foo.id).__dict__
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe fro
It looks like the only place I can find where {{ block.super }} is
documented[1] doesn't include explicitly explain how the super block is
executed, but it is certainly the reasonable thing to do: execute the super
block in the current template's context as if it hadn't been overridden.
Otherwise o
quot;. Groups let you solve
both problems flexibly. The downside is that they might not be very DRY,
having to repeat group="everything" over and over if you just want to load
it all on first access.
Best,
Alex Ogier
--
You received this message because you are subscribed to the
will be enormous and any code changes introduce the possibility of new bugs
or flaws.
Best,
Alex Ogier
On Wed, Apr 17, 2013 at 4:42 PM, Damian Skrodzki wrote:
> And how would you rate the chances that these projects will be selected
> for GSoC? Or which of all proposed projects have the most p
On Mon, Apr 15, 2013 at 1:22 PM, Donald Stufft wrote:
>
> On Apr 15, 2013, at 1:16 PM, Alex Ogier wrote:
>
> The problem I have with fallthrough-based dispatch is that it encourages
> really expensive performance-killing patterns, where you end up doing a
> linear scan over vi
er regex, such as dispatching by the Accept or Accept-Language
headers. All of this stuff falls under multiurl's purview, at least if and
until core supports fallthrough URLs.
Best,
Alex Ogier
On Mon, Apr 15, 2013 at 7:54 AM, Tom Christie wrote:
> This proposal is actually *very* similar
I agree, I think there are use cases for both types of dispatch, and it
seems clean and well-defined to make a route that is valid for only a
subset of HTTP methods. I guess there are a few corner cases to think
about, for example should Django's url resolver start returning 405s
instead of 404s wh
dubious
benefit, and I don't think it's worth re-adding.
Best,
Alex Ogier
On Sat, Apr 13, 2013 at 5:34 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 13 avr. 2013, at 22:13, Jeremy Dunck wrote:
>
> > After reading that ticket, I'm not
I think what he is saying is that many third-party libraries call the
equivalent of django.utils.simplejson.dumps("...",
cls=DjangoJSONEncoder) which, despite django.utils.simplejson only
being in a pending deprecation state, is broken.
On Thu, Apr 11, 2013 at 9:22 PM, Alex Gaynor wrote:
> When d
f there is anything in core that is blocking the
external implementation of a feature like this, it's worth looking at,
else just implement it outside of core. Particularly in this instance
since it will still be impossible to embed Django applications
anyways.
Best,
Alex Ogier
--
You rece
o a -1. If you want to have a field that allows relative or
scheme-relative URLs, creating your own field is the way to go.
Best,
Alex Ogier
[1]:
https://github.com/search?q=language%3Apython+URLField&ref=commandbar&type=Code
[2]:
https://github.com/django/django/blob/master/django/db/mode
Don't add an option, it's not needed. URLs with blank schemas are valid,
it's just a bug that Django adds 'http://' in that case. So make a ticket,
+1 from me.
Best,
Alex Ogier
On Wed, Apr 3, 2013 at 4:24 PM, Juan Pablo Martínez wrote:
> I love it.
>
ems like a bad idea, versus
"Install django-configurations, and now you have a new tool in your toolbox
to put in settings.py that imports from the environment!"
Best,
Alex Ogier
On Thu, Mar 14, 2013 at 3:42 PM, Omer Katz wrote:
> You haven't referred to the pull request
ow-tos on deployment we could write up some good practices for managing
settings in multiple contexts -- that would be more welcome than code in
Django core, I think. Midterms end today for me, so maybe I will try
writing up some of the practices that make managing settings easier for me
later tonigh
ults. If you want to modularize them, you are free to do so yourself. I
think composing settings internally is just added complexity for little
benefit.
Best,
Alex Ogier
On Wed, Mar 13, 2013 at 12:27 PM, Omer Katz wrote:
> Lately I implemented some changes for django's settings module .
>
to passing most tests.
So I see no reason to split off backends unless the maintenance burden is
such that they are chronically broken in every Django release. And every
reason to add MSSQL unless the maintenance burden is too high.
Best,
Alex Ogier
On Thu, Mar 7, 2013 at 4:03 PM, Erik Romijn
for them.
[1]: http://pytools.codeplex.com/
[2]:
http://www.windowsazure.com/en-us/develop/python/tutorials/django-with-visual-studio/
[3]:
http://www.windowsazure.com/en-us/develop/python/tutorials/web-app-with-django-and-mysql/
Best,
Alex Ogier
On Thu, Mar 7, 2013 at 12:46 PM, Jacob Kaplan-Moss wro
n stay modern outside of core,
then it will die, but we should make it a trivial matter to fork and adopt
for whoever needs it.
Anyways, +1 from me.
Best,
Alex Ogier
On Thu, Mar 7, 2013 at 12:41 PM, Luke Granger-Brown wrote:
> +1 from me too - I've only tried using django.contrib.commen
fix. Besides, it does have some merit as it is consistent with
`./manage.py somecommand`, which is the recommended way to run pretty
much every command except "startproject".
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Dja
ss you manually check for it,
you shouldn't even notice that you are getting Pillow libraries
instead of PIL libraries. Which means that supporting pillow *should*
be as easy as Marijonas suggests, unless there actually are real
regressions. Just install it instead of or in addition to PIL when
t
e on the server is a better
way of handling times. As a result, if the settings module doesn't contain
a TIME_ZONE setting, then you get 'America/Chicago' in order to be
backwards compatible, but when you make a new project you get the current
best-practice setting which is UTC.
Be
see unexpected things if they override it). So
I'm -0 due to the additional complexity for something which is already
possible and has a widely used idiom, even if it is more verbose.
Best,
Alex Ogier
On Thu, Jan 31, 2013 at 12:13 PM, Byron Ruth wrote:
> I don't want to belabor our di
Your new method will bypass their customizations.
Best,
Alex Ogier
On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth wrote:
> I don't understand your argument regarding overriding `__init__`. Nothing
> has changed in __init__, the logic for setting `data` and `files` is simply
> mov
letter and no "Input" suffix. So the naming is
consistent, and agrees with the HTML tags, even though it looks a little
weird without that knowledge.
Best,
Alex Ogier
On Sat, Jan 19, 2013 at 3:26 AM, Wim Feijen wrote:
> Hi guys,
>
> I was just wondering, and maybe my Eng
Well, most GNU command line utilities have an option
--color=always|auto|never that defaults to auto. Seems like it works for
them, so replicating it for management commands makes more sense than an
environment variable to me.
Best,
Alex Ogier
On Wed, Dec 19, 2012 at 4:09 PM, Alex Gaynor wrote
To be fair, the query you describe is significantly more expensive than
Marek's query.
On Fri, Nov 30, 2012 at 10:20 AM, Tom Evans wrote:
> On Fri, Nov 30, 2012 at 2:51 PM, Marek Brzóska
> wrote:
> >
> >
> >
> > 2012/11/30 Tom Evans
> >>
> >> On Fri, Nov 30, 2012 at 1:29 PM, Marek Brzóska
> >
For example, you miss Http404 and other error responses, which are
implemented as exceptional control flow. In addition, you can't do any
preprocessing of the request; for example, you can't set up any invariants
before your actual view method is called.
Best,
Alex Ogier
On Wed, Nov 1
Oh, my apologies, the proper argument to set the name of the table that is
created for a ManyToManyField is db_table instead of db_column (which just
controls the column on the user table itself). Entirely my mistake.
Best,
Alex Ogier
On Thu, Nov 8, 2012 at 8:10 PM, Christian Jensen wrote
jango's ModelBackend.
Best,
Alex Ogier
On Thu, Nov 8, 2012 at 3:27 PM, Christian Jensen wrote:
> I was tweaking around with making an email address only User model (sans
> username) while still retaining the permissions stuff and ran into a small
> issue. I can fix it but it might need
27;t to go mixin-crazy, it's to find the best way to expose
permissions-checking (the most boilerplate-heavy of the requirements of an
admin-compatible user). The other contracts are probably better exposed as
tests in contrib.admin than as little piece-wise mixins.
Best,
Alex Ogier
On Thu,
OK
limitation. Forms will still have to be overridden, but that was always
inevitable.
On Tue, Nov 6, 2012 at 5:02 PM, Anssi Kääriäinen wrote:
> On 6 marras, 23:05, Alex Ogier wrote:
>
> > ... Since you can't actually override or change the fields of an
> abstract model
tractBaseUser + UsernameMixin + PermissionsMixin. I might
try that on my branch, and see how it works out. My guess is it will work
just fine albeit with an absurdly deep inheritance tree.
Best,
Alex Ogier
On Tue, Nov 6, 2012 at 1:11 AM, Ryan Kaskel wrote:
> I implemented a custom User model in
t to core. Hopefully it
addresses your use case though.
Here's an example of a similar snippet someone has written, though
obviously you want to keep the same PK instead of auto-generating a new
one: http://djangosnippets.org/snippets/904/
Best,
Alex Ogier
--
You received this message beca
t "Fix it yourself" is
a hackneyed open-source truism, and "Speed doesn't matter" is more or less
self-evidently false -- especially to someone evaluating frameworks, who
may not yet have a strong opinion on what features are game-changers for
his application.
Best,
Alex Og
ng from local disk and writing
to S3, this is a big win, and doesn't require cooperation from any other
backends, or standardizing on md5 as a fingerprint method.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
T
go’s admin will blow your mind
There are a lot of other good python frameworks nowadays with lots of nice
features, but this is the one that keeps me coming back to Django.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers&
django-model-blueprint without even requiring any changes to
INSTALLED_APPS, which means the only benefit to being in core is
canonicalizing the pattern.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To pos
declaration.
>
> IPython 0.12.1
> Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34)
>
This is almost certainly related to https://code.djangoproject.com/ticket/18204
I can repro just as Alex Gaynor did, and the patch from the above
ticket fixes it.
Best,
Alex Ogier
--
You
On Wed, Aug 29, 2012 at 3:44 AM, Russell Keith-Magee
wrote:
>
> I suppose you could see it as a semantic nuance. However, to my mind,
> there is a different. A skipped test is something that could -- or
> even *should* be run -- but can't due to missing some optional
> prerequisite. In this case,
> Until the Python developers announce an actual timeline for removal
> (if they ever do), I can't see any reason for Django to be concerned
> about which formatting approach to use, apart from the immediate
> concerns of style and efficiency.
I don't think Python will ever remove %-style formatti
est practice to create new HttpResponses would *really* break this.
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@googlegroups.com.
To unsubscribe from thi
hanisms
if possible, and should be able to explicitly opt out if necessary.
Almost everyone should be using every single protection Django offers
on all their requests, and therefore it should be verbose and
discouraged to turn off these protections.
Best,
Alex Ogier
--
You received this message
They are also dated and appropriately
transient: a blog post from 2008 can be forgiven for missing some latest
best practices, whereas a tutorial enshrined in Django's official
documentation cannot.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google
On Thu, Jun 28, 2012 at 1:14 PM, Luke Plant wrote:
>
> Some other alternatives: build_html, build_html_safe, format_html
>
+1 for format_html.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
On Thu, Jun 28, 2012 at 11:18 AM, Alex Ogier wrote:
>
> Also, to be compatible with python 3 and more idiomatic python, I
> would implement the function as:
>
> def html_mark_safe(format_string, *args):
> return mark_safe(format_string.format(*map(conditional_escape, a
hon 3 and more idiomatic python, I
would implement the function as:
def html_mark_safe(format_string, *args):
return mark_safe(format_string.format(*map(conditional_escape, args)))
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers&q
en they are
unchecked. Kind of throws a wrench in my plan.
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@googlegroups.com.
To unsubscribe from this group, s
e all our
forms are explicit, it is feasible to catch that scenario and throw an
error, which I think we should do.
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-develo
r examples see "
It's an easy thing to justify turning on in an opt-out fashion,
Meta.allow_partial_submissions or something.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
ry:
+0 on option 1. Making a ModelForm is already a choice to expose a
model directly.
-1 on option 2. Default is still insecure, and Meta.exclude has use cases.
+0 on option 3. It's like my option 4, but requires [for field in
Model._meta.fields] hackery to work around.
+1 on option 4. Auto-g
On Tue, Jun 12, 2012 at 11:43 PM, Karen Tracey wrote:
> On Tue, Jun 12, 2012 at 10:10 PM, Alex Ogier wrote:
>>
>> No one can sneak extra unexpected fields past a developer by editing HTML
>> client side, because if the field wasn't rendered to HTML it's not
>>
fields other than primary keys use hidden input
widgets by default, so it's rather obvious when something changes. We
don't have the Rails problem where one dev makes a scaffold form for
an insecure model and another one adds a secure field to the model
opening up a security ho
subtle problems when
switching to json, recommend that people switch to simplejson instead,
or undeprecate django.utils.simplejson as a necessary wart (we can
still stop vendoring simplejson though).
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
&quo
eady on systems without
simplejson. If Django depends on optimized behavior, then it is a bug,
and a ticket should be filed.
Best,
Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send e
#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
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
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
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
--
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
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
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'
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
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
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
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
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
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
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
;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
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
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, "
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
Tai,
I think you are overestimating the importance of a "pluggable" user model.
If 100 apps all try to add fields to the User model then of course bloat
and performance issues and field name conflicts will be a problem. But I
don't think that will happen. There are very good reasons for an app *no
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
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
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
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
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
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
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
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
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
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
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.
>
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
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
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
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
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.
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
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
1 - 100 of 121 matches
Mail list logo
