Thanks. Would this just be for myself or would it be considered to merge
into Django core?
On Sat, Aug 5, 2023 at 9:22 PM Curtis Maloney wrote:
> On Sat, 5 Aug 2023, at 06:47, Ryan Gartin wrote:
>
> You are correct state_id is not a field on the model, state is, and using “
> s
preference I think it is
reasonable to request that if QuerySet.state_id returns a valid value then
it should also be capable of being serialized as well.
On Thursday, August 3, 2023 at 9:46:27 PM UTC-4 Curtis Maloney wrote:
> Hi Mike,
>
> On Fri, 4 Aug 2023, at 06:03, Ryan Gartin wrote:
&
I came across this issue calling the following and FK fields with _id are
ignored:
serialize('json', , fields=['title', 'state_id']).
State is a ForeignKey on my queryset. I can perform fields=['title',
'state'] and I get serialization correctly of {'state': int}. However, if I
specify fie
I've been working on setting up a new project that's never going to see the
light of production, so I went down the road of just disabling CSRF for
that purpose. I notably found that the Django admin still requires CSRF,
even when the middleware has been removed from the MIDDLEWARE setting. I
f
On Tuesday, April 18, 2023 at 8:34:14 AM UTC-5 Stratos Moros wrote:
[...] In my experience there are legitimate cases for setting
SameSite=None, especially concerning iframes.
Specifically, when developing a web app intended to be embedded as an
iframe by a different top-level origin, you can
I've recently been working with other new frameworks, particularly Remix.
Coming from Django, which has had excellent CSRF for many years, one of my
first questions was how to handle CSRF protection. And the response I got
lead me to the "Lax" SameSite cookie parameter, and that I really wouldn'
osed ... the idea
seems to be more of a 'wait and see'.
I believe Carlton also referenced the idea of type hints in a couple of
episodes of Django Chat (e103 with Nikita Sobolev and e105 with Adam
Johnson)
Current ticket in trac is 29299
<https://code.djangoproject.com/ticket/292
You’d run the migrations that you manually created with --fake. My experience
also corroborates the idea that squashmigrations may be unsuitable for many
situation that are similar to mine, where I am able to fully control the full
set of places that the code is deployed.
Ryan
> On May
> On Feb 2, 2021, at 11:29 AM, Carlton Gibson wrote:
>
> That is a good question. Do we take the X in an X.Y series in the SemVer way.
> I’ve always thought not
When we switched the version scheme ahead of 2.0, we wanted it to roughly match
SemVer. We’ve strategically weakened it in some pl
> On Feb 2, 2021, at 03:42, Carlton Gibson wrote:
>
> Possibly we could support Python 3.7 just for Django 4.0, as an exception,
> leveraging the "typically" in the existing policy, and clearly stating what
> we were doing.
>
> Can I ask for (limited) thoughts just on that smaller proposal?
This is an interesting discussion that is separate from, but related to,
django-safemigrate, which we use to separate which migrations may run
before or after deployment. I intend follow along with this discussion, to
see if there are reasonable ways to identify when these zero-downtime
operations
I recently developed a feature for my company that allows for mass upload
of users and a few other core models. I did use Django-rest-framework for
the core file upload piece which may not be in the scope of this group, but
it was fairly simple and if you wanted to do it for DSoC it'd be pretty
str
I'm almost exclusively a lurker on this list, but a constant user, and have
in the past a keen observer in the datetime discussions.
I think you've made your case well. I'd be happy for this migration from
Django to be as aggressive as the maintainers are comfortable. I agree that
doing step 1 at
It seems that many of the people who want a different name are not
understanding that this name is going to be exclusively for dealing with
POST forms that are using the standard `x-www-form-urlencoded` media type*,
*and won't be attempting to interpret any other media type. Some generic
names, lik
I can agree that there might be better things to do, but this falls into
the category of warts for me, so I'm +1. Having the name be pythonic is a
plus, but avoiding a beginner footgun is better.
And I believe the conventions used did indeed come from PHP. There even
used to be a parallel to `$_RE
magine that
Django using PASETO could give it a signal boost, but of course if there
were discovered some design flaw there, it would also entrench it more as
well as making it a security issue that Django has to address.
Either way, I really appreciate you taking the time to let us hear your
th
esigns for a similar
protocol that overcome your objections?
Ryan
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
>
> I think the conclusion should be to ask for a change in Python, not
> Django. The rule "if an exception is raised explicitly from an except
> clause then it is considered raised-from" seems simple enough to me.
>
I really like that. It makes perfect sense, and I can't think of a case
where tha
On Fri, Oct 11, 2019 at 9:29 PM Matt wrote:
> I think it should just show instead of .
>
I agree, I think this makes the most sense.
I think it can be argued that QuerySet should be consistent with [RawQuerySet,
> which just uses a string of the query in the repr]
>
I can see the argument I s
On Thu, Oct 10, 2019 at 10:50 AM Matt wrote:
>
> I think we ought to reconsider the behavior of repr on QuerySets. I'm of
> the opinion that we should scrap it completely. It could be replaced by
> something that generates the SQL that would be executed (although that may
> be tricky), or some ki
On Sat, Sep 14, 2019, 12:44 Adam Johnson wrote:
> (Fixed Ryan's link: https://github.com/aspiredu/django-safemigrate )
>
Doh. Thanks.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe fro
On Sat, Sep 14, 2019 at 10:09 AM Dylan Young
wrote:
> why do you need the model changes without the migrations? I.e. why would
> you want to be in a state that's inconsistent between the ORM and the DB?
> Is it just so you can recover more easily if something goes wrong?
>
I expect that its to a
On Mon, Jun 24, 2019, 21:29 Dan Davis wrote:
>
> Some questions:
>
>- How does the "safe" field of migrations work with other migrations
>related commands, such as squashmigrations? It seems to me that only
>migrations that share the same value of "safe" could be squashed.
>
> If do
I'm not sure about the solution you mentioned, but the problem you mention
is one that I definitely do deal with. At my work we have been happy with
using a "safe" migrate command that only runs migrations that are marked as
safe to run before the deployment happens, to address exactly this kind of
I'm not sure what the reasoning was, but it does ring some bells for me, as
I think this sounds like the case of the of the issue discovered in
https://code.djangoproject.com/ticket/28198. Hopefully that's a correct
connection, and I'm not sending you chasing something irrelevant to your
current ta
That won't be possible, Django 2.2 has been feature-frozen for a while now.
You might want to follow the following issue which is related to what
you're suggesting.
https://code.djangoproject.com/ticket/10227
On Wed, Mar 20, 2019 at 10:52 AM Mohammad Etemaddar <
mohammad.etemad...@gmail.com> wrot
I personally like the option better. This seems like a different use-case
than I'd normally expect from a verbosity level.
On Sun, Feb 3, 2019 at 12:45 PM Tim Schilling
wrote:
> Not changing the default output makes a lot of sense. I initially was
> wondering if it should have its own option. Ma
On Thu, Jan 24, 2019 at 11:29 AM Tim Graham wrote:
> Let's hear from people who find the current Python support policy
> insufficient for their needs.
>
Agreed. I'm not one of them, dropping 3.5 support disadvantages me in no
way. I don't use it in production or in development, and would have no
On Thu, Jan 24, 2019 at 10:55 AM Adam Johnson wrote:
> So, phrasing... maybe... as a draft: "Typically, we will support a Python
>> version unless it will be end of life before the corresponding version of
>> Django is outside of mainstream support. For example, Python 3.5 security
>> support end
I don't feel like my voice should have much weight, but I think that the
policy as written is better. Debian aims to be stable long term, and for us
to match Debian, especially when not in our LTS releases, seems excessive
to me.
On Mon, Jan 21, 2019 at 9:56 AM Tim Graham wrote:
> When deciding
I would also love to see a decent way to use enums as choices. The
translation issues seem the stickiest to me, but I'm kinda hoping we can
come up with something reasonable.
I'm a heavy user, but mostly a lurker on this list, but +1 from me for what
it's worth.
Ryan
On Mon, Dec
I’ll be on discord all day. https://discord.gg/EjNsDe
Warning I’m a noob also.
Sent from my iPhone
> On Aug 4, 2018, at 2:58 PM, Faisal Ali wrote:
>
> i am facing an issue while creating new project help me
>
>
>> On Sat, Aug 4, 2018 at 9:30 PM, tapfuma mashiri
>> wrote:
>> hello good
wrote:
> Hi Ryan, This mailing list is for the development of Django. Please use
> https://groups.google.com/forum/#!forum/django-users for usage questions.
> I think you're more likely to get help if you maintain a positive tone and
> omit sentences like "This is the pr
creating build\lib.win-amd64-3.7\twisted\protocols\test
copying src\twisted\protocols\test\test_basic.py ->
build\lib.win-amd64-3.7\twisted\protocols\test
copying src\twisted\protocols\test\test_tls.py ->
build\lib.win-amd64-3.7\twisted\protocols\test
copying src\twisted\protocols
I've found other places where things are fiddly for production migrations
as well. Migrating a nullable to a non-nullable field is one of a range of
cases where the migration cannot be run until the code has been fully
deployed to no longer write nulls to the database. A similar case, that's
even a
It's a subtle difference between how a single filter works and two filters
work together over to-many relationships. Here's a writeup that I found
helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/
On Thu, Mar 29, 2018 at 4:26 PM, Andrew Standley
wrote:
> I have recently
Hello everyone,
My name is Ryan and I've had the pleasure of working on various Django
backed projects for the last three or four years. I've never contributed
to the project (yet) but I'd like to get started. I'm posting today
because I'd like to discuss somethin
On Tue, Apr 18, 2017 at 11:27 AM Daniele Procida wrote:
> On Tue, Apr 18, 2017, Tim Allen wrote:
>
> >It struck me that this page is valuable real estate
>
> Yes it is! Firstly, I think that both your idea and design are excellent
> and I approve.
>
> Secondly, since that space is valuable, perh
> On Dec 22, 2016, at 5:22 PM, Adam Johnson wrote:
>
> +1 to what Aymeric wrote. I was just drafting an email with a similar
> argument about how it's hard to manage pure bytes in config management
> systems that write to env vars, that's why ascii strings are so useful.
> They're also easy t
> On Dec 22, 2016, at 2:32 PM, Tim Graham wrote:
>
> Perhaps times have changed but I forgot to mention that 8 years ago Malcolm
> rejected the idea that more randomness is required in the secret key. From
> the reporter of #9687:
You're right, and I knew that, but didn't consider it in my re
> On Dec 22, 2016, at 1:41 PM, Tim Graham wrote:
>
> There's debate in #24994 about whether or not settings.SECRET_KEY should or
> may be a bytestring. Some select quotes to summarize the discussion:
>
> [snip]
>
> I hope we can come to a decision and at least clarify the documentation.
> Pe
Loving this work! There's one thing that Flask's routing syntax does that
strikes me as backward, and it may be a good idea to consider reversing it: the
converter indication.
I suggest that rather than it being `` it should be
``, because the converter is very similar to a type, and we
have t
Thank you, Andrew, for your hard work. Channels is an exciting new feature, and
I'm glad that you're bringing it together. You're doing an excellent job.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
> On May 6, 2016, at 7:21 AM, Mark Lavin wrote:
>
> Ryan,
>
> Sorry if you felt I was ignoring your reply to focus on the discussion with
> Andrew. You both made a lot of the same points at about the same time but I
> did want to touch on a couple things.
I totally get
Thank you, Mark, for starting this discussion. I, too, found myself simply
accepting that channels was the right way to go, despite having the same
questions you do. I realize this shouldn't be, so I've chimed in on some of
your comments.
> On May 5, 2016, at 2:34 PM, Mark Lavin wrote:
>
> [s
I'd love to see better support for PaaS configuration, especially 12-factor. We
use Heroku, and I've been directly exposed to the challenges and had to come up
with some of my own solutions. Here's some thoughts I have on the matter, in no
particular order.
The SECRET_KEY needs to _not_ be req
> On Apr 7, 2016, at 5:13 PM, Stephen Kelly wrote:
>
> Daniel Chimeno wrote:
>
>> I think we should give an emphasis on this because are going to cause
>> problems to some people.
>
> Yes, this is why I suggested in my original mail that the feature needs more
> design consideration.
>
> *
The `is` operator in Python checks for identical objects. A string is not
guaranteed to be exactly the same object as another string (in this example
"True" is not the same object (bytes in memory) as the second "True", so Python
rightly sees that they are not the same object.
True, False, and
I have taken to using a prepare method called from dispatch which takes the
request args, and I use it primarily to resolve ids in the url to db objects.
This sounds like it fills a similar purpose.
Sent from my iPhone
> On Apr 3, 2016, at 14:07, Pablo Recio wrote:
>
> Hey there,
>
> Wanted
> On Mar 16, 2016, at 11:55 AM, Connor Boyle wrote:
>
> I'm hoping to add a feature that I've thought Django has needed for a long
> time, and thought that Google Summer of Code would be an excellent
> opportunity for it. Basically, it would be an API for defining 'Conditions'
> and applying
> On Mar 18, 2016, at 9:58 AM, Andrew Godwin wrote:
>
> routing = [
> route("http.request", ViewConsumer),
> route("websocket.connect", path="^chat/(?P[^/]+)/$", ChatConnect),
> route("sms.receive", sender="+44(?P[0-9]+)$",
> UkSmsConsumer),
> include(path="^notifications", "not
> On Jan 8, 2016, at 12:53 PM, Carl Meyer wrote:
>
> On 01/08/2016 11:48 AM, Ryan Hiebert wrote:
>>
>> While class-based middleware factories couldn't just do the same thing
>> in the __init__ method, they could do that in a __new__ method instead,
>>
> On Jan 8, 2016, at 12:38 PM, Carl Meyer wrote:
>
> Yes, you and Ryan are absolutely right, allowing `None` was a mistake
> and I've removed it from the spec. For function-based middleware,
> there's also the option to simply return the ``get_response`` callable
> y
> On Jan 8, 2016, at 11:57 AM, Ryan Hiebert wrote:
>
>> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin
>> wrote:
>>
>> In the spirit of “there should be only one way to do it”, I would require
>> raising MiddlewareNotUsed explicitly to disable a middlewar
> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin
> wrote:
>
> +1
>
> Great work.
>
> The only (and minor) concern I have is about allowing function-based
> middleware factories to return None.
>
> In the spirit of “there should be only one way to do it”, I would require
> raising Middleware
Sent from my iPhone
> On Jan 7, 2016, at 20:50, Carl Meyer wrote:
>
> Hi all,
>
> Back at the Django Under the Hood sprints in November, Florian and I
> started batting around some ideas for fixing some of the problems with
> the existing middleware abstraction. Florian put together an initia
> On Aug 24, 2015, at 5:37 PM, Carl Meyer wrote:
>
>> Any ideas on alternative ways to tackle this? I'm officially stuck.
>
> I'm afraid I don't have any solution to offer, other than embracing the
> "abstract vs concrete" dependencies distinction, and accepting the fact
> that users of your wh
Given the negative reaction to quick deprecation of LTS releases, I also now
most prefer Loïc's proposal. It's semver with a little extra to help folks out.
I'd also most prefer seeing 1.9 being changed to 2.0 if this proposal were
accepted, but that is not a strong opinion given that I am not f
res dropped
4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed
4.1 - 40 mos - No features dropped
4.2 - 48 mos - (LTS) No features dropped
I think those are probably the two best LTS support release schedules that
follow semver.
Ryan
--
You received this message because yo
LTER TABLE auth_user ALTER COLUMN username TYPE
varchar(254);')
]
```
Works so far, but haven't really tested it extensively
-Ryan
On Wednesday, April 22, 2015 at 10:26:31 AM UTC-5, Micah Hausler wrote:
>
> I actually migrated my site to 1.7 and added a custom user model very
&g
ld be in the authentication backend. I think that making it clearer what
the distinction is between login() and authenticate() is would help that
immensely, and making it clear that the backend need not be set by authenticate
would also make it clearer.
Ryan
--
You received this message becaus
s `python -m celery`.
I see value in adding these endpoints that are more easily guessable. However,
there’s a cost too, the cost of having more than one way to do it. We already
have `django-admin` and `django-admin.py`, would adding these obvious entry
points give too many options?
Ryan
--
You r
isn’t
enabled in my environment).
Ryan
> On Mar 18, 2015, at 1:34 PM, elky wrote:
>
> Awesome!! Sounds fantastic. Thanks, Aymeric
>
> On Monday, 16 March 2015 22:24:39 UTC+5, Aymeric Augustin wrote:
> For what it's worth, I've deployed your theme on an internal
As a anecdotal data point, when I getting started with class-based views I put
everything into get_context_data method, because that’s where I thought the
code for constructing the context should go. I eventually figured out that I
should probably never override that method, but rather override
These look very nice and are a step in the right direction. If you only
overrode admin/css/base.css I see no reason why this change can't be made.
Hanging on to the old design for legacy purposes has gone on long enough, it's
time to update. I would make a pull request after ensuring the new des
I follow the PEP for at least 3 reasons:
1. The PEP. I like using the Python standards.
2. It matches a (the primary?) widespread convention for commit messages.
3. Imperative verbs tend to also be the shortest of the tenses, so that’s a
nice side-effect.
Ryan
> On Jan 23, 2015, at 11:27
> On Dec 18, 2014, at 12:49 AM, Russell Keith-Magee
> wrote:
>
> So - I retract my suggestion - I think I can live with just documenting this
> as a backwards compatibility.
Sounds good. In case anyone is interested, I made a pull request (not complete)
with an implementation of a ‘ConfList’
> On Dec 17, 2014, at 6:12 PM, Carl Meyer wrote:
>
> On 12/17/2014 04:57 PM, Ryan Hiebert wrote:
>>>
>> What would __iadd__ do in this subclass? Would it behave like tuple and
>> create a new DjangoList, or would it behave like list and extend the
>> origi
if someone's
> motivated to write the patch.
>
What would __iadd__ do in this subclass? Would it behave like tuple and
create a new DjangoList, or would it behave like list and extend the
original list?
I’m interested at taking a whack at it, though I can imagine somebody else
getting i
Being the idealist I am, I hope we can find a way to rid ourselves of the pain
of cgi. I'd be more than willing to help, but my help would probably be more of
a hindrance because of the limited exposure I've had with developing wsgi.
However, I did want to register my support to those looking to
On Fri, Sep 5, 2014 at 12:49 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> On Fri, Sep 5, 2014 at 9:57 AM, Carl Meyer wrote:
>
>> On 09/05/2014 10:46 AM, Tim Graham wrote:
>> > In the meantime, shall we abandon the idea of organizing settings in
>> > dictionaries for "purity"? May
"""
payload = ... your payload ...
stream = StringIO(payload)
client.post(url,
CONTENT_TYPE='text/json',
CONTENT_LENGTH=len(payload),
wsgi.input = stream)
"""
It does not work.
在 2006年10月4日星期三UTC+8上午8时46分46秒，Russell Keith-Magee写道：
>
> On 10/4/06, Mikeal Rogers > wrote:
> >
> > I'm a l
> On Aug 19, 2014, at 12:02 PM, Andrew Godwin wrote:
>
> At this point, we're still a few weeks away from a final release at best.
> The release itself is pretty stable; the problem is that migrations are so
> complicated and provide such a large new feature surface that people are
> finding
> On Aug 6, 2014, at 7:14 AM, Collin Anderson wrote:
>
> Communication.
>
> From a purist theoretical perspective, there shouldn't be any argument - the
> data we're talking about is a list. Lists have homogeneous elements; Tuples
> have heterogeneous elements, but have *positional* homogene
> On Jul 25, 2014, at 2:22 PM, Andre Terra wrote:
> On Fri, Jul 25, 2014 at 12:17 PM, Ryan Hiebert wrote:
> > I see two benefits. One is that users who are interested in testing
> > aren't necessarily going to think to go to github; they're likely to
> > look f
> On Jul 25, 2014, at 10:06 AM, Ian Kelly wrote:
>
> On Fri, Jul 25, 2014 at 7:12 AM, Ryan Hiebert wrote:
>>
>>> On Jul 25, 2014, at 12:22 AM, Ian Kelly wrote:
>>>
>>> It seems to me that a new release would be useful to have for the
>>> r
> On Jul 25, 2014, at 12:22 AM, Ian Kelly wrote:
>
> It seems to me that a new release would be useful to have for the
> reasons given, but it should be called what it is: a beta version, not
> an RC.
>
I agree, but I don’t think that releasing a beta after an RC makes good sense
either. If th
releasing
prerelease versions on PyPI, then I’d probably reverse that opinion, because at
that point it would be easier to install (though only marginally).
Ryan
> On Jul 24, 2014, at 6:42 PM, Tim Graham wrote:
>
> 2 weeks later and we still have a fairly strong stream of new bug
>
> I thought TextField did have a default, the empty string?
>
> Like every other field, the "default default" is None (NULL).
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it
On Fri, Mar 14, 2014 at 10:07 AM, Val Neekman wrote:
>
> Localized solution is fine, but when I saw the number posts from people
> who were trying to find a solution to this, I thought, perhaps it would be
> a nice little enhancement to the APPEND_SLASH functionality.
>
You don't need to avoid A
t the end of the regex pattern).
On Thu, Mar 13, 2014 at 4:19 PM, Ryan Hiebert wrote:
> In your example, APPEND_SLASH
>
>
> On Thu, Mar 13, 2014 at 4:12 PM, Val Neekman wrote:
>
>> Some JavaScript frameworks(e.g. AngularJS) remove the ending slash before
>> making a r
In your example, APPEND_SLASH
On Thu, Mar 13, 2014 at 4:12 PM, Val Neekman wrote:
> Some JavaScript frameworks(e.g. AngularJS) remove the ending slash before
> making a request.
> If APPEND_SLASH = True, then the API would not be consumable by AngurlarJS.
>
> Would it be a good idea to add opti
On Fri, Feb 21, 2014 at 3:22 PM, Camilo Torres wrote:
> - Then, we can create dummy implementations of `render_to_response` (and
>> all
>>other functions) that checks the template extension and dispatch to
>>corresponding function from `django.dtl` or `jinja2`.
>>
>
> Hello,
>
> Could thi
On Thu, Jan 23, 2014 at 11:25 PM, Carl Meyer wrote:
> Hi Ryan,
>
> On 01/23/2014 09:50 PM, Ryan Hiebert wrote:
> > Assuming that the changes from the deprecation policy are in trunk now
> > that the alpha has landed, any use of the AUTH_PROFILE_MODULE must be
> > el
On Thu, Jan 23, 2014 at 10:30 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
On Fri, Jan 24, 2014 at 9:05 AM, Brian Neal wrote:
>
>> Hello,
>>
>> The deprecation timeline says this about Django 1.7:
>>
>> "The AUTH_PROFILE_MODULE setting, and the get_profile() m
On Thu, Jan 23, 2014 at 7:42 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
>
> On Fri, Jan 24, 2014 at 9:33 AM, Ryan Hiebert wrote:
>
>>
>>
>>
>> On Thu, Jan 23, 2014 at 7:24 PM, Russell Keith-Magee <
>> russ...@keith-magee.com
n migrating his existing profiles to something better, which is what I
understood the problem to be.
Using south might be an option for migrating, but if we were to keep the
profile around one release longer, perhaps that would ease the pain of
migrating profiles to a better solution.
Or maybe
On Mon, Dec 30, 2013 at 10:16 AM, Aymeric Augustin
wrote:
> The real question — is requiring django.setup() acceptable? Explicit is
> better than implicit, after all…
It's probably obvious to others, but where would that `django.setup()` be?
--
You received this message because you are subscr
On Mon, Nov 4, 2013 at 9:31 AM, Andre Terra wrote:
>
> On Sun, Nov 3, 2013 at 5:13 PM, Cody Scott wrote:
>>
>> 3
>> Why do Q objects use '&', '|' and '~' for AND, OR and NOT when python uses
>> 'and', 'or' and 'not'?
>> source
>
>
> Because Python actually does use &, | and ~.
The and/or/not ope
> changes, but I'm not losing anything either. If they benefit someone with
> "normal" vision, go ahead.
>
> Marc
>
>
> On 10 October 2013 03:16, Ryan Allen wrote:
>
>> It doesn't appear that the images I attached are being shown. Imgur
>>
It doesn't appear that the images I attached are being shown. Imgur instead:
Updated error:
http://imgur.com/JdoGyqw
Updated Error with Protonopia
http://imgur.com/Ve1ifAP
Deuteranomoly Success Message
http://imgur.com/QvqOHuo
--
You received this message because you are subscribed to the Googl
ssage. Introducing colour will be a UX win for those with colour vision;
> if we pick a good set of colors, those with a mild colour sensory disorder
> will still be able to distinguish error types based on colour. However,
> even if you are completely monochromatic, the icons are still
AAEX8/Y0BUK0ukpHs/s1600/Screen+Shot+2013-10-09+at+6.46.31+PM.png>
On Tuesday, October 8, 2013 2:46:08 PM UTC-4, Ryan Allen wrote:
>
> Here are comparisons for several different color blindness types:
> http://imgur.com/a/JaLPD
>
> On Tuesday, October 8, 2013 3:16:32 AM UTC-4, H
new error red
> is better though, bigger contrast to the white.
>
>
>
> On 7 October 2013 22:44, Ryan Allen >wrote:
>
>> https://github.com/django/django/pull/1715
>>
>> Currently, all admin messages have a background color of light yellow,
>> wheth
Here are comparisons for several different color blindness
types: http://imgur.com/a/JaLPD
On Tuesday, October 8, 2013 11:57:08 AM UTC-4, Ryan Allen wrote:
>
> Thanks, I found a Chrome extension to use -
> https://chrome.google.com/webstore/detail/spectrum/ofclemegkcmilinpcimpjkfhjf
Thanks, I found a Chrome extension to use
-
https://chrome.google.com/webstore/detail/spectrum/ofclemegkcmilinpcimpjkfhjfgmhieb?hl=en
On Tuesday, October 8, 2013 9:37:35 AM UTC-4, Daniele Procida wrote:
>
> On Tue, Oct 8, 2013, Ryan Allen > wrote:
>
> >Good thought, I'
d
> is better though, bigger contrast to the white.
>
>
>
> On 7 October 2013 22:44, Ryan Allen >wrote:
>
>> https://github.com/django/django/pull/1715
>>
>> Currently, all admin messages have a background color of light yellow,
>> whether they are success
https://github.com/django/django/pull/1715
Currently, all admin messages have a background color of light yellow,
whether they are success message, warning message, or error message. Errors
are displayed with red (#F00) text.
This pull request would give success messages a green background and
Up for discussion - https://github.com/django/django/pull/1715
The alert messages in the Django admin do not abide by the UX philosophy
"Don't Make Me Think". All messages whether success, warning, or error,
have a background color of yellow. This pull would change the bg-color of
successes to
Only is a different purpose than first, and as such it would make sense to me
if it was a separate method. First has some implication that there may be
second, third as well. It comes down to taste, but I think my buds would prefer
a separate method.
Ryan
—
Sent from Mailbox for iPhone
On
1 - 100 of 150 matches
Mail list logo
