I've been bitten by this once before as well but I think it's the kind of
mistake you make once and never again, and if you happen to encounter it
again you immediately know what it is (duplicated/missing items across
pages? must be a non-unique ordering).
I don't think implicitly adding an ext
I feel like this is a very niche use case and probably doesn't warrant
implementing field-to-column one-to-many relationships in Django, I don't
see why this specific case can't be implemented as:
1. A model that implements the data type
2. A custom field + custom datatype on the database backen
what that would look like.
+1 to OIDC, CORS and DB defaults
If nothing else, this thread has at least made me aware of some interesting
tickets :-)
Adrian
On Tuesday, November 29, 2022 at 5:35:40 AM UTC+1 Adam Johnson wrote:
> I am not sure the db level defaults PR is suitable for a GS
I finally had some time to do some work on this and have submitted a patch
at https://github.com/django/django/pull/16302 in case anyone is interested.
On Wednesday, October 5, 2022 at 2:24:35 PM UTC+2 carlton...@gmail.com
wrote:
> Hi Adrian.
>
> Nothing has been done, no.
>
varchar) is the best solution, but I'm also ok with Carlton's
idea of having a subclass in contrib.postgres is an acceptable compromise.
Cheers,
Adrian
On Monday, August 17, 2020 at 11:26:39 AM UTC+2 t...@carrick.eu wrote:
> It would work for my use-cases. It was mentioned that it&
ady to face the consequences.
I like the `UnvalidatedModel` vs `Model` idea proposed by Aaron.
Cheers,
Adrian
On Friday, September 30, 2022 at 3:39:20 AM UTC+2 aa...@aaronsmith.co wrote:
> I would also like everyone to know, my objective in starting this thread
> is to get the go-ahead to
model and have a FK between Pricing and
Product -- I know you want to avoid this, but to me it sounds simpler and
more maintainable than going the custom field route.
Cheers,
Adrian
[1] https://django-polymorphic.readthedocs.io/en/stable/
On Wednesday, August 10, 2022 at 6:44:55 PM UTC+2 ja
A common idiom is also
```
try:
foo = Foo.objects.get(x="foo")
except Foo.DoesNotExist:
foo = None
```
which is pretty pythonic IMO, but I wouldn't be opposed to a keyword-only
argument on `get` that returns `None` if not found
```
foo = Foo.objects.get(x="foo", strict=False)
# or
foo =
I personally dislike Adam's suggestion and feel like it makes it worse than
the current default, but to each their own.
I do prefer the proposed solution of the config directory, I am working on
two django projects in parallel and one follows the proposed config scheme
and the other doesn't (us
goXXWarning?
Should I follow the documentation at [1] for this implementation?
[1]
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature
Cheers,
Adrian
On Saturday, March 5, 2022 at 7:30:18 PM UTC+1 f.apo...@gmail.com wrote:
ial_configuration(request, user)
user = self.synchronize(request, user)
return user
Which is the same as having two separate methods for initial configuration
and synchronization, but with extra steps.
Have a good weekend,
Adrian
On Sat, Mar 5, 2022 at 12:54 PM Florian Apolloner
wrote:
would be more disruptive for existing
implementations.
Thank you in advance for your inputs,
Adrian
--
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 receivin
Declarative settings, and a lack of a good settings file parsing system,
led me into some rather interesting directions not that long ago.
I maintain an OpenStack project called Adjutant, and I built it on
Django, but ended up using yaml as my config file and having settings.py
read it and pull in
A backport probably isn't needed, but I strongly urge deprecation. The
library has had a few failed attempts at pick up, but ultimately those
who wanted to do that just moved to pymemcached, and anyone else
sensible will do the same. There is no need or want to maintain
python-memcached when a stro
7;s also a very
> simply update process.
>
> On Monday, November 25, 2019 at 6:46:05 AM UTC+7, Adrian Turjak wrote:
>
> A while ago now I opened a ticket that we need to deprecate the
> python-memcached backend in Django, and ideally make a new one which
> uses Pinteres
ccessor in
pymemcache.
I'm sadly not in a position where I can contribute this myself, but
would be happy to test/review. Are there any willing contributors for
this? Or some people from the Django core team which will tackle this?
Cheers,
Adrian Turjak
--
You received this message
There was a push to deprecated % formatting but too many people complained and that never happened.While .format and g-strings are superior, % is here to stay for the foreseeable future. Too many people still use it (including myself sometimes).On 1 Nov. 2018 08:14, Carlton Gibson wrote:We had a b
Through some of my last few projects using Django and Memcached I kept
running into the problem that python-memcached appears to no longer be
maintained[1], and even before that the release frequency was getting
quite low.
For Django pylibmc is an alternative, but having to rely on an
underlying C
Paroz escribió:
>
> Hi Adrian,
>
> I don't see anything related to Django development in your post. Maybe
> this was more for the django-users mailing list?
>
> Claude
>
> Le jeudi 30 novembre 2017 02:39:31 UTC+1, Adrian Mansilla a écrit :
>>
>> I am using th
I am using the function 'validate_password (password, new_user)' and I have
my settings configured in Spanish, the problem comes when the
validate_password function raises an error with the word 'contraseña' and
shows me this error:
ValidationError: [u'La contrase\xf1a es demasiado similar a l
ne place, not to be a "we will definitely do this" feature plan.
Adrian
On Mon, Apr 14, 2014 at 11:05 PM, Loic Bistuer wrote:
> I'm +1 on this.
>
> I do "forms in the templates" with a `{% field %}` templatetag that
> controls labels, placeholders, help_texts, etc.; Th
ody with
more familiarity with Python's PEP process provide some suggestions?
Adrian
--
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, send an email
to django-develo
#x27;re neutering the server, making development more difficult.
Long story short: go ahead and implement that robust support, with tests,
and I can take the lead on reviewing the patch. Email me offlist when it's
ready, if you could, so I don't lose track of it. Thanks for bringing this
up!
s, we would need to change DeferredAttribute to find all
*other* DeferredAttributes on the given model and load them in a single
query somehow.
Also, I should mention that this should be *optional* behavior, as the
current behavior is reasonable for the common case. The API for specifying
this &quo
ore
theoretical level, it introduces more coupling between URL patterns
and views.
Adrian
--
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, send an email
to django-
> wants to maintain it to take it over.
Late to the party, but +1 from me.
Adrian
--
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, send an email
to django-
o-users and the
djangoproject.com blog.
Adrian
--
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-developer
To
Do. Of course, there's no rush to do everything -- we can just nibble
off bits here and there.
I'll have some free time soon and would be happy to help out migrating
code. (Relatively) mindless refactoring like this is one of my
favorite things to do. :-)
Adrian
--
You received this
ons, so there might be an
> obvious and elegant solution that I'm missing, but I wanted to flag it
> so that it's kept in mind.
I'm hoping Jannis or somebody else with translation expertise will
chime in on this -- I have no idea what the repercussions/solutions
could
per our deprecation policy. The one
controversial thing would be requiring people to install their needed
django-localflavor-* packages when they upgrade to 1.5.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
he work myself on Sept.
1 (http://www.holovaty.com/writing/goodbye-everyblock/). :-)
Adrian
--
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 fro
On Fri, Apr 27, 2012 at 10:08 PM, Adrian Holovaty wrote:
> OK, it's live!
>
> https://github.com/django/django
Hi all,
I've written a post-mortem here, for anybody interested in how the process went:
http://www.holovaty.com/writing/django-github/
Adrian
--
You received t
On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote:
> We're going to do the migration to GitHub today. This means we'll no
> longer be committing code to our Subversion repository. Committers,
> please hold off on making commits until the migration is done.
OK
On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote:
> We're going to do the migration to GitHub today. This means we'll no
> longer be committing code to our Subversion repository. Committers,
> please hold off on making commits until the migration is done.
>
> I exp
" and "cell,"
both of whom were given temporary commit bits during a sprint six
years ago.
* If you're a Git/GitHub expert and are interested in helping, feel
free to join us in #django-dev on Freenode.
* Thanks in advance for bearing with us during this process. There
will b
ality is worth adding to
the framework. It's easy enough to make your own custom manager that
does the same thing. If you'd like to share it with others, toss it
online somewhere.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django devel
u'd need to tell the admin how your User model interacted with
it -- how it authenticates, how permissions work, etc.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develope
DERS = [(MALE, 'Male'), (FEMALE, 'Female')]
gender = models.IntegerField(choices=GENDERS)
def greet(self):
return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
If people aren't understanding that, we should improve our documentation.
t-came-from-planet-architecture.html
Adrian
--
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
djang
utions from
non-students (right?), I don't think the User refactoring would work
as a Summer of Code project. Sorry to break this news, as you've
clearly done a lot of preparation and thinking about the issue, but of
course we'd love to have you contribute to this particular feature
and in terms of code maintenance/understanding.
(django/utils/tree.py, anyone??)
I think our policy should be: make the simplest thing that can
possibly work for a narrowly-tailored use case, then make things more
generic *slowly* if there's a demand. No need to be an Architecture
Astronaut.
'email'" --
or "this User model doesn't have email addresses."
I chatted about this with Jacob on IRC, and we reached consensus on
this approach. I'd like to get moving on this and would be happy to
take it on myself, starting next week.
Adrian
--
You received t
umented things,
write up a patch for the release notes if you'd like. Specifically,
add it to the "Backwards incompatible changes in 1.4" section in
docs/releases/1.4.txt.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers&qu
aesthetic reasons. It's much easier to visually parse
single-line tags, and multi-line tags look ugly.
Granted, there are some situations in which multi-line tags are an
improvement (see the example by h3 in this thread), but those are
relatively rare and don't make it worth it to me.
Adri
o late now to add it to Django 1.4, but I'd
like to implement this for the next version.
Adrian
--
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 unsu
u should read: http://www.holovaty.com/writing/back-to-django/
ETA is sometime soon after we launch 1.4.
Adrian
--
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
y.
Not yet, alas, but hopefully soon.
Adrian
--
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+u
s, long line lengths are totally fine (and encouraged if it means
more readable code). It's the year 2012.
Adrian
--
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@googlegrou
I can't say how people abuse
> it).
Two points:
* If we decide to change the admin site to use LESS, we should ship
compiled CSS. No need to introduce the less.js overhead.
* I have been working on a Python LESS compiler in my spare time, and
there could be a use for it in here.
Adri
On Thu, Jan 19, 2012 at 12:15 PM, Carl Meyer wrote:
> I don't think Adrian is proposing anything as extensive as #17. What
> he's proposing (IIUC) wouldn't change the semantics of your sample code
> at all. All it would do is prepopulate the FK field on the results of a
&g
of the test suite (on sqlite3) from 1700 seconds to around 500
> seconds. On postgresql I reduced the run time from 5000 to 2500
> seconds.
Wow! Just wanted to say thanks for doing all of this work and making
these optimizations. I'm going to take a look at #16759, along with
your Git branc
[0].author
"""
I'm pretty sure there's a long-standing ticket for this, but I'm not
sure which one it is. Shai, does your solution approach this in a way
that can solve the issue for ForeignKeys as well?
Adrian
--
You received this message because you are subscribe
a (the empty dictionary), and it makes
sense that Django would see the empty data, then determine that empty
data is allowed on the fields (blank=True) and set those fields to
empty data. If you want to avoid this, you have two options: don't use
"blank=True," or don't use a model
On Sat, Dec 10, 2011 at 6:37 PM, Alex Gaynor wrote:
> 2.5 is EOL and no longer receiving security patches even, it is
> *irresponsible* of us to support it (I claim). ANyways +1
This is a very good reason I hadn't though of.
Anyway, looks like this is a plan! Excellent.
Adri
are great -- start merging the Python
3 work right after we release 1.4, and drop support for Python 2.5 in
trunk after 1.4 is released.
Thanks for the suggestion, Luke.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
On Tue, Nov 29, 2011 at 6:10 AM, Luke Plant wrote:
> On 28/11/11 20:33, Adrian Holovaty wrote:
>> I plan on starting this next week. Is there a list somewhere of what
>> needs to get done? If not, I can make it, but obviously it'd be great
>> if that already existe
ia the ticket
tracker (code.djangoproject.com).
Adrian
--
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+unsubsc
s bad user sanity checking, or
> HttpResponseRedirect() not being flexible enough?
I'd classify this one as bad user sanity checking. Doesn't seem like
the thing that happens frequently enough for us to check for it.
Adrian
--
You received this message because you are subscribe
issing but these are the most important changes):
Thanks for splitting these up, Jonas! I can commit to reviewing and
committing these in the next few days. I just took care of
https://code.djangoproject.com/ticket/17335 as a first step.
Adrian
--
You received this message because you are subs
underlying restaurant? That seems backwards -- cascading deletion
works the *other* way (e.g., if you delete a restaurant, then any
Table with a ForeignKey to it would get deleted). Sorry if I'm being
dense and am missing something.
Adrian
--
You received this message because you are subscrib
that you'll create), and post an update to this thread so
that I'm notified in case I missed the ticket.
Thanks for being willing to help out with the docs!
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
; for applying migration fixtures.
Just to be clear, how would you get the "diff" of what's changed?
Would it automatically change the fixture files after you close the
shell session? Or would that be up to you?
Adrian
--
You received this message because you are subscribed to the G
}
>
> Search post_delete in django/db/models/deletion.py. Signals seem to be sent,
> even for cascaded deletion.
H, that is not ideal behavior. You mean QuerySet.delete() calls
the signal for each deleted object, rather than doing a delete at the
database level?
Adrian
--
You receive
sly it'd be great
if that already existed.
Adrian
--
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
ble
> - c becomes queryable: A.objects.filter(c=x)
Hi Roald,
Thanks for suggesting this. I don't think it's worth implementing,
though, because you can already query across multiple foreign-key
relationships like this:
A.objects.filter(b__c__exact=x)
As for making C.a_set avai
d friends.
Totally agree we should set clear expectations that "ne" does not mean
we'll be getting nistartswith or any other negative lookup -- good
call in bringing that up. This should be treated as a special case for
a common case.
Adrian
--
You received this message becaus
ng exclude() with a single "exact" lookup parameter would
get the benefit; we could get trickier beyond that, but...diminishing
returns.) We could also do both.
I'm inclined to say we do the former -- restore the "ne" lookup type
-- because it's a quick fix, and ask someb
for the existence of a
setting, use it if it exists, and fall back on hard-coded defaults
otherwise.)
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@google
or so for folks to
chime in with reasons to keep it.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
dja
named Backend" -- and is an opportunity to make a
mistake. :-)
Unless Jacob feels strongly otherwise, let's go with class-based.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send ema
by committers) before a quick commit. In fact, it should be entirely
opt-in, not opt-out. "Please let me know by Thursday evening (GMT) if
there are objections" is not acceptable, IMO.
Adrian
--~--~-~--~~~---~--~~
You received this message because you are
ted branch. I'll post a note here
when I've got that up and running.
Adrian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-d
p the legacy decorators
-- transaction.commit_on_success(), etc. -- and they'd just work on
the default connection. But we'd encourage people to use this new API.
My proposal is not necessarily to get this in Django 1.1, but to get
it in trunk at the very least. I'm selfishly motiv
I don't see it introducing any bugs (famous last
words, right?)...
Then, the next step would be to change django.db.transactions to use
this connection list, as Alex pointed out in a previous e-mail in this
thread.
Adrian
--~--~-~--~~~---~--~~
You received this
re of
the multiple connections. All of the functions in there deal directly
with the global connection, and I don't immediately see an easy way to
refactor things to work on separate connections. Any ideas? Alex, have
you addressed this in the Grand Proposal of yours? :-)
Adrian
--~--~-
On Thu, Mar 12, 2009 at 7:59 PM, Alex Gaynor wrote:
>> I've created a ticket here:
>>
>> http://code.djangoproject.com/ticket/10487
>>
>> If anybody (Alex?) wants to code up a patch, I'll get it in ASAP.
>>
>> Adrian
>
> I've gon
me.
I've created a ticket here:
http://code.djangoproject.com/ticket/10487
If anybody (Alex?) wants to code up a patch, I'll get it in ASAP.
Adrian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"
stions on how to upgrade third-party backends or your own
hacks, please just respond to this and I'll try to help. If you don't
get a response within a day or so, just e-mail me off-list to get my
attention.
Adrian
--~--~-~--~~~---~--~~
You received this m
riable
whenever the code needed to refer to self.settings_dict many times.
http://code.djangoproject.com/changeset/10026
This will most probably break external database backends, so I'll send
out a separate django-developers note about that, in hopes of getting
their attention.
Adrian
--~--~-~--
that when we create
> the connection we have all the information we need then.
Hey, this sounds like a good improvement (passing the settings to the
constructor instead of _cursor). Do you have any patches or at least a
link your proposal, if you've written one? I ca
ads me to believe there are no
backwards-incompatibility issues with making this change. But I'm
bringing it up here in case anybody wants to point out problems before
I commit it.
Adrian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goog
e a reference to the flatpage object itself.
>
> Any opposition to the idea?
Yes, this gets strong, strong opposition from me. The fewer signals we
have in our framework, the better. It still bugs me that we have as
many as we have now, frankly.
Adrian
--~--~-~--~~~---
to trunk? Do you want me to
> submit a ticket and/or patch?
Hi Matias,
Sure, go ahead and file a ticket in our ticket system, here:
http://code.djangoproject.com/newticket
Adrian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
ten in django documentation. That leads to
>> misunderstanding in expectations, and should explain why some tickets
>> don't get expected resolutions.
>
> Adrian may not use it, but I certainly do, as do plenty of other folks
> I know. Which means, I guess, that it's ti
, so that's all I could come up with in a hurry.
Hope people find this easier and faster to use!
Adrian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to th
ist discussion wasn't linked-to on this one, so I'm
going purely on the name of the change -- but I really don't like it.
I rarely use RequestContext; I'd even feel comfortable saying I
dislike it strongly. I would not like to see render_to_response()
require it.
Adrian
--~--~
hacks currently used to filter CSS for
> IE
> 4. Encourage reuse of existing admin styles in custom app admins
This all sounds good to me...particularly the part about removing the
null.css file!
Adrian
--
Adrian Holovaty
holovaty.com | ever
e "standard" admin for the third-level
objects, then use two-level inlines for the first- and second-level
objects?
Adrian
--
Adrian Holovaty
holovaty.com | everyblock.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you
I havent gotten used to the new docs yet ...)
The old ones are available here:
http://www.djangoproject.com/documentation/0.96/
And don't worry about the new docs...I've been making some
improvements to the new index, which I agree could use some work.
Adrian
--
Adrian Holovat
www.djangoproject.com/documentation/0.96/
> and
> http://www.djangoproject.com/documentation/0.95/
Hey, you're right! I got confused by our inconsistency: for the 0.90
and 0.91 docs, we use /documentation/0_91/ (note the underscore
instead of the period).
Thanks for pointing this out,
Adrian
ion, but we could pop 'em online if there's an outrage.
Adrian
--
Adrian Holovaty
holovaty.com | everyblock.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
this page:
http://search.twitter.com/search?q=djangocon
Adrian
--
Adrian Holovaty
holovaty.com | everyblock.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post t
still be the case, over the next year or so?
>
> In other words, should I (or typical users) download the official 1.0
> version, or will it still be advised to track the development version?
I think it's too early to tell, but the cool stuff is always going to
be in trunk.
Adrian
k when forms
was called newforms!"
Adrian
--
Adrian Holovaty
holovaty.com | everyblock.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
e who have created custom managers.
Other solutions?
Adrian
--
Adrian Holovaty
holovaty.com | everyblock.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
T
s long as we advertised that it's on the way
> out we shouldn't have too much trouble.
Let's do it. I've been thinking this same thing over the past couple
of weeks. Let's get the thing out the door.
Adrian
--~--~-~--~~~---~--~~
You recei
On 21 Mai, 15:50, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Fri, May 16, 2008 at 9:27 PM, Adrian R. <[EMAIL PROTECTED]> wrote:
>
> > Okay, so I've got some additional information for you which are
> > hopefully useful for you. I've
'numEvalResults': 'COUNT(IF(er.TestRunId =
tr.TestRunId, 1, NULL))',
'DeviationA': 'COUNT(IF(er.TestRunId = tr.TestRunId
AND er.DeviationGrade = \'A\',1, NULL))',
'DeviationB': 'COUNT(IF(er.TestRu
ng the same tables but aliasing them
which does AFAIK not work with extra(tables=[...])).
The database view performs really bad, so I'm trying to relocate the
SQL into the Django ORM. The problem is now, that I can't use the
default QuerySet-functions to
On 14 Mai, 17:44, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> Adrian, disregard my previous question (you're using your own paginator).
>
> Does your paginator use len(set) or does it use set.count() to determine the
> number of items? You should fin
1 - 100 of 909 matches
Mail list logo
