Am 22.02.2012 19:46, schrieb Maciej Fijalkowski:
> On Wed, Feb 22, 2012 at 9:59 AM, wrote:
>> What is the hash of "ePjNTUhitHkL"?
>>
>> Regards,
>> Martin
>>
>> P.S. It took me roughly 86h to compute 150 strings colliding for the 64-bit
>>
e the same understanding.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
elf, but then also in extension modules.
I agree that moving the structures into the implementation is fine,
as long as there are sufficient access functions (for dictionaries,
there are plenty, of course).
Regards,
Martin
___
Python-Dev mailing list
e,
> hard-to-forget forms of % formatting (%s, %d, %f, without elaboration).
If that issue was getting serious, I would prefer if the .format method
was deprecated, and only % formatting was kept.
I doubt this is as much of an issue as you think, though.
quence, both APIs for formatting will coexist for a long time
to come (ten years at least); no deprecation is planned.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
was to understand the notion
of "placeholder", which I think is the reason why people are coming
up with so many templating systems (templating isn't "obvious").
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http
uldn't use the __future__ import, but the u() function.
> IIRC, I've previously opposed the restoration of unicode literals as a
> retrograde step. Looking at the implications for the future migration
> of PulpDist has changed my mind.
Did you try to follow the path of the u(
with u'' literals in
> them.
These can be easily fixed, right?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
r.
There are a few other unproven performance claims in the PEP. Can you
kindly provide the benchmarks you have been using? In particular, I'm
interested in the claim " In many cases 2to3 runs one or two orders of
magnitude slower than the testsuite for the library or applicat
's not that there is any (IMO) good
technical reason for the feature - only that people "hate" the many
available alternatives for some reason.
But then, practicality beats purity, so be it.
Regards,
Martin
___
Python-Dev mailing list
P
Am 27.02.2012 18:05, schrieb Ethan Furman:
> Martin v. Löwis wrote:
>> Am 26.02.2012 07:06, schrieb Nick Coghlan:
>>> On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum
>>> wrote:
>>>> A small quibble: I'd like to see a benchmark of a 'u' fu
the PEP -- my apologies.)
Well, if you didn't, you wouldn't have the same sources on 2.x and 3.x.
And if that was ok, you wouldn't need the u() function in 3.x at all,
since plain string literals are *already* unicode strings there.
Regards,
Martin
_
not theoretically)
In turn, I would ask that this counter-argument of mine is also
reflected in the PEP.
The whole point of the PEP process is that it settles disputes.
Part of that settling is to avoid arguments which go in circles.
To that effect, the PEP author ideally should *quickly*
"This for instance is the case for
the Jinja2 library".
On the contrary, I'd expect that the build time using 2to3 is
significantly shorter than the test suite run times, *in particular*
for large projects. For example, for Django, 2to3 takes less
Python 3 language. So the
specification clearly corresponds to the intent also.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
str(string_literal).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
st/crashers
> should be empty.
I agree. If you have patches to review, just put me on the nosy list.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
quest should not take more than 20 seconds,
else it's too much. It must be less than 2 seconds for interactive use,
and less than 1s if you get more than 100 requests per second. If these
numbers sound arbitrary to you: they are. They are still useful to me.
Regards,
Martin
__
is also a code base that will be around
for a long time to come, so any effort spend on this today will pay
off in the years to come.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> I think it would be nice for Python3.3 to implement the PEP-3118
> suggestion:
>
> 'c' -> UCS1
>
> 'u' -> UCS2
>
> 'w' -> UCS4
What is the use case for these format codes?
Regards,
Martin
___
stem. I guess that the
registry key for the DLL has a non-zero refcount before you started the
installation, so that the refcount didn't drop to zero when you uninstalled.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:/
Am 11.03.12 16:02, schrieb Guido van Rossum:
Martin has asked me to decide on PEP 382 vs. PEP 402 (namespace
packages) in time for inclusion of the decision in Python 3.3. As
people who attended the language-sig know, I am leaning towards PEP
402 but I admit that at this point I don't
e name and version twice in the path.
Do we *really* need this?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/arch
es. At least, that's the feedback I always get for the
Python documentation (typically contrasting it with the PHP
documentation, where the specification-style portion is typically
ignored by readers, which then move on to the user-contributed
examples).
Rega
> But don't bother to find out how to restart it just for me. I presume
> Martin knows the setup and will do it later.
It seems to be working fine now, and I didn't do anything. Thomas
rebooted the system for hardware inspection at 15:02 (and brought it
back up at 15:18), so
o, and was since waiting for
a contribution of a patch that makes it happen.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/p
without path
modification, and it will get the correct Python version even (which
neither the path manipulation nor the file association could achieve).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
> I don't see what is the use case requiring a is truly monotonic clock.
A clock that is purely monotonic may not be useful. However, people
typically imply that it will have a certain minimum progress (seconds
advanced/real seconds passed). Then you can use it for timeouts.
Regards
> How serious a problem this is for the Python 3.3 release? I could do the
> optimization, if someone is not working on this already.
I think the people who did the original implementation (Torsten,
Victor, and myself) are done with optimizations. So: contributions are
welcome. I'm not aware of an
plete.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Am 27.03.2012 23:11, schrieb "Martin v. Löwis":
> Upfront hosting (Izak Burger) is going to do a Debian upgrade of the bug
> tracker machine "soon" (likely tomorrow). This may cause some outage,
> since there is a lot of custom stuff on the machine which may
> br
Am 28.03.2012 23:55, schrieb R. David Murray:
> Since Martin hasn't sent a note about this here I will:
>
> I noticed that text search wasn't working right on the bug tracker, and Martin
> has taken it offline again to re-index.
which will, unfortunately, take a few
>> I noticed that text search wasn't working right on the bug tracker, and
>> Martin
>> has taken it offline again to re-index.
>
> which will, unfortunately, take a few more hours to complete.
It seems to work now, so I turned it on again. Text search now uses
Xapi
Am 29.03.2012 18:21, schrieb Ross Lagerwall:
> On 03/29/2012 05:07 AM, "Martin v. Löwis" wrote:
>>>> I noticed that text search wasn't working right on the bug tracker, and
>>>> Martin
>>>> has taken it offline again to re-index.
>&
otage of using git
> (and bzr) for cpython, then that's the only explanation I can
> understand, otherwise it doesn't make sense to me why these files are in
> HG repository at all.
>
Sabotage, most certainly.
Regards,
Martin
___
Pytho
gdb
extensions (requires gdb with Python support) are really powerful; they
will automatically render PyObject* by displaying the actual logical
value (and not just for strings).
Failing that, I use _PyObject_Dump to display strings; this requires a
debugger that can call functions in the deb
> The Tk fix Terry refers is applicable only to the OS X Aqua Cocoa Tcl/Tk
> 8.5 port. It has nothing to do with Windows, any other OS X Tcl/Tk, or
> any other platform. Further, the Tcl/TK source Martin is talking about
> is used only by the Windows installer builds. The pyt
this is done by a plain shell script,
one could also make this a post-update Mercurial hook.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
stepping
with pdb would, of course, be better than that, but I doubt it's
feasible.
In addition, there might be a performance gain with Cython over ceval.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
> So like execute hg diff on the dependent files and if nothing changed
> then touch the auto-generated file w/ 'touch' to prevent future attempts
> to execute the target?
Exactly. There might be something better than hg diff, perhaps some form
of hg statu
Am 16.04.2012 19:44, schrieb Antoine Pitrou:
> On Mon, 16 Apr 2012 13:33:45 -0400
> Brett Cannon wrote:
>> On Mon, Apr 16, 2012 at 13:08, "Martin v. Löwis" wrote:
>>
>>>> So like execute hg diff on the dependent files and if nothing changed
>>>&
he _subprocess and
> _multiprocessing.win32 modules now live in a single module "_winapi".
> Patch by sbt.
Can we use Real Names, please?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
new-bugs-announce.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e considered a bug, or
> should I work around it? Thanks.
If there is such a difference, it's a bug. The authority should be the
PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
loss of
performance needs serious justification. Easier maintenance is not
a sufficient reason.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
y. It will take some time, but it would be
possible to add parallel APIs that neither borrow nor steal references,
and have them preferred over the existing APIs. Then, with Python 4,
the old APIs could go away.
Regards,
Martin
___
Python-Dev mailing
rtable dealing with pseudonyms in the
net, more so since I committed code from (and, IIRC, gave commit rights
to) Reinhold Birkenfeld. Of course, the issue is different when you
*know* it's pseudonym (and no, I have no bad feelings towards Georg
about this at all).
Regards,
Martin
_
ay immediately. Otherwise, it should be
deprecated-then-removed.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
hat the right-most separator should then also be
used to separate __pycache__, but only that the right-most of
either SEP or ALTSEP is what separates the module name.
In any case, Barry apparently took this comment to mean that the
rightmost separator should be preserved.
So I don't think t
ble
on Unix but not on Windows.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t public, not specifying it as PyAPI_FUNC.
I agree that too much API is public, but the right approach is to rename
such API to _Py*, indicating to users that we don't want them to use it.
For existing API, that's tricky; for new API, I thin
et_objects())
run_complicated_tests()
end = pympler.muppy.get_size(pympler.muppy.get_objects())
print "delta mem: %d" % (end-start)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
Regarding Eric's hint: It seems that this agreement needs to be signed
and mailed. Can I sign/scan and email it to somebody?
Yes, see
http://www.python.org/psf/contrib/
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
egal issues, but also the responsibility for the
code. Otherwise, we end up with code that still nobody owns, and the
out-of-core version still gets better support.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
and VS 2012 for 3.4).
Regards,
Martin
P.S. There is (as of yet unconfirmed) rumor that VS 2012 won't support
XP, which would clearly rule it out for Python 3.3, and likely also for
3.4. It also appears that VS 2012 might include the VS 2010 tool chain,
which means that this tool chain won't
ge managers will do
this for you)". Or is that too much of a moving target to be worth
trying to specify?
I think a buildbot admin should be able to figure out what user the
buildbot to run under himself; if that already is a challenge, it mig
could change it to cover as OS which is not
already covered by the buildbots.
I'm not sure how useful it is to have a build slave which you can't
commit to having for more than 3 months. So I'm -0 on adding this
slave, but it is up to Antoine to decide.
On 02.05.2012 08:07, Senthil Kumaran wrote:
On Wed, May 2, 2012 at 1:55 PM, "Martin v. Löwis" wrote:
I'm not sure how useful it is to have a build slave which you can't
commit to having for more than 3 months. So I'm -0 on adding this
slave, but it is up to Antoine
a more appropriate forum for website
issues/questions).
I would send the above to webmas...@python.org (should be at the bottom
of pages).
Please don't (unless you want your message ignored).
Regards,
Martin
___
Python-Dev mailing list
Python-
Are the download pages for older Python versions supposed to be kept up
to date at all?
I occasionally update them when I see issues with them. Your specific
issue, I missed so far.
If you would like to make this kind of update, please let me know.
Regards,
Martin
uld
be possible to find out whose key has been used (although *not*
from the commit message), and revoke that, but the damage might
already be done.
Regards,
Martin
P.S. Another attack vector is through the master: if somebody
hacks into the machine running the master, they can also compromise
fine. However, we don't have any "make coverage" target currently in
the makefile. So if you contribute that, we could then have it run
daily.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
he English abilities of many of
us foreigners. I had to read Larry's text five times (two times after
you indicated that it indeed ought to rhyme - it finally worked when
I read it aloud).
So, folks: if you want to be understood, please keep the obfuscation
of the English language to a fairly l
rt it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
g itemized
lists including numbers. I think readers are very capable
of filtering this kind of information.
As for presenting highlights: the PEPs *are* the highlights of a new
release. The numerous bug fixes and minor enhancements don't get listed
at all.
will only affect pythonXY.dll.
That executable may be different from the regular python.exe, and
it might be necessary that it locates its Python installation first.
For Unix, symlinks sound fine. Not sure what the issue with OS X is.
Regards,
Martin
___
o the binary
inside the bundle. But if this is needed to know, I suggest that some
environment variable is passed from the stub to the actual binary
(akin PYTHONHOME). How does the stub normally find out where the
framework is located?
Regards,
Martin
___
On 07.05.2012 18:35, Carl Meyer wrote:
On 05/07/2012 03:52 AM, "Martin v. Löwis" wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS
On 07.05.2012 21:23, stefan brunthaler wrote:
Hello,
http://www.python.org/psf/contrib/
I took care of the formalities.
I am not sure how to proceed further. Would python-dev want me to draft a PEP?
Submit a patch to the bug tracker, against default's head.
Regards,
M
Is there a better way?
Dear Alex,
As Terry indicates: python-dev is a list for the development *of*
Python, not the development *with* Python. Use the general python-list
or the xml-sig list for this kind of question.
Regards,
Martin
___
Python
ecified attributes: "run-time environment" doesn't mean much
to me - my first guess is that it is the set of environment variables,
i.e. a dictionary identical to os.environ. I assume you mean something
different ...
gc_type is supposedly a string, but I cannot guess what possi
We've been over this before: collections.namedtuple *is* the standard
library's answer for structured records.
And I think it's a really ugly answer, and one that deserves a parallel
that is not a tuple. If this is contentious, I'll write a P
void_p = 8 if architecture()[0] == '64bit' else 4
+self.sizeof_void_p = 8 if sys.maxsize> 2**32 else 4
Why not unconditionally use sys.maxsize? I'd also hard-code that
sys.maxsize ought to be either 2**31-1 or 2**63-1.
Regards,
Martin
__
efore that
were available only from Mark Hammond.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
dictionary
lookup (PyObject_GetAttr) will be much faster.
Just make sure to use interned strings, and to cache the interned strings.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
c lookup
any time. Just define a common base class, and have all interesting
types inherit from it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
As this is apparently only relevant to speed fanatics, too, I suggest
that you check how fast PyPI works for you.
Did you mean PyPy?
Oops, yes - Freudian slip :-)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
rings.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
pass the exact function that caused the failure.
I'd weaken the documentation to just specify that the error-causing
function is reported, indicating that the exact set of functions
may depend on the operating system and change across Python versio
(leaving CE/Windows Mobile/WP7 aside).
The only place where platform support matters is the CRT, and this is
what I still want to test. E.g. it might be that the C RT works on XP,
and the C++ RT might use newer API.
Regards,
Martin
___
Python-Dev mai
. There
may be more dependencies on Vista+.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
I really wish the bug fixes had been made to SRE, instead of rewriting
it all. So I'm -0 on this regex module. If this isn't added to 3.3,
I'll start encouraging people to contribute changes to SRE for 3.4, and
just ignore the regex
n addition, I think it's
too complicated, both for users, and for the actual technical
implementation.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ready implements
significant parts in Python).
As a speedup module, it's uninteresting - we want to simplify
maintenance, not complicate it. So this can only work if it replaces
SRE.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pytho
would
still be supported, and not go through any notification period.
Objections?
As a consequence, we could then change some of the deferred-loading
stuff for "new" (i.e. XP+) API into proper linking.
Regards,
Martin
___
Python-Dev mailing list
P
On 03.06.2012 18:18, Larry Hastings wrote:
On 06/03/2012 08:32 AM, "Martin v. Löwis" wrote:
So I propose to just remove the claim from the PEP that 3.3 would
still be supported, and not go through any notification period.
Did you mean
s/3.3/Windows 2000/
?
I meant "
ither have to work hard on fixing the
problems, or will be responsible for breaking Python 3 in a serious way.
That's why nobody volunteers.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
fix reported bugs, by various people.
It may be aged software, but that has the advantage that more people
are familiar with the code base now than back in the days when /F
was still maintaining it.
Regards,
Martin
___
Python-Dev mailing list
Python
e that a maintainer for SRE may come back.
Gustavo Niemeyer had that role for some time after /F left, and
anybody sufficiently interested in a specific new feature might
grow into that role as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@
t at some point, somebody contributes yet another profiling
tool which may well supersede both profile and cProfile. If you are
interested in profiling in general, I suggest that you could rather work
on such code, and release it to PyPI.
Regards,
Martin
__
s not necessary.
So in theory, your change should have no effect, unless somebody has
modified some environment variables.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
also has assertions that can be disabled at compile time.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
4
(assuming that's when the next release is made).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
en, after the Fukushima accident, decided to revert that decision
(der Ausstieg vom Ausstieg vom Ausstieg aus der Atomenergie)).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
he raw unicode literals will be rejected (not by
explicitly detecting them, though).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
n your QA cycle, when it may be tough to track down the origin.
> I'd rather make ru"\u03b3" a syntax error if we can't give it the same
> meaning as in Python 2.
That's exactly the proposal, see
http://bugs.python.org/issue15096
http://bugs.python.org/fil
have a specific question about it, feel
free to ask. However, "teach me how to debug" is best asked on other
mailing lists.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
ed ahead accordingly.
Expect some rushing of PEP 397 then.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ersal might have been avoided.
> Dicts get their efficiency from sparseness.
> Reducing the mindict size from 8 to 4 causes
> substantially more collisions in small dicts
> and gets closer to a linear search of a small tuple.
Why do you think the dictsi
int on the syscall function, and see when it gets hit.
I'd also attach to a running Python interpreter instead of running
python from gdb, since the interaction between gdb's stdin
and python's stdin may be confusing.
Regards,
Martin
___
P
4301 - 4400 of 5764 matches
Mail list logo
