Re: [Python-Dev] Format strings, Unicode, and Py2.7: need clarification

[Random832]

On Thu, May 18, 2017, at 01:14, Hobson Lane wrote:
> Because `.format()` is a method on an instantiated `str` object in e and
> so
> must return the same type

That it *must* return the same type is overstating the matter. Split
returns a list (and, rather like %, the list is of unicode or str
objects depending on the argument). Join will return a unicode object if
any of the elements of the sequence are unicode. I was honestly
surprised though to see that % returns unicode when formatting a unicode
value, since my mental model of %s was more like {!s} - call str() on
whatever object is at the given position in the right-hand argument.
This kind of ad hoc implementation decision (format always returns str,
other methods can return unicode,  ljust/rjust refuse to accept a
unicode character argument) is what Python 3 moved away from.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Why doesn't Python's _multiprocessing.SemLock have 'name'?

[Wen Yaobin]

Hi,

This is not a general Python question but about a specific detail: *Why
doesn't Python's _multiprocessing.SemLock have 'name'?*

I posted the question on Stack Overflow but so far haven't got any
response. The link is here:

http://stackoverflow.com/questions/44036757/why-doesnt-pythons-multiprocessing-semlock-have-name

This mailing group might be a better place to ask because the question is
about the internal implementation.

I don't want to paste the question text in the email body because I
included source code which might get mal-formatted when pasting. Sorry for
the inconvenience.

*Could anyone help me on the question?* I would appreciate it!! This
doesn't affect any of my work but I am really curious about the reason.

Best,
Yaobin
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Format strings, Unicode, and Py2.7: need clarification

[Hobson Lane]

Yea, *must* probably should have been *should (unless indicated by the
method name)*. I forgot about the many methods that don't. But the names of
these methods, like `split()`, imply the types that they return.

Your example reminded me of the convention (outside python core) to name
getters and setters so that they imply their returned type. Similarly for
conversion methods like `to_*()`). But the name `format`, in my mind,
implies that it only changes the *contents* of the str, rather than
morphing its type.

The % example surprised me too, but it clicked for me when I realized % is
a binary operator and not a method.

--Hobson
(503) 974-6274
gh  twtr  li
 g+
 so


On Thu, May 18, 2017 at 7:25 AM, Random832  wrote:

> On Thu, May 18, 2017, at 01:14, Hobson Lane wrote:
> > Because `.format()` is a method on an instantiated `str` object in e and
> > so
> > must return the same type
>
> That it *must* return the same type is overstating the matter. Split
> returns a list (and, rather like %, the list is of unicode or str
> objects depending on the argument). Join will return a unicode object if
> any of the elements of the sequence are unicode. I was honestly
> surprised though to see that % returns unicode when formatting a unicode
> value, since my mental model of %s was more like {!s} - call str() on
> whatever object is at the given position in the right-hand argument.
> This kind of ad hoc implementation decision (format always returns str,
> other methods can return unicode,  ljust/rjust refuse to accept a
> unicode character argument) is what Python 3 moved away from.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> hobsonlane%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com